0

I have written a Puppet module that corrects the time via NTP, but this only works on server with a small NTP offset.

There are sometimes server with a time offset higher than 10 minutes for various reasons.

I want to make a Puppet module that runs exec "service ntpd stop; ntpdate ntp3.domain.local; service ntpd start" when the ntp offset is too high, to forcably correct the time.

How can I see if the NTP offset is too high in order to tell Puppet to run this command? Or are there better solutions?

ujjain
  • 348
  • 1
  • 6
  • 14
  • if you are running `ntpd`, why do you get such big time drifts? `ntpd` should be continually adjusting the time to *always* match. be aware that large time jumps can raise unexpected behaviour of loads of programs. – umläute Sep 19 '13 at 21:14
  • 1
    Check out that Q, they discuss the iburst feature of NTP which will force ntpd to "catchup" if the time is lagging far behind. – slm Sep 19 '13 at 21:25
  • 1
    @slm: iburst will do no such thing. You want `-g` (or a tinker line)... – derobert Sep 19 '13 at 23:18
  • @derobert - That was the take away in that other thread. I've never tried it, I always use a ntpdate, it's just easier to me. – slm Sep 20 '13 at 00:08

1 Answers1

1
service ntpd stop; ntpdate ntp3.domain.local; service ntpd start

is definitely the wrong solution for this problem. Use the -g option for ntpd:

   -g     Normally, ntpd exits with a message to the  system  log  if  the
          offset  exceeds the panic threshold, which is 1000 s by default.
          This option allows the time to  be  set  to  any  value  without
          restriction; however, this can happen only once.  If the thresh‐
          old is exceeded after that, ntpd will exit with a message to the
          system log.  This option can be used with the -q and -x options.

Combine this with the iburst option as slm suggested because without this it would take ntpd ages to correct such a huge difference. It usually tries to change the system time only in very small steps so that time-dependent applications don't get confused, but the iburst option will change this.

You will still have to ensure that Puppet automatically restarts ntpd after it panics, because according to the manpage it will fix the time once and then it will die nonetheless.

Martin von Wittich
  • 13,857
  • 6
  • 51
  • 74
  • 1
    `iburst` ONLY causes ntpd to initially send more packets. It makes the initial decision of "what time is it, really?" take ~10s instead of ~5m. Unless you've used `-x` (or some `tinker` options), a time offset >128ms will always be stepped, i.e., instant. – derobert Sep 19 '13 at 23:22