Just curious, what happens if you change the exit(APEXIT_CHILDFATAL) to
clean_child_exit(APEXIT_CHILDFATAL)? I'm not sure what that would
cause, but just off the cuff I'd aim for a clean exit when one is possible.
-- Dave
On 2/3/2011 5:40 AM, Hannes Landeholm wrote:
It happened again. After some research I found out what the problem is:
experimental/peruser/peruser.c:614
if (rv != APR_SUCCESS) {
const char *msg = "couldn't grab the accept mutex";
if (ap_my_generation !=
ap_scoreboard_image->global->running_generation)
{
ap_log_error(APLOG_MARK, APLOG_DEBUG, rv, NULL, msg);
clean_child_exit(0);
}
else {
ap_log_error(APLOG_MARK, APLOG_EMERG, rv, NULL, msg);
exit(APEXIT_CHILDFATAL);
}
}
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. In the mean time I will fix
this by commenting it out like this:
/*if (ap_my_generation !=
ap_scoreboard_image->global->running_generation)
{*/
ap_log_error(APLOG_MARK, APLOG_DEBUG, rv, NULL, msg);
clean_child_exit(0);
/*}
else {
ap_log_error(APLOG_MARK, APLOG_EMERG, rv, NULL, msg);
exit(APEXIT_CHILDFATAL);
}*/
Hannes
On 25 January 2011 15:48, Hannes Landeholm <[email protected]
<mailto:[email protected]>> wrote:
Good. :) It must have been some exceptionally rare condition...
Hannes
On 25 January 2011 15:20, Janno Sannik <[email protected]
<mailto:[email protected]>> wrote:
This should be common to all mpm's. Not just peruser. Something
went horribly wrong so it seems and recovery doesn't seem an option.
On 25.01.2011 15:37, Hannes Landeholm wrote:
FYI got this very unusual error just after reloading apache
configuration:
As you can see the whole apache server was brought down just
because I child returned a fatal error. That dangerous and
exploitable reaction should be removed IMO. Childs should
NEVER be able to stop the entire server. If they return a
fatal error they should promptly be killed and replaced.
Regards,
Hannes
_______________________________________________
Peruser mailing list
[email protected] <mailto:[email protected]>
http://www.telana.com/mailman/listinfo/peruser
_______________________________________________
Peruser mailing list
[email protected] <mailto:[email protected]>
http://www.telana.com/mailman/listinfo/peruser
_______________________________________________
Peruser mailing list
[email protected]
http://www.telana.com/mailman/listinfo/peruser
--
Dave Steinberg
http://www.geekisp.com/
http://www.steinbergcomputing.com/
http://www.redterror.net/
_______________________________________________
Peruser mailing list
[email protected]
http://www.telana.com/mailman/listinfo/peruser
