Limit CPU Usage


Verified User
Jun 27, 2019
The issue with Kernelcare and using stock CentOS (not sure what else they support... do they support Debian stock kernels?) is the rather lengthy delay in getting a patch issued. It can easily be two or three weeks after a new kernel has been released by CentOS before Kernelcare picks it up with a patch. So while you get reboot-less kernel updates... you just have to hope it's not patching something urgent.

They're probably more focused on patching their CloudLinux kernels... and I don't blame them.

Kind of a shame that there's not a competitor to Kernelcare. Although... doesn't RHEL natively support reboot-less kernel updates? At least starting with RHEL 7... I thought I remembered reading something about that.

I do go the kexec route myself. Technically you're "rebooting" the server to load the new kernel, but instead of loading through the BIOS and all of the POST tests as soon as the kernel gets unloaded it immediately starts into loading the new kernel. So instead of maybe a 5 minute reboot, you're looking at 30 seconds or so. But you do still have to deal with thundering herd as the services come back online, because memory has been dumped.

I do remember way back when - there was a kernel update and K-Splice (is K-Splice still around? I don't think you can get a license for it now. K-Splice was rebootless kernels before Kernelcare) had to tell all of their clients to reboot their servers. That's always hung with me. While the notion of applying a kernel update without rebooting is nice... I still think there's situations where rebooting (or kexec "rebooting" with unload and loading kernels) is the better solution. That and the fact that Kernelcare patches for CentOS stock kernels can be rather delayed, I just go the kexec route. But that's just me.