"cd" 进入 /sys/kernel/debug/tracing 导致权限更改

Question

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

我管理的一些服务器由 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 重新建立权限似乎并不能解决问题。

Answer 1

/系统

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

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

/系统/内核/调试

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

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

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

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

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

/sys/fs/cgroup

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

a) 你的可用内存用完了，

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

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

底线

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

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