稼働中のサービスを停止せずに設定変更を即時反映させる実務手順

まず結論：接続を維持したまま設定を反映させるコマンド

systemdで管理されているサービスであれば、systemctl reloadが最短かつ安全です。NginxやApacheなら以下のコマンドで、既存の接続を維持したまま設定ファイルを再読み込みできます。

# systemdで管理されているサービスの設定再読み込み
sudo systemctl reload nginx
sudo systemctl reload apache2   # Debian/Ubuntu系
sudo systemctl reload httpd     # RHEL/Rocky/AlmaLinux系

# reloadに対応しているか事前に確認する
systemctl show nginx --property=ExecReload

reloadはサービスプロセスを終了させず、ExecReload=で定義された処理（多くの場合SIGHUPの送信）を実行します。restart（停止→起動）とは根本的に異なり、セッションが維持されます。ExecReload=が定義されていないサービスではreloadがエラーになるため、事前確認が必要です。

systemdを介さずに直接プロセスへシグナルを送る必要がある場面——コンテナ内での制御やsystemd管理外のプロセスなど——では、PIDを特定してからkillコマンドを使います。

対象プロセスのPIDを正確に特定する

シグナルを送る前に、マスタープロセスのPIDを確認します。ps auxで全プロセスを一覧できますが、対象を絞るにはpgrepやsystemctl showが便利です。

# プロセス名でPIDと実行コマンドを表示
pgrep -a nginx

# systemdが把握しているメインPIDを取得（最も確実）
systemctl show nginx --property=MainPID

# rootが所有するApacheのマスタープロセスだけ絞り込む
ps aux | awk '$1=="root" && /httpd/ {print}'

NginxやApacheはマルチプロセス構成のため、ps auxで見るとワーカーも含め複数行が表示されます。シグナルを送る対象はマスタープロセス（通常rootが所有する親PID）だけで十分です。ワーカー全体に誤って送ると予期しない動作につながります。

systemdが管理するサービスであればsystemctl show --property=MainPIDで取得したPIDが最も確実です。プロセスが再起動されても自動的に更新されています。

シグナルを直接送ってプロセスを制御する

PIDが確定したらkillコマンドでシグナルを送ります。プロセス名で絞り込める場合はpkillを使うと1コマンドで済みます。シグナル送信後はjournalctlでログを確認し、設定が正しく反映されたかを検証します。

# PIDを指定してSIGHUP（設定再読み込み）を送る
sudo kill -HUP 1234

# systemdからPIDを取得してシグナル送信（変数展開で安全に）
MPID=$(systemctl show nginx --property=MainPID | cut -d= -f2)
sudo kill -HUP "$MPID"

# プロセス名で絞ってSIGHUPを送る
sudo pkill -HUP nginx

# シグナル送信後にログで反映を確認
sudo journalctl -u nginx -n 30 --no-pager

SIGHUPを送ると、プロセスは設定ファイルを再読み込みして動作を継続するのが慣例ですが、SIGHUPの扱いはアプリケーションの実装次第です。systemdのExecReload=行や公式ドキュメントで動作を確認してから使いましょう。また、設定ファイルを変更する前に構文チェックを行うと、設定ミスによるサービスダウンを防げます。

# シグナルを送る前に設定ファイルの構文チェック
sudo nginx -t
sudo apachectl configtest

主要シグナルの使い分け早見表

現場でよく使うシグナルの一覧です。番号とシンボル名はどちらもkillコマンドで使えます（kill -15 <PID> と kill -TERM <PID> は同義）。番号はLinux（x86_64）での値で、kill -lで確認できます。

番号  シンボル名   主な用途
1     SIGHUP      設定ファイルの再読み込み・デーモンの再初期化
2     SIGINT      Ctrl+C と同等。フォアグラウンドプロセスの割り込み終了
15    SIGTERM     正常終了要求（後処理をしてから終了。kill のデフォルト）
9     SIGKILL     強制終了。プロセスがキャッチできない。最終手段
19    SIGSTOP     一時停止（プロセスは止まるが終了しない）
18    SIGCONT     SIGSTOP後の再開

通常のサービス停止にはSIGTERM（番号15）を使います。引数なしのkill <PID>はデフォルトでSIGTERMを送ります。それでも止まらない場合に限り、SIGKILL（番号9）を検討します。

現場でよくある失敗と注意点

SIGKILL（kill -9）を最初に使わない。ある運用現場では、プロセスが応答しなくなった際にすぐkill -9を使ったところ、DBへの書き込み処理の途中でプロセスが消え、データ破損のインシデントになりました。まずSIGTERMを送り、10〜30秒待ってから反応がなければSIGKILLを検討するのが鉄則です。

pkillは名前の部分一致に注意する。pkill pythonは「python3.12」も「python-wrapper.sh」も対象にします。実行前にpgrep -a <名前>で対象プロセスを必ず確認してください。

systemd管理サービスにはsystemctl経由が原則。直接killでプロセスを終了させると、systemdがプロセスの消失を検知し、Restartポリシーに従って即座に再起動することがあります。意図した停止や設定変更はsystemctl stop/systemctl reloadを使うべきです。

設定変更の反映確認までの実務フロー

本番環境での設定変更は、以下の順序で行うと安全です。

# 1. 設定ファイルの構文チェック（先に必ず実施）
sudo nginx -t

# 2. systemd管理サービスはreloadが最速・安全
sudo systemctl reload nginx

# 3. systemd管理外のプロセスはPID確認→シグナル送信
MPID=$(systemctl show nginx --property=MainPID | cut -d= -f2)
sudo kill -HUP "$MPID"

# 4. ログで正常反映を確認
sudo journalctl -u nginx -n 50 --no-pager

# 5. サービスの死活確認
systemctl is-active nginx

構文エラーのある設定ファイルにSIGHUPを送ると、サービスが停止したまま起動できなくなるケースがあります。本番投入前の構文チェックは省略せず、必ず実施してください。