"CD" in / sys / kernel / debug / tracing bewirkt eine Änderung der Berechtigung

Ich habe heute ein wirklich seltsames Problem und bin völlig hilflos.

Einige der von mir verwalteten Server werden mit Nagios überwacht. Kürzlich habe ich gesehen, dass ein Festplattennutzungs-Test mit diesem Fehler fehlgeschlagen ist:

DISK CRITICAL - / sys / kernel / debug / tracing ist nicht verfügbar: Berechtigung verweigert

Ich wollte nachforschen und mein erster Versuch war, diese Verzeichnisberechtigungen zu überprüfen und diese mit einem anderen Server zu vergleichen (der gut funktioniert). Hier sind die Befehle, die ich auf dem Arbeitsserver ausgeführt habe, und Sie werden sehen, dass cddie Berechtigungen geändert werden , sobald ich in das Verzeichnis gehe :

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

Haben Sie eine Idee, was dieses Verhalten verursachen könnte?
Nebenbei bemerkt, die Verwendung von chmod zum Wiederherstellen von Berechtigungen scheint die Sonde nicht zu reparieren.

/ sys

/sysDies sysfsist eine vollständig virtuelle Ansicht der Kernelstrukturen im Speicher, die die aktuelle Systemkern- und Hardwarekonfiguration widerspiegelt und keinen realen Speicherplatz belegt. Neue Dateien und Verzeichnisse können nicht auf normale Weise darauf geschrieben werden.

Das Anwenden der Speicherplatzüberwachung liefert keine nützlichen Informationen und ist eine Verschwendung von Aufwand. Es kann Mount-Punkte für andere RAM-basierte virtuelle Dateisysteme enthalten, einschließlich ...

/ sys / kernel / debug

/sys/kernel/debugist der Standard-Mount-Punkt für debugfs, ein optionales virtuelles Dateisystem für verschiedene Kernel-Debugging- und Tracing-Funktionen.

Da es sich um das Debuggen von Funktionen handelt, sollte es für die Verwendung in der Produktion nicht erforderlich sein (obwohl Sie möglicherweise einige der Funktionen für erweiterte Systemstatistiken oder ähnliches verwenden möchten).

Da die Verwendung der von debugfswill angebotenen Funktionen in den meisten Fällen rootohnehin erforderlich ist und der Hauptzweck darin besteht, Kernel-Entwicklern eine einfache Möglichkeit zu bieten, Debug-Informationen bereitzustellen, kann dies etwas "rau an den Rändern" sein.

Beim Laden des Kernels wurde die Initialisierungsroutine für das Kernel-Tracing-Subsystem /sys/kernel/debug/tracingals Debugfs-Zugriffspunkt für sich selbst registriert , wodurch jede weitere Initialisierung verschoben wurde, bis zum ersten Mal tatsächlich darauf zugegriffen wurde (Minimierung des Ressourcenverbrauchs des Tracing-Subsystems, falls sich herausstellt, dass dies der Fall ist nicht benötigt). Wenn Sie sich cdin dem Verzeichnis befanden, wurde diese verzögerte Initialisierung ausgelöst und das Ablaufverfolgungssubsystem bereitete sich auf die Verwendung vor. Tatsächlich war das Original /sys/kernel/debug/tracinganfangs ein Trugbild ohne Substanz, und es wurde erst "real", als (und weil) Sie mit Ihrem cdBefehl darauf zugegriffen haben .

debugfs verwendet überhaupt keinen echten Speicherplatz: Alle darin enthaltenen Informationen verschwinden, wenn der Kernel heruntergefahren wird.

/ sys / fs / cgroup

/sys/fs/cgroupist ein tmpfsRAM-basiertes Dateisystem vom Typ, mit dem verschiedene laufende Prozesse in Kontrollgruppen gruppiert werden . Es wird überhaupt kein echter Speicherplatz verwendet. Wenn dieses Dateisystem jedoch aus irgendeinem Grund fast voll ist, ist es möglicherweise schwerwiegender, als nur der Speicherplatz zu knapp zu werden. Dies kann bedeuten

a) Ihnen geht der freie Arbeitsspeicher aus,

b) Ein Root-Prozess schreibt Müll in /sys/fs/cgroupoder

c) Etwas führt dazu, dass eine wirklich absurde Anzahl von Kontrollgruppen gebildet wird, möglicherweise im Stil einer klassischen "Gabelbombe", jedoch mit auf systemdDiensten basierenden Diensten oder ähnlichem.

Endeffekt

Ein Festplattennutzungs-Test sollte /sysausgeschlossen werden, da /sysauf keiner Festplatte etwas unter gespeichert ist.

Wenn Sie überwachen müssen /sys/fs/cgroup, sollten Sie einen dedizierten Test bereitstellen, der aussagekräftigere Warnungen liefert als ein generischer Speicherplatz-Test.