Ubuntu 16.04: Unattended-upgrades runs at random times












10















I have configured unattended-upgrades to install security packages and notify by mail when it does so.



I have noticed that the installation happens at very random times. I know that the latest versions added a random delay up to 30 minutes starting from the cron.daily execution time.



However the delays I am experiencing are much bigger than that. I see unattended-upgrades executing at 9am, 3pm, 12am... The logs show the same, so it is not just the email delivery that takes longer.



The unattended upgrades task is the first one in cron.daily, meaning that there is no previous task with huge execution times.



Anybody experienced a similar thing?






16.04 cron unattended-upgrades







share|improve this question























  • The random behavior is deliberate - to smooth out demand instead of millions of systems hammering a few mirrors at the same times each day. Ordinary desktop users should not notice the behavior at all. Some enterprise users way wish to change the behavior to something a bit more predictable, and are certainly welcome to do so.

    – user535733
    Feb 5 at 13:50











  • Yes, the reason behind this choice is clear. It is just that this behavior is unacceptable for production systems. At the time i asked this question, this behavior (and the fix) was not documented anywhere

    – daniel f.
    Feb 5 at 14:06
















10















I have configured unattended-upgrades to install security packages and notify by mail when it does so.



I have noticed that the installation happens at very random times. I know that the latest versions added a random delay up to 30 minutes starting from the cron.daily execution time.



However the delays I am experiencing are much bigger than that. I see unattended-upgrades executing at 9am, 3pm, 12am... The logs show the same, so it is not just the email delivery that takes longer.



The unattended upgrades task is the first one in cron.daily, meaning that there is no previous task with huge execution times.



Anybody experienced a similar thing?






16.04 cron unattended-upgrades







share|improve this question























  • The random behavior is deliberate - to smooth out demand instead of millions of systems hammering a few mirrors at the same times each day. Ordinary desktop users should not notice the behavior at all. Some enterprise users way wish to change the behavior to something a bit more predictable, and are certainly welcome to do so.

    – user535733
    Feb 5 at 13:50











  • Yes, the reason behind this choice is clear. It is just that this behavior is unacceptable for production systems. At the time i asked this question, this behavior (and the fix) was not documented anywhere

    – daniel f.
    Feb 5 at 14:06














10












10








10


6






I have configured unattended-upgrades to install security packages and notify by mail when it does so.



I have noticed that the installation happens at very random times. I know that the latest versions added a random delay up to 30 minutes starting from the cron.daily execution time.



However the delays I am experiencing are much bigger than that. I see unattended-upgrades executing at 9am, 3pm, 12am... The logs show the same, so it is not just the email delivery that takes longer.



The unattended upgrades task is the first one in cron.daily, meaning that there is no previous task with huge execution times.



Anybody experienced a similar thing?






16.04 cron unattended-upgrades







share|improve this question














I have configured unattended-upgrades to install security packages and notify by mail when it does so.



I have noticed that the installation happens at very random times. I know that the latest versions added a random delay up to 30 minutes starting from the cron.daily execution time.



However the delays I am experiencing are much bigger than that. I see unattended-upgrades executing at 9am, 3pm, 12am... The logs show the same, so it is not just the email delivery that takes longer.



The unattended upgrades task is the first one in cron.daily, meaning that there is no previous task with huge execution times.



Anybody experienced a similar thing?






16.04 cron unattended-upgrades




16.04 cron unattended-upgrades






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Sep 14 '16 at 8:06









daniel f.daniel f.

366313




366313













  • The random behavior is deliberate - to smooth out demand instead of millions of systems hammering a few mirrors at the same times each day. Ordinary desktop users should not notice the behavior at all. Some enterprise users way wish to change the behavior to something a bit more predictable, and are certainly welcome to do so.

    – user535733
    Feb 5 at 13:50











  • Yes, the reason behind this choice is clear. It is just that this behavior is unacceptable for production systems. At the time i asked this question, this behavior (and the fix) was not documented anywhere

    – daniel f.
    Feb 5 at 14:06



















  • The random behavior is deliberate - to smooth out demand instead of millions of systems hammering a few mirrors at the same times each day. Ordinary desktop users should not notice the behavior at all. Some enterprise users way wish to change the behavior to something a bit more predictable, and are certainly welcome to do so.

    – user535733
    Feb 5 at 13:50











  • Yes, the reason behind this choice is clear. It is just that this behavior is unacceptable for production systems. At the time i asked this question, this behavior (and the fix) was not documented anywhere

    – daniel f.
    Feb 5 at 14:06

















