Ok, here's me after *not* checking in what some might not consider a bug-fix
(and other might consider a new feature) right before a pre-release.
A while back, while fixing bug 1347709 (snmpd always opens default logfile), I
made a bunch of log related changed to snmpd. I didn't consider snmptrapd
until a co-worker of mine sent me a bug-report that setting logOptions in his
snmptrapd.conf did not work. So I took a look at logging in snmptrapd. And
wished I hadn't.
I would like to clean it up for 5.3. However, there are some quirks to
snmptrapd's log handling. So I'm opening a dialog.
1) it has distinct knowledge coded in for syslog logging and file/print
handling. Even to the point of logging differently formatted startup messages!
I'd like to remove the distinction, and have 1 format for all log types. The
only place this causes a problem is the startup message. Choices are:
a) snmp_log(LOG_INFO, "Starting snmptrapd %s\n", netsnmp_get_version());
b) snmp_log(LOG_INFO,
"%.4d-%.2d-%.2d %.2d:%.2d:%.2d NET-SNMP version %s Started.\n",
tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday,
tm->tm_hour, tm->tm_min, tm->tm_sec,
netsnmp_get_version());
I vote for a, since there's already an option to add time-stamps to log
messages.
2) message formatting can be specified the documented following ways:
command line
-F, for logging to stdout
snmptrapd.conf
format1, for v1 traps
format2, for v2 traps/informs
Additionally, there are the following *undocumented* ways:
snmptrapd.conf
print1, for v1 traps
print2, for v2 traps/informs
syslog1, for v1 traps
syslog2, for v2 traps/informs
Currently snmptrapd will register a syslog handler OR a print handler after
processing arguments. Both handlers call snmp_log() to log the final formatted
result, so the if even if multiple logs and different formats are configured,
only one format will be used for all logs.
It seems to me, in this day and age of multiple log handlers, this mode of
configuration is outdated, and supporting different formats for different
logging methods is overly complex, doesn't work now, and I'd be willing to bet
it never did!
3) Recently a bug was filed related to log file handing when logs exceed 2GB.
This has been partial fixed for snmpd by restoring the default behavior of
truncating log files on startup. Unfortunately, snmptrapd has no documented
behaviour for opening log files at startup. Currently:
-o : truncated
-Lf : 5.2.x not truncated, 5.3 truncated
Do we want to add an option to allow appending to log files? The option used
by snmpd, -A, does not appear to be used by snmptrapd.
4) For future consideration, it would be nice to add some processing to -L to
allow per-log options to be set. eg -Lt [truncate|append], which would allow
something like:
-Lf file.trunc -Lt append -Lf file.app
where file.trun would be truncated when created (the default), and file.app
would be appended.
So we have a week to hash out 1-3. I'd like to check in the fixes I've got
before 5.3.pre5 (yes, the schedule is slipping. Surprise, surprise.)
--
Robert Story; NET-SNMP Junkie
Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders>
You are lost in a twisty maze of little standards, all different.
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
