プロセスを名前で指定して一括停止・シグナル送信する実務手順

プロセスを止めたいとき、まず ps aux | grep nginx でPIDを調べ、kill 1234 に渡す——という手順は確実ですが、同名のプロセスが複数起動している場合は面倒です。killall コマンドを使えばプロセス名を直接指定してシグナルを送れるため、手順をひとつに縮められます。この記事では基本操作から、シグナル種別の実務的な使い分け、systemctl との役割分担、そして見落としがちな注意点まで解説します。

まず動かす：プロセス名でシグナルを送る基本形

killall は psmisc パッケージに含まれています。主要ディストリビューションでは以下でインストールできます。

# AlmaLinux / Rocky Linux / RHEL 8以降
sudo dnf install psmisc

# Ubuntu / Debian
sudo apt install psmisc

基本的な使い方はプロセス名を引数に渡すだけです。デフォルトで SIGTERM（15番） を送り、プロセスに正常終了を促します。

# nginx の全プロセスに SIGTERM を送る
sudo killall nginx

# 一般ユーザーが自分のプロセスを止める場合（sudo 不要）
killall my_batch.sh

root で実行すると、すべてのユーザーが起動した同名プロセスが対象になります。自分のプロセスだけを操作したい場合は -u でユーザーを絞り込めます。

# 自分が起動した python3 プロセスだけを対象にする
killall -u "$(whoami)" python3

シグナルの種類と状況別の使い分け

送るシグナルを変えることで「正常終了」「設定再読み込み」「強制終了」を使い分けられます。対応シグナルの一覧は killall -l で確認できます。実務でよく使うのは次の3種類です。

• SIGTERM（-TERM / -15）：デフォルト。プロセスに「終了してください」と伝え、ログのフラッシュやソケットのクローズといった後処理をさせてから終了させます。
• SIGHUP（-HUP / -1）：設定ファイルの再読み込みに使います。rsyslogd、nginx、sshd などは HUP を受け取ると再起動せずに設定を反映します。
• SIGKILL（-KILL / -9）：カーネルが直接プロセスを終了させるため、プロセス側は何もできません。後処理なしで即時終了するため最終手段です。

# nginx の設定を再読み込みする（プロセスは落とさない）
sudo killall -HUP nginx

# SIGTERM で応答しないプロセスを強制終了する（最終手段）
sudo killall -KILL zombie_worker

# 停止前に確認プロンプトを出す（-i で誤操作を防ぐ）
sudo killall -i nginx

ある運用現場では、デプロイスクリプトの中で killall -HUP rsyslogd を使い、rsyslog の設定変更をサービス無停止で反映させる手順が定着していました。SIGTERM を使わないことで、ログの取りこぼしを防いでいます。

systemd 管理サービスとの役割分担

現代の Linux では、nginx や sshd などのサービスは systemd が管理しています。systemd 管理下のサービスに対して killall を使うと、プロセスは落ちてもすぐに Restart=on-failure 設定で再起動されることがあります。また、systemctl 側がプロセスの終了を把握できず、サービス状態が failed のまま残る場合もあります。

# systemd 管理サービスは systemctl を使う（推奨）
sudo systemctl stop nginx
sudo systemctl reload nginx     # 設定再読み込み（HUP 相当）
sudo systemctl restart nginx    # 再起動

# サービスが管理されているか確認する
systemctl is-active nginx

killall が真に力を発揮するのは、systemd に登録されていないプロセス——自作スクリプト、一時的に起動したバッチ処理、デバッグ用プロセスなど——を扱うときです。

ハマりやすい注意点

実務で見かける落とし穴を先にまとめておきます。

• プロセス名の長さ制限： Linux のプロセス名は内部的に15文字で切り捨てられる場合があります。my_long_process_name のような長い名前は、killall -e（完全一致）と組み合わせて確認しながら使うと安全です。
• BSD 版 killall との動作差異： macOS や FreeBSD の killall は引数なしで実行するとシステム上の全プロセスを終了させます。Linux（psmisc 版）とは動作が大きく異なるため、スクリプトを別 OS に持ち込む際は要注意です。
• パスが含まれるプロセスへの対応： /usr/bin/python3 のようにフルパスでマッチさせたい場合、killall はバイナリ名部分（python3）でしかマッチできません。コマンドライン全体を検索したい場合は後述の pkill -f を使います。
• SIGKILL は最終手段： -9 で強制終了したプロセスはテンポラリファイルやロックファイルを残すことがあります。次回起動時に「ロックファイルが残っている」エラーが出た場合は、手動でクリーンアップが必要です。

pkill との使い分け

pkill（procps パッケージ）は killall に近い機能を持ちますが、正規表現によるパターンマッチングと -f オプションによるコマンドライン全体の検索が使える点で異なります。

# "worker" を含む名前のプロセスをまとめて停止する
pkill -TERM worker

# コマンドライン全体にマッチさせる（スクリプト名や引数を含めて検索）
pkill -f "python3 /opt/batch/run.py"

# 停止する前に対象プロセスを確認する（pgrep で事前チェック）
pgrep -la worker

「プロセス名が短く一意に定まる」場面では killall、「複数の似た名前が混在する」「引数まで含めて絞り込みたい」場面では pkill -f が適しています。どちらも実行前に pgrep -la <パターン> で対象を確認する習慣をつけると、誤操作によるサービス断を防げます。

操作前の確認を習慣にする

本番環境でシグナルを送る前に、対象プロセスを必ず目視確認します。

# killall を実行する前に対象プロセスを確認する
ps aux | grep nginx

# -i オプションで対話的に確認しながら実行する
sudo killall -i nginx

# pgrep で PID と名前を一覧表示してから判断する
pgrep -la nginx

systemd 管理サービスには systemctl、非管理プロセスや複数の同名プロセスには killall——この役割分担を意識するだけで、シグナル送信の操作ミスと予期しない自動再起動の両方を防げます。