NTPD slews time when it doesn't need to

Krist van Besien asked:

I have some odd behaviour running ntpd on a rhel 6.5 machine. This machine runs as a virtual machine on a kvm host (also rhel) and this host has the correct time (within a few ms), and an ntpd that keeps it correct.

What I noticed is that after i do an ntpdate -u the time will eventually become good, and usually stay there.
However Red Hat recommends that one runs ntpd also on virtual guests. So I start ntpd. Now this goes well on most of our hosts, except for a few where I see a wierd behaviour.

On those hosts as soon as ntpd is started time starts to lag on those systems by about 0.5 ms/sec (or the 500 ppm that is the maximum ntpd will slew time by).
And this even before the ntpd has aquired a peer it can synch with…

Stopping ntpd stops the time from drifting. Start it, and time start drifting again.

In other words, I seem to have an ntpd that on some systems (and this baffles me, as they are all identical) does more or less the exact oposite of what it should do.

My ntp.conf is fairly straightforward:

tinker panic 0

# Permit time synchronization with our time source, but do not'
# permit the source to query or modify the service on this system.'
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict -6 ::1

server time.mydomain.com

# Driftfile.
driftfile /var/lib/ntp/drift

What could be the cause of this?

My answer:

It sounds like ntpd has an incorrect idea of the virtual machine’s clock drift, and is incorrectly compensating for drift. Stop ntpd, delete the driftfile and restart ntpd.

If this doesn’t fix the issue, consider switching to chrony. This is the default NTP client in EL 7, and is available in EPEL for EL 6.

View the full question and any other answers on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.