Which updates need a reboot on Rocky/Alma

Which updates need a reboot on Rocky Linux and AlmaLinux

On Rocky Linux and AlmaLinux, dnf update writes new files to disk and stops there. The kernel you booted keeps running. Every process that already opened a library keeps using the copy it opened, because Linux keeps the old file alive on disk until the last process holding it exits. So the machine can report zero available updates while it still runs the code those updates replaced. None of this differs between the two distributions, since both rebuild the same Red Hat sources, and the choice between Rocky and Alma turns on compatibility promises and CPU support rather than on anything you will see here. The commands below are also the same ones a CentOS box used, which is not a coincidence: both projects were built as CentOS replacements after the 2020 Stream announcement.

Which updates need a reboot, and which need only a service restart, is a question you have to ask the machine. The command that answers it is needs-restarting. Updates sort into three tiers. The kernel and a short list of core packages need a full reboot. Ordinary library updates need the services that use them restarted. Everything else is already applied the moment RPM finishes.

Install needs-restarting

needs-restarting is a DNF plugin. The plugin ships in dnf-plugins-core, which is present on most Rocky and Alma installs already. The /usr/bin/needs-restarting command is a small wrapper shipped in yum-utils, which also answers to the name dnf-utils.

sudo dnf install -y yum-utils
needs-restarting --help

Both spellings run the same code, because the wrapper calls the DNF subcommand:

needs-restarting -r
dnf needs-restarting -r

Both packages come from the distribution's own repositories, so you do not need EPEL or the CRB repository enabled for this.

The Rocky Linux 10 and AlmaLinux 10 line still runs DNF 4. As of 2026-10-12, both BaseOS repositories carry dnf 4.20.0 together with dnf-plugins-core 4.7.0 and yum-utils, and no dnf5 package. So needs-restarting there is the same dnf-plugins-core plugin this page describes, and everything below applies. That includes -r, which is what produces the reboot hint and its exit code, so keep it in your scripts. Rocky and Alma 9 carry the older dnf-plugins-core 4.3.0 build, and the few places where the two builds behave differently are marked below.

Tier 1: the updates that need a reboot

Run the reboot check first. It reads the RPM database and the system boot time, nothing else, so it is fast and it does not need root.

needs-restarting -r

When nothing important has changed since boot, it prints two lines:

No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

When something has changed, it prints Core libraries or services have been updated since boot-up:, then the package names it found, and then:

Reboot is required to fully utilize these updates.
More information: https://access.redhat.com/solutions/27943

The exit code carries the same answer: 0 when no reboot is needed, 1 when one is. That is the half you script against.

if ! needs-restarting -r >/dev/null; then
  logger -t updates "reboot pending on $(hostname -s)"
fi

Exit code 1 here is a normal answer, not a failure. Under set -e an unguarded needs-restarting -r ends your script at that line, which is why the example above wraps it in if.

The packages that trigger the reboot answer are a short hard-coded list inside the plugin. In the build Rocky Linux 10 and AlmaLinux 10 ship, it holds kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon and microcode_ctl. The Rocky and Alma 9 build has the same list without kernel-core, which matters for the reason explained in the next section. Check yours rather than assuming.

Each entry is on that list for a reason you can state plainly. A new kernel package only writes files into /boot and /lib/modules, and the running kernel cannot be swapped underneath itself, so nothing changes until you boot it. Nearly every userspace process on the box links glibc, PID 1 included, which means "restart the affected services" would mean restarting PID 1 as well, and a reboot is the safe version of that. dbus and dbus-broker carry every client connection on the system, so stopping the bus on a live machine breaks the clients that are talking to it. linux-firmware and microcode_ctl load at boot, and on a VPS the microcode part usually changes nothing you can observe, because the hypervisor host owns the physical CPU.

You can add your own packages. Any .conf file under /etc/dnf/plugins/needs-restarting.d/ is read as a list of package names, one per line, and those names join the reboot list.

echo 'openssl-libs' | sudo tee /etc/dnf/plugins/needs-restarting.d/openssl.conf

That is a policy choice, not a fix. It says "when the TLS library changes, I would rather reboot than track down every service that mapped it".

What the reboot hint is actually derived from

needs-restarting -r does not compare your running kernel version against the newest installed kernel. It compares timestamps. For every package on that core list it reads the RPM install time and compares it against the time the system booted. If a core package was installed after the last boot, the answer is "reboot required". Boot time comes from systemd's UnitsLoadStartTimestamp over D-Bus when that is available, and otherwise from the later of the modification time of /proc/1 and the btime field in /proc/stat.

That mechanism has one consequence worth knowing. If you install a kernel, reboot, and land back on an older kernel because the boot default is pinned, the install time is now older than the boot time and needs-restarting -r goes quiet. It is answering its own question correctly. It is not the question you asked. Check the kernel separately.

