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

10

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.

zessx
fuente
1
Cuando proporcione muestras de entrada de terminal, considere reemplazar los alias no estándar, como lllos comandos que representan.
Roman Odaisky
2
@RomanOdaisky Es un alias predeterminado en Ubuntu, podría no haber sabido que no era predeterminado
GammaGames
Además de lo que dijo @tecloM, esto parece un error del kernel para su versión del kernel. El 4.19.0-4 el comportamiento es normal.
V13

Respuestas:

20

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

telcoM
fuente
1
¡Gracias por esta respuesta con todos los detalles que necesitaba! Lo excluiré /sysde mi rango de monitoreo.
zessx
1
@zessx: también excluir /procy probablemente /dev(porque incluso si no es 100% respaldado por RAM, por un lado contiene una cantidad de archivos y directorios que son "raros" de varias maneras, y por otro, si realmente consume una tonelada de espacio en el disco /dev, su configuración está horriblemente rota y debe encender todo el desastre).
Kevin
" /syses sysfsun sistema de archivos virtual completamente basado en RAM" - Estoy bastante seguro de que el contenido sysfsestá 100% sintetizado a partir de estructuras de datos en el núcleo y no vive en la RAM en algún lugar. De hecho, yo diría que el "sistema de archivos virtual basado en RAM" es un oxímoron: o está basado en RAM, es decir, tiene un almacén de respaldo (incluso si es un almacén de respaldo muy no tradicional para un sistema de archivos), entonces es no es virtual, o es virtual, entonces no tiene una tienda de respaldo.
Jörg W Mittag el
1
@ JörgWMittag Tenga en cuenta que con mucho cuidado evité decir que sysfses un disco RAM . ¿Dónde vivirían las estructuras de datos en el núcleo, si no en RAM, de todos modos? Estoy de acuerdo en que la palabra "virtual" es problemática aquí, ya que puede ser consciente de que, además de todos los controladores del sistema de archivos en el kernel de Linux, se encuentra la capa VFS (Virtual File System), que usa "virtual" en otro sentido, ya que Una abstracción uniforme para todos los sistemas de archivos posibles. Pero es difícil describir de forma concisa cómo procy sysfsson diferentes de los sistemas de archivos reales, ya que esto era solo información de fondo para hacer que el punto principal se mantuviera.
telcoM
1
@grawity modifiqué un poco la redacción, ¿sería mejor ahora?
telcoM