Re: [exim] Connection not timing out

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Heiko Schlittermann
Fecha:  
A: exim-users
Asunto: Re: [exim] Connection not timing out
Michael Fischer v. Mollard <lists@???> (Di 22 Mär 2016 11:02:13 CET):
>
>
> 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 ...>


Looks like the loop in src/deliver.c in function par_wait(), around line
3603. Waiting for any subprocess or (primarily) for the deliver status
from the subprocess.

There doesn't seem to be implemented a global timeout, this is probably
done in the transports/smtp.c…

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


It's not easy to tell who (which function) is calling this recvfrom(). I
suppose, it's inside the TLS connection handling, and hidden from any
"external" timeout catchers.

Is it possible to have a tcpdump watching the connection and then, if
the error re-occurs, to filter out the stream?

I'd like at which stage of conversation it hangs.


> 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


Unfortunately it's not visible how much they talked to each other
already.

Using an acl condion

    condition = <to be forwarded to the internal host>
    control = debug/tag=.foo/opts=+all


would help too.


--
Heiko