Kernel updates and reboots — when you actually need to reboot

Every Linux distro updates the kernel periodically — security CVEs, hardware support, performance fixes. The new kernel installs alongside the running one; until you reboot, the OLD kernel is still in memory and the new one is just files on disk. This article covers when you should reboot, how to tell, and what to do if you can't.

How to tell a reboot is pending

Debian / Ubuntu:

[ -f /var/run/reboot-required ] && echo "reboot needed" || echo "no reboot needed"
cat /var/run/reboot-required.pkgs 2>/dev/null    # shows which packages triggered it

AlmaLinux:

dnf install -y yum-utils                   # if not already present
needs-restarting -r                         # exits non-zero if reboot needed

Both are scriptable — wire them into your monitoring and get a single alert when a kernel update lands rather than discovering it weeks later.

Running kernel vs installed kernel

uname -r                                    # currently running
ls /boot/vmlinuz-*                          # installed kernels
# OR
dpkg -l 'linux-image-*' | grep ^ii          # Debian/Ubuntu
rpm -qa kernel                              # AlmaLinux

If uname -r doesn't match the highest installed version, a newer kernel is waiting in the bootloader for next reboot.

What triggers a reboot need (beyond the kernel)

It's not just the kernel. The following also benefit from a reboot:

• glibc updates — every running process loads libc; restarting individual services helps but a reboot is the only way to ensure consistency.
• openssl updates — same — every TLS-using process needs to pick up the new library. needs-restarting catches this.
• systemd updates — re-exec via systemctl daemon-reexec handles most of this without a reboot, but kernel-coupled changes still need a full restart.
• Init-system core packages on AlmaLinux.

Both Debian's checkrestart (debian-goodies package) and AlmaLinux's needs-restarting can list specific services that need restarting rather than the whole box — often you can patch + restart-individual-services and skip the reboot entirely.

The reboot itself

# Tell users / services first if they care
wall "Rebooting in 60 seconds for kernel update"

# Reboot
systemctl reboot

A LYLIX VPS comes back up in 30–60 seconds. SSH session drops; reconnect once it's back. The browser-console option in the portal lets you watch the boot if it doesn't come back in the expected window.

What can go wrong

• New kernel doesn't boot. Rare but happens — driver regression, initramfs missing a module. The previous kernel is still in GRUB's menu; reboot, pick the previous one. From the LYLIX portal, the browser console gets you to the GRUB menu where you'd otherwise be blind.
• VPS comes back but a service didn't. Check systemctl --failed. Most common cause: a service that depends on something that takes longer to start than its timeout allows.
• File-system check on boot. Long-uptime VPSes (300+ days) trigger fsck at boot. Can extend boot by minutes for large filesystems. Not a failure; just wait.

Avoiding reboots: Livepatch (Ubuntu only)

Canonical's Livepatch service patches kernel CVEs without rebooting. Free for personal use up to 5 machines (Ubuntu Pro tier). Worth enabling on Ubuntu VPSes if you genuinely can't tolerate reboots:

pro attach <token-from-ubuntu-com-pro>
pro enable livepatch

Caveats:

• Only Ubuntu — Debian and AlmaLinux don't have an equivalent free livepatch offering.
• Doesn't cover all CVEs — some kernel updates still require a real reboot eventually.
• You eventually need to reboot to consolidate accumulated livepatches; don't go a full year without ever rebooting.

Scheduling policy

Pragmatic positions for different workloads:

• Personal / dev / hobby VPS: reboot when needed, anytime. The 60 seconds is fine.
• Production with paying users: set a maintenance window (e.g. Sunday 03:00 local). Reboot only in that window unless the CVE is being actively exploited.
• PBX VPS with active calls: any reboot drops active calls. Reboot during off-hours; for 24/7 call centers, plan a short window and notify in advance. ViciBox® / FreePBX® web UIs warn users they'll be disconnected.
• HA setups: reboot one VPS at a time; load balancer drains and refills around each reboot. Coordinate so you're never down to N-1 capacity for sustained periods.