"Cd" в / sys / kernel / debug / tracing викликає зміну дозволу

Сьогодні я зіткнувся з дійсно дивним питанням і абсолютно безпорадний з цього приводу.

Деякі сервери, якими я керую, відслідковуються за допомогою Nagios. Нещодавно я побачив, що датчик використання диска не працює з цією помилкою:

DISK CRITICAL - / sys / kernel / debug / tracing недоступний: У дозволі відмовлено

Я хотів дослідити, і моя перша спроба була перевірити дозволи цього каталогу та порівняти їх з іншим сервером (який працює добре). Ось команди, які я запустив на робочому сервері, і ви побачите, що як тільки я cdпотрапляю в каталог, його дозволи змінюються:

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

Чи розумієте ви, що може спричинити таку поведінку?
Бічна примітка, використовуючи chmod для повторного встановлення дозволів, схоже, не виправляє зонд.

/ сис

/sysце sysfsцілком віртуальний погляд на структури ядра в пам'яті, який відображає поточну конфігурацію ядра системи та обладнання, і не займає реального дискового простору. Нові файли та каталоги не можуть бути записані до нього у звичайний спосіб.

Застосування моніторингу дискового простору до нього не дає корисної інформації і є марною витратою зусиль. Він може мати точки кріплення для інших віртуальних файлових систем на базі ОЗУ, включаючи ...

/ sys / ядро ​​/ налагодження

/sys/kernel/debugє стандартною точкою монтажу для debugfs, яка є необов'язковою віртуальною файловою системою для різних функцій налагодження та відстеження ядра.

Оскільки це для функцій налагодження, воно повинно бути непотрібним для використання у виробництві (хоча ви можете вибрати деякі функції для покращеної системної статистики чи подібних).

Оскільки використання функцій, пропонованих debugfsв більшості випадків, вимагає rootбудь-якого використання, а його основна мета - це простий спосіб для розробників ядра надавати інформацію про налагодження, це може бути трохи «нерівним по краях».

Коли ядро ​​було завантажено, процедура ініціалізації для підсистеми відстеження ядра, зареєстрованої /sys/kernel/debug/tracingяк точка доступу для налагодження, відкладає будь-яку подальшу ініціалізацію, поки вона фактично не отримає доступ до неї (мінімізуючи використання ресурсів підсистеми відстеження, якщо виявиться, що це не потрібно). Коли ви cdвходили в каталог, ця відкладена ініціалізація була запущена, і підсистема відстеження готувалася до використання. Фактично, оригінал /sys/kernel/debug/tracingбув спочатку міражем без речовини, і він став "справжнім" лише тоді, коли (і тому, що) ви отримали доступ до нього за допомогою своєї cdкоманди.

debugfs взагалі не використовує реального дискового простору: вся інформація, що міститься в ньому, зникне при закритті ядра.

/ sys / fs / cgroup

/sys/fs/cgroupє tmpfsтиповою файловою системою на основі ОЗУ, яка використовується для групування різних запущених процесів у контрольні групи . Він взагалі не використовує реальний дисковий простір. Але якщо ця файлова система з якихось причин стає майже повною, це може бути серйозніше, ніж просто не вистачає місця на диску: це може означати, що

а) у вас не вистачає безкоштовної оперативної пам’яті,

b) якийсь процес, що належить корінь, - це написання сміття /sys/fs/cgroup, або

в) щось спричиняє створення справді абсурдної кількості контрольних груп, можливо, у стилі класичної «вилкової бомби», але з systemdпослугами на базі або подібними.

Нижня лінія

Зонд використання диска повинен був /sysвиключити, оскільки нічого /sysне зберігається на жодному диску.

Якщо вам потрібно провести моніторинг /sys/fs/cgroup, вам слід надати спеціальний зонд для нього, який подаватиме більш значущі сповіщення, ніж загальний зонд на дисковому просторі.