From: Yoshiki Hayashi Date: Wed, 10 Jul 2002 07:01:02 +0000 (+0000) Subject: Oops. I don't know why but these files weren't committed at previous attempt. X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=d64b4a277d4a2c5360b873f429b133fd6fce2195;p=apache Oops. I don't know why but these files weren't committed at previous attempt. New Japanese translation. Submitted by: Hiroaki KAWAI Reviewed by: Yoshiki Hayashi git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95999 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/stopping.html b/docs/manual/stopping.html deleted file mode 100644 index 628c40403b..0000000000 --- a/docs/manual/stopping.html +++ /dev/null @@ -1,209 +0,0 @@ - - - - - - - Stopping and Restarting the Server - - - - - - -

Stopping and Restarting the Server

- -

This document covers stopping and restarting Apache on - Unix-like systems. Windows users should see Signalling Apache when - running.

- -

You will notice many httpd executables running - on your system, but you should not send signals to any of them - except the parent, whose pid is in the PidFile. That is to say you - shouldn't ever need to send signals to any process except the - parent. There are three signals that you can send the parent: - TERM, HUP, and USR1, - which will be described in a moment.

- -

To send a signal to the parent you should issue a command - such as:

- -
-
-    kill -TERM `cat /usr/local/apache/logs/httpd.pid`
-
-
- You can read about its progress by issuing: - -
-
-    tail -f /usr/local/apache/logs/error_log
-
-
- Modify those examples to match your ServerRoot and PidFile settings. - -

A shell script called apachectl is provided which - automates the processing of signalling Apache. For details - about this script, see the documentation on starting Apache.

- -

Stop Now

- -

Signal: TERM
- apachectl stop

- -

Sending the TERM signal to the parent causes it - to immediately attempt to kill off all of its children. It may - take it several seconds to complete killing off its children. - Then the parent itself exits. Any requests in progress are - terminated, and no further requests are served.

- -

Graceful Restart

- -

Signal: USR1
- apachectl graceful

- -

