mirror of
https://github.com/apache/httpd.git
synced 2025-06-04 21:42:15 +03:00
b68721ed3a
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@102617 13f79535-47bb-0310-9956-ffa450edef68
226 lines
10 KiB
XML
226 lines
10 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"?>
|
|
|
|
<!--
|
|
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>
|