Deal with EINTR while processing scoreboard file. Fix graceful restart

for scoreboard files.

Reviewed by:	Randy, Roy
Submitted by:
Obtained from:

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

diff --git a/docs/manual/stopping.html b/docs/manual/stopping.html
index 0cb67f515d4b4a93e83488f38d0467040f8d8ca0..e333deb851f06dd4291bd66ff5a98a487a67d3ea 100644 (file)
--- a/docs/manual/stopping.html
+++ b/docs/manual/stopping.html
@@ -57,11 +57,6 @@ 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
@@ -112,11 +107,15 @@ 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 whenever a signal is received (by the
-parent or children).  It is
-possible for the server to forget about some children when this happens.
+<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 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 0cb67f515d4b4a93e83488f38d0467040f8d8ca0..e333deb851f06dd4291bd66ff5a98a487a67d3ea 100644 (file)
--- a/docs/manual/stopping.html.en
+++ b/docs/manual/stopping.html.en
@@ -57,11 +57,6 @@ 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
@@ -112,11 +107,15 @@ 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 whenever a signal is received (by the
-parent or children).  It is
-possible for the server to forget about some children when this happens.
+<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 ScoreBoardFile documentation for a method to determine if your
 architecture uses it.