| Age | Commit message (Collapse) | Author |
|---|
|
We now wait for being online ourselves, so all we need to wait
on is for services we are using to be online first. This avoids
severe boot slowdowns by other services having specified an
After=network-online.target without a Wants=.
Gbp-Dch: Full
|
|
There's no real point in pulling it in in the timer already,
and it it somewhat saver to do so in the service.
|
|
Introduce a new helper, apt-helper wait-online that uses
NetworkManager and/or systemd-networkd to wait for them
reporting online, with a time out of 30 seconds; and run
that helper before running the daily update script.
LP: #1699850
Gbp-Dch: Full
|
|
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
|
|
.. instead of hardcoding the functionnality in the apt.systemd.daily
script.
Also make the compatibility cron job provide the same functionnality
for systems that do not use systemd.
Closes: #827930
|
|
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
|
