| Re: [chrony-users] Unreachable sources only updates NTPSynchronized on service start |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Tue, 17 Mar 2020, Jan Breuer wrote:
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.
One of the whole purposes of any ntp system is to discipline not only the
time, but also the rate of the clock. Thus even if no external sources are
available, the time ticked off by the clock should be 1 sec par sec, and its
time should have started at UTC. If that were correct then the clock should
tick off UTC-- be synchronized to UTC-- forever more. Of course it is not
right, since the measurements have uncertainties, and the clock rate can vary
due especially to temperature fluctuations. meaning that the deviation from
UTC will grow with time. Now, one can estimate the undertainty in the time by
having an estimate in the uncertainty of the rate and of the initial time.
When do you say that estimated uncertainty is too big. If both were zero, then
the clock could tick away on its own for years and still determine UTC. For
example, the atomic clocks at the National labs define UTC because that
uncertainty remains very small for centuries even if the clock is running on
its own. They do have a number of clocks, so average, and a number of
international clocks, and average, but that only buys you 1/sqrt(N) where N is
the number of clocks. You would hardly want chrony to report that the clock
was not synchronized to UTC immediately it cannot reach one of its servers,
because you used the design of ntp to make sure that the clock does tick one
second per second, and its time is right. It is synchronized to UTC ( which is
the only measure that makes any sense) for a long time thereafter. How long
will depend on the uncertainty in the measured values of the rate, of the time
offset, and the wandering due to outside influences of the rate. All of those
aspects are estimated by chrony while it is running. Can things change? Of
course. Someone could run hwclock and purposely change the time (for a test
let us say) , and the time it shows
may well be off by a lot. But estimates cannot take something like that into
account. So there is a difference between "I am unsynchronized to UTC" and "I
have no servers to compare with".
By looking in chronyc at the sources command, one can see whether chrony
thinks it has any servers to try to compare itself with. But that is different
from "do you think you are synchronized with UTC?"
Best regards,
Jan Breuer
[1] https://github.com/systemd/systemd/blob/a4f4a4e44100025cfbe01b042db386e0e933c627/src/bas
ic/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 upda
ted 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 restarti
ng the service, please let me know. I looked through all of the config options but nothing st
ood out.
Thank you,
Jordan Gibbens
Systems Engineer
Advanced Clustering Technologies, Inc,