CentOS / RHEL 7 : Understanding Kexec and Kdump

In mission-critical environments every second of downtime matters. On CentOS and RHEL 7, kexec and kdump work together to help you recover from a kernel crash quickly and capture diagnostic information without a full hardware reboot. Kexec lets you load a new kernel directly from the running system, bypassing firmware initialization steps. Kdump uses this feature to boot into a small, reserved capture kernel as soon as the primary kernel fails, then saves a memory dump for post-mortem analysis.

In this article you will learn how to enable and configure kexec and kdump on CentOS/RHEL 7. We will cover the prerequisites, step by step setup, and how to verify that your crash dump is being captured correctly. By the end you will have a reliable process in place to minimise service interruptions and gather the data needed to diagnose and fix the root cause of any kernel panic.

1. Install the kdump tools  

This provides the kdump service and the kexec utilities.

2. Reserve memory for the crash kernel

kdump works by booting a second, minimal “capture” kernel if the primary one panics. You must set aside some RAM for that. On RHEL 7 you do this by adding a crashkernel= parameter to your regular kernel’s boot line.

1. Open the main GRUB settings:

   sudo vi /etc/default/grub

2. Find the line beginning with GRUB_CMDLINE_LINUX and append your chosen crashkernel value. For example, to reserve 128 MB at the default address:

   GRUB_CMDLINE_LINUX="... existing parameters ... crashkernel=128M"

3. Examples of other common settings:

   • Reserve 128 MB at a 16 MB offset:

     crashkernel=128M@16M

   • Reserve 128 MB at a 48 MB offset:

     crashkernel=128M@48M

   • On systems with >128 GB RAM, reserve 512 MB at a 64 MB offset:

     crashkernel=512M@64M

   • Conditional sizing by total RAM:

     crashkernel=512M-2G:64M,2G-:128M

   • Let the kernel pick a good reservation automatically (if ≥2 GB RAM):

     crashkernel=auto

4. Regenerate your GRUB configuration so the change takes effect:

   sudo grub2-mkconfig -o /boot/grub2/grub.cfg

3. Reboot and verify memory reservation

Reboot the host so the kernel reserves that memory at startup:

After reboot, confirm that overall RAM is reduced by your crashkernel size:

4. Enable and start the kdump service

You can check its status with:

If it’s active and your chosen crashkernel shows in the kernel command line, you’re set.

5. Test your configuration

Warning: This will forcibly crash the system. Only do on non-production or during a scheduled maintenance window.

1. Ensure sysrq-trigger is enabled:

   sudo sysctl -w kernel.sysrq=1

2. Trigger an immediate panic:

   echo c | sudo tee /proc/sysrq-trigger

3. The system will reboot into the kdump kernel, write out a vmcore file, then reboot back into your normal kernel.

6. Locate your crash dump

By default, kdump saves dumps under:

You can analyse vmcore with tools like crash or makedumpfile.

7. Notes

• Xen domU guests: kdump is not supported on unprivileged Xen guests. In those environments use xm dump-coreinstead.

• If you need a custom dump location or compression, see /etc/kdump.conf.