0

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
2
  • While ntpd is running, add to your question the output of ntpq -p. Is this a VM, and if so on which hypervisor? Mar 11, 2020 at 14:12
  • Updated to show ntpq -p output. Not running in a VM. Mar 11, 2020 at 14:46

2 Answers 2

3

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.

4
  • Are you sure that 127.127.1.0 serves no purpose? As far as I know this is the reference for the local system clock. This effectively makes ntpd treat local system clock as a time source...
    – vidarlo
    Mar 11, 2020 at 18:13
  • I just want to remove all references to internet servers and only sync to the local machine. Mar 12, 2020 at 7:24
  • 1
    Yes, I am sure 127.127.1.0 aka undisciplined local clock aka LOCL does not work like you think it does, and is not a good idea on a client node whose only reference is a poor oscillator. See edit for citation. I suspect using LOCL with a large offset is causing you problems. Mar 12, 2020 at 14:22
  • 1
    NTP is a means of downloading timestamps from a reference clock. These days usually satellite nav via the Internet, but there is more than one way to do it. Commodity servers have rubbish clocks and no reference, so pointing to itself as a reference is dubious. And unnecessary, any machine running ntpd that at one point contacted a reference clock will have its clock disciplined. Mar 12, 2020 at 14:48
0

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.

2
  • That achieves almost exactly the same thing as following @John Mahowald's advice about ntpd would have achieved. It is generally a better choice to use chronyd on Ubuntu 18.04 and later, because it is in main and receives security support from Ubuntu, but the problem was your configuration, not ntpd itself.
    – Paul Gear
    Mar 15, 2020 at 5:38
  • That's probably true, but I didn't understand from his answer what the correct configuration for ntpd would be. Mar 16, 2020 at 14:57

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.