How to force locally isolated ntpd update time

by ayvango   Last Updated March 29, 2018 01:00 AM


I had locally isolated hosts. I'd like them all have the same time. One takes role of the time server, other syncs with it as clients.

All machines has sporadic uptime. They are powered rarely. So they could gain significant offset. Entire hosts set should become synced within minutes after setting the server local time manually.

To confirm reliability I had tested the ntp hosts connection by setting great manual adjusts (several hours) and measured how fast clients synced.

ntpd - ntpd case

I tried use ntpd for clients as well the server. ntpd take very long time to adjust clock. Moreover it refuses to rewind time by couple of hours.

If it could be fixed, I prefer to use ntpd as client. So I'm looking for configuration options to hint ntpd for being eager at accepting network clock updates.

But if there is no way to employ ntpd, ntpdate alternative is still acceptable.

ntpd - ntpdate case

ntpdate perfectly updates clock without hesitation. I put it in a cron task and got rough but working solution. Unfortunately the first impression was wrong. After several tests I noticed that the ntpdate client started refusing the server. For some reasons server decided to return stratum 16. I explicitly put fudge stratum 8 into the ntp.conf on the sever side to avoid this exact behaviour. But ntpdate -v -d output shows "stratum 16" transmitted from the server.

So I see two ways. Either compel the ntpd server return stratum 9 regardless of local time jumping or force the ntpdate client to accept any server, even if it has stratum 16.

I tried to google either way but found nothing. Could anyone suggest suitable configuration options?

Answers 2

Use one ntpd time server for all. All everyday rebooted PC can synchronize their clocks at start by ntpdate command. Clocks on other servers can be synchronized by ntpd service because it adjusts time softly.

For main ntpd time server use:

server prefer
fudge stratum 2
driftfile /var/lib/ntp/ntp.drift
restrict default nomodify notrust
disable auth
logfile /var/log/ntp.log
Mikhail Khirgiy
Mikhail Khirgiy
March 23, 2018 18:46 PM

My main suggestion: Don't do this. Try to change your requirements or constraints so that you can have an always-on system which can be a time source, or so that your systems are not isolated and can get time from the global NTP pool, or both.

You can get low-power NTP servers with GPS receivers quite cheaply nowadays. If you like to DIY, BeagleBones and Raspberry Pis can be made into NTP servers for under US$100, or if you want something off-the-shelf, try a LeoNTP.

Next suggestion: if ntpd takes a long time to update the clock, you probably need to check your configuration:

  1. Make sure you are using the -G command-line flag; -g is the default on some Linux distributions, but it won't make large backwards steps.
  2. Ensure all of your servers/pools are configured with iburst.
  3. Use tinker step 0.5 and tinker panic 0 to maximise ntpd's ability to fix large offsets.
  4. Make sure your drift file is writable by ntpd and is getting saved correctly when it shuts down.

Third suggestion (which I would prefer over ntpdate): try chrony - it has explicit support for occasionally-connected clients (like laptops which are suspended regularly). The chrony.conf(5) man page has all the details about this. If you're using a distribution where chrony is the default (CentOS/Red Hat, and Ubuntu after 18.04 is released), this would probably be my second suggestion.

Last suggestion: if ntpdate is reporting a server as stratum 16, it means there's something wrong with that server. Try posting the configuration of the server, and the output of ntpq -np and ntpq -nc rv so that we can help diagnose it.

Paul Gear
Paul Gear
March 24, 2018 00:04 AM

Related Questions

Different offset in "ntpq -p" and "ntpdate -q"

Updated December 01, 2015 13:00 PM

NTP client reseting date to 1970

Updated July 17, 2017 14:00 PM