Description of problem: This is probably a duplicate of 82146. I tried to add a comment here, but Bugzilla told me I was trying to change the Component field from AfterStep-APPS to net-snmp and that I wasn't privileged enough. Hmm. My apologies for the DUPL. Not to rehash and old problem, but I'm having the exact same problem. I've got a base Red Hat Linux 9 system with net-snmp-5.0.6. I can start the daemon, but snmpwalk (or an external snmp walking program) either returns partial output and then kills the listener (Timeout: No Response from localhost) or consumes the CPU ~95%, with the logs (snmpd -D -l /var/log/snmpd.log ..etc) showing an infinate loop when viewed with tail -f. It appears that this bug has existed since RHL7.2, in v4.2.3. Is this going to be fixed? Is there any way to use this service if it repeatedly crashes? The tool I'm using to query SNMP data needs to be able to walk the tree to discover the device. If there is a place in /etc/snmp/snmpd.conf to change 'system' to '.1', I'll do it (the host is RO and behind a firewall) except that I can't pinpoint where this change is to be made. Any further assistance you can provide would be greatly appreciated. Thanks for your time. Version-Release number of selected component (if applicable): net-snmp-5.0.6-17 How reproducible: Everytime Steps to Reproduce: 1.Install RH (7.2-9.0) with the corresponding package containing snmpd. 2. Run '/etc/rc.d/init.d/snmpd start' 3. Run 'snmpwalk -v 1 localhost -c public system Actual results: top shows the snmpd process at ~95%. System no longer responds to snmp queries. Expected results: snmp should run and respond and not kill the box. Additional info: I have seen this bug many places spanning many versions. I'm having a tough time grasping that this (seemingly basic) problem has gone uncorrected for so long.
Hi! As described in the other bug reports, this is a know problem with the upstream code and is not likely to be fixed in the near future. In order to make it at least responsive again look for the view systemview included lines and append the following line: view systemview included .1 That should prevent the snmpd running amok. Btw: the system recovers after a few minutes, then snmpd goes back to idle state and can receive new requests. :-) Read ya, Phil *** This bug has been marked as a duplicate of 82146 ***
view systemview included .1 Worked like a charm. You da man, thanks so much for clearing that up for me. Have a good one!
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.