Free — no signup required

The Magic SysRq Key

3 min read

The Emergency Eject Button

Imagine a car whose steering wheel is locked and the brakes have failed. You can't steer or stop normally — but you can still pull the handbrake, which bypasses the normal braking system entirely. The Magic SysRq key is Linux's handbrake.

When a server completely freezes — the display is locked, SSH connections time out, and the OOM killer isn't responding — the normal software stack is unresponsive. But the keyboard interrupt handler runs at a lower level than the graphics stack, the shell, or even most kernel threads. The SysRq mechanism hooks directly into this interrupt path, giving you a way to issue commands to the kernel even when everything else is dead.

Enabling SysRq:

The feature is controlled by /proc/sys/kernel/sysrq. The value is a bitmask:

Value Meaning
0 Completely disabled
1 All functions enabled
2 Enable control of console logging level
16 Enable sync command
32 Enable remount read-only
64 Enable signaling of processes
128 Allow reboot/poweroff
176 Safe subset: sync + remount + reboot (16+32+128)

Production servers often use value 176 — enough to safely recover from a freeze without allowing arbitrary process signaling from the keyboard.

How to use it:

Hold Alt + SysRq (the Print Screen key on most keyboards) and press a command key. On some systems you must press and release SysRq between each command key.

The REISUB sequence — safe reboot from a frozen system:

Type these letters slowly (2–3 seconds apart) while holding Alt+SysRq:

Key Action Why
R Raw Reclaim keyboard from X server
E tErminate Send SIGTERM to all processes (graceful shutdown)
I kIll Send SIGKILL to remaining processes
S Sync Flush all dirty pages to disk
U Unmount Remount all filesystems read-only
B reBoot Hard reset

Mnemonic: Reboot Even If System Utterly Broken.

The S and U steps are the critical ones. Without them, a hard reset leaves dirty write buffers unflushed, which means the filesystem journal has uncommitted transactions. On next boot, fsck must replay the journal — and if the journal itself is corrupt, you may lose data or be unable to mount the filesystem at all.

Remote equivalent via SSH (when you can still connect): the same letters can be written directly to /proc/sysrq-trigger instead of typed via the keyboard interrupt path, letting you drive the same sync-remount-reboot sequence over a network connection. This is useful when a server is partially responsive — SSH works but the system is otherwise degraded.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free