今日は非常に奇妙な問題に遭遇しましたが、これについて私ができることはまったくありません。
私が管理しているサーバーのいくつかは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を使って権限をリセットしても検出器が変更されないようです。
答え1
/システム
/sys
sysfs
現在のシステムカーネルとハードウェア構成を反映し、物理ディスクスペースを消費しないメモリ内カーネル構造の完全に仮想化されたビュー。新しいファイルとディレクトリは通常の方法で書き込むことはできません。
ディスク領域監視を適用すると、有用な情報は生成されず、労力の浪費です。内部には、次のような他のRAMベースの仮想ファイルシステムのマウントポイントがあります。
/システム/カーネル/デバッグ
/sys/kernel/debug
debugfs
さまざまなカーネルのデバッグおよびトレース機能に使用されるオプションの仮想ファイルシステムの標準マウントポイント。
これはデバッグ機能のためであるため、本番用途には必要ありません(システム統計を向上させるため、または同様の機能を強化するために一部を使用することを選択することもできます)。
willが提供する機能を使用することはほとんどの場合とにかくdebugfs
必要で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
汎用ディスク領域プローブよりも意味のある警告を提供する専用プローブを提供する必要があります。