Ubuntu 26.04 Unattended Upgrades — Operations Guide

ubuntuunattended-upgradessecuritylinuxdevopsapt

Bottom line

Ubuntu 26.04 LTS ("Resolute Raccoon") ships with unattended-upgrades pre-installed and enabled by default for automatic security updates. The mechanism is mature and well-documented, using two systemd timers (apt-daily.timer for downloads, apt-daily-upgrade.timer for installation) with randomized delays to prevent repository thundering-herd. The default configuration is conservative - security-only, no email, no auto-reboot - making it safe out of the box but insufficient for production visibility. Production hardening requires adding email notifications, a deliberate reboot policy (either scheduled or gated), post-update verification, and log monitoring. The package is the standard across all Debian derivatives and has been in use on millions of machines for over a decade.

Key findings

  • Finding: unattended-upgrades is pre-installed and enabled on fresh Ubuntu 26.04 Server installs, applying security patches from the -security pocket daily with no user interaction - but it's silent by default (no email, no reboot, no non-security updates). Why it matters: You may assume it's working when it isn't, or it may be applying updates you didn't know about.

  • Finding: Starting with Ubuntu 24.04, the needrestart companion tool changed behavior: it now automatically restarts services that use outdated shared libraries after unattended-upgrades runs, instead of merely listing them. Why it matters: On container hosts (k8s, Docker), this can cause unexpected kubelet restarts, job failures, and GPU driver disconnects - as reported by real-world users.

  • Finding: Canonical staff have acknowledged that Livepatch integration with unattended-upgrades is "not yet well done" - the system may report a reboot is required when Livepatch has already applied the fix. Why it matters: You can't rely on /var/run/reboot-required alone if Livepatch is active; manual verification is needed.

  • Finding: Unattended-upgrades has no built-in health monitoring - if APT enters a broken state (e.G., dpkg lock, unmet dependencies), updates silently stop with no alert. Why it matters: Production VMs need external monitoring of unattended-upgrades logs or a verification timer.

  • Finding: The 20auto-upgrades file also includes APT::Periodic::Download-Upgradeable-Packages "1" and APT::Periodic::AutocleanInterval "7" on Ubuntu 26.04, which pre-downloads packages and auto-cleans the cache weekly. Why it matters: This reduces update latency and prevents /var from filling on small VMs.

Background

unattended-upgrades is a Python-based tool maintained in the mvo5/unattended-upgrades GitHub repository and packaged by both Debian and Canonical. It originated as a way to apply Debian/Ubuntu security updates without manual apt upgrade commands. Ubuntu has shipped it enabled by default since at least 16.04, replacing the older cron-apt and cron.Daily approaches.

Ubuntu 26.04 LTS was released on April 23, 2026, codenamed "Resolute Raccoon." It ships with Linux kernel 7.0, systemd 259, and kernel Livepatch support extended to Arm architectures. The unattended-upgrades package for 26.04 is version 2.12ubuntu9. Standard LTS support runs until April 2031; with Ubuntu Pro/ESM, coverage extends to 10–15 years and 25,000+ packages.

Current state (Ubuntu 26.04 specifics)

The default 26.04 configuration is:

/etc/apt/apt.conf.d/20auto-upgrades:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";

/etc/apt/apt.conf.d/50unattended-upgrades (Allowed-Origins):

"${distro_id}:${distro_codename}";           # release pocket (dependencies)
"${distro_id}:${distro_codename}-security";   # security updates
"${distro_id}ESMApps:${distro_codename}-apps-security";  # ESM Apps
"${distro_id}ESM:${distro_codename}-infra-security";     # ESM Infra

${distro_id} resolves to Ubuntu, ${distro_codename} to resolute.

The -updates, -proposed, and -backports pockets are commented out by default. Non-security updates require manual uncommenting.

New since Ubuntu 25.04: Unattended-Upgrade::Postpone-For-Days allows administrators to let users defer updates for a configurable number of days, with a polkit-controlled Postpone() D-Bus method for integration.

Technical details

Architecture

Two systemd timer units drive the process:

Timer Purpose Default schedule
apt-daily.timer apt update (refresh package lists + download) 6:00 and 18:00 daily, with RandomizedDelaySec=12h
apt-daily-upgrade.timer unattended-upgrade (install) 6:00 daily, with randomized delay, ~6-8 min after boot

Both timers default to Persistent=true, meaning missed runs (e.G., machine was off) are caught up after next boot - still subject to the randomized delay. This can cause immediate update activity on startup. The official docs recommend setting Persistent=false via systemctl edit for VM images that are started only briefly.

The timers call /usr/lib/apt/apt.systemd.daily, which dispatches to /usr/bin/unattended-upgrade for the install phase.

Verification commands

# Check if enabled
cat /etc/apt/apt.conf.d/20auto-upgrades

# Dry-run test
sudo unattended-upgrades --dry-run --debug

# Check timer status
systemctl list-timers apt-daily*

# Check logs
sudo tail -50 /var/log/unattended-upgrades/unattended-upgrades.log

# Check if reboot is pending
cat /var/run/reboot-required && cat /var/run/reboot-required.pkgs

# Check service status
systemctl status unattended-upgrades.service

Enabling from scratch

sudo apt install unattended-upgrades apt-listchanges needrestart
sudo dpkg-reconfigure -plow unattended-upgrades   # select "Yes"

