Hi Amos,
thank you so much for your reply. I was starting to suspect that the
cause was located somewhere outside Squid or its config.
Is this happening at times of unusually high client connections
through the NAT?
Is eCAP processing blocking the Squid worker for all those seconds?
I was only able to reproduce the issue by provoking multiple
long-running ecap transactions by curl-ing a certain .deb file. In my
little test setup, there was not much of other client traffic (only
one client with an open browser). The eCAP Adapter uses poll to wait
for the response of a virus scanner on a unix domain socket, so yes, I
assume this blocks the worker. I will probably have to look into Async
operation with regard to this issue.
That part is likely to be the issue recently worked around by
Thanks for the patch, I will definitely try it, this will already go a
long way to help mitigate the problem.
Kind regards,
Andreas
Zitat von Amos Jeffries <squid3@xxxxxxxxxxxxx>:
On 24/02/22 12:05, Andreas Weigel wrote:
Hi everyone,
I had the following issue with Squid in Transparent Mode (and SSL
Interception in mode splice). It is working as expected, however
after multiple long-running (talking about several seconds)
anti-virus ecap-Processes have finished, I *sometimes* get the
following in the log:
2022/02/23 14:56:40.668 kid1| 5,2| src/comm/TcpAcceptor.cc(224)
doAccept: New connection on FD 21
2022/02/23 14:56:40.668 kid1| 5,2| src/comm/TcpAcceptor.cc(312)
acceptNext: connection on local=[::]:2412 remote=[::] FD 21 flags=41
2022/02/23 14:56:40.668 kid1| 89,5| src/ip/Intercept.cc(405)
Lookup: address BEGIN: me/client= 192.168.180.1:2412,
destination/me= 192.168.180.10:48582
2022/02/23 14:56:40.668 kid1| ERROR: NF getsockopt(ORIGINAL_DST)
failed on local=192.168.180.1:2412 remote=192.168.180.10:48582 FD
37 flags=33: (2) No such file or directory
2022/02/23 14:56:40.669 kid1| 89,9| src/ip/Intercept.cc(151)
NetfilterInterception: address: local=192.168.180.1:2412
remote=192.168.180.10:48582 FD 37 flags=33
2022/02/23 14:56:40.669 kid1| ERROR: NAT/TPROXY lookup failed to
locate original IPs on local=192.168.180.1:2412
remote=192.168.180.10:48582 FD 37 flags=33
These can happen if the NAT table entries expire or otherwise get
dropped by conntrack between the client initiating TCP SYN and Squid
accept(2) receiving the connection.
Your config looks good to me and the lack of regularity indicates
the issue is likely this type of transient state situation.
Is this happening at times of unusually high client connections
through the NAT?
Is eCAP processing blocking the Squid worker for all those seconds?
2022/02/23 14:56:40.669 kid1| 5,5| src/comm/TcpAcceptor.cc(287)
acceptOne: non-recoverable error: FD 21, [::] [ job2] handler
Subscription: 0x55edac3d08d0*1
Sometimes, this only appears on on of the two interception ports,
sometimes on both. After that, the squid worker does not poll the
intercept listen port any longer, i.e. stops working.
That part is likely to be the issue recently worked around by
<http://www.squid-cache.org/Versions/v6/changesets/squid-6-9fd3e68c3d0dfd6035db98ce142cf425be6c5fc1.patch>
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
