Bug#940840: systemctl --no-ask-password restart apt-daily-upgrade.timer hangs indefinetely

[Michael Biebl]

Am 22.09.19 um 14:08 schrieb Marc Haber:
> On Sat, Sep 21, 2019 at 05:05:10PM +0200, Michael Biebl wrote:
>>>   58 systemd-time-wait-sync.service       start running
>>
>> Hm, this service is not enabled by default and I'm guessing it prevents
>> time-sync.target to be reached, blocking all subsequent services.
>>
>> Have you enabled this service manually?
> 
> Not that I am aware of. The link dates back to August 8, the machine
> has been updated and rebooted multiple times since then without
> problems, there were no significant changes to the machine. The system
> logs don't show the service being enabled manually (auth.log should have
> a sudo entry if I did that manally, I never work in a root shell but
> prefix every root command with its own sudo call for exactly this
> reason).


All I can say for sure is that the Debian systemd package never
explicitly enabled this service. Looking at codesearch.debian.net I
don't find any other package referencing that service either.

Since you are adamant that you haven't enabled the service manually (at
least not explicitly), I wonder if you used something like "systemctl
preset" in the past and it was enabled because of that (afaics
systemd-time-wait-sync.service is not explicitly disabled).



>> What happens if you disable this service?
> 
> Then, everything is fine.

Ok, good. So we have isolated the root cause then.

>> If you read man 8 systemd-time-wait-sync.service
>>
>>>         systemd-time-wait-sync is a system service that delays the start of units that depend on time-sync.target
>>>         until the system time has been synchronized with an accurate time source by systemd-timesyncd.service.
>>>
>>>         systemd-timesyncd.service notifies on successful synchronization.  systemd-time-wait-sync also tries to
>>>         detect when the kernel marks the time as synchronized, but this detection is not reliable and is intended
>>>         only as a fallback for other servies that can be used to synchronize time (e.g., ntpd, chronyd).
>>>
>>
>>
>> Maybe you should only use systemd-time-wait-sync.service in combination
>> with systemd-timesyncd. The man page explicitly warns that using it
>> combination with other NTP clients can be unreliable.
> 
> Yes, but I interpret this part of the man page as an information that I
> might end up with a system that doesn't think that it's synchronized and
> otherwise runs fine. It is is really meant to warn that the system might
> be inhibited from finishing booting with unrelated systemctl calls
> blocking indefinetely and upgrades stalling, this warning should be WAY
> more explicit.

For me the man page is pretty clear, fwiw.
If you have ideas for how to improve the man page, please consider
filing an upsteam bug report.

> Or, preferably, the code should be made more robust so that using a
> non-systemd time server doesn't endanger the system.

Unfortunately, I have no idea how to "make it more robust".
This needs someone more clever then me to come up with ideas how the
heuristics for non-systemd-timesyncd case can be improved.

It could be debated whether it makes sense to use
TimeoutStartSec=infinity or if the service should have a reasonably
chosen timeout.
This would need discussion with upstream though.

> I do have only two decades of Unix experience and I am not familiar with
> the concept of time synchronization of the kernel. When does a regular
> ntp server consider itself synced, and why did we live for so long
> without the init systemd being informed about that state?

I guess the rationale for systemd-time-wait-sync.service is the same as
for NetworkManager-wait-online.service or
systemd-networkd-wait-online.service.
The simple fact that those daemons have started does not mean that you
have network access (or your system clock is synchronized).

You can probably find out more about it at the initial PR
https://github.com/systemd/systemd/pull/8494


> A new title for this bug report could probably be "using
> systemd-time-wait-sync with non-systemd time sync services such as ntp
> might lead to weird behavior and incomplete boots".

does
"systemd-time-wait-sync blocks indefinitely with alternative NTP
implementations, stalling boot and units depending on time-sync.target"
sound ok?

In any case, if you want the documentation improved or the behaviour of
the service changed, you should best file this upstream. This doesn't
look like a downstream, Debian specific issue.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- 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/20190922/fc5f1a8d/attachment-0001.sig>