Bill Stoddard wrote: > > > If the parent dies, shouldn't the children get the equivalent > > of SIGPIPE on the pod? However they find out, they should react > > appropriately -- i.e., by committing suicide with extreme prejudice. > > -1 in concept. We should not take the child processes down if > the parent process dies a horrible unplanned death. The way it > is now, the sysadmin can at least set MaxRequestsPerChild to 0 > and keep child processes up to handle requests.
That needs to be done before [re]starting, however. Once the parent is dead, there's no way to control the children short of directly signalling them -- which we have formally decried for years. And if the directive isn't set before the children were created, you can't tell them to use the new value. :-) Setting MaxRequestsPerChild to avoid this is a bogus band-aid. > I know of at least one case where a big site running Apache on > Solaris occasionally has the parent process die (funny enough, > I only see this on Solaris with 1.3). The problem happens so > infrequently, that it is difficult to debug. So far, it is > impossible to reliably recreate. If we caused the entire site > to go down when the parent dies, the owners of this big site > would be, umm, upset, to say the least. As it is, the sys admin > has a little time to identify that the parent has died and > properly recycle the server. I think I disagree; what you're describing is, essentially, relying on good luck, hoping for the best, and ignoring the problem and hoping it will go away. IIRC, what Greg observed was the children getting hung at some time t after the parent died. (Maybe when they tried to expire gracefully?) IMHO, if the parent process dies, something is seriously wrong, the server condition is indeterminate, and we need to re-base and restart. Consider this: Suppose that site had an automatic monitor that detected when the main Apache process died. If the children reliably died as well, it could simply restart the server, or page someone to do it, or the like. If the children DON'T die automatically, something or someone has to do a manual search-and-destroy on them before the server can be restarted. > For the most part, the people hitting the site never know > anything went wrong. And that's the way it should be. I agree with the sentiment, but leaving the children running uncontrollably after the parent has died is not an option I consider viable. What precedents are there? What happens to inetd-started sessions if inetd dies, for instance? > > Bill -- #ken P-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millenium hand and shrimp!"
