Re: [exim] Connection not timing out

Top Page
Delete this message
Reply to this message
Author: Michael Fischer v. Mollard
Date:  
To: exim-users
Subject: Re: [exim] Connection not timing out


-- Am 03/21/16 21:23:12 +0100 schrieb Heiko Schlittermann:

> Hi,
>
> (please no CC offlist, I'm here.)


sorry for that.

> Michael Fischer v. Mollard <lists@???> (Mo 21 Mär 2016
> 18:03:49 CET):
>
> Do you have any traces of the delivery attempt of 29077/29079 from
> the remote site? Did the mail get through twice?
>
> Can you use a `strace -p` on the delivery and on the transport process
> next time?


other PIDs, but same situation:
# strace -p 18619
Process 18619 attached
select(8, [7], NULL, NULL, {17, 252791}) = 0 (Timeout)
wait4(-1, 0x7ffe6b2aef8c, WNOHANG, NULL) = 0
select(8, [7], NULL, NULL, {60, 0})     = 0 (Timeout)
wait4(-1, 0x7ffe6b2aef8c, WNOHANG, NULL) = 0
select(8, [7], NULL, NULL, {60, 0})     = 0 (Timeout)
wait4(-1, 0x7ffe6b2aef8c, WNOHANG, NULL) = 0
select(8, [7], NULL, NULL, {60, 0}^CProcess 18619 detached
 <detached ...>


with
exim4     18619            root    0u      CHR                1,3      0t0 
1034 /dev/null
exim4     18619            root    1u      CHR                1,3      0t0 
1034 /dev/null
exim4     18619            root    2u      CHR                1,3      0t0 
1034 /dev/null
exim4     18619            root    3r      CHR                1,9      0t0 
1039 /dev/urandom
exim4     18619            root    4uw     REG              253,0   134167 
1795 /var/spool/exim4/input/1aiHUQ-0004q8-Lq-D
exim4     18619            root    5w      REG              253,0      176 
1649 /var/spool/exim4/msglog/1aiHUQ-0004q8-Lq
exim4     18619            root    6w      REG              253,0        0 
1827 /var/spool/exim4/input/1aiHUQ-0004q8-Lq-J
exim4     18619            root    7r     FIFO                0,8      0t0 
98772157 pipe


and
# strace -p 18622
Process 18622 attached
recvfrom(7, ^CProcess 18622 detached
<detached ...>

with no changes waiting for tcp traffic:

exim4     18622     Debian-exim    0u      CHR                1,3      0t0 
1034 /dev/null
exim4     18622     Debian-exim    1u      CHR                1,3      0t0 
1034 /dev/null
exim4     18622     Debian-exim    2u      CHR                1,3      0t0 
1034 /dev/null
exim4     18622     Debian-exim    3r      CHR                1,9      0t0 
1039 /dev/urandom
exim4     18622     Debian-exim    4u      REG              253,0   134167 
1795 /var/spool/exim4/input/1aiHUQ-0004q8-Lq-D
exim4     18622     Debian-exim    5w      REG              253,0      176 
1649 /var/spool/exim4/msglog/1aiHUQ-0004q8-Lq
exim4     18622     Debian-exim    6w      REG              253,0        0 
1827 /var/spool/exim4/input/1aiHUQ-0004q8-Lq-J
exim4     18622     Debian-exim    7u     IPv4           98772160      0t0 
TCP XXXX:41992->YYYY:smtp (ESTABLISHED)
exim4     18622     Debian-exim    8w     FIFO                0,8      0t0 
98772157 pipe


> I'm asking this, because some time ago we observed communication
> problems between the smtp transport process and its parent (here 29079
> talking back to 29077). If I remember well, the trigger were a long list
> of recipients plus some lengthy TLS information.
>
> I think, for us it resulted in crashing deliveries, but I can imagine
> hanging deliveries too.


TLS might be a good point. On the receiving side is see a bunch off

30977 handling TLS incoming connection from XXX

so I'll try to disable TLS between the external and internal gateways. I'll
post whether this changed the situation.

Regards
     Michael