Red Hat Bugzilla – Bug 205627
add --enable-exception-hook to apache build
Last modified: 2007-11-30 17:07:33 EST
Description of problem: (enhancement) add --enable-exception-hook to configure options Version-Release number of selected component (if applicable): httpd-2.2.3-4 How reproducible: always Steps to Reproduce: 1. none, part of build process 2. 3. Actual results: not able to use exception-hook Expected results: able to use exception-hook Additional info: 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.