[an error occurred while processing this directive]
[APACHE DOCUMENTATION]

Apache HTTP Server Version 1.3

Apache の終了またはリスタート

システム上でたくさんの httpd を走らせることには注意しても、PidFile にある pid の親以外のものにシグナルを送るべきではありません。これは親以外のあらゆる処理に対して送る必要はないということです。親に送ることのできるシグナルは三つあります:TERMHUPUSR1 は重要なもので、以下に記述があります。

親にシグナルを送るためには、以下のようなコマンドを送信すべきです:

    kill -TERM `cat /usr/local/apache/logs/httpd.pid`
以下を送信することによってその処理について読むことができます:
    tail -f /usr/local/apache/logs/error_log
ServerRootPidFile セッティングに一致させるためには、これらの例を修正してください。

TERM Signal: stop now

親に対して TERM シグナルを送ると、その子の全てをすぐに終了させるようにします。その子の終了を完全に行なうには数秒かかるかもしれません。その時親自身は存在します。進行中のあらゆる要求は終了して、それ以上の要求は受け入れられません。

HUP Signal: restart now

親に HUP シグナルを送信すると TERM の中にあるような子を終了させますが、親は終了しません。それはコンフィグレーションファイルを再度読み、なんらかのログファイルを再び開きます。それから新しい子のセットを作り、hits の受信を続行します。

status module のユーザーは HUP が送信された時、サーバ統計がゼロにセットしてあることに気付くでしょう。

Note: 再起動させる時に、もしその中にコンフィグレーションファイルがエラーを持っていると、親が再起動せずエラーと共に終了します。これを避ける方法については以下を参照してください。

USR1 Signal: graceful restart

Note: 以前にリリースされた1.2b9のこのコードは非常に不安定で使うべきではありません。

USR1 シグナルは最新の要求の後(または、もしそれらがなにも受信されていないなら、直に終了します)、子に終了を忠告する親処理を行ないます。親はそのコンフィギュレーションファイルを再度読み込み、ログファイルを開きます。それぞれの子が終了すると、親は新しい要求を直に受け取り始めるコンフィギュレーションの新しい世代からの子と置き換えます。

このコードは常に MaxClientsMinSpareServersMaxSpareServers セッティングを考慮して設計されています。その上、以下の方法で StartServers を考慮しています: もし少なくとも一秒後にStartServers の新しい子が作られないと、スラックを回復するために十分に作ります。これはコードがサーバの現在のロードに割り当てる子の数と StartServers のパラメータへの要求に関連した子の数の両方を維持しようとします。

status module のユーザーは USR1 が送信された時、サーバ統計がゼロにセットされないことに気付くでしょう。コードはサーバが新しい要求を受け取ることができない最小時間(それらは OS によって行列して待ち、それでなんらかの事象に没頭することはありません)とチューニングに関連した最小時間の両方で書かれています。これをするために、世代を横切る全ての子のトラックを管理するための scoreboard を管理しなければなりません。

ステータスモジュールはまた、正常な再起動が起こる前に送信された要求をまだ受け取っている、これらの子を指し示すために G を使うでしょう。

現在全ての子が書いている pre-restart ログが終了したことを確実に知るためにはログローテーションスクリプトが USR1 を使う以外に方法がない。古いログでなにかをする前に、USR1 シグナルを送信した後に適当な遅延を使うことを推奨します。例えば、もしヒットのほとんどが低いバンド幅リンクのユーザーにとって10分以内で完了するなら、古いログに対してなにかを行なう前に15分待つことができます。

Note: もしコンフィギュレーションファイルがその中にエラーを持っていれば、再起動をしようとした時に親が再起動せず、エラーと共に終了します。正常な再起動の場合には終了した時に子を作動させたままにします。 (これらは最後の要求をハンドリングすることによる"正常な終了"の子です。)これはサーバを再起動させようとすると問題を起こします -- その聞いているポートを繋ぐのは不可能でしょう。現在、再起動を行なう前にファイルのシンタックスのチェックを行なうことが次善策です。最も簡単な方法はnon-rootのユーザとしてhttpdを走らせることです。もしエラーがあれば、そのソケットやログ、フェイルを開くのはそれがルートではないからです。(もしくは現在すでに走っているhttpdがポートバウンドを持っているか)もしなにか他の理由で失敗すれば、そのたいていのコンフィグファイルエラーとエラーは正常な再起動を行なおうとする前に仕組まれていたのでしょう。

Appendix: signals and race conditions

以前のApache 1.2b9ではいくつかのrace conditionsが再起動と死ぬシグナルを含んでいました(単純なレース状態は: 期待したようには動かない、間が悪いときに起こるような問題)"right"の特徴のセットを持つこれらのアーキテクチャーについては可能な限り多く削除しています。しかし特定のアーキテクチャーにレース状態がまだあることに注意すべきです。

ディスクScoreBoardFile上で使うアーキテクチャーはスコアボードを壊す可能性があります。これは This can result in the "bind: すでに使用中のアドレス" (after HUP)や"長い間不明の子が戻ってきた!" (after USR1)ということになります。前者は致命的なエラーですが、一方後者はサーバのスコアボードをなくすことになります。時々行なうハードの再起動で正常な再起動を行なうのが賢明かもしれません。これらの問題は非常に次善策が難しいのですが、幸運にもほとんどのアーキテクチャーはスコアボードファイルを要求しません。もしアーキテクチャーがそれを使うなら、解決する方法としてスコアボードファイルのドキュメントを参照してください。

NEXTMACHTEN (68k only)は失われたrestart/dieシグナルを起こすことができる小さなレース状態を持っていますが、サーバになにか別の問題が起こることはないでしょう。

全てのアーキテクチャーはそれぞれの子が含んでいる二番目とそれに続く持続性のHTTP接続(KeepAlive)にある要求に小さなレース状態を持っています。要求行を読んだ後に終了するかもしれませんが、なんらかの要求ヘッダを読む前に終了するかもしれません。1.2をメイクするには遅すぎることがわかります。理屈の上でこれが問題にならないのは、KeepAliveクライアントがネットワークの待ち時間とサーバのタイムアウトの理由のせいでこれらの事象を予想しなければならないからです。実際にはどちらにも影響を与えていないように見えます -- テストケースではサーバは1秒ごとに20回再起動して、壊れた画像や空のドキュメントを持ってこないで首尾よくサイトを閲覧しました。


Apache HTTP Server Version 1.3

検索文字
Index The English original manual is here.
このページの情報に関わる、ご質問、お問い合わせは、 japache@infoscience.co.jpまで。

JAPACHE ホームページ