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_at_noc.ntua.gr National Technical Univ. of Athens, GREECEReceived on Fri Jan 18 2013 - 00:42:11 MST
This archive was generated by hypermail 2.2.0 : Fri Jan 18 2013 - 12:00:04 MST