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: Connection from - 18.104.22.168
snmpd: 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.
Created attachment 155534 [details]
The snmpd.conf file used to configure snmpd agent
Created attachment 155535 [details]
the snmpd log /var/log/snmpd.log
Created attachment 155536 [details]
the /var/log/messages log file
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
I can port it back to net-snmp-5.1.2.
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:
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.
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.
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.
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
With respect to comment #4 could you make the patch available so that i can
Created attachment 156962 [details]
patch for this bug
The patch is attached. You can find .srpm with it + other patches for RHEL4.6 at
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.
*** Bug 246057 has been marked as a duplicate of this bug. ***
HP tested and passed verification.
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.
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.