Automatic time synchronization: `ntpdate` works but `chrony` does not

Question

I have a problem with time synchronization of my Linux server. Both this machine and the NTP server are located in a (smaller) university data center hence the local address.

What is strange is that the ntpdate command works:

ntpdate -u 172.16.0.25

with the output:

17 Jan 15:03:53 ntpdate[25993]: adjust time server 172.16.0.25 offset 0.036043 sec

However, the chronyd does not (it simply hangs):

chronyd -q 'server 172.16.0.25 iburst'

I was trying all things to set the automatic time sync using ntpd but did not succeed and finally resorted to chrony but still cannot figure it out.

Here's what happened with ntpd. I installed ntpdate using the instructions on https://vitux.com/how-to-setup-ntp-server-and-client-on-debian-10. The conf file has a command

server 172.16.0.25 prefer iburst

while the system status ntp reports

Jan 18 10:26:11 akulab1 ntpd[26957]: kernel reports active service TIME_ERROR: 0x41: Clock Unsynchronized

The ntpq -p has the following output

HKS-SRV01.unica .LOCL.           1 u    9   64   15    0.557  2275.65   9.515 – 

However, after a while the service reports

Jan 18 10:31:01 akulab1 ntpd[26957]: ntpd exiting on signal 15 (Terminated)

as NTP sync did not succeed. But, the ntpdate -u 172.16.0.25 reports synchronization: 18 Jan 10:33:13 ntpdate[26990]: step time server 172.16.0.25 offset 2.282101 sec (if I am not mistaken...) – ksonofre 7 mins ago

Here is my /etc/ntp.conf file:

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 172.16.0.25 prefer iburst
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited
restrict 127.0.0.1
restrict ::1
restrict source notrap nomodify noquery

I have restarted the NTP service again: systemctl restart ntp

The output of the ntpq -np is the following:

root@akulab1:~# ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 172.16.0.25     .LOCL.           1 u   63   64  377    0.518  104.685  14.815

However, the service (systemctl status ntp) still reports:

Jan 18 11:04:10 akulab1 ntpd[27089]: kernel reports TIME_ERROR: 0x4041: Clock Unsynchronized

And, after I set the timedatectl set-ntp true the NTP service simply shuts down, i.e. reports inactive.

I have restarted the ntpd service again and it is active. Also, I have waited more than an hour for a sync and it never got it (there is no star or plus in front of the server address) - here is the output of ntpq -np:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 172.16.0.25     .LOCL.           1 u   61   64  377    0.588  269.847  14.797

Also, this is the output of ntpdate -qu command:

18 Jan 13:57:44 ntpdate[1975]: no servers can be used, exiting

OK, this above command was not complete so with the ntpdate -qu 172.16.0.25 there is a following output:

server 172.16.0.25, stratum 1, offset 0.435131, delay 0.02621
18 Jan 14:51:56 ntpdate[6951]: adjust time server 172.16.0.25 offset 0.435131 sec

And the ntpq -np gives the following:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 172.16.0.25     .LOCL.           1 u   17   64  377    0.554  436.092  14.279

---

The solution is given in an accepted answer below. I assume that the time sync is working now, but I will nevertheless track the clock drift and make an update of my question if it does not synchronize properly.

---

The final solution is posted in this post: ntp server reachable but never select/set the time

Answer 1

Your clock was almost certainly synchronised. The "Clock unsynchronised" is misleading as it only applies while ntpd is waiting to synchronise with its upstream sources.

There are two routes for NTP: the systemd one (managed through timedatectl) and the ntpd one (monitored through ntpq). I'd suggest you leave timedatectl alone.

systemctl start ntp    # don't restart ntpd if it was already running
watch -n1 ntpq -pn     # while :; do clear; date; echo; ntpq -pn; sleep 1; done

You should see your upstream listed, initially with a reachability of 0, increasing strangely to 377 over a period of about five minutes. It should have a + in the left-hand column to show that it's a candidate for time synchronisation, changing to * when it's finally been accepted.

The delay and offset fields are measured in milliseconds. Across your university WAN I'd expect the delay to be low, and 500ns is very good. Offset should tend towards zero over hours and days.

Here's an extract of a steady example from a server of mine. 37ms delay feels reasonable for an xDSL line. The offset from the upstread server is surprisingly low, and the jitter is bearable:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*51.155.16.62    .GPS.            1 u   10   64  377   37.420    0.524  34.067

You can view the synchronisation status with NTP's sysinfo command. Here, we are looking at the first line of output; notice sync_ntp, the presence of which confirms that my client is synchronised with an upstream server:

ntpq -c sysinfo | head -n1
associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer,

A final caution. It's essential that you don't change the local system's time while you have a service trying to keep the time correct. The service will notice the time change and will assume the local clock cannot keep good time. It will then try really hard to correct the clock, possibly ending up with it slewing so badly the local clock can no longer synchronise with an upstream. See How often (and when) does NTPD update the time?

If this happens you will either need to wait (a long time) for NTP to notice or fix it yourself. You can fix it yourself by disabling and stopping ntpd (systemctl stop ntp; systemctl disable ntp), then deleting /etc/adjtime and immediately rebooting. (You may need to do this delete/reboot step twice.) Then use ntpdate -u 51.155.16.62 to set the time correctly and reboot once more. Finally, re-enable NTP (systemctl enable ntp; systemctl start ntp).

If you have ntpdate installed you can query the upstream time difference against a nominated server with ntpdate -qu {server}. DO NOT try to set the time while ntpd is running.

Additional references

• When will ntp update the time
• How to update date/time without shutting down the NTP daemon?
• How to know during system start when system time becomes correct from NTP
• System disregards Daylight Saving Time