Apache HTTP サーバ バージョン 2.4

この文書では Unix に類似したシステムでの Apache の停止と再起動について扱っています。 Windows NT, 2000, XP ユーザはサービスとして Apache を実行するで、Windows 9x, MEユーザはコンソールアプリケーションとして Apache を実行するで、 これらのプラットホームでの使用方法をご覧下さい。
Apache を停止したり再起動したりするためには、実行されている
    httpd プロセスにシグナルを送る必要があります。
    シグナルを送るには二つの方法があります。
    一つ目はプロセスに直接シグナルを送る unix の kill
    コマンドを使用する方法です。
    システムを見ればたくさんの httpd が
    実行されているのに気が付くでしょうが、シグナルを送るのは
    親プロセスだけで、それ以外の個々のプロセスには
    シグナルを送らないで下さい。その親プロセスの pid は
    PidFile
    に書かれています。これはつまり、親以外のプロセスに
    シグナルを送る必要すらない、ということです。
    親プロセスに送ることができる 4 種類のシグナルがあります:
    TERM,
    HUP, 
    USR1,
    WINCH
    です。これらの説明については続きをご覧下さい。
親プロセスにシグナルを送るには、 次のようなコマンドを発行して下さい:
kill -TERM `cat /usr/local/apache2/logs/httpd.pid`
httpd プロセスにシグナルを送る 2 番目の方法は
    -k というコマンドライン引数を使用することです。
    下で説明されているように、stop, restart, 
    graceful, graceful-stop を指定できます。
    これらは httpd の引数ですが、
    制御用のスクリプト apache2ctl はそれらの引数をそのまま
    httpd に渡します。
httpd にシグナルを送った後、
    実行状況を次のコマンドで読むことができます:
tail -f /usr/local/apache2/logs/error_log
ここに挙げた例は、各自の
    ServerRoot
    と
    PidFile
    の設定に適合するように適宜修正して下さい。
apache2ctl -k stopTERM あるいは stop 
    シグナルを親プロセスに送ると、即座に子プロセス全てを kill しようとします。
    子プロセスを完全に kill し終わるまでに数秒かかるかもしれません。
    その後、親プロセス自身が終了します。
    処理中のリクエストは全て停止され、もはやリクエストに対する
    応答はされません。
apache2ctl -k graceful親プロセスは USR1 あるいは graceful
    シグナルを受け取ると、子プロセスに現在のリクエストの処理の後に終了する
    (あるいは何もしていなければすぐに終了する)
    ように助言します。
    親プロセスは設定ファイルを再読込して、ログファイルを開き直します。
    子プロセスが徐々になくなるに従って、
    新しい世代の設定による子プロセスに置き換えていきます。
    そして、これらが新たなリクエストに即座に応答し始めます。
このコードは常に
    MPM のプロセス制御ディレクティブの設定を重視しますので、
    クライアントのリクエストを扱うプロセスとスレッドの数を再起動の処理中も
    適切な値に維持されます。。また、次のようにして
    StartServers
    を守ります:
    少なくとも 1 秒後に StartServers 個の新しい子プロセスが
    生成されていなければ、その数になるように適宜プロセスを生成します。
    この挙動は現在の負荷に対して適切な子プロセスの数と
    StartServers パラメータでの
    希望の数の両方を維持しようとしています。
mod_status を
    使用している場合は、USR1 シグナルが送られた際に
    サーバ統計がゼロに設定されないことに
    注意してください。
    サーバが新しいリクエストに応答不能な時間を最小にするように
    (リクエストは OS によってキューに追加されるので絶対に紛失はしません)、
    また同時に、希望のチューニングパラメータを守るように
    コードは書かれています。
    このようにするために、世代をまたがった全子プロセスの追跡に使われている
    スコアボードを維持しなければなりません。
status モジュールは、緩やかな再起動以前から開始して
    リクエストに応答し続けている子プロセスを特定するために、
    G を使うこともします。
現在、USR1 を使うログ移動スクリプトでは、
    再起動前の子プロセスがログを書き終わったことを確証する方法が
    ありません。古いログに対して何かする前に、
    USR1 シグナルを送った後いくらか適当な時間待つことを
    提案します。例えば、帯域の狭い通信路のユーザのリクエストのほとんどが 10 
    分以下で完了しているということが分かっていれば、
    古いログに何かする前に 15 分待つということです。
再起動が発行されると設定ファイルの構文チェックがまず走り、 設定ファイルに (構文上の) 誤りがないかチェックされます。 誤りがあった場合エラーメッセージでその旨が示され、サーバは再起動されません。 こうすることでサーバが終了しているけれども再起動できないという状況を 防ぎ、サーバが機能不全な状態になるのを防いでいます。
ただしこれでもサーバが正しく再起動することは保証されません。
    設定ファイルの意味的な内容を構文と同様に検証したい場合は、
    非 root ユーザで httpd を起動しようとすればわかります。
    もしエラーがなければ、ソケットやログを開こうとして
    root でないため
    (もしくは実行中の httpd
    が既に必要なポートにバインドしているため)
    に失敗するでしょう。
    これ以外の理由で起動に失敗したのであれば、
    それは設定ファイルのエラーで、
    緩やかな再起動を行う前にその誤りを修正しなければなりません。
apache2ctl -k restartHUP あるいは restart シグナルを親プロセスに送ると、
    TERM と同様に子プロセスを kill しますが、
    親プロセスは終了しません。
    設定ファイルを再読込して、ログファイル全てを開き直します。
    その後、新しい子プロセスを起動して応答を続けます。
mod_status
    を使っている場合は、HUP が送られた場合に
    サーバ統計がゼロに設定されることに注意してください。
apache2ctl -k graceful-stopWINCH や graceful-stop シグナルを受け取ると、
    親プロセスは子プロセスに現在処理中のリクエストの後に終了する
    (あるいは処理中のものが何もなければ直ちに終了する)
    ようにアドバイスします。
    その後親プロセスは PidFile
    を削除し、ポートでの Listen を全て停止します。
    親プロセスはどの子プロセスがリクエスト処理中かを監視し続けています。
    全ての子プロセスが終了するか
    GracefulShutdownTimeout
    で設定した時間が過ぎると、親プロセスも終了します。
    タイムアウトに達した場合、残りの子プロセスには TERM
    シグナルが送信され強制的に終了されます。
"graceful" 状態の場合 TERM シグナルを受け取ると、
    親プロセスも子プロセスもすぐに終了します。しかしながら
    PidFile
    が削除されてしまっているので、apache2ctl
    や httpd にこのシグナルを送ることはできません。
graceful-stop を使うとまったく同一に設定された
    複数の httpd を同時に実行することができます。
    Apache を緩やかにアップグレードするのにはとても便利ですが、
    設定ファイルによってはデッドロックやレースコンディションを
    引き起こすこともあります。
ディスク上のファイルを使うもの、たとえば
    Lockfile や 
    ScriptSock 
    のファイルなどはサーバの PID を含めて管理されていて、
    共存できるよう注意が払われています。
    しかしその他設定ディレクティブやサードパーティ製のモジュール、
    CGI ユーティリティのパーシステント層などで
    ディスク上にロックファイルや状態管理ファイルを
    使っている場合は、実行されている複数の httpd
    が互いに衝突しないように気をつけなければなりません。
rotatelogs 形式のパイプを使ったログといった、
    その他潜在的なレースコンディションについても注意しなければなりません。
    複数の rotatelogs が同じファイルを同時に
    rotate しようとすると、互いにログファイルを破壊してしまいます。