Unattended-Upgrades on Ubuntu Server 24.04: Defaults, Origins, Reboots, Reports and Logs

Ubuntu Server installs security updates on its own, through the unattended-upgrades package. Many administrators never look further than that, and then are surprised that a third-party repository never updated, or that a kernel fix waited weeks for a reboot. This guide walks through what Ubuntu 24.04 LTS does by default and how to tune it, based on the Ubuntu Server documentation and the unattended-upgrade(8) manual.

What happens out of the box

• unattended-upgrades is installed by default, and automatic installation of security updates is enabled, including Expanded Security Maintenance (ESM) when the system has it.
• It runs once per day. Two systemd timers, apt-daily.timer (refresh package lists) and apt-daily-upgrade.timer (install), trigger it with a random delay.
• /etc/apt/apt.conf.d/20auto-upgrades switches it on or off; /etc/apt/apt.conf.d/50unattended-upgrades holds the behaviour.
• Every run is logged to /var/log/unattended-upgrades/unattended-upgrades.log, and the dpkg output to unattended-upgrades-dpkg.log in the same directory.
• It does not reboot by default, even when an update asks for it.

Check that it is actually running

cat /etc/apt/apt.conf.d/20auto-upgrades
# expected:
# APT::Periodic::Update-Package-Lists "1";
# APT::Periodic::Unattended-Upgrade "1";

# effective settings after all apt.conf.d files are merged
apt-config dump | grep -E 'Periodic|Unattended-Upgrade'

# when the timers last ran and will run next
systemctl list-timers 'apt-daily*'

# what the last runs did
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log

The values in 20auto-upgrades are a number of days: 1 means daily and 0 disables the step.

Where updates come from: Allowed-Origins

The default Allowed-Origins list in 50unattended-upgrades covers the release itself, its -security pocket and the two ESM security pockets. The -updates line (regular bug-fix updates) is commented out, as are -proposed and -backports:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
//  "${distro_id}:${distro_codename}-updates";
};

The most common surprise: adding a repository to apt does not make unattended-upgrades use it. Packages from a PPA or a vendor repository (database, container runtime, language runtime) stay at their old version until you update them by hand or add their origin. The Origin value is in the repository's InRelease file, which apt stores under /var/lib/apt/lists/:

grep -h '^Origin:' /var/lib/apt/lists/*InRelease | sort -u

# then, for example, for a Launchpad PPA:
#   "LP-PPA-canonical-server-server-backports:${distro_codename}";

Only add origins you trust to publish safe updates, because they will then install without a person watching.

Keeping specific packages back

Unattended-Upgrade::Package-Blacklist takes Python regular expressions that are matched from the start of the package name. "linux-" blocks every package starting with linux-, and "libc6$" blocks exactly libc6:

Unattended-Upgrade::Package-Blacklist {
    "mariadb-server";
    "libc6$";
};

Use this sparingly. The documentation warns that blocking a package can also hold back other updates that depend on it, and a held-back security fix is still an open vulnerability. Block a package only while you prepare a manual upgrade, not permanently.

Automatic reboots in a fixed window

When an update requests a reboot, a flag file appears at /var/run/reboot-required. unattended-upgrades acts on it only if you allow it:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

The time is passed to shutdown and uses the server's local time zone, so check timedatectl first. A server on UTC that reboots at 02:00 restarts at 05:00 Riyadh time. A scheduled reboot can be cancelled with sudo shutdown -c. Separately, on Ubuntu 24.04 the needrestart tool restarts services that use updated libraries automatically after each run, so plan for those restarts too.

Email reports

Unattended-Upgrade::Mail "ops@example.com";
Unattended-Upgrade::MailReport "only-on-error";

MailReport accepts always, only-on-error or on-change (the default). Mail is only sent if the server has a working local mail setup that can reach a mail server. Test it, or the reports silently go nowhere.

Dry runs and debugging

sudo unattended-upgrade --dry-run -v
sudo unattended-upgrade --dry-run --debug

A dry run shows the allowed origins, the block list and which packages would be upgraded, without changing anything. --debug writes extra detail to the log. Use it after every configuration change, especially after adding an origin.

Changing when it runs

To move the install run into a quieter hour, override the timer rather than editing the packaged unit. An empty OnCalendar= line clears the existing schedule first, as described in systemd.timer(5):

# same drop-in file that 'systemctl edit' would create
sudo mkdir -p /etc/systemd/system/apt-daily-upgrade.timer.d
printf '[Timer]\nOnCalendar=\nOnCalendar=*-*-* 01:30\n' | sudo tee /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf
sudo systemctl daemon-reload
systemctl list-timers 'apt-daily*'

If a server was off at the scheduled time, the timer catches up at the next boot, which can briefly lock apt. Ubuntu documents Persistent=false in the same override to stop that catch-up behaviour.

Common pitfalls

• Assuming third-party repositories are covered. They are not, unless you add their origin.
• Leaving Automatic-Reboot off and never rebooting by hand, so new kernels never load.
• Configuring Mail without a working mail setup.
• A full /boot or root disk stopping upgrades. The upstream option Remove-Unused-Kernel-Packages exists to remove old kernels; check that it is not disabled.
• Packages kept back because dpkg would ask about a changed configuration file. The tool checks for these prompts and skips such packages, so read the log for anything kept back.

What you should do

• Confirm on each server that both 20auto-upgrades values are 1 and that the timers ran recently.
• List your third-party repositories and decide, one by one, whether to add their origin or to update them in a planned window.
• Choose a reboot policy: automatic at a fixed local time, or manual in a weekly window, but not "never".
• Turn on email reports or ship /var/log/unattended-upgrades/ to your monitoring, and review kept-back packages.
• Run unattended-upgrade --dry-run -v after every change to 50unattended-upgrades.

Sources

• documentation.ubuntu.com/server/how-to/software/automatic-updates
• manpages.ubuntu.com/manpages/noble/en/man8/unattended-upgrade.8.html
• manpages.ubuntu.com/manpages/noble/en/man5/systemd.timer.5.html
• manpages.ubuntu.com/manpages/noble/en/man8/shutdown.8.html
• github.com/mvo5/unattended-upgrades/blob/master/README.md
• packages.ubuntu.com/search?keywords=unattended-upgrades&searchon=names&exact=1&suite=al...