<manualpage metafile="stopping.xml.meta">
- <title>Stopping and Restarting</title>
+ <title>Stopping and Restarting Apache HTTP Server</title>
<summary>
- <p>This document covers stopping and restarting Apache on
+ <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 Apache as a
+ <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 Apache as a
+ href="platform/windows.html#wincons">Running httpd as a
Console Application</a> for information on how to control
- Apache on those platforms.</p>
+ httpd on those platforms.</p>
</summary>
<seealso><program>httpd</program></seealso>
<section id="introduction"><title>Introduction</title>
- <p>In order to stop or restart Apache, you must send a signal to
+ <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
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>
+ <directive module="mpm_common">StartServers</directive>
parameter.</p>
<p>Users of <module>mod_status</module>
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
+ 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
<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
+ 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
+ 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
+
+ <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
+ 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
+ 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 others files.</p>
+ 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