2

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

Improve this question
2
  • 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...) Commented Jan 18, 2022 at 9:33
  • Thank you - I have added some new tests and requested outputs. I have also found this answer but adding tos maxdist 30 unfortunately does not help. Commented Jan 18, 2022 at 10:36

1 Answer 1

Reset to default
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

Improve this answer
4
  • I will add the info above. Commented Jan 18, 2022 at 12:54
  • OK, thanks, the command works fine now. The only 2 questions I have still are: 1. why is the offset constantly rising and not going towards zero (it is now around 420 ms)?, 2. why is there no + or * sign next to the local address in ntpq -np command? (sorry for asking so many questions but without the proper time sync I will get the wrong results) Commented Jan 18, 2022 at 13:49
  • @ksonofre I've updated the question once more with information on handling a worsening time slew Commented Jan 18, 2022 at 14:27
  • OK, I did the steps and restored the ntp service. I have accepted your answer as there is everything explained. I guess this is solved - in any case what I can only do is to monitor the time sync and see whether there would be any drift. Thank you once again for your help! Commented Jan 18, 2022 at 14:56

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.