Automatic security updates on Ubuntu: what is enabled, what is not, and the reboot question

Two files and a timer

On Ubuntu, unattended upgrades are configured in two places. One file holds the behaviour: which origins may be installed from, which packages are blocked, how reboots are handled and where mail goes. The other turns the feature on and sets how often it runs, with a number of days where zero disables and one means daily. The actual runs are triggered by systemd timers rather than a cron job. That matters when you check it: look at the timers and the files, not just whether the package is installed. A package that is installed but disabled does nothing, and a timer that is not enabled never fires.

• Behaviour: the 50-numbered file in the apt configuration directory.
• Switch and frequency: the 20-numbered auto-upgrades file.
• Check the apt timers with the timer listing.

What it installs by default

The documented Ubuntu default allows the base release pocket and its security pocket, plus the extended security maintenance pockets where they apply. The updates, proposed and backports pockets are present but commented out. So out of the box you get security fixes and not general bug-fix updates, which is a reasonable default for a server but means non-security package updates need a decision. A repository you add yourself is not eligible just because it is configured; its Origin value must be added to the allowed list. That is the usual reason a third-party package never updates itself. This guide describes Ubuntu. Debian ships a different template, with origins matched on the Debian and Debian-Security labels and the codename-security suite, so read the file on your own Debian server rather than assuming the Ubuntu lines.

• Security pocket only is the conservative default.
• To receive non-security updates, uncomment the updates origin deliberately.
• Third-party repositories need their Origin added to be eligible.

Dry run, logs and mail

The documentation describes a dry run with the verbose option that previews what would happen without changing the system and lists the allowed origins and the packages it would upgrade. Run it as part of any check, because it tells you what the real run will do tonight. Detailed logs of each real run, including the package manager's own log, are written to a directory under the system log directory. Email reports are off unless a recipient is configured, and a mail-sending tool must be set up separately. If you want to know that updates ran, pick one of these routes and test it.

• unattended-upgrade -v --dry-run shows the plan without applying it.
• The log directory holds a record per run.
• No recipient set means no report is sent.

Reboots are a separate decision

Installing a package does not always put the fix into use: a library or kernel update can need a restart before the running system benefits. The tool can mark that a reboot is required, and automatic reboot is off by default. If turned on, it restarts without asking, even with people logged in unless that is changed, at a time you can set. Choose on purpose: an unattended reboot is fine for a stateless server that restarts cleanly and a bad surprise for one that does not. Services are a separate matter from the reboot. Canonical documents that from Ubuntu 24.04 LTS, needrestart runs after updates and restarts the affected services automatically by default, which can restart a production service between any two maintenance windows. Decide whether you want that or a list-only mode, and write the choice down. If you leave reboots off, someone must check for the pending marker regularly and reboot in a window, which is exactly the kind of chore a monthly review exists to do.

• Decide on, off or scheduled for reboots, and write down the choice.
• On Ubuntu 24.04 LTS and later, check the needrestart mode; the default restarts services automatically.
• If reboots are off, a human checks for a pending reboot each month.
• A scheduled reboot can be cancelled with the normal shutdown cancel command.

What a monthly review adds

Automatic updates install packages; they do not tell you what changed, whether your services still work, what the disk is doing or which accounts can log in. The monthly server patch and review service leaves automatic security updates switched on, reads the update log and the pending-reboot state to check they ran, lists what they installed or restarted, applies anything held back or not security-related in a window you approve after a snapshot, checks the services you listed and sends a short report. It is not emergency cover and promises no response time. The one-off Linux baseline job sets automatic security updates up and proves them with a dry run; it is the starting point for the monthly service.