Keeping Ubuntu clock in sync with another machine using NTP

Question

Goal

To synchronize the clock of machine A (Ubuntu 18.04) with the clock of machine B (Ubuntu 16.04 on local network running an NTP server - time is approx. 10 minutes ahead of real-world time).

My research

I am new to NTP and slightly confused about the available packages and commands: ntpd, ntpq, timesyncd, timedatectl etc. Apparently some of these interact and others conflict. Any help clearing that up would be appreciated.

What I have tried

On machine A:

$ sudo apt-get install ntp

ntp.conf:

server 192.168.12.20 # NTP server (machine B)
server 127.127.1.0
fudge 127.127.1.0 stratum 10

driftfile /var/lib/ntp/ntp.drift

leapfile /usr/share/zoneinfo/leap-seconds.list

Then running:

$ sudo service ntp stop
$ sudo ntpd -gq
11 Mar 14:35:50 ntpd[11344]: ntpd 4.2.8p10@1.3728-o (1): Starting
11 Mar 14:35:50 ntpd[11344]: Command line: ntpd -gq
11 Mar 14:35:50 ntpd[11344]: proto: precision = 0.128 usec (-23)
11 Mar 14:35:50 ntpd[11344]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
11 Mar 14:35:50 ntpd[11344]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): loaded, expire=2019-12-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
11 Mar 14:35:50 ntpd[11344]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): expired less than 75 days ago
11 Mar 14:35:50 ntpd[11344]: Listen and drop on 0 v6wildcard [::]:123
11 Mar 14:35:50 ntpd[11344]: Listen and drop on 1 v4wildcard 0.0.0.0:123
11 Mar 14:35:50 ntpd[11344]: Listen normally on 2 lo 127.0.0.1:123
11 Mar 14:35:50 ntpd[11344]: Listen normally on 3 eth0 192.168.12.193:123
11 Mar 14:35:50 ntpd[11344]: Listen normally on 4 wlan0 10.1.11.171:123
11 Mar 14:35:50 ntpd[11344]: Listen normally on 5 lo [::1]:123
11 Mar 14:35:50 ntpd[11344]: Listen normally on 6 eth0 [fd06:b21a:9c69::242]:123
11 Mar 14:35:50 ntpd[11344]: Listen normally on 7 eth0 [fd06:b21a:9c69:0:3411:70bb:5786:e9f9]:123
11 Mar 14:35:50 ntpd[11344]: Listen normally on 8 eth0 [fd06:b21a:9c69:0:f474:e414:7210:dc9e]:123
11 Mar 14:35:50 ntpd[11344]: Listen normally on 9 eth0 [fe80::37ed:4c5:7941:3e6%3]:123
11 Mar 14:35:50 ntpd[11344]: Listen normally on 10 wlan0 [fe80::2e44:748b:5ae0:f2dd%7]:123
11 Mar 14:35:50 ntpd[11344]: Listening on routing socket on fd #27 for interface updates
11 Mar 14:46:14 ntpd[11344]: ntpd: time set +617.018832 s
ntpd: time set +617.018832s

At this point, the date is correctly set to the date of machine A:

$ date
Wed Mar 11 14:46:33 CET 2020

However, after starting the service again...

$ sudo service ntp start

A few seconds later, the clock is reverted back:

$ date
Wed Mar 11 14:36:41 CET 2020

Peers (showing an unexpected 188. IP):

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*_gateway        188.67.52.171    4 u  131  128  377   10.171  -11.526  16.139

Answer 1

That offset means you are less than 12 ms different from the remote. Your NTP server does not provide the time you wanted, or you are syncing to something other than you intended.

Refid is the code for what the peer is using as a reference. An IP address means a NTP server. An IP you don't own may be a public NTP service, from the NTP Pool or otherwise. Review NTP configuration on host 192.168.12.20 and all NTP servers.

If you intend to maintain a 10 minute offset from "real-world" time, you can't do that and also sync from Internet time. Instead, fake the time applications get, with a custom time zone or shims like libfaketime.

---

127.127.1.0 serves no purpose in modern ntpd. Definitely not in client configurations that do not serve time. Remove both lines.

After ntpd establishes drift, even if there are no servers it will continue to discipline the clock. Adding undisciplined local clock asserts that the local clock is good for serving time, which 1) you aren't serving time from a client host 2) if 10 minute offset from the time you want is not accurate. Think of this feature as more intended for NTP appliances plugged into reference clocks. Not commodity servers.

Citation from NTP support wiki regarding undisciplined local clock:

The Undisciplined Local Clock should generally no longer be used. Users of ntp-4.2.2 and later should consider OrphanMode as a means of keeping an isolated group of servers synchronized. The Undisciplined Local Clock is not a back-up for leaf-node (i.e. client only) ntpd instance.

---

Only one NTP server cannot be corrected for falseticker errors. Ideally, deploy at least 4 and use all of them on all clients.

---

Time sync daemons do conflict with each other. Two things fighting to set the clock differently is not good. Install and use only one of chrony, ntpd, systemd-timesyncd. Some systemd units (at least Red Hat's) guard against running both, but don't rely on this.

Answer 2

I ended up using ntpdate and chrony instead.

sudo apt-get install -y ntpdate chrony

First I run an immediate update using ntpdate:

sudo ntpdate 192.168.12.20

Then I configure the server in /etc/chrony/chrony.conf

#pool ntp.ubuntu.com        iburst maxsources 4
#pool 0.ubuntu.pool.ntp.org iburst maxsources 1
#pool 1.ubuntu.pool.ntp.org iburst maxsources 1
#pool 2.ubuntu.pool.ntp.org iburst maxsources 2

server 192.168.12.20 minpoll 0 maxpoll 5 maxdelay .05

and start the chrony daemon:

/etc/init.d/chrony start

It seems to work well, running with less than 1 ms offset.