Sync ntp immediately at boot with undiciplined clock
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 [email protected] (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 [email protected] (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
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.
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.