> Perhaps Exim should have a knob to let people re-enable core-dumps for > deliveries, on a per-transport basis. Patches welcome.
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.
Not to say that everyone should have the ability to have a development system/environment, but I just believe that the select few that encounter problems of a magnitude that require low-level program debugging should not require a "program feature" to allow them to debug the code (beyond "exim -d" that is). Debugging shouldn't need to be done very often, and as such I believe that a source code #define switch (for example) should be sufficient for those that do require low-level debugging.
I personally strip all my binaries (in fact, some distros may auto-strip on install I believe), plus I don't have debugging libraries, so I couldn't debug even if I wanted to. Such a set up I don't think is too uncommon for a production environment, and having a scriptable toggle to try and allow for core dumps would just be silly and useless in such a scenario.
To be honest, if Jorg is having a problem that's causing Exim to crash and he's that intent on trying to solve the problem, re-compiling a debug-able version of Exim to try and reproduce the crash with a core dump (and whatever else he could do such as tracing the execution) would be the "right" direction. If he would prefer to be able to debug/examine core dumps whenever he would like, then he should probably just run a debug-enabled Exim binary all the time; I don't believe any runtime toggles should be necessary.