uname -r
rpm -q --last kernel
sudo grubby --default-kernel

The first command prints what is running. The first line of rpm -q --last kernel is the most recently installed kernel. grubby --default-kernel prints what the bootloader will pick next time. If those three disagree, fix the boot default before you reboot a machine you cannot reach over a console.

Rocky and Alma 9 have a second gap. Because their plugin build watches kernel but not kernel-core, a transaction that updates kernel-core without the kernel package leaves a new kernel installed and not yet running while needs-restarting -r reports that no reboot is needed. Red Hat documents this behaviour for Enterprise Linux 9. A routine dnf update on a machine with the kernel package installed updates that package too, so the hint still fires. Run rpm -q kernel to check. If it says the package is not installed, the reboot hint will not catch kernel updates on that machine, and you should compare uname -r against rpm -q --last kernel-core instead.

Tier 2: the updates that need a service restart

When RPM replaces a shared library, it unlinks the old file and writes a new one. A process that already mapped the old file keeps the old inode alive and keeps executing the old code. openssl-libs is the case that matters most: a fix in libcrypto reaches your web server only after that web server restarts.

sudo needs-restarting -s

This lists the systemd services whose own files, or whose dependencies' files, were updated after the service started. Use sudo. Without root the tool can only read /proc entries for your own processes, so it quietly under-reports and the short list looks like good news.

sudo needs-restarting
sudo needs-restarting --exclude-services

The first prints the PID and command line of every affected process. The second drops the ones a systemd service already covers, which leaves login shells, tmux sessions, cron jobs and anything you started by hand. Those never restart on their own. --exclude-services exists only in the Rocky and Alma 10 build. On 9 the option is not there, so read the full sudo needs-restarting list and set aside the processes that belong to services from the -s output.

Do not restart a service on the list that belongs to a reboot-tier package, such as dbus-broker.service. Reboot instead. As of 2026-10-12, the builds Rocky Linux and AlmaLinux ship still print such a service like any other. The CentOS Stream 10 package gained a change in July 2026 that moves those services off the list and prints Warning: The following services should not be restarted but require a reboot: on stderr instead. Once your release picks that change up, take the warning literally.

Restart the rest one at a time, and check each one before moving to the next.

sudo systemctl restart nginx
systemctl status nginx

Do not pipe the list into systemctl restart. Your own SSH session is the reason. On the RHEL family, sshd.service ships with KillMode=process, so restarting it signals the listening daemon and leaves the per-connection processes alone, and an open session survives. Confirm that on your own box with systemctl cat sshd | grep KillMode, and keep a second session open the first time regardless.

You can also find the same processes without DNF, which is useful when you want to see the file paths involved:

sudo dnf install -y lsof
sudo lsof -n +c 0 2>/dev/null | grep -w DEL

DEL marks a mapped file that has been deleted from disk. Read the paths before acting. Deleted temporary files and memory-backed files show up here too, and they are not a reason to restart anything.

Tier 3: everything else

Most updates land here and need nothing. A package whose files are only read when a command starts, such as curl, tar, vim or dnf itself, is fully applied when RPM finishes, because the next run reads the new binary. Configuration files, scripts, documentation and data packages behave the same way. needs-restarting will not mention any of them, and that silence is the correct answer rather than a missed detection.

The one catch in this tier is duration. A process started before the update keeps running its old executable until it exits, however trivial the package was. That is exactly what sudo needs-restarting --exclude-services is for, or plain sudo needs-restarting on 9.

Why a machine on dnf-automatic can carry unapplied fixes for weeks

This is where the three tiers stop being trivia. Automatic updates with dnf-automatic install packages on a timer, and the default reboot setting in /etc/dnf/automatic.conf is never. With apply_updates = yes and reboot = never, a machine can install six kernel updates and a glibc fix over six weeks and still be running the kernel and the C library it booted with in week zero. The update log looks perfect. The running system has none of it.

The fix is three lines in /etc/dnf/automatic.conf:

[commands]
upgrade_type = security
apply_updates = yes
reboot = when-needed
reboot_command = "shutdown -r +5 'Rebooting after applying package updates'"

reboot accepts never, when-changed and when-needed. never is the default and leaves every decision to you. when-changed reboots after any transaction that changed a package, which is blunt but predictable. when-needed asks DNF whether the transaction it just applied requires a reboot, so a userspace-only update night passes without one. reboot_command is what actually runs, and the default gives logged-in users five minutes of warning. Set random_sleep and the timer's schedule so this lands inside a window where you can watch the machine come back.

