Linux killコマンドの使い方｜シグナル一覧とkill -9・pkill

kill は、プロセスに「シグナル」という合図を送るコマンドです。何も指定しなければ SIGTERM（15番、終了のお願い）を送り、kill -9 は SIGKILL（9番、強制終了）を送ります。 名前の印象とは違い、終了させるだけでなく、一時停止・再開・設定の再読み込みなどの合図にも使います。

この記事では、Ubuntu 24.04.4 LTS（bash 5.2.21、procps-ng 4.0.4、psmisc 23.7、coreutils 9.4）で実際に実行した結果をもとに、全シグナルの早見表、kill・pkill・killall・pgrep の違い、SIGTERM から SIGKILL へ進む手順、エラー表示の再現と対処を説明します。既定動作と「捕捉できるか」は、各シグナルを実際にプロセスへ送って確かめました。systemd と macOS に関する部分は手元で動かせなかったため「未実行」と明記しています。

よく使うシグナルとコマンドの早見表

基本の流れは「kill PID → 数秒待つ → まだ動いていれば kill -9 PID」です。 終了コードは「128＋シグナル番号」になるため、143 は SIGTERM、137 は SIGKILL で終わったことを表します。

kill コマンドの基本

書き方

kill PID                # SIGTERM を送る（既定）
kill -9 PID             # 番号で指定
kill -KILL PID          # 名前で指定（SIG は省略できる）
kill -s KILL PID        # -s で指定
kill -SIGKILL PID       # SIG 付きでもよい
kill PID1 PID2 PID3     # 複数まとめて

PID（プロセスID）は ps や pgrep で調べます。検証では、sleep をコピーして t209worker という名前にしたプログラムを動かして試しました。

./t209worker 300 &
kill $!
wait $!; echo "exit=$?"

実行結果:

exit=143

$! は直前にバックグラウンドで起動したプロセスのPIDです。kill -9 と kill -s INT も同じように試しました。

k.sh: line 4:  7594 Killed                  ./t209worker 300
exit=137
exit=130

kill はシェルの組み込みコマンドでもある

type -a kill

kill is a shell builtin
kill is /usr/bin/kill
kill is /bin/kill

bash で kill と打つと、bash に組み込まれた kill が使われます。/bin/kill は procps-ng パッケージの別のプログラムで、メッセージの形が少し異なります。ジョブ番号（kill %1）を使えるのは組み込みの kill です。

kill -0 でプロセスの存在を確認する

kill -0 はシグナルを送らず、送れるかどうかだけを調べます。スクリプトで「まだ動いているか」を判定するときに使います。

kill -0 $p; echo "kill -0 exit=$?"     # 動いているとき
kill $p; wait $p
kill -0 $p; echo "kill -0 exit=$?"     # 終了したあと

実行結果:

kill -0 exit=0
k.sh: line 6: kill: (7596) - No such process
kill -0 exit=1

kill -l の全シグナル一覧

kill -l の実行結果

kill -l

実行結果（bash 5.2.21 の組み込み kill）:

 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
21) SIGTTIN 22) SIGTTOU 23) SIGURG  24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF 28) SIGWINCH    29) SIGIO   30) SIGPWR
31) SIGSYS  34) SIGRTMIN    35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3
（38〜63 は SIGRTMIN+4 〜 SIGRTMAX-1。省略）
63) SIGRTMAX-1  64) SIGRTMAX

32番と33番は表示されません（スレッドのライブラリが内部で使うためです）。番号と名前は相互に変換できます。

番号はCPUの種類によって一部異なるため、スクリプトでは kill -TERM のように名前で書くと読みやすく、移植もしやすくなります（9 と 15 はどの環境でも共通です）。

標準シグナル（1〜31）の早見表

「既定動作」は、プログラムが何も準備していないときにシグナルを受けるとどうなるかです。既定動作と「捕捉できるか」の列は、x86_64 の Ubuntu 24.04 で各シグナルを実際に送って確かめた結果です（既定動作は sleep プロセスに送って終了状態を確認、捕捉は bash の trap で受け取れるかを確認）。コアダンプの有無は、コアファイルの上限を外した状態で調べました。

（※）20〜22 は一般に「停止」が既定動作とされています。今回の検証では端末につながっていないプロセスに送ったため停止せず、確実に停止したのは SIGSTOP だけでした。スクリプトから一時停止させたいときは kill -STOP を使うと確実です。

この表でいちばん大事なのは、捕捉も無視もできないシグナルは SIGKILL と SIGSTOP の2つだけという点です（Linux の signal(7) のマニュアルにも、この2つは捕捉・ブロック・無視ができないと書かれています）。それ以外は、プログラムが受け取ったときの動作を自分で決められます。

SIGTERM と SIGKILL の違い

