Am 26.07.20 um 23:12 schrieb Francesco Poli: > On Sun, 26 Jul 2020 22:48:18 +0200 Michael Biebl wrote: > >> Am 26.07.20 um 22:43 schrieb Francesco Poli: >>> On Sun, 26 Jul 2020 22:22:55 +0200 Michael Biebl wrote: >>> >>> [...] >>>> Afaics, the problem is, that your service does not properly handle the >>>> case, when the network is not available. >>> >>> It does, that's the reason why the operation is attempted hourly. >> >> The bug report was about apt-listbugs throwing an error if network is >> not available. > > We can argue that the service should be more silent in case of network > errors, or maybe it's OK that it throws an error. > But that's not the point. > > The point is that the timer triggers during wake-up, while it should > behave as it does during a boot (wait for at least 5 min and then > trigger hourly, with a random delay). > >> >>>> Even if systemd would delay timer events after a resume: How long should >>>> it wait? 30s, 1min? How would that robustly solve your problem? How >>>> would that guarantee that after 1min network is available? >>> >>> It should wait at least 5 min (as specified in OnActiveSec=5min), >> >> That is not what OnActiveSec=5min means > > Then I think the systemd.timer(5) man page should be clarified. > It states: > > │OnActiveSec= │ Defines a timer relative │ > │ │ to the moment the timer │ > │ │ unit itself is activated. │ > > I thought this meant that an OnActiveSec=5min timer triggers 5 min > after being activated. > And the timer is either inactive during sleep (then it's activated > again during wake-up and it should wait 5 min before triggering) or > considered as active during sleep (but then the OnActiveSec should have > already happened 5 min after boot and should not happen again during > wake-up).
The timer is activated during boot and then stays active (unless you stop it with systemctl stop foo.timer). You can query the state with systemctl status. A system sleep does not deactivate a timer.
signature.asc
Description: OpenPGP digital signature
