Сегодня я столкнулся с действительно странной проблемой, и я совершенно беспомощен в этом.

Некоторые из серверов, которыми я управляю, отслеживаются с помощью Nagios. Недавно я увидел, что проверка использования диска не работает с этой ошибкой:

КРИТИЧЕСКИЙ ДИСК — /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 для повторной установки разрешений, похоже, не устраняет проблему.

10
Gilles 'SO- stop being evil' 27 Сен 2019 в 16:21
2
Предоставляя образцы ввода терминала, рассмотрите возможность замены нестандартных псевдонимов, таких как ll, на команды, которые они обозначают.
 – 
Roman Odaisky
27 Сен 2019 в 21:26
3
Это псевдоним по умолчанию в Ubuntu, возможно, он не знал, что это не по умолчанию
 – 
GammaGames
28 Сен 2019 в 01:20
Помимо того, что сказал @tecloM, это похоже на ошибку ядра для вашей версии ядра. На 4.19.0-4 поведение нормальное.
 – 
V13
29 Сен 2019 в 01:52

1 ответ

Лучший ответ

/sys

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

Применение к нему мониторинга дискового пространства не дает полезной информации и является пустой тратой усилий. Он может иметь точки монтирования для других виртуальных файловых систем на основе ОЗУ внутри, включая...

/sys/ядро/отладка

/sys/kernel/debug — это стандартная точка монтирования для debugfs, которая является дополнительной виртуальной файловой системой для различных функций отладки и трассировки ядра.

Поскольку он предназначен для функций отладки, предполагается, что он не нужен для производственного использования (хотя вы можете использовать некоторые функции для расширенной системной статистики или чего-то подобного).

Поскольку использование функций, предлагаемых debugfs, в любом случае в большинстве случаев потребует быть root, а его основная цель - предоставить разработчикам ядра простой способ предоставления отладочной информации, это может быть немного "грубым". края".

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

debugfs вообще не использует реальное дисковое пространство: вся информация, содержащаяся в нем, исчезнет при завершении работы ядра.

/sys/fs/cgroup

/sys/fs/cgroup — это файловая система типа tmpfs на основе оперативной памяти, используемая для группировки различных запущенных процессов в группы управления. Он вообще не использует реальное дисковое пространство. Но если эта файловая система по какой-то причине почти заполнена, это может быть более серьезно, чем просто нехватка места на диске: это может означать, что

А) у вас заканчивается свободная оперативная память,

Б) какой-то процесс, принадлежащий root, записывает мусор в /sys/fs/cgroup, или

C) что-то вызывает создание поистине абсурдного количества контрольных групп, возможно, в стиле классической «форк-бомбы», но с сервисами на основе systemd или подобными.

Нижняя линия

Проверка использования диска должна быть /sys исключена, потому что ничего меньше /sys не хранится ни на одном диске.

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

20
telcoM 28 Сен 2019 в 21:29
1
Спасибо за этот ответ с такими подробностями, как мне нужно! Я исключим /sys из своего диапазона мониторинга.
 – 
zessx
27 Сен 2019 в 15:21
1
@zessx: Также исключите /proc и, вероятно, /dev (потому что, даже если он не на 100% поддерживается оперативной памятью, с одной стороны, он содержит ряд файлов и каталогов, которые «странны» в различных способами, а с другой, если вы на самом деле потребляете тонну дискового пространства в /dev, ваша установка ужасно сломана, и вы должны поджечь весь этот бардак).
 – 
Kevin
28 Сен 2019 в 05:23
«/sys — это sysfs, виртуальная файловая система, полностью основанная на оперативной памяти» — я почти уверен, что содержимое sysfs на 100% синтезировано из структур данных в ядре и делает не жить где-то в оперативной памяти. На самом деле, я бы сказал, что «виртуальная файловая система на основе ОЗУ» — это оксюморон: либо она основана на ОЗУ, т. е. имеет резервное хранилище (даже если это очень нетрадиционное резервное хранилище для файловой системы), не виртуальный, или он виртуальный, то у него нет резервного хранилища.
 – 
Jörg W Mittag
28 Сен 2019 в 14:27
1
Обратите внимание, что я очень тщательно избегал говорить, что sysfs — это RAMdisk. Где будут жить структуры данных в ядре, если не в оперативной памяти? Я согласен, что слово «виртуальный» здесь проблематично, поскольку вы, возможно, знаете, что поверх всех драйверов файловой системы в ядре Linux находится слой VFS (Virtual File System), который использует «виртуальный " в еще одном смысле, как единую абстракцию для всех возможных файловых систем. Но трудно сжато описать, чем proc и sysfs отличаются от реальных файловых систем, так как это была просто справочная информация, чтобы зафиксировать основную мысль.
 – 
telcoM
28 Сен 2019 в 15:13
1
Я немного подправил формулировку, теперь будет лучше?
 – 
telcoM
28 Сен 2019 в 21:33