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
Sap
  • 43
  • 1
  • 8
  • 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 '21 at 00:02
  • what is the package name? apt install swclock doesn't work – Sap Feb 24 '21 at 04:15
  • Ah, I was mistaken about the name, the actual package name is `fake-hwclock`. – Austin Hemmelgarn Feb 24 '21 at 15:57
  • This is not at all accurate – Sap Feb 25 '21 at 16:02

4 Answers4

12

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.

muru
  • 589
  • 8
  • 26
basekat
  • 456
  • 2
  • 5
  • I think this is the same as running `ntpdate` at boot. – Andrew Schulman Feb 23 '21 at 10:09
  • 3
    ntpdate has been deprecated for some time now and it is missing from most modern GNU/Linux distributions. http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate – basekat Feb 23 '21 at 10:12
  • Thanks. Yes, `ntpd -g` seems to be the way to go. – Andrew Schulman Feb 23 '21 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 '21 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 '21 at 10:42
  • service ntp stop ; ntpd - gq ; service ntp start. But this doesn't work – Sap Feb 23 '21 at 10:43
  • The exact syntax is ntpd -g -x -q pool.ntp.org. You are not mentioning which Linux distribution you are using, so not able to tell you how to add a boot script. – basekat Feb 23 '21 at 10:47
  • I am using dietpi on master. Smaller version of raspbian. So the syntax for my case will be ntpd -g -x -q 192.168.0.51 right? – Sap Feb 23 '21 at 10:50
  • Please check the edit. Your suggested command worked in the second attempt. Why didn't it work on the first? – Sap Feb 23 '21 at 11:15
  • Your NTP server is at 192.168.0.51 according to your ntp.conf. So the correct command is ntpd -g -x -q 192.168.0.71 – basekat Feb 23 '21 at 11:20
  • You can do the following test: 1. Set date to date --set "01 Jan 2010 10:00:00" and check if really set to 2010 2. Run ntpd -g -x -q 192.168.0.71 3. Run date and confirm your date is current 4. Start your ntpd: systemctl start ntp or service ntp start – basekat Feb 23 '21 at 11:23
  • Yes sorry. Have mentioned the correct ip in the edit. I have server at both 51 and 71 so sorry for confusion – Sap Feb 23 '21 at 11:23
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/120075/discussion-between-sap-and-basekat). – Sap Feb 23 '21 at 11:29
6

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.

Paul Gear
  • 4,367
  • 19
  • 38
  • Thanks for your answer. Can I force the local clock to stratum 1? – Sap Feb 23 '21 at 10:52
  • How could server jump backwards? – R.. GitHub STOP HELPING ICE Feb 23 '21 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 '21 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 '21 at 21:20
  • 3
    @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 '21 at 06:05
  • @hobbs The local clock driver is documented, but has been deprecated for years. This setup with no external reference clock is definitely not a recommended use case. – Paul Gear Feb 25 '21 at 10:31
-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.

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

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

David Schwartz
  • 31,449
  • 2
  • 55
  • 84
  • 6
    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 '21 at 09:32