Avoiding having calendar-interval timers run during boot/wakeup

[zackw]

Submission type

• Bug report
• Request for enhancement (RFE)

NOTE: Do not submit anything other than bug reports or RFEs via the issue tracker!

systemd version the issue has been seen with

232 (the current version of systemd.timer(5) is unchanged)

Used distribution

Debian (jessie, sid)

Feature request

If an OnCalendar timer has its deadline expire while the computer is suspended or powered off, systemd will run the timer immediately upon wakeup or power-on. Sometimes this is exactly what you want, but for daily background jobs (e.g. distribution package index updates) there is no particular urgency and you would rather not have them add additional resource contention. (See Debian bug #844453 for a detailed example scenario.)

Can we please have a mechanism for specifying that OnCalendar timers should not run within some interval of some other event (such as boot)?

(Note that systemd-tmpfiles-clean.timer seems to have been written specifically to avoid this issue, using OnBootSec+OnActiveSec, which means that a laptop that spends most of its time suspended will not get its temporary files cleaned for much longer than was probably the intent.)

[julian-klode]

Anacron imposed a 5 minute delay on catching up with daily jobs during boot, maybe it makes sense to follow that, but I'm not entirely convinced. I should note that this only really affects users without an SSD.

Maybe it makes sense to run any catch-up stuff after reaching the login screen, though. That to me sounds like it makes a lot more sense than imposing an arbitrary magic delay, and is actually a proper design.

[karelzak]

The same issue with fstrim timer (OnCalendar=weekly) https://bugzilla.redhat.com/show_bug.cgi?id=1442537

It has pretty bad impact to the boot time...

I think we need postpone OnCalendars at all or add option to specify delay after boot

OnCalendar=weekly
OnBootDelay=10min

or so...

[julian-klode]

@karelzak I'm surprised the RH bug is mentioning RandomizedDelaySec as a work around. We have RandomizedDelaySec=12h in apt's timer and that makes no difference.

Just doing what anacron does (5m) is probably the safest option.

[fhuberts]

@julian-klode 'RandomizedDelaySec' is the closest I could find, but wasn't able to actually test it yet...
I can see why it wouldn't work, but I could also argue that if it doesn't work that the semantics of the option are different from what I expected and what is specified at https://www.freedesktop.org/software/systemd/man/systemd.timer.html, hence a bug.

[hedayat]

This is my finding about RandomizedDelaySec;
RandomizedDelaySec doesn't work. Apparently, it only affects the scheduled time of running the timer (e.g. run on 00:10 rather than 00:00), but doesn't affect running the service immediately if it is a Persistent service and has not run on time. So, the service will still run immediately on boot if the system was off when the service was supposed to run.

The bug also affects (very badly) mlocate in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1282232

[hedayat]

I prefer the delay to be user controllable rather than a fixed one (e.g. 5min). Or maybe RandomizedDelaySec should be also applied (in addition to the fixed time) when an outdated timer is going to be started too.