Bug 1137688

The value is 184 also on my system without changing anything, without using
YaST at all. So the configuration (value=1) does not seem to be permanent.

Copied from /usr/src/linux/Documentation/sysrq.txt (kernel-source)

*  How do I enable the magic SysRq key?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You need to say "yes" to 'Magic SysRq key (CONFIG_MAGIC_SYSRQ)' when
configuring the kernel. When running a kernel with SysRq compiled in,
/proc/sys/kernel/sysrq controls the functions allowed to be invoked via
the SysRq key. The default value in this file is set by the
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE config symbol, which itself defaults
to 1. Here is the list of possible values in /proc/sys/kernel/sysrq:
   0 - disable sysrq completely
   1 - enable all functions of sysrq
  >1 - bitmask of allowed sysrq functions (see below for detailed function
       description):
          2 =   0x2 - enable control of console logging level
          4 =   0x4 - enable control of keyboard (SAK, unraw)
          8 =   0x8 - enable debugging dumps of processes etc.
         16 =  0x10 - enable sync command
         32 =  0x20 - enable remount read-only
         64 =  0x40 - enable signalling of processes (term, kill, oom-kill)
        128 =  0x80 - allow reboot/poweroff
        256 = 0x100 - allow nicing of all RT tasks

You can set the value in the file by the following command:
    echo "number" >/proc/sys/kernel/sysrq

According to code https://github.com/yast/yast-tune/blob/e30ecd09d9d66a9cd01f44c6e2580149707ac87e/src/modules/SystemSettings.rb all should be logged, so, please, attach YaST logs.

https://en.opensuse.org/openSUSE:Report_a_YaST_bug

(BTW, 184 is a valid value)

Hi Lukas, thanks very much for the prompt reply.

