"Cd" en / sys / kernel / debug / tracing provoca un cambio de permiso

Hoy me he enfrentado a un problema realmente extraño y estoy totalmente indefenso al respecto.

Algunos de los servidores que administro son monitoreados con Nagios. Recientemente vi que una sonda de uso de disco fallaba con este error:

DISCO CRÍTICO - / sys / kernel / debug / tracing no es accesible: Permiso denegado

Quería investigar y mi primer intento fue verificar los permisos de este directorio y compararlos con otro servidor (que funciona bien). Estos son los comandos que ejecuté en el servidor de trabajo y verá que tan pronto como ingrese cdal directorio, sus permisos cambian:

# 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/

¿Tienes alguna idea de qué podría causar este comportamiento?
Nota al margen, el uso de chmod para restablecer los permisos no parece arreglar la sonda.

/ sys

/syses decir sysfs, una vista completamente virtual de las estructuras del kernel en la memoria que refleja el kernel del sistema actual y la configuración del hardware, y no consume espacio en disco real. No se pueden escribir nuevos archivos y directorios de la manera normal.

La aplicación de monitoreo de espacio en disco no produce información útil y es una pérdida de esfuerzo. Puede tener puntos de montaje para otros sistemas de archivos virtuales basados ​​en RAM en el interior, incluidos ...

/ sys / kernel / debug

/sys/kernel/debuges el punto de montaje estándar para debugfs, que es un sistema de archivos virtual opcional para varias funciones de depuración y rastreo del kernel.

Debido a que es para depurar características, se supone que es innecesario para uso de producción (aunque puede optar por usar algunas de las características para mejorar las estadísticas del sistema o similares).

Dado que el uso de las características ofrecidas por debugfswill en la mayoría de los casos requiere ser de roottodos modos, y su propósito principal es ser una forma fácil para que los desarrolladores de kernel proporcionen información de depuración, puede ser un poco "tosco".

Cuando se cargó el kernel, la rutina de inicialización del subsistema de rastreo del kernel se registró /sys/kernel/debug/tracingcomo un punto de acceso de debugfs por sí mismo, aplazando cualquier inicialización adicional hasta que realmente se acceda por primera vez (minimizando el uso de recursos del subsistema de rastreo en caso de que resulte que es innecesario). Cuando cdingresó al directorio, se activó esta inicialización diferida y el subsistema de rastreo se preparó para su uso. En efecto, el original /sys/kernel/debug/tracingera inicialmente un espejismo sin sustancia, y solo se volvió "real" cuando (y porque) accedió a él con su cdcomando.

debugfs no utiliza ningún espacio de disco real: toda la información contenida en él desaparecerá cuando se cierre el núcleo.

/ sys / fs / cgroup

/sys/fs/cgroupes un tmpfssistema de archivos basado en RAM de tipo, utilizado para agrupar varios procesos en ejecución en grupos de control . No utiliza espacio en disco real en absoluto. Pero si este sistema de archivos se está llenando casi por alguna razón, podría ser más grave que quedarse sin espacio en disco: podría significar que

a) te estás quedando sin RAM libre,

b) algún proceso propiedad de la raíz está escribiendo basura en /sys/fs/cgroup, o

c) algo está causando la creación de un número realmente absurdo de grupos de control, posiblemente al estilo de una "bomba de horquilla" clásica pero con systemdservicios basados ​​o similares.

Línea de fondo

Una sonda de uso de disco debería haberse /sysexcluido porque nada debajo /sysse almacena en ningún disco.

Si necesita monitorear /sys/fs/cgroup, debe proporcionarle una sonda dedicada que brinde alertas más significativas que una sonda genérica de espacio en disco.