Apache HTTP サーバ バージョン 2.2
この文書では Unix に類似したシステムでの Apache の停止と再起動について扱っています。 Windows NT, 2000, XP ユーザはサービスとして Apache を実行するで、Windows 9x, MEユーザはコンソールアプリケーションとして Apache を実行するで、 これらのプラットホームでの使用方法をご覧下さい。
Apache を停止したり再起動したりするためには、実行されている
httpd
プロセスにシグナルを送る必要があります。
シグナルを送るには二つの方法があります。
一つ目はプロセスに直接シグナルを送る unix の kill
コマンドを使用する方法です。
システムを見ればたくさんの httpd
が
実行されているのに気が付くでしょうが、シグナルを送るのは
親プロセスだけで、それ以外の個々のプロセスには
シグナルを送らないで下さい。その親プロセスの pid は
PidFile
に書かれています。これはつまり、親以外のプロセスに
シグナルを送る必要すらない、ということです。
親プロセスに送ることができる 3 種類のシグナルがあります:
TERM
,
HUP
,
USR1
です。これらの説明については続きをご覧下さい。
親プロセスにシグナルを送るには、 次のようなコマンドを発行して下さい:
kill -TERM `cat /usr/local/apache2/logs/httpd.pid`
httpd
プロセスにシグナルを送る 2 番目の方法は
-k
というコマンドライン引数を使用することです。
下で説明されているように、stop
, restart
,
graceful
, graceful-stop
を指定できます。
これらは httpd
の引数ですが、
制御用のスクリプト apachectl
はそれらの引数をそのまま
httpd
に渡します。
httpd
にシグナルを送った後、
実行状況を次のコマンドで読むことができます:
tail -f /usr/local/apache2/logs/error_log
ここに挙げた例は、各自の
ServerRoot
と
PidFile
の設定に適合するように適宜修正して下さい。
apachectl -k stop
TERM
あるいは stop
シグナルを親プロセスに送ると、即座に子プロセス全てを kill しようとします。
子プロセスを完全に kill し終わるまでに数秒かかるかもしれません。
その後、親プロセス自身が終了します。
処理中のリクエストは全て停止され、もはやリクエストに対する
応答はされません。
apachectl -k graceful
親プロセスは USR1
あるいは graceful
シグナルを受け取ると、子プロセスに現在のリクエストの処理の後に終了する
(あるいは何もしていなければすぐに終了する)
ように助言します。
親プロセスは設定ファイルを再読込して、ログファイルを開き直します。
子プロセスが徐々になくなるに従って、
新しい世代の設定による子プロセスに置き換えていきます。
そして、これらが新たなリクエストに即座に応答し始めます。
このコードは常に
MPM のプロセス制御ディレクティブの設定を重視しますので、
クライアントのリクエストを扱うプロセスとスレッドの数を再起動の処理中も
適切な値に維持されます。。また、次のようにして
StartServers
を守ります:
少なくとも 1 秒後に StartServers
個の新しい子プロセスが
生成されていなければ、その数になるように適宜プロセスを生成します。
この挙動は現在の負荷に対して適切な子プロセスの数と
StartServers
パラメータでの
希望の数の両方を維持しようとしています。
mod_status
を
使用している場合は、USR1
シグナルが送られた際に
サーバ統計がゼロに設定されないことに
注意してください。
サーバが新しいリクエストに応答不能な時間を最小にするように
(リクエストは OS によってキューに追加されるので絶対に紛失はしません)、
また同時に、希望のチューニングパラメータを守るように
コードは書かれています。
このようにするために、世代をまたがった全子プロセスの追跡に使われている
スコアボードを維持しなければなりません。
status モジュールは、緩やかな再起動以前から開始して
リクエストに応答し続けている子プロセスを特定するために、
G
を使うこともします。
現在、USR1
を使うログ移動スクリプトでは、
再起動前の子プロセスがログを書き終わったことを確証する方法が
ありません。古いログに対して何かする前に、
USR1
シグナルを送った後いくらか適当な時間待つことを
提案します。例えば、帯域の狭い通信路のユーザのリクエストのほとんどが 10
分以下で完了しているということが分かっていれば、
古いログに何かする前に 15 分待つということです。
-t
コマンドライン引数
(httpd
をご覧下さい)
を使って検証することができます。
設定ファイルの意味的な内容を構文と同様に検証したい場合は、
非 root ユーザで httpd
を起動しようとすればわかります。
もしエラーがなければ、ソケットやログを開こうとして
root でないため
(もしくは実行中の httpd
が既に必要なポートにバインドしているため)
に失敗するでしょう。
これ以外の理由で起動に失敗したのであれば、
それは設定ファイルのエラーで、
緩やかな再起動を行う前にその誤りを修正しなければなりません。apachectl -k restart
HUP
あるいは restart
シグナルを親プロセスに送ると、
TERM
と同様に子プロセスを kill しますが、
親プロセスは終了しません。
設定ファイルを再読込して、ログファイル全てを開き直します。
その後、新しい子プロセスを起動して応答を続けます。
mod_status
を使っている場合は、HUP
が送られた場合に
サーバ統計がゼロに設定されることに注意してください。
apachectl -k graceful-stop
親プロセスは WINCH
あるいは graceful-stop
シグナルを受け取ると、子プロセスに現在のリクエストの処理の後に終了する
(あるいは何もしていなければすぐに終了する)
ように助言します。
その後に親プロセスは PidFile
を削除し、全ポートからの Listen をやめます。
親プロセスはこのまま継続し、子プロセスがリクエストを処理する
のを監視しています。子プロセスが全て処理を終えて終了するか、GracefulShutdownTimeout
で指定されたタイムアウトに達した後で、親プロセスも終了します。
タイムアウトに達した場合は、残りの子プロセスには TERM
シグナルが送信され、強制終了されます。
TERM
シグナルによって、"graceful" 状態にある親プロセスと
子プロセスの全てが直ちに終了します。ただし、
PidFile
は既に削除
されてしまっていますので、apachectl
や httpd
でこれらにシグナルを送ることはできません。
graceful-stop
シグナルを使うと、まったく同一の設定
ファイルを使った httpd
を同時に複数起動することが
できるようになります。
この機能を使うと、Apache をアップグレードする際にとても便利でしょう。
ただし、設定によってはデッドロックや競合状態 (レースコンディション)
を引き起こすかもしれません。
Lockfile
や ScriptSock
などでのディスク上のファイルについては、
ファイルにサーバの PID が含まれるようになっていて、httpd が複数同時に動作していても
問題がおきないように注意が払われています。
しかし、設定ディレクティブやサードパーティ製モジュール、CGI で使用される永続的な
ディスクを使ったロックや状態ファイルを活用している場合についても、
複数の httpd
が動作している状態であっても、それぞれで
ファイルを上書きしないように注意しなければなりません。
潜在的な競合状態についても心配する必要があるでしょう。
たとえば rotatelogs
形式のパイプによるログなどが該当します。
複数の rotatelogs
インスタンスが同時に同じログファイルを
rotate しようとすると、ログファイルが破壊されるかもしれません。