<-
Apache > HTTP サーバ > ドキュメンテーション > バージョン 2.2

停止と再起動

Available Languages:  de  |  en  |  es  |  fr  |  ja  |  ko  |  tr 

This translation may be out of date. Check the English version for recent changes.

この文書では Unix に類似したシステムでの Apache の停止と再起動について扱っています。 Windows NT, 2000, XP ユーザはサービスとして Apache を実行するで、Windows 9x, MEユーザはコンソールアプリケーションとして Apache を実行するで、 これらのプラットホームでの使用方法をご覧下さい。

参照

top

イントロダクション

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 の引数ですが、 制御用のスクリプト apache2ctl はそれらの引数をそのまま httpd に渡します。

httpd にシグナルを送った後、 実行状況を次のコマンドで読むことができます:

tail -f /usr/local/apache2/logs/error_log

ここに挙げた例は、各自の ServerRootPidFile の設定に適合するように適宜修正して下さい。

top

急な停止

シグナル: TERM
apache2ctl -k stop

TERM あるいは stop シグナルを親プロセスに送ると、即座に子プロセス全てを kill しようとします。 子プロセスを完全に kill し終わるまでに数秒かかるかもしれません。 その後、親プロセス自身が終了します。 処理中のリクエストは全て停止され、もはやリクエストに対する 応答はされません。

top

緩やかな再起動 (Graceful Restart)

シグナル: USR1
apache2ctl -k graceful

親プロセスは USR1 あるいは graceful シグナルを受け取ると、子プロセスに現在のリクエストの処理の後に終了する (あるいは何もしていなければすぐに終了する) ように助言します。 親プロセスは設定ファイルを再読込して、ログファイルを開き直します。 子プロセスが徐々になくなるに従って、 新しい世代の設定による子プロセスに置き換えていきます。 そして、これらが新たなリクエストに即座に応答し始めます。

このコードは常に MPM のプロセス制御ディレクティブの設定を重視しますので、 クライアントのリクエストを扱うプロセスとスレッドの数を再起動の処理中も 適切な値に維持されます。。また、次のようにして StartServers を守ります: 少なくとも 1 秒後に StartServers 個の新しい子プロセスが 生成されていなければ、その数になるように適宜プロセスを生成します。 この挙動は現在の負荷に対して適切な子プロセスの数と StartServers パラメータでの 希望の数の両方を維持しようとしています。

mod_status を 使用している場合は、USR1 シグナルが送られた際に サーバ統計がゼロに設定されないことに 注意してください。 サーバが新しいリクエストに応答不能な時間を最小にするように (リクエストは OS によってキューに追加されるので絶対に紛失はしません)、 また同時に、希望のチューニングパラメータを守るように コードは書かれています。 このようにするために、世代をまたがった全子プロセスの追跡に使われている スコアボードを維持しなければなりません。

status モジュールは、緩やかな再起動以前から開始して リクエストに応答し続けている子プロセスを特定するために、 G を使うこともします。

現在、USR1 を使うログ移動スクリプトでは、 再起動前の子プロセスがログを書き終わったことを確証する方法が ありません。古いログに対して何かする前に、 USR1 シグナルを送った後いくらか適当な時間待つことを 提案します。例えば、帯域の狭い通信路のユーザのリクエストのほとんどが 10 分以下で完了しているということが分かっていれば、 古いログに何かする前に 15 分待つということです。

再起動時に設定ファイルに誤りがあると、 親プロセスは再起動せずにエラーとともに終了します。 緩やかな再起動の場合は、親プロセスが終了した後でも子プロセスが 実行されたまま放置されたりもします。 (最後のリクエストを処理した後「緩やかに終了」する 子プロセスとなります。) サーバを再起動する際に、これが問題になるかもしれません -- サーバは listen するポートにバインドできないかもしれません。 再起動する前に、設定ファイルの構文を -t コマンドライン引数 (httpd をご覧下さい) を使って検証することができます。 設定ファイルの意味的な内容を構文と同様に検証したい場合は、 非 root ユーザで httpd を起動しようとすればわかります。 もしエラーがなければ、ソケットやログを開こうとして root でないため (もしくは実行中の httpd が既に必要なポートにバインドしているため) に失敗するでしょう。 これ以外の理由で起動に失敗したのであれば、 それは設定ファイルのエラーで、 緩やかな再起動を行う前にその誤りを修正しなければなりません。
top

急な再起動

シグナル: HUP
apache2ctl -k restart

HUP あるいは restart シグナルを親プロセスに送ると、 TERM と同様に子プロセスを kill しますが、 親プロセスは終了しません。 設定ファイルを再読込して、ログファイル全てを開き直します。 その後、新しい子プロセスを起動して応答を続けます。

mod_status を使っている場合は、HUP が送られた場合に サーバ統計がゼロに設定されることに注意してください。

再起動時に設定ファイルに誤りがあると、 親プロセスは再起動せずにエラーとともに終了します。 これを避けるには次の方法をご覧下さい。
top

緩やかな停止 (Graceful Stop)

Signal: WINCH
apache2ctl -k graceful-stop

親プロセスは WINCH あるいは graceful-stop シグナルを受け取ると、子プロセスに現在のリクエストの処理の後に終了する (あるいは何もしていなければすぐに終了する) ように助言します。 その後に親プロセスは PidFile を削除し、全ポートからの Listen をやめます。 親プロセスはこのまま継続し、子プロセスがリクエストを処理する のを監視しています。子プロセスが全て処理を終えて終了するか、GracefulShutdownTimeout で指定されたタイムアウトに達した後で、親プロセスも終了します。 タイムアウトに達した場合は、残りの子プロセスには TERM シグナルが送信され、強制終了されます。

TERM シグナルによって、"graceful" 状態にある親プロセスと 子プロセスの全てが直ちに終了します。ただし、 PidFile は既に削除 されてしまっていますので、apache2ctlhttpd でこれらにシグナルを送ることはできません。

graceful-stop シグナルを使うと、まったく同一の設定 ファイルを使った httpd を同時に複数起動することが できるようになります。 この機能を使うと、Apache をアップグレードする際にとても便利でしょう。 ただし、設定によってはデッドロックや競合状態 (レースコンディション) を引き起こすかもしれません。

LockfileScriptSock などでのディスク上のファイルについては、 ファイルにサーバの PID が含まれるようになっていて、httpd が複数同時に動作していても 問題がおきないように注意が払われています。 しかし、設定ディレクティブやサードパーティ製モジュール、CGI で使用される永続的な ディスクを使ったロックや状態ファイルを活用している場合についても、 複数の httpd が動作している状態であっても、それぞれで ファイルを上書きしないように注意しなければなりません。

潜在的な競合状態についても心配する必要があるでしょう。 たとえば rotatelogs 形式のパイプによるログなどが該当します。 複数の rotatelogs インスタンスが同時に同じログファイルを rotate しようとすると、ログファイルが破壊されるかもしれません。

Available Languages:  de  |  en  |  es  |  fr  |  ja  |  ko  |  tr