-- Am 03/22/16 12:27:05 +0100 schrieb Heiko Schlittermann:
>
> 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.
Sorry, but that's not possible at the moment due to load and privacy
concerns.
>> 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.
I just had an example for which I could examine at the internal host - it
tries to communicate with fsecure via the socket, so it should be in the
DATA ACL. This should not take longer than final_timeout. Btw: Disabling
TLS between internal and external host seemed to be a good idea as the
number of long hanging connections seem to decrease.
Sorry for the weird stuff
Michael
