☰

“cd”进入 /sys/kernel/debug/tracing 会导致权限更改

tag-icon • tag-icon linux permissions cd-command sysfs
“cd”进入 /sys/kernel/debug/tracing 会导致权限更改

我今天遇到了一个非常奇怪的问题，对此我完全无能为力。

我管理的一些服务器是使用 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 重新建立权限似乎并不能修复探测器。

答案1

/系统

/sys是sysfs内存中内核结构的完全虚拟视图，反映当前系统内核和硬件配置，并且不消耗任何实际磁盘空间。新文件和目录无法以正常方式写入其中。

对它应用磁盘空间监控不会产生有用的信息，而且是浪费精力。它内部可能有其他基于 RAM 的虚拟文件系统的挂载点，包括...

/系统/内核/调试

/sys/kernel/debug是 的标准安装点debugfs，它是用于各种内核调试和跟踪功能的可选虚拟文件系统。

因为它用于调试功能，所以对于生产用途来说应该是不必要的（尽管您可能选择使用某些功能来增强系统统计信息或类似功能）。

由于在大多数情况下使用 will 提供的功能无论如何都debugfs需要root，并且其主要目的是为内核开发人员提供调试信息的简单方法，因此它可能有点“粗糙”。

加载内核时，内核跟踪子系统的初始化例程将注册/sys/kernel/debug/tracing为自身的 debugfs 访问点，推迟任何进一步的初始化，直到第一次实际访问它（最大限度地减少跟踪子系统的资源使用，以防万一它是不需要）。当您cd进入目录时，会触发此延迟初始化，并且跟踪子系统已做好使用准备。实际上，原始版本/sys/kernel/debug/tracing最初是一个没有实质内容的海市蜃楼，只有当（并且因为）您通过命令访问它时它才变得“真实” cd。

debugfs根本不使用任何实际的磁盘空间：当内核关闭时，其中包含的所有信息都将消失。

/sys/fs/cgroup

/sys/fs/cgroup是一种tmpfs基于 RAM 的文件系统，用于将各种正在运行的进程分组为对照组。它根本不使用实际磁盘空间。但是如果这个文件系统由于某种原因几乎满了，它可能是更认真不仅仅是磁盘空间不足：这可能意味着

a) 您的可用 RAM 即将耗尽，

b) 某些 root 拥有的进程正在向 写入垃圾/sys/fs/cgroup，或者

c) 某些因素导致创建数量确实荒谬的控制组，可能采用经典的“叉子炸弹”风格，但具有systemd基于 的服务或类似服务。

底线

磁盘使用情况探测应该已/sys排除因为/sys任何磁盘上都不会存储任何内容。

如果您需要监视/sys/fs/cgroup，则应为其提供专用探测器，该探测器将提供比通用磁盘空间探测器更有意义的警报。

相关内容