Kernel Live Patching Doesn't Mean You Can Skip Linux Reboots Forever

A lot of VPS owners treat kernel live patching as a permanent exemption from reboots. The thinking goes: kpatch or Livepatch is installed, security fixes land in the running kernel, so the uptime counter can keep climbing forever. Live patching is a genuinely useful tool, but it was built to shorten the time a server stays exposed before the next reboot. It was never designed to replace that reboot. The gap between those two ideas usually stays invisible until something goes wrong: a vulnerability scanner keeps flagging the server, a bug fix never arrives, or the machine finally restarts after a host-level event and does not come back cleanly.

What a live patch actually changes

A kernel live patch is a small kernel module that contains replacement versions of specific functions. When it loads, the kernel uses its function tracing infrastructure (ftrace) to redirect calls from the old function to the new one. The original code is still in memory. It just stops being called. The switch also does not happen for every process at the same instant. The kernel moves each task to the patched code once that task is not in the middle of running one of the affected functions. Most systems finish this transition quickly, but it is a per-task handover, not a clean swap of the whole kernel. Two things follow from this. First, the running kernel is still the same build. uname -r reports the same version as before, which is why compliance tools that only compare version strings keep reporting the server as vulnerable. That confusion is common enough that it has its own article: why uname -r still shows the old kernel after a security patch. Second, a live patch can only do what function replacement can do. That is where the limits come from.

The fixes a live patch cannot carry

Function replacement works well for a fix like adding a missing bounds check or correcting a condition. It gets hard or impossible when the fix needs something else:

Changing the layout of a data structure that is already in use by live objects in memory. There are workarounds such as shadow variables, but they add complexity and not every fix fits them.
Changing code that only runs at boot or initialization. That code already ran. Patching it changes nothing for the current boot.
Changing low-level entry code, assembly, or functions that are inlined or excluded from tracing, because there is no clean call site to redirect.

Then there is scope. Building and testing a live patch is real engineering work, so vendors typically ship them only for selected high-severity security issues. Ordinary bug fixes, driver updates, performance changes, filesystem fixes, and many hardening changes usually arrive only in a full kernel package. Check your vendor's policy, but assume a live patch stream is a subset of the fixes in the regular kernel updates, not a mirror of them. Live patching also says nothing about anything outside the kernel. CPU microcode updates and userspace libraries like glibc or OpenSSL need their own handling. A library update requires restarting every process that still has the old copy mapped, and some microcode or firmware changes are only fully applied at boot.

Live patches expire too

Each live patch is built against a specific kernel build. Vendors typically keep producing patches for a given kernel only for a limited period, after which you are expected to move to a newer kernel. If a server keeps running the same kernel past that point, live patching keeps reporting as active while new fixes quietly stop arriving. It is worth checking what is actually loaded instead of trusting that the service is enabled:

BASH

# Kernel build that is actually running
uname -r

# Live patch modules loaded into this kernel (generic sysfs view, if supported)
ls /sys/kernel/livepatch/

# RHEL-family systems using kpatch
kpatch list

# Ubuntu systems using Canonical Livepatch
canonical-livepatch status --verbose

Only the tools you have installed will respond, and the output format differs between versions. What you are looking for is whether patches are loaded and enabled, and whether the vendor tool says your running kernel is still supported. If it reports the kernel as no longer eligible, the only way to get future fixes is to boot a newer kernel. Also confirm what kind of VPS you are on. On KVM, the guest runs its own kernel and live patching inside it makes sense. On a container-based VPS, such as LXC on Proxmox, every container shares the host kernel, so the kernel is patched and rebooted by whoever runs the host. If you are not sure which one you have, this comparison of Proxmox LXC and KVM covers the difference.

Long uptime hides a different problem

Even if every relevant fix were live patchable, skipping reboots has a cost that has nothing to do with security. Every change made since the last boot is untested at boot time. A new mount added to /etc/fstab with a typo, a service started by hand but never enabled, firewall rules added at runtime but never saved, a network config edited months ago, a GRUB default that points somewhere unexpected. None of these show up while the server keeps running. They show up when the server reboots on its own schedule instead of yours: a host maintenance event, a kernel panic, a power issue at the data center. From the support desk, this is a familiar pattern. A server with very long uptime restarts, sites stay down, and the cause turns out to be several unrelated changes stacked up over months, each of which would have been trivial to catch alone. A planned reboot is also a regular test that the machine can recover. The longer you wait, the more changes go into that test at once, and the harder it is to tell which one broke it.

A production pattern that uses both

The sensible approach treats live patching and reboots as two layers that do different jobs:

Use live patching to close the window on urgent kernel vulnerabilities right away, without waiting for a maintenance slot.
Keep installing full kernel updates through the normal package manager, so the newer kernel is ready to boot.
Schedule regular reboots into the latest installed kernel at a cadence that fits your workload, for example monthly or at the next maintenance window after a kernel update.
Before each reboot, take a snapshot or backup, confirm you have console access through your provider panel, and confirm which kernel will boot next.
For clusters or load-balanced setups, reboot one node at a time and verify it rejoins before moving to the next.

A few read-only checks help decide whether a reboot is due:

BASH

# Debian/Ubuntu: these files exist when installed packages request a reboot
cat /var/run/reboot-required /var/run/reboot-required.pkgs 2>/dev/null

# RHEL-family (dnf-utils or yum-utils): exit code 1 means a reboot is recommended
needs-restarting -r; echo $?

# RHEL-family: which kernel GRUB will boot next
grubby --default-kernel

If a new kernel is installed and the reboot-required checks agree, live patching has only bought you time. Use that time to pick a quiet window, not to forget about the reboot. The practical takeaway: treat a live patch as a temporary bridge that covers a few critical fixes on a kernel with an expiry date. Check periodically that patches are loaded and that your running kernel is still supported, and keep a reboot on the calendar anyway. A short planned restart at a time you choose is far easier to handle than an unplanned one that exposes months of untested changes.