mirror of
https://github.com/systemd/systemd.git
synced 2024-11-02 10:51:20 +03:00
The systemd System and Service Manager
9ea9faff78
On timejumps, including suspend, timer_time_change() calls for a re-calculation of the next elapse. Sadly I'm not quite sure what the intended effect of this was! Because it was not managing to fire OnCalendar= timers which fired during the suspend... unless the timer had already fired once before. Reported, entirely correctly as far as I can see, on stackexchange: https://unix.stackexchange.com/questions/351829/systemd-timer-that-expired-while-suspended /* If we know the last time this was * triggered, schedule the job based relative - * to that. If we don't just start from - * now. */ + * to that. If we don't, just start from + * the activation time. */ The same code is called for both the initial calculation and this re-calculation. If we're _not_ already active, then this is before the activation time has been recorded in the unit, so just use the current time as before. The new code is mechanically adapted from the same logic for `OnActiveSec=` (case TIMER_ACTIVE in the code which follows). Tested with `date --set`. Motivations: * Rotate monitoring data from Atop into files which are named per-day. Fedora currently implements this with a cron job that runs at midnight, but that didn't handle suspend correctly either. * unbound-anchor.timer on Fedora, is used to update DNSSEC "root trust anchor" daily, before the TTL expires. It uses OnCalendar=daily AccuracySec=24h. Which is a bit suspect because the TTL is 2 days, but I think it has the right general idea. None of the other timer settings are correct, because they would not account for time spent in suspend. Unless you set WakeSystem (this feature is currently undocumented). * So in general, we can expect to see people using OnCalendar= for the same cases as cron.daily and cron.monthly. Which use anacron to keep track of jobs which should be run even if the system was down at the time. Timers which are configured to run more frequently than that, are unlikely to mind if they get run slightly more often that the writer realized, relative to the amount of time the system was really running. * From the user report above: "I only want to use remind to show a desktop notification, it seems excessive to wake up the computer for that. Also, I would like to get the reminder first thing in the morning, so the OnActiveSec doesn't help with that." |
||
---|---|---|
.github | ||
.mkosi | ||
catalog | ||
coccinelle | ||
doc | ||
docs | ||
factory/etc | ||
hwdb | ||
man | ||
modprobe.d | ||
network | ||
po | ||
presets | ||
rules | ||
scripts | ||
shell-completion | ||
src | ||
sysctl.d | ||
sysusers.d | ||
test | ||
tmpfiles.d | ||
tools | ||
travis-ci | ||
units | ||
xorg | ||
.dir-locals.el | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
.mailmap | ||
.travis.yml | ||
.vimrc | ||
.ycm_extra_conf.py | ||
configure | ||
LICENSE.GPL2 | ||
LICENSE.LGPL2.1 | ||
Makefile | ||
meson_options.txt | ||
meson.build | ||
mkosi.build | ||
mkosi.default | ||
NEWS | ||
README | ||
README.md | ||
TODO | ||
zanata.xml |
systemd - System and Service Manager
Details
General information about systemd can be found in the systemd Wiki.
Information about build requirements are provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the HACKING file for information 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 or join our IRC channel.