3

I had a situation lately with a host that need up to date ntp servers. We had during the weekend a crash of our internet router. When everything came back to hte normal our application was still complaining about NTP.

We discovered that the ntp client took 9h to get sync. Here is the ntpd's logs :

Aug 19 15:31:15 host ntpd[26550]: kernel time sync status 0040
Aug 19 15:31:15 host ntpd[26550]: frequency initialized 97.149 PPM from /tmp/drift
Aug 20 00:29:24 host ntpd[26550]: synchronized to 192.168.10.13, stratum 3
Aug 20 00:29:24 host ntpd[26550]: kernel time sync disabled 0001

When the issue occured here is the output of peers state :

# ntpq
ntpq> peers
remote refid st t when poll reach delay offset jitter
==============================================================================
srv1 145.238.203.10 3 u 31 64 377 0.714 -685.16 6.388
srv2 145.238.203.10 3 u 5 64 377 0.652 -1385.7 12.165

Someone told me that I should use minpoll and maxpoll settings to solve this issue.

What should I do to avoid 9H NTP synchronisation ?

|improve this question
  • Your information is very "out of whack". Your log says you're synced to 192.168.10.13, yet ntpq peers says 145.238.203.10, and that peer is listed twice as 2 different servers, with different offsets. (P.S. it's better to use ntpq -p as it indicates which server you're currently syncing to). – Patrick Sep 24 '13 at 1:24
  • 192.168.10.13 is srv1. srv1 is prefered ntp server in ntpd.conf It seems that when the ntp is synced reach filed is at 377. – Hugo Oct 7 '13 at 12:49
  • You need to post your ntp.conf. Why are you storing the drift file in tmp? – dfc Jan 18 '14 at 0:08
2

The offset is way too large; make sure to synchronise the clock “one-shot” before you start xntpd, e.g. with rdate (sudo rdate -nv 2.pool.ntp.org) or xntpd’s very own ntptime utility.

|improve this answer
  • 1990 called they want their rdate example back. Use sntp on a modern system. On an older system use ntpdate. use rdate on the computers in museum displays. – dfc Jan 18 '14 at 0:08
  • 1
    @dfc please read the rdate manpage again: the -n option does precisely that, it uses the SNTP protocol – and that in a manner much better than xntpd's ntpdate – to set the time. Just thinking for a second would have shown that, as 2.pool.ntp.org surely doesn't offer RFC868 rdate service, only NTP. – mirabilos Jan 19 '14 at 12:36
  • I don't have the rdate manpage installed; the 90s are over. xntpd? Seriously are you from the past? – dfc Jan 19 '14 at 16:25
  • 1
    @dfc that's why I made that into a link… sigh – mirabilos Jan 19 '14 at 22:52
0

The other alternative is to add the following to ntp.conf:

tinker panic 0

or adding -g to your ntpd startup options.

This will allow ntpd to deal with the offset no matter how big it gets.

One more thing; two time servers is the worst possible configuration for acquiring the time. Your ntpd will have no idea which clock is better when they report different times. Use a minimum of three clocks.

"A man with a watch knows what time it is. A man with two watches is never sure."

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.