| <!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> |