The random behavior is deliberate - to smooth out demand instead of millions of systems hammering a few mirrors at the same times each day. Ordinary desktop users should not notice the behavior at all. Some enterprise users way wish to change the behavior to something a bit more predictable, and are certainly welcome to do so.

– user535733
Feb 5 at 13:50





The random behavior is deliberate - to smooth out demand instead of millions of systems hammering a few mirrors at the same times each day. Ordinary desktop users should not notice the behavior at all. Some enterprise users way wish to change the behavior to something a bit more predictable, and are certainly welcome to do so.

– user535733
Feb 5 at 13:50













Yes, the reason behind this choice is clear. It is just that this behavior is unacceptable for production systems. At the time i asked this question, this behavior (and the fix) was not documented anywhere

– daniel f.
Feb 5 at 14:06





Yes, the reason behind this choice is clear. It is just that this behavior is unacceptable for production systems. At the time i asked this question, this behavior (and the fix) was not documented anywhere

– daniel f.
Feb 5 at 14:06










3 Answers
3






active

oldest

votes


















14














After debugging this I found the solution.



The root cause of this issue resides in the fact that under Ubuntu 16.04 and newer, unattended-upgrades uses systemd - not cron - to schedule the updates with a huge randomized delay:



/lib/systemd/system/apt-daily.timer is configured with



OnCalendar=*-*-* 6,18:00

RandomizedDelaySec=12h


This means that it will run twice a day, at 6:00 and 18:00, with a random delay of up to 12 hours. As this is not always acceptable for production environments, I had to override these settings.



In order to keep the package config files untouched, I defined my override in /etc/systemd/system/apt-daily.timer.d/override.conf (I had to create the folder and file).



There I set



[Timer]

OnCalendar=

OnCalendar=06:00

RandomizedDelaySec=1h


to have unattended-upgrades run at 6:00 plus a random delay of up to an hour.



Then I simply restarted the timer with systemctl restart apt-daily.timer (eventually need to reload the daemon).



Unattended-updates now runs at predictable times again!



Edit:
It would seem as if for Ubuntu 18.04 things changed a bit. The override should now be stored in /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf and look like this:



[Timer]

OnCalendar=*-*-* 6:00

RandomizedDelaySec=1h





share|improve this answer


























  • Why do you clear OnCalendar first?

    – jarno
    Dec 14 '16 at 10:15






  • 1





    Because otherwise it would only ADD a new timer at 6am, leaving the existing one as well. Since I want unattended-upgrades to ONLY run at 6, I need to clear the schedule first.

    – daniel f.
    Dec 14 '16 at 10:19











  • I added "OnBootSec=5min" to enable running after boot as well, but it did not work. (also added OnUnitActiveSec=12h so that it is not run too frequently.)

    – jarno
    Dec 14 '16 at 15:09











  • systemd, or rather, the systemd mindset, strikes again. I may have to rethink upgrading to Xenial Xerus in production after this gem bit me.

    – Joe
    Jan 11 '17 at 11:30






  • 1





    @daniel f. I have an apt-daily.timer file in /lib/systemd/system/ as well as one in /etc/systemd/system/timers.target.wants/ However I don't have any in /etc/systemd/system/ itself like you. Would you know if I should be creating the apt-daily.timer.d directory and the override.conf under /lib/systemd/system instead? All advice gratefully recd with thx.

    – Purvez
    Apr 27 '17 at 10:24



















2














The official debian documentation on https://wiki.debian.org/UnattendedUpgrades currently has a mistake in it that is misleading a lot of people.
It claims that you can override the upgrade time by creating a file called



/etc/systemd/system/apt-daily-upgrade.d/override.conf


However the correct path is 



/etc/systemd/system/apt-daily-upgrade.timer.d/override.conf





share|improve this answer





















  • 1





    Nice finding. IMHO the safest thing is to use sudo systemctl edit apt-daily.timer. This will open an editor with the correct drop-in file.

    – PerlDuck
    Feb 5 at 10:39






  • 1





    Thank you PerlDuck, I edited the Debian Wiki page with your suggestion

    – Rolf Wojtech
    Feb 5 at 12:45



















