FFe: DBus time API should control ntpdate, not ntpd

Bug #734894 reported by Michael Terry
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNOME Settings Daemon
Fix Released
Medium
gnome-settings-daemon (Ubuntu)
Undecided
Unassigned
Natty
Undecided
Unassigned

Bug Description

Binary package hint: gnome-settings-daemon

time-admin and indicator-datetime-preferences both have controls that allow the user to choose between "Automatically set time from Internet" and "manual time".

However, those options don't do what they sound like because of ntpdate.

ntpdate is installed by default and sets the local time from an ntp server every time the system is connected to the Internet. This is done by /etc/network/if-up.d/ntpdate and has no graphical interface.

"Automatically set time from Internet" controls whether the ntpd daemon is running or not. ntpd is *not* installed by default (time-admin will prompt to install it). When the ntpd daemon is running, time is always current, not just when you connect to the Internet.

"Manual time" allows the user to set time manually like you expect, but since it doesn't turn off ntpdate, time will be reset when you next connect to the Internet.

What we (especially mpt) want is to have "automatically set from Internet" turn on/off ntpdate so that manual time is actually manual time until the user decides to automatically sync again. So gnome-settings-daemon needs to change what it does when asked to sync to Internet.

Currently gnome-settings-daemon controls ntpd, but it should instead modify /etc/default/ntpdate to (un)comment NTPSERVERS.

time-admin uses system-tools-backend which has the same problem. But I'm more focused right now on gnome-settings-daemon (used by indicator-datetime-preferences), since gnome-settings-daemon is the preferred way to set time.

Revision history for this message
Martin Pitt (pitti) wrote :

As I was the one who originally pointed out the issue and was part of the discussion to find the better solution, I abstain from deciding about this FF.

I'd recommend approving it, though. The current status quo is both incomplete (there is no installation of ntpd, the "automatic sync" option is just grayed out) as well as very confusing (the user thinks that the time is handled only manually, while it is actually synced each time an internet connection is established).

It would make much more sense if the "Automatic sync" option would be on by default (reflecting the fact that we enable ntpdate by default), and the user can switch it off manually. Personally I don't see an use case for doing that, but according to Matthew there are some users who deliberately keep their local time off by ten minutes and don't want ntp sync.

Revision history for this message
Martin Pitt (pitti) wrote :

Oh, and thirdly, I don't really see enough of an use case for having ntpd on a desktop system that warrants exposing this in the GUI. ntpd has nonzero overhead in terms of extra CPU/memory/battery/start up time/CD space, and also opens a network port.

Revision history for this message
Kate Stewart (kate.stewart) wrote :

Approved.

I agree that the way it is right now is confusing. This change should be release noted though, since it will be changing a visible behavior.

(Another possible use case for going to manual, is if traveling and want to use local time temporarily. )

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 734894] Re: FFe: DBus time API should control ntpdate, not ntpd

On Mon, Mar 14, 2011 at 04:16:03PM -0000, Martin Pitt wrote:
> Oh, and thirdly, I don't really see enough of an use case for having
> ntpd on a desktop system that warrants exposing this in the GUI. ntpd
> has nonzero overhead in terms of extra CPU/memory/battery/start up
> time/CD space, and also opens a network port.

GUIs notwithstanding, ntpdate is not a proper substitute for ntpd. At best,
ntpdate gives you a one-time sync with a network time source when the
network interface comes up, after which the clock will resume drifting
unchecked. For a true "desktop system", which may have a wired network
connection that never goes down, this can easily result in clocks drifting
well outside the requirements of certain time-synced network protocols (such
as Kerberos).

I don't think this changes anything wrt the FFe or the decision about how to
handle time syncing on the desktop, I just want to be clear about the
rationale and note that there are use cases that ntpdate will not satisfy.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Steve Langasek (vorlon) wrote :

On Mon, Mar 14, 2011 at 04:25:50PM -0000, Kate Stewart wrote:

> (Another possible use case for going to manual, is if traveling and want
> to use local time temporarily. )

No, you should change your configured timezone setting instead, you should
never set the system clock in local time ;)

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Michael Terry (mterry) wrote :

To be clear, the modified plan is to control both, if available. That is, if requested to use automatic time, both ntpd and ntpdate will be enabled. And the other way around. gnome-settings-daemon just won't *require* ntpd to be installed to be useful anymore.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-settings-daemon - 2.32.1-0ubuntu9

---------------
gnome-settings-daemon (2.32.1-0ubuntu9) natty; urgency=low

  * debian/patches/33-datetime-service-ubuntu-ntp.patch:
    - Update to disable/enable ntpdate as well as ntpd. LP: #734894
 -- Michael Terry <email address hidden> Mon, 14 Mar 2011 15:38:04 -0400

Changed in gnome-settings-daemon (Ubuntu Natty):
status: New → Fix Released
Michael Terry (mterry)
tags: added: patch-forwarded-upstream
Changed in gnome-settings-daemon:
importance: Unknown → Medium
status: Unknown → New
Changed in gnome-settings-daemon:
status: New → Confirmed
Changed in gnome-settings-daemon:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.