Re: [exim] Exim drops core size

Top Page
Delete this message
Reply to this message
Author: Eli
Date:  
To: exim-users
Subject: Re: [exim] Exim drops core size
> 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).


Dealing with purely Exim over the past 8 years or so I've been using it,
I've yet to have the need to actually show anyone a core dump. During the
times that I have had odd behavior and other such problems, simply
mentioning where the problem seemed to happen allowed people to rather
quickly pinpoint the potential area problem in the source code - no core
dump required.

There may indeed be times in production when an unforeseen error does come
up, though I think in my *entire life* dealing with Linux, I have sent off
(I don't know how to "use" a core dump despite knowing how to program fairly
well, and also being quite adept at debugging my own problems) a total of
perhaps 1-2 core dumps at most, ever. I think one of those was for the
kernel :) My point: requiring a core dump is pretty slim from my point of
view.

> 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.


Ah, I see - so why doesn't he diagnose the code in the program that's
crashing? If he knows how to use a core dump (and I'm assuming as much
since he's asking for one), surely he can try other debugging methods if
he's not able to produce a core dump? Also, if a new program is being
forked, I would assume that he should be able to set core settings for that
program? Run it through a shell script that sets up his ulimits perhaps (no
need to answer this for me - just mentioning potential solutions)?

> 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.


I know - and that was my reason for replying. I don't think we need a patch
to have some sort of toggle for causing a core dump /at runtime/. If
there's not such a thing already in the source code so that it can be
enabled at compile time, then sure - by all means, but I still firmly
believe we don't need any runtime patches for this.

Eli.