Commit 7bfdb649 authored by dgaudet's avatar dgaudet
Browse files

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
parent 9cd36b7f
Loading
Loading
Loading
Loading
+9 −10
Original line number Diff line number Diff line
@@ -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.

+9 −10
Original line number Diff line number Diff line
@@ -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.