Unattended upgrades not upgrading: check these in order

apt list --upgradable shows a screen of packages, unattended-upgrades has been installed for months, and little seems to change. Before assuming it is broken, check what it is configured to do. The defaults cover less than the name suggests.

By David Kabel · Updated 2026-09-23 · 11 min read

Defaults on Debian 13 and Ubuntu 24.04

We checked the defaults against Debian 13 with unattended-upgrades 2.12 and apt 3.0.3, and Ubuntu 24.04 LTS with unattended-upgrades 2.9.1+nmu4ubuntu1 and apt 2.8.3.

The checklist

1. It is switched onRun apt-config dump | grep Periodic. You want Update-Package-Lists "1" and Unattended-Upgrade "1". Both default to 0 in apt's daily script, so a missing 20auto-upgrades means nothing runs, and APT::Periodic::Enable "0" in any file switches everything off. sudo dpkg-reconfigure -plow unattended-upgrades writes the file if it never existed, but not if someone deleted it. In that case ucf prints Not replacing deleted config file and leaves it missing. Run it as sudo UCF_FORCE_CONFFMISS=1 dpkg-reconfigure -plow unattended-upgrades, or copy /usr/share/unattended-upgrades/20auto-upgrades back into place.
2. The timers firesystemctl list-timers apt-daily.timer apt-daily-upgrade.timer shows the last and next run, and journalctl -u apt-daily-upgrade.service shows what happened. A disabled or masked timer means no runs, whatever the configuration says.
3. apt itself is healthyBefore anything else, apt's daily script runs apt-get check, which takes the dpkg lock, and exits quietly if it fails. That includes the state an interrupted install leaves behind, where apt will not take its lock until someone runs dpkg --configure -a. One power cut mid-upgrade can stop every later run without a word. Run sudo apt-get check yourself. If it complains, sudo dpkg --configure -a finishes the interrupted install and sudo apt-get -f install repairs broken dependencies.
4. The package comes from an allowed originEach run in the log starts with Starting unattended upgrades script, followed by Allowed origins are:. Compare that list with apt-cache policy <package>, which shows which archive the new version sits in. On Ubuntu a version in noble-updates is not allowed by default, and neither is anything from Docker, a PPA or any other repository you added.
5. Run it by handsudo unattended-upgrade --dry-run --debug simulates a run and writes its reasoning to /var/log/unattended-upgrades/unattended-upgrades.log. The directory is readable by root and the adm group only. A dry run cannot list kept-back packages, and says so. For that, read the log of a real run.
6. Nothing is on holdapt-mark showhold lists held packages. unattended-upgrades leaves them alone, and a real run, not a dry run, logs Package <name> is marked to be held back.
7. The blacklist is not too broadPackage-Blacklist entries are Python regular expressions matched from the start of the name, so "linux-" blocks every kernel package. A blacklisted package also blocks upgrades of packages that depend on it. A real run logs Package <name> is blacklisted. for the package itself, but only is kept back because a related package is kept back for the packages that depend on it.
8. No configuration-file prompt is waitingIf an upgrade would ask whether to keep your edited configuration file, the package is skipped and the log says has conffile prompt and needs to be upgraded manually. Upgrade it by hand and answer the question.
9. It does not need a removalunattended-upgrades installs new dependencies only from allowed origins and never removes an installed package to complete an upgrade. apt upgrade also skips an upgrade that needs a removal. Ubuntu 24.04's apt lists it under "kept back", and Debian 13's apt 3.0 lists it under "Not upgrading". Unlike unattended-upgrades, apt upgrade does install new dependencies from any configured repository. Read what sudo apt full-upgrade proposes to remove before you accept it.
10. Phasing only holds back apt upgradeUbuntu releases some updates in stages. APT decides per machine from the package name, version and /etc/machine-id, and apt upgrade holds the new version back until your share comes up. apt policy <package> shows it as, for example, (phased 20%). Security updates are never phased. APT has done this since Ubuntu 21.04 and apt 2.1.16. unattended-upgrades does not apply phasing. In our test it installed an update phased at 0% as soon as its origin was allowed. Phasing can explain why apt upgrade holds something back, but it does not explain why unattended-upgrades does. If you allow -updates, phased updates reach the machine straight away.
11. Nothing else holds the lockA run that collides with you or a configuration tool using apt gives up until the next day. If unattended-upgrades itself meets the lock, it logs Lock could not be acquired (another package manager running?). The reverse often happens after boot. The timers are persistent, so a run missed while the machine was off starts after it comes up, subject to the same random delay. apt waits for it to finish, and apt-get stops at once with Could not get lock.

