--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+<HTML>
+<HEAD>
+<TITLE>Stopping and Restarting Apache</TITLE>
+</HEAD>
+
+<BODY>
+<!--#include virtual="header.html" -->
+<h1>Stopping and Restarting Apache</h1>
+
+<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.
+
+<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>
+
+You can read about its progress by issuing:
+
+<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>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 lose track of a child during graceful restart (you'll see an <a
+href="mod/core.html#errorlog">ErrorLog</a> message saying something about
+a <i>long lost child</i>). The ScoreBoardFile directive explains how
+to figure out if your server uses a file, and possibly how to avoid it.
+There is also the potential that the scoreboard will be corrupted during
+any signalling, but this only has bad effects on graceful restart.
+
+<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>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+<HTML>
+<HEAD>
+<TITLE>Stopping and Restarting Apache</TITLE>
+</HEAD>
+
+<BODY>
+<!--#include virtual="header.html" -->
+<h1>Stopping and Restarting Apache</h1>
+
+<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.
+
+<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>
+
+You can read about its progress by issuing:
+
+<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>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 lose track of a child during graceful restart (you'll see an <a
+href="mod/core.html#errorlog">ErrorLog</a> message saying something about
+a <i>long lost child</i>). The ScoreBoardFile directive explains how
+to figure out if your server uses a file, and possibly how to avoid it.
+There is also the potential that the scoreboard will be corrupted during
+any signalling, but this only has bad effects on graceful restart.
+
+<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>
projects / apache / commitdiff