What Ubuntu’s “*** System Restart Required ***” Message Means (and When You Actually Need to Reboot)

When you log into an Ubuntu server via SSH, you may be greeted by a prominent banner: *** System Restart Required ***. This DevAnswers guide explains what the message means, how to find which packages triggered it after an apt upgrade, and when you actually need to reboot.

What Does “System Restart Required” Actually Mean? #

The message is not an error and not an immediate emergency. It is a notification from the package management system telling you that a recent update touched something the running kernel or running services cannot reload at runtime, so the new code only takes effect after a reboot.

The banner itself is printed at login by the script /etc/update-motd.d/98-reboot-required, which is part of the update-notifier-common package shipped on Ubuntu by default. The script is short; it simply prints the contents of /var/run/reboot-required when that file exists.

Whether the reboot is urgent depends entirely on what the update touched. A glibc or kernel update is a security imperative; a routine library update for an application you’re not running heavily can usually wait for a planned window. The rest of this article shows you how to make that call.

The Mechanism: /var/run/reboot-required #

Ubuntu signals a pending reboot with a specific file: /var/run/reboot-required (Debian uses the same file only when update-notifier-common is installed, covered below). This file does not exist on a fully updated, running system. It is created only when a package’s post-installation script (the postinst hook) calls the helper /usr/share/update-notifier/notify-reboot-required.

Confirm whether the banner is accurate by checking for the file directly:

ls -l /var/run/reboot-required

If the command returns a file listing, a reboot is genuinely pending. If it returns “No such file or directory”, the system is clean and the banner you saw was stale (it clears on the next login after a reboot, since the flag lives in tmpfs).

One useful detail: /var/run is mounted as tmpfs, meaning its contents are wiped on every reboot. That’s why the file disappears automatically once you restart, with no manual cleanup needed.

Identifying the Triggering Packages #

Knowing that a reboot is required is rarely enough. You need to know what triggered it. The package manager writes the names of the requesting packages to a secondary file: /var/run/reboot-required.pkgs.

cat /var/run/reboot-required.pkgs

Typical output after a kernel security update looks like this:

linux-image-6.8.0-31-generic
linux-base

In this scenario, a Linux kernel security update has been installed. The new kernel image is on disk, but the operating system is still running the old kernel in memory. The vulnerability patched in the new kernel is still active in your RAM until you reboot. (For broader package-status inspection; listing every installed package, querying specific ones; see our guide on how to check if a package is installed in Ubuntu.)

If the .pkgs file is missing or ambiguous but the notification persists, inspect the package manager log directly. The dpkg.log file contains a timestamped history of all package status changes:

grep 'status installed' /var/log/dpkg.log | grep 'linux-image' | tail -n 5

This gives you a precise timeline of when the kernel update landed, useful for correlating against your maintenance schedule.

When Do You Actually Need to Reboot? #

Once you know which packages triggered the request, you can prioritise. The category of package determines both the technical reason for the reboot and how soon you should schedule it:

Canonical’s security notices (USNs) regularly call out the reboot requirement explicitly. USN-7580-1 on a recent PAM vulnerability puts it plainly: “after a standard system update you need to reboot your computer to make all the necessary changes.”

The needrestart Tool (Ubuntu 22.04 and Later) #

needrestart has shipped in the default Ubuntu install since 21.04 and is present in 22.04 LTS onward, complementing /var/run/reboot-required. Where the file is a static signal set by package postinst hooks, needrestart performs a dynamic analysis: it inspects running processes for outdated library mappings and reports which daemons are still using deleted or upgraded files.

sudo needrestart -b -r l

Batch mode (-b) gives parseable output suitable for scripts, and -r l forces list-only so the check never restarts anything (important on 24.04, where the default mode would otherwise restart services). Typical output includes a kernel-version comparison:

NEEDRESTART-KCUR: 6.8.0-31-generic
NEEDRESTART-KEXP: 6.8.0-35-generic
NEEDRESTART-KSTA: 3

A NEEDRESTART-KSTA value of 3 means a reboot is required (the running kernel differs from the installed one). On Ubuntu 24.04 LTS the default changed so needrestart now restarts affected services automatically rather than only listing them, which is why an unattended-upgrades run can now restart your services after a security update. If that surprises your automation, set NEEDRESTART_MODE=l to return to list-only, or change the restart mode in /etc/needrestart/needrestart.conf.

