Control: reassign -1 systemd
On Fri, 17 Jul 2020 18:11:08 +0200 Francesco Poli wrote: > On Fri, 17 Jul 2020 01:46:06 +0200 Michael Biebl wrote: [...] > > network-online.target is only relevant during boot, once the target has > > been reached, it will stay up, it is not dynamic. > > I.e. you can't use that to delay the execution of a service after > > suspend-resume. [...] > > > > Reassigning accordingly. > > Hello Michael, thanks for your prompt reply. > > OK, I acknowledge that the network-online.target check is not reliable > enough, I was aware of that. > > But anyway, let's pretend the network check is completely absent. > > Why is the service triggered *immediately* during wake-up? > It should wait at least 5 min (OnActiveSec=5min) or be triggered on the > basis of the calendar scheduling (OnCalendar=*-*-* *:20) with a random > delay (RandomizedDelaySec=20min). > > And it should *not* catch up with missed execution chances (since the > timer is *not* a Persistent=true one). > > What am I missing here? Dear Michael, I am still convinced that this is a bug in systemd, as explained above. I am reassigning back the bug report to package systemd. If you think that the timer unit can be modified so that it behaves as intended, please tell me how I should modify it. Just to recap the intended behavior: the timer should trigger the corresponding oneshot service 5 min after the timer activation and then hourly, with a random delay between 0 and 20 min, *without* catching up with missed execution chances, and it should *not* trigger the service immediately during a wake-up from sleep. Otherwise, please investigate/fix the issue and/or forward my bug report upstream, as appropriate. Thanks for your time and understanding. Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpeq76KhLPEk.pgp
Description: PGP signature