[APACHE DOCUMENTATION]

Apache HTTP Server Version 1.3

Apache の停止と再起動

このドキュメントは Unix での Apache の停止と再起動について記述したものです。Windows ユーザは 走っている Apache へのシグナル送信を見てください。

システムでたくさんの実行可能な httpd が走っていることに気が付くと思いますが、PidFile にある pid を持つ親プロセス以外の httpd にシグナルを送信すべきではありません。つまり、親以外のプロセスにシグナルを送信する必要はないということです。親プロセスに送信することができるシグナルは 3 つあります:TERMHUPUSR1 です。

親プロセスにシグナルを送信するためには、次のようなコマンドを入力してください:

    kill -TERM `cat /usr/local/apache/logs/httpd.pid`
入力の結果を読むことができます:
    tail -f /usr/local/apache/logs/error_log
これらの例を、あなたの ServerRootPidFile に一致するように修正してください。

Apache 1.3 からは、Apache を起動、停止、再起動する src/support/apachectl スクリプトがあります。あなたのシステムに合わせて若干のカスタマイズが必要かもしれません。スクリプトの最初のコメントを見てください。

TERM シグナル: 停止

親プロセスに TERM シグナルを送信すると、全ての子プロセスを直ちに殺そうとします。数秒後に子プロセスが完全に死んで、それから親プロセスが終了します。処理中のリクエストは終了して、それ以上のリクエストは受け取りません。

HUP シグナル: 再起動

親プロセスに HUP シグナルを送信すると、TERM シグナルのように子プロセスを殺しますが、親プロセスは終了しません。親プロセスは設定ファイルを再読み込みして、ログファイルを再び開きます。それから、新しい子プロセスを生んでリクエストの受信を続行します。

status module を使用していれば、HUP が送信されたときにサーバの統計値は 0 になります。

注: 再起動したときに設定ファイルにエラーがあれば、親プロセスは再起動しないで、エラーを出して終了します。これを避けるためには、以下を読んでください。

USR1 シグナル: 完全再起動

注: バージョン 1.2b9 以前では、このコードは不安定で、使うべきではありません。

USR1 シグナルは子プロセスの現在のリクエストの後、親プロセスに子を終了させるように(リクエストを受け取っていなくても直ちに終了するように)通知します。親プロセスは設定ファイルを再読み込みし、ログファイルを再び開きます。子プロセスが死ぬと、親プロセスは直に新しいリクエストを受け取る、設定の新しい子プロセスと置き換えます。

このコードは常に、MaxClientsMinSpareServersMaxSpareServers の設定に関連付けられています。その上、以下のように StartServers にも関連付けられています: もし、少なくとも一秒後に StartServers の新しい子が作られなければ、スラックをピックアップするのに十分なだけ作ってください。コードは、サーバにある現在のロードのための子の割り当て数を維持して、StartServers のパラメータをあなたが望んだものにしようとします。

status module を使っていれば、USR1 が送信されたときにサーバの統計値は 0 にはなりません。コードは、サーバが新しいリクエストを受け取り(これらは OS によってキューになり、失われることはありません)、パラメータの変更を可能にするのに要する時間を最小限にするように書かれています。このため、全ての子の世代のトラックを管理するために使われる scoreboard を管理しなければばりません。

status module は、完全再起動の前に始まったリクエストを受け取る子に G シグナルを送ります。

現在、全ての子が再起動以前のログを書くのを終了したことを確かめる USR1 を使ったログローテーションスクリプトのための方法がありません。古いログについてなにかを行う前に、USR1 シグナルを送った後、間を置くことをお勧めします。例えばヒットのほとんどが、低いバンド幅のユーザのために10 分以内になっていれば、古いログについてなにかを行う前に 15 分待つことができます。

注: 再起動する時に設定ファイルにエラーが出れば、親プロセスは再起動せずにエラーを出して終了します。完全再起動の場合には、親プロセスは終了するときに子プロセスを走らせたままにします(これは、最後のリクエストをハンドルすることにより"gracefully exiting"になる子プロセスです)。もしサーバを再起動しようとすると -- その聞いているポートにバインドできず、問題になるでしょう。今できることは、再起動する前にファイルの記述をチェックすることだけです。最も簡単な方法は root 以外のユーザで httpd を走らせることです。もしエラーがなければ、そのソケットとログを開けようとして、失敗するでしょう。なぜなら、root でないからです(または、今走っている httpd が既にそのポートを持っているからです)。もし他の理由で失敗しているのなら、それはおそらく設定ファイルのエラーなので、完全再起動する前にエラーを修正するべきでしょう。

追記: シグナルと競合条件

Apache 1.2b9 以前では、再起動と死ぬシグナルに関係したいくつかの競合条件がありました(競合条件の簡単な説明: 間の悪い時に予期しない動作が起こるような、時間に敏感な問題)。正しい機能を持ったアーキテクチャにするために、出来るだけ多くのものを削除します。しかし、正しいアーキテクチャに必要な競合条件があることに注意すべきです。

ディスク ScoreBoardFile を使っているアーキテクチャは、scoreboards を破壊する可能性があります。これは、"bind: Address already in use" (HUP の後)か、 "long lost child came home!" (after USR1) になります。前者は致命的なエラーですが、後者は scoreboard のスロットをサーバに失わせます。特別な場合の、ハードウェアの再起動による完全な再起動を行うと良いでしょう。このような問題は手段によって異なりますが、幸いなことにほとんどのアーキテクチャは scoreboard ファイルを要求しません。もしアーキテクチャで使っているなら、詳細については ScoreBoardFile のドキュメントを見てください。

NEXTMACHTEN (68k のみ) は restart/die シグナルをなくさせるような小さな競合条件を持っていますが、それ以外の問題はありません。

全てのアーキテクチャは、それぞれの子が HTTP 接続にある、二番目とそれに続くリクエストを巻き込む小さな競合条件があります(KeepAlive)。リクエスト行は読み込んで、リクエストヘッダを読む前に終了するかもしれません。1.2 を構成するにはあまりに遅く発見された修正があります。理論的にはこれはありませんが、KeepAlive クライアントがネットワークの待ち時間とサーバタイムアウトのせいで、これらを予想しているからです。実際は、どちらにも影響はないように見えます -- テストケースでは、サーバは一秒毎に 20 回再起動して、クライアントは壊れた画像や空のドキュメントのないサイトを見ることができます。


このページの情報に関わる、ご質問、お問い合わせは、 japache@infoscience.co.jpまで。

JAPACHE ホームページ