It was thus said that the Great Rainer Gerhards once stated: > > The format being sent is documented in RFC-3164, in which the only > > mandatory field is PRI > > No, not even PRI ;)
Yes, you are correct. I misspoke 8-) > > ---it's up the the receiving end to make sense of > > the > > rest of the message. It appears that in your case rsyslogd is > > mis-interpreting the incoming message. > > Technically speaking, RFC3164 is not a standard, because it is an > informational document. I have elaborated about its implications in: > > http://www.rsyslog.com/doc-syslog_parsing.html > > So if we follow your view, we simply need to accept anything as being valid, > and as such we do never know which information is contained inside a message > (just ask yourself the question how you know what the sender meant in this > case. Message is > > "hostname junk" > > Was this intended to mean MSG = "hostname junk" or was it intended to mean > hostname="hostname", MSG="junk" -- or something else? In my own project, I treat it as MSG = "hostname junk" with a facility of USER and priority of NOTICE (as per section 4.3.3 of RFC-3164). Also, because of the wide variance I've encountered in parsing syslog messages, when I send out a message, I use the IP address as the hostname (I find the IP address (either v4 or v6) to be unambigious and easier to find than a hostname), and anything else in that portion (up to a colon) as the program name (one exception: anything in square brackets is a process id). The entire parser routine is 210 lines of C (including a ton of comments) and it works enough for my tastes (and if I come across somethign that doesn't parse right, I still have the raw log to check against). Adding RFC-5424 parsing support would be easy, but I don't have anything generating RFC-5424 records (well, I suppose my program could relay in RFC-5424 format ... ) -spc _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
