[Pkg-systemd-maintainers] Bug#725422: Some more thinking about this bug

[Raphaël HALIMI]

Hi,

I recently experienced a situation when one of my machine (a Sid 
desktop) froze and I tried to use the magic SysRq keys, to no avail. 
After 40 minutes or so I decided to do a hardware reboot and tried to 
find why the magic keys didn't worked. That's when I found this new 
default behavior introduced by systemd.

At first I tried to override this default by writing an adequate file in 
/etc/sysctl.d but, since I named it 10-sysrq.conf, I was very surprised 
to see that restarting procps' init script didn't set the value 
according to my file. After carefully checking /etc/sysctl.conf and all 
files in /etc/sysctl.d, I didn't find anything that would explain why my 
configuration file didn't work.

Then I looked for reports in Debian BTS about SysRq and found this bug, 
and finally I understood why my configuration file didn't work as 
intended. After renaming it to 99-sysrq.conf, it worked.

To be honest, I didn't even know about the existence of 
/usr/lib/sysctl.d. I admit it is mentioned in the manpage, but according 
to a quick search with apt-file, it's only used by systemd so far.

Even if the new kernel.sysrq default value is considered to be a good 
default (to which I don't agree, see below), I think that the file 
/usr/lib/sysctl.d/50-default.conf which sets this value should at least 
be moved to /etc/sysctl.d, which is the "natural" place a Debian 
sysadmin would look first for sysctl settings.

Furthermore, I'm no systemd expert (yet... :)) but as far as I know, 
it's intended to replace SysV, and take charge of the boot process 
(amongst other things); since /usr isn't guaranteed to be available at 
boot-time, I think it's another reason to move the 50-default.conf file 
to /etc/sysctl.d (besides, the procps init script only requires 
$local_fs, which may exclude /usr, so, in the - admittedly rare - case 
of a /usr partition located on a remote fs, the current location of this 
file would prevent it from being read and thus applied when the procps 
init script is executed).

To conclude, I'd like to give my opinion about the setting itself.

The very first question asked to the original reporter was :

"You failed to justify why kernel.sysrq = 16 is a bad default.
Can you elaborate?"

That's only my opinion, but personally, I think that any experienced 
Linux sysadmin (Debian or otherwise)  expects most (if not all) magic 
SysRq keys to be available out-of-the-box, without any further 
configuration. I use Debian since Slink and the SysRq keys got me out of 
quite a bunch of sticky situations, either at home or at work. The 
problem I recently experienced was with a personal Sid desktop that I 
didn't mind to hard reset, but if I encountered the same kind of 
situation at work with an important server, I think that being unable to 
use the SysRq keys and discovering this new default setting afterwards 
would have made me... very upset, to say the least. Not only do I 
totally agree with the original poster about the fact that it's not 
systemd's job to define a new default value for this setting, but I also 
think that this value of 16 (sync only) is far too restrictive, compared 
to the one compiled in the kernels currently shipped by Debian (0x01b6, 
or 438, which means all but signals and dump) which is fine; not to 
mention that two different "defaults" can be confusing even for an 
experienced sysadmin. If nothing is done to change this "second" default 
value introduced by systemd, I expect a lot more users to complain about 
it once Jessie becomes the new stable release and they find out that 
only one SysRq key is now available on their new systemd-enabled Debian 
systems.

Thanks for reading, and I really hope someone will do something about 
this, be it matching kernel's current default setting, or moving the 
responsible file to a more common place (personally I'd prefer the 
former solution but I understand that the choice is not mine to make).

Hope it helps.

-- 
Raphaël HALIMI