Re: [chrony-users] Unreachable sources only updates NTPSynchronized on service start

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ]


Hi Jordan,

after looking in the source code [1] of systemd-timedated (provider of org.freedesktop.timedate1 DBUS interface), you can see how "NTPSynchronized" is determined.

Where timex.maxerror is some worst case estimation of error of current time. It is automatically incremented by the kernel and it tooks 8.89 hours to go from 0 to threshold of timedated. You can see direct value just by calling "adjtimex -p" and the threshold of timedated is 16000000. This value comes from linux kernel and it is NTP_PHASE_LIMIT [2]
This value is incremented every second by 500 by the linux kernel itself [3]. This is fixed increment of worst case value.
So it is badly named property. It does not mean, that your NTP client see some upstream server, but it means, that maximum estimated error of system time is not grater then some fixed value.

Question is if Chrony touches somehow these values even if it is not synchronized. I don't know this.
If chrony does not touch any kernel time adjustment interfaces, it can take hours for this dbus property to go to false state.

Best regards,
Jan Breuer

[1] https://github.com/systemd/systemd/blob/a4f4a4e44100025cfbe01b042db386e0e933c627/src/basic/time-util.c#L1190
[2] https://elixir.bootlin.com/linux/v5.5/source/include/linux/timex.h#L132
[3] https://elixir.bootlin.com/linux/v4.8/source/kernel/time/ntp.c#L456

po 16. 3. 2020 v 23:36 odesílatel Jordan Gibbens <jgibbens@xxxxxxxxxxxxxxxxxxxxxx> napsal:
Hi,

]# cat /etc/redhat-release
CentOS Linux release 8.1.1911 (Core)

]# uname -r
4.18.0-147.3.1.el8_1.x86_64

]# rpm -qa | grep chrony
chrony-3.5-1.el8.x86_64

I've been working with dbus and org.freedesktop.timedate1. If I purposefully stop my upstream NTP server that my chrony client is synchronizing to, the NTPSynchronized property never seems to get updated to reflect this.

]# chronyc sources
210 Number of sources = 1
MS Name/IP address         Stratum Poll Reach LastRx Last sample              
===============================================================================
^? head.cluster                  3   6     0   636    -29us[  +95ns] +/- 8964us
So the single NTP source is clearly unreachable in this scenario. Yet, I will still see NTPSynchronized in DBUS.

# gdbus introspect --system --dest org.freedesktop.timedate1 --object-path /org/freedesktop/timedate1 | grep NTPSynchronized
      readonly b NTPSynchronized = true;


Timedatectl shows the same.
]# timedatectl 
...
System clock synchronized: yes
NTP service: active


And within chrony, it doesn't update leap status. Or show the server as down in the activity report.

]# chronyc tracking | grep ^Leap
Leap status     : Normal

]# chronyc activity
200 OK
1 sources online
0 sources offline
0 sources doing burst (return to online)
0 sources doing burst (return to offline)
0 sources with unknown address

This behavior seems indefinite, until I restart the client side chronyd service.
]# systemctl restart chronyd

]# gdbus introspect --system --dest org.freedesktop.timedate1 --object-path /org/freedesktop/timedate1 | grep NTPSynchronized
      readonly b NTPSynchronized = false;

]# chronyc tracking | grep ^Leap
Leap status     : Not synchronised

]# chronyc activity
200 OK
1 sources online
0 sources offline

]# chronyc sources
210 Number of sources = 1
MS Name/IP address         Stratum Poll Reach LastRx Last sample              
===============================================================================
^? head.cluster                  0   8     0     -     +0ns[   +0ns] +/-    0ns

If I bring the NTP source online, then restart the chronyd client, it will properly update to show not synchronized, then eventually synchronized. The sync state appears to only get updated during the chronyd service startup sequence though.
I really liked the idea of being able to easily show the NTP synchronization status, and this is already done in the Cockpit GUI 'system' tab. Cockpit appears to use the same DBUS value though, because it is not updating properly either. 

If there is a configuration setting to force chronyd to update at intervals, without restarting the service, please let me know. I looked through all of the config options but nothing stood out.


Thank you,

Jordan Gibbens
Systems Engineer
Advanced Clustering Technologies, Inc,




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/