4

I have setup one ntp server and 5 clients. I want to force sync the clients to server clock on boot. With my current ntp settings the computers are syncing but after several minutes. I cannot wait so long for them to synchronise. I am not using a RTC/GPS and all machines are in a LAN. What config or commands do I need to use to force them to sync all clients immediately on boot with the undisciplined server clock*?

Server ntp.conf

driftfile /var/lib/ntp/ntp.drift
leapfile /usr/share/zoneinfo/leap-seconds.list

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server 127.127.1.0
fudge 127.127.1.0 stratum 8

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Needed for adding pool entries
restrict source notrap nomodify noquery

# (Again, the address is an example only.)
broadcast 192.168.0.255

Client ntp conf

driftfile /var/lib/ntp/ntp.drift
leapfile /usr/share/zoneinfo/leap-seconds.list

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server 192.168.0.51

restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Needed for adding pool entries
restrict source notrap nomodify noquery

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
disable auth
broadcastclient

EDIT Adding result of suggested commands

root@displaypi:~# ntpd -g -x -q 192.168.0.71
23 Feb 16:36:22 ntpd[446]: ntpd 4.2.8p12@1.3728-o (1): Starting
23 Feb 16:36:22 ntpd[446]: Command line: ntpd -g -x -q 192.168.0.71
23 Feb 16:36:22 ntpd[446]: proto: precision = 0.815 usec (-20)
23 Feb 16:36:22 ntpd[446]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
23 Feb 16:36:22 ntpd[446]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): loaded, expire=2021-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
23 Feb 16:36:22 ntpd[446]: Listen and drop on 0 v6wildcard [::]:123
23 Feb 16:36:22 ntpd[446]: Listen and drop on 1 v4wildcard 0.0.0.0:123
23 Feb 16:36:22 ntpd[446]: Listen normally on 2 lo 127.0.0.1:123
23 Feb 16:36:22 ntpd[446]: Listen normally on 3 eth0 192.168.0.72:123
23 Feb 16:36:22 ntpd[446]: Listen normally on 4 lo [::1]:123
23 Feb 16:36:22 ntpd[446]: Listen normally on 5 eth0 [fe80::dea6:32ff:fee4:8867%2]:123
23 Feb 16:36:22 ntpd[446]: Listening on routing socket on fd #22 for interface updates
23 Feb 16:36:22 ntpd[446]: Listen for broadcasts to 192.168.0.255 on interface #3 eth0
23 Feb 16:36:29 ntpd[446]: ntpd: time slew +25.555462 s
ntpd: time slew +25.555462s
root@displaypi:~# date
Tue Feb 23 16:36:31 IST 2021
root@displaypi:~# date
Tue Feb 23 16:36:39 IST 2021
root@displaypi:~# date
Tue Feb 23 16:36:59 IST 2021
root@displaypi:~# ntpq -p
ntpq: read: Connection refused
root@displaypi:~# service ntp start
root@displaypi:~# ntpq -p
 remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 192.168.0.71    LOCAL(0)         4 u    1   16    1    0.192  25533.4   0.001
root@displaypi:~# service ntp sto
Usage: /etc/init.d/ntp {start|stop|restart|try-restart|force-reload|status}
root@displaypi:~# service ntp stop
root@displaypi:~# ntpd -g -x -q 192.168.0.71
23 Feb 16:38:03 ntpd[513]: ntpd 4.2.8p12@1.3728-o (1): Starting
23 Feb 16:38:03 ntpd[513]: Command line: ntpd -g -x -q 192.168.0.71
23 Feb 16:38:03 ntpd[513]: proto: precision = 0.778 usec (-20)
23 Feb 16:38:03 ntpd[513]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
23 Feb 16:38:03 ntpd[513]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): loaded, expire=2021-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
23 Feb 16:38:03 ntpd[513]: Listen and drop on 0 v6wildcard [::]:123
23 Feb 16:38:03 ntpd[513]: Listen and drop on 1 v4wildcard 0.0.0.0:123
23 Feb 16:38:03 ntpd[513]: Listen normally on 2 lo 127.0.0.1:123
23 Feb 16:38:03 ntpd[513]: Listen normally on 3 eth0 192.168.0.72:123
23 Feb 16:38:03 ntpd[513]: Listen normally on 4 lo [::1]:123
23 Feb 16:38:03 ntpd[513]: Listen normally on 5 eth0 [fe80::dea6:32ff:fee4:8867%2]:123
23 Feb 16:38:03 ntpd[513]: Listening on routing socket on fd #22 for interface updates
23 Feb 16:38:03 ntpd[513]: Listen for broadcasts to 192.168.0.255 on interface #3 eth0
23 Feb 16:38:10 ntpd[513]: ntpd: time slew +0.000000 s
ntpd: time slew +0.000000s
4
  • 1
    If you are not dealing with physical RTC hardware, you may want to look into a ‘software-clock’ option. Debian (and Ubuntu) have a package for handling this called ‘swclock’. It writes out the system time at shutdown just before poweroff/reboot, and then sets the clock to this on startup. For systems with almost no downtime, it will let ntpd properly sync the clock without any special options needed unless you keep the system off for more than about 15 minutes. – Austin Hemmelgarn Feb 24 at 0:02
  • what is the package name? apt install swclock doesn't work – Sap Feb 24 at 4:15
  • Ah, I was mistaken about the name, the actual package name is fake-hwclock. – Austin Hemmelgarn Feb 24 at 15:57
  • This is not at all accurate – Sap Feb 25 at 16:02