SIGKILL はプログラムに知らされないままカーネルが終了させるため、書きかけのファイルやロックファイルがそのまま残ることがあります。まず SIGTERM を送り、後片付けの時間を待つのが基本です。

SIGTERM → 待機 → SIGKILL の手順

後片付けをするプログラムの例

SIGTERM を受け取ると、ロックファイルを消してから終了するスクリプトです。

graceful.sh:

#!/bin/bash
# SIGTERM を受けたら後片付けをして終わる
cleanup() { echo "[$(date +%T)] SIGTERM を受信。後片付けをして終了します"; rm -f /tmp/t209_graceful.lock; exit 0; }
trap cleanup TERM
touch /tmp/t209_graceful.lock
echo "[$(date +%T)] 起動 PID=$$"
while :; do sleep 0.2; done

段階的に止めるスクリプト（コピペ用）

stop.sh:

#!/bin/bash
# 使い方: ./stop.sh PID [待つ秒数]
pid=$1; wait_sec=${2:-10}
kill -0 "$pid" 2>/dev/null || { echo "PID $pid は見つかりません"; exit 1; }
echo "SIGTERM を送信: PID $pid"
kill -TERM "$pid"
for i in $(seq "$wait_sec"); do
    kill -0 "$pid" 2>/dev/null || { echo "${i}秒以内に終了しました"; exit 0; }
    sleep 1
done
echo "${wait_sec}秒待っても動いているため SIGKILL を送信"
kill -KILL "$pid"
sleep 0.5
kill -0 "$pid" 2>/dev/null && { echo "まだ残っています（状態を ps で確認）"; exit 2; }
echo "終了しました"

実行結果1：SIGTERM で終了する場合

./graceful.sh &
./stop.sh $! 5

[08:28:57] 起動 PID=7601
SIGTERM を送信: PID 7601
[08:28:58] SIGTERM を受信。後片付けをして終了します
2秒以内に終了しました

終了後にロックファイルが消えていること（ls で No such file or directory）と、終了コードが 0 であることも確かめました。SIGTERM なら、プログラムが用意した後片付けが実行されます。

実行結果2：SIGTERM を無視するプログラムの場合

trap '' TERM で SIGTERM を無視するスクリプト（stubborn.sh）に対して、同じ手順を実行しました。

./stubborn.sh &
kill $!; sleep 1
ps -o pid,stat,cmd -p $!
./stop.sh $! 3

起動 PID=7616
  PID STAT CMD
 7616 S    /bin/bash ./stubborn.sh
SIGTERM を送信: PID 7616
3秒待っても動いているため SIGKILL を送信
終了しました
k.sh: line 8:  7616 Killed                  ./stubborn.sh
exit=137

kill を送ったあとも ps に残っており、SIGKILL で終了しました。SIGTERM で終わらないことを確かめてから SIGKILL に進む、という順番がこのスクリプトの要点です。待つ秒数は、対象のプログラムが後片付けにかける時間に合わせて決めます。

kill・pkill・killall・pgrep の違い

pgrep と pkill は同じ探し方をする兄弟コマンドです。pkill を実行する前に、同じ引数で pgrep を実行すると、どのプロセスが対象になるかを確認できます。

pgrep で対象を確認する

t209worker を3つ起動した状態で試しました。

pgrep -a t209worker

7673 ./t209worker 301
7674 ./t209worker 302
7675 ./t209worker 303

pkill -f は思ったより広く一致する

-f を付けると、プロセス名ではなくコマンドライン全体と照合します。引数で区別したいときに便利ですが、同じ文字列を引数に含む別のプロセスにも一致します。コマンドラインに t209worker 302 という文字を含む別の bash を動かして確かめました。

pgrep -af 't209worker 302'
pgrep -af '^./t209worker 302$'

実行結果:

7827 ./t209worker 302
7830 bash -c sleep 3; : t209worker 302 note
7827 ./t209worker 302

1つ目のパターンでは、目的のプロセスに加えて bash も一致しました。^ と $ で前後を固定した2つ目では、目的の1件だけになっています。検証中にも、パターンの文字列を引数に持っていた呼び出し元のシェルが pkill -f の対象になり、一緒に終了する場面がありました。pkill -f の前には pgrep -af で一覧を確認し、パターンはできるだけ具体的にすると安心です。

pkill と killall の実行結果

pkill -e -f '^./t209worker 302$'
killall -v t209worker

t209worker killed (pid 7827)
Killed t209worker(7826) with signal 15
Killed t209worker(7828) with signal 15

pkill -e と killall -v は、シグナルを送った相手を表示するオプションです。対象がいないときは次のようになりました。

pkill -x t209worker; echo "pkill exit=$?"
killall t209worker; echo "killall exit=$?"

