rsyslog 1.17.0

I had an extraordinary good day today. I managed to make rsyslog 1.17.0 nearly feature complete for the upcoming 2.0.0 release. I also see much more interest from the community, now that red hat thinks about moving rsyslog into Fedora 8. If all goes well, we’ll soon see it pushed to F7 as an extra. That would enable more people to play with it. And that’s important. We had a lot (a real looooot) of changes the past weeks. It’s now time that some folks seriously try to break the code, so that we can create a solid set of bug-fixes (not that I or my contributors made any mistakes – but you know: all these multi-bit errors messing up the source ;)).

Let’s stay tuned how things evolve. For the time being, will simply enjoy being satisfied ;)

rsyslog and fedora…

The news is creeping around the net that rsyslog possible replaces sysklogd in Fedora 8. As far as I know, no definitive decision has jet been made by the Fedora folks. But a lot of them already contribute to the code and its packaging system. So no matter how they’ll finally decide, this is very good news for the project.

Currently, I have not “advertised” the fact because I think it is not yet finally decided. But now it looks it has left the mailing Fedora mailing lists:

GPLv3 and rsyslog

Did you know? GPLv3 is out. And I am seriously considering it for my rsyslog project. Why? I do not like Tivo-ization nor do I like software patents. So, isn’t then moving to a license unfriendly to those a good idea? I think it is. But of course, there are a number of subtleties that I need to check.

I guess version 2.0.0, due soon, will be released under GPLv3.

Why are there so few messages from sysklogd itself?

Have you ever wondered why your logs do not contain anything from the syslog subsystem itself, except for maybe a message or two? Tina Bird has started an interesting new discussion on the loganalysis mailing list.

Of course, I couldn’t stand it and have added my 2cts. I’d like to reproduce it here in the blog, too:

> I have received a number of responses along these lines, obtained by
> grepping the source code or by running strings on the binary.
> These are far
> better than nothing, and I’m grateful for the help, but they miss an
> important piece of the picture. Especially in a piece of code
> as old and,
> uh, crufty as syslogd, there’s a high likelihood that many of
> the errors
> find themselves at the far ends of code paths that rarely (if
> ever) get
> executed, and therefore those errors never find themselves in
> the “outside”
> world, providing assistance (or confusion) to system administrators
> everywhere.

OK, I’ve once again done a real review of the sysklogd 1.14.1 source. I wanted to make sure I really tell the truth. The plain truth is that it is nearly impossible that anything goes wrong after syslogd is started. So you’ll observe a number of “config file invalid” messages, but only (hopefully;)) during initial setup. Once things run smoothly, you will see error message only when things go really wrong, e.g. when the hard disk dies. But then, in practice, will that ever occur? If the answer is yes, then you need to ask “will it be seen”? Of those systems where a hard disk failure is catastrophic, all of the logs are probably on that failed hard disk. Yes, exactly that disk our error message will be … ahem would be … written to ;) So you end up with just initialization and termination messages.

Is that the case because syslogd is such a perfect piece of software. Not really. The reason is that the stock implementation simply can not have any real problems once it runs: selector lines were either OK (and operating) or invalid (and disabled). And how about the network? Surely received packets are a trouble source. Formatting errors of all kind…

Let’s have a look at (informational RFC 3164):

4. Packet Format and Contents

The payload of any IP packet that has a UDP destination port of 514
MUST be treated as a syslog message.

Sweet – anything that is destined to 514 is a syslog message. No matter what the content is. Really? Am I kidding? Let’s read on:

Example 2

Use the BFG!

While this is a valid message, it has extraordinarily little useful

Yeah… This is a valid message. This also: “HaHaHa”. So how will a parser need to complain when it processes the message. It doesn’t – and that’s why you won’t see many messages from sysklogd itself.

HOWEVER, things are improving. In rsyslogd, there are a lot more things that can go wrong. For example, IETF is standardizing the frame format if TLS is used. This provides a number of opportunities for emitting error messages. TCP itself gives ground to another set of messages. On the output side the same: rsyslog can do dynamic file names. That means files are created depending on incoming messages. Of course, things can go wrong here, providing another set of error messages.

I am talking about rsyslog, because I maintain this project. I think any other modern-day syslogd has a similar set of error messages. And these are possibly seen in practice. But now it is much more depending on how valid all parts of the system, including senders, work. With the majority of syslog-enabled applications still following the “I don’t need to obey any format” paradigm, the typical cause for error messages is not-existent for syslog servers.

I hope that clarifies. And there is even hope: syslogd’s will spit out more errors in the future ;) [and, yes, I have at least created a todo item to emit meaningful error identifiers together with them…]


Is syslog blogging worth it?

Hi all,

I’ve not posted anything for a looong while. I was (and I am) dissatisfied with the amount of traffic (or better non-traffic) that the blog showed. Anyhow, I think I am giving it a new try. Probably this blog will also morph into a rgerhards blog, not necessarily being on syslog only (which seem to be a too-boring topic for blobs). But I am still unsure if it makes sense to continue – drop me a note if you have an opinion.