3 ms·

The times my Linux installs have locked up, those keys never worked.

• malfist 4y ago
  They always worked for me, but it's been a long time since linux has locked up on me.
• pengaru 4y ago
  They may be disabled by distros to enhance security against physical access attacks. It can also be challenging to actually input a magic-sysrq combo on many modern keyboards where sysrq isn't its own key, if it's labeled at all as some Fn-key contortion.
  • nyanpasu64 4y ago
    Personally I value being able to trigger oomkiller early when a process is eating up RAM, and being able to SIGKILL kwin_x11 on Nvidia or whatever other process is wedging Linux shutdown, instead of waiting multiple minutes for systemd to give up waiting and SIGKILL it directly. In terms of physical access attacks, it's just as viable and far more powerful to add a keylogger to my keyboard or Linux distro, or pull and image my hard drive, than to gasp kill processes or sync filesystem data to disk, oh the horror!
    • pengaru 4y ago
      WRT the physical security argument in favor of disabling sysrq, my assumption is it's more aimed towards defeating quick-n-dirty mischief style abuse. Ages ago I worked with a small team of young sysadmins who would often cause trouble for one another abusing things like sysrq, or poorly configured XFree86 instances without DontZap enabled (ctrl-alt-backspace termination, to a shell when startx/xinit is being used). Most of the time nothing malicious was actually done. But when you return to your screen-locked X desktop to find a fullscreen VC with a root shell blinking back at you and an empty history, guess what you'll at least have on the back of your mind for the rest of the workday?
• sebazzz 4y ago
  From what I recall it needs to be enabled (or not be disabled) when the kernel is compiled and in some cases a flag must be put on the kernel command line while booting.