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@laptop:~$ cat ~/.config/systemd/user/fetch-mail.timer [Timer] OnActiveSec=0 OnUnitInactiveSec=0 AccuracySec=1 RandomizedDelaySec=2400 [Install] WantedBy=timers.target me@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@laptop:~$ date; systemctl suspend Fri 9 Nov 10:46:16 CET 2018 *** Waking up a few minutes later... *** me@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 _______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers