How do I tell if chronyd is actually self-synchronising correctly?

Question

I'm working on some devices where I want them to self-synchronise while their network connection is down (i.e. use chrony's calculations of drift rates to compensate for system clock drift), and then sync normally when remote connectivity is available.

Unfortunately, chronyd fails to bind to the NTP listening port, and actively attempts to sends packets to the NTP pseudo-server address, and I'm having trouble working out if that is expected behaviour or not.

The standard chrony.conf settings recommended for self-synchronisation are:

server 127.127.1.0 # Self-synchronise
allow 127.0.0.0/8  # NTP server for the local system, not just a client
local stratum 10   # Serve low quality time even when the remote link is down

However, when I run chrony sources with that configuration, it claims that it hasn't synchronised with the pseudo-time server for localhost:

chronyc sources
210 Number of sources = 1
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^? 127.127.1.0                   0   7     0     -     +0ns[   +0ns] +/-    0ns

Even though chrony tracking does seem to suggest that it is working as expected:

$ chronyc tracking
Reference ID    : 7F7F0101 ()
Stratum         : 10
Ref time (UTC)  : Mon Jun 04 08:27:11 2018
System time     : 0.000000007 seconds fast of NTP time
Last offset     : +3.297439098 seconds
RMS offset      : 3.297439098 seconds
Frequency       : 466.833 ppm slow
Residual freq   : +0.000 ppm
Skew            : 0.000 ppm
Root delay      : 0.000000000 seconds
Root dispersion : 0.000000000 seconds
Update interval : 0.0 seconds
Leap status     : Normal

No matter how I adjust the allow settings in the config file I cannot get chronyd to show up as actually listening on UDP port 123 on any of the machine's interfaces, whereas I'd expect to see that in netstat -ulnp if I've successfully set it up to act as a time server.

Even more strangely, if I run chronyd under strace -f, I see it attempting to actually send messages to 127.127.1.0, even though it should know that that's the pseudo-address for local time synchronisation.

As things stand, I have very little confidence that chrony is actually compensating for clock drift while the remote connection is down, since it's tricky to provoke a situation where it actually does need to automatically correct for clock drift.

So my actual question is: does anyone know how to tell if chrony is correctly set up for self-synchronisation when offline? Or do I just need to deploy this as I currently have it configured, and then wait and see whether or not we have problems with clocks drifting while devices are disconnected from their backend management server?

Solution 1

I managed to find the problem: there was an extraneous port 0 line in the existing config file I started with, so the allow line wasn't setting up the local time server correctly. Delete that line and everything started working the way I expected it to.

This means the answer to my original question is "Do what you did":

• Check that sudo netstat -ulnp shows chronyd listening on the NTP port (UDP 123)
• Check that sudo chronyc sources shows 127.127.1.0 as an available source

The fact those checks failed for me was an accurate reflection of the fact that the port 0 setting wasn't correct.

Solution 2

You might want to consider the Information at
https://chrony.tuxfamily.org/doc/3.3/chrony.conf.html
according to what it says at Isolated Networks.

There are several options to help configure a pseodo time. Especially this parragraph might be interesting for you:

If there is no suitable computer to be designated as the master, or there is a requirement to keep the clients synchronised even when it fails, the orphan option of the local directive enables a special mode where the master is selected from multiple computers automatically. They all need to use the same local configuration and poll one another. The server with the smallest reference ID (which is based on its IP address) will take the role of the master and others will be synchronised to it. When it fails, the server with the second smallest reference ID will take over and so on.

But as I understand from the documentation several servers are required.

About you server appearing synchronized perhaps this scenario might apply to you: https://chrony.tuxfamily.org/faq.html#_computer_is_not_synchronising

Check the Reach value printed by the chronyc's sources command. If it’s zero, it means chronyd did not get any valid responses from the NTP server you are trying to use.

Also the Manual explains about the local Directive

local [option]…​
The local directive enables a local reference mode, which allows chronyd operating as an NTP server to appear synchronised to real time (from the viewpoint of clients polling it), even when it was never synchronised or the last update of the clock happened a long time ago.

So it might give a sinchronization time although it's not true

Comments

[ncoghlan]

Aye, I've been going over those docs quite a bit. I actually have two different scenarios to handle (1 with a single intermittently connected system, 1 where the intermittently connected system has another dozen servers on the isolated LAN), and I think I managed to confuse myself into believing I needed the master server to be a client of itself in order for chrony to manage local clock drift.

[ncoghlan]

Ironically, after finally getting this working and looking at the impact it has by setting log tracking in the config file, I'm pretty sure I don't actually want to run chronyd in this mode. Still, nice to have got the configuration to the point where it's working the way I thought it should be :)

[Bodo Hugo Barwich]

In the case of 1 connected Master and x isolated Slave Servers you just need to allow the Slaves to synchronize with the Master but the Master does not need to synchronize in Offline Mode. In case of a Network Outage for the Master it would just stop synchronizing untill the Network is available again notifying chronyd[538]: Can't synchronise: no selectable sources. The Master retakes its activity as soon as it is connected again.