Bug 205627
| Summary: | add --enable-exception-hook to apache build | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Christopher McCrory <chrismcc> |
| Component: | httpd | Assignee: | Joe Orton <jorton> |
| Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.0 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-04-11 12:39:32 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Christopher McCrory
2006-09-07 17:55:29 UTC
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. |