AlmaLinux 9: whether to reboot after kernel updates

Test scope

On a real AlmaLinux 9.8 host (kernel 5.14.0-687.54.1.el9_8): uname -r, needs-restarting -r, needs-restarting, dnf needs-restarting, rpm -q kernel. Log: plans/content-expansion/evidence/logs/alma-reboot-policy.log.

The “returns 1 after an update” branch was not triggered here (this host needs no reboot); it is described from command semantics and the dnf documentation.

The decision tool: needs-restarting -r

uname -r
needs-restarting -r; echo "rc=$?"

5.14.0-687.54.1.el9_8.x86_64
No core libraries or services have been updated since boot-up.
Reboot should not be necessary.
rc=0

The exit code is the answer: 0 = no reboot needed, 1 = reboot needed. It compares packages updated since boot that affect the running system — not “did I install something new”.

An installed older kernel does not force a reboot

rpm -q kernel | tail -2

kernel-5.14.0-427.13.1.el9_4.x86_64
kernel-5.14.0-687.54.1.el9_8.x86_64

Two kernels are installed (an older 9_4 and the running 9_8) and needs-restarting -r still returns 0 — an old kernel on disk does not mean a reboot is due; what matters is whether the running kernel is the newest installed one.

Service level versus system level

needs-restarting          # list services that need a restart
dnf needs-restarting      # same semantics as a dnf subcommand

The first lists services needing restart; the second is the dnf wrapper. Both come from yum-utils, not dnf-plugins-core. When restarting a service is enough, do not reboot the host.

When a reboot is mandatory

Updated	Reboot required
Kernel	Yes (the new kernel only takes effect after reboot)
glibc / systemd / openssl and other core libraries	Yes (running processes keep the old libraries)
Ordinary userland services	No — restart the service

When needs-restarting -r returns 1, it is usually the first two.

Scheduling the window

needs-restarting -r || echo "schedule a reboot"
sudo dnf history list | head -3

Check what this update installed (dnf history), then plan the window with load-balancer draining, health checks and a rollback path. Do not default to “reboot immediately after updating”, but do not leave a host unrebooted for months either — kernel security fixes stay inactive.

Common traps

Assuming a successful dnf update means patched: kernel and core-library fixes need a reboot;
Using needs-restarting (no -r) to judge the host: it lists services, not whether the host must reboot;
Never rebooting: kernel security updates never take effect.

Practice: decide and schedule one reboot

sudo dnf -y update
needs-restarting -r; echo "rc=$?"
needs-restarting
sudo dnf history list | head -3

Checks:

Record whether rc is 0 or 1
If rc=1, name whether the kernel or a core library caused it
List the services needing restart
State a reboot window and rollback plan

FAQ

常见问题

Is a 0 from needs-restarting -r a full safety guarantee?

It only covers installed-package effects on the running system, not configuration drift or expiring certificates. Confirm that services and the kernel actually loaded the new versions.

Why is the vulnerability still there after installing a new kernel?

The old kernel is still running. Kernel updates only take effect after rebooting into the new kernel, which is why kernel CVEs require a scheduled reboot.