summaryrefslogtreecommitdiff
path: root/debian/apt-daily.timer
Commit message (Collapse)AuthorAgeFilesLines
* apt-daily: Pull in network-online.target in service, not timerJulian Andres Klode2017-09-091-2/+0
| | | | | There's no real point in pulling it in in the timer already, and it it somewhat saver to do so in the service.
* Split apt-daily timer into twoJulian Andres Klode2017-05-041-3/+3
| | | | | | | | | | | 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
* systemd: Rework timing and add After=network-onlineJulian Andres Klode2017-04-241-3/+4
| | | | | | | | | | | | | | | | | | | | 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
* Fix `OnCalendar=*-*-* 6,18:00` instead of `OnCalendar=*-*-* 6:00,18:00`Michael Vogt2016-04-041-1/+1
| | | | | | | | 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
* Use systemd.timer instead of a cron jobMichael Vogt2016-04-011-0/+11
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