Somewhere around 2010, at a Plesk-related conference (the location has faded, but the conversation hasn’t), I got talking to a chap who ran a hosting business. I was early in my web admin career/hobby, and I confessed a great fear to him about restarting production servers. A reboot felt like the moment where things can and will go wrong. The server doesn’t come back up, panic mode kicks in, and suddenly you’re deep in territory you don’t understand, trying to resuscitate a machine that was working perfectly fine five minutes ago.
He was kind about it. “I leave my servers on at all times,” he told me. “I keep patching the packages, but I hardly ever restart them. Very reliable.”
What a relief that was to hear! If it ain’t broke, don’t restart it. The advice made intuitive sense, it came from a professional, and it neatly sidestepped the thing I was afraid of. It stuck with me for many years.
It was also — as I’ve slowly come to understand — only half good advice. And the half that’s wrong is wrong in a really interesting way. To see why, we need to look at what actually happens when Linux updates a package, and why the kernel is the one component that breaks the whole “never reboot” philosophy.
Act One: what a package update actually does
When your package manager (dnf, apt, or Plesk doing it for you behind the curtain) updates a package, it’s fundamentally doing something very simple: it replaces files on disk. The old binary for, say, nginx gets unlinked, and a new one is written in its place.
But here’s the subtlety that makes Linux different from what you might expect: replacing a file on disk does not affect a program that’s already running. When a process starts, the kernel maps the program’s code into memory. As long as that process lives, it keeps running the code it was started with — even if the file it came from has been deleted and replaced on disk. The old file’s data isn’t truly gone until the last process using it lets go. (This is the inode story, and it deserves its own article — the short version is that a filename and a file’s contents are two separate things in Linux, and deleting the name doesn’t delete the contents while someone’s still holding on to them.)
This is why package updates on Linux are so wonderfully undramatic. No “please close all applications.” No locked files. The update just happens, and running services carry on with the old code until they’re restarted — which is exactly why dnf and apt restart or reload services after updating them. The restart is the moment the new code actually kicks in.
So far, the conference chap’s advice holds up perfectly: patch your packages, restart the affected services, and the server itself never needs a reboot. Uptime climbs into the hundreds of days. Screenshots of uptime get posted like marathon times. Life is good.
Act Two: the kernel is a service you can’t restart
Now apply the same logic to a kernel update. The package manager installs the new kernel exactly like any other package: it writes the new kernel image and its modules to disk (into /boot and /lib/modules/<version>/), rebuilds the initramfs, and updates the bootloader so the new version becomes the default menu entry.
And then… nothing happens. The running kernel — loaded into memory once, at boot — carries on completely unaffected. Run uname -r and you’ll still see the old version, even though the new one is sitting right there on disk, installed and ready. That mismatch between installed and running is one of the most common points of confusion in Linux administration, and it’s the answer to a question I carried around for many years: when does a kernel update actually kick in?
At the next boot. That’s it. That’s the whole answer.
The reason is the same principle from Act One, taken to its logical extreme. A running program keeps its old code in memory until it’s restarted — and the kernel is the ultimate running program. It’s the thing every other process runs on. You can restart nginx, PHP-FPM, even systemd services one by one, but you cannot restart the kernel from within the kernel, because there’d be nothing left standing to do the restarting. The only “service restart” available for the kernel is a reboot of the entire machine.
(Yes, livepatching exists — kpatch, Canonical Livepatch, KernelCare, which Plesk offers as an extension. It can inject specific critical security fixes into the running kernel’s memory. But it’s a stopgap for urgent CVEs, not a substitute for the real kernel upgrade. Sooner or later, you boot into the new kernel properly.)
Helpfully, distributions keep the previous kernel or two installed alongside the new one. If the fresh kernel misbehaves, the boot menu lets you fall back to the old, known-good version. The upgrade destroys nothing — it just adds an option and changes the default.
Interlude: reading the receipts
Before we get to why the old advice goes bad, a detour that nearly fooled me while writing this. On my AlmaLinux 9 web server, a dnf upgrade offered me a kernel update:
- from
5.14.0-503.19.1.el9_5 - to
5.14.0-687.30.1.el9_8
My first reading was reassuring: 5.14.0 to 5.14.0, same version, just a “semantic minor bump” after the dash. How big a deal can that be?
Quite big, as it turns out. On the RHEL family (RHEL, AlmaLinux, Rocky), the kernel version is frozen for the entire life of the release — AlmaLinux 9 will say “5.14.0” until it goes end-of-life in 2032. That doesn’t mean the kernel stops receiving fixes. Red Hat practices backporting: security patches and selected features from newer upstream kernels are ported back into the frozen 5.14 codebase, and each batch bumps the number after the dash. That’s the number that tells you how patched you are. My jump from 503 to 687 represents well over a year of accumulated fixes, and the el9_5 → el9_8 suffix reveals that my running kernel dates from the AlmaLinux 9.5 era while the current point release is 9.8.
This is the great trade of the enterprise distros: interface stability (software certified against RHEL 9’s kernel behaves identically for a decade) in exchange for version numbers that become useless for judging patch level. A RHEL-family kernel with a boring old version and a high release number is often better patched against known CVEs than a stock newer kernel. Meanwhile Fedora runs genuinely new kernels — 7.x as I write this — with new features and, inevitably, new bugs. Fedora is the proving ground; RHEL is where the survivors settle down.
So how do you read the receipts? Like this:
rpm -q --changelog kernel-core-$(uname -r | sed 's/\.x86_64//') | head -50What scrolls past is a changelog with CVE numbers going by like film credits — batches of security fixes landing every week or two. And here’s the moment that motivated this whole section: when I ran it on my web server, the most recent entry was dated November 2024. On a server I had assumed was fully current! Same 5.14.0 in the version string, eighteen months of missing fixes in the changelog — and the el9_5 branch my kernel belongs to isn’t even receiving patches anymore, because the patched lineage moved on to 9.6, 9.7, 9.8 without me.
(One subtlety if you try this yourself: a plain rpm -q --changelog kernel-core may show you a different installed kernel than the one you’re running, because — as we’re about to see — there’s usually more than one on disk. Target the running one explicitly, as above.)
Which brings us to a lovely detail visible in the dnf upgrade transaction itself. Kernels are install-only packages: dnf never upgrades them in place. It installs the new kernel alongside the existing ones and prunes the oldest beyond a retention limit (three by default — installonly_limit in /etc/dnf/dnf.conf). In my transaction, dnf proposed removing an older spare (503.11.1) while leaving my running 503.19.1 untouched. The package manager is structurally incapable of pulling the rug out from under the live kernel. It only ever adds options to the boot menu and tidies up the far end of the shelf.
The Plesk blind spot
There’s one more piece to this puzzle, and it’s the one that explains how my particular server got here despite being, as I believed, fully self-maintaining.
Like many Plesk admins, I assumed Plesk’s automatic updates were essentially running dnf upgrade under the hood every so often, keeping everything current. And Plesk does dutifully update itself, its components, and — with the system updates option enabled — the OS packages too.
But kernel updates are excluded from Plesk’s Update Manager entirely. This isn’t a setting you’ve missed: the System Updates UI simply doesn’t include kernel packages, even with safe-updates mode disabled. Plesk’s reasoning is exactly the theme of this article — kernels are install-only packages that require a reboot to take effect, and Plesk isn’t going to reboot your production server for you, so it leaves the entire category to the admin. (Their suggested alternative for reboot-averse setups is the KernelCare livepatching extension, which we met earlier.)
The result can be a quietly dangerous illusion: Every userland package on the box is current — which is why my dnf upgrade showed nothing pending except kernel bits — while the single most security-critical package has been parked since whenever the server was last manually updated and rebooted. The division of labour is never announced. You have to already know about it, or discover it the way I did: by idly running dnf upgrade one Saturday morning and wondering why there’s a kernel sitting there.
If you run Plesk, the takeaway is one line: Plesk patches your packages; the kernel is yours. Put a recurring reminder somewhere — check for kernel updates, apply, reboot on your schedule.
Act Three: why the old advice curdled
So here’s where the hosting chap’s philosophy runs aground. A server with a proud 900-day uptime is also, unavoidably, a server running a 900-day-old kernel — complete with every privilege escalation and security hole discovered in it since. The very metric that used to signal reliability now signals exposure.
But there’s a second problem, and it’s the one that took me longest to appreciate: a server that hasn’t rebooted in years has an untested boot path. Over those years, configuration accumulates. A new mount in fstab. A tweaked service. A firewall rule someone added live and never persisted. None of it has ever been through a cold start. The boot sequence — the thing I was so afraid of back in 2010 — has been quietly rotting the entire time.
And rebooting is not optional; it’s merely deferrable. Eventually it happens whether you like it or not: a power event, a hardware failure, or a kernel vulnerability you can no longer ignore. When it does, it happens involuntarily, at the worst possible time, with years of untested changes hitting the boot sequence all at once.
This is where the fear becomes self-fulfilling. You don’t reboot because it’s risky, and it’s risky precisely because you never reboot. It’s the same trap as backups you’ve never restored: an unrebooted server is Schrödinger’s boot configuration. You don’t know whether it comes back up until you try — and you really want to find out on your own terms.
The modern consensus has therefore flipped the old wisdom on its head. Regular, scheduled reboots aren’t an admission of weakness; they’re a feature. A reboot you choose — on a quiet Tuesday morning, coffee in hand, terminal open, ready to watch it come back — is infinitely better than the one the power grid chooses for you at 3am. Each planned reboot proves the boot path works, activates the latest kernel, and gives you a fresh, known point in time: a state where you can actually tell whether things are working, because you just watched them start.
The chap at the conference wasn’t wrong for his era. Linux really doesn’t need reboots for hygiene — there’s no slow Windows-style degradation that a restart magically cures. His servers really were reliable. But “hardly ever restart” quietly became “never test the one operation your server cannot avoid forever,” and that’s a debt that compounds.
These days I check uptime regularly — not to admire a big number, but with mild suspicion when I see one. If I can’t remember when or why I last rebooted a machine, that’s not a badge of honour anymore. It’s a reminder that a reboot is overdue.
Epilogue: the boring reboot
I didn’t have to wait long for my own medicine. While writing this article, I applied that pending kernel update on my server and scheduled the reboot — chosen time, coffee in hand, terminal open, exactly as prescribed.
Before the restart, the two-line proof of everything above:
# installed, per the dnf transaction: kernel-core-5.14.0-687.30.1.el9_8
uname -r
5.14.0-503.19.1.el9_5.x86_64New kernel on disk, old kernel in memory. Installed is not running.
And after the restart:
uname -r
5.14.0-687.30.1.el9_8.x86_64The reboot itself was entirely boring — which is precisely how we like them. Websites answering, logins working, services up, and an uptime reading a gloriously humble couple of minutes: a known point in time, a boot path proven to work, and roughly eighteen months of backported kernel fixes finally doing their job instead of waiting politely in /boot.
One last confession to round it off. The day before, I’d restored one of my sites from a backup while chasing an unrelated slowdown — not as a drill, but because I needed to. It struck me afterwards that the same principle had been staring at me from two directions at once: a backup you’ve never restored and a server you’ve never rebooted are the same superstition wearing different hats. You don’t know either one works until you try it — so try it on a quiet Tuesday, before something else tries it for you.
Practical checklist
- Installed ≠ running. After a kernel update, compare
uname -r(running) with the newest version in/bootorrpm -q kernel/dpkg -l 'linux-image*'(installed). If they differ, a reboot is pending. - Reboot on your schedule, not fate’s. Pick a quiet window, announce it if anyone depends on the box, and watch it come back up.
- Keep the fallback. Distros retain older kernels in the boot menu — that’s your safety net if the new kernel misbehaves.
- Persist your changes. Live firewall rules, manual mounts, hand-started services: if it isn’t in config, it dies at reboot. A planned reboot is exactly how you find these before an unplanned one does.
- Livepatching buys time, not absolution. Useful for critical CVEs on boxes that genuinely can’t reboot right now — but the real kernel still waits at the next boot.
- RHEL family: read past the dash. The kernel version is frozen for the release’s lifetime; the release number after the dash (and the
el9_xsuffix) is your real patch level. Check the receipts withrpm -q --changelogagainst the running kernel. - Plesk admins: the kernel is yours. Plesk’s automatic system updates exclude kernel packages entirely — they never appear in the Update Manager. Schedule your own kernel check + reboot cadence.
Also: have fun and enjoy!