Linux sysrq-trigger: How to Force a Kernel Panic

The /proc/sysrq-trigger file in Linux provides a direct interface for executing Magic System Request (SysRq) commands from the command line, including intentionally forcing a kernel panic. This article explains the technical purpose of this interface, demonstrates how to trigger an immediate panic using the file, and outlines the primary use cases—such as testing kernel crash dumps (kdump), simulating hardware failure, and recovering diagnostics from unresponsive systems.

What Is the sysrq-trigger File?

The /proc/sysrq-trigger entry is a virtual, write-only file exposed by the procfs virtual filesystem. It acts as a software hook into the Linux kernel's Magic SysRq subsystem. While SysRq commands were traditionally executed via physical keyboard shortcuts (Alt + SysRq + <command key>), /proc/sysrq-trigger allows administrators to invoke the same low-level kernel routines over headless connections, SSH sessions, and automated scripts.

Because this interface operates at the core kernel level, it bypasses userspace limitations and can accept commands even when standard system utilities, daemons, or shells are malfunctioning.

How to Force a Kernel Panic

To force a kernel panic using this interface, root privileges are required to write the character c into the trigger file:

echo c > /proc/sysrq-trigger

When the kernel receives the c argument, it deliberately performs a NULL pointer dereference. This illegal memory access immediately crashes the kernel and triggers an intentional panic.

Prerequisite Configuration

For this command to work, the Magic SysRq feature must be enabled in the running kernel. You can check the current status by inspecting /proc/sys/kernel/sysrq:

cat /proc/sys/kernel/sysrq

To enable all SysRq functions immediately at runtime:

echo 1 > /proc/sys/kernel/sysrq

Primary Purposes of Forcing a Kernel Panic

Forcing a panic is inherently disruptive, but it serves critical administrative and engineering roles:

1. Testing Kdump and Vmcore Generation

The primary purpose of forcing a kernel panic via sysrq-trigger is verifying that the Linux crash dump mechanism (kdump) functions properly. When a system panics, kexec boots a secondary capture kernel to copy the crashed memory space into a vmcore file. Writing c to /proc/sysrq-trigger validates that the secondary kernel boots correctly, target storage mounts, and memory dumps are captured without waiting for a real, unpredicted production crash.

2. High-Availability Cluster and Fencing Validation

Enterprise clusters (such as Pacemaker or Corosync) utilize fencing mechanisms like STONITH ("Shoot The Other Node In The Head") and kernel watchdogs to isolate failing nodes. Engineers force a panic using sysrq-trigger to simulate abrupt node failure, ensuring the remaining nodes detect the drop, initiate failover routines, and prevent split-brain conditions.

3. Capturing Diagnostics from Frozen Systems

When a system suffers from severe deadlocks or driver freezes where userspace processes cannot be terminated normally, sending a panic command forces the kernel into a diagnostic state. This action dumps CPU registers, stack traces, and active process states to the serial console or system logs before shutting down, providing the post-mortem data necessary to identify the root cause.

Operational Risks

Forcing a panic via echo c > /proc/sysrq-trigger does not perform a graceful shutdown. Open files are not flushed to disk, running databases cannot commit transactions, and filesystems are not cleanly unmounted. To minimize data corruption before a deliberate panic, administrators often flush dirty buffers and remount filesystems as read-only by issuing preparatory SysRq signals:

sync
echo s > /proc/sysrq-trigger  # Sync dirty memory buffers to disk
echo u > /proc/sysrq-trigger  # Remount filesystems as read-only
echo c > /proc/sysrq-trigger  # Trigger the crash