-- 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
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
