Ubuntu 26.04 Tutorial / Manage Security Updates and Planned Reboots

Ubuntu security maintenance does not end with successful package installation. Inspect automatic-update scope and logs, then verify required reboots and service responses separately.

Inspect automatic-update configuration

dpkg-query -W unattended-upgrades
systemctl list-timers --all apt-daily.timer apt-daily-upgrade.timer
apt-config dump | grep -E 'Periodic|Unattended-Upgrade'

If a package or timer is absent, identify the installation type first. Prefer effective APT configuration and actual history over comments in one file. Having unattended-upgrades installed does not mean updates from every source are authorized.

Ubuntu’s automatic-update guide explains allowed origins, scheduling, logs, and reboot settings.

Review manual updates and service impact

sudo apt update
apt list --upgradable
apt-get -s upgrade

Review packages, space, and service effects, then schedule work and backups before sudo apt upgrade. Check required external requests as well as local process startup. Distinguish phased updates from ordinary failures.

Use a dry run and logs for automatic work

sudo unattended-upgrade --dry-run --debug
sudo journalctl -u apt-daily-upgrade.service --since today --no-pager
sudo ls /var/log/unattended-upgrades

A dry run examines what current rules would select; it is not evidence that updates were installed. Inspect actual logs for success, failure, exclusions, and time. Wait for another APT operation rather than creating a competing one.

Make reboot policy explicit

For a lab server that must not reboot automatically, back up existing settings and define the following local APT option. A possible file is /etc/apt/apt.conf.d/52unattended-upgrades-local; inspect and merge an existing file instead of overwriting it.

Unattended-Upgrade::Automatic-Reboot "false";

Check the effective value with apt-config dump. Preventing automatic reboot does not remove the need for one; an operator must schedule it. A policy that permits reboot should address timing, logged-in users, service interruption, and failure alerts.

Verify reboot requirements and recovery

test -f /run/reboot-required && cat /run/reboot-required
uname -r
systemctl --failed

Save work and reboot at the planned time when required. Compare the running kernel, time, networking, SSH, and web responses against the baseline. The installed kernel package and running kernel can differ. Use pre-update logs and prepared console or prior-kernel recovery routes if needed.

Restore only the local setting changed for the exercise and query the effective value again. Do not disable all security updates or delete error logs to make checks appear successful.