Re: [exim] Batch SMTP hangs

Inizio della pagina
Delete this message
Reply to this message
Autore: John Hall
Data:  
To: Exim Users list
CC: Geraint Edwards
Oggetto: Re: [exim] Batch SMTP hangs
On 09/08/05, Geraint Edwards <gedge-lists@???> wrote:
> I've been busy of late, so my analysis has not been as thorough
> as I had hoped, so apologies if the below is brief.
>
> John Hall <john.d.hall@???> said
>                 (on Wed, Jul 13, 2005 at 04:06:30PM +0100):
> > I have a perl script that runs as a pipe transport and injects two
> > e-mails back into the system via BSMTP. Up until a recent upgrade from
> > Woody to Sarge this all worked fine.

>
> Did exim get bumped from to 4.51 at that time? You could
> possibly do
>
>         grep 'daemon started' /var/log/exim/mainlog*

>
> to get version numbers/dates for daemon versions.


No - I build exim myself from source (and end up using equivs :().

> About a week after an upgrade to 4.51, I noticed things not
> working properly (mail was often sent, but...).
>
> The close on the pipe just hung. Namely, the perl:
>
>         close(MAIL) or croak "..."

>
> never returned. So the inbound delivery (triggering the above
> code to send an outbound mail) *eventually* fell over as follows:
>
> 2005-07-22 15:47:25 1DvXs5-000n6s-I9 ** |/usr/sbin/listreq foo <foo-request@???> R=into_list T=address_pipe: pipe delivery process timed out
>
> This happened several times, so I took the opportunity (ahem!) to
> rewrite the mail submission part of the code using perl's
> Net::SMTP module. This problem seemed to occur elsewhere - not
> just for these (list-generated) mails. So, the following may be
> related - my hunch is that it is.
>
> I've since upgraded to exim 4.52 - but I still get a lot of ugliness.
> Inbound deliveries work OK, locally-generated mail to local sites
> is OK, but mail to remote sites (typically using mutt) seems to
> follow this pattern:


<snip>

I've now upgraded to 4.52 and it all seems to be working fine again. I
sadly do not really have the time to debug further (hence my slowness in
replying to this e-mail). It's not satisfactory, I know.

regards,
John