Hi all, > That's definitely a way to go. Unfortunately, pmrfc3164 already does a > lot of > guesswork for other cases where things are malformed (just as an > example, > there are devices that put an additional space in front of the date, > invalidating all the offsets you give...). > > The problem is that in a strict sense, RFC3164 does not demand > anything. So > there are lots of things that are mutually exclusive. In the current > parser, > I try to weigh importance of occurrence and performance. So the most > prominent cases are probably handled, conflicting less common cases > not. > "last message repeated n times" is pretty useless, so it has low > priority. I > have also a "performance filter" on my mind, that means I do only those > things that seem reasonable. > > However, the whole idea of introducing message parsers was to solve > exactly > that problem. So I think it is natural to write a new message parser > rather > than try (and probably fail) to fiddle even more with the 3164 parser, > which > already is overwhelmed with guesswork. For "last message...", I would > need to > do a full string compare, anything else would be incompatible with the > already-existing guesswork in pmrfc3164. > > Rainer
I have crafted the new message parser I spoke about this morning. The module is called "pmlastmsg" and available via the git master branch right now. The commit is here (you notice it is not much code, if you ignore the macros and preprocessor statements): http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=73ebadd5980f91079416a14b a6463d576ecb6207 Doc, with the typical usage sample, is available here: http://www.rsyslog.com/doc-pmlastmsg.html This parser module should solve the "last message repeated n times" problem for all future ;) Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
