Apache HTTP サーバ バージョン 2.2

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

# 停止と再起動

翻訳済み言語: de | en | es | fr | ja | ko | tr

この日本語訳はすでに古くなっている 可能性があります。 最近更新された内容を見るには英語版をご覧下さい。

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

### 参照

- `httpd`
- `apachectl`

## イントロダクション

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

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

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

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

## 急な停止

シグナル: TERM
  `apachectl -k stop`

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

## 緩やかな再起動 (Graceful Restart)

シグナル: USR1
  `apachectl -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` が既に必要なポートにバインドしているため) に失敗するでしょう。 これ以外の理由で起動に失敗したのであれば、 それは設定ファイルのエラーで、 緩やかな再起動を行う前にその誤りを修正しなければなりません。

## 急な再起動

シグナル: HUP
  `apachectl -k restart`

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

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

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

## 緩やかな停止 (Graceful Stop)

Signal: WINCH
  `apachectl -k graceful-stop`

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

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

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

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

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

翻訳済み言語: de | en | es | fr | ja | ko | tr