Check which unit you enabled with systemctl list-timers 'dnf-*'. Several variants ship with dnf-automatic and they do not all behave the same way, so the config file alone does not tell you what runs.

After a scheduled run, ask the machine rather than the log:

needs-restarting -r; echo "exit: $?"
uname -r
rpm -q --last kernel | head -1

If the reboot is the part you cannot schedule, live kernel patching on a VPS is the other route. It applies certain kernel fixes to the running kernel with no reboot. It covers a subset of kernel issues, and it does nothing for glibc or for your services, so treat it as a way to space reboots out rather than to stop doing them. When you do reboot, do it deliberately and stay logged in until the machine answers, because a kernel update is the most common reason a machine does not come back. Read what to do when a VPS will not boot after a kernel update before you reboot a box with no console access, and fold the reboot check into a regular server maintenance checklist so it is not something you remember only after an incident.

The same job on Ubuntu and Debian

A mixed fleet needs the equivalents. On Ubuntu and Debian the reboot flag is a file, not a command: package scripts create /run/reboot-required, and /run/reboot-required.pkgs lists which packages asked for it, so [ -f /run/reboot-required ] is the plain equivalent of needs-restarting -r. Older documentation writes /var/run/reboot-required, which is the same file, because /var/run is a symlink to /run. The service side is needrestart, installed by default on recent Ubuntu Server releases, which runs during apt upgrade and can be run on its own with sudo needrestart -r l to list what needs restarting without touching anything. The automatic-update gap is identical there, and so is the fix: unattended-upgrades on Ubuntu takes Unattended-Upgrade::Automatic-Reboot "true"; and Unattended-Upgrade::Automatic-Reboot-Time "02:00"; in /etc/apt/apt.conf.d/50unattended-upgrades.

Failure modes and what you will see

• needs-restarting: command not found means yum-utils is not installed. Install it, or call dnf needs-restarting instead, which works as soon as dnf-plugins-core is present.
• A script that stops at the reboot check with no error message is hitting exit code 1 under set -e. That code means "reboot required", so branch on it instead of letting it terminate the script.
• needs-restarting -s printing nothing right after a library update usually means you ran it without sudo. Without root it sees only your own processes.
• needs-restarting -r reporting no reboot while uname -r shows an older version than the newest installed kernel usually means you booted an older kernel. The check compares install time against boot time, and both are now behind you. Look at grubby --default-kernel. On Rocky or Alma 9 there is a second cause: the update changed kernel-core without the kernel package, which the 9 build does not watch, so a reboot is still pending.
• needs-restarting --exclude-services failing with an unrecognized-argument error means you are on the 9 build, which does not have that option. Use plain sudo needs-restarting.
• A service that appears again on the next run, minutes after you restarted it, is usually being restarted by something else, or the unit failed to come back. Read systemctl status for that unit before restarting it a second time.

FAQ

Does dnf update restart services on Rocky Linux?

As a rule, no. The transaction writes files and ends. Some packages do carry an RPM scriptlet that restarts their own service on upgrade, so behaviour is per package rather than a system-wide guarantee. Treat sudo needs-restarting -s as the authority: it lists the services whose files, or whose dependencies' files, changed after the service started, whatever the scriptlets did.

Why does needs-restarting -r say no reboot is needed when a newer kernel is installed?

Because it compares the RPM install time of a short list of core packages against the system boot time. It never compares the running kernel version against the newest installed one. If you installed a kernel, rebooted, and came back on an older kernel because the bootloader default points there, the install time is older than the boot time and the check goes quiet. On Rocky and Alma 9 it also misses a kernel-core update made without the kernel package, because kernel-core is not on the 9 build's list. Run uname -r, rpm -q --last kernel and sudo grubby --default-kernel to see the real picture.

Which packages trigger the reboot hint on Rocky and Alma?

A hard-coded list inside the plugin. On Rocky and Alma 10 it holds kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon and microcode_ctl. On 9 it is the same list without kernel-core. You can extend it: drop a .conf file into /etc/dnf/plugins/needs-restarting.d/ containing package names, one per line, and those names count toward the reboot answer too.

Can dnf-automatic reboot the server by itself?

Yes. Set reboot = when-needed in the [commands] section of /etc/dnf/automatic.conf and it reboots only when the transaction it applied requires it. when-changed reboots after any package change, and never is the default. reboot_command controls how, and its default gives logged-in users a five minute warning. Only enable this on a machine whose boot you can recover, because an unattended reboot on a VPS with no console access is a hard failure mode.

Does needs-restarting see processes inside containers?

Not usefully. It matches running processes against the host RPM database, and packages inside a container image are not in that database, so an outdated library baked into an image will not appear. Rebuild the image and redeploy it. The host side still matters: the container runtime and the kernel it shares are host packages, and those do show up.