<?xml version="1.0" encoding="iso-2022-jp"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>

    <title>停止と再起動</title>
  </head>
  <!-- English revision: 1.25 -->
  <!-- Background white, links blue (unvisited), navy (visited), red (active) -->

  <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
  vlink="#000080" alink="#FF0000">
        <div align="center">
      <img src="images/sub.gif" alt="[APACHE DOCUMENTATION]" /> 

      <h3>Apache HTTP Server Version 2.0</h3>
    </div>




    <h1 align="center">サーバの停止と再起動</h1>

    <p>この文書では Unix に類似したシステムでの
    Apache の停止と再起動について扱っています。Windows
    ユーザ (Windows で Apache を使う場合) は、<a
    href="platform/windows.html#signal">実行中の Apache
    にシグナルを送る</a>もご覧下さい。</p>

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

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

    <blockquote>
<pre>
    kill -TERM `cat /usr/local/apache/logs/httpd.pid`
</pre>
    </blockquote>
    これの実行状況は次のコマンドで読むことができます:

    <blockquote>
<pre>
    tail -f /usr/local/apache/logs/error_log
</pre>
    </blockquote>
    ここに挙げた例は、各自の
    <a href="mod/core.html#serverroot">ServerRoot</a>
    と
    <a href="mod/mpm_common.html#pidfile">PidFile</a>
    の設定に適合するように適宜修正して下さい。

    <p><a href="programs/apachectl.html">apachectl</a>
    と呼ばれるシェルスクリプトで、Apache にシグナルを送る手順を
    自動化することができます。このスクリプトの詳細に関しては、
    <a href="invoking.html">Apache の起動</a>の文書をご覧下さい。</p>

    <h3>急な停止</h3>

    <p><strong>シグナル:</strong> TERM<br />
     <code>apachectl stop</code></p>

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

    <h3>緩やかな再起動</h3>

    <p><strong>シグナル:</strong> USR1<br />
     <code>apachectl graceful</code></p>

    <p>親プロセスは <code>USR1</code> シグナルを受け取ると、
    子プロセスに現在のリクエストの処理の後に終了する
    (あるいは何もしていなければすぐに終了する)
    ように<em>助言</em>します。
    親プロセスは設定ファイルを再読込して、ログファイルを開き直します。
    子プロセスが徐々になくなるに従って、
    新しい<em>世代</em>の設定による子プロセスに置き換えていきます。
    そして、これらが新たなリクエストに即座に応答し始めます。</p>
    <i>特定のプラットホームでは USR1 を緩やかな再起動のために
    使うことができませんが、代わりのシグナル
    (例えば WINCH) が使用できるでしょう。
    <code>apachectl graceful</code>
    というコマンドはプラットホームに合ったシグナルを送ります。</i>

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

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

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

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

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

    <h3>急な再起動</h3>

    <p><strong>シグナル:</strong> HUP<br />
     <code>apachectl restart</code></p>

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

    <p><a href="mod/mod_status.html">status モジュール</a>
    を使っている場合は、<code>HUP</code> が送られた場合に
    サーバ統計がゼロに設定されることに注意してください。</p>

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

    <h3>付録: シグナルと競合状態</h3>

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

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

    <p><code>NEXT</code> や <code>MACHTEN</code> (68k のみ)
    は、再起動と終了のシグナルを失うような小さな競合状態を持っていますが、
    その他に問題になるようなことをサーバに及ぼすことはありません。
    <!-- they don't have sigaction, or we're not using it -djg -->
    </p>

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

    <h3 align="center">Apache HTTP Server Version 2.0</h3>
    <a href="./"><img src="images/index.gif" alt="Index" /></a>



  </body>
</html>

