“ 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重新获得权限似乎无法解决此问题。

/ sys

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

对磁盘空间进行监视不会产生有用的信息，而且很浪费精力。它可能在内部具有其他基于RAM的虚拟文件系统的安装点，包括...

/ sys /内核/调试

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

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

由于debugfs在大多数情况下都需要使用所提供的功能root，并且其主要目的是成为内核开发人员提供调试信息的简便方法，因此可能有些“困难”。

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

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

/ sys / fs / cgroup

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

a）您的可用RAM即将用完，

B）一些超级用户拥有的过程被写入到垃圾/sys/fs/cgroup，或

c）某种原因导致创建了非常荒谬的控制组，这很可能是经典的“叉子炸弹”风格，但具有systemd基于服务或类似的功能。

底线

磁盘使用情况调查应/sys排除在外，因为/sys任何磁盘上均未存储任何内容。

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