Hi, Good to know.
Since the check makes the child exit gracefully if the parent server generation is different, doesn't that indicate that they do indeed expect this problem in this particular case? Maybe the problem is that peruser children doesn't share any memory so the parent server generation info becomes out of sync in the children which makes the check always compare equal although the server generation has in fact incremented? Even if it isn't supposed to happen, how does it justify crashing the server with a fatal error? Why not just shut down the child and try again? As I said, this condition seem to be expected in some cases anyway. And I still don't like the idea that the children can signal the main process to exit with a crash. This makes denial of service possible if you have found an exploit that allows you to control signal/exit code of the child process in a certain processors, affecting other separate processors. Hannes On 3 February 2011 15:21, Taavi Sannik <[email protected]> wrote: > On 3.02.2011 12:40, Hannes Landeholm wrote: > >> Can someone please explain why the child proceeds to take down the entire >> server by exiting with a fatal error if it can't grab the accept mutex and >> the child generation is the same as the running generation? Whoever wrote >> this must have been stoned. >> > > Hello! > > Peruser is somewhat based on the prefork MPM (which is the basically most > simple MPM ever). A lot of code you see in peruser.c is in fact from > prefork. If you look at the original prefork code (line 196 at > http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/prefork/prefork.c?revision=1057045&view=markup< > http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/prefork/prefork.c?revision=1057045&view=markup>), > you can see it behaves the same way. > > I think the actual problem is that it should NEVER fail to accept the > mutex. I think we had the same issue sometime and setting "AcceptMutex > flock" in the configuration file fixed the problem. > > > -- > Taavi Sannik > DataCode OY > > _______________________________________________ > Peruser mailing list > [email protected] > http://www.telana.com/mailman/listinfo/peruser >
_______________________________________________ Peruser mailing list [email protected] http://www.telana.com/mailman/listinfo/peruser
