/ sys / kernel / debug / tracingに「cd」すると、権限が変更されます
今日私は本当に奇妙な問題に直面しました、そしてそれについて完全に無力です。
私が管理するサーバーの一部は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/kernel/debug
/sys/kernel/debugはdebugfsの標準のマウントポイントです。これは、さまざまなカーネルデバッグおよびトレース機能用のオプションの仮想ファイルシステムです。
これはデバッグ機能用であるため、本番環境では不要であると考えられます（一部の機能を拡張システム統計などに使用することもできます）。
とにかくdebugfsが提供する機能を使用するには、ほとんどの場合rootである必要があり、その主な目的は、カーネル開発者がデバッグ情報を提供する簡単な方法であることなので、少々 "エッジの周りが荒い。」.
カーネルが読み込まれると、カーネルトレースサブシステムの初期化ルーチンは、自分自身のdebugfsアクセスポイントとして/sys/kernel/debug/tracingを登録し、初めて実際にアクセスされるまで追加の初期化を延期します（トレースサブシステムのリソース使用量を最小限に抑えます）必要ないことが判明した場合）。ディレクトリに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を監視する必要がある場合は、専用のプローブを提供する必要があります。これにより、一般的なディスクスペースプローブよりも意味のあるアラートが提供されます。