-<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
-<HTML>
-<HEAD>
-<TITLE>Stopping and Restarting Apache</TITLE>
-</HEAD>
+URI: stopping.html.de
+Content-Language: de
+Content-type: text/html; charset=ISO-8859-1
-<BODY>
-<!--#include virtual="header.html" -->
-<h1>Stopping and Restarting Apache</h1>
+URI: stopping.html.en
+Content-Language: en
+Content-type: text/html; charset=ISO-8859-1
-<p>You will notice many <code>httpd</code> executables running on your system,
-but you should not send signals to any of them except the parent, whose
-pid is in the <a href="mod/core.html#pidfile">PidFile</a>. 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:
-<code>TERM</code>, <code>HUP</code>, and <code>USR1</code>, which will
-be described in a moment.
+URI: stopping.html.es
+Content-Language: es
+Content-type: text/html; charset=ISO-8859-1
-<p>To send a signal to the parent you should issue a command such as:
-<blockquote><pre>
- kill -TERM `cat /usr/local/etc/httpd/logs/httpd.pid`
-</pre></blockquote>
+URI: stopping.html.fr
+Content-Language: fr
+Content-type: text/html; charset=ISO-8859-1
-You can read about its progress by issuing:
+URI: stopping.html.ja.utf8
+Content-Language: ja
+Content-type: text/html; charset=UTF-8
-<blockquote><pre>
- tail -f /usr/local/etc/httpd/logs/error_log
-</pre></blockquote>
-
-Modify those examples to match your
-<a href="mod/core.html#serverroot">ServerRoot</a> and
-<a href="mod/core.html#pidfile">PidFile</a> settings.
-
-<h3>TERM Signal: stop now</h3>
-
-<p>Sending the <code>TERM</code> 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.
-
-<h3>HUP Signal: restart now</h3>
-
-<p>Sending the <code>HUP</code> signal to the parent causes it to kill off
-its children like in <code>TERM</code> 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.
-
-<p>Users of the
-<a href="mod/mod_status.html">status module</a>
-will notice that the server statistics are
-set to zero when a <code>HUP</code> is sent.
-
-<h3>USR1 Signal: graceful restart</h3>
-
-<p><b>Note:</b> prior to release 1.2b9 this code is quite unstable and
-shouldn't be used at all.
-
-<p>The <code>USR1</code> signal causes the parent process to <i>advise</i>
-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 <i>generation</i> of the
-configuration, which begins serving new requests immediately.
-
-<p>Architectures that use an on disk <a
-href="mod/core.html#scoreboardfile">ScoreBoardFile</a> are not supported
-on graceful restarts. See the ScoreBoardFile documentation for a method
-to determine if your architecture uses it.
-
-<p>This code is designed to always respect the
-<a href="mod/core.html#maxclients">MaxClients</a>,
-<a href="mod/core.html#minspareservers">MinSpareServers</a>,
-and <a href="mod/core.html#maxspareservers">MaxSpareServers</a> settings.
-Furthermore, it respects <a href="mod/core.html#startservers">StartServers</a>
-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.
-
-<p>Users of the
-<a href="mod/mod_status.html">status module</a>
-will notice that the server statistics
-are <b>not</b> set to zero when a <code>USR1</code> 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 <i>scoreboard</i> used to keep track
-of all children across generations.
-
-<p>The status module will also use a <code>G</code> to indicate those
-children which are still serving requests started before the graceful
-restart was given.
-
-<p>At present there is no way for a log rotation script using
-<code>USR1</code> 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 <code>USR1</code> 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.
-
-<h3>Appendix: signals and race conditions</h3>
-
-<p>Prior to Apache 1.2b9 there were several <i>race conditions</i>
-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.
-
-<p>Architectures that use an on disk <a
-href="mod/core.html#scoreboardfile">ScoreBoardFile</a> have the potential
-to corrupt their scoreboards whenever a signal is received. It is
-possible for the server to forget about some children when this happens.
-See the ScoreBoardFile documentation for a method to determine if your
-architecture uses it.
-
-<p><code>NEXT</code> and <code>MACHTEN</code> 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.
-<!-- they don't have sigaction, or we're not using it -djg -->
-
-<p>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.
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+URI: stopping.html.ko.euc-kr
+Content-Language: ko
+Content-type: text/html; charset=EUC-KR
projects / apache / blobdiff