【完全比較】Linux kill vs pkill vs killall の違いと使い分け

Linux でプロセスを終了する時に使う3大コマンド:

kill 12345              # PID を指定
pkill -f "my_script"    # パターンで検索して終了
killall nginx           # 名前で全部終了

一見似ていますが、検索方法・対象範囲・危険度が全く違います。

サーバー運用・開発の現場でよく遭遇する場面:

• 暴走したプロセスを止めたい
• 特定のスクリプトだけ終了したい
• Node.js / Python プロセスを全部殺したい
• Nginx の設定リロード
• Docker コンテナ内プロセスの終了

しかし、いざ使おうとすると:

• kill -9 を最初から使っていいの？
• pkill と killall はどう違うの？
• pkill -f の -f って何？
• SIGTERM と SIGKILL の使い分けは？
• 「他人のプロセスまで殺してしまった」を防ぎたい
• Docker では何を使う？
• systemd と併用は？

など、正しく使い分けないと本番環境で事故を起こす可能性がある繊細なコマンド群です。

本記事では、kill / pkill / killall のすべての違いと使い分けを、リファレンスとして実用的に整理します。基本コマンド、シグナル完全解説、オプション、graceful shutdown、プロセス検索連携、Docker/systemd 連携、危険パターン、実践シナリオ、FAQまで完全網羅。この1本でプロセス終了を安全かつ意図通りに実行できるようになります。

結論：3コマンドの違いを一発で理解

時間がない方向けに、最重要ポイントを先に示します。

早見表

一言で言うと

• kill: PID がある時（ps で確認済み等）
• pkill: パターン検索で柔軟に指定したい時
• killall: 名前で完全一致させたい時

「まず SIGTERM、次に SIGKILL」の原則

# ✅ 推奨
kill 12345           # SIGTERM（graceful）
sleep 5
kill -9 12345        # 効かなければ SIGKILL

# ❌ いきなり -9 は事故のもと
kill -9 12345        # データ破損・ゾンビ化の危険

詳細は以下で解説します。

まず押さえる：シグナルとは

シグナル = プロセスへの「合図」

シグナルは Linux カーネルがプロセスに送るソフトウェア割り込み。プロセスは受け取ったシグナルに応じて挙動を変えます。

kill 12345 → SIGTERM 送信 → プロセス「終了処理して自主的に終わろう」

主要シグナル一覧

kill -l   # シグナル一覧

SIGTERM vs SIGKILL の決定的違い

SIGTERM（15）:
  ├─ プロセスが受信
  ├─ 独自のハンドラで処理可
  ├─ ファイル・接続クローズ
  ├─ バッファフラッシュ
  └─ 正常終了

SIGKILL（9）:
  ├─ カーネルが直接プロセス破壊
  ├─ プロセスは何もできない
  ├─ ハンドラ実行なし
  └─ データ破損・ゾンビ・リソース残置の可能性

⚠️ SIGKILL と SIGSTOP は捕捉・無視・ブロック不可。他のシグナルはプロセス側でハンドリング可能。

なぜ -9 を安易に使うと危険か

• データ破損: 書き込み途中のファイルが不完全
• ロックファイル残置: 次回起動時に「既に動いている」誤検知
• 子プロセスの孤児化 or ゾンビ化
• 接続の異常終了: DB 接続、TCP 通信のリソース残置

kill コマンドの詳細

基本構文

kill [-シグナル] PID [PID ...]

使用例

# デフォルト（SIGTERM）
kill 12345

# シグナル番号指定
kill -15 12345
kill -9 12345

# シグナル名指定
kill -TERM 12345
kill -SIGTERM 12345
kill -KILL 12345
kill -HUP 12345

# 複数PID
kill -TERM 12345 12346 12347

シグナル一覧を確認

# 全シグナル
kill -l

# 名前→番号
kill -l TERM
# 15

kill -l KILL
# 9

# 番号→名前
kill -l 15
# TERM

kill -0：生存確認（重要テクニック）

kill -0 12345
# シグナル送信せず、プロセスの存在＆権限をチェック

戻り値:

• 0: プロセス存在＆シグナル送信権限あり
• 1: プロセス不在 or 権限なし

活用:

if kill -0 12345 2>/dev/null; then
  echo "PID 12345 は生きている"
else
  echo "PID 12345 は死んでいる or 権限なし"
fi

プロセスグループへの送信

# 負のPID = プロセスグループID
kill -TERM -12345
# PGID 12345 の全プロセスに SIGTERM

# 全プロセスグループ
kill -TERM -1
# 自分が権限を持つ全プロセス（危険！）

権限

