Unattended upgrades on Ubuntu. And proof they really run.

On a standard Ubuntu server, the package is installed by default and security updates are switched on. Custom and minimal images are where it goes wrong.

Setting up a new server? Deploy a Lite 2, run the checker below in its first minute, and you know your updates are real from day one. It bills by the hour, so testing this costs cents.

echo "installed $(dpkg -s unattended-upgrades >/dev/null 2>&1 && echo yes || echo no)"
for t in apt-daily.timer apt-daily-upgrade.timer; do echo "timer $t $(systemctl is-enabled $t 2>&1)"; done
apt-config dump APT::Periodic | sed 's/^/periodic /'
echo "kernels $(ls /boot 2>/dev/null | grep -c '^vmlinuz')"
echo "reboot $([ -f /var/run/reboot-required ] && echo yes || echo no)"
echo "lastrun $(sudo grep -h 'Starting unattended upgrades script' /var/log/unattended-upgrades/unattended-upgrades.log 2>/dev/null | tail -n 1 | cut -c1-10)"
echo "today $(date -u +%F)"

Click “Load our server before the fix” to see the real output that started this tutorial: everything looks switched on, and nothing has ever run.

Both timers were links to /dev/null, created when the image was built. That’s what masking is: the unit is linked to /dev/null so it can’t be started, even by hand. It shows up on other images too.

We also found an empty /boot. That server starts its kernel from outside, so apt has no kernel to update. Kernel fixes on a server like that come from the platform, not from you.

1. 01

   Install the package

   sudo apt update
   sudo apt install unattended-upgrades

2. 02

   Switch on the schedule

   sudo dpkg-reconfigure -plow unattended-upgrades

   Answer Yes. Then check cat /etc/apt/apt.conf.d/20auto-upgrades shows both values as “1” (every day).

3. 03

   Make sure the timers can run

   sudo systemctl unmask apt-daily.timer apt-daily-upgrade.timer
   sudo systemctl enable --now apt-daily.timer apt-daily-upgrade.timer
   systemctl list-timers 'apt-daily*'

   The last command should list both timers with a time under NEXT. If they weren’t masked, the first line does nothing.

4. 04

   Dry run

   sudo unattended-upgrade -v --dry-run

   Shows which sources it allows and what it would install, without installing anything.

5. 05

   First real run

   sudo unattended-upgrade -v

   This creates the log. Ours said “No packages found that can be upgraded unattended”, which was correct: we were already up to date on security fixes.

On our 22.04 server the timers fire at 06:00 and 18:00 for the download and 06:00 for the install, each with a random delay (up to 12 hours and 60 minutes), so thousands of servers don’t hit the mirrors at once. A missed run catches up after boot.

• By default: security updates. The -updates, -proposed and -backports lines are commented out.
• Our proof: nano and tmux had newer versions waiting in jammy-updates. The run skipped both, because neither was a security fix.
• Other repositories are ignored. Adding a repo does not make unattended-upgrades consider it. You have to list it.

Adding Docker’s repository

Docker’s repository identifies itself as Origin: Docker, with the Ubuntu codename as the suite, so the line is:

Unattended-Upgrade::Allowed-Origins {
    // ...the existing lines...
    "Docker:${distro_codename}";
};

Holding a package back

Unattended-Upgrade::Package-Blacklist {
    "postgresql-16$";
};

Entries are regular expressions, so end the name with $ to match only that package. Holding back one package can also block updates that depend on it.

Want an email instead? Set Unattended-Upgrade::Mail to your address. It needs a working mail client on the server, which most VPSes don’t have out of the box.