CloudLinux "Reboot to Update Kernel" — The Field Guide

"CloudLinux Manager Dashboard shows: Reboot your system to update the kernel." You've seen this banner. You've been ignoring it for three weeks. And now you're here.

I've stared at this exact message hundreds of times across customer servers. Sometimes it's important; sometimes it's harmless; sometimes ignoring it for too long causes the very downtime you were trying to avoid. This is the no-nonsense field guide.

What the message actually means

CloudLinux ships kernel updates regularly — security fixes, LVE (Lightweight Virtualised Environment) improvements, file-system patches. When a new kernel is installed via yum or your control panel, the files are updated on disk, but the running kernel in memory is still the old one. A normal Linux server requires a reboot to load the new kernel.

The dashboard banner is CloudLinux telling you: "I notice the on-disk kernel version is newer than the running kernel. You should reboot."

Three possible underlying situations:

1. You haven't rebooted since a kernel update. The most common case. Reboot and the banner goes away.
2. KernelCare is installed but stopped or not licensed. KernelCare patches the running kernel in memory without reboot. If it stopped working, the banner reappears.
3. A failed kernel install (rare). The new kernel files are partially installed. Reboot will fail or boot the old kernel anyway.

Knowing which case you're in matters because the fix is different for each.

Step 1 — Check which situation you're in

SSH in as root and run:

uname -r                           # the currently running kernel
rpm -q kernel --last | head -3     # the installed kernel(s), newest first

Compare the two:

• Running == newest installed → you've already rebooted; the banner is stale. Refresh the dashboard.
• Running < newest installed → you have a pending reboot.

Also check KernelCare status:

kcarectl --info

If you see a recent patchset and the message "Up-to-date", KernelCare is doing its job — the banner is from a legacy code path that doesn't always recognize live-patched kernels. Less urgent.

If you see "Not licensed", "License expired", or no response at all, KernelCare isn't protecting you. The pending kernel update is real and the security fixes aren't applied.

Why KernelCare exists — the zero-reboot solution

KernelCare is CloudLinux's own product. It applies kernel security patches to the running kernel in memory, without reboot. For hosting providers running 100+ servers, this is the difference between "schedule reboots monthly" and "the kernel just stays patched continuously."

Two flavours:

• KernelCare — bundled with CloudLinux Premium / Imunify licenses on many hosts. Check your control panel.
• KernelCare Enterprise — paid separately. ~$3.95/server/month at the time I last priced it. Works on RHEL, CentOS, AlmaLinux, Rocky, Ubuntu, Debian — not just CloudLinux.

If you're running a serious hosting operation, license KernelCare. The cost is dramatically lower than the cost of one unplanned outage from a delayed reboot.

Step 2 — Safely reboot the server

If you've confirmed you need a reboot, here's the procedure I run on every production CloudLinux server. Skip steps at your own risk.

Pre-reboot checklist

# 1. Confirm a recent backup exists
ls -lh /backup/    # or wherever your backups land
df -h              # confirm disk has space

# 2. Check what's running
systemctl list-units --state=running | head -20

# 3. Confirm cPanel/WHM, MySQL, and httpd will come back on boot
systemctl is-enabled cpanel httpd mysqld

# 4. Verify network config will persist
nmcli connection show
cat /etc/sysconfig/network-scripts/ifcfg-*

# 5. Note current uptime so you know what's normal
uptime

If systemctl is-enabled returns disabled for cPanel or httpd, fix that before rebooting:

systemctl enable cpanel httpd mysqld

I have seen servers reboot and not come back because the previous admin disabled a critical service during troubleshooting and forgot to re-enable it.

Drain traffic (optional but recommended)

If you have multiple servers behind a load balancer, drain this one first. If it's a single-server install, schedule the reboot for low-traffic hours and consider putting up a maintenance page.

The reboot

# Verify everything once more
uname -r          # current kernel
rpm -q kernel --last | head -1  # newest installed kernel

# Sync filesystems before pulling the rug
sync; sync; sync

# Reboot
shutdown -r now "Kernel update reboot — back in 2 minutes"

shutdown is gentler than reboot: it gives services 60+ seconds to flush state. reboot -f is the equivalent of pulling the plug. Don't use it unless you're already convinced the system is wedged.

Post-reboot verification

Once the server comes back:

uname -r                                  # confirm new kernel is running
uptime                                    # should be <5 min
systemctl list-units --state=failed       # any service that didn't come back?
systemctl status cpanel httpd mysqld      # spot-check critical services

# Test the actual user-facing surface
curl -I https://yourdomain.com            # HTTP status?
mysql -e "SELECT 1"                       # database reachable?

