6

We have some hosts that have gotten out of sync due to ntpd being mis-configured, with an ntp server that was unreachable. Our clocks on some hosts (CentOS 6) are now upwards of 30 seconds off (in the future it seems, for most of these).

It looks like from the docs of ntpd that the fastest sync we have available is around 500us/s -- is there any way to increase this so that the clocks update much faster, but not instantly? For example, we'd like to have this set instead to something like 100ms/s.

Is this possible? If so, how can we go about this safely?

Is it dangerous?

MrDuk
  • 865
  • 2
  • 10
  • 18
  • 1
    Unless you allow the clock to periodically retrogress, which is not done by default anymore, you should experience no trouble. – Falcon Momot Oct 09 '15 at 23:17
  • 2
    Having your clock stuck in the future is a real problem, and moving time backwards by large chucks is guaranteed to make services freak out. eg: postfix will literally generate a log message "time moved backwards" and then immediately exit. Just let ntpd move by 500us/s and after 17 hours you'll be back in sync. – Sammitch Oct 10 '15 at 00:07
  • 1
    Make sure you are _not_ passing the `-x` option to `ntpd`. – Michael Hampton Oct 10 '15 at 00:53
  • Related: [How to force a clock update using ntp?](http://askubuntu.com/q/254826) – Martin Schröder Oct 17 '15 at 19:02

1 Answers1

1

The safe thing to do is to take down services then just set the clock. Such as with ntpdate, which tends to ship with a init script to do that at boot. Downtime isn't fun, but databases and other things don't like the clock going backwards.

The Linux adjtimex man page describes the system call used. Allowed offsets are measured in usec, it takes a long time to slew.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34