On 2/04/2013 11:26 p.m., Pavel Bychykhin wrote:
Hi All!
My system is FreeBSD 9.0
My SQUID ver. is 3.2.9.
Recently i tried to define some rules for the client delay pools.
Here part from my config:
acl to_rfc1579 dst 192.168.0.0/16
acl to_rfc1579 dst 10.0.0.0/8
acl to_rfc1579 dst 172.16.0.0/12
client_delay_pools 1
client_delay_parameters 1 16384 16384
client_delay_access 1 allow all !to_rfc1579
After that Squid died, and i see in log:
2013/04/02 10:48:56 kid1| ACL::checklistMatches WARNING: 'to_rfc1579'
ACL is used but there is no HTTP request -- not matching
2013/04/02 10:48:56 kid1| assertion failed: cbdata.cc:463: "c->locks > 0"
If you are able to run Squid in a debugger I'm very interested in seeing
a stack trace from that assertion.
Is it a bug, or i just don't understand something about an access lists.
Both. Assert is always a bug and the client_delay_pool operates right
after the TCP SYN is accept()'ed.
client_delay_access is tested as soon as the TCP SYN packet has been
accepted. All Squid has for ACLs to work with at that point is the
IP:port of each end of the client TCP connection.
client_delay_access can be used with: src, arp, localip / myip,
localport / myport.
"myportname" ACL should in theory work as well, but looking at the
code I see the required details are not yet passed to the ACL code
properly so that is broken.
The dst ACL is for testing the destination IP address an HTTP request
might be going to. It requires an HTTP request URL to locate a domain
name then DNS to locate the IP addresses.
Amos
