Point things at the stopping/restarting document.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@78007 13f79535-47bb-0310-9956-ffa450edef68

5 files changed, 21 insertions, 17 deletions

diff --git a/docs/manual/invoking.html b/docs/manual/invoking.html
index 8134e72072..7534bc055f 100644
--- a/docs/manual/invoking.html
+++ b/docs/manual/invoking.html
@@ -92,8 +92,9 @@ On daemon startup, it saves the process id of the parent httpd process to
 the file <code>logs/httpd.pid</code>. This filename can be changed with the
 <A HREF="mod/core.html#pidfile">PidFile</A> directive. The process-id is for
 use by the administrator in restarting and terminating the daemon;
-A HUP signal causes the daemon to re-read its configuration files and
-a TERM signal causes it to die gracefully.
+A HUP or USR1 signal causes the daemon to re-read its configuration files and
+a TERM signal causes it to die gracefully.  For more information
+see the <a href="stopping.html">Stopping and Restarting</a> page.
 <p>
 If the process dies (or is killed) abnormally, then it will be necessary to
 kill the children httpd processes.
diff --git a/docs/manual/invoking.html.en b/docs/manual/invoking.html.en
index 8134e72072..7534bc055f 100644
--- a/docs/manual/invoking.html.en
+++ b/docs/manual/invoking.html.en
@@ -92,8 +92,9 @@ On daemon startup, it saves the process id of the parent httpd process to
 the file <code>logs/httpd.pid</code>. This filename can be changed with the
 <A HREF="mod/core.html#pidfile">PidFile</A> directive. The process-id is for
 use by the administrator in restarting and terminating the daemon;
-A HUP signal causes the daemon to re-read its configuration files and
-a TERM signal causes it to die gracefully.
+A HUP or USR1 signal causes the daemon to re-read its configuration files and
+a TERM signal causes it to die gracefully.  For more information
+see the <a href="stopping.html">Stopping and Restarting</a> page.
 <p>
 If the process dies (or is killed) abnormally, then it will be necessary to
 kill the children httpd processes.
diff --git a/docs/manual/mod/mod_proxy.html b/docs/manual/mod/mod_proxy.html
index 0332ee6e6c..107041fc49 100644
--- a/docs/manual/mod/mod_proxy.html
+++ b/docs/manual/mod/mod_proxy.html
@@ -199,7 +199,7 @@ was supplied with the document.
 <strong>Context:</strong> server config<br>
 <strong>Status:</strong> Base<br>
 <strong>Module:</strong> mod_proxy<br>
-<strong>Compatibility:</strong> CacheLastModified is only available in
+<strong>Compatibility:</strong> CacheLastModifiedFactor is only available in
 Apache 1.1 and later.<p>
 
 If the origin HTTP server did not supply an expiry date for the
diff --git a/docs/manual/stopping.html b/docs/manual/stopping.html
index 84db932246..0cb67f515d 100644
--- a/docs/manual/stopping.html
+++ b/docs/manual/stopping.html
@@ -57,6 +57,11 @@ set to zero when a <code>HUP</code> is sent.
 <p><b>Note:</b> prior to release 1.2b9 this code is quite unstable and
 shouldn't be used at all.
 
+<p><b>Note:</b> Architectures that use an on disk <a
+href="mod/core.html#scoreboardfile">ScoreBoardFile</a> are not supported
+on graceful restarts.  See the ScoreBoardFile documentation for a method
+to determine if your architecture uses a file.
+
 <p>The <code>USR1</code> signal causes the parent process to <i>advise</i>
 the children to exit after their current request (or to exit immediately
 if they're not serving anything).  The parent re-reads its configuration
@@ -64,11 +69,6 @@ files and re-opens its log files.  As each child dies off the parent
 replaces it with a child from the new <i>generation</i> of the
 configuration, which begins serving new requests immediately.
 
-<p>Architectures that use an on disk <a
-href="mod/core.html#scoreboardfile">ScoreBoardFile</a> are not supported
-on graceful restarts.  See the ScoreBoardFile documentation for a method
-to determine if your architecture uses it.
-
 <p>This code is designed to always respect the
 <a href="mod/core.html#maxclients">MaxClients</a>,
 <a href="mod/core.html#minspareservers">MinSpareServers</a>,
@@ -114,7 +114,8 @@ certain architectures.
 
 <p>Architectures that use an on disk <a
 href="mod/core.html#scoreboardfile">ScoreBoardFile</a> have the potential
-to corrupt their scoreboards whenever a signal is received.  It is
+to corrupt their scoreboards whenever a signal is received (by the
+parent or children).  It is
 possible for the server to forget about some children when this happens.
 See the ScoreBoardFile documentation for a method to determine if your
 architecture uses it.
diff --git a/docs/manual/stopping.html.en b/docs/manual/stopping.html.en
index 84db932246..0cb67f515d 100644
--- a/docs/manual/stopping.html.en
+++ b/docs/manual/stopping.html.en
@@ -57,6 +57,11 @@ set to zero when a <code>HUP</code> is sent.
 <p><b>Note:</b> prior to release 1.2b9 this code is quite unstable and
 shouldn't be used at all.
 
+<p><b>Note:</b> Architectures that use an on disk <a
+href="mod/core.html#scoreboardfile">ScoreBoardFile</a> are not supported
+on graceful restarts.  See the ScoreBoardFile documentation for a method
+to determine if your architecture uses a file.
+
 <p>The <code>USR1</code> signal causes the parent process to <i>advise</i>
 the children to exit after their current request (or to exit immediately
 if they're not serving anything).  The parent re-reads its configuration
@@ -64,11 +69,6 @@ files and re-opens its log files.  As each child dies off the parent
 replaces it with a child from the new <i>generation</i> of the
 configuration, which begins serving new requests immediately.
 
-<p>Architectures that use an on disk <a
-href="mod/core.html#scoreboardfile">ScoreBoardFile</a> are not supported
-on graceful restarts.  See the ScoreBoardFile documentation for a method
-to determine if your architecture uses it.
-
 <p>This code is designed to always respect the
 <a href="mod/core.html#maxclients">MaxClients</a>,
 <a href="mod/core.html#minspareservers">MinSpareServers</a>,
@@ -114,7 +114,8 @@ certain architectures.
 
 <p>Architectures that use an on disk <a
 href="mod/core.html#scoreboardfile">ScoreBoardFile</a> have the potential
-to corrupt their scoreboards whenever a signal is received.  It is
+to corrupt their scoreboards whenever a signal is received (by the
+parent or children).  It is
 possible for the server to forget about some children when this happens.
 See the ScoreBoardFile documentation for a method to determine if your
 architecture uses it.