The update installed cleanly. apt upgrade finished without a single red line. But the new kernel isn't running — and it won't be until you reboot. Here's the operator's playbook for making that reboot boring.

The gap nobody talks about

Here's a sentence that has ended careers quietly: "the patch is applied." On Linux, installing a kernel update and running a kernel update are two different facts. The package manager writes new files to /boot. The kernel actually executing in memory is the old one, and it stays the old one until the machine reboots.

Verify this on any machine right now:

uname -r            # the kernel that's RUNNING
dpkg -l 'linux-image-*' | grep ^ii   # the newest kernel INSTALLED (Debian/Ubuntu)
# or: rpm -q kernel                   # (Fedora/RHEL)

If those two disagree, you're patched on disk and vulnerable in memory. Every fleet has a few of these — machines someone updated six months ago and never rebooted. Check yours today; you might be surprised.

Do you even need to reboot?

Not every kernel update demands an immediate reboot of every machine. The honest signals:

  • Debian/Ubuntu: the file /var/run/reboot-required exists when the packaging system thinks you should reboot. cat /var/run/reboot-required.pkgs tells you which package asked for it.
  • RHEL/Fedora: needs-restarting -r (from the dnf-utils package) exits nonzero when a reboot is required.
  • Anything: checkrestart from the debian-goodies package finds processes still using deleted libraries after an upgrade — a reboot-adjacent problem that's worth fixing in the same window.

Internet-facing servers with memory-safety fixes pending: reboot soon. A laptop you'll close tonight anyway: just reboot when it's convenient. A database primary in the middle of a busy quarter: that's what the rest of this article is for.

Options that skip the reboot (and their trade-offs)

Live patching applies critical kernel fixes to the running kernel without rebooting. Canonical offers Livepatch with a free tier for personal use on Ubuntu; TuxCare's KernelCare covers more distros commercially. This is genuinely useful for bridging the gap between patch release and your next maintenance window. It is not a substitute for rebooting eventually — live patches are a curated subset of fixes, and they accumulate.

kexec skips the firmware and bootloader on reboot, jumping straight from the old kernel into the new one. A kexec reboot can take seconds instead of minutes, which matters on machines with slow POST (looking at you, servers with forty disks). systemctl kexec on systemd machines does it in one command. Caveat: it skips firmware updates too, so don't let kexec become an excuse to never cold-boot.

Unattended reboots are the set-and-forget endgame. Debian/Ubuntu's unattended-upgrades supports Unattended-Upgrade::Automatic-Reboot "true"; with a configurable Automatic-Reboot-Time. Pair it with a staggered time across your fleet and patch Tuesdays become a non-event. Just make sure something pages you if a machine doesn't come back.

The staggered fleet reboot

For anything that matters, never reboot the whole fleet at once. The boring, correct sequence:

  1. One canary node first. Reboot it, watch your health checks go green, then wait one full monitoring cycle before touching the next.
  2. Then the rest, in waves. Halve the fleet, then halve again. If a kernel regression exists — and they happen, even in stable trees — you find it on 1% of capacity, not 100%.
  3. Respect the unlock problem. Full-disk encryption means a reboot stops at a passphrase prompt. If you encrypted your root disk and your machine reboots at 3 AM, it sits at the prompt until morning. Options: TPM2-based automatic unlocking (worth setting up once), a remote unlock mechanism like Dropbear in initramfs, or simply scheduling encrypted machines for daytime reboots when a human is around.

The checklist

Tape this to your runbook:

  • uname -r vs installed kernel — do they match?
  • /var/run/reboot-required or needs-restarting -r — is a reboot actually pending?
  • Internet-facing first, internal second, canaries before fleets.
  • Encrypted disks: confirm the unlock path before scheduling the reboot.
  • After reboot: uname -r again. The number should have changed. If it didn't, your bootloader is pointing at the old kernel — a different problem, and now you know.

Kernel release days are the project doing its job. Reboot days are you doing yours. Make them boring on purpose.

Sources: Debian Wiki — UnattendedUpgrades, Ubuntu Livepatch documentation, kernel.org — kexec documentation.