0














I tried Daniel's solution but the upgrade still ran at the wrong times. Turned out there two systemd overrides that are needed:



Used for downloads



/lib/systemd/system/apt-daily.timer - override with /etc/systemd/system/apt-daily.timer.d/override.conf



Used for upgrading



/lib/systemd/system/apt-daily-upgrade.timer - override with /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf






share|improve this answer





















  • 1





    Which version are you on? So you had to override both mentioned timers at the same time?

    – daniel f.
    Jan 23 at 7:48











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f824718%2fubuntu-16-04-unattended-upgrades-runs-at-random-times%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes









14














After debugging this I found the solution.



The root cause of this issue resides in the fact that under Ubuntu 16.04 and newer, unattended-upgrades uses systemd - not cron - to schedule the updates with a huge randomized delay:



/lib/systemd/system/apt-daily.timer is configured with



OnCalendar=*-*-* 6,18:00

RandomizedDelaySec=12h


This means that it will run twice a day, at 6:00 and 18:00, with a random delay of up to 12 hours. As this is not always acceptable for production environments, I had to override these settings.



In order to keep the package config files untouched, I defined my override in /etc/systemd/system/apt-daily.timer.d/override.conf (I had to create the folder and file).



There I set



[Timer]

OnCalendar=

OnCalendar=06:00

RandomizedDelaySec=1h


to have unattended-upgrades run at 6:00 plus a random delay of up to an hour.



Then I simply restarted the timer with systemctl restart apt-daily.timer (eventually need to reload the daemon).



Unattended-updates now runs at predictable times again!



Edit:
It would seem as if for Ubuntu 18.04 things changed a bit. The override should now be stored in /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf and look like this:



[Timer]

OnCalendar=*-*-* 6:00

RandomizedDelaySec=1h





share|improve this answer


























  • Why do you clear OnCalendar first?

    – jarno
    Dec 14 '16 at 10:15






  • 1





    Because otherwise it would only ADD a new timer at 6am, leaving the existing one as well. Since I want unattended-upgrades to ONLY run at 6, I need to clear the schedule first.

    – daniel f.
    Dec 14 '16 at 10:19











  • I added "OnBootSec=5min" to enable running after boot as well, but it did not work. (also added OnUnitActiveSec=12h so that it is not run too frequently.)

    – jarno
    Dec 14 '16 at 15:09











  • systemd, or rather, the systemd mindset, strikes again. I may have to rethink upgrading to Xenial Xerus in production after this gem bit me.

    – Joe
    Jan 11 '17 at 11:30






  • 1





    @daniel f. I have an apt-daily.timer file in /lib/systemd/system/ as well as one in /etc/systemd/system/timers.target.wants/ However I don't have any in /etc/systemd/system/ itself like you. Would you know if I should be creating the apt-daily.timer.d directory and the override.conf under /lib/systemd/system instead? All advice gratefully recd with thx.

    – Purvez
    Apr 27 '17 at 10:24
















14














After debugging this I found the solution.



The root cause of this issue resides in the fact that under Ubuntu 16.04 and newer, unattended-upgrades uses systemd - not cron - to schedule the updates with a huge randomized delay:



/lib/systemd/system/apt-daily.timer is configured with



OnCalendar=*-*-* 6,18:00

RandomizedDelaySec=12h


This means that it will run twice a day, at 6:00 and 18:00, with a random delay of up to 12 hours. As this is not always acceptable for production environments, I had to override these settings.



In order to keep the package config files untouched, I defined my override in /etc/systemd/system/apt-daily.timer.d/override.conf (I had to create the folder and file).



There I set



[Timer]

OnCalendar=

OnCalendar=06:00

RandomizedDelaySec=1h


to have unattended-upgrades run at 6:00 plus a random delay of up to an hour.



Then I simply restarted the timer with systemctl restart apt-daily.timer (eventually need to reload the daemon).



Unattended-updates now runs at predictable times again!



Edit:
It would seem as if for Ubuntu 18.04 things changed a bit. The override should now be stored in /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf and look like this:



[Timer]

OnCalendar=*-*-* 6:00

RandomizedDelaySec=1h





