2026年5月28日

Apacheのグレースフルリスタートとは？restart・reloadとの違いと安全な使い方

Webサーバー・Apache

Apache のグレースフルリスタート（graceful restart）は、処理中のリクエストを途中で切らずに、設定ファイルを読み直して新しい設定へ切り替える再起動の方法です。通常の restart が子プロセスをすぐに止めるのに対し、graceful は「今の仕事を終えた子プロセスから順に入れ替える」ため、WordPress の投稿保存やアップロードの最中に接続が切れる事態を避けられます。この記事では、仕組み、コマンドの違い、使う前の確認、graceful では反映されない変更、実行後の確かめ方を説明します。

グレースフルリスタートの仕組み

Apache は、親プロセスが一つあり、その下で複数の子プロセス（MPM によってはスレッド）が実際のリクエストを処理しています。グレースフルリスタートを指示すると、次の順で処理が進みます。

親プロセスが設定ファイルを読み直し、ログファイルを開き直す。
親が子プロセスに「今のリクエストを終えたら終了するように」と伝える。待機中の子はすぐに終了する。
親は新しい設定で子プロセスを起動し、新しいリクエストはそちらが受け付ける。
古い子プロセスは処理中のリクエストを返し終えてから順次終了する。

待ち受けているポートは親が持ち続けるので、切り替えの間も新しい接続は受け付けられます。内部的には SIGUSR1 シグナルで指示が伝わります。

restart・graceful・stop の違い

似た名前のコマンドが多いので、違いを整理しておきます。

操作	コマンド例	処理中のリクエスト
グレースフルリスタート	`apachectl -k graceful`	終わるまで待つ
通常の再起動	`apachectl -k restart`	子プロセスをすぐ止めるため切れる
グレースフル停止	`apachectl -k graceful-stop`	終わるまで待ってから停止
停止	`apachectl -k stop`	すぐ止める

systemd で管理している環境では、systemctl reload がグレースフルリスタートに相当するのが一般的です。Debian / Ubuntu の apache2.service も RHEL 系の httpd.service も、reload の実体は graceful を呼ぶ形になっています。一方、systemctl restart はプロセスを止めてから起動し直すため、一瞬サービスが途切れます。ユニットファイルの中身は systemctl cat apache2（RHEL 系は httpd）で確認できます。

# Debian / Ubuntu
sudo systemctl reload apache2

# RHEL 系（AlmaLinux・Rocky Linux など）
sudo systemctl reload httpd

実行前に構文チェックをする

グレースフルリスタートは処理中の通信を守ってくれますが、設定ミスから守ってくれるわけではありません。新しい設定に構文エラーがあると、再読み込みに失敗し、環境によっては Apache が停止したままになることがあります。設定を変えたら、まず構文チェックを通してから実行します。

sudo apachectl configtest
# Syntax OK と表示されれば構文上の問題はない

apachectl graceful は実行前に構文チェックを行う作りになっていますが、systemd 経由や httpd -k graceful を直接使う場合の挙動は環境で差があります。どの方法で再起動するにしても、configtest を習慣にしておくのが安全です。

構文が正しくても、存在しない証明書ファイルのパスを指定した、読み込み権限が無いといった問題は、起動処理の段階で初めて分かることがあります。設定変更の前には該当ファイルのバックアップを取り、反映後すぐに動作を確認できる時間帯に作業します。

graceful が使われる典型的な場面

グレースフルリスタートは、意識せずに使われていることも多い操作です。

設定変更の反映：VirtualHost の追加やリダイレクト設定の変更など、日常的な変更の多くは graceful で反映できます。
証明書の更新：Let's Encrypt の証明書を更新したら、Apache に新しい証明書を読ませる必要があります。certbot の Apache プラグインは更新時に自動でリロードしますが、別の方法で取得している場合は --deploy-hook "systemctl reload apache2" のように更新後のリロードを指定します。
ログローテーション：logrotate でログを切り替えた後、Apache が新しいファイルに書き込むようにリロードします。ディストリビューション標準の設定では、この処理が postrotate に書かれていることが多いです。

graceful では反映されない変更

すべての変更がグレースフルリスタートで反映されるわけではありません。代表的なものを挙げます。

MPM の切り替え：prefork から event へ切り替えるといった変更は、完全な再起動（stop と start）が必要になる場合があります。
PHP-FPM 側の設定：WordPress を PHP-FPM で動かしている場合、php.ini やプールの設定（pm.max_children など）は PHP-FPM のプロセスが読んでいます。Apache をリロードしても変わらないので、PHP-FPM 側をリロードします。

# PHP-FPM のサービス名はバージョンやディストリビューションで異なる
systemctl list-units --type=service | grep fpm
sudo systemctl reload php8.3-fpm   # 表示された名前に置き換える

OPcache の opcache.validate_timestamps を無効にして高速化している環境では、テーマやプラグインのファイルを更新しても PHP が古いコードを使い続けます。この場合も、PHP-FPM のリロードでキャッシュを入れ替えるのが一般的です。PHP を mod_php で動かしている環境なら、PHP の設定は Apache のリロードで読み直されます。

長いリクエストがある環境での注意

古い子プロセスは処理中のリクエストが終わるまで残ります。大きなファイルのアップロード、時間のかかるインポート処理、WebSocket のような長時間の接続があると、古い子プロセスがなかなか終わらず、しばらく新旧のプロセスが並行して動きます。メモリに余裕の無いサーバーでは、この間にメモリ不足になる可能性があります。

mod_status を有効にしている場合、server-status のスコアボードで G（Gracefully finishing）と表示されているのが、終了待ちの古いプロセスです。この表示がいつまでも消えないときは、どのリクエストが長引いているかを確認します。graceful-stop で止めるときに待つ上限は、GracefulShutdownTimeout で秒数を指定できます。server-status は管理用の IP からだけ見られるよう制限しておいてください。

実行後の確認

リロードの後は、次の三点を確認します。

# サービスの状態と直近のログ
sudo systemctl status apache2 --no-pager

# エラーログの末尾（パスは環境に合わせる）
sudo tail -n 50 /var/log/apache2/error.log

# サイトが応答するか
curl -I https://example.com/

エラーログには、graceful の実行を示す行（「SIGUSR1 received. Doing graceful restart」のような内容）が残るのが一般的です。続けて警告やエラーが出ていないか、WordPress のトップページと管理画面が開けるかを確認すれば完了です。バージョンによってログの文言は異なる場合があります（2026年10月現在）。

本番で大きな設定変更を反映する前には、ステージング環境で同じ手順を通しておくと、反映されない変更や起動時のエラーに先に気付けます。

まとめ

グレースフルリスタートは、処理中のリクエストを終えてから子プロセスを入れ替える再起動で、apachectl -k graceful や systemctl reload で実行する。
restart は処理中の通信が切れる。日常の設定反映や証明書の更新は graceful を使う。
実行前に apachectl configtest で構文を確認する。graceful は設定ミスまでは防がない。
MPM の切り替えや PHP-FPM 側の設定は graceful では変わらない。長い接続がある環境では新旧プロセスの並行によるメモリ使用にも注意する。