• 自分のプロセス: 制限なし
• 他ユーザーのプロセス: sudo 必要
• PID 1（systemd/init）: 通常 SIGKILL は効かない

# 他ユーザーのプロセス
sudo kill 12345

pkill コマンドの詳細

基本構文

pkill [オプション] パターン

基本的な使い方

# 名前に "python" を含むプロセスに SIGTERM
pkill python

# シグナル指定
pkill -9 python
pkill -SIGTERM python
pkill -HUP nginx

# 存在確認（pgrep との組み合わせ）
pgrep -fl python
# 12345 python /opt/app/main.py
# 12346 python -m http.server

# 確認後、実行
pkill python

主要オプション

-f：フルコマンドラインで一致（最重要）

# ❌ デフォルトは「プロセス名」のみ（最初の15文字程度）
pkill "main.py"
# マッチしない（プロセス名は "python"）

# ✅ -f で完全なコマンドラインで検索
pkill -f "main.py"
# python /opt/app/main.py → マッチ

# ✅ 特定スクリプトを狙い撃ち
pkill -f "gunicorn myapp:app"

-f が pkill 最強のオプション。スクリプト名や引数で特定できる。

-u：ユーザー指定

# 特定ユーザーのプロセスのみ
pkill -u alice python

# 複数ユーザー
pkill -u alice,bob nginx

-n / -o：最新 / 最古

# 最新のマッチプロセスだけ
pkill -n -f "python main.py"

# 最古のマッチプロセスだけ
pkill -o -f "python main.py"

-e：終了したプロセス名を表示

pkill -e python
# python killed (pid 12345)
# python killed (pid 12346)

CI/CD や自動化スクリプトで何を終了したか記録したい時に便利。

-c：カウントのみ

pkill -c python
# 3

# 実際に終了はする

–signal / -SIG

pkill --signal HUP nginx
pkill -HUP nginx           # 同上（短縮）
pkill -1 nginx             # 番号でも同上

実践パターン

# 開発用サーバーを全部停止
pkill -f "rails server"
pkill -f "puma"
pkill -f "webpack-dev-server"

# 特定ユーザーの python プロセス全部
pkill -u appuser python

# 特定ポートで動く Node.js
lsof -ti :3000 | xargs kill

詳細はAddress already in use の記事も参照。

killall コマンドの詳細

基本構文

killall [オプション] プロセス名

基本的な使い方

# nginx プロセスを全部 SIGTERM
killall nginx

# 強制終了
killall -9 nginx
killall -SIGKILL nginx

# 特定シグナル
killall -HUP nginx        # 設定リロード

pkill との違い

# killall: 完全一致
killall python
# → プロセス名が正確に "python" だけマッチ

# pkill: 部分一致
pkill python
# → "python3", "python2.7" 等もマッチ

killall は名前完全一致、pkill は部分一致（正規表現可）。

主要オプション

-e：正確に完全一致（デフォルトの厳密化）

killall -e python
# 完全に "python" のみ
# "python3.11" にはマッチしない

-r：正規表現

killall -r "^python.*"
# python, python3, python-app 全部

-i：確認プロンプト

killall -i nginx
# Kill nginx(1234) ? (y/N)
# Kill nginx(1235) ? (y/N)

本番運用で誤爆を避けるための重要オプション。

-I：大文字小文字を無視

killall -I NGINX
# nginx, Nginx, NGINX 全部

-u：ユーザー指定

killall -u www-data nginx

-w：待機（プロセス終了まで）

killall -w nginx
# nginx が実際に終了するまでブロック

停止確認までしたい時に便利。

-q：quiet モード

killall -q nonexistent
# エラーメッセージなし

-o / -y：起動時刻でフィルタ

# 1時間以上前から動いているプロセス
killall -o 1h nginx

# 1時間以内に起動したプロセス
killall -y 1h nginx

killall の重大な落とし穴（Solaris/BSD）

⚠️ 一部のUnix系OS（旧Solaris等）では killall の挙動が違う:

• Linux: 名前で指定したプロセスを終了
• 旧Solaris: 全プロセスを終了（システムシャットダウン）

Linux では安全ですが、リモートサーバーの OS を確認して使用。

プロセス検索と組み合わせ

ps コマンド

# 全プロセス
ps -ef
ps aux

# 検索
ps -ef | grep python

# grep 自身を除外
ps -ef | grep [p]ython
# or
ps -ef | grep python | grep -v grep

# ユーザー指定
ps -u alice

# フォーマット指定
ps -eo pid,user,cmd | grep python

詳細はLinux grep オプション一覧の記事も参照。

pgrep（推奨）

