mirror of
https://github.com/apache/httpd.git
synced 2026-10-25 10:59:28 +03:00
4f1d428f25
reached. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@264737 13f79535-47bb-0310-9956-ffa450edef68
269 lines
13 KiB
XML
269 lines
13 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$ -->
|
|
|
|
<!--
|
|
Copyright 2002-2005 The Apache Software Foundation or its licensors, as
|
|
applicable.
|
|
|
|
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><program>httpd</program></seealso>
|
|
<seealso><program>apachectl</program></seealso>
|
|
|
|
<section id="introduction"><title>Introduction</title>
|
|
|
|
<p>In order to stop or restart Apache, 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 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 <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>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 <program>httpd</program>). 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.</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="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 Apache, 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 the <directive module="core">Lockfile</directive> and <directive
|
|
module="mod_cgid">ScriptSock</directive> files contain the server
|
|
PID, and should co-exist 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 others 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>
|
|
|
|
|
|
<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 simply put,
|
|
a race condition is a time-sensitive problem - if something happens
|
|
at just the wrong time or things happen in the wrong order,
|
|
undesired behaviour will result. If the same thing happens at the right
|
|
time, all will be well). For those architectures that have the "right"
|
|
feature set we have eliminated as many as we can. But it should
|
|
be noted that race conditions do still exist on certain
|
|
architectures.</p>
|
|
|
|
<p>Architectures that use an on-disk <directive
|
|
module="mpm_common">ScoreBoardFile</directive> can potentially have
|
|
their scoreboards corrupted. 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 may 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
|
|
architecture which 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>
|