Bug#913303: systemd: RandomizedDelaySec should inherit the clock of the timer that triggered it
Lars Luthman
deb-bugs at larsluthman.net
Fri Nov 9 10:49:55 GMT 2018
Package: systemd
Version: 232-25+deb9u4
Severity: normal
When using RandomizedDelaySec, the random delay that is added is treated as
delay in calendar time (not paused during system suspension) even if the timer
that triggered the random delay is one of the 'monotonic' timers that _should_
be paused during system suspension. This makes RandomizedDelaySec fairly
useless for preventing thundering herds of timer jobs when the system wakes
up, if those timer jobs were configured using, say, OnUnitInactive (a monotonic
timer, according to the systemd.timer webpage), in order to run jobs at random
intervals.
Here is a short example of what happens, with a timer configured to run the
fetch-mail service at random intervals between 0 and 40 minutes:
me at laptop:~$ cat ~/.config/systemd/user/fetch-mail.timer
[Timer]
OnActiveSec=0
OnUnitInactiveSec=0
AccuracySec=1
RandomizedDelaySec=2400
[Install]
WantedBy=timers.target
me at laptop:~$ systemctl --user list-timers fetch-mail.timer
NEXT LEFT LAST PASSED
Fri 2018-11-09 10:57:44 CET 11min left Fri 2018-11-09 10:43:11 CET 2min 52s ag
1 timers listed.
Pass --all to see loaded but inactive timers, too.
me at laptop:~$ date; systemctl suspend
Fri 9 Nov 10:46:16 CET 2018
*** Waking up a few minutes later... ***
me at laptop:~$ date; systemctl --user list-timers fetch-mail.timer
Fri 9 Nov 10:52:06 CET 2018
NEXT LEFT LAST PASSED
Fri 2018-11-09 10:56:22 CET 4min 16s left Fri 2018-11-09 10:43:11 CET 8min ago
1 timers listed.
Pass --all to see loaded but inactive timers, too.
When the computer is suspended, the randomized delay keeps on running instead
of pausing, and when it's woken up, the timer is 7 minutes nearer to expiring
rather than 0 minutes as expected. If the delay expires while the computer is
suspended, systemd will immediately run the job on wakeup rather than waiting
7 more minutes. If the delays for several timers expire before the wakeup, all
those jobs will run at once, which is what RandomizedDelaySec is meant to
avoid.
I would expect RandomizedDelaySec to add a random delay _using the same clock
as the timer that triggered it_, in this case OnUnitInactiveSec. That would
cause a more expected behaviour.
-- Package-specific info:
-- System Information:
Debian Release: 9.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 4.9.0-8-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=1541759466 WARNING torsocks[16644]: [syscall] Unsupported syscall number 220. Denying the call (in tsocks_syscall() at syscall.c:488)
UTF-8), LANGUAGE=en_GB:en (charmap=1541759466 WARNING torsocks[16646]: [syscall] Unsupported syscall number 220. Denying the call (in tsocks_syscall() at syscall.c:488)
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages systemd depends on:
ii adduser 3.115
ii libacl1 2.2.52-3+b1
ii libapparmor1 2.11.0-3+deb9u2
ii libaudit1 1:2.6.7-2
ii libblkid1 2.29.2-1+deb9u1
ii libc6 2.24-11+deb9u3
ii libcap2 1:2.25-1
ii libcryptsetup4 2:1.7.3-4
ii libgcc1 1:7.2.0-19
ii libgcrypt20 1.7.6-2+deb9u3
ii libgpg-error0 1.26-2
ii libidn11 1.33-1
ii libip4tc0 1.6.0+snapshot20161117-6
ii libkmod2 23-2
ii liblz4-1 0.0~r131-2+b1
ii liblzma5 5.2.2-1.2+b1
ii libmount1 2.29.2-1+deb9u1
ii libpam0g 1.1.8-3.6
ii libseccomp2 2.3.1-2.1
ii libselinux1 2.6-3+b3
ii libsystemd0 232-25+deb9u4
ii mount 2.29.2-1+deb9u1
ii procps 2:3.3.12-3+deb9u1
ii util-linux 2.29.2-1+deb9u1
Versions of packages systemd recommends:
ii dbus 1.10.26-0+deb9u1
ii libpam-systemd 232-25+deb9u4
Versions of packages systemd suggests:
ii policykit-1 0.105-18
ii systemd-container 232-25+deb9u4
ii systemd-ui 3-4+b1
Versions of packages systemd is related to:
pn dracut <none>
ii initramfs-tools 0.130
ii udev 232-25+deb9u4
-- debconf information excluded
More information about the Pkg-systemd-maintainers
mailing list