>>102418087
how can it recover from a freeze if key commands are no longer being processed?

>>102418119
because regardless of the computers state the kernel keeps those keys unfrozen

>>102418141
well thanks for letting me know about this, it would have been nice to know that there's a key combo that activated the oom killer

>>102418087
imagine the DEs and software in general being such pieces of shit that you need this to recover from constant freezes and crashes
the absolute state of loonix

>>102418192
Oh shit I forgot that one, good to know.
>>102418202
You probably pay for AAA and use gmail

>>102418202
I have experienced not a single solitary system crash in the last 15 years of using linux, not one, and I use it every day for at least 10 hours a day. Oh no wait. I did have 1 crash when i was seeing what manjaro was like about 6 years ago 7 years ago

>>102418230
yes, I tend to prefer stuff that works
>>102418231
shitposting and ricing your desktop for 10 hours a day is not a valid benchmark of system stability

i've always known about this but never had the chance to actually try it, it was often faster to just reboot the computer
also, i think DEs often have it disabled by default, you have to enable it beforehand

>>102418265
I happen to use linux for a lot of things. yes I like a nice desktop, but my main reason for using it is to remotely log in to customers servers to do maintenance etc and to implement various programs, also to log into their routers and other peripherals. I also like experimenting with router firmware running in emulators and VM's
how about you, what do you use your computer for? Fap material I expect

>>102418291
To enable sysrq magic keys temporarily:

# echo "1" > /proc/sys/kernel/sysrq

or # sysctl -w kernel.sysrq=1

This enables sysrq magic keys for the current user session. You can disable it again by exchanging 1 with 0 in the above commands. Or go back to the standard value of 176.

To enable these changes at boot time one has to create config file in the sysctl.d directory (e.g. /etc/sysctl.d/90-sysrq.conf) with this line:

kernel.sysrq=1

So setting /proc/sys/kernel/sysrq to 1 enables the sysrq magic keys, setting it to 0 disables it

>>102418298
IDEs, running local servers (for some webshit code I'm unfortunately paid to maintain), android emulator for debugging apps, image editing (manly for editing manga), databases, watching video and listening to music, and fap material

>>102418326
>standard value of 176
Only linux would use "standard" and "176" in the same sentence.
Maybe power of 2 nonsense?
176 =
> 128 * 1
> 64 * 0
> 32 * 1
> 16 * 1
> 8 * 0
> 4 * 0
> 2 * 0
> 1 * 0
So not even a nice symmetric pattern.

File: 2024-09-16T19:47:55,63210(...).png (72 KB, 782x404)

72 KB PNG

>>102418620
Gee, if only there was a manual for that.

>>102418087
SysRq is based. The kernel is so stable you can pretty much always have a safe way to shutdown/reboot.

>>102418864
>The kernel is so stable...
No it's not. I have a gen6 lenovo legion 5 slim with amd cpu and nvidia gpu. I had to disable the integrated amd gpu because it was so unstable it would freeze the whole system twice a day. Magic Sysrq key was not helpful, I had to hold the power button. I don't even know if the problem is now fixed.
I bought this laptop almost a year ago and I'm still not able to control the screen brightness with fn keys.

>>102418864
Reboot Even If System Utterly Broken

It is possible to freeze a machine so hard that Magic SysRq won't work, but that's generally a hardware fault. I did it while overclocking a few times, back when. I read on some sysadmin's blog once that allegedly PS/2 KBs are more reliable for this than USB ones, since PS/2 sends an actual interrupt to the CPU, and doesn't require any of the kernel's complicated USB stack to be answering hails.

>>102418705
in intelligently designed systems, the default is zero, and you only need to set it to override the (sensible) default.