テクノロジー · 実用ガイド

Linux の「inotify watch limit reached」― sysctl を上げる前にプロセスと上限を特定する

inotify の ENOSPC は、ユーザー単位のインスタンス枯渇、watch 枯渇、または別系統のイベントキューあふれを示し得ます。まず稼働中の記述子と監視対象を所有プロセスへ結び付け、範囲を絞るか、証明できた上限だけを変更します。

執筆 Watch at Ease News · 3 分で読めます公開 2026/10/19 2:17 UTC

max_user_instances と max_user_watches は実ユーザー ID 単位で計上されます。 max_queued_events は新しい inotify インスタンスに積めるイベント数を制限します。

1. 呼び出し元と課金対象の ID を保存する

再起動前に、完全な ENOSPC メッセージ、プログラム、PID、実効 UID と実 UID、コンテナまたはサービス境界、監視ルート、最初の時刻を記録します。カーネルオブジェクトを持つホストで 3 個の fs.inotify 値も保存します。

errno 名だけでディスク不足と決めず、広く共有された sysctl 値を貼り付けないでください。3 個の制御は別の資源を表し、同じ実 UID の複数プロセスが同じユーザー枠を共有します。

inotify インスタンス作成時の失敗はインスタンス上限、watch 追加時の失敗は watch 上限を疑います。ただしライブラリがシステムコールを隠すため、元の呼び出し経路を残します。

キューあふれは別問題です。インスタンスは既に存在し、読み取りが追い付かず、IN_Q_OVERFLOW が届きます。max_user_watches を増やしても失ったイベントは戻らず、再走査が必要です。

PID と実 UID ごとに inotify 記述子を列挙し、/proc/<pid>/fdinfo/<fd> を調べます。inotify 行を数えて watch 数を推定し、公開チケットには wd、inode、device、mask の小さなサンプルだけを残します。

最大の所有プロセスと想定監視ルートを比較します。再帰ツールには多数の watch が正当な場合もありますが、重複依存木、生成物、bind mount、再起動ループは数を増幅します。

重複ルートを除き、対応ツールでは生成物や依存ディレクトリを除外し、インスタンスを漏らすループを修正します。証拠保存後に特定プロセスだけを再起動し、帰属を消す全体再起動は避けます。

正当な定常需要が証明した上限を超える場合だけ、その一項を管理された sysctl で変更します。旧値、理由、予想ピーク、ロールバック条件を記録し、3 項を同時に上げません。

制御したワークロードを一つ起動し、実 UID と PID のインスタンス数・watch 数が想定範囲で安定し、再ビルドごとに増え続けないことを確認します。

監視ルートで代表的な作成、変更、改名、削除を行い、必要イベントをすべて受信し、IN_Q_OVERFLOW がなく、他ユーザーにも余裕があることを確認します。未達なら変更を戻します。