| <?xml version='1.0' encoding='UTF-8' ?> |
| <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd"> |
| <?xml-stylesheet type="text/xsl" href="./style/manual.en.xsl"?> |
| <!-- $LastChangedRevision$ --> |
| |
| <!-- |
| Licensed to the Apache Software Foundation (ASF) under one or more |
| contributor license agreements. See the NOTICE file distributed with |
| this work for additional information regarding copyright ownership. |
| The ASF licenses this file to You 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 Apache HTTP Server</title> |
| |
| <summary> |
| <p>This document covers stopping and restarting Apache HTTP Server on |
| Unix-like systems. Windows NT, 2000 and XP users should see |
| <a href="platform/windows.html#winsvc">Running httpd as a |
| Service</a> and Windows 9x and ME users should see <a |
| href="platform/windows.html#wincons">Running httpd as a |
| Console Application</a> for information on how to control |
| httpd on those platforms.</p> |
| </summary> |
| |
| <seealso><program>httpd</program></seealso> |
| <seealso><program>apachectl</program></seealso> |
| <seealso><a href="invoking.html">Starting</a></seealso> |
| |
| <section id="introduction"><title>Introduction</title> |
| |
| <p>In order to stop or restart the Apache HTTP Server, you must send a signal to |
| the running <program>httpd</program> 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 <program>httpd</program> 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 four signals that you can send the parent: |
| <code><a href="#term">TERM</a></code>, |
| <code><a href="#graceful">USR1</a></code>, |
| <code><a href="#hup">HUP</a></code>, and |
| <code><a href="#gracefulstop">WINCH</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 <program>httpd</program> processes |
| is to use the <code>-k</code> command line options: <code>stop</code>, |
| <code>restart</code>, <code>graceful</code> and <code>graceful-stop</code>, |
| as described below. These are arguments to the <program> |
| httpd</program> binary, but we recommend that |
| you send them using the <program>apachectl</program> control script, which |
| will pass them through to <program>httpd</program>.</p> |
| |
| <p>After you have signaled <program>httpd</program>, 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> |
| |
| <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 module="mpm_common">StartServers</directive> |
| parameter.</p> |
| |
| <p>Users of <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> |
| <p>When you issue a restart, a syntax check is first run, to |
| ensure that there are no errors in the configuration files. |
| If your configuration file has errors in it, you will get an |
| error message about that syntax error, and the server will refuse to |
| restart. This avoids the situation where the server halts and then |
| cannot restart, leaving you with a non-functioning server.</p> |
| |
| <p>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 <program>httpd</program> 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 |
| <program>httpd</program> 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.</p></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>As with a graceful restart, a syntax check is run before the |
| restart is attempted. If your configuration file has errors in it, the |
| restart will not be attempted, and you will receive notification of the |
| syntax error(s).</note> |
| </section> |
| |
| <section id="gracefulstop"><title>Graceful Stop</title> |
| |
| <dl><dt>Signal: WINCH</dt> |
| <dd><code>apachectl -k graceful-stop</code></dd> |
| </dl> |
| |
| <p>The <code>WINCH</code> or <code>graceful-stop</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 will then remove its <directive |
| module="mpm_common">PidFile</directive> and cease listening on |
| all ports. The parent will continue to run, and monitor children |
| which are handling requests. Once all children have finalised |
| and exited or the timeout specified by the <directive |
| module="mpm_common">GracefulShutdownTimeout</directive> has been |
| reached, the parent will also exit. If the timeout is reached, |
| any remaining children will be sent the <code>TERM</code> signal |
| to force them to exit.</p> |
| |
| <p>A <code>TERM</code> signal will immediately terminate the |
| parent process and all children when in the "graceful" state. However |
| as the <directive module="mpm_common">PidFile</directive> will |
| have been removed, you will not be able to use |
| <code>apachectl</code> or <code>httpd</code> to send this signal.</p> |
| |
| <note><p>The <code>graceful-stop</code> signal allows you to run multiple |
| identically configured instances of <program>httpd</program> at the |
| same time. This is a powerful feature when performing graceful |
| upgrades of httpd, however it can also cause deadlocks and race |
| conditions with some configurations.</p> |
| |
| <p>Care has been taken to ensure that on-disk files such as lock files |
| (<directive module="core">Mutex</directive>) and Unix socket files |
| (<directive module="mod_cgid">ScriptSock</directive>) contain the server |
| PID, and should coexist without problem. However, if a configuration |
| directive, third-party module or persistent CGI utilises any other on-disk |
| lock or state files, care should be taken to ensure that multiple running |
| instances of <program>httpd</program> do not clobber each other's files.</p> |
| |
| <p>You should also be wary of other potential race conditions, such as |
| using <program>rotatelogs</program> style piped logging. Multiple running |
| instances of <program>rotatelogs</program> attempting to rotate the same |
| logfiles at the same time may destroy each other's logfiles.</p></note> |
| </section> |
| |
| </manualpage> |