Letting it install more than security updates

The unattended-upgrades README recommends putting changes in a separate file that sorts after 50unattended-upgrades, so package updates to the shipped file do not collide with your edits. Lists in a later file add to the stock list rather than replacing it:

// /etc/apt/apt.conf.d/52unattended-upgrades-local
// Ubuntu: also install bug-fix updates, not only security
Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-updates";
};

// Debian uses Origins-Pattern instead:
// Unattended-Upgrade::Origins-Pattern {
//         "origin=Debian,codename=${distro_codename}-updates";
// };

For a third-party repository, find its Origin in the repository's InRelease file under /var/lib/apt/lists/ or in apt-cache policy output, and add it the same way. Decide separately whether you want vendor packages updating themselves at six in the morning.

Run schedule and run time

apt-daily.timer, which refreshes package lists, fires at 06:00 and 18:00 with up to 12 hours of random delay. apt-daily-upgrade.timer installs at 06:00 with up to 60 minutes of delay. The APT::Periodic values are intervals in days, checked against stamp files by calendar date, so each step still happens once a day and a value below one day does not make it run more often. To run twice a day, set the value to always and add a second OnCalendar line. To move the run:

sudo systemctl edit apt-daily-upgrade.timer

# in the editor that opens:
[Timer]
OnCalendar=
OnCalendar=*-*-* 03:00
RandomizedDelaySec=30m

There is no typical run time to quote, because it depends on what is waiting. By default the upgrade runs in minimal steps, which the shipped configuration describes as a bit slower but safe to interrupt at shutdown. To measure your own, compare the log timestamp on Starting unattended upgrades script with the one on the last line of each run.

Reboots and kernel updates

A new kernel package installs like any other, and the running kernel stays as it was until the machine reboots or live patching applies the fix. unattended-upgrades does not decide whether a reboot is needed. It looks for /var/run/reboot-required and, with automatic reboot on, reboots when that file exists:

// /etc/apt/apt.conf.d/52unattended-upgrades-local
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";

unattended-upgrades passes the time to shutdown as given, and it uses the server's time zone. The default is now, which means straight after the run, and it reboots with users logged in unless you set Automatic-Reboot-WithUsers to false. On both Debian and Ubuntu, unattended-upgrades itself installs a kernel hook, /etc/kernel/postinst.d/unattended-upgrades, that writes the flag file whenever a kernel package is installed. Ubuntu's update-notifier-common adds another. On Ubuntu, both skip it for kernels while Canonical Livepatch is enabled. The flag file covers kernels only. Running services keep the old copy of a library in memory until they restart. From Ubuntu 24.04, needrestart restarts affected services automatically by default when apt runs it. Debian's version defaults to asking, and when it runs without a terminal, as during an unattended upgrade, it only lists them.

"Unattended-upgrade in progress during shutdown"

The package ships a small service, unattended-upgrades.service, that does nothing until the machine shuts down. If an upgrade is running at that moment, it sends the upgrade a stop signal, writes this message to unattended-upgrades-shutdown.log and to the shutdown splash screen where there is one, and holds shutdown while the current step finishes, for up to 25 minutes by default. Let it finish. Cutting power mid-install can leave dpkg half-configured, and from then on apt installs nothing, the daily job included, until someone runs sudo dpkg --configure -a, which is step three above.

InstallOnShutdown does the opposite and installs updates during shutdown instead of in the background. It is off by default, makes every shutdown slower, and the shipped configuration advises raising logind's InhibitDelayMaxSec if you enable it. On a server that rarely shuts down it is the wrong tool.

Automatic security updates are step five of securing a new VPS. The checklist above tells you whether step five is happening.

Gotchas

• A healthy-looking timer that does nothing. The official Ubuntu 24.04 Docker image ships /etc/apt/apt.conf.d/docker-disable-periodic-update containing APT::Periodic::Enable "0". The timers were listed and enabled, and apt-daily-upgrade.service finished with "Deactivated successfully", yet the run wrote no stamp file or log line. Any image or configuration tool can do the same, so check apt-config dump | grep Periodic for an Enable line before trusting the timer.
• Deleting 20auto-upgrades is sticky. After we removed the file, dpkg-reconfigure -plow unattended-upgrades printed Not replacing deleted config file and left it missing, because ucf treats a deleted configuration file as the administrator's choice. UCF_FORCE_CONFFMISS=1 in front of the command recreated it.
• An interrupted dpkg looks like a lock problem. We killed dpkg during a package's configure step. From then on apt-daily-upgrade.service still reported success and nothing reached the unattended-upgrades log, and a manual unattended-upgrade logged Lock could not be acquired (another package manager running?) although nothing else was running. Its built-in repair, AutoFixInterruptedDpkg, never ran, because it only runs after the lock is taken. sudo dpkg --configure -a fixed it. Setting APT::Periodic::Verbose "1" makes the daily job write error encountered in cron job with "apt-get check" to the journal instead of failing silently.
• Phased updates do not slow unattended-upgrades down. APT deferred a test update phased at 0%, but unattended-upgrades installed it on both Debian 13 and Ubuntu 24.04 as soon as its origin was allowed. On Debian it also scheduled a 50% update that APT was deferring for that machine. If you add -updates on Ubuntu, expect updates before apt upgrade would offer them.
• Automatic reboot follows the flag file, not the run. With Automatic-Reboot "true" and /var/run/reboot-required present, unattended-upgrades called shutdown -r at the end of a run that had installed nothing. A kernel you installed by hand earlier in the day therefore gets its reboot at the next unattended run.

How this was tested. On 23 September 2026 we worked through every step above in Docker containers running systemd. One ran Debian 13 from the debian:trixie image with unattended-upgrades 2.12 and apt 3.0.3, and one ran Ubuntu 24.04.5 LTS with unattended-upgrades 2.9.1+nmu4ubuntu1 and apt 2.8.3. A local repository of dummy packages produced a hold, blacklist hits, a configuration-file prompt, new dependencies from allowed and disallowed origins, an upgrade needing a removal, and updates phased at 0% and 50%. We killed dpkg mid-install, held the dpkg lock, fired the timers, stopped unattended-upgrades.service during a slow install to simulate shutdown, installed a real Debian kernel package, and replaced shutdown with a logging stub to test automatic reboot. Not tested: a real reboot or power cut, real phased updates from the Ubuntu archive, ESM origins, mail reports, or what a fresh Ubuntu Server installation ships, since the Docker images do not include unattended-upgrades.

Sources

1. unattended-upgrades README, unattended-upgrades project, GitHub
2. unattended-upgrade(8) manual page, Debian 13, unattended-upgrades 2.12
3. unattended-upgrades 2.12 source: 50unattended-upgrades.Debian, unattended-upgrade, unattended-upgrade-shutdown, debian/templates, Debian
4. 50unattended-upgrades.Ubuntu, unattended-upgrades 2.9.1+nmu4ubuntu1, Ubuntu
5. apt 3.0.3 source: apt.systemd.daily, apt-daily.timer, apt-daily-upgrade.timer, Debian
6. UnattendedUpgrades (PeriodicUpdates), Debian Wiki, last modified 10 July 2026
7. stable-updates, Debian Wiki
8. Automatic updates, Ubuntu Server documentation
9. About apt upgrade and phased updates, Ubuntu Server documentation, updated 26 June 2026
10. apt_preferences(5): Phased Updates, Debian 13
11. apt(8) and apt-mark(8), Debian 13
12. systemd.timer(5), Debian 13