Safely test and run unattended-upgrade on Ubuntu

You will inspect the APT policy, simulate the upgrades selected by unattended-upgrade, and then run them deliberately if the result is acceptable. You will also know where to look when a package is held back or an upgrade is interrupted.

Allow about fifteen minutes for inspection and a dry run. The real upgrade can take longer and can restart services or require a reboot. This guide uses the Ubuntu package version 2.9.1+nmu4ubuntu1 installed on the reference system. Check your own version because command output and configuration options can differ.

You need an Ubuntu or Debian-family system using APT, a shell, and sudo access. The actual installation step requires elevated privileges. Reading the configuration and logs normally does not.

1. Confirm the command and package

Start with read-only checks. The command has no useful --version option on this installation, so query the package instead:

$ command -v unattended-upgrade
/usr/bin/unattended-upgrade
$ dpkg-query -W -f='${Package} ${Version}\n' unattended-upgrades
unattended-upgrades 2.9.1+nmu4ubuntu1
$ unattended-upgrade --help

The help text is the installed command's contract. In this version, --dry-run is described as a simulation that can download packages but does not install them. That is less destructive than a real run, but it can still use network bandwidth and local package-cache space.

2. Inspect what APT is allowed to install

unattended-upgrade is the backend for the APT setting APT::Periodic::Unattended-Upgrade. Its default configuration file is /etc/apt/apt.conf.d/50unattended-upgrades. Read it without editing:

$ sed -n '1,180p' /etc/apt/apt.conf.d/50unattended-upgrades
$ apt-config dump | grep -E 'APT::Periodic::(Update-Package-Lists|Unattended-Upgrade)'

Look first at Unattended-Upgrade::Allowed-Origins. The usual Ubuntu file permits the release and security origins while leaving updates, proposed and backports commented out. Your file may be different. A package is not automatically approved merely because an update exists in an APT repository.

Do not assume that a comment in 50unattended-upgrades is the effective value. A later file in /etc/apt/apt.conf.d/ can add or override settings. apt-config dump shows the merged configuration that APT will use.

3. Simulate the upgrade

Run the simulation with debugging and verbose output so that the decision is recorded in the normal log. This is an elevated command because the program uses APT and its package state:

$ sudo unattended-upgrade --dry-run --debug --verbose

Do not treat a quiet terminal as proof that nothing happened. The manpage names these log files:

$ sudo tail -n 80 /var/log/unattended-upgrades/unattended-upgrades.log
$ sudo tail -n 80 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log

On this installed release, the help output says that the dry run may download packages, but it will not install them. Review the package names, origins and any held-back packages in the log. If the output mentions a lock, another APT process is active. Wait for that process to finish; do not delete lock files.

4. Run approved updates

When the simulation is acceptable, run the same command without --dry-run:

$ sudo unattended-upgrade --verbose

The command returns control after its selected work completes. Verify the exit status immediately:

$ printf 'exit status: %s\n' "$?"
exit status: 0

Status zero means the command completed successfully, not that every available package was upgraded. Packages can remain back because they are outside the allowed origins, blacklisted, held, or not currently installable.

Do not add --no-minimal-upgrade-steps casually. Minimal upgrade steps are the default in this version and split work into smaller interruptible sets. The alternative attempts to upgrade all packages together, which can be less convenient to interrupt.

5. Check the scheduler rather than starting a second job

The normal unattended path is usually driven by apt-daily-upgrade.service, which may be started by apt-daily-upgrade.timer, or by a cron job. Inspect the unit and timer as an ordinary user:

$ systemctl cat apt-daily-upgrade.service apt-daily-upgrade.timer
$ systemctl list-timers apt-daily-upgrade.timer
$ systemctl is-enabled apt-daily-upgrade.timer

On systems using the systemd unit, the service invokes /usr/lib/apt/apt.systemd.daily install. The timer's schedule can include a random delay, so its displayed time is not necessarily the exact start time. If a scheduled run is active, do not launch a manual run alongside it.

If the timer is absent or disabled, inspect /etc/cron.daily/apt and the APT periodic values instead. Enabling a scheduler is a policy change and is outside this runbook. Record the existing state before changing it, and use your distribution's package documentation for the supported enablement method.

6. Recover from an interrupted run

If a run stops with a dpkg error, do not repeatedly retry unattended upgrades. First capture the relevant output:

$ sudo tail -n 120 /var/log/unattended-upgrades/unattended-upgrades.log
$ sudo tail -n 120 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
$ dpkg --audit

Resolve the specific package or repository problem using your normal change process. After an interrupted dpkg operation, the installed configuration supports an automatic repair setting named Unattended-Upgrade::AutoFixInterruptedDpkg, enabled by default in the shipped file. Do not enable extra recovery behaviour blindly: inspect the package manager error first and confirm what a repair will do.

When the underlying problem is fixed, start with another dry run. If it reports a dpkg configuration error, follow the named package's repair instructions before attempting installation again. If the host is running a critical service, check its status and application health after packages are installed.