| <?xml version='1.0' encoding='UTF-8' ?> |
| <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd"> |
| <?xml-stylesheet type="text/xsl" href="./style/manual.en.xsl"?> |
| <!-- $Revision: 1.12 $ --> |
| |
| <!-- |
| Copyright 2002-2004 The Apache Software Foundation |
| |
| Licensed under the Apache License, Version 2.0 (the "License"); |
| you may not use this file except in compliance with the License. |
| You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| |
| <manualpage metafile="stopping.xml.meta"> |
| |
| <title>Stopping and Restarting</title> |
| |
| <summary> |
| <p>This document covers stopping and restarting Apache on |
| Unix-like systems. Windows NT, 2000 and XP users should see |
| <a href="platform/windows.html#winsvc">Running Apache as a |
| Service</a> and Windows 9x and ME users should see <a |
| href="platform/windows.html#wincons">Running Apache as a |
| Console Application</a> for information on how to control |
| Apache on those platforms.</p> |
| </summary> |
| |
| <seealso><a href="programs/httpd.html">httpd</a></seealso> |
| <seealso><a href="programs/apachectl.html">apachectl</a></seealso> |
| |
| <section id="introduction"><title>Introduction</title> |
| |
| <p>In order to stop or restart Apache, you must send a signal to |
| the running <code>httpd</code> processes. There are two ways to |
| send the signals. First, you can use the unix <code>kill</code> |
| command to directly send signals to the processes. 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 <directive |
| module="mpm_common">PidFile</directive>. 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><a href="#term">TERM</a></code>, |
| <code><a href="#hup">HUP</a></code>, and |
| <code><a href="#graceful">USR1</a></code>, which |
| will be described in a moment.</p> |
| |
| <p>To send a signal to the parent you should issue a command |
| such as:</p> |
| |
| <example>kill -TERM `cat /usr/local/apache2/logs/httpd.pid`</example> |
| |
| <p>The second method of signaling the <code>httpd</code> processes |
| is to use the <code>-k</code> command line options: <code>stop</code>, |
| <code>restart</code>, and <code>graceful</code>, |
| as described below. These are arguments to the <a |
| href="programs/httpd.html">httpd</a> binary, but we recommend that |
| you send them using the <a |
| href="programs/apachectl.html">apachectl</a> control script, which |
| will pass them through to <code>httpd</code>.</p> |
| |
| <p>After you have signaled <code>httpd</code>, you can read about |
| its progress by issuing:</p> |
| |
| <example>tail -f /usr/local/apache2/logs/error_log</example> |
| |
| <p>Modify those examples to match your <directive |
| module="core">ServerRoot</directive> and <directive |
| module="mpm_common">PidFile</directive> settings.</p> |
| </section> |
| |
| <section id="term"><title>Stop Now</title> |
| |
| <dl><dt>Signal: TERM</dt> |
| <dd><code>apachectl -k stop</code></dd> |
| </dl> |
| |
| <p>Sending the <code>TERM</code> or <code>stop</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.</p> |
| </section> |
| |
| <section id="graceful"><title>Graceful Restart</title> |
| |
| <dl><dt>Signal: USR1</dt> |
| <dd><code>apachectl -k graceful</code></dd> |
| </dl> |
| |
| <p>The <code>USR1</code> or <code>graceful</code> signal causes |
| the parent process to <em>advise</em> 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 <em>generation</em> of the |
| configuration, which begins serving new requests immediately.</p> |
| |
| <note>On certain platforms that do not allow <code>USR1</code> to |
| be used for a graceful restart, an alternative signal may be used (such |
| as <code>WINCH</code>). The command <code>apachectl graceful</code> |
| will send the right signal for your platform.</note> |
| |
| <p>This code is designed to always respect the process control |
| directive of the MPMs, so the number of processes and threads |
| available to serve clients will be maintained at the appropriate |
| values throughout the restart process. Furthermore, it respects |
| <directive module="mpm_common">StartServers</directive> in the |
| following manner: if after one second at least <directive |
| module="mpm_common">StartServers</directive> new children have not |
| been created, then create enough to pick up the slack. Hence the |
| code tries to maintain both the number of children appropriate for |
| the current load on the server, and respect your wishes with the |
| <directive>StartServers</directive> parameter.</p> |
| |
| <p>Users of the <module>mod_status</module> |
| will notice that the server statistics are <strong>not</strong> |
| 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 |
| <em>scoreboard</em> used to keep track of all children across |
| generations.</p> |
| |
| <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> |
| |
| <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.</p> |
| |
| <note>If your configuration file has errors |
| in it when you issue a restart then your parent will not |
| restart, it will exit with an error. In the case of graceful |
| restarts it will also leave children running when it exits. |
| (These are the children which are "gracefully exiting" by |
| handling their last request.) This will cause problems if you |
| attempt to restart the server -- it will not be able to bind to |
| its listening ports. Before doing a restart, you can check the |
| syntax of the configuration files with the <code>-t</code> |
| command line argument (see <a |
| href="programs/httpd.html">httpd</a>). This still will not |
| guarantee that the server will restart correctly. To check the |
| semantics of the configuration files as well as the syntax, you |
| can try starting <code>httpd</code> as a non-root user. If there are no |
| errors it will attempt to open its sockets and logs and fail |
| because it's not root (or because the currently running <code>httpd</code> |
| already has those ports bound). If it fails for any other |
| reason then it's probably a config file error and the error |
| should be fixed before issuing the graceful restart.</note> |
| </section> |
| |
| <section id="hup"><title>Restart Now</title> |
| |
| <dl><dt>Signal: HUP</dt> |
| <dd><code>apachectl -k restart</code></dd> |
| </dl> |
| |
| <p>Sending the <code>HUP</code> or <code>restart</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> |
| |
| <p>Users of <module>mod_status</module> |
| will notice that the server statistics are set to zero when a |
| <code>HUP</code> is sent.</p> |
| |
| <note>If your configuration file has errors in it when you issue a |
| restart then your parent will not restart, it will exit with an |
| error. See above for a method of avoiding this.</note> |
| </section> |
| |
| <section id="race"><title>Appendix: signals and race conditions</title> |
| |
| <p>Prior to Apache 1.2b9 there were several <em>race |
| conditions</em> 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> |
| |
| <p>Architectures that use an on disk <directive |
| module="mpm_common">ScoreBoardFile</directive> have the potential |
| to corrupt their scoreboards. This can result in the "bind: |
| Address already in use" (after <code>HUP</code>) or "long lost |
| child came home!" (after <code>USR1</code>). The former is a fatal |
| error, while the latter just causes the server to lose a |
| scoreboard slot. So it might be advisable to use graceful |
| restarts, with an occasional hard restart. These problems are very |
| difficult to work around, but fortunately most architectures do |
| not require a scoreboard file. See the <directive |
| module="mpm_common">ScoreBoardFile</directive> documentation for a |
| architecture uses it.</p> |
| |
| <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. </p> |
| </section> |
| |
| </manualpage> |