| Age | Commit message (Collapse) | Author |
|---|
|
There's no real point in pulling it in in the timer already,
and it it somewhat saver to do so in the service.
(cherry picked from commit 11417c1058e1b8441ee8f30f948e854b7a6ce89e)
LP: #1716973
(cherry picked from commit 3e639687bbea08acd34f5a66dc99ea62848b7c17)
|
|
The timer doing downloading runs throughout the day, whereas
automatic upgrade and clean actions only happen in the morning.
The upgrade service and timer have After= ordering requirements
on their non-upgrade counterparts to ensure that upgrading at
boot takes place after downloading.
LP: #1686470
(cherry picked from commit 496313fb8e83af2ba71f6ce3d729be687c293dfd)
(cherry picked from commit a234cfe1466066aa1f404cf01e544f16cb517846)
|
|
The timeout values were so large that the timer could run at any
random time of the day, possibly easily interfering with business
hours, and causing trouble. Reduce them to 30 minutes of random
delay and an accuracy to the default value (1 minute).
Also drop the 18:00 event. People still actively use their device
during that time, and for servers, there might be less attendance
than in the regular 06:00 time slot, so longer time to fix things
if something breaks.
During a boot, the service might be run to catch up with a timer
that would have normally elapsed. Due to no dependencies, it would
have run before the network is online - that's bad. Adding an After
and a Wants fixes that for boots, but still leaves the same issue
for Resume.
LP: #1615482
(cherry picked from commit b4f32b13055287d2ac46a08255db475af195b5f7)
(cherry picked from commit 6267b47f85588fdd00f6e667598abe52887385ae)
|
|
See https://github.com/systemd/systemd/issues/2956 - it appears that
`OnCalendar=*-*-* 6,18:00` and `OnCalendar=*-*-* 6:00,18:00` are
quite different.
Git-Dch: ignore
|
|
The rational is that we need to spread the load on the mirrors
that apt update and unattended-upgrades cause. To do so, we
leverage the RandomizeDelay feature of systemd. The other advantage
is that the timer is not run at a fixed daily.daily time but
instead every 24h. This also fixes the problem that the randomized
deplay in the current apt.cron.daily causes other cron jobs to
be deplayed.
A compatibility cron job is also provided for systems that do not
use systemd.
Note that the time is fired two times a day, but the logic inside
of apt.systemd.daily will ensure (via stamp files) that the
servers are hit at most every 24h. Firing two times a day helps
with the worst case update time and it also helps with systems
that are not always on.
LP: #246381, #727685
Closes: #600262, #709675, #663290
|
