On 2011-07-16 01:16, Roger Oberholtzer wrote:
On Fri, 2011-07-15 at 12:45 -0400, Anton Aylward wrote:
I am on a laptop that exhibits the problem. hwclock -r is showing the correct UTC time that I expect. The network is up via NetworkManager when I logged in graphically. The ntp that started when I booted is still running. But, alas, the time is incorrect. It can sit like this for hours, and the time will NEVER be corrected. Ever. Consistently.
All I have to do now is run 'rcntp restart', and time will be corrected.
Of course. When ntp is running, it will adjust the clock very slowly, so slow that you will not notice it is changing. If there is one minute error it may take hours to correct. However, if you restart the daemon, using the script, the first step is jump-set the clock, even by hours if needed, and after that it will run the daemon to keep it correct.
This happens on any computer I set up with ntp starting at boot (the supplied rc script unmodified) and a network that starts some time after that outside the ifup/rc script environment.
Obviously. At that time, the jump-set can not work, there is no network. Later, only slow adjustments will be made. NTP must not be started till network is up. Never earlier. If you are not using ifup scripts, and the network is not mandatory, do not start ntp on boot. Start it manually, later.
I suspect it is that the ntp rc script is assuming that since it is set to start after networking, it can assume that access to time servers is available when it starts. Alas, when a network device starts some time afterward, this assumption is faulty.
What is faulty is not starting the network earlier, ie, using network manager.
This would not be a huge problem if ntp checked again if a server becomes available. If it is trying this, it is not working. The server is now available. But until I do 'rcntp restart', the time will never be corrected.
Ntp does check, but it can not jump-set the clock once it is running. As documented.
In this configuration, when the system does have correct time when the system is shutdown (I have restarted ntp), shouldn't the time come up correct when the system is rebooted?
Only after weeks. Ie, if the conditions are stable.
It would if the claim that ntp kept a record of the drift and used that when it first starts. Alas, the time is always the BIOS time. Which is always the expected two hours off. The hardware clock is working. ntp is just not adjusting it when the config above is used.
No, ntp is not responsible to set the correct time just after booting. And the time must be correct to within seconds, without ntp, else you have a problem I already said how to correct.
I am flexible. I just need it to work reliably all over the world, no matter what silly things the users may try.
If the users move around time zones, and _they_ set the clock, weird things will happen. For this to work, bios must keep UTC time. The linux timesetting logic is not designed for people on the move. The original design is for stable machines, server type.
Nope! The init scripts CANNOT make my wireless connection available to ntp. They have no connection to networks brought up outside the traditional ifup method. Like KDE/GNOME Network Manager-type initialization.
Then you have to make sure that NTP is restarted later, no matter what.
Ah! Perhaps 'systemd' will be able to cure that :-)
Nope. See my comment above.
It might, if it can restart services on events (network goes up). -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)