Rocky 9: deciding and scheduling reboots after kernel updates

Test scope

In a Rocky 9.8 environment (privileged container, host kernel 5.14.0-687.54.1.el9_8): uname -r, needs-restarting -r, rpm -q kernel. Log: plans/content-expansion/evidence/logs/rocky-reboot-policy.log.

The container rootfs has no kernel package (rpm -q kernel reports not installed), so the “returns 1 after a kernel update” branch was not triggered here; it is described from command semantics and the dnf documentation. The logic on a real host is the same.

One command gives the answer

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

rc=0 means no reboot, rc=1 means reboot. It looks at packages updated since boot that affect the running system, not at how many packages you installed today.

What a missing kernel package reveals

rpm -q kernel

package kernel is not installed

The container shares the host kernel and ships no kernel package — which is also why needs-restarting -r always returns 0 here: it cannot see kernel updates. Do not carry that conclusion over to a real host.

Service level versus host level

needs-restarting
dnf needs-restarting

• needs-restarting: lists services that need a restart;
• dnf needs-restarting: the dnf wrapper with the same semantics;
• needs-restarting -r: answers only whether the host must reboot.

All three come from yum-utils. When restarting a service is enough, do not reboot.

What forces a reboot

Updated	Action
kernel	Reboot into the new kernel, otherwise the fix is inactive
glibc / systemd / openssl	Reboot the host (processes share these libraries)
Ordinary services (nginx, sshd)	Restart the service

Reboot window checklist

1. Confirm with needs-restarting -r;
2. Check dnf history list for what this update changed;
3. Drain traffic (load balancer/health checks) and confirm a rollback image or snapshot;
4. After rebooting verify uname -r, key services, and that needs-restarting -r is back to 0.

Common traps

• Validating reboot policy in a container: no kernel package, so the conclusion does not transfer;
• Restarting services only: kernel and core libraries are unaffected;
• Never rebooting: kernel CVE fixes stay inactive.

Practice: decide and record

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

Checks:

1. Record rc
2. List services needing restart (if any)
3. State whether the running kernel matches the newest installed kernel
4. Give a reboot conclusion with its reason

FAQ

常见问题

Why does needs-restarting always return 0 in a container?

Containers ship no kernel package and share the host kernel, so the tool cannot see kernel updates; reboot policy must be judged on a real host.

Is needs-restarting different from dnf needs-restarting?

Same semantics: a standalone command and its dnf subcommand, both from yum-utils. Pick one in scripts and do not confuse either with -r.

What must happen before rebooting?

Confirm that -r returns 1, review dnf history for impact, drain traffic and prepare a rollback, then verify kernel version and services afterwards.

Next steps

• Post-install checks: 7 checks after install
• Minimal versus DVD: Install group differences
• Log rotation: logrotate in practice