timer: Import defaults from systemd-sysupdate.timer #956
Conversation
Inspired by coreos/rpm-ostree@db108a3 Signed-off-by: Colin Walters <[email protected]>
| # This is copied from systemd-sysupdate.timer; it's just an arbitrary | ||
| # starting point. | ||
| # | ||
| # Trigger the update 1 hour after boot, and then – on average – every 6h, but |
There was a problem hiding this comment.
every 6h should be every 4h here? If it's randomly picking between 2h and 6h. Maybe I am misunderstanding something though.
There was a problem hiding this comment.
The comment here is mostly copied verbatim, so any errors are in the original. But it is good to double check. In looking at this...I think offhand you're right that the comment here is wrong or misleading.
It does seem offhand to me that the timer is going to be actually on average 2h (after initial bootup and completion of the timer, ignoring the time it takes to actually execute the check).
There was a problem hiding this comment.
I am going to just jot down my flimsy understanding here of how this would play out. Corrections very much welcomed 😄
- T-0: system boots
- T+1h:
OnBootSec=1his "triggered", but doesn't fire immediately due toRandomizedDelaySec=4hbeing applied to all "subtimers" within this timer? - T+~3h: (assume
RandomizedDelaySec=4halways just produces 2h) The timer actually fires for the first time, activating the associated service unit - T+~5h:
OnUnitActiveSec=2his "triggered" but as above withOnBootSecdoesn't fire immediately due to delay - T+~7h: The timer fires the service for the second time
- (loop here)
- T+11h: service fires
- T+15h: service fires
- (and so on looping)
- I guess Saturday at 00:00 the
OnCalendarbit fires, but is still subjected to the ~2h delay - Saturday 2am: service fires
- (subtimer for
OnUnitActiveresets?) - Saturday 4am:
OnUnitActivetriggered but delays - Saturday 6am: service fires
Something like that?
Inspired by coreos/rpm-ostree@db108a3