I guess, we could be seeing:
https://bugs.debian.org/cgi-bin/bugrepor...bug=940840
We are using chrony as time sync daemon instead of the systemd ntp one. And the Debian bug then experiences similar hangs with the sstemd-time-wait-sync service running (which does not work with chronyd):
> 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.
The man page says:
So, any timer that waits until the time is synchronized is on hold. And the apt-daily-upgrade.timer is one of those, I guess.
UPDATE: I don't experience the hangs myself. Could somebody who does check with
```systemctl status systemd-time-wait-sync.service```
to see if this service is somehow enabled on their mobian device?
https://bugs.debian.org/cgi-bin/bugrepor...bug=940840
We are using chrony as time sync daemon instead of the systemd ntp one. And the Debian bug then experiences similar hangs with the sstemd-time-wait-sync service running (which does not work with chronyd):
> 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.
The man page says:
Code:
> 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.So, any timer that waits until the time is synchronized is on hold. And the apt-daily-upgrade.timer is one of those, I guess.
UPDATE: I don't experience the hangs myself. Could somebody who does check with
```systemctl status systemd-time-wait-sync.service```
to see if this service is somehow enabled on their mobian device?
