Linuxのkillコマンドを「とりあえずkill -9」で使っていた話|SIGTERMとSIGKILLの違いを知って変わった障害対応の考え方

HOMEリナックスマスター.JP 公式ブログLinux学習ガイド > Linuxのkillコマンドを「とりあえずkill -9」で使っていた話|SIGTERMとSIGKILLの違いを知って変わった障害対応の考え方
宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
「kill -9で止めてみたのに、なぜかまだプロセスが残ってる…」

Linux初心者の頃、プロセスを止めるときに何も考えず kill -9 を使っていました。応答しないプロセスがあれば、とりあえず kill -9 PID。それが唯一知っているプロセス終了の手段でした。

この記事では、SE時代に本番データベースを壊してしまった「kill -9の誤用」から学んだこと、そしてLinuxのシグナルという仕組みを理解してから障害対応がどう変わったかを、20年以上Linuxサーバーを運用してきた経験からお伝えします。

この記事のポイント

シkill -9(SIGKILL)は最後の手段。まずkill(SIGTERM)で正常終了を試みるのが鉄則
シkill -9を多用するとデータファイルが壊れたりゾンビプロセスが残るリスクがある
シsystemctlがあれば、killコマンドを直接使わずsystemctl stopを優先するほうが安全
シシグナルの種類と役割を知ることが、安全な障害対応の第一歩


Linuxのkillコマンドを「とりあえずkill -9」で使っていた話|SIGTERMとSIGKILLの違いを知って変わった障害対応の考え方
「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

「kill -9で止めれば終わり」と思っていたSE時代の話

2003年のことです。私がSEとして初めて担当したLinuxサーバーで、当時使っていたバックアップソフトのプロセスが途中で固まって応答しなくなりました。

「止めてもう一度起動すればいい」——そう判断して、プロセスIDを調べて kill -9 を実行しました。プロセスは消え、再起動も成功したように見えました。

ところが翌日、前夜のバックアップファイルが壊れていると発覚しました。バックアップソフトがディスクへの書き込みを完了する前に、シグナルで強制終了されてしまったのです。ファイルはサイズが0バイトになっており、中身は何も残っていませんでした。

その時初めて、「プロセスを止める方法には、正しい順番がある」ということを知りました。

セミナーで3,100名以上を指導してきた中で、同じような経験をした方に何度もお会いしました。「kill -9以外を使ったことがない」という受講生は珍しくありません。コマンドの使い方は知っていても、シグナルの仕組みを理解していないと、知らないうちに本番データを壊す危険があります。

kill -9が「とりあえず効く」がために、その危険性に気づきにくいことも問題です。エラーがすぐ出るわけではなく、データが静かに壊れるか、ゾンビプロセスという形で問題が後から顕在化します。

そもそもLinuxのシグナルとは何か——なぜkill -9が危険なのか

Linuxでは、プロセス同士やカーネルがプロセスに「特定の動作を要求する」仕組みをシグナル(signal)と呼びます。kill コマンドの名前から「殺す」ことしかできないと思いがちですが、実際には「シグナルを送る」ためのコマンドです。

シグナルにはそれぞれ番号と名前があります。kill -l コマンドで一覧を確認できます。

# シグナルの一覧を確認する # kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP # ps auxでプロセスのIDと状態を確認する # ps aux | grep httpd | grep -v grep www-data 8421 0.0 0.2 116256 3200 ? S 09:11 0:00 /usr/sbin/httpd root 8245 0.0 0.3 118312 4196 ? Ss 09:10 0:00 /usr/sbin/httpd

よく使うシグナルを整理します。

SIGTERM(15):「終了してください」というお願いです。プロセスは受け取った後、後片付け(ファイルのフラッシュ・ロック解除・ログ書き込み)を行ってから終了します。killコマンドのデフォルトはこのSIGTERMです
SIGKILL(9):カーネルが強制的に即座に終了させます。プロセスは後片付けを一切できません
SIGHUP(1):もともとは「ハングアップ(回線切断)」を意味しますが、多くのデーモンは受け取ると設定ファイルを再読み込みします
SIGINT(2):Ctrl+Cを押したときに送られるシグナルです。対話的な割り込みに使われます

SIGKILLが危険な理由は、プロセスに後片付けの機会を与えないことにあります。データベース(MySQLやPostgreSQLなど)は書き込みバッファをディスクにフラッシュする前に強制終了されると、データファイルが壊れたりトランザクションが中途半端な状態に残ったりします。私が経験したバックアップ破損も、この仕組みが原因でした。

SIGTERM・SIGHUP・SIGKILLの実務での違いと使い分け

実務でよく使うシグナルの使い分けを整理します。

まずsystemctl stopを試みる

systemd管理下のサービスであれば、killコマンドを直接使う前に systemctl stop サービス名 を試してください。systemctlはサービス定義に従って適切な停止手順を踏んでくれます。サービスの起動・停止・再起動の管理については「chkconfig/systemctlでサービスを管理する方法」もあわせてご覧ください。

それでも止まらない場合のkillコマンドの使い方

systemctlでも止まらない、またはsystemd管理外のプロセスを止めたい場合は、次の順番でシグナルを送ります。

ステップ1:まずSIGTERM(デフォルト)を送ります。kill PID または kill -15 PID
ステップ2:10秒ほど待ってから ps aux で確認します
ステップ3:それでも生きていたら初めてSIGKILL(kill -9 PID)を打ちます

この「SIGTERM → 待つ → 確認 → SIGKILL」という手順が、プロセスに後片付けの機会を与えるための最低限の配慮です。

SIGHUPの活用(再起動なしで設定を再読み込み)

Apacheやrsyslogなど多くのデーモンは、SIGHUP(シグナル番号1)を受け取ると設定ファイルを再読み込みします。サービスを停止・再起動せずに設定を反映したい場面で使います。

