From: SourceForge.net <no...@so...> - 2010-04-12 14:32:08
|
Bugs item #2966234, was opened at 2010-03-09 12:21 Message generated for change (Comment added) made by jackfalworth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112694&aid=2966234&group_id=12694 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: agent Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: JackF (jackfalworth) Assigned to: Nobody/Anonymous (nobody) Summary: Logging cannot be disabled Initial Comment: I'm running snmpd v5.4.2.1 and v5.5 on Ubuntu 8.04. I run snmpd with snmpd -f -Ls4, i.e. I want to log to syslog facility 4. This works perfectly fine for both versions. But at the same time I want to disable logging to file. Neither the cli option -Lf /dev/null nor -Ln works for me. A similar bug was reported for v5.2 in http://sourceforge.net/tracker/index.php?func=detail&aid=1084413&group_id=12694&atid=112694 . It was stated that this bug has already been fixed for versions v5.3 and v5.2.1. I couldn't find the supplied patch, so I assume that maybe the patch wasn't applied in version > 5.4. ---------------------------------------------------------------------- >Comment By: JackF (jackfalworth) Date: 2010-04-12 16:32 Message: Just wanted to ask if this bug will be fixed in near future? ---------------------------------------------------------------------- Comment By: JackF (jackfalworth) Date: 2010-03-24 09:27 Message: Sorry for the delay. I haven' t been in the office for a couple of days. I did a lot of testing and you're right. The source of the problem is a config file directive. When I start snmpd without logging parameter and a "clean" log file, I see the following message: >> clean config file, daemon started without logging >> No log handling enabled - turning on stderr logging If I start the daemon with logging parameter, for example: snmpd -Lf logfile or snmpd -Ls4 and a default config file, logging works as intended. I use a very basic config file with few directives. But I figured out that the reported problem occurs when I use the proxy directive. It is used to forward remote snmp requests to a HTTP proxy via snmpd. The forwarding works fine but additionally it produces the erroneous loggin behavior. File logging / Syslog logging works, but log messages _additionally_ go to STDERROR. It seems that snmpd registers an additional log handler for STDERROR, if I supply the proxy command. The following line in the snmpd.conf causes the problem: >> proxy -v1 -c secret 127.0.0.1:12345 .1.3.6.1.4.1.3495.1 ---------------------------------------------------------------------- Comment By: Dave Shield (dts12) Date: 2010-03-17 15:45 Message: This may sound a strange question, but what else do you have in your snmpd.conf file? In particular, do you have any trap destinations configured? What happens if you comment these out? Are there any other errors being reported, or is the version line the first thing that appears? I've managed to reproduce the behaviour you report, but *only* when the snmpd.conf file contains a "trapsess" line. This also only applies to the 5.5.x (and earlier) branches. The same configuration with the current development code logs to syslog as expected. I need to do some more digging, but it would be useful to know what your snmpd.conf file looks like. ---------------------------------------------------------------------- Comment By: JackF (jackfalworth) Date: 2010-03-15 11:46 Message: I currently use v5.5. I want to use the agent like this: snmpd -f -Ls4 , i.e. it should not detach and log _only_ to syslog facility 4. For me, it doesn't matter if I run "snmpd" or "snmpd - f". The message "NET-SNMP version 5.5" goes to STDERROR. But the -f parameter works as intended. Ommitting -f also works. A "ps -Af | grep snmpd" indicates a running agent. ---------------------------------------------------------------------- Comment By: Dave Shield (dts12) Date: 2010-03-15 10:51 Message: There seems to be something strange going on. Your very first comment says: "If I run snmpd without supplying any logging parameter, log messages are logged to STDERR" That shouldn't be happening. If I run "snmpd -f", then the agent exits (because it can't open the socket) without printing _anything_ to either stdout or stderr. Do you see anything different? What is the full command that you are using to start the agent? ---------------------------------------------------------------------- Comment By: JackF (jackfalworth) Date: 2010-03-15 09:24 Message: Ok, let me refine my statement. I digged a little bit deeper. The problem I have is related to logging to STDERR. If I run snmpd without supplying any logging parameter, log messages are logged to STDERR. If I supply parameters for logging to file or to syslog this works perfectly fine, but at the same time snmpd logs to STDERR. Even when starting the agent with snmpd -Ln, which should suppress any logging, messages appear on STDERR. The only way of getting rid of those messages is to enable logging to STDOUT via the -Lo switch. But this is no improvement for me. By looking in the source in snmp_logging.c I found the function snmp_enable_stderrlog. As I understand the code it processes all registered loghandlers and enables the loghandlers for STDERROR and STDOUT. But if no such loghandler exists, an additional loghandler for STDERR with priority LOG_DEBUG is registered, which seems to be the source of those messages. Is this the intended behavior? Why is there an additional loghandler for STDERR if you explicitly want to disable any logging to console? ---------------------------------------------------------------------- Comment By: Dave Shield (dts12) Date: 2010-03-12 13:22 Message: I'm not sure that I understand the problem here. If you want to log to a file, this needs to be specified explicitly. The agent won't log to file automatically. (The default is to use syslog, I believe) So if you specify -Ls4, then the agent shouldn't be logging to file anyway. The 5.4 development only forked away from 5.3 in late 2005, so the (2004) bug entry you mention covers 5.4 code and above automatically. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112694&aid=2966234&group_id=12694 |