SysRq Key?


Well there are user defined button keys that can be programmed to fill that task.
 
Maybe we need a poll to ask if we want that button as default in the kernel.
But all the distros i tried in the past years have that deactivated anyway so its probably not usefull enough to have anyone care about.
 
It's mostly useful to shutdown without damaging your filesystem if your system froze. You can use it to manually sync disks, unmount filesystems, reboot, etc. without having any kind of command-line. As long as the kernel itself isn't frozen I believe the key works.
 
Yes, I recall you need to enable it first in most linuxes these days, feature by feature. I looked it up once, but I've never found a need to use it on any of my systems, even though my system used to lock up if I accidentally started PCmanFM. I used to just wait for the disks to sync then held down the power button, and tried not to do anything that would start the file manager, before eventually just uninstalling it.
 
Maybe this is the appropriate function to assign to the super secret key combo... SuperSquared + key.

The Pyra logo key between the nubs is a "Super" key behind the scene - I think we called it Left Super. The other (Right) Super was assigned to the lid switch.

SuperSquared would be pushing the keyboard Super key while holding a magnet near the hall effect switch for the lid.

So, it would then be 'double super shifted' Just press a key assigned to SysReq while holding the other two.

Or you could just assign it to the Fn+Shift layer of something.

All threads are keyboard threads.
 
_mostly_
And since _modern_ file systems (since ext2 maybe?) are barely damagable by just a freeze i have to ask: What else can it do?
There are times, especially on my currently used Athlon® with 500mb ram, that i beg to have a key to kill the most cpu or memory hungry process so that i dont need to enter kill commands in a tty that takes minutes to respond.
But i guess that would be asking for too much...
 
I'd probably want it as both shoulder buttons on one side, either right or left, and the Pyra button. The magnet thing sounds nice at first, but if it's anything like the one in the 3DS, it's a huge pain in the arse to put the magnet in the right spot while also holding down a button.
 
_mostly_
And since _modern_ file systems (since ext2 maybe?) are barely damagable by just a freeze i have to ask: What else can it do?
There are times, especially on my currently used Athlon® with 500mb ram, that i beg to have a key to kill the most cpu or memory hungry process so that i dont need to enter kill commands in a tty that takes minutes to respond.
But i guess that would be asking for too much...
Yes, You can manually trigger the OOM Killer (SysRq+f)
 
_mostly_
And since _modern_ file systems (since ext2 maybe?) are barely damagable by just a freeze
There is more damage to be taken than just the filesystem that may be corrupted by incomplete transactions. For example, the log messages that contain the reason for the freeze/crash may never make it onto persistent memory. Or an SSD firmware may cause damage to the filesystem that goes beyond what can be rescued by a journal due to the sudden power loss that a manual emergency power-off that follows such a crash may entail - which has already happened to me twice and required a firmware update to get rid of.

Especially btrfs is notorious for replacing currently opened files with empty shells, even if they are only open for read access. Of course the filesystem stays in a sane state, but you may still end up with an unbootable system. ext3/4 may not be as susceptible to these kind of damages, but it was designed with a sacrificial mindset as well: filesystem integrity has a higher priority than the files stored within.
 
There is more damage to be taken than just the filesystem that may be corrupted by incomplete transactions. For example, the log messages that contain the reason for the freeze/crash may never make it onto persistent memory. Or an SSD firmware may cause damage to the filesystem that goes beyond what can be rescued by a journal due to the sudden power loss that a manual emergency power-off that follows such a crash may entail - which has already happened to me twice and required a firmware update to get rid of.

Especially btrfs is notorious for replacing currently opened files with empty shells, even if they are only open for read access. Of course the filesystem stays in a sane state, but you may still end up with an unbootable system. ext3/4 may not be as susceptible to these kind of damages, but it was designed with a sacrificial mindset as well: filesystem integrity has a higher priority than the files stored within.

Pandora and Pyra have a neat way to conquer this. Keep a bootable backup copy of the OS drive/partition on the device itself. I used to keep a 2nd copy of my OS install on the first partition of the card in the left SD card slot on the Pandora. I plan to do the same on the internal microSDXC on the Pyra. I had the primary OS on my Pandora freak out when I was standing in line to board a plane - the only time it ever did that. I was rebooted to the 2nd OS instance before I got to the front of the line.
 
Back
Top