A calendar timer that is already waiting keeps the base timestamp it was last armed from. When the wall clock is set backwards, that base can end up in the future relative to the new realtime, and passing it to calendar_spec_next_usec() schedules the next elapse relative to the old future time instead of recalculating from now. systemctl list-timers then keeps showing the stale pre-adjustment elapse (e.g. "3 years left" after the clock moved back two years) and the timer never catches up. Clamp the selected calendar base to the current realtime before asking calendar_spec_next_usec() for the next occurrence. The clamp only kicks in when the base is genuinely in the future, so Persistent=yes timers whose last trigger is still in the past keep their catch-up behaviour and we don't reintroduce the missed-run regression seen after suspend. Fixes #6036.
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS, and also repositories with packages built from the latest stable release
