Durante a solução de problemas de um servidor Oracle Linux 6.3 (derivado RHEL), tentei usar alguns dos comandos da chave Magic SysRq pela primeira vez. Não tive essa sorte, então tive que reiniciar duro. Quando ele voltou, verifiquei se o SysRq estava ativado ...
> sysctl kernel.sysrq
kernel.sysrq = 0
Mas em nossos sistemas Oracle Linux 7.2 (RHEL Derivative) ...
> sysctl kernel.sysrq
kernel.sysrq = 16
Olhando para a Documentação do Kernel para o 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
De acordo com o QA do Fedora para o Sysrq :
Stock Fedora and RHEL kernels do have this functionality enabled at compile-time, but the distributions disable it at boot time, by default, using sysctl.conf.
Ativar essa funcionalidade por padrão em todos os nossos sistemas parece ser uma boa ideia. Na chance de um sistema travar, você pode desligá-lo pelo menos sem graciosidade.
Minhas perguntas ...
kernel.sysrq a 1 em todos os nossos sistemas? Você pode não querer que alguém aleatório caminhe até o teclado e reinicie a máquina, ou pior, comece a imprimir registros, syslog ou todas as tarefas no console, tudo sem fazer login. É um potencial questão de segurança.
Eu o habilito seletivamente, por exemplo, em hardware em nosso datacenter conectado a um concentrador de console serial. Eu desabilitá-lo em nossas estações de trabalho do usuário final.