same as https://bugs.mageia.org/show_bug.cgi?id=6842 ?

Not really.  In that bug, the OP was complaining that when you terminate the DM with SysRq-E/I, it restarts.  The problem here is that the magic keys don't work at all, and you get (in tty mode) a messages saying that the particular magic key is disabled.

Not sure why this happened but I blame me with the new systemd! :)


Likely a sysctl thing as Frank says.

$ rpm -ql systemd | grep sysctl
/usr/lib/sysctl.d
/usr/lib/sysctl.d/50-default.conf
/usr/lib/systemd/systemd-sysctl
/usr/share/man/man5/sysctl.d.5.xz
/usr/share/man/man8/systemd-sysctl.8.xz
/usr/share/man/man8/systemd-sysctl.service.8.xz

So the likely candidate is /usr/lib/sysctl.d/50-default.conf and looking closer I see:

# System Request functionality of the kernel (SYNC)
kernel.sysrq = 16


Not quite sure why that is disabled by default (likely as a sane package default - e.g. for public terminals etc) that we should consider and decide if we want to keep or whether a more lax default is better for us. I don't really care what the default is, but would rather not change systemd package itself and instead install a /usr/lib/sysctl.d/51-mageia.conf in some other package if we want to over ride things or teach msec to write a /etc/sysctl.d/99-mageia-msec.conf or similar if it wants to override things based on security level.

OK, so the defaults were added here:

commit 0f59fe5171b5564fc6fb58f3281fbc259c45f7d0
Author: Kay Sievers <kay@vrfy.org>
Date:   Fri Mar 15 19:30:53 2013 +0100

    sysctl: default - add safe sysrq options



Thinking about it some more, I'd be pretty raging if some ne'er do well in my university computer lab or internet cafe was able to go to my locked terminal and use these keys to kill my session!

Probably a good idea for us to keep this default but teach msec to override if it needed.

(In reply to Colin Guthrie from comment #4)
> Thinking about it some more, I'd be pretty raging if some ne'er do well in
> my university computer lab or internet cafe was able to go to my locked
> terminal and use these keys to kill my session!

Good point, but that's probably an outlier case for most MGA usage.

> 
> Probably a good idea for us to keep this default but teach msec to override
> if it needed.

Do you mean default for systemd or default for msec ?  However we do it, I'd vote to leave the operational default as sysrq=1 and let those who have special circumstances use msec to control it.

Also, see bug#9454 .  If the msec toggle gets added, that one can be marked FIXED.

(In reply to Frank Griffin from comment #5)
> (In reply to Colin Guthrie from comment #4)
> > Probably a good idea for us to keep this default but teach msec to override
> > if it needed.
> 
> Do you mean default for systemd or default for msec? 

I meant the default in the systemd package (I'd rather not have to carry a patch to change). Whether it's the default for a new install I don't really care too much. I would suggest that under standard security mode it would be 1, but under paranoid or whatever it's called, it should be 16, but I'm not super fussed.

That makes sense.  In "secure", msec is already turning it off, I think by setting it to 0 because when I tried it, I just got no response as opposed to the message saying that this particular key is disabled.  The point of bug#9454 was that there's no way to set it in the msec GUI.

*** Bug 11691 has been marked as a duplicate of this bug. ***

CC: (none) => alfaflo

I've just upgraded to Mga 4 (RC) and been bitten badly by this. In the emergency case when one's machine has become unresponsive, it's really really unhelpful to discover at that point that the option-of-last-resort for a clean shutdown has been disabled. Please can I ask you to put this back to fully-enabled by default.

(at least, please mention it in the release notes, and the instructions on how to put it back).

CC: (none) => mageia

The underlying problem here is that shutdown under systemd (at least on my systems) locks up, and the alt-SYSRQ keys are the only way to reboot.

alt-SYSRQ-E gets a response from journald, but nothing else.

alt-SYSRQ-I breaks the logjam and allows shutdown to proceed normally.

Without the SYSRQ keys, there's going to be a mess.

Yes... I'm getting a lot of use out of Sysrq at the moment (graphics-card related). Anyway, for those looking here for a workaround, here it is:


Create a file:      /etc/sysctl.d/60-fix-sysrq.conf 
with the following contents:

---- begin ---
#Fix SysRQ to be properly enabled. 
kernel.sysrq = 1
---- end   ---


(Aside, a safe test for whether it works or not is to use the R and S options. In the case where this bug applies, only "S" works, and "R" will throw an error about it being disabled, whereas when sysrq is functional, both R and S keys do what they should. Neither R nor S will do anything nasty to a running system.)

Valid pre-4final kde livedvd 32

I'll set release blocker as live isos are affected
(currently preventing recovery from a hang on reboot)

Priority: Normal => release_blocker
Blocks: (none) => 11704

OK, bowing to pressure, I've modified systemd to drop a file in /etc/sysctl.d/51-alt-sysrq.conf with this applied.

I think it's really up to e.g. msec to manage this for us so I'd really appreciate it if someone would patch it up to write this file (or remove it completely) based on the security level.

But for now all users get it (so same as before) and can safely rm the file if they want it more secure (it won't come back).

This only applies to new installations and upgrades from mga3, so cauldron updates wont get it.

And systemd is now pushed.

Status: NEW => RESOLVED
Resolution: (none) => FIXED