share|improve this answer


























  • Why do you clear OnCalendar first?

    – jarno
    Dec 14 '16 at 10:15






  • 1





    Because otherwise it would only ADD a new timer at 6am, leaving the existing one as well. Since I want unattended-upgrades to ONLY run at 6, I need to clear the schedule first.

    – daniel f.
    Dec 14 '16 at 10:19











  • I added "OnBootSec=5min" to enable running after boot as well, but it did not work. (also added OnUnitActiveSec=12h so that it is not run too frequently.)

    – jarno
    Dec 14 '16 at 15:09











  • systemd, or rather, the systemd mindset, strikes again. I may have to rethink upgrading to Xenial Xerus in production after this gem bit me.

    – Joe
    Jan 11 '17 at 11:30






  • 1





    @daniel f. I have an apt-daily.timer file in /lib/systemd/system/ as well as one in /etc/systemd/system/timers.target.wants/ However I don't have any in /etc/systemd/system/ itself like you. Would you know if I should be creating the apt-daily.timer.d directory and the override.conf under /lib/systemd/system instead? All advice gratefully recd with thx.

    – Purvez
    Apr 27 '17 at 10:24














14












14








14







After debugging this I found the solution.



The root cause of this issue resides in the fact that under Ubuntu 16.04 and newer, unattended-upgrades uses systemd - not cron - to schedule the updates with a huge randomized delay:



/lib/systemd/system/apt-daily.timer is configured with



OnCalendar=*-*-* 6,18:00

RandomizedDelaySec=12h


This means that it will run twice a day, at 6:00 and 18:00, with a random delay of up to 12 hours. As this is not always acceptable for production environments, I had to override these settings.



In order to keep the package config files untouched, I defined my override in /etc/systemd/system/apt-daily.timer.d/override.conf (I had to create the folder and file).



There I set



[Timer]

OnCalendar=

OnCalendar=06:00

RandomizedDelaySec=1h


to have unattended-upgrades run at 6:00 plus a random delay of up to an hour.



Then I simply restarted the timer with systemctl restart apt-daily.timer (eventually need to reload the daemon).



Unattended-updates now runs at predictable times again!



Edit:
It would seem as if for Ubuntu 18.04 things changed a bit. The override should now be stored in /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf and look like this:



[Timer]

OnCalendar=*-*-* 6:00

RandomizedDelaySec=1h





share|improve this answer















After debugging this I found the solution.



The root cause of this issue resides in the fact that under Ubuntu 16.04 and newer, unattended-upgrades uses systemd - not cron - to schedule the updates with a huge randomized delay:



/lib/systemd/system/apt-daily.timer is configured with



OnCalendar=*-*-* 6,18:00

RandomizedDelaySec=12h


This means that it will run twice a day, at 6:00 and 18:00, with a random delay of up to 12 hours. As this is not always acceptable for production environments, I had to override these settings.



In order to keep the package config files untouched, I defined my override in /etc/systemd/system/apt-daily.timer.d/override.conf (I had to create the folder and file).



There I set



[Timer]

OnCalendar=

OnCalendar=06:00

RandomizedDelaySec=1h


to have unattended-upgrades run at 6:00 plus a random delay of up to an hour.



Then I simply restarted the timer with systemctl restart apt-daily.timer (eventually need to reload the daemon).



Unattended-updates now runs at predictable times again!



Edit:
It would seem as if for Ubuntu 18.04 things changed a bit. The override should now be stored in /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf and look like this:



[Timer]

OnCalendar=*-*-* 6:00

RandomizedDelaySec=1h






share|improve this answer














share|improve this answer



share|improve this answer








edited Aug 20 '18 at 10:19

























answered Sep 29 '16 at 13:59









daniel f.daniel f.

366313




