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.
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.
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 127.127.1.0 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?
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.
ntpd time server use:
server 127.127.1.0 prefer fudge 127.127.1.0 stratum 2 driftfile /var/lib/ntp/ntp.drift restrict default nomodify notrust restrict 127.0.0.0/8 disable auth logfile /var/log/ntp.log
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:
-gis the default on some Linux distributions, but it won't make large backwards steps.
tinker step 0.5and
tinker panic 0to maximise
ntpd's ability to fix large offsets.
ntpdand is getting saved correctly when it shuts down.
Third suggestion (which I would prefer over
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.