Buried in the Wikipedia article is what I remember, with a note saying not to use it any more.

So what sysreq keys do you use to recover a non responsive system with a journaling file system?

Before the advent of journaled filesystems a common use of the magic SysRq key was to perform a safe reboot of a locked-up Linux computer (using the sequence of key presses indicated by the mnemonic REISUB), which lessened the risk of filesystem corruption. With modern filesystems, syncing and unmounting is still useful to force unflushed data to disk, but is no longer necessary to prevent filesystem corruption (and may increase the risk of corruption in case the lock-up is caused by the kernel being in a bad state).[11] The default value of kernel.sysrq in distributions such as Ubuntu and Debian remains 176[1]^ (allowing the sync, unmount, and reboot functions) and 438[12] (allowing the same functions plus loglevel, unraw, and nice-all-RT-tasks) respectively.

  1. citation needed ↩︎

  • Rentlar@lemmy.ca
    7·
    19 hours ago

    The function I used most often aside from the usual sequence is Alt-SysRq-F. This runs oomkiller to SIGKILL what would appear to be the process hogging the most memory. That was usually enough to get control back from an agonizingly sluggish system caused by hitting the swapspace. I didn’t need it anymore after I upgraded to 48GB of RAM.

    Another way to remember the classic mnemonic, it’s “busier” in reverse, after holding down for a second the Alt and SysRq keys (which may require a function key combo on some keyboards).

    You should check ahead of time whether the value of /proc/sys/kernel/sysrq is not zero to be sure the Sysrq functions are enabled. If not, then in /etc/sysctl.d/99-sysctl.conf you can add the line kernel.sysrq = 1 to enable all features, or a higher number to enable select features.