Bug 241581

Summary: RHEL4U5 GA : snmpwalk takes 10 to 12 mins to traverse mib-2 tree
Product: Red Hat Enterprise Linux 4 Reporter: Narendra K <narendra_k>
Component: net-snmpAssignee: Jan Safranek <jsafrane>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: urgent    
Version: 4.6CC: jfeeney, palliv, pb, rainer.traut, rvokal, wwlinuxengineering
Target Milestone: ---Keywords: ZStream
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: RHBA-2007-0738 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-11-15 16:00:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 246028, 251132    
Description Flags
The snmpd.conf file used to configure snmpd agent
the snmpd log /var/log/snmpd.log
the /var/log/messages log file
patch for this bug none

Description Narendra K 2007-05-28 10:18:05 UTC
Description of problem: When the mib-2 tree is walked on RHEL4 U5 GA, it takes 
anywhere between 7 to 12 mins, with the default "-Lsd -Lf /dev/null -
p /var/run/snmpd.pid -a" option to snmpd. If "-Lsd" option is not supplied it 
takes 10 to 12 seconds to walk the tree. The following messages are found many 
times in /var/log/messages.
        snmpd[15029]: Connection from -
        snmpd[15029]: transport socket = 12

Version-Release number of selected component (if applicable):

kernel version : 2.6.9-55.ELsmp

How reproducible: Often

Steps to Reproduce:

1.Install RHEL4 Update 5 GA.
2.Add the following line to /etc/snmp/snmpd.conf:
  view    all    included    .1
3.Change the "access" line in /etc/snmp/snmpd.conf to:
 access    notConfigGroup    ""    any    noauth    exact    all    none    
4. Run "service snmpd start" to start snmpd.
5. Run "date; snmpwalk -v1 -c public localhost mib-2 >snmpwalk.log; date" to 
walk MIB-II and timestamp the start and end of the walk. 

Actual results: It takes about 7 to 12 mins to walk the tree

Expected results: It should take about 10 to 12 seconds.

Additional info :

If *.info string is removed from /etc/syslog.conf snmpwalk on mib-2 tree takes 
10 to 12 seconds. The same behaviour is observed on x86_64 architecture also.

Comment 1 Narendra K 2007-05-28 10:18:05 UTC
Created attachment 155534 [details]
The snmpd.conf file used to configure snmpd agent

Comment 2 Narendra K 2007-05-28 10:26:52 UTC
Created attachment 155535 [details]
the snmpd log /var/log/snmpd.log

Comment 3 Narendra K 2007-05-28 10:34:00 UTC
Created attachment 155536 [details]
the /var/log/messages log file

Comment 4 Jan Safranek 2007-05-29 13:42:19 UTC
This is already fixed upstream - the second log line is not produced in newer
versions of snmpd -> syslogd cuts the first log line to 'last message repeated
533 times'.

I can port it back to net-snmp-5.1.2.

Comment 8 Peter Bieringer 2007-06-04 12:11:48 UTC
Is there an option to disable this logging at all?
I tried removing "-a" from default options - won't help.
I played around with the "-L" option, but it didn't help also.

As I understand (according to http://www.net-snmp.org/docs/man/snmpcmd.html) I
should use for warning priority to syslog:
 -LSw -Lsd

But -LSw isn't supported neither on RHEL4U5 nor in Fedora Core 6 version.

Digging through source code I have found, that -LS isn't supported at all at
least in 5.3.1 (see snmp_logging.c and look for call of function
decode_priority). A short test shows me that "-LFw" works (like expected after
digging through source code).

Looks like programmers forgot to add/copy this piece of code, but author of man
page didn't realize it and one also forgot to test described options.

Should I file another bug according to this issue.

Comment 9 Peter Bieringer 2007-06-04 12:16:04 UTC
Ooops, I must revert my comment about the missing function call, it exists on
case "S", but then the problem must be somewhere else.
-LFn works, -LSn isn't supported - now still don't know why.

Comment 10 Peter Bieringer 2007-06-04 12:31:51 UTC
Digging through modified source code I finally found how the option works:

OPTIONS="-LS notice daemon -Lf /dev/null -p /var/run/snmpd.pid"

This will suppress all the messages mentioned in #1

Looks like one have at least to update the man page for a proper working example.

Comment 11 RHEL Product and Program Management 2007-06-09 13:24:23 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 12 Narendra K 2007-06-14 05:39:01 UTC
With respect to comment #4 could you make the patch available so that i can 
test it.

Comment 13 Jan Safranek 2007-06-14 07:11:35 UTC
Created attachment 156962 [details]
patch for this bug

Comment 14 Jan Safranek 2007-06-14 07:16:18 UTC
The patch is attached. You can find .srpm with it + other patches for RHEL4.6 at

Comment 16 Narendra K 2007-06-15 16:47:02 UTC
With respect to comment #14, tested the application built using the srpm 
mentioned in comment #14. The messsages mentioned in the description of the 
problem are not repeatedly being logged into /var/log/messages. And snmpwalk 
on mib-2 tree takes about 10 seconds. 

Comment 21 Jan Safranek 2007-06-28 07:58:09 UTC
*** Bug 246057 has been marked as a duplicate of this bug. ***

Comment 31 Sandy Garza 2007-10-01 16:15:46 UTC
HP tested and passed verification.

Comment 32 Larry Troan 2007-10-04 14:07:27 UTC
people.page lists net-snmp-5.1.2-11.EL4.10.test.src.rpm in comment #14.

RHEL4.6-snapshot4 contains net-snmp-5.1.2-11.EL4.11.i386.rpm which should
contain the fix.

Comment 33 errata-xmlrpc 2007-11-15 16:00:33 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.