mirror of
https://github.com/apache/httpd.git
synced 2025-07-29 12:37:06 +00:00
69c1a5c854
Trim trailing whitespace... no func change git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1174747 13f79535-47bb-0310-9956-ffa450edef68
232 lines
11 KiB
XML
232 lines
11 KiB
XML
<?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>
|