Bug 23034 - UCD SNMP agent hangs, eats 99% CPU for several minutes
UCD SNMP agent hangs, eats 99% CPU for several minutes
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: ucd-snmp (Show other bugs)
6.2
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Phil Knirsch
Brock Organ
:
: 63332 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-12-30 14:34 EST by Mario Lorenz
Modified: 2015-03-04 20:08 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-01-31 14:06:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Sample Config (2.76 KB, text/plain)
2002-01-31 14:00 EST, Mario Lorenz
no flags Details

  None (edit)
Description Mario Lorenz 2000-12-30 14:34:26 EST
UCD SNMP as included with RedHat 6.2, as well as in 7.0 after fixing Bug
#23033 has a
problem walking the MIB with the hosts tree hidden.
Consider this snmpd.conf excerpt:

view    t1view        included             .1            
view    t1view        excluded            
.iso.org.dod.internet.mgmt.mib-2.host

access t1group  ""       any        noauth     prefix   t1view  t1view  
t1view

A snmpwalk (v1, community t1, mapped to t1group) will walk through the
regular mib-2,
and then time out when it  would hit the host mib (where it doesnt have
access for)

By that time, snmpd is hung and consumes 99% CPU for several minutes.
Comment 1 John E. Martin 2001-03-22 13:34:10 EST
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.
Comment 2 Phil Knirsch 2001-07-19 09:40:48 EDT
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
Comment 3 Mario Lorenz 2001-07-23 16:19:32 EDT
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.....
Comment 4 Phil Knirsch 2001-11-07 10:42:46 EST
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
Comment 5 Mario Lorenz 2001-11-07 12:06:37 EST
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
Comment 6 Phil Knirsch 2002-01-29 09:07:01 EST
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
Comment 7 Mario Lorenz 2002-01-31 14:00:19 EST
Created attachment 44176 [details]
Sample Config
Comment 8 Mario Lorenz 2002-01-31 14:06:52 EST
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.

Comment 9 Phil Knirsch 2002-06-25 12:08:41 EDT
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
Comment 10 Phil Knirsch 2002-06-25 12:09:12 EDT
*** Bug 63332 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.