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

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

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

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

    kill -TERM `cat /usr/local/etc/httpd/logs/httpd.pid`
送信することによってその処理について読むことができます:
    tail -f /usr/local/etc/httpd/logs/error_log
ServerRootPidFileセッティングに合致する例を修正します。

TERM Signal: stop now

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

HUP Signal: restart now

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

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

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

USR1 Signal: graceful restart

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

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

このコードは常にMaxClients, MinSpareServers, MaxSpareServersセッティングに関連して設計されています。その上、以下の方法で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が再起動と死ぬシグナルを含んでいました(単純なレース状態の記述は: なにかがちょうど悪い時間に起これば期待したようには動かないtime-sensitive問題)"right"の特徴のセットを持つこれらのアーキテクチャーについては可能な限り多く削除しています。しかし特定のアーキテクチャーにレース状態がまだあることに注意すべきです。

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

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

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

検索文字
Index