On 30/12/2020 13:20, Victor Sudakov via Exim-users wrote:
In my situation, I set net.inet.tcp.fastopen.client_enable=0 on the client (exim host) and it cured the problem.
Good to know. It's a workaround, not a fix, IMO.
I could probably have set net.inet.tcp.fastopen.server_enable=1 on the server side (clamd host) and it would cure the problem too?
It's worth trying. However, a TFO implementation is *required* to operate properly talking to a non-TFO peer.
Jeremy, I did not quite understand if the whole problem is a bug in FreeBSD
This.
or a bug in Exim, or both, but if I can provide any help or additional info/testing to clear the situation once and for all, I'd be glad to.
If you could get a run with the original configuration, but with debug enabled (command-line "-d+all") on the exim that ends up calling out to Clam, that will help to locate that "close(-1)" we saw. If that's the exim daemon: - Check using "ps" for any extra args normally used on your exim daemon process - stop the exim service - run # exim -d+all -bd 2>&1 | tee logfile to get a daemon with debug. -- Cheers, Jeremy -- ## 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/
