“Cd” em / sys / kernel / debug / tracing causa alteração na permissão

Hoje enfrentei um problema realmente estranho e estou totalmente desamparado.

Alguns dos servidores que eu gerencio são monitorados com o Nagios. Recentemente, vi um probe de uso de disco falhar com este erro:

CRÍTICO DO DISCO - / sys / kernel / debug / tracing não está acessível: permissão negada

Eu queria investigar e minha primeira tentativa foi verificar as permissões deste diretório e compará-las com outro servidor (que está funcionando bem). Aqui estão os comandos que eu executei no servidor de trabalho e você verá que, assim que eu cdentrar no diretório, suas permissões são alteradas:

# Here we've got 555 for /sys/kernel/debug/tracing
root@vps690079:/home/admin# cd /sys/kernel/debug
root@vps690079:/sys/kernel/debug# ll
total 0
drwx------ 30 root root 0 Jul 19 13:13 ./
drwxr-xr-x 13 root root 0 Jul 19 13:13 ../
…
dr-xr-xr-x  3 root root 0 Jul 19 13:13 tracing/
drwxr-xr-x  6 root root 0 Jul 19 13:13 usb/
drwxr-xr-x  2 root root 0 Jul 19 13:13 virtio-ports/
-r--r--r--  1 root root 0 Jul 19 13:13 wakeup_sources
drwxr-xr-x  2 root root 0 Jul 19 13:13 x86/
drwxr-xr-x  2 root root 0 Jul 19 13:13 zswap/

# I cd into the folder, and it (./) becomes 700!!
root@vps690079:/sys/kernel/debug# cd tracing/
root@vps690079:/sys/kernel/debug/tracing# ll
total 0
drwx------  8 root root 0 Jul 19 13:13 ./
drwx------ 30 root root 0 Jul 19 13:13 ../
-r--r--r--  1 root root 0 Jul 19 13:13 available_events
-r--r--r--  1 root root 0 Jul 19 13:13 available_filter_functions
-r--r--r--  1 root root 0 Jul 19 13:13 available_tracers
…

# Next commands are just a dumb test to double-check what I'm seeing
root@vps690079:/sys/kernel/debug/tracing# cd ..
root@vps690079:/sys/kernel/debug# ll
total 0
drwx------ 30 root root 0 Jul 19 13:13 ./
drwxr-xr-x 13 root root 0 Sep 27 10:57 ../
…
drwx------  8 root root 0 Jul 19 13:13 tracing/
drwxr-xr-x  6 root root 0 Jul 19 13:13 usb/
drwxr-xr-x  2 root root 0 Jul 19 13:13 virtio-ports/
-r--r--r--  1 root root 0 Jul 19 13:13 wakeup_sources
drwxr-xr-x  2 root root 0 Jul 19 13:13 x86/
drwxr-xr-x  2 root root 0 Jul 19 13:13 zswap/

Você tem alguma idéia do que poderia causar esse comportamento?
Nota lateral, o uso do chmod para restabelecer as permissões não parece corrigir o probe.

/ sys

/sysé sysfsuma visão totalmente virtual das estruturas do kernel na memória que reflete a configuração atual do kernel e do hardware do sistema e não consome nenhum espaço em disco real. Novos arquivos e diretórios não podem ser gravados nele da maneira normal.

A aplicação do monitoramento do espaço em disco não produz informações úteis e é um desperdício de esforço. Pode ter pontos de montagem para outros sistemas de arquivos virtuais baseados em RAM, incluindo ...

/ sys / kernel / debug

/sys/kernel/debugé o ponto de montagem padrão debugfs, que é um sistema de arquivos virtual opcional para vários recursos de depuração e rastreamento de kernel.

Por se tratar de recursos de depuração, é suposto ser desnecessário para uso em produção (embora você possa optar por usar alguns dos recursos para obter estatísticas aprimoradas do sistema ou similares).

Como o uso dos recursos oferecidos pelo debugfswill na maioria dos casos exige ser de rootqualquer maneira, e seu objetivo principal é ser uma maneira fácil para os desenvolvedores do kernel fornecerem informações de depuração, pode ser um pouco "difícil".

Quando o kernel foi carregado, a rotina de inicialização do subsistema de rastreamento do kernel registrou-se /sys/kernel/debug/tracingcomo um ponto de acesso para depuração, adiando qualquer inicialização adicional até que seja realmente acessada pela primeira vez (minimizando o uso de recursos do subsistema de rastreamento, caso ocorra não é necessário). Quando você cdestava no diretório, essa inicialização adiada foi acionada e o subsistema de rastreamento se preparou para o uso. De fato, o original /sys/kernel/debug/tracingera inicialmente uma miragem sem substância e só se tornou "real" quando (e porque) você o acessou com seu cdcomando.

debugfs não usa nenhum espaço em disco real: todas as informações contidas nele desaparecem quando o kernel é desligado.

/ sys / fs / cgroup

/sys/fs/cgroupé um tmpfssistema de arquivos baseado em RAM do tipo usado para agrupar vários processos em execução em grupos de controle . Ele não usa espaço em disco real. Mas se esse sistema de arquivos estiver quase cheio por algum motivo, pode ser mais sério do que ficar sem espaço em disco: pode significar que

a) você está ficando sem RAM grátis,

b) algum processo de propriedade raiz está gravando lixo /sys/fs/cgroupou

c) algo está causando a criação de um número verdadeiramente absurdo de grupos de controle, possivelmente no estilo de uma "bomba de forquilha" clássica, mas com systemdserviços baseados ou similares.

Bottom line

Um probe de uso de disco deveria ter sido /sysexcluído, porque nada abaixo /sysé armazenado em qualquer disco.

Se você precisar monitorar /sys/fs/cgroup, forneça uma análise dedicada para fornecer alertas mais significativos do que uma análise genérica de espaço em disco.