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