Trigger Linux SysRq Safely Through /proc/sysrq-trigger

You will learn how to invoke a Linux Magic SysRq function by writing one character to /proc/sysrq-trigger, check whether the interface is present, and separate the keyboard control setting from the file interface. 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.

This is a kernel control surface, not an ordinary log or configuration file. Several keys can terminate processes, remount filesystems, crash the machine or reboot it immediately. Read the action you intend to invoke before writing anything, and keep the first test to h, which asks the kernel to display SysRq help.

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 that the file exists and inspect 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. A normal unprivileged account should expect a permission error when it tries to write. Do not "fix" that by changing the file mode. The restriction is part of the safety boundary.

2. Read the keyboard control setting

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

$ cat /proc/sys/kernel/sysrq
176

A value of 0 disables keyboard SysRq handling. A value of 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.

Do not infer that this value makes a write to /proc/sysrq-trigger safe or harmless. Current kernel documentation says the setting affects keyboard invocation; the procfs trigger is separately restricted by administrative privilege. The file can therefore invoke an operation even when the keyboard setting is 0.

3. Identify the key before you use it

SysRq command keys are case-sensitive. The most useful operational distinction is the risk attached to each key:

• h displays help. Other unrecognised keys also display help, but use h so the intent is obvious.
• m prints memory information, and t prints a task dump. These affect kernel logging but do not intentionally reboot the host.
• s attempts to sync mounted filesystems, while u attempts to remount them read-only. These can disrupt a running system.
• e sends SIGTERM broadly, i sends SIGKILL broadly, and f invokes the out-of-memory killer.
• b reboots immediately without syncing or unmounting disks, and c triggers a kernel crash. Treat both as destructive, service-disrupting actions.

The full list belongs to the kernel's 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 because putting sudo only before a shell redirection would leave the redirection running as the unprivileged user. If the command fails, the likely causes are 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 that the write failed. The command's exit status confirms that 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 character. Current kernel documentation says the first character is processed and warns that extra characters without the documented sequence form have undefined future behaviour. Keep a single character in every ordinary invocation:

$ 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, not writes by an administrator 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 containing OLD_SYSRQ has gone away, restore the value you recorded before the change. Do not guess a distribution default. These procfs changes are runtime state and are not automatically a durable boot configuration.

Common mistakes

• Using sudo echo h > /proc/sysrq-trigger. The shell performs > before sudo, so use sudo tee or a root shell for the redirection.
• Testing with b, c, i or u. These are not harmless diagnostics.
• Assuming /proc/sys/kernel/sysrq is an access switch for the trigger file. It controls keyboard invocation, not the administrative procfs path.
• Writing a word such as help. Only the first character is intended for this simple interface; extra characters are not a safe way to queue actions.