The USR1 signal causes the parent process to - advise the children to exit after their current - request (or to exit immediately if they're not serving - anything). The parent re-reads its configuration files and - re-opens its log files. As each child dies off the parent - replaces it with a child from the new generation of - the configuration, which begins serving new requests - immediately.

- On certain platforms that do not allow USR1 to be used for a - graceful restart, an alternative signal may be used (such as - WINCH). apachectl graceful will send the right signal for your - platform. - -

This code is designed to always respect the MaxClients, MinSpareServers, - and MaxSpareServers - settings. Furthermore, it respects StartServers in the - following manner: if after one second at least StartServers new - children have not been created, then create enough to pick up - the slack. This is to say that the code tries to maintain both - the number of children appropriate for the current load on the - server, and respect your wishes with the StartServers - parameter.

- -

Users of the status module - will notice that the server statistics are not - set to zero when a USR1 is sent. The code was - written to both minimize the time in which the server is unable - to serve new requests (they will be queued up by the operating - system, so they're not lost in any event) and to respect your - tuning parameters. In order to do this it has to keep the - scoreboard used to keep track of all children across - generations.

- -

The status module will also use a G to indicate - those children which are still serving requests started before - the graceful restart was given.

- -

At present there is no way for a log rotation script using - USR1 to know for certain that all children writing - the pre-restart log have finished. We suggest that you use a - suitable delay after sending the USR1 signal - before you do anything with the old log. For example if most of - your hits take less than 10 minutes to complete for users on - low bandwidth links then you could wait 15 minutes before doing - anything with the old log.

- -

Note: If your configuration file has errors - in it when you issue a restart then your parent will not - restart, it will exit with an error. In the case of graceful - restarts it will also leave children running when it exits. - (These are the children which are "gracefully exiting" by - handling their last request.) This will cause problems if you - attempt to restart the server -- it will not be able to bind to - its listening ports. Before doing a restart, you can check the - syntax of the configuration files with the -t - command line argument (see httpd). This still will not - guarantee that the server will restart correctly. To check the - semantics of the configuration files as well as the syntax, you - can try starting httpd as a non-root user. If there are no - errors it will attempt to open its sockets and logs and fail - because it's not root (or because the currently running httpd - already has those ports bound). If it fails for any other - reason then it's probably a config file error and the error - should be fixed before issuing the graceful restart.

- -

Restart Now

- -

Signal: HUP
- apachectl restart

- -

Sending the HUP signal to the parent causes it - to kill off its children like in TERM but the - parent doesn't exit. It re-reads its configuration files, and - re-opens any log files. Then it spawns a new set of children - and continues serving hits.

- -

Users of the status module - will notice that the server statistics are set to zero when a - HUP is sent.

- -

Note: If your configuration file has errors - in it when you issue a restart then your parent will not - restart, it will exit with an error. See below for a method of - avoiding this.

- -

Appendix: signals and race conditions

- -

Prior to Apache 1.2b9 there were several race - conditions involving the restart and die signals (a simple - description of race condition is: a time-sensitive problem, as - in if something happens at just the wrong time it won't behave - as expected). For those architectures that have the "right" - feature set we have eliminated as many as we can. But it should - be noted that there still do exist race conditions on certain - architectures.

- -

Architectures that use an on disk ScoreBoardFile have the - potential to corrupt their scoreboards. This can result in the - "bind: Address already in use" (after HUP) or - "long lost child came home!" (after USR1). The - former is a fatal error, while the latter just causes the - server to lose a scoreboard slot. So it might be advisable to - use graceful restarts, with an occasional hard restart. These - problems are very difficult to work around, but fortunately - most architectures do not require a scoreboard file. See the ScoreBoardFile - documentation for a architecture uses it.

- -

NEXT and MACHTEN (68k only) have - small race conditions which can cause a restart/die signal to - be lost, but should not cause the server to do anything - otherwise problematic. - -

- -

All architectures have a small race condition in each child - involving the second and subsequent requests on a persistent - HTTP connection (KeepAlive). It may exit after reading the - request line but before reading any of the request headers. - There is a fix that was discovered too late to make 1.2. In - theory this isn't an issue because the KeepAlive client has to - expect these events because of network latencies and server - timeouts. In practice it doesn't seem to affect anything either - -- in a test case the server was restarted twenty times per - second and clients successfully browsed the site without - getting broken images or empty documents. - -

- - - diff --git a/docs/manual/stopping.html.ja.jis b/docs/manual/stopping.html.ja.jis new file mode 100644 index 0000000000..e4f416bc1d --- /dev/null +++ b/docs/manual/stopping.html.ja.jis @@ -0,0 +1,220 @@ + + + + + + 停止と再起動 + + + + + + + +

サーバの停止と再起動

+ +

この文書では Unix に類似したシステムでの + Apache の停止と再起動について扱っています。Windows + ユーザ (Windows で Apache を使う場合) は、実行中の Apache + にシグナルを送るもご覧下さい。

+ +

たくさんの実行形式 httpd がシステム上で + 実行されているのに気が付くでしょうが、シグナルを送るのは + 親プロセスだけで、それ以外の個々のプロセスには + シグナルを送らないで下さい。その親プロセスの pid は + PidFile + に書かれています。これはつまり、親以外のプロセスに + シグナルを送る必要すらない、ということです。 + 親プロセスに送ることができる 3 種類のシグナルがあります: + TERM, HUP, USR1 + です。これらの説明については続きをご覧下さい。

+ +

親プロセスにシグナルを送るには、 + 次のようなコマンドを発行して下さい:

+ +
+
+    kill -TERM `cat /usr/local/apache/logs/httpd.pid`
+
+
+ これの実行状況は次のコマンドで読むことができます: + +
+
+    tail -f /usr/local/apache/logs/error_log
+
+
+ ここに挙げた例は、各自の + ServerRoot + と + PidFile + の設定に適合するように適宜修正して下さい。 + +

apachectl + と呼ばれるシェルスクリプトで、Apache にシグナルを送る手順を + 自動化することができます。このスクリプトの詳細に関しては、 + Apache の起動の文書をご覧下さい。

+ +

急な停止

+ +

シグナル: TERM
+ apachectl stop

+ +

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

+ +

緩やかな再起動

+ +

シグナル: USR1
+ apachectl graceful

+ +

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

+ 特定のプラットホームでは USR1 を緩やかな再起動のために + 使うことができませんが、代わりのシグナル + (例えば WINCH) が使用できるでしょう。 + apachectl graceful + というコマンドはプラットホームに合ったシグナルを送ります。 + +

このコードは常に + MaxClients, + MinSpareServers, + MaxSpareServers + の設定を重視します。また、次のようにして + StartServers + を守ります: + 少なくとも 1 秒後に StartServers 個の新しい子プロセスが + 生成されていなければ、その数になるように適宜プロセスを生成します。 + この挙動は言ってみれば、現在の負荷に対して適切な子プロセスの数と + StartServers パラメータでの希望の数の両方を維持しようと + しているといえるでしょう。

+ +

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

+ +

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

+ +

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

+ +

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

+ +

急な再起動

+ +

シグナル: HUP
+ apachectl restart

+ +

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

+ +

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

+ +

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

+ +

付録: シグナルと競合状態

+ +

Apache 1.2b9 以前は、再起動や停止のシグナルを含む競合状態 + (競合状態を簡単に説明すると: タイミンにグよる問題で、 + 具合の悪い時間帯にちょうど何かが起こると予想外の動作をする + ようなことを指します) がありました。 + 「正しい」機能を持っているアーキテクチャでは、できるだけ + このようなことが起こらないようにしています。 + しかし、ある種のアーキテクチャでは競合状態は未だ確実に起こりえる + ということに注意してください。

+ +

ディスク上で + ScoreBoardFile + を使用しているアーキテクチャでは、 + 潜在的にスコアボードが壊れる可能性があります。 + スコアボードが壊れた場合は、 + "bind: Address already in use" (HUP 後) や + "long lost child came home!" (USR1 後) + といった結果になります。 + 前者は致命的なエラーですが、 + 後者はスコアボードスロットを失うだけです。 + ですから緩やかな再起動は、たまに確実な再起動 (HUP) + も併用して使った方が良いでしょう。 + これらの問題を克服するのは非常に難しいのですが、 + 幸いなことに大部分のアーキテクチャではスコアボードのファイルは必要ありません。 + これを使用するアーキテクチャは、 + ScoreBoardFile + をご覧下さい。

+ +

NEXTMACHTEN (68k のみ) + は、再起動と終了のシグナルを失うような小さな競合状態を持っていますが、 + その他に問題になるようなことをサーバに及ぼすことはありません。 + +

+ +

全てのアーキテクチャにおいて、個々の子プロセスで + 継続的な HTTP コネクション (KeepAlive) + に関する小さな競合状態が起こりえます。 + リクエスト行を読んだ後、そしてリクエストヘッダを読む前に + 子プロセスは終了するかも知れません。 + これに対する修正がありますが 1.2 で修正するには発見が遅すぎました。 + 理論的には、これは問題ではありません。 + なぜなら KeepAlive のクライアントは、ネットワーク遅延や + サーバのタイムアウトなどに備えていなければならないからです。 + 実際にも何か影響があるようには見えません + -- テストケースでサーバを 1 秒間に 20 回再起動しても + クライアントは壊れた画像や空のドキュメントを受け取ることなく + 正常に閲覧できています。

+ + + +