Loading docs/manual/stopping.html +9 −10 Original line number Diff line number Diff line Loading @@ -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 Loading Loading @@ -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. Loading docs/manual/stopping.html.en +9 −10 Original line number Diff line number Diff line Loading @@ -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 Loading Loading @@ -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. Loading Loading
docs/manual/stopping.html +9 −10 Original line number Diff line number Diff line Loading @@ -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 Loading Loading @@ -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. Loading
docs/manual/stopping.html.en +9 −10 Original line number Diff line number Diff line Loading @@ -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 Loading Loading @@ -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. Loading