1

This question was asked a lot in the past, but since ntpdate has been depricated, I'm having issues finding answers that work via ntp.conf. I've read a lot about setting a cron job for ntpdate is a bad idea now, so that answer won't work for me.

My server time (ubuntu 14.04 server) is drifting quite a bit, and I have a time server I'm using locally.

In my ntp.conf file I have my server listed like this

server 192.168.1.25 iburst burst minpoll 4 maxpoll 4

Despite these settings the watchdog timer run from

ntpdc -c loopinfo 

never resets and my drift keeps getting larger and larger.

To sum up my question, why isn't my /etc/ntp.conf file actually doing anything? More info: This is a Ubuntu 14.04 VM running on Hypver-V and is used as a Redmine server.

output of ntpq -p (not sure if typo, but no q option)

    remote           refid        st  t  when  poll  reach   delay   offset   jitter
   ===================================================================================
    myother.server 192.168.1.26    2  u   2    16    377     0.607   0.808     4691.46 
Eric Carvalho
  • 54,385
  • Are you able to set the time using ntpdate? – muru Jul 17 '14 at 18:22
  • Please add the output of ntpq -qp. – Martin Schröder Jul 18 '14 at 14:10
  • When I run ntpdate -u 192.168.1.25 I get the offset, and I'm assuming it also sets the time correctly. However, when I try to set ntpdate up in cron, it won't run. I'm not sure why, but since it is depricated, I didn't really worry about it. – trueCamelType Jul 18 '14 at 18:36
  • The requested output is shown above. – trueCamelType Jul 21 '14 at 20:09
  • With that output it is clear it thinks your source is Stratum-2, which is very good. And surprising, since you are not using time.nist.gov. Here is a reference Q&A that talks to this subject, suggesting you reference the master clock directly: https://askubuntu.com/questions/972799/how-do-i-set-ubuntu-to-use-the-primary-time-server-time-nist-gov/972800#972800 – SDsolar Nov 04 '17 at 08:09

1 Answers1

0

After a bit of searching, the problem was obvious. It wasn't actually a problem with the machine itself, but with hyper-v. Apparently Hyper-v is a terrible choice for linux virtualization. It's a known problem that doesn't appear to have a fix other than just running something on the guest Linux machine.

I use this cron job

0 * * * * /usr/sbin/ntpdate 192.168.1.x

obviously the 192.168.1.x represents the ntp server. This fixed my time every hour. The documentation on how hyper-v has a hard time keeping time with linux guests is noted in several places such as here, and here.