Trigger Linux SysRq Safely Through /proc/sysrq-trigger

One bad write to /proc/sysrq-trigger can reboot a live server in under a second, so it pays to know exactly what you are doing before you touch it. This shows how to invoke a Magic SysRq function by writing a single character to that file, check whether the interface is present, and keep it separate from the keyboard control setting. Allow about ten minutes.

You need a shell on the target host and, for an actual trigger, elevated privileges. The examples use the installed manpages package version 6.7-2 and the behaviour documented for this host's Linux interface.

1. Check the interface without changing anything

The installed manual describes /proc/sysrq-trigger as the file that invokes the same SysRq function as typing Alt-SysRq-character. Confirm it exists and check its permissions:

$ command -v man
/usr/bin/man
$ stat -c '%A %U:%G %n' /proc/sysrq-trigger
--w------- root:root /proc/sysrq-trigger
$ test -e /proc/sysrq-trigger && echo 'SysRq trigger interface is present'
SysRq trigger interface is present

The exact mode and ownership can vary, but this machine exposes a root-writable procfs file. An unprivileged account should hit a permission error on a write attempt. Do not "fix" that by loosening the file mode: the restriction is part of the safety boundary, not a bug.

2. Read the keyboard control setting

Linux also exposes /proc/sys/kernel/sysrq, which controls which functions may be invoked from the keyboard. Read it with an ordinary command:

$ cat /proc/sys/kernel/sysrq
176

• 0 disables keyboard SysRq handling entirely.
• 1 enables all keyboard functions.
• Other positive values are a bitmask, with bits for console logging, keyboard control, debugging dumps, syncing, read-only remounts, signalling, reboot or poweroff, and real-time task priority changes. The installed upstream kernel documentation lists the exact bit meanings.

3. Identify the key before you use it

SysRq command keys are case-sensitive. Here is the risk attached to each one:

• h displays help. Any other unrecognised key also shows help, but use h so the intent is obvious.
• m and t dump memory and task information. They affect kernel logging but do not intentionally reboot the host.
• s and u touch mounted filesystems. s attempts to sync them, u attempts to remount them read-only. Both can disrupt a running system.
• e, i and f kill processes. e sends SIGTERM broadly, i sends SIGKILL broadly, f invokes the out-of-memory killer.
• b and c are the destructive ones. b reboots immediately without syncing or unmounting disks, c triggers a kernel crash. Treat both as service-ending.

The full list belongs to the kernel's own SysRq documentation. Never substitute a guessed character, and never paste a multi-character string into this file as a shortcut for a sequence.

4. Run the harmless help test

Writing to the trigger requires elevated privileges. This command changes kernel activity by emitting help into the kernel log or console, so run it only when that output is acceptable:

$ printf 'h' | sudo tee /proc/sysrq-trigger > /dev/null
[sudo] password for USER:
$ printf 'trigger exit status: %s\n' "$?"
trigger exit status: 0

tee is used deliberately. Putting sudo only before a shell redirection would leave the redirection itself running as the unprivileged user. If the command fails, suspect a missing interface, insufficient privilege, a kernel without Magic SysRq support, or a restricted environment.

Check the kernel log if you need to confirm the response and your system permits reading it:

$ sudo dmesg | tail -n 30

Log visibility depends on the kernel and system policy. No visible output does not prove the write failed. The exit status confirms the write completed, not that a particular line appeared on your console.

5. Handle one character only

The manpage defines the interface in terms of writing a single character. Current kernel documentation says the first character is processed and warns that extra characters, outside the documented sequence form, have undefined future behaviour. Keep every ordinary invocation to one character:

$ ACTION='h'
$ case "$ACTION" in
    h|m|t) printf '%s' "$ACTION" | sudo tee /proc/sysrq-trigger > /dev/null ;;
    *) printf 'Refusing unreviewed SysRq key: %s\n' "$ACTION" >&2; exit 1 ;;
   esac

This small allow-list is a useful guard in a script, but it is not a replacement for reviewing the action. Expand it only after checking the kernel documentation and the operational effect on the specific host.

6. Change the keyboard setting only when you mean to

Changing /proc/sys/kernel/sysrq is a separate, runtime configuration change. It does not undo an earlier trigger and it does not disable the privileged procfs interface. Record the current value before changing it:

$ OLD_SYSRQ=$(cat /proc/sys/kernel/sysrq)
$ printf 'saved keyboard setting: %s\n' "$OLD_SYSRQ"
saved keyboard setting: 176
$ printf '0' | sudo tee /proc/sys/kernel/sysrq > /dev/null
0

That disables keyboard SysRq invocation, nothing more. It does not stop an administrator writing to /proc/sysrq-trigger. Restore the previous value when the maintenance window ends:

$ printf '%s' "$OLD_SYSRQ" | sudo tee /proc/sys/kernel/sysrq > /dev/null
$ cat /proc/sys/kernel/sysrq
176

If the shell holding OLD_SYSRQ has gone away, restore the value you wrote down instead of guessing a distribution default. These procfs changes are runtime state, not durable boot configuration.

Common traps

• Writing with a bare redirection. sudo echo h > /proc/sysrq-trigger fails because the shell performs > before sudo runs; use sudo tee or a root shell for the redirection.
• Testing with a destructive key. b, c, i and u are not harmless diagnostics.
• Confusing the keyboard switch with the file's access control. /proc/sys/kernel/sysrq governs keyboard invocation, not the administrative procfs path.
• Writing a whole word instead of a character. Only the first character is meant to be processed by this simple interface; extra characters are not a safe way to queue actions.