How to control when daily automatic update happens?

jp flag

On Ubuntu server 22.04, how do you control when the automatic daily update check happens?

One of my servers doesn't have internet access during certain (known) periods. When the automatic update happens it hangs forever if there is no internet access. Even with internet access resumes, the update stays hung and I have to manually kill it then do a manual update.

I'd like to keep the automatic update feature, but I need to limit it to certain days/hours.

I found this thread which claims that for 18.04 one should set up a chron job to toggle a couple settings:

How can I ban Software Updater from checking for updates at certain times of day or certain days of week?

But, the settings it specifies don't exist:

# gsettings get download-updates 
No such schema “”

# gsettings get allow-updates 
No such schema “”
Grant E. avatar
jp flag
Thanks. I should have guessed this had been assimilated by the borg. Presumably I should set up a chron job to stop/start apt-daily-upgrade.timer
user535733 avatar
cn flag
It would be much simpler to simply adapt the existing timer to your needs. It's not difficult.
cn flag

apt daily timers are run by systemd:

me@me:~$ systemctl list-timers | grep apt
Wed 2022-11-30 00:42:17 CST 14h left      Tue 2022-11-29 07:57:32 CST 2h 22min ago  apt-daily.timer                apt-daily.service
Wed 2022-11-30 06:41:41 CST 20h left      Tue 2022-11-29 07:57:32 CST 2h 22min ago  apt-daily-upgrade.timer        apt-daily-upgrade.service

Note that there are two jobs:

  • apt-daily = apt update
  • apt-daily-upgrade = unattended upgrades = apt upgrade for security upgrades only (configurable at /etc/apt/apt.conf.d/50unattended-upgrades)

Next, let's locate where the apt-daily timer is located:

me@me:~$ systemctl status apt-daily.timer | grep loaded
     Loaded: loaded (/lib/systemd/system/apt-daily.timer; enabled; preset: enabled)

Since the file is located in /lib/systemd, it will be overwritten when the apt package gets updated. So we cannot make changes directly to that file.

Instead, let's write an override file in /etc.

First, we copy the file into /etc:

sudo cp /lib/systemd/system/apt-daily.timer /etc/systemd/system/

Next, we edit the file. Here's the original:

Description=Daily apt download activities

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


Look at the timer section. That's the part you want to edit to match times when your system is online.

For example, something like this might be more reasonable for a machine that get shut down daily. The apt-daily job will run sometime between 5 and 60 minutes after startup.


Overriding the timer of the second job (apt-daily-upgrade) is left as an exercise for the student.

Grant E. avatar
jp flag
Brilliant! I'm not a native systemd speaker, and didn't know about override files. I was about to install chron and set up a chron job to "stop/start" the timer to implement a "blocked" period, but an override file that blocks out the times when there is no network access is obviously the right answer. [don't tell anybody I'm learning how systemd timers work...]
Grant E. avatar
jp flag
I copied the file as shown above and manually edited it, but I couldn't figure out how to get systemd to notice the new override file. After a bit of googling, I did: `systemctl edit --full apt-daily.timer` Answered 'y' so that it would overwrite the old override file in /etc, re-did the edits, saved, exited the editor, and presto -- systemctl status showed the new file and expected trigger time.
jp flag

The short answer is:

# systemctl edit --full apt-daily.timer

That will copy the existing file to /etc/systemd/... and open it in $EDITOR. Make changes to OnCalendar= and RandomizedDelaySec= lines, save file, exit editor. Using systemctl edit will trigger loading of the new/edited file after editor exits.

# systemctl status apt-daily.timer

The above should show new file in use (/etc/systemd/...) and expected trigger time.

Repeat above with apt-daily-upgrade.timer:

# systemctl edit --full apt-daily-upgrade.timer


I sit in a Tesla and translated this thread with Ai:


Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.