Hi misc@,
while testing the to be released 4.1 I found a problem with the
snmpd daemon (package is net-snmp-5.1.3p5).
Trying, from another machine a command like this:
snmptable -c public -v 1 1.2.3.4 HOST-RESOURCES-MIB::hrSWRunTable
where 1.2.3.4 is the ip address of the OpenBSD server, the snmpd daemon
hangs eating all the cpu it can find.
I tried running the daemon as:
snmpd -d -D -f -q -u nobody -g nobody
to see the debug output. The last lines are
snmp_agent: tp->start HOST-RESOURCES-MIB::hrSWRunType, tp->end
HOST-RESOURCES-MIB::hrSWRunStatus,
trace: netsnmp_add_varbind_to_cache(): snmp_agent.c, 1806:
snmp_agent: add_vb_to_cache(0x87eab780, 7,
HOST-RESOURCES-MIB::hrSWRunStatus, 0x872d2180)
trace: snmp_call_callbacks(): callback.c, 176:
callback: START calling callbacks for maj=1 min=12
trace: snmp_call_callbacks(): callback.c, 184:
callback: calling a callback for maj=1 min=12
trace: vacm_in_view(): mibII/vacm_vars.c, 747:
mibII/vacm_vars: vacm_in_view: ver=0, community=public
trace: netsnmp_udp_getSecName(): snmpUDPDomain.c, 744:
netsnmp_udp_getSecName: resolve <"public", 0x2d06bc0a>
trace: netsnmp_udp_getSecName(): snmpUDPDomain.c, 749:
netsnmp_udp_getSecName: compare <"public", 0x4a0110ac/0xffffffff>... nope
trace: netsnmp_udp_getSecName(): snmpUDPDomain.c, 749:
netsnmp_udp_getSecName: compare <"public", 0x2c05bc0a/0xffffffff>... nope
trace: netsnmp_udp_getSecName(): snmpUDPDomain.c, 749:
netsnmp_udp_getSecName: compare <"public", 0x2d06bc0a/0xffffffff>...
SUCCESS
trace: netsnmp_subtree_find_first(): agent_registry.c, 156:
subtree: looking for subtree for context: ""
trace: netsnmp_subtree_find_first(): agent_registry.c, 160:
subtree: found one for: ""
trace: vacm_in_view(): mibII/vacm_vars.c, 854:
mibII/vacm_vars: vacm_in_view: sn=anonymousSecName002,
gn=anonymousGroupName002, vn=anonymousView002
trace: vacm_checkSubtree(): vacm.c, 526:
vacm:checkSubtree: , included
trace: snmp_call_callbacks(): callback.c, 196:
callback: END calling callbacks for maj=1 min=12 (1 called)
trace: netsnmp_add_varbind_to_cache(): snmp_agent.c, 1871:
snmp_agent: tp->start HOST-RESOURCES-MIB::hrSWRunStatus, tp->end
HOST-RESOURCES-MIB::hrSWRunEntry.8,
trace: netsnmp_call_handlers(): agent_handler.c, 443:
handler:calling: main handler bulk_to_next
trace: netsnmp_call_handler(): agent_handler.c, 381:
handler:calling: calling handler bulk_to_next for mode GETNEXT
trace: netsnmp_call_handler(): agent_handler.c, 381:
handler:calling: calling handler old_api for mode GETNEXT
trace: header_hrswrunEntry(): host/hr_swrun.c, 378:
host/hr_swrun: var_hrswrunEntry: HOST-RESOURCES-MIB::hrSWRunIndex 0
(index 20 (entry #1) ....HOST-RESOURCES-MIB::hrSWRunIndex
saved
at this time there is no other output and the daemon is running at full
speed.
The same happens on another 4.1 so I don't think it's hw related.
# dmesg | head -2
OpenBSD 4.1-current (GENERIC) #1466: Fri Apr 6 01:36:13 MDT 2007
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
# snmpd -v
NET-SNMP version: 5.1.3
Web: http://www.net-snmp.org/
Email: net-snmp-coders@lists.sourceforge.net
Any ideas?
D.
| Rafael J. Wysocki | 2.6.28-rc3-git6: Reported regressions from 2.6.27 |
| Rafael J. Wysocki | [Bug #11207] VolanoMark regression with 2.6.27-rc1 |
| Matthew Wilcox | [PATCH] Fix boot-time hang on G31/G33 PC |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
git: | |
| Jon Smirl | ! [rejected] master -> master (non-fast forward) |
| Jon Smirl | Packfile can't be mapped |
| Sverre Rabbelier | Git vs Monotone |
| Shawn O. Pearce | libgit2 - a true git library |
| Richard Stallman | Real men don't attack straw men |
| GVG GVG | ssh_exchange_identification: Connection closed by remote host |
| Douglas A. Tutty | OBSD's perspective on SELinux |
| Girish Venkatachalam | Ethernet jumbo frames? |
| Volker Armin Hemmann | build error with 2.6.27.6+reiser4+ehci-hub patch. ERROR: "mii_ethtool_gset" [drive... |
| Michael Grollman | Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945... |
| Evgeniy Polyakov | [resend take 2 0/4] Distributed storage. |
| Krzysztof Halasa | Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC |
