---
title: "Unattended upgrades not upgrading: check these in order"
description: "Why unattended-upgrades installs less than you expect, in diagnostic order: timers, 20auto-upgrades, allowed origins, holds, phasing, locks and reboots."
source: "https://wardio.net/guides/unattended-upgrades-not-working/"
---

**Patching**

# 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

**The short answer**

Work down the list. Confirm `apt-daily-upgrade.timer` fires and `/etc/apt/apt.conf.d/20auto-upgrades` sets both periodic values to "1". Then read the allowed origins. Ubuntu installs security updates only and Debian adds point releases. Neither touches `-updates` or third-party repositories unless you add them. Run `sudo unattended-upgrade --dry-run --debug` and read `/var/log/unattended-upgrades/`. Holds, blacklist entries, configuration-file prompts, new dependencies and dpkg locks explain most of the rest.

## 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.

|  | Debian 13 | Ubuntu 24.04 |
| --- | --- | --- |
| Installed out of the box | Depends on how the system was installed; the Debian wiki warns it may be missing | Yes, with security updates enabled |
| 20auto-upgrades | Written with both values set to "1" when the package is installed, because its setup question defaults to yes | Present, both values "1" |
| Installs from | trixie-security, plus the trixie release itself, which only changes at point releases | noble-security, ESM security where available, and the release pocket for new dependencies |
| Ignores by default | trixie-updates, backports, every third-party repository | noble-updates, backports, proposed, PPAs, every third-party repository |
| Schedule | Upgrade timer at 06:00 server time, plus up to 60 minutes random delay | Same |
| Automatic reboot | Off | Off |

## The checklist

1.  **It is switched on**: Run `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 fire**: `systemctl 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 healthy**: Before 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 origin**: Each 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 hand**: `sudo 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 hold**: `apt-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 broad**: `Package-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 waiting**: If 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 removal**: unattended-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 upgrade**: Ubuntu 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 lock**: A 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](/guides/kernel-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](/guides/secure-a-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](https://github.com/mvo5/unattended-upgrades/blob/master/README.md), unattended-upgrades project, GitHub
2.  [unattended-upgrade(8) manual page](https://manpages.debian.org/trixie/unattended-upgrades/unattended-upgrade.8.en.html), Debian 13, unattended-upgrades 2.12
3.  [unattended-upgrades 2.12 source: 50unattended-upgrades.Debian, unattended-upgrade, unattended-upgrade-shutdown, debian/templates](https://sources.debian.org/src/unattended-upgrades/2.12/), Debian
4.  [50unattended-upgrades.Ubuntu, unattended-upgrades 2.9.1+nmu4ubuntu1](https://git.launchpad.net/ubuntu/+source/unattended-upgrades/tree/data/50unattended-upgrades.Ubuntu?h=applied/ubuntu/noble-devel), Ubuntu
5.  [apt 3.0.3 source: apt.systemd.daily, apt-daily.timer, apt-daily-upgrade.timer](https://sources.debian.org/src/apt/3.0.3/debian/), Debian
6.  [UnattendedUpgrades (PeriodicUpdates)](https://wiki.debian.org/UnattendedUpgrades), Debian Wiki, last modified 10 July 2026
7.  [stable-updates](https://wiki.debian.org/StableUpdates), Debian Wiki
8.  [Automatic updates](https://documentation.ubuntu.com/server/how-to/software/automatic-updates/), Ubuntu Server documentation
9.  [About apt upgrade and phased updates](https://documentation.ubuntu.com/server/explanation/software/about-apt-upgrade-and-phased-updates/), Ubuntu Server documentation, updated 26 June 2026
10.  [apt\_preferences(5): Phased Updates](https://manpages.debian.org/trixie/apt/apt_preferences.5.en.html), Debian 13
11.  [apt(8)](https://manpages.debian.org/trixie/apt/apt.8.en.html) and [apt-mark(8)](https://manpages.debian.org/trixie/apt/apt-mark.8.en.html), Debian 13
12.  [systemd.timer(5)](https://manpages.debian.org/trixie/systemd/systemd.timer.5.en.html), Debian 13

## Questions

### How often do unattended upgrades run?

Once a day by default. On Debian and Ubuntu, apt-daily-upgrade.timer fires at 06:00 server time with up to 60 minutes of random delay, and apt-daily.timer, which refreshes package lists, fires at 06:00 and 18:00 with up to 12 hours of delay. The APT::Periodic values in 20auto-upgrades are intervals in days, so with the default of 1 each step still happens once per day. Because the timers are persistent, a run missed while the machine was off happens shortly after the next boot.

### How do I enable unattended upgrades?

Install the unattended-upgrades package, then run sudo dpkg-reconfigure -plow unattended-upgrades and answer yes. That writes /etc/apt/apt.conf.d/20auto-upgrades with APT::Periodic::Update-Package-Lists and APT::Periodic::Unattended-Upgrade both set to "1". If the file was deleted after installation, dpkg-reconfigure will not recreate it unless you run it as sudo UCF\_FORCE\_CONFFMISS=1 dpkg-reconfigure -plow unattended-upgrades. Check the result with apt-config dump, and test with sudo unattended-upgrade --dry-run --debug. On Ubuntu Server both steps are already done after installation.

### Why are packages kept back and not upgraded automatically?

unattended-upgrades skips a package when the new version is in a repository that is not an allowed origin, such as Ubuntu -updates or a third-party repository; when it is held with apt-mark or matches Package-Blacklist; when its upgrade would ask about a changed configuration file; or when it needs a package removed or a dependency from a disallowed origin. On Ubuntu, phased updates hold non-security updates back from apt upgrade for a while, but in our tests unattended-upgrades itself ignored phasing.

### How long does an unattended upgrade take?

There is no fixed duration. It depends on how many packages are waiting and what their install scripts do. By default it installs in minimal steps, which is slightly slower but can be interrupted safely. To see your own timings, compare the start and finish lines in /var/log/unattended-upgrades/unattended-upgrades.log, or read journalctl -u apt-daily-upgrade.service.

### What does "unattended-upgrade in progress during shutdown" mean?

You shut down while an upgrade was running. The unattended-upgrades shutdown helper asks the running upgrade to stop after its current step and delays shutdown while it finishes, for up to 25 minutes by default. Let it finish rather than cutting power. If dpkg is interrupted anyway, run sudo dpkg --configure -a, because until you do apt installs nothing, and the daily job stops at its first check.

**Not sure your servers are patching?**

The free server review checks whether updates get applied and what gets skipped. [Pricing](/pricing/).

[Free server review](/contact/)