Silent-Hunter
Hardcore Member
- Joined
- May 29, 2010
- Messages
- 3,485
Does the Pyra have a SysRq key? It can be useful.
Okay, thanks! I wasn't sure SysRq could be programmed into any key like that.Well there are user defined button keys that can be programmed to fill that task.
It has to be done on kernel-level, though. The kernel does not care what X is doing with the keyboard.I wasn't sure SysRq could be programmed into any key like that.
Oh, darn. I'll have to figure it out when my Pyra gets here.It has to be done on kernel-level, though. The kernel does not care what X is doing with the keyboard.
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 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...
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._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.