-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
timer: Import defaults from systemd-sysupdate.timer #956
base: main
Are you sure you want to change the base?
Conversation
Inspired by coreos/rpm-ostree@db108a3 Signed-off-by: Colin Walters <walters@verbum.org>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍, one minor correction if you want to fix (assuming I'm not misunderstanding things).
# 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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=1h
is "triggered", but doesn't fire immediately due toRandomizedDelaySec=4h
being applied to all "subtimers" within this timer? - T+~3h: (assume
RandomizedDelaySec=4h
always just produces 2h) The timer actually fires for the first time, activating the associated service unit - T+~5h:
OnUnitActiveSec=2h
is "triggered" but as above withOnBootSec
doesn'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
OnCalendar
bit fires, but is still subjected to the ~2h delay - Saturday 2am: service fires
- (subtimer for
OnUnitActive
resets?) - Saturday 4am:
OnUnitActive
triggered but delays - Saturday 6am: service fires
Something like that?
Inspired by coreos/rpm-ostree@db108a3