Re: [exim-dev] Exim issues with shadow_transport

On 2008-09-26 at 21:19 +1000, Ted Cooper wrote:
> Phil Pennock wrote:
> > On 2008-09-26 at 03:12 -0700, Phil Pennock wrote:
> >> FWIW, and this is likely *not* the cause of your ALRM problems, it
> >> appears that there's an undocumented (but intuitively sensible, if you
> >> think about it) constraint that you can't use
> >> return_output/return_fail_output on shadow transports.
> >
> > In transport.c:transport_write_block(), shouldn't there be a
> > "sigalrm_seen = FALSE" before the "alarm(local_timeout);" on line 234
> > (per rev 1.21) so that if a previous alarm's SIGALRM was issued, we
> > don't fail out immediately?
>
> It seems to be a global var and so is set to FALSE before the function
> is called (line 765 of transports/pipe.c)
> I don't see why it can't be set to FALSE before the call, but it might
> not make any difference to the problem. When the error occurs and
> changes the value of sigalrm_seen, the entire function returns FALSE and
> the value of the variable is never checked again.

Right, and when the function is called again?

Eg, when sending a bounce message, the return value of
transport_write_message() is not checked and if multiple recipients
failed, the loop is called multiple times, so you can go into this with
sigalrm_seen set TRUE.

This won't create spurious SIGALRM so isn't the problem source, but will
have Exim think it hasn't returned a message when it has.

For this, you'd have to have reached the timeout on a connection
already, so the odds are that things are dead anyway. So it's unlikely
to be making things worse. Especially since you'd have to be accepting
and then generating bounces.

I haven't tracked down all the callers of transport_write_block
transport_write_string transport_write_message so haven't seen if there
are other instances. It's probably best just to reset to clean state.

Hideous packet loss to colo box, ending mail terse and stopping looking
at Exim invocation paths.

-Phil