Red Hat Bugzilla – Bug 477768
incorrect parsing of options to /usr/sbin/snmpd
Last modified: 2010-10-23 02:44:36 EDT
Description of problem:
In our environment we have used to following options to /usr/sbin/snmpd: ' -LS n d -Lf /dev/null -p /var/run/snmpd.pid -a' to get snmpd to use syslog and log from notice priority level. With version net-snmp-126.96.36.199-4.el5 this generates an error, 'invalid syslog facility:', and snmpd fails. The separate 'n' and 'd' in the log (-L) option must be specified like 'nd' to make it work. Although this works with the 188.8.131.52-4 version it does not work with previous versions, where the log options must be stated separately. This makes for an unnecessary difficult upgrade of a large environment.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install net-snmp-184.108.40.206-4.el5
2. try to start snmpd with '/usr/sbin/snmpd -LS n d -Lf /dev/null -p /var/run/snmpd.pid'
Start of snmpd fails.
Start of snmpd succeeds.
You are right, the parsing of -LS options is different now. It's caused by upstream patch at https://sourceforge.net/tracker/index.php?func=detail&aid=1806336&group_id=12694&atid=312694.
This bugzilla has Keywords: Regression.
Since no regressions are allowed between releases,
it is also being proposed as a blocker for this release.
Please resolve ASAP.
Fixed upstream: http://net-snmp.svn.sourceforge.net/viewvc/net-snmp?view=rev&revision=17350
Looks like this bug is not solved in final 5.3
OPTIONS="-LS 0-4 d -Lf /dev/null -p /var/run/snmpd.pid"
Worked with 5.2, broken in 5.3
That's really bad and very unexpected.
Yeah, I know... The report came too late to catch 5.3 update, sorry.
Do you know how to replace my config string with a working one? I played a litte bit around, but did not find a solution....
'0-4' in '-LS 0-4 d' is IMHO a bit useless, 0 is the default -> you can use '-LS 4d' to get LOG_WARNING and above to syslog.
oops, wrong bug, clearing NEEDINFO.
I noticed another thing. I had changed some settings in /etc/snmpd/snmpd.options:
OPTIONS="-LS 0-4 d -Lf /dev/null -p /var/run/snmpd.pid -a"
This seemed to work for me, (the file in the /etc/snmpd and the options for snmpd)
with 5.3, the location /etc/snmpd is no longer recognized, although it seems the rpm has moved my file from /etc/snmpd to /etc/sysconfig
I have now modified the options file in /etc/sysconfig to:
OPTIONS="-Ls 4d -Lf /dev/null -p /var/run/snmpd.pid -a"
and it now starts....
Can someone clarify what the "d" stands for in this line?
OPTIONS="-Ls 4d -Lf /dev/null -p /var/run/snmpd.pid -a"
I'm assuming thats the "debug" facility?
Can someone help me out here. I have modified /etc/sysconfig/snmpd.options to OPTIONS="-Ls 4d -Lf /dev/null -p /var/run/snmpd.pid -a"
I see snmpd running:
root 762 0.1 0.3 27484 6628 ? Sl 21:00 0:00 /usr/sbin/snmpd -Ls 4d -Lf /dev/null -p /var/run/snmpd.pid -a
But I'm still getting messages in /var/log/messages about polling:
Feb 18 21:14:18 <hostname> snmpd: Connection from UDP: [<ip>]:1104
Originally we just had the following line in /etc/snmp/snmpd.options:
OPTIONS="-LS 4 d -Lf /dev/null -p /var/run/snmpd -a"
> But I'm still getting messages in /var/log/messages about polling:
> Feb 18 21:14:18 <hostname> snmpd: Connection from UDP: [<ip>]:1104
"Connection from UDP:" can be suppressed by adding "dontLogTCPWrappersConnects 1" to your snmpd.conf file. And by removing '-a' from command line, you get less messages too.
What if I want to only log improperly authenticated connections? This appears to stop logging for everything...
(In reply to comment #15)
> What if I want to only log improperly authenticated connections? This appears
> to stop logging for everything...
OPTIONS="-LS 4d -Lf /dev/null -p /var/run/snmpd -a"
Unfortunately, those options do not work in the 5.2 version of snmpd (5.3.1). As stated in the original description by Adam,
"Although this works with the 220.127.116.11-4 version it does not work with previous versions, where the log options must be stated separately. This makes for an unnecessary difficult upgrade of a large environment. "
# /usr/sbin/snmpd -LS 4d -Lf /dev/null -p /var/run/snmpd.pid -a
invalid syslog facility: -
Usage: /usr/sbin/snmpd [OPTIONS] [LISTENING ADDRESSES]
We still a set of options that will work in both 5.3.1 and 5.3.2 which reduce logging to only improperly authenticated connections. From what I've read, this is only possible with a patch that accepts the old style '-LS 4 d' option.
Can we get a test package incorporating this fix? Fujitsu would like to verify the same.
~~ Attention - RHEL 5.4 Beta Released! ~~
RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner!
If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.
Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value.
Questions can be posted to this bug or your customer or partner representative.
Event posted on 07-13-2009 12:20pm EST by aimamura
> Could you please verify the fix on RHEL5.4 Beta?
We confirmed that this problem was corrected in RHEL5.4 Beta.
The Snmpd operated correctly by below options.
OPTIONS="-LS 5 d -Lf /dev/null -p /var/run/snmpd.pid -a"
OPTIONS="-LS 5d -Lf /dev/null -p /var/run/snmpd.pid -a"
Internal Status set to 'Waiting on Support'
Status set to: Waiting on Tech
This event sent from IssueTracker by jnansi
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 therefore 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.