2026年6月3日

Apacheのグレースフルリスタートとは何か（restart・reloadとの違いと使い分け）

Webサーバー・Apache

Apacheのグレースフルリスタート（graceful restart）は、処理中のリクエストを途中で切らずに、設定ファイルを読み直して新しい設定に切り替える再起動の方法です。apachectl -k graceful、または多くの環境では systemctl reload で実行でき、サイトを止めずに設定変更や証明書の更新を反映できます。この記事では、通常のrestartとの違い、実行前に確認すること、gracefulでは反映されない設定、反映に時間がかかるときの見方を説明します。

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

Apacheは、設定を読み込んで待ち受けを管理する親プロセスと、実際にリクエストを処理する子プロセス（MPMによってはスレッド）で動いています。グレースフルリスタートを指示すると、次の順で処理が進みます。

親プロセスが設定ファイルを読み直し、ログファイルを開き直します。
子プロセスには「今のリクエストが終わったら終了する」ように伝えます。何も処理していない子プロセスはすぐに終了します。
親プロセスは新しい設定で子プロセスを起動し、新しいリクエストはそちらが受け付けます。

待ち受けているポートは閉じられないため、切り替えの間も新しい接続は受け付けられます。処理中のリクエストは古い設定のまま最後まで処理されるので、大きなファイルのダウンロードやWordPressの時間のかかる処理が途中で切れることもありません。

restart・stopとの違い

Apacheの停止と再起動には、いくつかの種類があります。apachectl -k に渡す引数と、親プロセスに送られるシグナルの対応は次のとおりです。

コマンド	シグナル	処理中のリクエスト
`apachectl -k graceful`	USR1	最後まで処理してから切り替え
`apachectl -k restart`	HUP	子プロセスをすぐに終了させる
`apachectl -k graceful-stop`	WINCH	最後まで処理してから停止
`apachectl -k stop`	TERM	すぐに停止

restart は子プロセスをすぐに終了させるため、その瞬間に処理していたリクエストはエラーになります。graceful-stop で停止を待つ時間の上限は GracefulShutdownTimeout で設定でき、既定の0は「処理が終わるまで待ち続ける」という意味です。

systemctlでの実行

systemdで管理されている環境では、普段は systemctl で操作します。

# Ubuntu
sudo systemctl reload apache2

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

UbuntuやRHEL系の標準のパッケージでは、reload がグレースフルリスタートに対応づけられています。一方、systemctl restart は停止してから起動するため、短時間ですがサイトが応答しなくなります。手元の環境で reload が何を実行するかは、次のコマンドの ExecReload の行で確認できます。

systemctl cat apache2   # RHEL系は httpd

パッケージの更新によって内容が変わる可能性もあるので、運用手順書にはこの確認方法も書いておくと安心です（2026年10月現在）。

実行前に設定の文法を確認する

グレースフルリスタートで気をつけたいのは、設定ファイルに誤りがあると、親プロセスが新しい設定を読み込めずに終了してしまう場合があることです。そうなるとサイトが止まります。設定を変えたら、反映の前に文法を確認します。

sudo apachectl configtest && sudo systemctl reload apache2

&& でつなぐと、Syntax OK が出たときだけ再読み込みが実行されます。ただし、文法チェックが通っても、証明書ファイルのパスの誤りなど、実際に読み込むまで分からない問題もあります。反映後はエラーログを確認し、サイトにアクセスして表示を確かめてください。

sudo tail -n 50 /var/log/apache2/error.log   # RHEL系は /var/log/httpd/error_log

グレースフルリスタートで反映されるもの・されないもの

バーチャルホストの追加、書き換えルール、セキュリティヘッダー、SSL証明書の差し替えなど、普段の設定変更の多くはグレースフルリスタートで反映されます。Let's Encryptの証明書を更新した後に、更新ツールのフックで systemctl reload を実行するのはこのためです。

一方、次のような変更は再読み込みだけでは反映されません。

ServerLimit・ThreadLimit: 子プロセスやスレッドの数の上限を決める値で、再起動の際に変更しても無視されます。MaxRequestWorkers は再起動で変更できますが、ServerLimit が決める範囲を超えることはできません。上限そのものを変えたいときは、停止してから起動します。
MPMの切り替え: preforkからeventへの変更などは、停止してから起動する手順で行います。
PHP-FPMの設定: PHP-FPMを使っている場合、PHPは別のサービスとして動いているため、Apacheを再読み込みしても php.ini やプールの設定は反映されません。systemctl reload php8.3-fpm のように、PHP-FPM側を再読み込みします（サービス名はPHPのバージョンやディストリビューションによって異なります）。

なお、.htaccess は毎回のリクエストで読み込まれるため、変更してもApacheの再起動は不要です。WordPressのパーマリンク設定を保存したときに書き換わるのも .htaccess なので、それだけでApacheを再起動する必要はありません。

切り替えに時間がかかるとき

グレースフルリスタートでは、古い子プロセスは処理中のリクエストが終わるまで残ります。通常は数秒で入れ替わりますが、次のような接続があると古いプロセスが長く残ります。

大きなファイルのダウンロードやアップロード
WebSocketなど、長時間つながったままの接続
応答に時間のかかるPHPの処理

mod_status を有効にしている場合、ステータスページのスコアボードで G と表示されているのが、終了待ちの古いプロセス（Gracefully finishing）です。

eventのMPMでは、古いプロセスが残っている間も新しいプロセスが起動するため、短い間隔で何度も再読み込みを繰り返すと、プロセスの枠が足りなくなることがあります。エラーログに scoreboard is full という記録が出るのはこの状態です。設定変更の反映はまとめて行い、連続した再読み込みを避けるのが基本です。長時間の接続が多いサイトでは、ServerLimit に余裕を持たせておくことも検討します。

ログローテーションとの関係

グレースフルリスタートでは、親プロセスがログファイルを開き直します。logrotateでApacheのログを回すときに、ローテーション後に reload を実行するのは、Apacheに新しいログファイルへ書き込ませるためです。ただし、終了待ちの古い子プロセスはしばらく古いファイルに書き込むことがあるため、ローテーション直後のファイルをすぐに圧縮しない設定（delaycompress）がよく使われます。

WordPressサイトでの使い分け

WordPressを動かしているサーバーでは、次のように使い分けると安全です。

設定変更・証明書の更新: configtest の後に reload（グレースフルリスタート）。
モジュールの追加・削除: 多くは reload で反映されますが、PHPの組み込みモジュール（mod_php）を外すなど構成を大きく変えるときは、メンテナンスの時間帯に restart を使い、エラーログを確認します。
Apacheのパッケージ更新: パッケージによっては更新時に自動で再起動されます。更新後に apachectl -v でバージョンを、エラーログで起動時の警告を確認します。

本番サーバーの設定を変える前には、元の設定ファイルを複製しておくと、問題が起きたときにすぐ戻せます。

sudo cp -a /etc/apache2 /root/apache2-backup-$(date +%Y%m%d)

まとめ

グレースフルリスタートは、処理中のリクエストを切らずに設定を読み直す再起動で、apachectl -k graceful や多くの環境の systemctl reload で実行できます。
restart は子プロセスをすぐに終了させるため、処理中のリクエストがエラーになります。
設定の誤りがあると停止する場合があるので、configtest を通してから再読み込みします。
ServerLimit の変更やMPMの切り替え、PHP-FPMの設定はグレースフルリスタートでは反映されません。
古いプロセスが長く残る場合は、長時間の接続がないかを mod_status のスコアボードで確認します。