Production configuration checklist

  1. Allowed origins: Uncomment -updates only if you accept non-security changes automatically.
  2. Package blacklist: Add regex patterns for packages you manage manually (databases, custom kernels, GPU drivers).
  3. Email notifications: Set Unattended-Upgrade::Mail and MailReport "on-change" - requires an MTA (Postfix, ssmtp, or msmtp).
  4. Reboot policy: Choose one of:
    • Automatic-Reboot "false" + weekly reboot-check timer during maintenance window (recommended for production).
    • Automatic-Reboot "true" with Automatic-Reboot-Time "03:00" for non-critical systems.
  5. Auto-cleanup: Enable Remove-Unused-Kernel-Packages "true" and Remove-New-Unused-Dependencies "true".
  6. Post-update verification: A custom systemd oneshot service that checks service health after unattended-upgrades.service completes.
  7. Log shipping: Forward /var/log/unattended-upgrades/ to centralized logging (Loki, ELK) or monitor via a Nagios-compatible check script.

Common pitfalls

Pitfall Symptom Fix
No MTA configured Email notifications never arrive Install mailutils + Postfix, or ship logs instead
Kernel updates held back uname -r shows old kernel despite apt listing newer Check apt-mark showhold; adjust origins or manually apt full-upgrade
Persistent=true on VMs Updates run immediately on boot, blocking other package ops systemctl edit apt-daily-upgrade.timer → set Persistent=false
needrestart restarts critical services kubelet/docker/DB restarts mid-operation Add service regex to /etc/needrestart/conf.d/ to prevent auto-restart
Disk fills on small VPS /var/cache/apt grows unbounded Keep AutocleanInterval "7"; monitor disk usage
APT broken state unattended-upgrades silently stops Monitor logs; run sudo unattended-upgrades --dry-run periodically

Evidence, comparisons, and related context

needrestart behavior change (24.04+)

Previously, needrestart would list services needing restart after library updates but not restart them in non-interactive contexts (like unattended-upgrades). Since Ubuntu 24.04, it auto-restarts affected services in both interactive and non-interactive modes. The rationale: if a security update patches a library, services still using the old in-memory copy remain vulnerable. You can override this per-service via /etc/needrestart/conf.d/.

Debian vs Ubuntu

Debian uses the same unattended-upgrades package but recommends creating overrides in /etc/apt/apt.conf.d/52unattended-upgrades-local rather than editing 50unattended-upgrades directly - a practice that applies equally well to Ubuntu to prevent config conflicts during package upgrades.

Landscape and Ubuntu Pro

For fleets beyond a handful of machines, unattended-upgrades isn't a replacement for fleet management. Landscape (Canonical's tool, included with Ubuntu Pro) manages up to 40,000 machines with centralized patch deployment, canary rollouts, compliance reporting, and Livepatch integration. Ubuntu Pro is free for up to 5 personal machines and covers 25,000+ packages with guaranteed security updates.

Kernel 7.0 context

Ubuntu 26.04 ships with kernel 7.0. Kernel updates are the most disruptive automatic update type - they always trigger /var/run/reboot-required and, if combined with DKMS modules (NVIDIA, ZFS, etc.), can cause boot failures if headers and image are installed in separate unattended-upgrades runs (Debian bug #1006753).

Limitations and critiques

  1. Silent failure mode: No built-in monitoring or alerting - if APT breaks, updates silently stop.
  2. Reboot control bug: Launchpad bug #1887655 (reboot despite Automatic-Reboot "false") confirmed on Ubuntu 20.04, status unchanged. Impact on 26.04 not yet verified.
  3. Livepatch disconnect: The system may report a reboot requirement when Livepatch has already patched the kernel, causing unnecessary reboots or confusion.
  4. No canary/staged rollout: unattended-upgrades applies the same updates to all machines simultaneously. There's no built-in mechanism to test on a subset first.
  5. Kernel + DKMS fragility: Kernel updates interacting with DKMS modules can break boot if headers arrive separately from the kernel image.
  6. Container host risk: The needrestart auto-restart behavior can disrupt container orchestration, as documented by k8s users who experienced kubelet restarts and GPU access loss.

Open questions

  • Is Launchpad bug #1887655 (spurious reboots) fixed in the 26.04 package (2.12ubuntu9)?
  • What are the exact OnCalendar and RandomizedDelaySec values in 26.04's shipped timer units (vs. The 24.04 values cited in most documentation)?
  • Does the InstallOnShutdown feature (which was limited from 30min to 30s inhibit delay) have practical production use on 26.04?
  • Is there a 26.04-specific changelog entry for unattended-upgrades beyond what's in the upstream repo?

Practical takeaways

  • For Ansible roles: Template 20auto-upgrades and 50unattended-upgrades with explicit values. Always include a verification step: unattended-upgrades --dry-run --debug in a handler, and check systemctl is-active apt-daily-upgrade.timer.
  • For production VMs: Default to security-only origins, enable email (or ship logs), disable auto-reboot, add a weekly reboot-check timer gated to a maintenance window, and wire a post-update service-health check.
  • For container hosts: Blacklist container runtime packages (docker-ce, containerd) from unattended-upgrades, and add GPU driver packages (nvidia-*) to the blacklist. Configure needrestart overrides for kubelet and container runtimes.
  • For verification in testinfra: Check that 20auto-upgrades has "1" for both Update-Package-Lists and Unattended-Upgrade, that 50unattended-upgrades has -security origin uncommented, that both systemd timers are active, and that /var/log/unattended-upgrades/unattended-upgrades.log has recent timestamps.

Sources used