You are not logged in.
On some systems I noticed that "System clock synchronized:" says "no".
While:
1. NTP service: active
2. Journal says: systemd-timesyncd[48936]: Initial clock synchronization to Fri 2024-01-19 15:16:38.615313 CET. (about 28 hours ago)
I know I can fix this by restarting systemd-timesyncd. Though I would like to know what is causing this "System clock synchronized: no".
Regression:
1. Manually setting the hardware clock
hwclock -wv --update-drift
hwclock from util-linux 2.39.3
System Time: 1705773366.323721
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1705773270 seconds after 1969
Last calibration done at 1705773270 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2024/01/20 17:56:07
Hw clock time : 2024/01/20 17:56:07 = 1705773367 seconds since 1969
Time since last adjustment is 97 seconds
Calculated Hardware Clock drift is 0.000000 seconds
RTC type: 'rtc_cmos'
Using delay: 0.500000 seconds
1705773367.500000 is close enough to 1705773367.500000 (0.000000 < 0.001000)
Set RTC to 1705773367 (1705773367 + 0; refsystime = 1705773367.000000)
Setting Hardware Clock to 17:56:07 = 1705773367 seconds since 1969
ioctl(RTC_SET_TIME) was successful.
Not adjusting drift factor because it has been less than four hours since the last calibration.
New /etc/adjtime data:
0.000000 1705773367 0.000000
1705773367
UTCstill results in "System clock synchronized: no".
Systemd timedated.c source code lists from line 561:
static bool ntp_synced(void) {
struct timex txc = {};
if (adjtimex(&txc) < 0)
return false;
/* Consider the system clock synchronized if the reported maximum error is smaller than the maximum
* value (16 seconds). Ignore the STA_UNSYNC flag as it may have been set to prevent the kernel from
* touching the RTC. */
return txc.maxerror < 16000000;
}It looks like maxerror is below 16 seconds, leaving " if (adjtimex(&txc) < 0)" to be true, or is txc.maxerror > 16s?
Any clue how to view adjtimex.maxerror? (Which package would provide the adjtimex binary?
When it is the case, what might be the "code comment" to describe what "adjtimex(&txc) < 0" is doing?
Offline
adjtimex appears to be a function (not a binary) in the standard c library that interfaces with the linux kernel .
man adjtimex for more info.
(I use ntpd instead of systemd-timesynd so may not be able to help further.)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Again timedatectl reports: "System clock synchronized: no"
Last update is Today according to "timedatectl show-timesync --all"
NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=2, Precision=-24, RootDelay=141.998ms, RootDispersion=23.742ms, Reference=81FA23DE, OriginateTimestamp=Wed 2024-02-14 09:23:31 CET, ReceiveTimestamp=Wed 2024-02-14 09:23:31 CET, TransmitTimestamp=Wed 2024-02-14 09:23:31 CET, DestinationTimestamp=Wed 2024-02-14 09:23:31 CET, Ignored=no, PacketCount=8, Jitter=895.203ms }Last update is 1 week ago according to "systemctl status systemd-timesyncd":
Feb 07 09:23:30 systemd-timesyncd[355]: Initial clock synchronization to Wed 2024-02-07 09:23:30.139579 CET
PS This box had package ntp installed. Which is now removed.
Another *good* system (synchronized: yes) shows this NTPMessage:
NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=2, Precision=-25, RootDelay=4.791ms, RootDispersion=76us, Reference=4F852C92, OriginateTimestamp=Thu 2024-02-15 09:26:25 CET, ReceiveTimestamp=Thu 2024-02-15 09:26:25 CET, TransmitTimestamp=Thu 2024-02-15 09:26:25 CET, DestinationTimestamp=Thu 2024-02-15 09:26:25 CET, Ignored=no, PacketCount=377, Jitter=195us }Let me first match the systemd-timesyncd config of the bad system with the good ntp system. My guess is that "System clock synchronized: no" is related to increased polling:
PollIntervalMinSec=1d
PollIntervalMaxSec=4wLast edited by probackup-nl (2024-02-15 09:45:36)
Offline