Linuxで動作中の処理を調べるときは、プロセス、シェルのジョブ、systemdのサービスを区別することが出発点です。PIDだけを見て終了操作へ進むと、同名プロセスの取り違えやPID再利用によって別の処理へシグナルを送る危険があります。まず所有者、親PID、開始時刻、経過時間、状態、完全なコマンド行を読み取り、対象を一意に確定します。
結論は「最初はps、pgrep、jobs、/procによる読み取りだけを行い、サービスならsystemctl statusも照合します。停止が必要な場合は対象を再確認してTERMを送り、終了を待ってから結果を検証します。KILLは後処理を実行できないため、応答しないことを証拠で確認した最後の選択肢です。」です。
プロセス・ジョブ・サービスを切り分ける
プロセスはカーネルが管理する実行単位でPIDを持ち、PPIDは親プロセスを示します。ジョブは対話シェルがパイプラインを管理するための概念で、jobs、fg、bgなどは同じシェルのジョブ表を対象にします。サービスはsystemdなどのサービスマネージャーが再起動方針や依存関係を含めて管理します。psのSTATには実行中、割り込み可能な待機、停止、ゾンビなどが表れますが、一回の表示だけでは瞬間的な状態しか分かりません。
- 対象は単一プロセス・シェルジョブ・systemdサービスのどれか
- PID・PPID・所有者・開始時刻・経過時間・完全なコマンド行
- 同名プロセスやworkerが複数存在しないか
- 監視機構やサービスマネージャーが自動再起動しないか
- 停止時に失われる処理・接続・未保存データがないか
プロセス名だけの検索結果は確定情報ではありません。pgrepでは完全な引数を表示し、psでは開始時刻と所有者も並べます。対象PIDが分かったら/proc/PID/statusでName、State、Pid、PPid、Uidなどを照合します。長時間の調査ではPIDが再利用され得るため、操作直前に開始時刻とコマンド行を再取得します。コンテナやPID名前空間の内部とホストでは見えるPIDが異なる点にも注意します。
プロセス、対話shellのjob、systemd serviceを区別します。ps -eoでPID、PPID、user、STAT、開始時刻、経過時間、完全なcommand lineを表示し、pgrep -a -fは候補抽出として使います。同名workerが複数いる場合はparent、cgroup、namespace、ownerを確認します。古いメモのPIDは再利用されるため、操作直前に/proc/PID/statusと開始時刻を再取得します。
読み取り専用の観察から対象を確定する
最初に自分のシェルPIDを基準例として観察し、次に検索条件を文字列から所有者、親、起動引数へ絞ります。サービス由来なら個別PIDへ直接シグナルを送る前にunit状態とMainPIDを確認します。停止が承認された場合はTERMで正常終了を要求し、一定時間ごとに存在と状態を読み取ります。終了しない場合はログ、I/O待ち、子プロセス、ハンドラーの有無を調べ、KILLへ進む理由と影響を記録します。
一覧の列を明示して観察
ps -eo pid,ppid,user,stat,lstart,etime,cmd --sort=pidPIDだけでなく開始時刻、経過時間、所有者、完全なコマンドを同じ行で比較します。表示幅で末尾が省略されていないかも確認します。
現在のシェルを基準に読む
ps -p $$ -o pid,ppid,user,stat,lstart,etime,cmd既知の安全な対象で列の意味を確認できます。ダブルドルは現在のシェルPIDへ展開されます。
候補を引数付きで検索
pgrep -a -f -- 'worker-name'候補抽出に使い、結果をそのまま終了対象とはみなしません。短い一般語ではなく識別力のある引数を選びます。
同じシェルのジョブを確認
jobs -l対話シェルが管理するジョブ番号とPIDを表示します。別端末や別シェルの処理はこの一覧に現れません。
確定したPIDの状態を読む
pid=1234
sed -n '1,12p' "/proc/$pid/status"1234は観察で確定した値へ置き換えます。ファイルが消えた場合はプロセス終了とPID再利用を考え、検索からやり直します。
読み取りだけのps、pgrep、jobs -l、/proc/PID/status、systemctl statusを先に使い、管理主体を特定します。停止が承認された単独processには通常TERMで正常終了を要求し、一定時間ごとに存在と状態を確認します。service管理下なら個別PIDへkillせずsystemctl等の正式手順を使います。応答しない場合もlog、I/O待ち、child、handlerを調べてからKILLの必要性を判断します。
PID・PPID・状態・経過時間を読む
psは観察時点のスナップショットです。STATのRは実行中または実行可能、Sは割り込み可能な待機、Dは割り込み不能な待機、Tは停止、Zは終了したが親に回収されていないゾンビを表します。ゾンビへKILLを送っても回収は進まず、親プロセス側のwait処理を調べる必要があります。killコマンドは既定でTERMを送り、成功ステータスはシグナル送信要求が受理されたことを示すだけで、アプリケーションが正常終了した保証ではありません。
- PIDとPPIDはプロセス関係を示すがPIDは将来再利用される
- jobsは現在のシェルが管理するジョブだけを扱う
- psの表示は一時点であり状態遷移を継続観察する必要がある
- TERMは処理側が捕捉して後処理できるがKILLは捕捉できない
- ゾンビは既に終了しており親による終了状態の回収を待っている
PIDはprocess識別子ですが将来再利用され、PPIDは親関係を示します。jobsは現在のshellが管理するpipelineだけを扱い、別terminalのprocessは表示しません。STATのZは既に終了して親のwaitを待つzombieなのでkill -9では回収できません。kill commandの成功はsignal送信要求が受理されたことを示し、applicationがdataをflushして正常終了した保証ではありません。
シグナル送信とPID再利用の危険を理解する
本番環境では終了操作の前に対象、所有者、開始時刻、コマンド行、サービス管理者、影響範囲、復旧方法を二者確認します。kill -9、killall、pkillの広いパターンを最初の手段にしません。データベースやキューworkerは正常終了手順とdrain方法を製品の公式手順で確認します。root権限へ上げる前に、現在の権限で読み取れる情報と正規のサービス操作を使います。
- 名前が一致した候補すべてを同じ処理とみなす
- 古いPIDメモを操作直前に再確認しない
- TERMを待たず直ちにKILLへ進む
- サービス管理下の子PIDだけを終了して自動再起動に気付かない
- ゾンビを実行中プロセスと誤解してシグナルを繰り返す
killallや広いpkill pattern、kill -9を最初に使いません。database、queue、storage、backup processには製品固有のdrain・shutdown手順があります。rootで停止する前にowner、開始時刻、command line、service unit、利用者影響、冗長系、rollbackを二者確認します。container内PIDとhost PIDを混同せず、namespaceとorchestratorの管理対象を確認します。
誤停止を防ぐ確認記録を残す
終了や再起動を行った場合は、旧PIDの消滅だけでなく、新しいPIDの有無、サービス状態、未処理件数、接続、ログの終了理由、利用者向け機能を確認します。正常終了では終了コードやflush完了記録を確認し、強制終了では破損検査と再処理範囲を追加します。操作しなかった場合も、候補を除外した根拠と監視継続条件を残します。
- 対象の種類と管理主体を特定した
- PID・開始時刻・所有者・完全な引数を操作直前に照合した
- 必要な場合だけ正常終了手順を使い結果を観察した
- サービス・データ・利用者機能まで終了後の状態を確認した
停止後は旧PIDが消えただけでなく、新PIDへの自動再起動、service状態、listen port、未処理queue、logの終了理由、利用者機能を確認します。正常終了ならexit codeとflush完了を、強制終了なら破損検査と再処理範囲を追加します。高負荷調査なら一回のpsではなく一定間隔のCPU・memory・I/O・state推移を記録します。
通常運用と障害対応の境界を決める
単なる高負荷なら、終了より先にCPU、メモリ、I/O、待機、子プロセスを継続観察します。明らかな異常でも冗長系や再実行保証が不明なら運用責任者へ判断を上げます。シェルジョブはjobsとfg/bg、サービスはサービスマネージャー、単独プロセスは所有者と正常終了仕様に沿うという境界を守ると、場当たり的な強制停止を減らせます。
単なる高負荷や一時的なD stateなら即停止せず、I/Oと依存先を観察します。対話jobはjobs/fg/bg、systemd serviceはservice manager、containerはorchestrator、単独processはownerとアプリ手順に従います。対象を一意にできない、冗長性が不明、data損失があり得る場合は停止せず運用責任者へ判断を上げます。
コメント