シkill -HUP PID(または kill -1 PID)で送信できます
シsystemctlが使える場合は systemctl reload サービス名 で同等のことができます

SIGHUP対応かどうかはサービスによって異なります。Apache(httpd)はgraceful reloadをサポートしており、処理中のリクエストを終わらせてから設定を再読み込みします。これを知っておけば、深夜のメンテナンス時にサービスを完全に止めずに設定変更を反映できます。

「プロセスが死なない」「ゾンビプロセスになる」トラブルと対処手順

SIGTERM・SIGKILLを送ってもプロセスが消えない、または ps aux でSTATが「Z」になったプロセスが見える——これは現場でよく遭遇するトラブルです。

DステートプロセスはSIGKILLでも死なない

SIGKILL(-9)を送ってもプロセスが消えないケースは、「Dステート(Uninterruptible Sleep)」に入っているときです。これはカーネルのI/O待ちで発生する特殊な状態で、シグナルを受け付けません。

この状態のプロセスは強制終了できません。以下を確認してください。

シNFSマウント先が切断されていないか(umount後にNFSサーバーが落ちた場合によく発生します)
シディスクやストレージデバイスに問題がないか(dmesg | tail -30 でカーネルログを確認してください)
シファイルシステムが正常にマウントされているか(df -h でステータスを確認してください)

DステートプロセスはI/Oが完了するか、原因となっているデバイスを切り離すことで解消されます。それでも残る場合はサーバーの再起動が必要になることがあります。

ゾンビプロセスの確認と対処

ゾンビプロセス(Zステート)は、子プロセスが終了したのに親プロセスが終了ステータスを回収していない状態です。プロセスの実体はなく、プロセスエントリだけが残っています。SIGKILLを送っても消えません。

# ゾンビプロセスを確認する(STATがZまたはZ+のプロセスを検索) # ps aux | grep Z | grep -v grep USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND backup 18423 0.0 0.0 0 0 ? Z 11:42 0:00 [backup.sh] # 親プロセスのPIDをPPIDフィールドで確認する # ps -o pid,ppid,stat,comm -p 18423 PID PPID STAT COMMAND 18423 1842 Z backup.sh # 親プロセスにSIGTERMを送るとゾンビも一緒に回収される # kill 1842

ゾンビプロセスを消すには、親プロセス(PPIDで確認できる)をSIGTERMで終了させます。親プロセスが終了すると、カーネルがゾンビプロセスを自動的に回収します。

親プロセスがsystemd(PID 1)の場合は、カーネルが自動回収するのを待つことになります。少数のゾンビプロセスはシステムに実害を与えないので、大量に発生していなければサービスへの影響はほぼありません。ゾンビが大量発生している場合は、アプリケーション側のバグ(子プロセスのwait処理の漏れ)が原因のことが多く、アプリケーション修正が必要です。

どのプロセスがポートやリソースを占有しているかを確認する方法については「ssコマンド/lsofコマンドでポートとプロセスを確認する」も参考にしてください。

現役講師が20年間守り続けるプロセス終了の「型」

20年以上サーバーを運用してきた経験から言うと、「まずsystemctl、次にSIGTERM、最後にSIGKILL」という順番を守ることが、本番での事故を防ぐ最短の道です。

私が現場で守っている確認手順を紹介します。

1. プロセスの状態を必ず確認してから動く:ps aux | grep プロセス名 でPIDとSTATを確認します。Dステートなら先にI/O問題を調べてください
2. サービス管理コマンドを先に試す:systemd配下なら systemctl stop サービス名 を優先します
3. SIGTERMを送り、必ず10秒待つ:kill PID を打ったら、すぐに kill -9 を打たないでください。後片付けの時間を与えることが大切です
4. 状態を再確認してからSIGKILL:ps aux | grep PID でまだ生きているかを確認してから、初めて kill -9 PID を打ちます

「確認 → 正規手段 → 待つ → 再確認 → SIGKILL」という流れが身についてから、本番での後悔がほぼなくなりました。

【注意】kill -9を使っていい場面と使ってはいけない場面

kill -9が有効なのは、プロセスが完全に応答しなくなってSIGTERMでも止まらないと判断した後です。テスト環境の一時プロセスを即座に止めたい場合も問題ありません。

逆に、データベースやファイルストレージ、メール配信デーモンなど、書き込み中のデータを持つプロセスに対しては、最初にkill -9を使わないでください。後片付けができずにデータが壊れるリスクがあります。2003年の私がやらかした失敗そのものです。

本記事のまとめ

「プロセスを止めるのはkill -9で十分」というのは、新人時代の思い込みでした。シグナルの仕組みを理解してから、本番での事故がほぼなくなったのは事実です。

やりたいこと 推奨コマンド
systemd管理下のサービスを停止する systemctl stop サービス名
プロセスIDを指定してSIGTERMを送る(正常終了) kill PID(デフォルトはSIGTERM)
コマンド名でプロセスをSIGTERM終了する pkill -TERM プロセス名
SIGTERMで止まらない場合の最終手段 kill -9 PID
ゾンビプロセス(Zステート)を消す 親プロセスを終了する(kill PPID
設定ファイルを再読み込みする(再起動なし) kill -HUP PID または systemctl reload サービス名
シグナル一覧を確認する kill -l

「kill -9で止める」から「正しい順番で安全に止める」へ、最初から正しい型を身につけませんか?

SIGTERM → 確認 → SIGKILLの手順を最初から体系的に学んでいれば、本番のデータ破損は防げました。ネットの断片情報を拾い集めるより、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、「Linuxサーバー構築入門マニュアル(図解60P)」を完全無料でプレゼントしています。

「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。