From: dgaudet Date: Sun, 27 Apr 1997 07:45:00 +0000 (+0000) Subject: Deal with EINTR while processing scoreboard file. Fix graceful restart X-Git-Tag: APACHE_1_2b9~2 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=8c4d270fd08fcd57c863658ec05502fc9f78459e;p=apache 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 0cb67f515d..e333deb851 100644 --- a/docs/manual/stopping.html +++ b/docs/manual/stopping.html @@ -57,11 +57,6 @@ set to zero when a HUP is sent.

Note: prior to release 1.2b9 this code is quite unstable and shouldn't be used at all. -

Note: Architectures that use an on disk ScoreBoardFile are not supported -on graceful restarts. See the ScoreBoardFile documentation for a method -to determine if your architecture uses a file. -

The USR1 signal causes the parent process to advise 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. -

Architectures that use an on disk ScoreBoardFile 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. +

Architectures that use an on disk +ScoreBoardFile +have the potential to corrupt their scoreboards. This can result in +the "bind: Address already in use" (after HUP) or +"long lost child came home!" (after USR1). 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 0cb67f515d..e333deb851 100644 --- a/docs/manual/stopping.html.en +++ b/docs/manual/stopping.html.en @@ -57,11 +57,6 @@ set to zero when a HUP is sent.

Note: prior to release 1.2b9 this code is quite unstable and shouldn't be used at all. -

Note: Architectures that use an on disk ScoreBoardFile are not supported -on graceful restarts. See the ScoreBoardFile documentation for a method -to determine if your architecture uses a file. -

The USR1 signal causes the parent process to advise 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. -

Architectures that use an on disk ScoreBoardFile 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. +

Architectures that use an on disk +ScoreBoardFile +have the potential to corrupt their scoreboards. This can result in +the "bind: Address already in use" (after HUP) or +"long lost child came home!" (after USR1). 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.