We are using net-snmpd version 5.0.7 on Linux. We
have the agent configured to proxy several subtrees to
another agent. When we attempt to walk a proxied
section of the mib tree, we can cause snmpd to 'hang'.
It will not process any further SNMP requests, and
cannot be killed with a SIGTERM.
A little investigation reveals that the last value returned
from the select() call in receive()s main processing loop
snmpd.c is 2, whereas every previous call to select()
returned 1.
Here's a stack trace taken while the daemon was 'hung':
-----------------------------------------------------
#0 0x0faf81ac in recvfrom () from /lib/libc.so.6
#1 0x0fca8b4c in recvfrom () from /lib/libpthread.so.0
#2 0x0ffb902c in netsnmp_udp_recv (t=0x10061e60,
buf=0x100696c0, size=65536,
opaque=0x7fffe980, olength=0x7fffe984)
at /work6/wes.bemont/work/product/sp/snmp/snmplib/sn
mpUDPDomain.c:107
#3 0x0ff9f2f0 in _sess_read (sessp=0x10061888,
fdset=0x7fffea08)
at /work6/wes.bemont/work/product/sp/snmp/snmplib/sn
mp_api.c:5264
#4 0x0ff9fb6c in snmp_sess_read (sessp=0x10061888,
fdset=0x7fffe8d4)
at /work6/wes.bemont/work/product/sp/snmp/snmplib/sn
mp_api.c:5478
#5 0x0ff9e9bc in snmp_read (fdset=0x7fffea08)
at /work6/wes.bemont/work/product/sp/snmp/snmplib/sn
mp_api.c:5090
#6 0x100032d8 in receive ()
at /work6/wes.bemont/work/product/sp/snmp/agent/snm
pd.c:1112
#7 0x10002af0 in main (argc=7, argv=0x7ffffcf4)
at /work6/wes.bemont/work/product/sp/snmp/agent/snm
pd.c:913
#8 0x0fa44dbc in __libc_start_main () from /lib/libc.so.6
-----------------------------------------------------