Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | Split apt-daily timer into two | Julian Andres Klode | 2017-05-04 | 1 | -2/+2 |
| | | | | | | | | | | | 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 | ||||
* | Use the ConditionACPower feature of systemd in the apt-daily service | Nicolas Le Cam | 2016-06-27 | 1 | -0/+1 |
| | | | | | | | | | | .. 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 | ||||
* | Use systemd.timer instead of a cron job | Michael Vogt | 2016-04-01 | 1 | -0/+8 |
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 |