11

You can use the -g parameter. From the manpage:

-g

Normally, ntpd exits with a message to the system log if the offset exceeds the panic threshold, which is 1000 s by default. This option allows the time to be set to any value without restriction; however, this can happen only once. If the threshold is exceeded after that, ntpd will exit with a message to the system log. This option can be used with the -q and -x options. See the tinker command for other options.

So upon boot you would have to run once (add to some startup script) the following command (replace pool.ntp.org with your own NTP servers) in order to sync the local clock: ntpd -g -x -q pool.ntp.org

Afterwards you can run ntpd as normal.

13
  • I think this is the same as running ntpdate at boot. – Andrew Schulman Feb 23 at 10:09
  • 3
    ntpdate has been deprecated for some time now and it is missing from most modern GNU/Linux distributions. support.ntp.org/bin/view/Dev/DeprecatingNtpdate – basekat Feb 23 at 10:12
  • Thanks. Yes, ntpd -g seems to be the way to go. – Andrew Schulman Feb 23 at 10:16
  • 1
    On Debian & Ubuntu, this flag is supplied by default and you shouldn't need to use an extra invocation. – Paul Gear Feb 23 at 10:22
  • So ntpd shouldn't start before I run this command? I have tried manually to add an on boot script – Sap Feb 23 at 10:42
5

In addition to the -g flag described above, you should add iburst to the server line on the clients. This will cause them to sync more quickly to the server.

However, you can't expect your server setup to work well, because you have no external reference clock, and you are forcing the server's local clock to a high stratum. You need to have a path to a stratum 1 reference clock, either locally on your LAN or via the Internet.

In addition, if you lose power on both the clients and the server at the same time, you can expect all of them to jump (see System time is off by up to hundreds of milliseconds despite NTP sync before boot for an example) slightly differently, and you could end up with the server jumping backwards while the clients jump forwards, meaning that when the clients sync they could see a large (in NTP terms) backwards jump. This might be larger if your server takes longer to boot than your clients do (not an uncommon scenario).

You really can't get away from the requirement to have a stratum 1 reference clock somewhere. If time is that important to you, best to invest in a low-power GPS-synced device like a BeagleBone, Raspberry Pi, or LeoNTP, all of which can run for many hours on a small-ish UPS.

6
  • Thanks for your answer. Can I force the local clock to stratum 1? – Sap Feb 23 at 10:52
  • How could server jump backwards? – R.. GitHub STOP HELPING ICE Feb 23 at 20:13
  • @Sap, you can force the local clock to stratum 1 by just changing the fudge line in your configuration. But it won't solve your problem, because the local clock is the thing you're trying to discipline by using NTP. And because local clocks vary in quality, there's no guarantee that the client NTP installations will be able to track it meaningfully. – Paul Gear Feb 23 at 21:18
  • 1
    @R..GitHubSTOPHELPINGICE per the link I included above, just rebooting a machine can cause offsets of hundreds of milliseconds, because the resolution of CMOS clocks can be lower than that of the running system timer. – Paul Gear Feb 23 at 21:20
  • 2
    @PaulGear what Sap is doing is a documented and recommended ntp usecase — if you don't have an external reference, you can at least keep a herd in sync. Plus, you can discipline the server's clock using "offline" methods like adjtimex -w. But you keep the local stratum high so that an external reference will be preferred if available. – hobbs Feb 24 at 6:05
0

What you are trying to do is impossible. Two clocks are synchronized if, and only if, the rate at which the two clocks flow has been equalized. Otherwise, they are not synchronized. There is no instantaneous way to observe the rate at which a clock flows or compare the rates at which two clocks flow.

Given the time resolution of each clock, the communication delay between them, the jitter in that delay, the maximum asymmetry of that delay, and the required accuracy of the clock synchronization, a minimum time to accomplish the synchronization can be determined.

It's quite likely to be on the same order of magnitude of whatever you're getting if you use appropriate ntp settings (such as burst or iburst).

1
  • 4
    I believe OP's use of "sync" probably actually means "set the client time to that of the server, even if not perfectly accurate, because a 1-second offset is better than the client thinking we're in 1970 or whatever default date". – jcaron Feb 24 at 9:32
-1

You can synchronize once using ntpdate before starting ntpd.

If you are running Debian, the ntpdate package already contains the necessary infrastructure to hook into dhclient; the assumption appears to be that devices without an RTC likely do not have a fixed IP address either.

1
  • Per the first answer above, ntpdate is deprecated, and unnecessary if the -g flag is used on ntpd. – Paul Gear Feb 23 at 21:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.