If list-units --state=failed shows anything, fix it now. I've seen reboots that look fine but Imunify360 or LiteSpeed didn't restart properly and stayed offline for hours.

What to do when the reboot fails

The server doesn't come back. Two scenarios:

Scenario A: Server pings but services don't respond

The kernel booted; userspace didn't fully start. Connect via your hosting provider's console (KVM/VNC/serial) and check:

journalctl -b -p err     # show errors from the current boot
systemctl --failed

Common causes: corrupted MySQL ibdata, full disk, broken cPanel update, missing kernel module.

Scenario B: Server doesn't come back at all

The new kernel won't boot. You need console access. From your hosting provider's KVM:

1. At the GRUB menu, pick the previous kernel version.
2. Once booted on the old kernel, set GRUB's default back temporarily: grub2-set-default 1 (or whatever index the old kernel is).
3. Investigate why the new kernel failed: check /var/log/messages for hardware compatibility, check dracut initramfs, etc.
4. If you can't resolve it, file a ticket with CloudLinux support and reference the failed kernel package version.

This is exactly why you keep multiple kernels installed (default behavior — don't disable it). yum-utils defaults to keeping the 5 most recent.

Step 3 — Set up KernelCare so you never have to do this again

If your provider includes KernelCare, install it once and forget about it:

# Install
curl -s -L https://kernelcare.com/installer | bash

# Verify
kcarectl --info

# Force a check (normally automatic every 4 hours)
kcarectl --update

License activation depends on your provider. CloudLinux includes KernelCare for many customers — check kcarectl --info output. If it says "Not licensed", contact your hosting provider or buy a KernelCare key directly from kernelcare.com.

Once KernelCare is active, the dashboard banner will stop appearing after kernel updates — your running kernel stays patched continuously without reboots.

Step 4 — Monitor it so you don't get surprised again

If you run more than two CloudLinux servers, you want this in your monitoring. Two simple checks:

# 1. Reboot-pending check (returns 1 if reboot needed, 0 otherwise)
running=$(uname -r)
installed=$(rpm -q kernel --last | head -1 | awk '{print $1}' | sed 's/kernel-//')
[ "$running" = "$installed" ] && echo 0 || echo 1

# 2. KernelCare health
kcarectl --info | grep -q "Up-to-date" && echo 0 || echo 1

Wire these into your monitoring of choice (UptimeRobot HTTP checks via a tiny PHP endpoint, Zabbix items, Datadog custom metrics, Prometheus node-exporter textfile). Alert when either returns 1 for more than a configurable window (I use 7 days for reboot-pending, 1 hour for KernelCare).

Common pitfalls (and how to spot them)

"I rebooted, but the dashboard still shows the banner." CloudLinux Manager caches state. Refresh the page, or restart the cagefs service: systemctl restart cagefs. If still stuck after 10 minutes, the banner is stale and refreshes after the next periodic check.

"kcarectl --info reports up-to-date, but security scanners still flag the kernel as vulnerable." Most scanners read the kernel version from uname, not the live patch level. This is a scanner limitation, not a real vulnerability. Use scanners that understand live-patching, like Imunify360 with the proper KernelCare integration.

"My server runs cPanel and the update broke EasyApache after reboot." Rebuild it: /scripts/easyapache --build. Subscribe to your control panel's update channels carefully — major version jumps shouldn't happen during the same window as a kernel reboot.

"I'm afraid to reboot because the previous admin left undocumented state." Reasonable fear. Run a documented service-restart drill before the actual reboot: stop and start cPanel, MySQL, and any custom services individually. If any fail to restart, you've discovered a latent issue before it bites you during the reboot window.

My take — the policy I run on every hosting client

1. License KernelCare on every production server. Stop thinking about reboots as a separate task.
2. Schedule reboots quarterly anyway. Kernel updates aren't the only thing that benefits from a fresh boot. Drivers, glibc, libssl — clean reboot every 90 days catches drift before it becomes an emergency.
3. Always have console access to your VPS / dedicated server. If your provider doesn't offer it, switch providers. The day you need it is the day you can't get it.
4. Document the "if it doesn't come back" runbook alongside every server in your inventory. The middle of an outage is not the time to figure it out.

Going further

• CloudLinux OS kernel docs
• KernelCare docs
• CloudLinux OS components overview

I manage CloudLinux fleets for hosting businesses — kernel hygiene, KernelCare licensing, monitoring, automated reboots, the works. If you're tired of seeing this banner across your servers, tell me about your setup and I'll send a quote in 24 hours.