Re: [exim] debugging problems with transport_filter

Etusivu
Poista viesti
Vastaa
Lähettäjä: Adam D. Barratt
Päiväys:  
Vastaanottaja: Ross Boylan
Kopio: exim
Aihe: Re: [exim] debugging problems with transport_filter
On Mon, 2011-09-26 at 10:16 -0700, Ross Boylan wrote:
> Observations on the trace below:
> "R=filter_test T=easy_test defer (-24): transport filter process failed
> (2) while writing to /home/ross/mailutil/mbox" made me think the issue
> was actually in writing to the mbox. I think the actual error was in
> running the filter. Is that correct?


At least in exim 4.72, that message is produced by a block of code
starting:

/* Handle a process failure while writing via a filter; the return
from child_close() is in more_errno. */

  else if (errno == ERRNO_FILTER_FAIL)
    {
    yield = PANIC;


indicating that child_close() returned "2". -24 is -EMFILE, also known
as "too many open files".

> "appendfile yields 10 with errno=-24 more_errno=2"? Could someone help
> me interpret that? What do the 10, -24, and 2 mean in general--that is,
> what kind of things do they indicate, and what do the specific values
> mean in this case?


10 is "PANIC" ("Hard failed with internal error"), from src/macros.h;
see the above code snippet. In terms of error numbers, assuming a Linux
kernel (which as you mentioned Debian lenny is a reasonable assumption),
see /usr/include/asm-generic/errno{-base,}.h, which would yield -EMFILE
as above.

exim's own spec.txt indicates that a positive return value from
child_close is simply the exit status from the child - in this case
presumably your python process. Again, if it's using standard error
numbers then "2" is ENOENT, or "no such file or directory". It's
probably easier for you to work out why your script would be returning
that, though. :-)

For what it's worth, other than an educated guess that "errno" was a
"standard" error number, particularly given that it was negative, the
remainder of the above was derived from a few minutes grepping of the
exim source.

Regards,

Adam