Ubuntu 12.04 LTS regularly loses sync with NTP server

Question

I have a Ubuntu 12.04 LTS VM running inside VirtualBox. It is fine except the clock winds up being exactly 25 minutes behind every other machine on the network. My normal procedure is to setup NTP, run ntpdate manually, and then I never have any problems. I have tweaked the NTP setting and even added another local NTP server as a precaution. But I noticed all the other machines (VM or physical) write a drift file to /var/lib/ntp. This machine never does that. It has the following line in /etc/ntp.conf

driftfile /var/lib/ntp/ntp.drift

But the file is never created

ericu@ubuntu-lts-base:/etc/apparmor/init$ service ntp status && ls -l /var/lib/ntp/
 * NTP server is running
total 0
ericu@ubuntu-lts-base:/etc/apparmor/init$ 

I checked the permissions on the directory

ericu@ubuntu-lts-base:/etc/apparmor/init$ ls -l /var/lib | grep ntp
drwxr-xr-x 2 ntp      ntp      4096 Jun  5  2012 ntp

Looks good to me. What is going on here? This has to be the problem. Every other machine creates a drift file just fine and never loses sync with the NTP server.

Answer 1

Check the log files; you should expect to see the ntp daemon adjusting the clock periodically. Any virtual machine will skew. If there're no ongoing corrections happening then ntpd isn't working and losing sync is inevitable.

Use 'ntpq -p' to check what your ntp client reports about your ntp servers.

[user@host-1 ~]$ ntpq -p
 remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+1.1.1.2      69.15.40.29      3 u  827 1024  377    0.575   -0.553   0.125
+1.1.1.3      38.229.71.1      3 u  582 1024  377    0.393   -0.170   0.104
 1.1.1.4      11.4.12.87       4 u  479 1024  377    0.465   -0.276   0.020
*1.1.1.5      67.18.87.111     3 u  634 1024  377    0.460   -0.117   0.575

It's got tons of great info. You should expect to see small but non-zero values for delay, offset, and jitter. 'reach' should be 377 - if it's 0 it means your ntp client isn't successfully querying the associated ntp server. Other signs of not successfully connecting to the server include if refid says '.INIT.', or if stratum (st) is 16. If this is the case start checking the normal "reachability" criteria: firewalls, whether the ntp server is configured to allow that client, etc.