366313













  • Why do you clear OnCalendar first?

    – jarno
    Dec 14 '16 at 10:15






  • 1





    Because otherwise it would only ADD a new timer at 6am, leaving the existing one as well. Since I want unattended-upgrades to ONLY run at 6, I need to clear the schedule first.

    – daniel f.
    Dec 14 '16 at 10:19











  • I added "OnBootSec=5min" to enable running after boot as well, but it did not work. (also added OnUnitActiveSec=12h so that it is not run too frequently.)

    – jarno
    Dec 14 '16 at 15:09











  • systemd, or rather, the systemd mindset, strikes again. I may have to rethink upgrading to Xenial Xerus in production after this gem bit me.

    – Joe
    Jan 11 '17 at 11:30






  • 1





    @daniel f. I have an apt-daily.timer file in /lib/systemd/system/ as well as one in /etc/systemd/system/timers.target.wants/ However I don't have any in /etc/systemd/system/ itself like you. Would you know if I should be creating the apt-daily.timer.d directory and the override.conf under /lib/systemd/system instead? All advice gratefully recd with thx.

    – Purvez
    Apr 27 '17 at 10:24



















  • Why do you clear OnCalendar first?

    – jarno
    Dec 14 '16 at 10:15






  • 1





    Because otherwise it would only ADD a new timer at 6am, leaving the existing one as well. Since I want unattended-upgrades to ONLY run at 6, I need to clear the schedule first.

    – daniel f.
    Dec 14 '16 at 10:19











  • I added "OnBootSec=5min" to enable running after boot as well, but it did not work. (also added OnUnitActiveSec=12h so that it is not run too frequently.)

    – jarno
    Dec 14 '16 at 15:09











  • systemd, or rather, the systemd mindset, strikes again. I may have to rethink upgrading to Xenial Xerus in production after this gem bit me.

    – Joe
    Jan 11 '17 at 11:30






  • 1





    @daniel f. I have an apt-daily.timer file in /lib/systemd/system/ as well as one in /etc/systemd/system/timers.target.wants/ However I don't have any in /etc/systemd/system/ itself like you. Would you know if I should be creating the apt-daily.timer.d directory and the override.conf under /lib/systemd/system instead? All advice gratefully recd with thx.

    – Purvez
    Apr 27 '17 at 10:24

















Why do you clear OnCalendar first?

– jarno
Dec 14 '16 at 10:15





Why do you clear OnCalendar first?

– jarno
Dec 14 '16 at 10:15




1




1





Because otherwise it would only ADD a new timer at 6am, leaving the existing one as well. Since I want unattended-upgrades to ONLY run at 6, I need to clear the schedule first.

– daniel f.
Dec 14 '16 at 10:19





Because otherwise it would only ADD a new timer at 6am, leaving the existing one as well. Since I want unattended-upgrades to ONLY run at 6, I need to clear the schedule first.

– daniel f.
Dec 14 '16 at 10:19













I added "OnBootSec=5min" to enable running after boot as well, but it did not work. (also added OnUnitActiveSec=12h so that it is not run too frequently.)

– jarno
Dec 14 '16 at 15:09





I added "OnBootSec=5min" to enable running after boot as well, but it did not work. (also added OnUnitActiveSec=12h so that it is not run too frequently.)

– jarno
Dec 14 '16 at 15:09













systemd, or rather, the systemd mindset, strikes again. I may have to rethink upgrading to Xenial Xerus in production after this gem bit me.

– Joe
Jan 11 '17 at 11:30





systemd, or rather, the systemd mindset, strikes again. I may have to rethink upgrading to Xenial Xerus in production after this gem bit me.

– Joe
Jan 11 '17 at 11:30




1




1





@daniel f. I have an apt-daily.timer file in /lib/systemd/system/ as well as one in /etc/systemd/system/timers.target.wants/ However I don't have any in /etc/systemd/system/ itself like you. Would you know if I should be creating the apt-daily.timer.d directory and the override.conf under /lib/systemd/system instead? All advice gratefully recd with thx.

– Purvez
Apr 27 '17 at 10:24





@daniel f. I have an apt-daily.timer file in /lib/systemd/system/ as well as one in /etc/systemd/system/timers.target.wants/ However I don't have any in /etc/systemd/system/ itself like you. Would you know if I should be creating the apt-daily.timer.d directory and the override.conf under /lib/systemd/system instead? All advice gratefully recd with thx.

– Purvez
Apr 27 '17 at 10:24













2














The official debian documentation on https://wiki.debian.org/UnattendedUpgrades currently has a mistake in it that is misleading a lot of people.
It claims that you can override the upgrade time by creating a file called



/etc/systemd/system/apt-daily-upgrade.d/override.conf


However the correct path is 



/etc/systemd/system/apt-daily-upgrade.timer.d/override.conf





