„Cd” do / sys / kernel / debug / tracing powoduje zmianę uprawnień

Dzisiaj spotkałem się z naprawdę dziwnym problemem i jestem całkowicie bezradny.

Niektóre serwery, którymi zarządzam, są monitorowane za pomocą Nagios. Ostatnio widziałem, że sonda użytkowania dysku nie działa z tym błędem:

DISK CRITICAL - / sys / kernel / debug / tracing nie jest dostępny: Odmowa dostępu

Chciałem to zbadać, a moją pierwszą próbą było sprawdzenie uprawnień do tego katalogu i porównanie ich z innym serwerem (który działa dobrze). Oto polecenia, które uruchomiłem na działającym serwerze, a zobaczysz, że jak tylko przejdę cddo katalogu, jego uprawnienia zostaną zmienione:

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

Czy masz pojęcie, co może być przyczyną takiego zachowania?
Na marginesie: wydaje się, że użycie chmod do przywrócenia uprawnień nie naprawia sondy.

/ sys

/systo sysfscałkowicie wirtualny widok struktur jądra w pamięci, który odzwierciedla bieżącą konfigurację jądra systemu i sprzętu i nie zajmuje rzeczywistego miejsca na dysku. Nowe pliki i katalogi nie mogą być zapisywane w zwykły sposób.

Zastosowanie monitorowania miejsca na dysku nie generuje użytecznych informacji i jest marnowaniem wysiłku. Może zawierać punkty montowania innych wirtualnych systemów plików opartych na pamięci RAM, w tym ...

/ sys / kernel / debug

/sys/kernel/debugjest standardowym punktem montowania dla debugfs, który jest opcjonalnym wirtualnym systemem plików dla różnych funkcji debugowania i śledzenia jądra.

Ponieważ służy do debugowania funkcji, powinien być niepotrzebny do użytku produkcyjnego (chociaż możesz zdecydować się na użycie niektórych funkcji do ulepszonych statystyk systemu lub podobnych).

Ponieważ korzystanie z funkcji oferowanych przez debugfswill w większości przypadków wymaga i roottak bycia , a jego głównym celem jest łatwy sposób dla deweloperów jądra w celu dostarczenia informacji debugowania, może to być nieco „szorstkie wokół krawędzi”.

Kiedy jądro zostało załadowane, procedura inicjalizacji podsystemu śledzenia jądra zarejestrowana /sys/kernel/debug/tracingdla siebie jako punkt dostępu do debugowania, odkłada wszelką dalszą inicjalizację, dopóki nie zostanie faktycznie uzyskana po raz pierwszy (minimalizując zużycie zasobów przez podsystem śledzenia, na wypadek gdyby okazało się, że jest to nie są potrzebne). Gdy cdprzejdziesz do katalogu, ta odroczona inicjalizacja została uruchomiona, a podsystem śledzenia przygotował się do użycia. W efekcie oryginał /sys/kernel/debug/tracingbył początkowo mirażem bez substancji i stał się „prawdziwy” tylko wtedy, gdy (i ponieważ) uzyskałeś do niego dostęp za pomocą swojego cdpolecenia.

debugfs w ogóle nie wykorzystuje rzeczywistego miejsca na dysku: wszystkie zawarte w nim informacje znikną po zamknięciu jądra.

/ sys / fs / cgroup

/sys/fs/cgroupto tmpfsoparty na pamięci RAM system plików, służący do grupowania różnych działających procesów w grupy kontrolne . W ogóle nie wykorzystuje rzeczywistego miejsca na dysku. Ale jeśli ten system plików z jakiegoś powodu jest prawie pełny, może to być poważniejsze niż po prostu brak miejsca na dysku: może to oznaczać, że

a) kończy Ci się wolna pamięć RAM,

b) jakiś proces rootowania zapisuje śmieci do /sys/fs/cgroup, lub

c) coś powoduje, że powstaje naprawdę absurdalna liczba grup kontrolnych, być może w stylu klasycznej „bomby widelcowej”, ale z systemdusługami na bazie lub podobnymi.

Dolna linia

Sonda użytkowania dysku powinna była zostać /syswykluczona, ponieważ nic poniżej nie /sysjest przechowywane na żadnym dysku.

Jeśli potrzebujesz monitorować /sys/fs/cgroup, powinieneś dostarczyć dedykowaną sondę, która dostarczy bardziej znaczących alertów niż ogólna sonda miejsca na dysku.