Linux Kernel rebootless patching for High Availability

Go straight to an AI summary of this blog post instead

Key Takeaways

Linux kernel rebootless patching applies security fixes to a running kernel, so remediation stops waiting on reboots.
In this blog post, we examine a five-person team covering roughly 10,000 critical trading systems without a single mandatory patching reboot.
Reboot intervals doubled, moving from about six months to about a year and becoming optional maintenance events.
Removing the reboot dependency cut cross-team coordination and kept PCI DSS remediation off the maintenance calendar.

A trading platform can survive a lot of bad days. A kernel reboot in the middle of order execution is not one of them.

There is a gap between a kernel fix existing and a production system actually being protected. The update lands, then someone has to find a window, get change approval, line up application owners, and restart the machine. Linux kernel rebootless patching closes that gap by applying eligible security fixes to the running kernel, so protection stops depending on the reboot.

Now scale the problem. Five engineers. Roughly 10,000 critical systems across multiple data centers, primarily RHEL-based and largely AlmaLinux. PCI DSS on top of that, plus additional security and audit standards that expect known vulnerabilities to be remediated on something better than a geological timescale.

That was the situation at one global financial services provider, where uptime maps directly onto revenue and even minor disruption to order execution hits the books.

When kernel patching becomes an operational project

Reboot-driven patching ran roughly every six months. Not because anyone thought half a year of exposure was acceptable, but because that was the cadence the coordination could actually support. Planning a single cycle could consume days of the team lead’s time before the wider business was even involved, and every app owner and change approver had a different opinion about when a system could go dark.

Six months, and it still fell short. Security and compliance teams wanted faster remediation. The engineering team was already strained at that frequency. Both of those were true at the same time, which is usually the sign that the process is broken rather than the people running it.

Most of that cost never shows up in a ticket queue. It goes into scheduling calls, rollback planning, and dependency checks. None of it patches a single additional CVE.

The maintenance window math never worked

Here is how the team lead described the scheduling problem:

“These systems are critical; you can’t stop them. If you stop them, only during certain maintenance windows. Those windows were practically impossible to hit because they’re too short, and you’d need like 100 people to reboot everything.”

That is the arithmetic every high-availability shop eventually runs into. Windows get shorter as the business goes global, the fleet keeps growing, and headcount does not.

At a few hundred hosts, you can brute force your way through a reboot weekend and call it a plan. At 10,000 critical systems with five people, brute force stops being available, and the patch backlog becomes a permanent fixture of the environment. Hiring 100 people for every kernel CVE is not a strategy.

If your reboot capacity grows with your fleet, scheduled windows can still work. If it doesn’t, the only real fix is to stop tying vulnerability remediation to reboots at all.

What rebootless patching changed for a five-person team

After evaluating several options, the organization chose TuxCare’s KernelCare and deployed it across approximately 10,000 of its most critical systems. Testing showed reliable, consistent patch delivery, and the rollout was managed centrally through ePortal so five people could keep visibility across all of it.

Mandatory patching reboots dropped to zero. Reboots still happen, but the interval stretched from about six months to about a year, and their purpose changed along the way. They became optional maintenance events instead of prerequisites for fixing kernel vulnerabilities. Cross-team coordination for kernel patching all but disappeared, and so did the days of planning that used to precede it.

Patch delivery also changed shape. Instead of accumulated fixes landing in one tense window, patches apply continuously, so risk stops piling up on long-running systems.

Why this matters for PCI DSS and audit evidence

Compliance frameworks measure elapsed time. Effort does not enter into it. PCI DSS expects security patches for critical and high-risk vulnerabilities to be installed within a set window after release, and an auditor asks for evidence that the deadline was met rather than an explanation of why the maintenance window slipped.

A six-month cycle guarantees a gap between a patch existing and that patch being applied. Across 10,000 systems, that gap is documented in every scan report, quarter after quarter. Taking the reboot out of the loop closes it without adding a single window to the calendar.

Who should read this

Anyone running high-availability Linux under audit pressure with a team smaller than the fleet arguably deserves. Trading platforms are the obvious case, but the same math applies to databases, clustered workloads, telecom, payment processing, and any customer-facing service where “just reboot it” is not a security strategy.

The case study covers why the six-month cycle became unsustainable, what the team looked for while evaluating rebootless patching, and what changed for compliance and day-to-day workload afterward, largely in the organization’s own words. It is a short read, and specific about numbers rather than adjectives.

Read the full case study:

Keeping Global Trading Systems Secure Without Breaking Uptime →

Summary