This is a bit “out of the box”, and normally I would not recommend this. The following URL explains MagicSysRq but is probably too general to learn much by, so I’ll explain a bit more.
This special key binding system is usually for developers who might cause some part of the system to fail, and need some sort of controlled way to safely shut down or perform various debug functions when only part of the system works. This cannot save content of open applications, and perhaps may even leave data truncated in files being written to, but it can freeze the filesystem and change it to read-only. Being read-only implies there won’t be corruption needing
fsck, thus it could save the system from needing to be brought in and worked on locally even if an individual file is truncated.
Before I mention any more specifics, you’ll see the flaw that the keyboard needs to be connected. However, it doesn’t. The heart of this is the pseudo file “
/proc/sysrq-trigger”. Many developers perform kernel debugging using “
kgdb” and “
kgdboc” over a serial console. Echo of various values to the
sysrq-trigger file performs the same function as if the keyboard magic key combinations were run, so you can script this and perhaps assign a button or some other trigger to echo the right thing to that file.
Before starting, note that there are many key combinations available. Setup is able to disable or enable this via a mask. If you look at file “
/etc/sysctl.conf”, then you can consider mostly that this config is to automatically echo values to certain “
/proc” entries at boot. The directory “
/proc/sys” contains many
sysctl files, and the entry in “
/etc/sysctl.conf” will name paths within the “
/proc/sys” tree, although it will abbreviate and not mention that prefix. This entry, in “
/etc/sysctl.conf”, would echo “
1” to “
If you want to see the current mask:
(Jetsons would normally have this enabled, many desktop distributions would only enable parts)
Not every system supports every binding, and often a vendor will disable this entirely to prevent an end user from accessing such function. It would in fact be dangerous to call “
sync” too many times on eMMC since it causes wear. However, a system in emergency, or a system which you already know is about to shut down anyway, won’t be harmed by
sync. A while back @snarky mentioned something important, that calling
sync will start a sync, but it won’t guarantee finishing it, but if you call
sync twice in a row, then the second
sync won’t begin until the first
sync has completed.
sysrq is enabled, then these keystrokes would safely shut down a system (but would also perhaps truncate open files, leave temporary file locks open and to fail proper cleanup, so on…but the ext4 would remain uncorrupt):
# Two sync in a row:
# Unmount file systems and turn them read-only:
You could try this via sudo echos using serial console as well, or even over ethernet.
There are also other variations, such as sending SIGKILL to all processes except
init, and this could be added just after the two
sync calls, followed by two more
sync calls. You might experiment with this. For the purposes of testing you can probably use
sync quite a bit without worrying about wear leveling on the eMMC.
Some more information on using Magic SysRq:
Please keep in mind that freezing a running system and then rebooting without applications cleaning up may have side effects which cannot be predicted. However, this beats side effects in combination with corrupted filesystems, and so is still superior to just yanking out the power cable.