Another systemd annoyance

[Heinz Diehl]

Hi,

tried to safely bring down a crashed Fedora 21 machine today, but M-sysrq
didn't do anything. After bringing the machine up again, the logs showed
that M-sysrq functionality was disabled. After investigating further, it seemed
that only Sysrq-S (emergency save) was actually working. In /etc/sysctl.d/01-sysctl.conf,
"kernel.sysrq=1" was present. It took me nearly 30 min. to find out that
systemd
has it's own sysctl definitions, gladly ignoring/overwriting /etc/sysctl.d. In
/usr/lib/sysctl.d/50-default.conf, "kernel.sysrq=16" was set, which is what
crippled
full sysrq functionality.

In addition, I'm curious what happens when the next systemd update gets pulled in.
Most probably, my manual settings will be overwritten with what systemd thinks
is good for the user..

Another user annoyance

[poma]

On 31.01.2015 12:52, Heinz Diehl wrote:
>  Hi,
>  
>  tried to safely bring down a crashed Fedora 21 machine today, but M-sysrq
>  didn't do anything. After bringing the machine up again, the logs showed
>  that M-sysrq functionality was disabled. After investigating further, it seemed
>  that only Sysrq-S (emergency save) was actually working. In
> /etc/sysctl.d/01-sysctl.conf,
>  "kernel.sysrq=1" was present. It took me nearly 30 min. to find out that
> systemd
>  has it's own sysctl definitions, gladly ignoring/overwriting /etc/sysctl.d. In
>  /usr/lib/sysctl.d/50-default.conf, "kernel.sysrq=16" was set, which is what
> crippled
>  full sysrq functionality.
>  
>  In addition, I'm curious what happens when the next systemd update gets pulled in.
>  Most probably, my manual settings will be overwritten with what systemd thinks
>  is good for the user..
>   
:)

$ grep kernel.sysrq /usr/lib/sysctl.d/*
/usr/lib/sysctl.d/50-default.conf:kernel.sysrq = 16

$ grep kernel.sysrq /etc/sysctl.d/*
/etc/sysctl.d/sysrq.conf:kernel.sysrq = 1

$ sysctl kernel.sysrq
kernel.sysrq = 1

[Tom Horsley]

On Sat, 31 Jan 2015 12:52:10 +0100
Heinz Diehl wrote:

>  In addition, I'm curious what happens when the next systemd
> update gets pulled in.
>  Most probably, my manual settings will be overwritten with what systemd thinks
>  is good for the user.. 
I use a big hammer for this:

yum-plugin-post-transaction-actions is a yum plugin (hopefully
there is a dnf equivalent) that will let you run hooks
after yum runs, so I have a /usr/local/bin/after-yum-hook
script I run every time yum runs to apply any changes
I've made that may have just been overwritten by an
update :-). (Actually, I use a yum plugin I wrote
myself before I found out about the post transaction
plugin above, but the idea is the same).

[Ahmad Samir]

On 31 January 2015 at 14:01, Joonas Sarajärvi <muep(a)iki.fi&gt; wrote:
>  2015-01-31 13:52 GMT+02:00 Heinz Diehl <htd+ml(a)fritha.org&gt;:
> > Hi,
> >
> > tried to safely bring down a crashed Fedora 21 machine today, but M-sysrq
> > didn't do anything. After bringing the machine up again, the logs showed
> > that M-sysrq functionality was disabled. After investigating further, it seemed
> > that only Sysrq-S (emergency save) was actually working. In
> /etc/sysctl.d/01-sysctl.conf,
> > "kernel.sysrq=1" was present. It took me nearly 30 min. to find out that
> systemd
> > has it's own sysctl definitions, gladly ignoring/overwriting /etc/sysctl.d. In
> > /usr/lib/sysctl.d/50-default.conf, "kernel.sysrq=16" was set, which is what
> crippled
> > full sysrq functionality.
> >
> > In addition, I'm curious what happens when the next systemd update gets pulled
> in.
> > Most probably, my manual settings will be overwritten with what systemd thinks
> > is good for the user..
> >
>
>  Processing order of files under /etc/sysctl.d/ seems to be such that
>  files with a high number override files with a low number. If you do
>  not want your changes to be overridden, I think it would be a good
>  idea to pick a high number like 90 instead of 01 for the start if your
>  config file name.
>
>  -Joonas 
Exactly.
$ cat /etc/sysctl.d/99-sysctl.conf
# sysctl settings are defined through files in
# /usr/lib/sysctl.d/, /run/sysctl.d/, and /etc/sysctl.d/.
#
# Vendors settings live in /usr/lib/sysctl.d/.
# To override a whole file, create a new file with the same in
# /etc/sysctl.d/ and put new settings there. To override
# only specific settings, add a file with a lexically later
# name in /etc/sysctl.d/ and put new settings there.
#
# For more information, see sysctl.conf(5) and sysctl.d(5).

I use an /etc/sysctl.d/99-custom-sysctl.conf to override stuff from
/usr/lib/sysctl.d/ .

--
Ahmad Samir

[Joonas Sarajärvi]

2015-01-31 13:52 GMT+02:00 Heinz Diehl <htd+ml(a)fritha.org&gt;:
>  Hi,
>
>  tried to safely bring down a crashed Fedora 21 machine today, but M-sysrq
>  didn't do anything. After bringing the machine up again, the logs showed
>  that M-sysrq functionality was disabled. After investigating further, it seemed
>  that only Sysrq-S (emergency save) was actually working. In
> /etc/sysctl.d/01-sysctl.conf,
>  "kernel.sysrq=1" was present. It took me nearly 30 min. to find out that
> systemd
>  has it's own sysctl definitions, gladly ignoring/overwriting /etc/sysctl.d. In
>  /usr/lib/sysctl.d/50-default.conf, "kernel.sysrq=16" was set, which is what
> crippled
>  full sysrq functionality.
>
>  In addition, I'm curious what happens when the next systemd update gets pulled in.
>  Most probably, my manual settings will be overwritten with what systemd thinks
>  is good for the user..
>  
Processing order of files under /etc/sysctl.d/ seems to be such that
files with a high number override files with a low number. If you do
not want your changes to be overridden, I think it would be a good
idea to pick a high number like 90 instead of 01 for the start if your
config file name.

-Joonas