Time-admin's "Synchronize Now" should be enabled even in NTP mode

Thank you for your bug report. I can reproduce this here, and it is not expected behaviour.

The "synchrosize now" action is available if you don't use the NTP mode

My problem is that when I switched the NTP, the time did NOT synchronized immediately. For at least 5 minutes I was getting the wrong time still. You have to either enable that button, OR, make it synchronize immediately after the user changes to NTP mode.

Hi,

> You have to either enable that button,
From ntpdate man page:

 ntpdate will decline to set the date if an NTP server daemon (e.g., ntpd) is running on the same host.

So it has to be:

> OR, make it synchronize immediately after the user changes to NTP mode.

 Or fix the Edgy regression about 'without the full ntp package the button doesn't update the date but screws ntpdate-debian' cf #62745 and #83604 and remove the config manual/internet.

> My problem is that when I switched the NTP, the time did NOT synchronized immediately

that's what NTP is doing, it doesn't do disruptive changes and do a smooth compensation rather

I believe the "update now" button exists on both Windows and OSX and it is used quite regularly...

the GNOME tool also has a "synchronize now"

The Problem is also that ntp is only synchronizing at startup by me, if I have no connection on startup, then it is not synchronizing at all...

When seting up the clock to sync with servers, the applet is modifying the ntpd.conf, it should also configure it to sync once an hour or something like that, by default

this, then, looks like a duplicate of bug 90267. Please have a look at the comments there.

A quick summary:

1. if ntp is started before network interfaces are active, then it will not work until restarted.

2. if ntp is running then ntpdate will not run (working as designed)

3. If network-manager is inactive, then ntp works OK (i.e., no issue as in (1))

4. if ntp is installed then the "synchronise now" button is grayed out (working as designed, AFAIK).

5. ntp will not make a big correction to the clock but instead will slowly adjust it (working as designed)

Ok, but there are always some issues :

ntp is installed by default on ubuntu, so is also for network-manager.
If I've understood, it means that every user that won't start with network will have this problem. I think there is need to find a better solution, because I don't believe new users are able to stop ntpd by themself, and they even don't will understand that the problem comes from ntpd...

Maybe a solution would be to make network-manager restart ntpd , when link is up ?

Or to disable ntp by default, and enable the ntpdate from the gnome clock, as a beginer will first try to modify things through the gui...

@schmirrwurst:

yes, this is why I suggested looking at the other bug. I do not see an immediate, simple solution here. Of course, NTP's approach to correcting the clock seems sensible and good, but some users want the clock corrected NOW, and this approach (I mean NTP's) may simply not do the trick here.

Also, "synchronise now" does not make sense when NTP is running (since only ntpdate can do it) -- and, at the same time, will potentially confuse a lot of users. On the other hand, the default behaviour of ntpd is to step differences bigger than ~ 100 ms -- which means instantaneous correction, so this is no big deal, unless you really need your clock accurate to the 10s of ms.

I think this will have to be worked out on discussions by the developers.

After just installing Feisty, I ran into this exact same problem. I puzzled over it for quite a bit without figuring out what exactly was expected of me. After reading the comments here, I am still very confused. Hopefully this can be sorted out somehow.

I have another case where a "synchronize now" button should be available:
When running Ubuntu in VMWare, suspending the VMWare session and then resuming it at a later time, the clock is stuck at the time you suspended it. So even though I'm using ntpd to keep the clock in synch, I also want to be able to synchronize it "now" rather than waiting a few years for ntpd to catch up. I'm guessing this is a problem for most suspend solutions.

I was just noticed this problem on my Gutsy system. I think the answer's here already but not entirely intuitive. To do a sync "now", you have to go to "manual" mode and hit "synchronize now". I saw my time change when i did that. Then you can go back to "keep synchronized" mode if you want.

Couldn't the "sync now" button do just what brianhanna suggested? That is, stop ntpd, run ntpdate and start ntpd again?
What server does ntpdate use to sync on?

How about (waves hands vaguely) determine whether NTP is present and working, and, if so, change the label to "Synchronization in progress ..." or some such? Then it makes sense for the button to be greyed out.

Maybe we can go with the "brutal" solution to stop ntp, run ntpdate and restart ntp. This is relatively easy to do from the backends. But it seems to me that ntp should be able to handle those problems better on its own.

This is still a problem in 64 bit Lucid. I noticed my clock was off by several minutes and went into system > Admin > Time & Date to set it and discovered that it was set to manual. I set it to use a time server on the internet and when I was done, it still displayed the wrong time. There is no "synchronize now" button, either grayed out or otherwise. I tried logging off and on, but that made no difference. On going back to Time & Date, I noticed it was set back to Manual mode and again set it synch with time servers, but no change happened. I finally set the clock manually, but don't know if it's going to stay synced with correct time of not.

I should also mention that the first time I ran Time & Date it needed to install ntpd as that was not installed by default.