Bug#964444: systemd-timesyncd: time synchronization suddenly stopped working
Michael Biebl
biebl at debian.org
Wed Jul 8 20:16:43 BST 2020
Am 08.07.20 um 12:35 schrieb Vincent Lefevre:
> On 2020-07-08 01:49:16 +0200, Vincent Lefevre wrote:
>> On 2020-07-07 23:59:06 +0200, Michael Biebl wrote:
>>> Am 07.07.20 um 12:58 schrieb Vincent Lefevre:
>>>> Package: systemd-timesyncd
>>>> Version: 245.6-1
>>>> Severity: important
>>>>
>>>> systemd-timesyncd no longer seems to work. I couldn't find any
>>>> reason in the logs. Now there's a 5-second delta!
>>>>
>>>> zira:~> timedatectl timesync-status
>>>> Server: (null) (3.debian.pool.ntp.org)
>>>> Poll interval: 34min 8s (min: 32s; max 34min 8s)
>>>> Leap: normal
>>>> Version: 4
>>>> Stratum: 2
>>>> Reference: 596DFB17
>>>> Precision: 1us (-24)
>>>> Root distance: 40.580ms (max: 5s)
>>>> Offset: -1.087495s
>>>
>>> For smaller offset likes this one, timesyncd will adjust the time gradually.
>>> I don't see anything in the logs which would show that timesyncd is not
>>> working.
>>
>> I don't know what this offset means, but this does not explain the
>> 5-second difference with other machines.
>
> Note that after a reboot yesterday, I can't currently reproduce
> the issue.
>
> There's something suspicious in the "timedatectl timesync-status"
> output above:
>
>>>> Server: (null) (3.debian.pool.ntp.org)
>
> Currerntly I get:
>
> Server: 193.52.136.2 (0.debian.pool.ntp.org)
>
> So, why "(null)" above instead of the IP address?
Dunno, maybe it's a result of the failure to resolve the names via DNS.
But this does look fishy indeed.
> It seems that there was a temporary DNS resolution failure, and
> after that, systemd-timesyncd stopped doing anything (I think that
> the offset was the old difference, but the difference increased
> over the hours).
>
> Note also that "systemctl status systemd-timesyncd.service" was
> outputting
It would have been interesting to see, if timesyncd eventually would
have picked up another NTP server and started to gradually adjust the
time again.
Not sure what to do about this bug report now.
Can you trigger the issue somehow which would allow to run further
diagnostics (e.g. running with Environment=SYSTEM_LOG_LEVEL=debug)?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20200708/12edfac9/attachment.sig>
More information about the Pkg-systemd-maintainers
mailing list