(In reply to Lukas Ocilka from comment #3)
> all should be logged, so, please, attach YaST logs.
> https://en.opensuse.org/openSUSE:Report_a_YaST_bug

OK, thanks. I just generated the log output, but I noticed that it contains rather a lot of personal filenames and usernames, and almost all of it is unrelated and very old system messages and RPM transactions. I looked through the ./Yast2/config_diff_* files, but they are also old. There should be a file covering 2019-06-09 and 2019-06-10, which is when I started messing with the SysRq checkbox in YaST. Can you tell me which file(s) you specifically need? Sorry for the hassle.

> (BTW, 184 is a valid value)

Yes, I also discovered that some SysRq functions are enabled with this subset, but it appears to be non-standard. And most importantly the Alt+SysRq+F combination to force an OOM-kill is not enabled with the 184 subset, which is the main reason I need it.

We are interested in one of the /var/log/YaST2/y2log[*] file(s).

I agree that "64 =  0x40 - enable signalling of processes (term, kill, oom-kill)" is probably the reason why people might want to configure it. The implementation is rather old and most probably something has changed meanwhile.

Created attachment 807221 [details]
y2log since I started messing with Yast2 Kernel SysRq checkbox

Ah, thanks, I found it. (attached)

I wonder if this is not a YaST bug, but rather some other sysctl or systemd setting that is changing the /proc/sys/kernel/sysrq value? Because immediately after enabling SysRq in YaST and before a reboot, it does correctly set the value to 1. Only after a reboot does it change to 184.

/usr/lib/sysctl.d/50-default.conf has 'kernel.sysrq = 184' in it.

YaST is probably interacting not perfectly with the system's standard way to
store these settings.

TL;DR: I cannot reproduce it.

What happens is that yast stores the value in /etc/sysctl.conf. That's
(according to the docs) not correct. Instead, /etc/sysctl.d should be used.

BUT: there's a symlink /usr/lib/sysctl.d/99-sysctl.conf linking to
/etc/sysctl.conf so that in the end the config is used anyway.

I tried it and it does work on my system.

Despite this, I've created a card in our Scrum board to have yast using the
modern location.

If it does not work for you, please check the various sysctl.d locations
on your machine (see 'man sysctl.d').

This has been already fixed by the recent changes in this area. See https://github.com/yast/yast-tune/pull/39

(In reply to Ancor Gonzalez Sosa from comment #9)
> This has been already fixed by the recent changes in this area. See
> https://github.com/yast/yast-tune/pull/39

It looks like the code has been fixed, but it hasn't reached Tumbleweed yet? I'm on Tumbleweed 20191128, and with the SysRq function enabled in YaST Kernel Settings, /proc/sys/kernel/sysrq is still set to 184 after reboot.

Could you set the parameter (using the YaST2 system settings again) and tell us the content of `/etc/sysctl.d/30-yast.conf`? It should contain "kernel.sysrq = 1".

If it is still set to 184 after reboot, it might happen that the YaST value is being overridden. Please, check sysctl.d(5) and systctl.conf(5) for more information about which files are read (and in which order).

PS: the 30-yast.conf will be (automatically) moved to 70-yast.conf in the future.

Hi @Imobach, OK, so I used the YaST Kernel Settings to disable and then re-enable the SysRq option, and it does contain:
kernel.sysrq = 1
Let's see what happens after reboot...

(In reply to S. B. from comment #12)
> Hi @Imobach, OK, so I used the YaST Kernel Settings to disable and then
> re-enable the SysRq option, and it does contain:
> kernel.sysrq = 1
> Let's see what happens after reboot...

Unfortunately it is still getting set to 184 on reboot. I only have two files in /etc/sysctl.d 
30-yast.conf
99-sysctl.conf

I tried searching for 184, with no interesting results:
grep -iRl "184" /etc
/etc/alternatives/vim
/etc/alternatives/ImageMagick-7/thresholds.xml
/etc/openldap/schema/dlz.schema
/etc/skel/.config/khotkeysrc
/etc/ssh/moduli
/etc/udev/rules.d/55-libsane.rules
/etc/udev/hwdb.bin
/etc/xdg/colors/Royal.colors
/etc/mime.types
/etc/ImageMagick-7/thresholds.xml
/etc/services
/etc/ImageMagick-7-SUSE/thresholds.xml

Hi S.B.,

Well, you should check the directories that are listed in sysctl.d(5) and systctl.conf(5) man pages. These are /run/sysctl.d, /etc/sysctl.d, /usr/local/lib/sysctl.d, /usr/lib/sysctl.d, /lib/sysctl.d and /etc/sysctl.conf.

For further details, see the "CONFIGURATION DIRECTORIES AND PRECEDENCE" section in the "sysctl.d(5)" man page and the "FILES" section in the "sysctl.conf(5)" man page.

Actually, you could even try to load system settings with "sysctl --system". It should give you a clue about where it is reading the values from.

(In reply to Imobach Gonzalez Sosa from comment #15)
> Actually, you could even try to load system settings with "sysctl --system".
> It should give you a clue about where it is reading the values from.

Ah yes, that helped:

sysctl --system
* Applying /boot/sysctl.conf-5.3.12-1-default ...
kernel.hung_task_timeout_secs = 0
kernel.msgmax = 65536
kernel.msgmnb = 65536
kernel.shmmax = 0xffffffffffffffff
kernel.shmall = 0x0fffffffffffff00
vm.dirty_ratio = 20
* Applying /etc/sysctl.d/30-yast.conf ...
kernel.sysrq = 1
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0
net.ipv4.tcp_syncookies = 1
* Applying /usr/lib/sysctl.d/50-default.conf ...
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.all.promote_secondaries = 1
net.ipv6.conf.default.use_tempaddr = 1
fs.inotify.max_user_watches = 65536
kernel.sysrq = 184
dev.cdrom.autoclose = 0
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
kernel.kptr_restrict = 1
* Applying /usr/lib/sysctl.d/51-network.conf ...
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
* Applying /etc/sysctl.d/99-sysctl.conf ...
vm.swappiness = 1
vm.vfs_cache_pressure = 50
vm.dirty_background_bytes = 16777216
vm.dirty_bytes = 33554432
* Applying /etc/sysctl.conf ...

OK. Now we know why the value is getting overridden. The good news is that we have changed the name of the file and, in the near future, YaST will use 70-yast.conf instead of 30-yast.conf, so it will take precedence over 50-*.conf files[1]. The change is included in yast2 4.2.46 (which is not in tumbleweed yet).

[1] https://github.com/yast/yast-yast2/pull/995