“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，對記憶體中核心結構的完全虛擬視圖，它反映了目前系統核心和硬體配置，並且不消耗任何實際磁碟空間。不能以正常方式將新文件和目錄寫入其中。對其應用磁碟空間監控不會產生有用的資訊，而且是浪費精力。它內部可能有其他基於 RAM 的虛擬文件系統的掛載點，包括…
/sys/核心/調試
/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) 您的可用 RAM 快用完了，
b) 某個根擁有的程序正在向 寫入垃圾
/sys/fs/cgroup，或c) 某些事情導致創建數量非常荒謬的控制組，可能採用經典的“叉子炸彈”風格，但具有
systemd基於服務或類似的服務。底線
應該
/sys排除磁碟使用探測，因為/sys任何磁碟上都沒有儲存任何內容。如果您需要監控
/sys/fs/cgroup，您應該為其提供一個專用探測，該探測將提供比通用磁碟空間探測更有意義的警報。