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

[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).

> What happens if you disable this service?

Then, everything is fine.

> 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.

Or, preferably, the code should be made more robust so that using a
non-systemd time server doesn't endanger the system. This might be
misunderstood as another systemd conspiration to drive ntp and chrony
from the systems in favor of systemd-timesyncd.

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?

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".

> > Now, speaking with my ippl maintainer hat on, what was the information
> > that made you take a closer look at ippl?
> 
> It was in the list of queued jobs and a quick apt-file search
> ippl.service did not reveal anything, so I was wondering if this was
> maybe a 3rd party service file.

Thanks. Good news is that I don't need to change anything there (the
package is dying away anyway, upstream hasn't been active in fifteen
years).

Thanks for helping with the issue at hand, I appreciate your patience
and speed of replies.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421