UNATTENDED-UPGRADES(7) Savvy Admin Process Reference UNATTENDED-UPGRADES(7)

NAME

unattended-upgrades — Ubuntu's automatic security updates: a daily systemd timer refreshes the package lists and runs unattended-upgrade, which installs packages from the allowed origins (the security pockets by default) and can reboot the machine if you let it.

kind: system daemon · package: unattended-upgrades (installed by default on Ubuntu) · binary: /usr/bin/unattended-upgrade, a Python 3 script run daily by apt-daily-upgrade.service through /usr/lib/apt/apt.systemd.daily; ps truncates the name to unattended-upgr. A second, long-lived python3 process, unattended-upgrade-shutdown --wait-for-signal, is the unattended-upgrades.service that waits to finish a run cleanly at shutdown · config: /etc/apt/apt.conf.d/20auto-upgrades (on/off and frequency), /etc/apt/apt.conf.d/50unattended-upgrades (origins, blacklist, reboot, mail), apt-daily.timer and apt-daily-upgrade.timer (schedule) · updated 2026-10-20

SAFE TO KILL?

VERDICTNO. Not while dpkg is running underneath it: killing it mid-install leaves half-configured packages and a dpkg --configure -a at best. Wait for the lock to clear (the diagnose commands show who holds it and what is being installed), or stop the timers if you do not want it on this machine. The idle shutdown waiter can be stopped with systemctl stop unattended-upgrades, but it comes back at the next boot and it does no harm.

SYMPTOMS

· apt or dpkg fails with 'Could not get lock /var/lib/dpkg/lock-frontend' first thing in the morning: the apt-daily-upgrade run is in progress
· python3 unattended-upgrade at high CPU with dpkg and apt children for minutes: it is installing updates
· the server rebooted by itself at a fixed hour: Unattended-Upgrade::Automatic-Reboot is true and Automatic-Reboot-Time is set
· a python3 process named unattended-upgrade-shutdown that never exits: the shutdown waiter, idle and normal

DIAGNOSE

$ systemctl list-timers apt-daily.timer apt-daily-upgrade.timer when the package-list refresh and the upgrade run last fired and when they fire next; both carry a random delay, so the hour varies from day to day$ sudo fuser -v /var/lib/dpkg/lock-frontend /var/lib/apt/lists/lock who holds the apt and dpkg locks right now; an unattended-upgrade entry means wait, anything else means a stuck apt of your own$ tail -n 20 /var/log/unattended-upgrades/unattended-upgrades.log what the last run decided: allowed origins, packages found, packages installed, and whether a reboot was requested$ apt-config dump APT::Periodic Update-Package-Lists and Unattended-Upgrade at 1 means on, daily; 0 means off. This reads the effective value, whichever file sets it$ grep -vE '^\s*(//|$)' /etc/apt/apt.conf.d/50unattended-upgrades the live configuration without the comments: Allowed-Origins, Package-Blacklist, Automatic-Reboot and Mail are the lines that matter$ ps -o pid,user,etime,args -C unattended-upgr distinguishes a running upgrade (/usr/bin/unattended-upgrade, minutes old) from the idle shutdown waiter (unattended-upgrade-shutdown --wait-for-signal, hours or days old)$ sudo unattended-upgrade -v --dry-run shows exactly what the next run would install, without installing it

FIX

1. Watch the run finish instead of fighting the lock. The dpkg log shows package by package progress. On a slow VM a kernel update plus initramfs rebuild takes a few minutes; the lock clears by itself.

$ tail -f /var/log/unattended-upgrades/unattended-upgrades-dpkg.log

2. Move the run to an hour nobody is working. In the override put a [Timer] section with an empty OnCalendar= line (to clear the packaged schedule) followed by OnCalendar=*-*-* 03:00 and a short RandomizedDelaySec=. The Ubuntu docs also suggest Persistent=false in the same override if you do not want a missed run to catch up at the next boot.

$ sudo systemctl edit apt-daily-upgrade.timer

3. Keep the updates, lose the surprise reboots. Unattended-Upgrade::Automatic-Reboot is "false" by default; if you enable it, set Unattended-Upgrade::Automatic-Reboot-Time to a quiet hour ("03:30"), and set Unattended-Upgrade::Mail with MailReport "on-change" or "only-on-error" so you hear about it.

4. Turn it off on machines you update by hand. Set both APT::Periodic::Update-Package-Lists "0" and APT::Periodic::Unattended-Upgrade "0" in /etc/apt/apt.conf.d/20auto-upgrades; sudo dpkg-reconfigure -plow unattended-upgrades asks the same question (unattended-upgrades/enable_auto_updates) interactively. Leaving security updates off on an internet-facing box is a decision, not a default.

IMPOSTORS

$ ps -o pid,user,args -C unattended-upgr both legitimate forms run as root as /usr/bin/python3 /usr/bin/unattended-upgrade or /usr/share/unattended-upgrades/unattended-upgrade-shutdown; a different user or a script under /tmp is not this package

DISTRIBUTIONS

ubuntu Installed and enabled by default on Server and Desktop; Allowed-Origins covers the release pocket plus -security and the ESM security pockets; logs under /var/log/unattended-upgrades/. Desktop also runs update-notifier, which is a different thing.

APPLIES TO

unattended-upgrades 2.x on Ubuntu 20.04 and later with systemd timers; configuration keys from the Ubuntu Server docs on 2026-10-20.

SOURCES

1. Ubuntu Server docs — Automatic updates, fetched 2026-10-20
Machine-readable: /process/unattended-upgrades.json · changelog 2026-10-20: first version

Ubuntu 22.04 · unattended-upgrades 2.8ubuntu1 · systemd 249 (WSL2 with systemd; timers, logs, config and process checks; the dry run and the timer override need root and were taken from the docs) 2026-10-20 UNATTENDED-UPGRADES(7)