On Kubuntu Desktop: kubuntu-notification-helper #

If you’re on Kubuntu (the KDE Plasma flavour of Ubuntu) you may see a graphical popup instead of the SSH banner: “A system restart is needed to complete the update process.” The same underlying mechanism drives it.

The component responsible is kubuntu-notification-helper, a kded module that watches /var/lib/update-notifier/dpkg-run-stamp. Whenever apt or dpkg finishes a package transaction, that stamp file is touched. The helper then checks for /var/run/reboot-required and, if the file exists, triggers the rebootevent KDE notification. So the desktop popup and the server SSH banner are reading the same file; they’re just different surfaces.

You can configure the notification’s behaviour in System Settings → Notifications → Application Settings → Other Notifications (search for “Notification Helper”). Disabling the popup does not disable the underlying reboot requirement; the file is still there and the system still needs a restart.

Note for Debian Users #

Debian uses the same /var/run/reboot-required mechanism, but it is not part of a default Debian server install. The update-notifier-common package (which ships the MOTD script and the notify-reboot-required helper) is an Ubuntu default, not a Debian default. On a stock Debian system you typically see /var/run/reboot-required only if you’ve enabled unattended-upgrades or installed update-notifier-common manually. Without those, you can still infer reboot need by comparing the running kernel version (uname -r) against the installed one (dpkg -l 'linux-image-*'). needrestart itself is present on current Debian releases (it ships on Debian 12 and 13, including the common cloud images), so its service-restart detection works the same as on Ubuntu; the genuinely Ubuntu-specific piece is the reboot-required file, not needrestart. On a minimal install, confirm with dpkg -l needrestart and add it with sudo apt install needrestart if missing.

Checking Programmatically (Bash, Ansible) #

If you manage a fleet, relying on a login banner is inefficient. Automate the check so you only schedule maintenance windows for servers that actually need them.

#!/bin/bash
if [ -f /var/run/reboot-required ]; then
  echo "REBOOT REQUIRED on $(hostname)"
  [ -f /var/run/reboot-required.pkgs ] && cat /var/run/reboot-required.pkgs
  exit 1
fi
exit 0

For richer output that also flags running services with outdated library mappings, prefer needrestart -b -r l on Ubuntu 22.04+:

sudo needrestart -b -r l

An equivalent Ansible task is straightforward:

- name: Check if reboot is required
  ansible.builtin.stat:
    path: /var/run/reboot-required
  register: reboot_required

- name: Reboot if needed
  ansible.builtin.reboot:
  become: true
  when: reboot_required.stat.exists

Both the script and the Ansible task above key off /var/run/reboot-required, so on a stock Debian host where that file is not created by default (see the Debian note above) they will report no reboot needed even when one is. On those systems, fall back to comparing the running kernel (uname -r) against the installed one, or install needrestart and use needrestart -r l.

For other automation patterns around service management; auto-restarting crashed daemons, watchdog scripts; see our guide on auto-restarting MySQL on Linux.

Performing the Reboot #

Once you’ve decided to reboot, the simplest command is:

sudo reboot

If you need to schedule the reboot for a maintenance window, use shutdown with a delay and a broadcast message so other logged-in users see the warning. For more options (broadcasting messages, scheduling for specific times, single-user mode), see our guide on how to shut down or reboot Ubuntu.

Suppressing the Message Without Rebooting #

You can remove the file manually to clear the banner:

sudo rm -f /var/run/reboot-required /var/run/reboot-required.pkgs

Be aware of what you’re doing: this clears the signal, not the underlying state. The running kernel or library is still the old version. The system is still due for a reboot. The only legitimate reason to do this is a planned maintenance window where you’ve reviewed /var/run/reboot-required.pkgs and determined the listed packages don’t apply to your workload.

For routine sysadmin work, leave the file alone; its presence is honest signal about a security state your system has not yet caught up with.

Next Steps #

Once you’ve decided to reboot, see our guide on how to shut down or reboot Ubuntu for scheduled-shutdown options and broadcast warnings. If you’d rather automate the check across a fleet, the bash and Ansible patterns above pair well with our guide on auto-restarting services on Linux. And to confirm the upgrade that triggered the banner is what you intended, the canonical apt update / apt upgrade workflow covers the typical update flow.