majortool-misuseverifiedfirsthand
サーバ1本の再起動のつもりが、9プロセスを道連れにした
AIコーディングエージェント（Claude Code）がローカルのサーバを1本だけ再起動しようとして、127.0.0.1で通信していた9つのプロセスにまとめてSIGTERMを送った。
原因
lsof に -i を2つ重ねると条件がOR扱いになり、ポート指定が効かなくなる。その検索結果を kill $(...) の形でそのまま kill に渡していたため、確認の機会が一度もなかった。
結果
自作のアプリランチャー、自作の販売管理ダッシュボード、別セッションの検証用サーバ2本、ログイン項目の常駐アプリ（推定）、正体不明の3本が止まった。ランチャーとダッシュボードは再起動して復旧した。
対策
kill の前に必ず PID を1つに絞って表示し、コマンド名と作業ディレクトリを目で確かめてから止める。検索結果をそのまま kill に渡す kill $(...) の形は使わない。
何が起きたか
頼んだのは、自作の文字起こしアプリのサーバを再起動することだけだった。 AIコーディングエージェント（Claude Code）は、そのポートで待ち受けている プロセスを探して止める一行を組み立てた。
kill $(lsof -tiTCP:<ポート> -sTCP:LISTEN -a [email protected] || ...)
見た目は慎重だ。ポートを指定し、LISTEN状態に絞り、ループバックに限定している。 だが実際に SIGTERM を受け取ったのは1本ではなく、127.0.0.1 で通信していた 9つのプロセスだった。
現場の混乱
止まったものの一覧がそのまま被害報告になった。
- 自作のアプリランチャー（とその転送機能）
- 自作の販売管理ダッシュボード
- 別のセッションが検証に使っていたサーバ2本
- ログイン項目で常駐していたアプリ（推定）
- 正体の分からないプロセス3本
最後の2項目が厄介だった。何を止めたのかを後から完全には特定できていない。 「推定」と「正体不明」が残る時点で、止めた側は影響範囲を説明しきれない。 ランチャーと販売管理ダッシュボードは再起動して復旧したが、ほかのものが その後どうなったかは記録に残っていない。
しかも、止まったプロセスの中には別のセッションが使っていたものが混ざっていた。 自分の作業とは無関係なところで、誰かの検証環境がいきなり消えたことになる。
原因
直接の原因は lsof のオプションの読み違いだ。-i を2つ重ねると、それぞれの
条件がOR扱いになり、ポート番号での絞り込みが効かなくなる。結果として
「127.0.0.1 で通信しているもの全部」が返ってきた。
もう一つの原因は、その結果を kill $(...) の形でそのまま kill に流し込んだことだ。
検索と実行が1行に溶け合っていたため、「何件返ってきたか」「それは何か」を
人もエージェントも一度も見ていない。検索式の誤りは誰にでも起こるが、
この書き方だと誤りがそのまま実害に直結する。
プロセスを止める操作は後戻りできない。常駐アプリや他のセッションまで 巻き込む可能性がある操作を、確認の段を持たない一行で実行していた。
対策
- kill する前に、必ず PID を1つに絞って表示する。コマンド名と作業ディレクトリを
確かめてから止める。
lsof -iTCP:<ポート> -sTCP:LISTEN -Pの出力を目で見る。 kill $(...)のように、検索結果をそのまま kill に渡す書き方はしない。- 同じポートを別の仕組み（転送など）も握っている場合は、止めたい側の PID だけを選ぶ。ポート番号だけで「止める相手」を決めない。
これはAIエージェントに渡す作業ルールとして記録した。検索式の正しさを 信じるのではなく、「実行前に対象を1件ずつ見る」段を必ず挟む。
出典
- 運営者自身が起こした事故の一次記録です。外部に公開された元記事はありません。