On 2009-03-30 at 12:23 -0400, Eli wrote: > Just my two cents on this whole topic... Very few people know what to
> do with a core dump; even fewer even know what a core dump is. Out of
> the few that know what a core dump is AND how to use it for debugging
> purposes, I hope that none of them are 1) running debug code on a
> production machine, 2) debugging programs on a production machine, and
> 3) need a simple "knob" to enable core dumps (or any other low-level
> debugging routines) on a production machine.
Unfortunately the real world doesn't like clean and simple and
reproducible. Sometimes, the only place you see a problem is in
production and you need to get a core-dump from there to let you figure
out what's going wrong (and improve whatever test set-up you have so
that you can catch it pre-production in future).
> To be honest, if Jorg is having a problem that's causing Exim to crash
No, he's having a problem where the program invoked for a transport
delivery is crashing and Exim's sanitisation is interfering with this
ability to get diagnostic information back.
While I disagree with Jorg that Exim should not interfere with
core-dumps by default -- in part because of how few people know how to
deal with a core-dump (but the painkillers mean that I couldn't find a
way to say it tactfully without insulting all of exim-users) -- I do
think that a production system needs a way to let you in to capture
core-dumps from prod -- this is not unreasonable and it was slightly
surprising to me to see that Exim doesn't already have a knob for this.
So I pointed Jorg at where in the code the problem was and I would be in
favour of seeing a new transport option permit_coredump to solve this
more cleanly. My "patches welcome" was serious, not sarcastic.