# プロセス名検索
pgrep nginx

# 詳細表示（-l で PID+名前）
pgrep -l nginx
# 1234 nginx

# フルコマンドライン
pgrep -f "gunicorn myapp"

# ユーザー指定
pgrep -u alice python

# 詳細フル表示
pgrep -a python
# 12345 python /opt/app/main.py

pkill 前に pgrep で確認する習慣

# ステップ1: 確認
pgrep -fl python
# 12345 python /opt/app/main.py
# 12346 python -m http.server

# ステップ2: 意図通りなら pkill
pkill -f python

pgrep → pkill の順番で誤爆を防ぐ。

Graceful Shutdown パターン

標準的な段階的終了

#!/bin/bash
# graceful_shutdown.sh
PID=12345

# 1. SIGTERM 送信
kill -TERM $PID

# 2. 猶予期間（5秒）
sleep 5

# 3. まだ生きているなら SIGKILL
if kill -0 $PID 2>/dev/null; then
  echo "SIGTERM failed, sending SIGKILL"
  kill -KILL $PID
else
  echo "Process terminated gracefully"
fi

systemd スタイル

# TERM 待ち → タイムアウト後 KILL
timeout 30 bash -c 'while kill -0 12345 2>/dev/null; do sleep 1; done'
kill -0 12345 2>/dev/null && kill -9 12345

複数プロセスの graceful stop

# 全 python プロセスに TERM
pkill -TERM python
sleep 5

# 生き残りに KILL
pkill -KILL python

アプリ側での SIGTERM ハンドリング（参考）

# Python
import signal
import sys

def graceful_exit(signum, frame):
    print("Shutting down gracefully...")
    # クリーンアップ処理
    sys.exit(0)

signal.signal(signal.SIGTERM, graceful_exit)
signal.signal(signal.SIGINT, graceful_exit)

# Ruby
Signal.trap("TERM") do
  puts "Shutting down..."
  # cleanup
  exit
end

正しく作られたアプリは SIGTERM で綺麗に終了。SIGKILL は最終手段。

SIGHUP による設定リロード

多くのデーモンは SIGHUP で設定ファイルを再読み込み:

# Nginx の設定リロード（再起動不要）
kill -HUP $(cat /var/run/nginx.pid)
# または
nginx -s reload

# rsyslog
kill -HUP $(pidof rsyslogd)

# sshd
sudo systemctl reload sshd
# または
sudo kill -HUP $(pidof sshd)

⚠️ すべてのデーモンが SIGHUP でリロードするわけではない。マニュアル確認:

man sshd | grep -A5 SIGHUP

systemctl reload 推奨

# systemd 管理下なら
sudo systemctl reload nginx
sudo systemctl reload sshd

サービスの ExecReload= で定義された動作を実行。

Docker との連携

docker kill

# コンテナに SIGKILL（デフォルト）
docker kill container_name

# シグナル指定
docker kill --signal=SIGTERM container_name
docker kill --signal=SIGHUP container_name

docker stop（graceful）

# SIGTERM → タイムアウト後 SIGKILL
docker stop container_name

# タイムアウト時間指定（デフォルト10秒）
docker stop -t 30 container_name

docker stop vs docker kill

通常は docker stop、緊急時のみ docker kill。

docker exec 内での kill

# コンテナ内のプロセスに操作
docker exec container_name kill -HUP $(pidof nginx)

Docker daemon 全体

Docker daemon 停止:

sudo systemctl stop docker

詳細はdocker daemon 接続エラーの記事も参照。

systemd との連携

systemctl 経由（推奨）

# サービス停止
sudo systemctl stop nginx

# 再起動
sudo systemctl restart nginx

# リロード（設定のみ）
sudo systemctl reload nginx

# 強制終了
sudo systemctl kill nginx
sudo systemctl kill -s KILL nginx

systemd unit 内の設定

# /etc/systemd/system/myapp.service
[Service]
KillSignal=SIGTERM
TimeoutStopSec=30
KillMode=mixed
ExecReload=/bin/kill -HUP $MAINPID

• KillSignal: 送るシグナル
• TimeoutStopSec: 猶予期間
• KillMode: 対象範囲（control-group, process, mixed, none）

危険なパターンと注意点

1. pkill -9 python の乱用

# ❌ Python プロセス全部を強制終了
pkill -9 python
# システム上のすべての Python プロセス（他人のも！）を殺す

→ 対処:

# ✅ 事前確認
pgrep -fl python

# ✅ ユーザー限定
pkill -u $USER python

# ✅ フルパス指定
pkill -f "/opt/myapp/venv/bin/python"

