Red Hat Bugzilla – Bug 205627
add --enable-exception-hook to apache build
Last modified: 2007-11-30 17:07:33 EST
Description of problem:
add --enable-exception-hook to configure options
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. none, part of build process
not able to use exception-hook
able to use exception-hook
As far as I can tell, --enable-exception-hook does not cause any performance
slowdowns or other issues and is dis-abled in the httpd.conf by default.
We are currently running into a problem with httpd segfaulting and dumping core.
( in RHEL3 ). We wanted to use mod_whatkilledus (
http://people.apache.org/~trawick/mod_whatkilledus.c ) to help debug the
problem. whatkilledus requires --enable-exception-hook. I can see this helping
others in the future with similar problems.
I'm not really convinced about this feature.
Use of mod_log_forensic (which is already shipped in RHEL) is a far safer and
more reliable method to obtain request context from intermittently segfaulting
children, and I'd rather encourage that (or improve it as necessary, if there is
some context which mod_whatkilledus reports which log_forensic misses).
For us apache segfaulted once per day or two. If we had used mod_log_forensic
on our entire web server farm we would have had massive amounts of additional
logs to deal with. Where mod_whatkilledus would log only the entry we needed.
I'm not advocating adding mod_whatkilledus.c to the RHEL build , just
--enable-exception-hook. That would allow mod_whatkilledus or any other module
needing the hook to be easily added later by the local admin.
But I don't have to support it for every RHEL user :)
either way, thanks.
I do think this feature is flawed in principle, which is really why I don't want
to support it in RHEL, although I appreciate its utility. When doing post-crash
analysis, to get the most reliable results it's essential to analyse the process
state as close to the point at which it crashed as possible. This means letting
the process dump core ASAP and analysing that core dump "after the fact".
Attempting to run more code in process after the segfault occurs is inherently
risky because it inevitably *changes* the process state.
As ever - thanks for the request.