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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
