0N/A<!
DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
210N/A<
TITLE>Stopping and Restarting Apache</
TITLE>
210N/A<
h1>Stopping and Restarting Apache</
h1>
0N/A<
p>You will notice many <
code>httpd</
code> executables running on your system,
0N/Abut you should not send signals to any of them except the parent, whose
0N/Asay you shouldn't ever need to send signals to any process except the
0N/Aparent. There are three signals that you can send the parent:
0N/A<
code>TERM</
code>, <
code>HUP</
code>, and <
code>USR1</
code>, which will
0N/Abe described in a moment.
0N/A<
p>To send a signal to the parent you should issue a command such as:
0N/AYou can read about its progress by issuing:
0N/AModify those examples to match your
0N/A<
h3>TERM Signal: stop now</
h3>
0N/A<
p>Sending the <
code>TERM</
code> signal to the parent causes it to
0N/Aimmediately attempt to kill off all of its children. It may take it
44N/Aseveral seconds to complete killing off its children. Then the
210N/Aparent itself exits. Any requests in progress are terminated, and no
210N/Afurther requests are served.
210N/A<
h3>HUP Signal: restart now</
h3>
210N/A<
p>Sending the <
code>HUP</
code> signal to the parent causes it to kill off
210N/Aits children like in <
code>TERM</
code> but the parent doesn't exit. It
210N/Are-reads its configuration files, and re-opens any log files.
210N/AThen it spawns a new set of children and continues
210N/Awill notice that the server statistics are
210N/Aset to zero when a <
code>HUP</
code> is sent.
210N/A<
h3>USR1 Signal: graceful restart</
h3>
210N/A<
p><
b>Note:</
b> prior to release 1.2b9 this code is quite unstable and
210N/Ashouldn't be used at all.
210N/A<
p>The <
code>USR1</
code> signal causes the parent process to <
i>advise</
i>
210N/Athe children to exit after their current request (or to exit immediately
210N/Aif they're not serving anything). The parent re-reads its configuration
210N/Afiles and re-opens its log files. As each child dies off the parent
210N/Areplaces it with a child from the new <
i>generation</
i> of the
210N/Aconfiguration, which begins serving new requests immediately.
210N/A<
p>This code is designed to always respect the
210N/Ain the following manner: if after one second at least StartServers new
210N/Achildren have not been created, then create enough to pick up the slack.
210N/AThis is to say that the code tries to maintain both the number of children
210N/Aappropriate for the current load on the server, and respect your wishes
210N/Awith the StartServers parameter.
210N/Awill notice that the server statistics
210N/Aare <
b>not</
b> set to zero when a <
code>USR1</
code> is sent. The code
210N/Awas written to both minimize the time in which the server is unable to serve
210N/Anew requests (they will be queued up by the operating system, so they're
210N/Anot lost in any event) and to respect your tuning parameters. In order
210N/Ato do this it has to keep the <
i>scoreboard</
i> used to keep track
210N/Aof all children across generations.
210N/A<
p>The status module will also use a <
code>G</
code> to indicate those
210N/Achildren which are still serving requests started before the graceful
210N/A<
p>At present there is no way for a log rotation script using
210N/A<
code>USR1</
code> to know for certain that all children writing the
210N/Apre-restart log have finished. We suggest that you use a suitable delay
210N/Aafter sending the <
code>USR1</
code> signal before you do anything with the
210N/Aold log. For example if most of your hits take less than 10 minutes to
210N/Acomplete for users on low bandwidth links then you could wait 15 minutes
210N/Abefore doing anything with the old log.
210N/A<
h3>Appendix: signals and race conditions</
h3>
210N/A<
p>Prior to Apache 1.2b9 there were several <
i>race conditions</
i>
210N/Ainvolving the restart and die signals (a simple description of race
210N/Acondition is: a time-sensitive problem, as in if something happens at just
210N/Athe wrong time it won't behave as expected). For those architectures that
210N/Ahave the "right" feature set we have eliminated as many as we can.
210N/ABut it should be noted that there still do exist race conditions on
210N/A<
p>Architectures that use an on disk
210N/Ahave the potential to corrupt their scoreboards. This can result in
210N/Athe "bind: Address already in use" (after <
code>HUP</
code>) or
210N/A"long lost child came home!" (after <
code>USR1</
code>). The former is
210N/Aa fatal error, while the latter just causes the server to lose a scoreboard
210N/Aslot. So it might be advisable to use graceful restarts, with
210N/Aan occasional hard restart. These problems are very difficult to work
210N/Aaround, but fortunately most architectures do not require a scoreboard file.
210N/ASee the ScoreBoardFile documentation for a method to determine if your
210N/A<
p><
code>NEXT</
code> and <
code>MACHTEN</
code> have small race conditions
210N/Aserver to do anything otherwise problematic.
210N/A<!-- they don't have sigaction, or we're not using it -djg --> 210N/A<
p>All architectures have a small race condition in each child involving
210N/Athe second and subsequent requests on a persistent HTTP connection
210N/A(KeepAlive). It may exit after reading the request line but before
210N/Areading any of the request headers. There is a fix that was discovered
210N/Atoo late to make 1.2. In theory this isn't an issue because the KeepAlive
210N/Aclient has to expect these events because of network latencies and
210N/Aserver timeouts. In practice it doesn't seem to affect anything either
210N/A-- in a test case the server was restarted twenty times per second and
210N/Aclients successfully browsed the site without getting broken images or