2. killall の広範囲マッチ

# nginx を止めたつもりが…
killall nginx
# 実は nginx-worker, nginx-master 等が別プロセス名なら残る

# 確認
pgrep -fl nginx

3. kill -9 の常用

# ❌ いきなり
kill -9 12345
# データ破損リスク

# ✅ 段階的
kill 12345
sleep 5
kill -9 12345   # まだ生きてれば

4. root プロセスへの誤操作

# 誤って PID 1（systemd/init）へ
kill 1
# 効かないが、一部の派生プロセスに影響

5. Uninterruptible sleep（D state）

ps aux | awk '$8 == "D" {print}'
# → プロセスがカーネル I/O 待ち

D state のプロセスは SIGKILL でも殺せない。I/O 完了を待つか、システム再起動が必要。

原因例:

• 応答しない NFS マウント
• 故障ディスクへのアクセス
• ハングした USB デバイス

6. ゾンビプロセス（Z state）

ps aux | awk '$8 == "Z" {print}'

ゾンビは既に終了しているが親が回収していない状態。kill しても消えない。親プロセスを終了 or システム再起動で解消。

実践シナリオ

シナリオ1：暴走 Node.js プロセス

# 確認
pgrep -fl node
# 12345 node /opt/app/server.js
# 12346 node --inspect debug.js

# 特定プロセスだけ終了
kill 12345

# または全 node（自分の分だけ）
pkill -u $USER node

シナリオ2：Nginx 設定リロード

# 設定ファイルを編集後
sudo nginx -t   # 構文チェック
sudo nginx -s reload   # または
sudo kill -HUP $(cat /var/run/nginx.pid)
# または
sudo systemctl reload nginx

シナリオ3：開発サーバー一括停止

# Rails, Sidekiq, Webpack を全部停止
pkill -f "rails server"
pkill -f "sidekiq"
pkill -f "webpack-dev-server"

シナリオ4：特定ポートを使うプロセス

# ポート3000を使うプロセス発見・終了
lsof -ti :3000 | xargs kill

# もしくは
fuser -k 3000/tcp

詳細はAddress already in use の記事も参照。

シナリオ5：バックグラウンドジョブ

# 起動
./long_task.sh &
[1] 12345

# 停止（ジョブ番号）
kill %1

# 停止（PID）
kill 12345

# 停止（パターン）
pkill -f "long_task.sh"

詳細はLinuxでプロセスをバックグラウンド実行する方法の記事も参照。

シナリオ6：SSH 経由でリモート停止

ssh user@server "pkill -f 'my_app'"

# 確認付き
ssh user@server "pgrep -fl my_app"
ssh user@server "pkill -f my_app"

詳細はSSH host key verification failed の記事も参照。

シナリオ7：Solid Queue ワーカーの停止（Rails）

# graceful
kill -TERM $(cat tmp/pids/solid_queue.pid)

# または systemd で管理
sudo systemctl stop solid_queue

詳細はSolid Queue 使い方の記事も参照。

シナリオ8：メモリリークプロセスの発見と終了

# メモリ使用トップ
ps aux --sort=-%mem | head

# 該当PIDを終了
kill -TERM 12345
sleep 10
kill -0 12345 && kill -KILL 12345

ベストプラクティス

1. まず SIGTERM

# ✅
kill 12345
sleep 5
kill -9 12345   # 残ってれば

# ❌
kill -9 12345   # いきなり

2. pgrep で確認してから pkill

pgrep -fl python
# 意図通り確認
pkill -f "specific_script.py"

3. ユーザー限定

# ✅ 自分のプロセスだけ
pkill -u $USER python

4. -f で厳密に指定

# ❌ 全 python
pkill python

# ✅ 特定スクリプト
pkill -f "/opt/myapp/bin/worker.py"

5. systemctl 使えるなら優先

# ✅ サービス管理
sudo systemctl stop myapp
sudo systemctl reload nginx

# vs
sudo kill -HUP $(pidof nginx)

6. スクリプトで trap

#!/bin/bash
cleanup() {
  echo "Cleanup..."
  kill $child_pid
  exit
}
trap cleanup TERM INT

./long_task.sh &
child_pid=$!
wait

7. Docker では docker stop

# ✅
docker stop container

# ❌
docker kill container   # 最終手段

8. ログを残す

pkill -e -f python >> kill.log
# 何を終了したかログ

よくある質問（FAQ）

Q1. kill -9 が効かないプロセスがある

Uninterruptible sleep（D state） の可能性。カーネルの I/O 待ち。

ps aux | grep "D" | grep " D "

対処:

• I/O 対象（NFS等）の解消
• システム再起動