share|improve this answer





















  • 1





    Nice finding. IMHO the safest thing is to use sudo systemctl edit apt-daily.timer. This will open an editor with the correct drop-in file.

    – PerlDuck
    Feb 5 at 10:39






  • 1





    Thank you PerlDuck, I edited the Debian Wiki page with your suggestion

    – Rolf Wojtech
    Feb 5 at 12:45
















2














The official debian documentation on https://wiki.debian.org/UnattendedUpgrades currently has a mistake in it that is misleading a lot of people.
It claims that you can override the upgrade time by creating a file called



/etc/systemd/system/apt-daily-upgrade.d/override.conf


However the correct path is 



/etc/systemd/system/apt-daily-upgrade.timer.d/override.conf





share|improve this answer





















  • 1





    Nice finding. IMHO the safest thing is to use sudo systemctl edit apt-daily.timer. This will open an editor with the correct drop-in file.

    – PerlDuck
    Feb 5 at 10:39






  • 1





    Thank you PerlDuck, I edited the Debian Wiki page with your suggestion

    – Rolf Wojtech
    Feb 5 at 12:45














2












2








2







The official debian documentation on https://wiki.debian.org/UnattendedUpgrades currently has a mistake in it that is misleading a lot of people.
It claims that you can override the upgrade time by creating a file called



/etc/systemd/system/apt-daily-upgrade.d/override.conf


However the correct path is 



/etc/systemd/system/apt-daily-upgrade.timer.d/override.conf





share|improve this answer















The official debian documentation on https://wiki.debian.org/UnattendedUpgrades currently has a mistake in it that is misleading a lot of people.
It claims that you can override the upgrade time by creating a file called



/etc/systemd/system/apt-daily-upgrade.d/override.conf


However the correct path is 



/etc/systemd/system/apt-daily-upgrade.timer.d/override.conf






share|improve this answer














share|improve this answer



share|improve this answer








edited Feb 5 at 10:47









PerlDuck

6,74711535




6,74711535










answered Feb 5 at 10:17









Rolf WojtechRolf Wojtech

232




232








  • 1





    Nice finding. IMHO the safest thing is to use sudo systemctl edit apt-daily.timer. This will open an editor with the correct drop-in file.

    – PerlDuck
    Feb 5 at 10:39






  • 1





    Thank you PerlDuck, I edited the Debian Wiki page with your suggestion

    – Rolf Wojtech
    Feb 5 at 12:45














  • 1





    Nice finding. IMHO the safest thing is to use sudo systemctl edit apt-daily.timer. This will open an editor with the correct drop-in file.

    – PerlDuck
    Feb 5 at 10:39






  • 1





    Thank you PerlDuck, I edited the Debian Wiki page with your suggestion

    – Rolf Wojtech
    Feb 5 at 12:45








1




1





Nice finding. IMHO the safest thing is to use sudo systemctl edit apt-daily.timer. This will open an editor with the correct drop-in file.

– PerlDuck
Feb 5 at 10:39





Nice finding. IMHO the safest thing is to use sudo systemctl edit apt-daily.timer. This will open an editor with the correct drop-in file.

– PerlDuck
Feb 5 at 10:39




1




1





Thank you PerlDuck, I edited the Debian Wiki page with your suggestion

– Rolf Wojtech
Feb 5 at 12:45





Thank you PerlDuck, I edited the Debian Wiki page with your suggestion

– Rolf Wojtech
Feb 5 at 12:45











0














I tried Daniel's solution but the upgrade still ran at the wrong times. Turned out there two systemd overrides that are needed:



Used for downloads



/lib/systemd/system/apt-daily.timer - override with /etc/systemd/system/apt-daily.timer.d/override.conf



Used for upgrading



/lib/systemd/system/apt-daily-upgrade.timer - override with /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf






share|improve this answer





















  • 1





    Which version are you on? So you had to override both mentioned timers at the same time?

    – daniel f.
    Jan 23 at 7:48
















0














I tried Daniel's solution but the upgrade still ran at the wrong times. Turned out there two systemd overrides that are needed:



Used for downloads



/lib/systemd/system/apt-daily.timer - override with /etc/systemd/system/apt-daily.timer.d/override.conf



Used for upgrading



/lib/systemd/system/apt-daily-upgrade.timer - override with /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf






share|improve this answer





















  • 1





    Which version are you on? So you had to override both mentioned timers at the same time?

    – daniel f.
    Jan 23 at 7:48














0












0








0







