On a RHEL 9 host, `dnf upgrade` has installed patched openssl and glibc packages, but a scanner still reports the vulnerable versions in running processes. Why, and which dnf command tells you what to restart or whether to reboot?

## Why the patch is on the box but not in effect A package upgrade is a file operation. dnf lays down the new `libcrypto` or `libc` and updates the RPM database, and from that moment anything *newly started* uses the patched code. What it cannot do is reach into a process that is already running: that process loaded its executable and its shared libraries when it started and goes on using them for its whole lifetime. So a service that has been up for forty days is still running the vulnerable code, and a scanner that inspects running processes rather than the package database is telling you the truth. This is the gap between "patched" and "remediated", and it is the whole point of the question. Reporting a patch window as complete on the strength of `dnf upgrade` exiting zero is the mistake being probed for. ## The tool `dnf needs-restarting`, provided by the `dnf-plugins-core` package, exists exactly for this. Three forms matter: ```bash dnf needs-restarting # running processes whose files were replaced dnf needs-restarting -s # the systemd services to restart dnf needs-restarting -r # is a full reboot recommended? ``` The bare form prints PIDs with their command lines — every process started before the files it uses were updated. It is the raw evidence, useful when you want to see that it is a long-lived worker rather than something that will cycle on its own. `-s` is the form you act on, because it translates those processes into the systemd units that own them, and units are what you restart. Restarting the unit starts a fresh process which maps the patched libraries, and that is remediation for a userspace library. `-r` answers a different question: whether the update touched something that cannot be fixed by restarting a service — the kernel above all, but also core userspace like glibc, systemd or dbus, where restarting every dependent process is neither practical nor safe. It reports its verdict in the exit status as well as in text, which is what makes it usable in a script or a configuration-management run: check it, and reboot the host only when it says so. ## Turning it into a patch procedure A defensible sequence for a patch window looks like this: 1. `dnf upgrade` (or a security-only variant of it) and record the transaction ID from `dnf history` so you know what changed. 2. `dnf needs-restarting -r`. If it says reboot, schedule the reboot and stop — a reboot subsumes every service restart. 3. Otherwise take the unit list from `dnf needs-restarting -s` and restart those units, respecting whatever ordering or draining your service needs. This is where a load balancer and rolling restarts matter more than the dnf command does. 4. Re-run the check, and re-scan. If a process still shows up, something restarted it into the old state or the unit was not the owner you thought. The kernel deserves its own line. A kernel package installs alongside the running one rather than replacing it, so nothing about the running system changes until you boot into it. `needs-restarting -r` is the honest reporter of that fact. ## The judgment part The interesting disagreement in real organisations is not which flag to use, it is what you do with the answer. Restarting services individually keeps uptime but leaves you reasoning about a long tail of processes — cron-spawned children, forked workers, an agent nobody owns. Rebooting is coarse, costs a maintenance window, and is completely unambiguous: after a reboot, nothing is running old code. Many teams settle on "reboot on kernel or core-library updates, rolling service restarts otherwise", which is exactly the policy `-r` is designed to drive. The containerised case flips the burden. You do not restart a process inside a container to patch it; you rebuild the image with the updated packages and replace the container. `needs-restarting` is a host tool, and on a container host it is telling you about host processes — the containers running on it are a separate patching path entirely. ## What a weak answer sounds like "dnf handles it" — it does not; nothing in a package transaction restarts your services for you. Or the opposite overcorrection, that only a reboot can ever apply a library patch, which is not true either: restarting the service is sufficient for a userspace library and is the reason `-s` exists as a separate answer from `-r`.