New answers tagged ntp
Debian OpenNTPD packaging automatically restarts it if an interface comes up. This is common. Also, you will (usually) need to sync one-shot before starting xntpd anyway, so I suggest this is the way to go.
You might have been bitten by an edge case for ntpd: IIRC ntpd versions < 4.2.4p3 removed any servers from it's synchronization list that couldn't be reached at some point. This is of course quite bad in this case, as ntpd might very well 'exhaust' the list of its peers before gaining internet connectivity. One could/can set the dynamic option for these ...
In the end it turned out that it was the ESX Host that was messing with the time on the VM. The time of the ESX host was manually configured and was approx 60sec off the normal time. After we synchronized the host with an NTP server the problem disappeared. I still ask myself how could a VM that does not have vmware tools installed to pull the time from ...
I was expecting ntpq to query local server via 127.0.0.1, but it turns out to be querying local server via ethernet network interface. Although I have no idea why a local ntp query would have to go through ethernet, but in configuration file I added restrict <eht0 ip address> And now NTP works fine.
I convinced myself that the problem was a misidentified time stamp counter (TSC) frequency. Apparently the kernel is calibrating the TSC against the programmable interval timer (PIT). Usually the identified CPU frequency is 2400.204 ± 0.134 MHz, which corresponds to about 56 ppm accuracy. After the problematic boot the CPU freq was estimated as 2383.579 ...
This type of behavior is atypical. A good check would be to monitor the values of the ntp.drift file to see if significant changes happen when the behavior was showing up. If it kept changing significantly, NTP was attempting to skew around a problem. If that was the case, it's a sign that the kernel misidentified the true clock frequency on startup, or the ...
Top 50 recent answers are included