1 files changed, 0 insertions, 193 deletions
diff --git a/docs/manual/stopping.html b/docs/manual/stopping.html
deleted file mode 100644
index eb6502574a..0000000000
--- a/docs/manual/stopping.html
+++ /dev/null
@@ -1,193 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Stopping and Restarting the Server</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-<H1 ALIGN="CENTER">Stopping and Restarting the Server</H1>
-
-<P>This document covers stopping and restarting Apache on Unix-like
-systems. Windows users should see <A
-HREF="platform/windows.html#signal">Signalling Apache when
-running</A>.</P>
-
-<P>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 <A HREF="mod/core.html#pidfile">PidFile</A>.  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>TERM</CODE>, <CODE>HUP</CODE>, and <CODE>USR1</CODE>, which will
-be described in a moment.
-
-<P>To send a signal to the parent you should issue a command such as:
-<BLOCKQUOTE><PRE>
-    kill -TERM `cat /usr/local/apache/logs/httpd.pid`
-</PRE></BLOCKQUOTE>
-
-You can read about its progress by issuing:
-
-<BLOCKQUOTE><PRE>
-    tail -f /usr/local/apache/logs/error_log
-</PRE></BLOCKQUOTE>
-
-Modify those examples to match your
-<A HREF="mod/core.html#serverroot">ServerRoot</A> and
-<A HREF="mod/core.html#pidfile">PidFile</A> settings.
-
-<p>A shell script called <a
-href="programs/apachectl.html">apachectl</a> is provided which
-automates the processing of signalling Apache.  For details about this
-script, see the documentation on <a href="invoking.html">starting
-Apache</a>.</p>
-
-<H3>Stop Now</h3>
-
-<p><strong>Signal:</strong> TERM<br>
-<code>apachectl stop</code></p>
-
-<P>Sending the <CODE>TERM</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.
-
-<H3>Graceful Restart</H3>
-
-<p><strong>Signal:</strong> WINCH<br>
-<code>apachectl graceful</code></p>
-
-<P>The <CODE>WINCH</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 <A
-HREF="mod/mpm_common.html#maxclients">MaxClients</A>, <A
-HREF="mod/prefork.html#minspareservers">MinSpareServers</A>, and <A
-HREF="mod/prefork.html#maxspareservers">MaxSpareServers</A>
-settings.  Furthermore, it respects <A
-HREF="mod/mpm_common.html#startservers">StartServers</A> in the
-following manner: if after one second at least StartServers new
-children have not been created, then create enough to pick up the
-slack.  This is to say that the code tries to maintain both the number
-of children appropriate for the current load on the server, and
-respect your wishes with the StartServers parameter.</p>
-
-<P>Users of the
-<A HREF="mod/mod_status.html">status module</A>
-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>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>At present there is no way for a log rotation script using
-<CODE>WINCH</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>WINCH</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><STRONG>Note:</STRONG> 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 httpd
-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 httpd 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.
-
-
-<H3>Restart Now</H3>
-
-<p><strong>Signal:</strong> HUP<br>
-<code>apachectl restart</code></p>
-
-<P>Sending the <CODE>HUP</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>Users of the
-<A HREF="mod/mod_status.html">status module</A>
-will notice that the server statistics are
-set to zero when a <CODE>HUP</CODE> is sent.
-
-<P><STRONG>Note:</STRONG> 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 below for a method of avoiding this.
-
-
-<H3>Appendix: signals and race conditions</H3>
-
-<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>Architectures that use an on disk
-<A HREF="mod/core.html#scoreboardfile">ScoreBoardFile</A>
-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 <a HREF=
-"mod/core.html#scoreboardfile">ScoreBoardFile</a> documentation for a
-architecture uses it.
-
-<P><CODE>NEXT</CODE> and <CODE>MACHTEN</CODE> (68k only) have small race
-conditions
-which can cause a restart/die signal to be lost, but should not cause the
-server to do anything otherwise problematic.
-<!-- they don't have sigaction, or we're not using it -djg -->
-
-<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.
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>