From 8c4d270fd08fcd57c863658ec05502fc9f78459e Mon Sep 17 00:00:00 2001 From: dgaudet Date: Sun, 27 Apr 1997 07:45:00 +0000 Subject: [PATCH] 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 --- docs/manual/stopping.html | 19 +++++++++---------- docs/manual/stopping.html.en | 19 +++++++++---------- 2 files changed, 18 insertions(+), 20 deletions(-) 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. -- 2.50.1