Re: Apache Service Control

[Q Beukes]

Thanks for your quick response. Nick Kew wrote: To restart the process you need to send a HUP signal. This works fine, but what if you want to stop the server for a moment and then start it again, perhaps doing something in the mean while. This cannot be automated unless you watch the process/PID in some way. You could send it SIGKILL and take the consequences. Not that I'd recommend that! There are various techniques you can use for scripting a shutdown: for example, polling it. With polling it I figure you just mean something along the lines of a "kill -0" to see if it's still running. So is there (when sending a TERM signal) some shutdown processes that can fail and cause Apache to abort the shutdown? This is fine for most purposes, but what if you want to stop what you're doing in case the shutdown fails. If the "httpd" binary would return a non-negative exit code Return a code to whom? Basically like "if ! httpd -k stop; then --failed--; fi". These are just some issues people have. Some people feel it's a bad design. Why? Simply because you can't determine for certain if the shutdown was successful or not, and to restart apache you have to rely on the restart signal or uncertain timeouts. Some people (like me) are not so sure what the idea behind it is. To give the workers time to finish serving current requests rather than aborting them. I understand this yes. This question was more along the lines of whether or not there is a reason one just sends and waits, or not IPC which returns only later or any one of the methods daemons can use to shutdown. We're open to patches if you have a better design. The design seems fine. Perhaps just some mechanism to track the shutdown? Or a command line switch to block the process until shutdown completed? With some guidance and advice I would be more than willing to implement something. Q Beukes