Bug 23034
Summary: | UCD SNMP agent hangs, eats 99% CPU for several minutes | ||||||
---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Mario Lorenz <ml> | ||||
Component: | ucd-snmp | Assignee: | Phil Knirsch <pknirsch> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Brock Organ <borgan> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 6.2 | CC: | jem, rvokal | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2002-01-31 19:06:58 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Mario Lorenz
2000-12-30 19:34:26 UTC
I've actually experienced similar issues on the following releases: 6.2, 7.0, 7.1 beta. It appears that the SNMP daemon would listen, run through the first part of the MIB, then timeout before moving on to the host section. After that, any queries to the tree would timeout. I'd have to restart the daemon and try again. Oddly, removing the RPM, then re-installing cured the troubles. *Note: The config file was identical in all setups. Could you give the current rawhide version a try and see if that fixes the problem? We had several problems reported related to snmpwalk and a fix has now been included. Thanks, Read ya, Phil I tried again with the rawhide package (4.2.1-2). I had to recompile, because I didnt know where to find libcrypto.so.2 (since when is openssl at major 2 ?) The problem persists tho. I still see the timeouts with the configuration as stated above. Except that its now a bit faster to respond again (thats most likely because I upgraded my hardware). stracing the process reveals a lot of activity in accessing /var/lib/rpm related files, stats, read, etc. so it seems that it indeed walks all the time through the whole internal RPM MIB to see that it isnt actually allowed to dish out the info, as per the view configuration. This seems to take long enough to make the client timeout. So I am not sure if there is an easy fix at all..... Hmmm.. I am currently still trying to reproduce the problem locally here, but without success. Could you send me your snmpd.conf file so that i can try to reproduce it locally here? Otherwise i have a real hard time fixing this problem. It might even be fixed with the latest and greates package (ucd-snmp-4.2.1-7). Read ya, Phil OK, I just checked. 4.2.1-7 doesnt exhibit the problem, because 4.2.1-7 does not include the RPM query support, and thats due to the librpm check is AGAIN BROKEN (see #23033). (want me to reopen 23033 or open a new bug on that ?) It seems the RPM guys have split librpm again, and this time librpmdb needs to be linked (and added to the check) Without the RPM functions, the bug doesnt occcur - see above. As for the configuration, all you really need is the snmpd.conf snipped in the original bugreport (see above) and add the com2sec etc. so that you define t1group. then a simple snmpwalk (see above) most likely will show the problem, however due to lack of time I havent tested that yet. Mario Could you give the latest version from rawhide a try? It's based on 4.2.3 now which has quite a few fixes included. Thanks, Read ya, Phil Created attachment 44176 [details]
Sample Config
Nope, the new 4.2.3-4 RPMs do NOT fix the problem. It is still the same. Since it seems you are not able to reproduce this, I have attached my snmpd.conf Put it into /etc/snmp/snmpd.conf, restart snmpd, then do this: snmpwalk localhost public -> snmp mib gets walked, all works snmpwalk localhost t1 -> snmp mib walks all the way to snmp.snmpEnableAuthenTraps, then your snmpwalk will (well, it does here) time out, and snmpd will run for quite some time with 99% CPU utilization. After checking the net-snmp devel mailinglists this seems to be a know issue and is not likely to be fixed anytime for the 4.x release, so the only way to fix it is to either only query the OID's you're really interessted in or to increase the timeout of the snmpwalk command. Read ya, Phil *** Bug 63332 has been marked as a duplicate of this bug. *** |