2

I understand ntpd has a -g option to allow a one time immediate clock set for large skews. Then the daemon runs and continuously adjusts. In the event of the skew becoming too large, the daemon exits with an error.

With this understanding, is it sufficient to run a process manager like pm2 that will run ntpd -g when the daemon stops running?

Elliot
  • 121
  • 3
  • 1
    Check the system log to see if the offset exceeds the panic threshold. How far off is your system? Have you tried using sntp for a one-off. Do you use something like munin to log the ntpd offset/drift? – Alexx Roche Oct 13 '17 at 07:08
  • Yes - clarifying whether this is something you're seeing in practice or purely hypothetical would help. – Paul Gear Oct 14 '17 at 21:12
  • Purely hypothetical – Elliot Oct 16 '17 at 18:15

2 Answers2

3

If ntpd is exiting regularly, it means that it's having problems keeping your clock in sync. You probably want to be notified if this happens, so getting your process monitor to send an email or alert whenever it restarts ntpd might be a good idea.

However, if you have an extremely poor quality local clock, this might happen a lot, so combining the -g flag (which is the default on some distributions) with tinker panic 0 in your ntp.conf (to keep ntpd from exiting) may be necessary. If you do this, you probably want to monitor frequency & offset through a monitoring system.

Paul Gear
  • 3,938
  • 15
  • 36
  • ntpd 4 should be able to deal with +/- 68 years (this isn't your grandfathers ntpd) so the kernel or some other process is probably killing it – Alexx Roche Oct 13 '17 at 07:05
-1

For large time corrections, I suggest you using ntpdate which, by implementing the simpler SNTP protocol, is much faster and only slightly less accurate than ntp.

I generally use it on boot: after having adjusted any large time difference with ntpdate, the ntpd service can do its work by issuing fine-grained time corrections.

shodanshok
  • 44,038
  • 6
  • 98
  • 162
  • 3
    Keep in mind that `ntpdate` is deprecated, all ntpdate functionality is part of recent versions of ntpd. http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate – Zoredache Oct 12 '17 at 22:23
  • 1
    Sure, but as a fast boot time-only solution, it remain the better approach in my opinion. I also read something similar in a red hat configuration guide, but I don't remember exactly were/when... – shodanshok Oct 12 '17 at 22:50
  • @Zoredache so we should use **sntp -c pool.ntp.org -K /dev/null** to replace **ntpdate pool.ntp.org** ? (Seems sntp could do with some sideways compatibility ) – Alexx Roche Oct 13 '17 at 06:59