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

Linux の defunct ゾンビプロセス?kill の前に親と wait 境界を証明する

ゾンビはすでに終了しています。回収を担うのは生きている親、subreaper、またはコンテナ PID 1 です。子と親の同一性を固定してから、一つの安全な回収境界だけを直します。

オリジナルイラスト:子プロセスが終了してゾンビとなり、親が wait で回収する流れ。
オリジナルイラスト:診断対象は終了済みの子ではなく、生きている親です。 Watch at Ease

ゾンビは再度 kill できる実行中タスクではなく、親または reaper が読むのを待つ終了済み子プロセスの状態記録です。したがって、安全な調査は強いシグナルではなく親の同一性から始まります。

子 PID と開始時刻、親 PID と開始時刻、サービスまたはコンテナ境界、Z 状態数の推移を保存します。実際に wait を所有する一箇所を直し、元の起動経路で回収が有界であることを確認します。

1. 親を再起動する前に記録を固定する

ps 全文、子 PID、親 PID、コマンド、ユーザー、コンテナまたは unit、初回時刻、Z 数を保存し、/proc の開始時刻で PID 再利用を防ぎます。

子への kill -9 や全親プロセスへの一括シグナルから始めてはいけません。無関係なサービスを停止する危険があります。

2. 生きている親と wait 境界を証明する

同じ名前空間で Z と PPID を確認し、親を実行ファイル、開始時刻、サービス、supervisor、デプロイに対応付けます。

一時的なゾンビは短時間なら正常なこともあります。同じ負荷で安定または増加する数を欠陥の証拠にします。

3. PID 名前空間と subreaper を含める

コンテナ PID 1 はアプリまたは小さな init で、ホスト init とは別です。Docker --init の回収責任を確認します。

init の追加だけでアプリの待機不具合が直るとは限りません。長寿命の親は自分の子を正しく wait する必要があります。

4. 親に最小影響の修復を選ぶ

自作プログラムなら全終了子を回収し、バーストとエラー経路を含むライフサイクルを修正します。

第三者ソフトは証拠保存後に文書化された再起動または更新を優先し、依存とロールバックを理解せず親を終了しません。

5. 元の起動経路で有界な回収を確認する

同じ unit、コンテナコマンド、supervisor または wrapper で負荷を再現し、親同一性と Z 数を一定間隔で測ります。

親が健全で、終了子が回収され、Z 数が基準に戻り、無関係なプロセスが影響を受けない場合だけ完了とします。

オリジナルイラスト:コンテナ PID 1 が孤児となった子を引き取り回収する流れ。
オリジナルイラスト:ホスト PID 1 とコンテナ PID 1 は別の運用境界です。 Watch at Ease