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 cd
entrar 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.
fonte
ll
os comandos que eles representam.Respostas:
/ sys
/sys
ésysfs
uma 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ãodebugfs
, 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
debugfs
will na maioria dos casos exige ser deroot
qualquer 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/tracing
como 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êcd
estava 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/tracing
era inicialmente uma miragem sem substância e só se tornou "real" quando (e porque) você o acessou com seucd
comando.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
é umtmpfs
sistema 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 quea) você está ficando sem RAM grátis,
b) algum processo de propriedade raiz está gravando lixo
/sys/fs/cgroup
ouc) 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
systemd
serviços baseados ou similares.Bottom line
Um probe de uso de disco deveria ter sido
/sys
excluí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.fonte
/sys
do meu alcance de monitoramento./proc
e provavelmente/dev
(porque mesmo que não seja 100% suportado por RAM, por um lado, ele contém vários arquivos e diretórios que são "estranhos" de várias maneiras e, por outro, se você realmente consuma uma tonelada de espaço em disco/dev
, sua configuração está horrivelmente quebrada e você deve acender toda a bagunça)./sys
issysfs
, um sistema de arquivos virtual inteiramente baseado em RAM" - tenho certeza de que o conteúdosysfs
é 100% sintetizado a partir de estruturas de dados no kernel e não mora na RAM em algum lugar. De fato, eu argumentaria que "o sistema de arquivos virtual baseado em RAM" é um oxímoro: ou é baseado em RAM, ou seja, possui um armazenamento de backup (mesmo que seja um armazenamento de backup muito não tradicional para um sistema de arquivos), então é não é virtual ou é virtual, não há armazenamento de suporte.sysfs
é um disco RAM . Onde morariam as estruturas de dados no kernel, se não na RAM, afinal? Concordo que a palavra "virtual" é problemática aqui, pois você deve estar ciente de que, além de todos os drivers do sistema de arquivos no kernel Linux, está a camada VFS (Virtual File System), que usa "virtual" em outro sentido, como uma abstração uniforme para todos os sistemas de arquivos possíveis. Mas é difícil descrever de forma concisa comoproc
esysfs
são diferentes dos sistemas de arquivos reais, pois essas eram apenas informações básicas para destacar o ponto principal.