"Cd" in / sys / kernel / debug / tracing causa il cambio di autorizzazione

Ho affrontato un problema davvero strano oggi e sono totalmente impotente al riguardo.

Alcuni dei server che gestisco sono monitorati con Nagios. Recentemente ho visto un probe di utilizzo del disco non riuscito con questo errore:

DISK CRITICAL - / sys / kernel / debug / tracing non è accessibile: autorizzazione negata

Volevo indagare e il mio primo tentativo è stato quello di controllare i permessi di questa directory e confrontarli con un altro server (che sta funzionando bene). Ecco i comandi che ho eseguito sul server funzionante e vedrai che non appena entrerò cdnella directory, le sue autorizzazioni saranno cambiate:

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

Hai idea di cosa potrebbe causare questo comportamento?
Nota a margine, l'uso di chmod per ristabilire le autorizzazioni non sembra correggere il probe.

/ sys

/sys è sysfs , una visione completamente virtuale delle strutture del kernel in memoria che riflette l'attuale kernel di sistema e la configurazione hardware e non consuma spazio su disco reale. Nuovi file e directory non possono essere scritti in modo normale.

Applicare il monitoraggio dello spazio su disco non produce informazioni utili ed è uno sforzo. Potrebbe contenere punti di montaggio per altri filesystem virtuali basati su RAM, incluso ...

/ Sys / kernel / debug

/sys/kernel/debug è il punto di montaggio standard per debugfs , che è un filesystem virtuale opzionale per varie funzionalità di debug e traccia del kernel.

Poiché è per le funzionalità di debug, non dovrebbe essere necessario per l'uso in produzione (anche se potresti scegliere di utilizzare alcune delle funzionalità per statistiche di sistema avanzate o simili).

Dal momento che l'utilizzo delle funzionalità offerte da debugfsWill nella maggior parte dei casi richiede di essereroot comunque, e il suo scopo principale è quello di essere un modo semplice per gli sviluppatori del kernel di fornire informazioni di debug, potrebbe essere un po '"approssimativo".

Quando il kernel è stato caricato, la routine di inizializzazione per il sottosistema di traccia del kernel è stata registrata /sys/kernel/debug/tracingcome un punto di accesso di debug per sé, rinviando ogni ulteriore inizializzazione fino a quando non viene effettivamente acceduta per la prima volta (minimizzando l'utilizzo delle risorse del sottosistema di traccia nel caso in cui risultasse che è non necessario). Quando si cdentrava nella directory, questa inizializzazione posticipata veniva attivata e il sottosistema di tracciamento si preparava per l'uso. In effetti, l'originale /sys/kernel/debug/tracingera inizialmente un miraggio senza sostanza e divenne "reale" solo quando (e perché) vi si accedeva con il vostro cdcomando.

debugfs non utilizza alcuno spazio su disco reale: tutte le informazioni contenute al suo interno svaniranno quando il kernel verrà spento.

/ Sys / fs / cgroup

/sys/fs/cgroupè un tmpfsfilesystem di tipo RAM, utilizzato per raggruppare vari processi in esecuzione in gruppi di controllo . Non utilizza affatto spazio su disco reale. Ma se questo filesystem si sta riempiendo quasi per qualche motivo, potrebbe essere più grave che esaurire lo spazio su disco: potrebbe significare che

a) stai esaurendo la RAM libera,

b) alcuni processi di proprietà di root stanno scrivendo spazzatura in /sys/fs/cgroup, o

c) qualcosa sta causando la creazione di un numero veramente assurdo di gruppi di controllo, possibilmente nello stile di una classica "bomba a forcella" ma con systemdservizi a base o simili.

Linea di fondo

Un probe di utilizzo del disco avrebbe dovuto essere /sysescluso perché nulla di ciò che /sysè archiviato è archiviato su alcun disco.

Se è necessario monitorare /sys/fs/cgroup, è necessario fornire un probe dedicato per esso che fornirà avvisi più significativi di un probe di spazio su disco generico.