Q2. pkill と killall どっちを使う？

私は個人的に pkill -f がメイン。柔軟性最高。

Q3. どのシグナルを送ったか確認

strace -e trace=signal -p 12345
# プロセスが受け取ったシグナルをトレース

または dmesg / システムログ。

Q4. 自分のプロセスだけを対象にする

pkill -u $USER python
killall -u $USER python

Q5. 起動中のプロセス全部を kill

# 全ユーザープロセス（危険）
kill -TERM -1

# 自分だけ
kill -TERM -$(id -u)

⚠️ セッション終了・自分のシェルも殺す可能性。慎重に。

Q6. Ctrl+C と SIGINT の関係

Ctrl+C = SIGINT（2）を前面プロセスに送る。プログラムでハンドリング可能:

try:
    while True:
        time.sleep(1)
except KeyboardInterrupt:
    print("Ctrl+C received")

Q7. Ctrl+Z と SIGSTOP の関係

Ctrl+Z = SIGTSTP（20）でプロセス一時停止。bg / fg で復帰。

詳細はLinuxでプロセスをバックグラウンド実行する方法の記事も参照。

Q8. プロセスグループとは

シェルが起動する子プロセスは同じプロセスグループに属する。

kill -TERM -12345
# PGID 12345 の全プロセスに送信

| パイプで繋いだプロセスも同一グループ。

Q9. Docker container の PID 1

Docker container の PID 1 は特殊:

• SIGTERM を明示的にハンドリングしないと無視される
• 適切なアプリを PID 1 にする、または tini 等を使う

Q10. macOS での違い

macOS（BSD 系）は Linux（GNU）と一部違い:

• pkill -f の挙動は同じ
• killall は Linux と互換
• 一部シグナル番号が異なる

Q11. Windows Subsystem for Linux

WSL2 内でも Linux と同様に動作。ただし PID は Windows の PID と別体系。

Q12. Kubernetes での graceful shutdown

spec:
  terminationGracePeriodSeconds: 30

Pod に SIGTERM → 30秒後 SIGKILL。アプリは SIGTERM を適切にハンドリング。

参考リンク・関連資料

公式

• kill(1) – Linux manual page – kill 公式
• pkill(1) – Linux manual page – pkill 公式
• killall(1) – Linux manual page – killall 公式
• signal(7) – Linux manual page – シグナル全般

関連記事（本サイト）

• Linuxでプロセスをバックグラウンド実行する方法 – nohup/&/disown
• Address already in use – ポート占有プロセス終了
• docker daemon 接続エラー – Docker系
• SSH host key verification failed – リモート操作
• Linux find オプション一覧 – ファイル検索
• Linux grep オプション一覧 – プロセス検索
• Linux awk 使い方 – データ加工
• crontab 書き方 例 – 定期実行
• Linuxでファイル差分を確認する方法 – diff/colordiff/vimdiff
• Linuxでシンボリックリンクを作成・確認・削除する方法 – ファイル管理
• Solid Queue 使い方 – Rails ジョブ管理
• rake task 作り方 – Rails のバッチ処理

まとめ

Linux のプロセス終了3大コマンド、要点を再整理します。

使い分け早見表

シグナル早見表

黄金ルール

# 1. まず SIGTERM
kill 12345
sleep 5

# 2. 効かなければ SIGKILL
kill -0 12345 && kill -9 12345

事故防止

• pgrep で確認してから pkill/killall
• -u でユーザー限定
• -f で厳密に指定
• -i で確認プロンプト（killall）
• kill -0 で生存確認

主要コマンド

# 検索
pgrep -fl PATTERN         # 詳細確認
ps aux | grep [P]ATTERN   # ps 経由

# 終了
kill PID                  # PID指定
pkill -f "PATTERN"        # パターン
killall NAME              # 名前完全一致

# 強制
kill -9 PID
pkill -9 -f "PATTERN"
killall -9 NAME

# 設定リロード
kill -HUP $(pidof nginx)
systemctl reload nginx    # 推奨

これらの知識は、Linux サーバー運用・トラブルシューティング・デプロイ・バッチ処理管理など、あらゆる場面で活用できます。本記事をブックマークしておけば、プロセス管理の作業を安全かつ効率的に進められるようになります。

本記事は2026年6月時点の情報をもとに、GNU procps 4.x、util-linux 2.x、Linux Kernel 6.x での動作確認・公式ドキュメントに基づき作成しています。ディストリビューションやバージョンによって挙動が異なる場合があるため、最新の情報は man ページ（man kill、man pkill、man killall、man 7 signal）もあわせてご確認ください。