Roger Oberholtzer wrote:
On Sat, 2011-07-16 at 02:43 +0200, Carlos E. R. wrote:
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.
So, there is a flaw in the ntp start logic when the network interface on which it's server lives only becomes available some time after ntp starts. It seems never to re-check that a server that was initially not available later becomes available.
I don't think that is correct. As my logs showed last week, ntp is perfectly capable of switching time source/server when the availability/quality changes. However, if ntp fails to start, it would (obviously) also not be checking any servers later. Have you looked at the output of "ntpq -p" at different points of your problem scenario?
IMO, the problem is ntp, not the system start stuff. Since I have effectively removed my network from the system startup environment, I would find it hard to see that environment being able to solve ordering or dependency issues. How could a system service know that some user will, via their own non-system configuration, eventually, maybe start a network where an interesting server lives?
A daemon would just try to reach the interesting server, and when the error says "network not reachable" (or something similar) it means it's still not there. Personally I don't think there is a problem with ntp here - maybe in the network config or the ntp config, but not ntp itself. Your options are probably to 1) debug your ntp setup or 2) pursue a chrony setup. If you want, I'll be happy to help with option 1), but I'll need some more detailed info. -- Per Jessen, Zürich (16.1°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org