I tried Daniel's solution but the upgrade still ran at the wrong times. Turned out there two systemd overrides that are needed:



Used for downloads



/lib/systemd/system/apt-daily.timer - override with /etc/systemd/system/apt-daily.timer.d/override.conf



Used for upgrading



/lib/systemd/system/apt-daily-upgrade.timer - override with /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf






share|improve this answer















I tried Daniel's solution but the upgrade still ran at the wrong times. Turned out there two systemd overrides that are needed:



Used for downloads



/lib/systemd/system/apt-daily.timer - override with /etc/systemd/system/apt-daily.timer.d/override.conf



Used for upgrading



/lib/systemd/system/apt-daily-upgrade.timer - override with /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf







share|improve this answer














share|improve this answer



share|improve this answer








edited Feb 5 at 13:29









Rolf Wojtech

232




232










answered Jan 23 at 7:45









Niels RaskNiels Rask

12




12








  • 1





    Which version are you on? So you had to override both mentioned timers at the same time?

    – daniel f.
    Jan 23 at 7:48














  • 1





    Which version are you on? So you had to override both mentioned timers at the same time?

    – daniel f.
    Jan 23 at 7:48








1




1





Which version are you on? So you had to override both mentioned timers at the same time?

– daniel f.
Jan 23 at 7:48





Which version are you on? So you had to override both mentioned timers at the same time?

– daniel f.
Jan 23 at 7:48


















draft saved

draft discarded




















































Thanks for contributing an answer to Ask Ubuntu!


  • Please be sure to answer the question. Provide details and share your research!

But avoid …



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f824718%2fubuntu-16-04-unattended-upgrades-runs-at-random-times%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







-

Popular posts from this blog

Human spaceflight

Image
Human spaceflight From Wikipedia, the free encyclopedia Jump to navigation Jump to search "Space traveler" redirects here. For other uses, see Space traveler (disambiguation). @media all and (max-width:720px){.mw-parser-output .tmulti>.thumbinner{width:100%!important;max-width:none!important}.mw-parser-output .tmulti .tsingle{float:none!important;max-width:none!important;width:100%!important;text-align:center}} Apollo 11 crewmember Buzz Aldrin on the Moon, 1969 International Space Station crewmember Tracy Caldwell Dyson views the Earth, 2010 Space Shuttle Discovery heads into space with a crew aboard, STS-121 in 2006 Inside a space suit on the Canadarm, 1993 Human spaceflight (also referred to as crewed spaceflight or manned spaceflight ) is space travel with a crew or passengers aboard the spacecraft. Spacecraft carrying people may be operated directly, by human crew, or it may be e
Read more

Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

Image
0 1 What exactly does the error message beginning with E: mean? I assume it has to do with the file structure on Ubuntu-on-Windows, but what exactly? The following package was automatically installed and is no longer required: os-prober Use 'apt-get autoremove' to remove it. The following extra packages will be installed: libxslt1.1 The following NEW packages will be installed: libxslt1.1 xmlstarlet 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 435 kB of archives. After this operation, 1023 kB of additional disk space will be used. Get:1 http://archive.ubuntu.com/ubuntu/ trusty/main libxslt1.1 amd64 1.1.28-2build1 [145 kB] Get:2 http://archive.ubuntu.com/ubuntu/ trusty/universe xmlstarlet amd64 1.5.0-1 [290 kB]
Read more

File:DeusFollowingSea.jpg

Image
File:DeusFollowingSea.jpg From Wikipedia, the free encyclopedia Jump to navigation Jump to search File File history File usage No higher resolution available. DeusFollowingSea.jpg ‎ (238 × 211 pixels, file size: 12 KB, MIME type: image/jpeg ) Summary [ edit ] Media data and Non-free use rationale Description Cover art of the Deus CD Following Sea Author or copyright owner Deus Source (WP:NFCC#4) rocksucker.co.uk Date of publication 2012 Use in article (WP:NFCC#7) Following Sea Purpose of use in article (WP:NFCC#8) to serve as the primary means of visual identification at the top of the article dedicated to the work in question. Not replaceable with free media because (WP:NFCC#1) n.a. Minimal use (WP:NFCC#3) Low res image used in infobox of the article on the album Respect for commercial opportunities (WP:NFCC#2) n.a. Fair use Fair use of co
Read more