/ 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

/sysisはsysfs、現在のシステムカーネルとハードウェア構成を反映し、実際のディスク領域を消費しない、メモリ内のカーネル構造を完全に仮想化したビューです。新しいファイルとディレクトリを通常の方法で書き込むことはできません。

ディスクスペースモニタリングを適用しても、有用な情報は得られず、労力の無駄になります。内部に他のRAMベースの仮想ファイルシステムのマウントポイントがある場合があります...

/ sys / kernel / debug

/sys/kernel/debugは、の標準のマウントポイントですdebugfs。これは、さまざまなカーネルデバッグおよびトレース機能用のオプションの仮想ファイルシステムです。

これはデバッグ機能用であるため、本番環境では不要であると考えられます（一部の機能を拡張システム統計などに使用することもできます）。

debugfswill が提供する機能を使用するには、ほとんどの場合、rootとにかく必要があり、その主な目的は、カーネル開発者がデバッグ情報を提供する簡単な方法であることから、少々「大雑把」かもしれません。

カーネルが読み込まれると、カーネルトレースサブシステムの初期化ルーチンは、/sys/kernel/debug/tracingそれ自体がdebugfsアクセスポイントとして登録され、初めて実際にアクセスされるまで初期化を延期します（判明した場合に備えて、トレースサブシステムのリソース使用量を最小限に抑えます）必要ありません）。いつcdディレクトリに「D、この延期の初期化がトリガとトレースサブシステムは、使用のために自分自身を準備されました。実際、オリジナル/sys/kernel/debug/tracingは実体のないミラージュでしたが、cdコマンドでアクセスしたとき（そしてそのため）だけが「リアル」になりました。

debugfs 実際のディスク領域はまったく使用しません。その中に含まれているすべての情報は、カーネルがシャットダウンすると消えます。

/ sys / fs / cgroup

/sys/fs/cgroupは、tmpfsRAMベースのファイルシステムで、実行中のさまざまなプロセスをコントロールグループにグループ化するために使用されます。実際のディスク領域はまったく使用しません。しかし、このファイルシステムが何らかの理由でほぼ満杯になっている場合は、単にディスク領域が不足するよりも深刻な場合があります。

a）RAMが不足している

b）ルートが所有するプロセスがにゴミを書き込んでいる/sys/fs/cgroup、または

c）何かが、おそらく古典的な「フォーク爆弾」のスタイルで、systemdベースのサービスまたは類似のものを使用して、本当に不合理な数のコントロールグループを作成させている。

ボトムライン

/sys何/sysもディスクに保存されていないため、ディスク使用状況プローブは除外されているはずです。

を監視する必要がある場合/sys/fs/cgroupは、汎用のディスクスペースプローブよりも意味のあるアラートを提供する専用のプローブを提供する必要があります。