How to force locally isolated ntpd update time

Question

Objective

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 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?

score 2 · Answer 1 · answered Mar 23 '18 at 18:46

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 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

answered Mar 23 '18 at 18:46

Mikhail Khirgiy

2,003
9
7

I have the same configuration. But the *ntpd* (from Ubuntu 16.04) ignores `fudge 127.127.1.0 stratum 2` option sometims. Debug shows that the *ntpd* server sends stratum 16 for some unknown to me reason – ayvango Mar 23 '18 at 18:52
Do you have only one server declaration in ntpd. conf file? – Mikhail Khirgiy Mar 23 '18 at 18:54
yes. I removed all other servers and pools. And server resides in a network isolation. – ayvango Mar 23 '18 at 18:55
Server is physical or virtual? – Mikhail Khirgiy Mar 23 '18 at 18:57
Physical. It would be used in a place without internet – ayvango Mar 23 '18 at 18:59
Hmmm.... It's strange. I'll try to test it next week. – Mikhail Khirgiy Mar 23 '18 at 19:01
Could you try setting within half a hour time 8 hours back, then 6 hours back, 7 hours forth, 5 hours forth and so on. I performed such test prior to nptd begin sending stratum 16 – ayvango Mar 23 '18 at 19:08
If system time will so often canged manually, I think, ntpd will decide that the system clock has been damaged. – Mikhail Khirgiy Mar 23 '18 at 19:19
add the "true" keyword if you want your main server to consider the local clock always correct. – cde Jun 20 '20 at 09:10

Paul Gear · Answer 2 · 2018-03-29T00:07:47.940

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:

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.
Ensure all of your servers/pools are configured with iburst.
Use tinker step 0.5 and tinker panic 0 to maximise ntpd's ability to fix large offsets.
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.

The configuration is irrelevant. After restarting it begin serve proper stratum. So it is not a configuration issue but a runitme behaviour. Changing local clock frequently made ntpd believe in failure. I read documentation about `tinker step` it is about slewing not about ignoring large steps. But it says that there is 900s threshold for discarding large steps. Is it possible to change that threshold? — ayvango, Mar 28 '18 at 09:41
example: setting local time one year back made server return stratum 16 for many hours — ayvango, Mar 28 '18 at 12:05
@ayvango: I don't know which documentation you're reading, but http://doc.ntp.org/current-stable/miscopt.html#tinker and http://doc.ntp.org/current-stable/clock.html#step make it very clear that `tinker step` is about stepping, not slewing. You also probably want `tinker panic 0` to ensure `ntpd` stays running no matter what. — Paul Gear, Mar 29 '18 at 00:06
The configuration is not irrelevant; if it's serving bad time (stratum 16) and a restart with the same configuration causes it to serve good time, that means that the configuration is not enabling it to keep serving good time consistently. The config items I've suggested should help this (although they can't guarantee it). — Paul Gear, Mar 29 '18 at 00:09

How to force locally isolated ntpd update time

Objective

ntpd - ntpd case

ntpd - ntpdate case

2 Answers2

Linked