Hello everybody, we are currently migrating our squid 2.7 installation to 3.2 and facing some SNMP related problems. We are using squid 3.2.6 on FreeBSD 9.1-amd64 and our system is fully IPv6 enabled. Using the following configuration: workers 2 snmp_port 163 snmp_access allow all Cache.log reports: 2013/01/18 01:38:21 kid2| Sending SNMP messages from [::]:163 2013/01/18 01:38:21 kid1| Sending SNMP messages from [::]:163 2013/01/18 01:38:21 kid1| Accepting SNMP messages on [::]:163 2013/01/18 01:38:25 kid2| Accepting SNMP messages on [::]:163 Every SNMP query fails: % snmpwalk -v2c -c public 127.0.0.1:163 1.3.6.1.4.1.3495 Timeout: No Response from 127.0.0.1:163 And cache.log reports: 2013/01/18 01:38:46 kid2| snmpHandleUdp: FD 15 recvfrom: (35) Resource temporarily unavailable 2013/01/18 01:38:47 kid1| snmpHandleUdp: FD 15 recvfrom: (35) Resource temporarily unavailable (note that trying to query 'UDP6:[::1]':163 would result squid worker crashes and restarts, but let's leave that out for now) Changing the configuration to: workers 2 snmp_port 163 snmp_incoming_address 127.0.0.1 snmp_access allow all Would result successful SNMP queries: % snmpget -v2c -c public 127.0.0.1:163 1.3.6.1.4.1.3495.1.1.1.0 SNMPv2-SMI::enterprises.3495.1.1.1.0 = INTEGER: 460 And cache.log would report just one line per SNMP query: 2013/01/18 02:20:26 kid1| snmpHandleUdp: FD 15 recvfrom: (35) Resource temporarily unavailable In both cases, every SNMP adds two or new stale entries (filedescriptors, sockets or whatever) as reported by lsof: # lsof -i -nP | egrep 'PID|:163$' COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME squid 5007 squid 15u IPv4 0xfffffe0006b14790 0t0 UDP 127.0.0.1:163 squid 5008 squid 15u IPv4 0xfffffe0006b14790 0t0 UDP 127.0.0.1:163 squid 5008 squid 19u IPv4 0xfffffe0006b14790 0t0 UDP 127.0.0.1:163 squid 5008 squid 41u IPv4 0xfffffe0006b14790 0t0 UDP 127.0.0.1:163 (and the list gets longer and longer as our monitoring systems keep quering squid..). Everything (SNMP-related) works correctly when we use just one worker but currently this is no option since a single squid 3.2 worker seems to be unable to handle as many requests as squid 2.7 (in our case at least). Any feedback would be greatly appreciated. Thanks, Panagiotis -- Panagiotis J. Christias Network Management Center P.Christias@xxxxxxxxxxx National Technical Univ. of Athens, GREECE
