If a computer is only running occasionally the apt-daily*.timers
(apt-daily.timer and apt-daily-upgrade.timer) are hardly ever executed.
As far as I understand this is because of the RandomizedDelaySec values
for the timers. Especially the 12h for the apt-daily.timer.


Lets say a computer is running only 30 minutes every month.
That makes 6 hours a year.
Then statistically the apt-daily.timer will only run once every 2 years.

Those computers could be rarely used pc's, notebooks or even
offline-backup systems.
I'm not an expert for systemd timers. But I'd say the timer should run
immediately after boot (and wakeup from s2ram/s2disk), if the timer
expired while the computer wasn't running.


This is a notebook, being rarely used by one of my family members.
You can see, that it's being used for 5 to 60 minutes every few weeks.

$ zgrep -aEo '.*(Command line: BOOT_IMAGE=|PM: hibernation: hibernation
(entry|exit))' /var/log/messages{.2,.1,}
/var/log/messages.2:Nov  6 13:36:38 MyPC kernel: [ 7024.194560] PM:
hibernation: hibernation exit
/var/log/messages.2:Nov  6 13:46:51 MyPC kernel: [ 7638.066922] PM:
hibernation: hibernation entry
/var/log/messages.2:Nov 26 15:32:20 MyPC kernel: [ 7647.920545] PM:
hibernation: hibernation exit
/var/log/messages.1:Nov 26 16:26:32 MyPC kernel: [10918.255697] PM:
hibernation: hibernation entry
/var/log/messages.1:Dec  1 11:17:26 MyPC kernel: [10945.390253] PM:
hibernation: hibernation exit
/var/log/messages.1:Dec  1 11:21:38 MyPC kernel: [11198.595707] PM:
hibernation: hibernation entry
/var/log/messages.1:Dec  1 11:22:52 MyPC kernel: [11251.644099] PM:
hibernation: hibernation exit
# shut down at Dec 1 around 12:00 (couldn't find that in the logs)
/var/log/messages.1:Dec  4 18:52:44 MyPC kernel: [    0.000000] Command
line: BOOT_IMAGE=

$ systemctl list-timers apt-daily.timer
NEXT                        LEFT       LAST
PASSED              UNIT            ACTIVATES
Sat 2021-12-04 19:21:08 CET 17min left Mon 2021-11-01 12:16:15 CET 1
months 2 days ago apt-daily.timer apt-daily.service



Regards,
kolAflash

P.S.

I guess RandomizedDelaySec=12h is needed to balance the load on the
update servers. So removing or lowering RandomizedDelaySec is probably
not a good solution.
On the other hand, when a system has just been booted or waked from s2*,
there should be no reason to wait further.

So another systemd option is needed to prevent the update from always
being run at the same time. But on the other hand there should be no
further delay if the timer expired while the system wasn't running.
Unfortunately I don't see such an systemd timer option.

But maybe there's another alternative:
Remove RandomizedDelaySec and replace OnCalendar with OnUnitInactiveSec=12h.
This would result in some randomization. But if I understand systemd
correctly, the timer would run immediately if it expired while the
system was offline.

https://www.freedesktop.org/software/systemd/man/systemd.timer.html
| OnUnitInactiveSec=
|   Defines a timer relative to when the unit the timer unit is
|   activating was last deactivated.

Control: reassign -1 systemd
Control: forcemerge 997943 -1
Control: affects 997943 apt

In fact quite the opposite. We must absolutely always distribute the
load as I don't want to have all my containers/VMs do intense work at
precisely the same time, it's madness.

My general expectation as a user would be that things do not run immediately
after resume, but only in idle periods - if I resumed, it's likely I
have to get work done _right now_ and I likely will have trouble if
everything is running update or installing upgrades in the background,
the load is intense.

In any case, this is a recent change (whether regression or feature
is debatable) in systemd, and I'm reassigning and merging it with the
issue where this is being tracked.