pkill exit=1
t209worker: no process found
killall exit=1

「未実行」と書いた2つ以外は、すべて今回の検証で動作を確かめています。

プロセス名は15文字までしか照合されない

Linux が保持するプロセス名（/proc/PID/comm）は15文字までです。20文字の名前のプログラムで試しました。

./t209worker_long_name_x 300 &
cat /proc/$!/comm
pgrep t209worker_long_name_x
pgrep -f t209worker_long_name_x

t209worker_long
pgrep: pattern that searches for process name longer than 15 characters will result in zero matches
Try `pgrep -f' option to match against the complete command line.
7843

16文字以上の名前で pgrep や pkill を使うと0件になり、-f を使うよう案内されます。 killall は長い名前でも Killed t209worker_long_name_x(7843) with signal 15 と表示され、対象を見つけられました。

プロセスグループにまとめて送る

親と子をまとめて終了させたいときは、PIDの代わりに「マイナスを付けたプロセスグループID」を指定します。

ps -o pid,pgid,stat,comm -C t209worker
kill -TERM -- -8432

  PID  PGID STAT COMMAND
 8434  8432 S    t209worker
 8435  8432 S    t209worker
kill -TERM -- -8432

-- は「ここから先はオプションではない」という区切りです。実行後、2つとも終了しました（検証環境では親による回収まで数秒のあいだ Z と表示され、その後一覧から消えました）。

エラー表示の再現と対処

No such process

kill 999999
/bin/kill 999999

実行結果:

k.sh: line 9: kill: (999999) - No such process
/bin/kill: (999999): No such process

指定したPIDのプロセスが存在しないときの表示です。すでに終了しているか、PIDの打ち間違いが考えられます。pgrep -a 名前 や ps -p PID で現在のPIDを確認し直します。 PIDは再利用されるので、時間がたったPIDをそのまま使わず、直前に確認するのが確実です。

Operation not permitted

root が動かしているプロセスに、一般ユーザー taro から kill を実行しました（ユーザー名の表示は置き換えています）。

kill 7656
/bin/kill 7656
pkill -x sleep

実行結果:

bash: line 1: kill: (7656) - Operation not permitted
/bin/kill: (7656): Operation not permitted
pkill: killing pid 7656 failed: Operation not permitted

シグナルを送れるのは、自分が動かしているプロセスか、root の権限があるときだけです。 kill -0 でも同じ表示になるので、権限の確認にも使えます。

引数の書き間違い

kill abc
kill -FOO $$

k.sh: line 9: kill: abc: arguments must be process or job IDs
k.sh: line 9: kill: FOO: invalid signal specification

kill にプロセス名は指定できません。名前で指定したいときは pkill か killall を使います。

kill -9 でも消えないゾンビプロセス

ゾンビプロセスは、すでに終了していて、親プロセスが終了状態を受け取る（wait する）のを待っているだけの状態です。ps では Z や <defunct> と表示されます。子がすぐ終了し、親が wait を呼ばないプログラムで再現しました。

zombie.py:

import os, time
pid = os.fork()
if pid == 0:
    os._exit(0)          # 子はすぐ終了
print(f"parent={os.getpid()} child={pid}", flush=True)
time.sleep(600)          # 親は wait() を呼ばない

python3 zombie.py &
ps -o pid,ppid,stat,comm -p 7664
kill -9 7664; echo "exit=$?"
ps -o pid,ppid,stat,comm -p 7664

実行結果:

parent=7662 child=7664
  PID  PPID STAT COMMAND
 7664  7662 Z    python3
exit=0
  PID  PPID STAT COMMAND
 7664  7662 Z    python3

kill -9 はエラーにならず終了コード0を返しますが、Z のまま残っています。すでに終了しているプロセスには、シグナルを受け取って動く部分がないためです。

対処は、親プロセス（PPID）に働きかけることです。 親を終了させると、ゾンビは別のプロセス（通常は PID 1 の init や systemd）に引き取られ、そこで回収されて消えます。この流れを、孤児になったプロセスを引き取る役のプログラムを用意して確かめました。

parent=7962 child=7963
PID  PPID STAT COMMAND
 7963  7962 Z    python3
-- kill -9 の後
PID  PPID STAT COMMAND
 7963  7962 Z    python3
-- 親を終了した直後（引き取り先が wait する前）
PID  PPID STAT COMMAND
 7963  7961 Z    python3
-- 引き取り先が wait() で回収: 7963
PID  PPID STAT COMMAND

親を終了すると PPID が引き取り先（7961）に変わり、回収されたあとは ps の一覧から消えました（最後は見出し行だけ）。

ゾンビはメモリやCPUをほとんど使わないので、少数であれば急いで対処する必要はありません。数が増え続けるときは、親プログラムが子の終了を受け取れていない合図なので、親側を見直します。

kill -9 でも終了しないその他の状態

D の状態は今回再現していません（一般に知られた説明です）。

一時停止と再開（SIGSTOP・SIGCONT）

kill -STOP $p; ps -o pid,stat,comm -p $p
kill -CONT $p; ps -o pid,stat,comm -p $p

実行結果:

  PID STAT COMMAND
10168 T    t209worker
  PID STAT COMMAND
10168 S    t209worker

STAT が T（停止）になり、kill -CONT で S（待機、通常の状態）に戻りました。重い処理を一時的に止めて、あとで続きから再開したいときに使えます。

終了コードからシグナルを読み取る

シグナルで終了したプロセスの終了コードは、シェルからは「128＋シグナル番号」として見えます。ログやスクリプトの $? に見慣れない数字が出たときは、128 を引くとどのシグナルで終わったのかがわかります。今回の検証で確認した値です。

kill -l 137 のように終了コードをそのまま渡すと、bash が KILL と名前に直してくれます。137 を見かけたら「だれか（またはメモリ不足時の仕組み）が SIGKILL を送った」、143 なら「SIGTERM で終了を頼まれた」と読み取れます。

timeout と systemctl kill

timeout で時間制限を付ける

timeout は、指定した時間を過ぎるとコマンドにシグナルを送ります。

timeout -k 待ち秒数 制限秒数 コマンド は、この記事の「SIGTERM → 待機 → SIGKILL」を1行で書ける形です。SIGTERM を無視する stubborn.sh も、-k を付けることで終了しました。終了コード 124 は「時間切れで止めた」ことを表すので、スクリプトで判定に使えます。

systemctl kill（未実行）

systemd が管理するサービスには、systemctl kill でシグナルを送れます。サービスに属するプロセスをまとめて対象にできるのが特徴です。今回の検証環境は systemd が動いておらず（System has not been booted with systemd as init system と表示）、次の書き方は未実行です。

sudo systemctl kill -s HUP nginx            # サービスの全プロセスに SIGHUP
sudo systemctl kill -s TERM --kill-who=main nginx   # メインのプロセスだけ
sudo systemctl stop nginx                   # ふつうに止めるならこちら

サービスを止める目的なら、まず systemctl stop を使います。ユニットに定義された手順で停止し、自動再起動の設定とも整合が取れるためです。

macOS の killall との違い（未実行）

macOS にも kill、pkill、killall がありますが、killall は Linux（psmisc）とは別の実装で、オプションの意味が異なります。macOS は手元で動かせないため、この節は一般に知られた仕様で、未実行です。

同じ killall -s でも意味が変わるので、両方の環境で使うスクリプトでは pkill -x 名前 や kill -TERM PID のように、差の少ない書き方にそろえると安心です。

安全に止めるためのチェックリスト

よくある質問

Q. kill -9 と kill -KILL、kill -SIGKILL は同じですか？ A. 同じです。どれも SIGKILL を送ります。スクリプトでは、意味が読み取りやすい kill -KILL の形がおすすめです。

Q. Ctrl+C と kill は何が違いますか？ A. Ctrl+C は、端末で手前に動いているプロセスに SIGINT（2番）を送ります。kill PID は SIGTERM（15番）を送ります。どちらもプログラム側で受け取って後片付けができるシグナルです。

Q. kill -HUP で設定が再読み込みされるのはなぜですか？ A. SIGHUP を受けたら設定ファイルを読み直す、という動作を各プログラムが自分で用意しているためです。対応していないプログラムでは既定動作どおり終了するので、そのプログラムの説明書で確かめてから使います。

Q. killall と pkill はどちらを使えばよいですか？ A. 名前の完全一致で止めたいなら killall 名前 か pkill -x 名前、引数や親プロセスなど細かい条件で絞りたいなら pkill が向いています。どちらも、先に pgrep -a で対象を確認すると安心です。

まとめ

• kill PID は SIGTERM（15）、kill -9 PID は SIGKILL（9）を送る。終了コードは 143 と 137
• 捕捉も無視もできないのは SIGKILL と SIGSTOP の2つだけ。ほかはプログラムが動作を決められる
• 手順は「SIGTERM → 待つ → SIGKILL」。timeout -k なら1行で書ける
• pkill は部分一致、killall は完全一致。pkill の前に同じ引数の pgrep で対象を確認する
• pkill -f はコマンドライン全体と照合するため、^ と $ でパターンを固定する
• Operation not permitted は権限、No such process はPIDの確認で対処する
• ゾンビは kill -9 では消えない。親プロセスに対処すると回収される

株式会社RJCでは、killコマンドとシグナルの使い分けを仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。