rsyslog changes until 2007-09-24

Hi all,

I’ve been a bit lazy reporting what I’ve done with rsyslog. The primary reason is that it was a lot of review, which is quite boring to report in a blog. Today, I think, I’ll do a new release, so at least here is my worklog for up until yesterday.

2007-09-17
– possibly found a bug in cvthname() that lead to a wrong size being specified
in a getnameinfo() API call – not sure, though, if it is “the” bug (actually,
it looks like it isn’t). – this is EXPERIMENTAL
– fixed a bug that caused signal handlers in cvthname() not to be restored when
a malicious pointer record was detected and processing of the message been
stopped for that reason (this should be really rare and can not be related
to the segfault bug we are hunting).
2007-09-18
– split the function cvthname() for clarity. Also changed to using the rsRetVal
status return system
– removed some compiler warnings in regard to signed / unsigned comparison
2007-09-20
– code cleanup
– fixed a minor memory leak that occured when the %APPNAME% property was
used (I think nobody used that in practice)
2007-09-21
– more review and cleanup
– simplified code in shouldProcessThisMessage() for debug output
– changed strerror() calls to thread-safe strerror_r() variant

What’s going on with rsyslog?

I’ve not posted much the past days. That doesn’t mean nothing has happened. I wanted to post a work log today, but I have to admit I have forgotten it on a machine I right now can not access. OK, first thing tomorrow morning…

In short words, we are still on the bug hunt. I am now again back to reviewing code, this time on a functional basis. I am checking everything based on the message flow, looking at functions as they are called. Today, I completed the review of the reception part (up to the point when it gets into the main message queue). Unfortunately, no serious problem found. I used the review, however, to clean out some nits, add a large number of new comments and even found a memory leak. The later one would currently most probably never occur in practice, but when syslog-protocol gets adopted, it would have hit.

Tomorrow, and probably then next two or three days I’ll review the code that is executed once the message leaves to main queue. There is probably more meat for a bug in that part (its by far more complex).

I also think I’ll release the cleaned-up version sometime soon – after all, it’s better then what is currently released.

I keep you posted. Comments are always welcome.

paid services for rsyslog

As with a lot of open source projects, rsyslog funding is problematic. Of course, rsyslog currently is funded by my interest in it. And I am glad that Adiscon, my company, permits me to work on. The actual funding for all that action, kind of funny, mostly stems from closed source projects in the Windows world.

However, I’d like to see that over the years rsyslog can fund itself. In my point of view, funding should be provided by those that benefit most from it. So obviously, I do not expect any funding from private folks, people like you and me. Of course, everyone is invented to contribute and new code, doc and bug hunting is definitely a pro. On the other hand, companies (and other organizations, namely the government) take financial advantage of using it. Some of them also contribute in terms of time and code. This is great and much appreciated :)

For the others, I have begun to offer donations. Not surprisingly, this is not a real source of funding ;) But now I have taken an offer from sourceforge.net, which I think is interesting. They begin to offer a marketplace for open source services. So those folks that actually need help can be brought in contact with those that have experience. Sounds like a good idea to me and a fair way to fund projects.

I have created two test service offerings for rsyslog. One is to write a nice custom-created rsyslog configuration file. Well, with rsyslog’s relative ease of use, I do not expect that many folks use that. But you never know and I am always curios.

The other one is especially targeted towards organizations who must prove they have “official” support for all software they use (I guess this includes at least a number of government agencies). For them, I have created a email support option for rsyslog. It guarantees responses to support questions and this is often needed for auditing and other purposes. Of course, we still answer all support emails and do not plan to stop that.

I have added one real goody, though: and that is that we will provide patches for past releases of rsyslog. As you may know, developers hate to fumble with old releases. And so there is very little motivation to look at an older release when there is a new one out. With the paid support option, however, there is some motivation to do that. So, again, I think this is fair: we are just offering a service that would otherwise never appear. It doesn’t hurt any of the other users.

I am very interested to see how this works out. I would also be interested in feedback from the field. How do you like this idea? Do you have any other/additional suggestions?

recent rsyslog changes

Again, I am doing small changes, mostly review, at this time. So I have batched up some things. Probably I’ll switch back to a more daily mode, as it allows to keep better in touch. We’ll see (comments appreciated).

Here comes the log:

2007-09-10
– bumped version number to 1.19.6
– fixed a bug that in –enable-debug mode caused an assertion when the
discard action was used
2007-09-07
– added eCmdHdlrGetWord command handler
– added $ModDir config directive
– modified $ModLoad so that an absolute path may be specified as
module name (e.g. /rsyslog/ommysql.so)
– applied patch by varmojfekoj two fix two potential segfault situations
– cleaned up some signed/unsinged char issues
– released 1.19.5
2007-09-10
– bumped version number to 1.19.6
– fixed a bug that in –enable-debug mode caused an assertion when the
discard action was used
2007-09-11
– applied patch by varmojfekoj to change signal handling to the new
sigaction API set (replacing the depreciated signal() calls and its
friends.
– did a full review of all remaining TODO items in code – nothing of
importance found (but some minor nits like comments fixed)
– cleaned up compiler warnings
– applied patch by varmojfekoj to FIX a bug that could cause
segfaults if empty properties were processed using modifying
options (e.g. space-cc, drop-cc)
– fixed man bug: rsyslogd supports -l option
– checked -s/-l option and found that they work as expected – closed case
– added some comments in relation to -s/-l option
– released 1.19.6
– removed compiler warnings in non-debug mode
– fixed a bug that caused the CStr class to not honor the parameter to
return NULL on empty string – causes a mem leak and can create favourable
environment for other bugs (as it leads to empty hostnames)
– pulled 1.19.6 (no downloads so far), created new 1.19.6 with the bugfix,
re-released that (now tagged v1-19-6b in cvs)

bug hunting…

We have received feedback that the 1.19.x releases of rsyslog contain a bug that leads to a segfault after some time. Of course, this is a very bad thing to happen. After all, the primary goal for the rsyslog project is reliability and it should be able to survive even in the worst conditions (e.g. low system memory). So this bug is clearly unacceptable and has received highest priority.

Unfortunately, it is hiding very well. We are all looking into troubleshooting this beast. Thankfully, there is a lot of community support, especially with testing. What makes this bug so hard to find is, among others, the inability to reproduce it in lab. So the project is totally dependent on user feedback. As current reports have shown, we also currently assume that releases prior to 1.19.0 can also be affected – so it is not as easy as checking the changes.

I receive very valuable help by varmojfekoj. He is already a frequent and great contributor of patches. His skills and experience are extremely valuable and I am very glad to have him work on this project. Please give him a big hand. Thanks, varmojfekoj, the project would not be that far without your help!

While the bug itself is obviously a very bad thing, it has some good side-effects. Most importantly, the code is getting another round of very in-depth review. That review has already brought up some fixes for obscure situations. Situations that I’d expect to happen extremely infrequently (if at all) in reality. But now even those are fixed. And I am sure that the review will bring even more benefit as it continues. Of course, I’d be glad if we find the bug ASAP, but it is good to know that all that work also provides additional benefit (at least that keeps my depression level low ;)).

The bad thing, besides the bug itself, is that the bug hunt obviously defers other work. Most importantly, I refrain from making any changes that may not be related to clean up or bug fixing. I think it is not smart to introduce new code (read: complexity) at this stage of the project. And, of course, all resources should focus on fixing that bug, so there wouldn’t even be time to enhance other parts of the code. So for all of you waiting for new features: please bear with us, the implementation schedule will slip a little bit.

If you experience stability problems, please report. Each reports helps us understand the problem somewhat better.

recent rsyslog changes

Now that I am back working on the rsyslog code, I will continue to provide information about what I am doing. In most cases, however, I will not provide daily logs. The reason is that I currently focus on new design and will leave rsyslog code mature. So changes will be relatively infrequent (at least I plan so ;]).

Here is the work log for the past days:

2007-09-04
– integrated patches from Michel Samia and varmojfekoj
– released 1.19.4
– changed some calls to CStr class to their “safe” counterpart – they could
cause program aborts if the object in question was an empty string
2007-09-05
– added some links to doc
– removed an invalid config sample from sample.conf
– changed part of the CStr interface so that better error tracking
is provided and the calling sequence is more intuitive (there were
invalid calls based on a too-weired interface)
– (hopefully) fixed some remaining bugs rooted in wrong use of
the CStr class. These could lead to program abort.
2007-09-06
– added forwarding information to sysklogd (requires special template)
to config doc

rsyslog config again…

I am writing a lot about rsyslog config file formats these days. Now I think I come closer to a result. The past days, I have thought a lot about potential formats. Now, I have created configuration samples in the rsyslog wiki. Also, some others have posted hints.

I now have two favorites: one is a XML-based format. Its advantage is that it would be easy to use when (if) we implement NETCONF protocol. If I assume NETCONF will actually become *the* configuration standard, this is a big pro argument for that format. However, I consider the format to be exceptionally bulky and pretty less intuitive. In other words, I do not really like it – but that doesn’t mean it is a bad choice.

What I like more is a programming-language like format (and especially the last sample in the wiki article). It looks somewhat more “natural” to me, but this may be because I like programming languages ;) In any case, I think it is easier to grasp and modify, but of course it is not standardized. Plus, there are three different samples, each in a different style and level of verbosity.

The question is now what users consider to be best. I sincerely hope to receive feedback, as I probably have only one “shot” at this for the foreseeable future (well… I have to admit that I thought about dynamically loadable config file parsers, but that adds probably too much complexity).

So if you have anything to say, please speak up now!
If you do not know where to make yourself heard, simply post to the rsyslog forum thread on the config file format.

where is liblogging heading to?

I just received a question whether or not I plan to change the build system for liblogging to a modern one, just like I have done with rsyslog recently.

As a reminder, liblogging is the library that provides RFC 3195 functionality to rsyslog. Of course, others can integrate it too. Writing liblogging was a considerable effort. When I did this, I had hoped that RFC 3195 would become much more dominant in the logging space. Unfortunately, the current version became a failure. This is also one reason that rsyslog supports receiving messages via 3195 but not sending them – the interest was too low (to phrase it politely) and other features received priority.

Liblogging development is currently “on hold”. I was tempted to completely abandon it, but then Cisco moved RFC 3195 support into IOS. That was one thing that made me hope that the standard may become accepted in the long term. Recently, while designing rsyslog v3, I noticed that rfc 3195 (or more precisely BEEP, RFC 3080) indeed offers a very good choice for protocol extensions. I am currently very seriously thinking about re-vitalizing liblogging and make it the foundation of rsyslog-to-rsyslog communication.

But there are also a number of other subtleties. Most importantly, the current RFC 3195 is insufficient for practical purposes. For example, it limits message size to 1K. It also does not support new syslog headers. The IETF is considering a new version of 3195, which will fix these shortcomings. Of course, I can go ahead and use from 3195 what makes sense to me and extend the rest on my own. But that will cause trouble in the long term and I do not really like that.

There are also some funding issues. As you possibly know, we fund our projects also via closed-source Windows software (e.g. MonitorWare Agent or EventReporter). The current liblogging has a BSD-style license. That was chosen in the hope it will help to make it a standard. However, it also enables our closed-source competitors to pull our work without contributing anything back.

So, to be honest, if we go ahead and do a new substantial effort on liblogging, we will probably release it under GPLv3. That enables everybody who does open source to use it, but prohibits our closed-source competitor to integrate the library. Of course, we need to retain the right to use it ourselfs in our commercial products, but I think it can be arranged in a way that is compatible with GPLv3 – at least I have seen a number of projects doing that.

To summarize in short words: liblogging is currently on hold and will be for at least some more weeks. We are deciding if we extend it. If so, that will go along with rsyslog development.

rsyslog v3 object model and message flow

I thought quite a while about the upcoming configuration file format today. I
have to admit, I am not very satisfied with the outcome. I have a few potential
formats, but either they are too brief (and quite complex) or there is a lot of
text. Also, I am not satisfied yet with the flexibility of the format. I guess
this is a harder nut to crack than I thought. Unfortunately, I can not yet post
any of the ideas, as I have done them on paper and they are probably unreadable
to anybody but me. Bear with me, I’ll create an online version these days.

But to understand any config file formats, you need to know more about the
object model. A first version of that model has materialized on my mind, and
actually rsyslog 1.18.0 and above is already supporting parts of it. To aid
understanding (and get some discussion going), I have created a quick outline of
what I have in mind. It’s textual, it’s incomplete and it can not be formally
verified. Still, I think (sincerely hope), it is useful. So I decided to post
what I currently have. Besides the actual object model discussion, it will help
a great deal in understanding what needs to be in the config file (thus it’s
currently a bit biased towards configurable objects and internal ones are almost
completely missing).

rsyslog v3 Objects

Rsyslog uses objects, even though it is written in C. This can quite well be
done. Only at some points (like inheritance) we need to fiddle a bit with the
language. But nothing to hard to be done. We try to keep object overhead very
low, so it should be more like traditional C than C++.

module

The module object is the base class for anything that even remotely looks
like a loadable object. In the long term, that might eventually be almost
everything. It handles the necessary plumbing like loading modules, keeping
track of module status, querying interface and all those things… It does not
by itself provide any module-specific actions.

input

An input gatheres messages (events) from external sources. Current typical
examples are UDP or TCP based syslog. However, there is no architectural limit,
so in the long term an input module may also gather SNMP traps or file lines.
Please note that an input does not necessarily parse the obtained event by
itself – this may be delegated to a parser module (this whole thing still needs
to be thought out).

output

An output module receives strings from the engine and writes them to some
ultimate destination. Popluar examples are files, databases or remote syslog
servers.

action

The action object is the "engine wrapper" around an output module. It
provides numerous servies to the output. Most importantly, it provides the core
plumbing behind restarting and queueing actions.

function

A function object (and lodable module) provides extensibility for internal
processing. Version 3.0 will support programming-like functions, which replace
and extend the property replacer options. For example, we may want to extract
characters 5 to 10 and convert them to lower case. With current rsyslog, this
works as follows: %msg:5:10:lower%. With Version 3, it will look much nicer (at
least I hope so): lower(substr(%msg, 5, 10)). The exact sytax and semantics of
how this is used in the config file is under development – but I think you can
get the idea from the example. The core improvement featuere-wise is that with
functions, rsyslog can very esaily be extended by just programming a small
plug-in with a new function. Do to the programming-like strucuture, the new
function can be combined with all exisitng ones.

Functions will be supported everywhere a string is supported, which means
everywhere. Examples are filters, output format (templates) and file name
generation.

Message Flow

This is a brief description of how a message (an event) flows inside rsyslog.

The message text is received by the input module. The input module, possibly
with the help of a parser module uses the message text to create a msg-in memory
structure. This msg structure enters rsyslog’s main processing queue. As soon as
possible, the msg object is dequeued. Now the rule engine processes the rule set.
A rule set object contains multiple rule object, which are executed in order
until either all rules are processed or a discard action is encountered. If
there are multiple rule set objects bound to a single input module, they are
also executed in the configured order (the normal discard action will discard a
message for one rule set, but an additional rule set will  continue to
process the msg object. A special case of the discard action can be envisioned,
which discards a msg object for all bound rule sets.. Each rule object contains
filter objects and action objects. First, all filter objects are executed. That
means, their expressions are evaluated. If there are multiple filter objects,
their result is combined in a AND operation (other modes are not supported –
that could be easily done by crafting a specific filter expression, so we do not
encourage an additional set of complexity be allowing additional boolean
operators when multiple filter objects are used inside a single rule). If the
outcome of the overall filter object evaluation results in true ("to be
processed"), all action objects are called. The are called in the order of their
appearance in the config file (no exceptions here). The msg object is used to
generate that string required by the action (note that the msg object itself is
NOT passed to the action, this is a security and encapsulation boundary). For
string generation, function plug-ins may posibly be called (this is also the
case during filter procesing). The resulting strings are  passed to the
execute method of the action object. That object decides if queing,
rate-limiting or other functionality generically available to all actions is the
be carried out. All of this is done by the action object itself. Finally, the
strings are passed from the action object to the actual output object (a plug-in).
The output objct takes the strings and performs whatever processing needs to be
done. After all actions, rules and rule sets have been processed (or when a
discard action occurs), the msg object is destroyed. Please note that even than
a copy may be held in memory, because that might be needed for duplicate message
reduction and similiar features. Thus, msg is reference-counted and actually
only destroyed when the count reaches zero.

Please note that there are a number of utility objects involved. For clarify,
these have been omitted. Also, all function calls return a meaningful return
state. The caller will process that state with care. In some cases, however,
this may mean ignore a failed call, because this is the most appropriate thing
to do (e.g. when an action fails – if we’d abort processing the msg object, we’d
do much more harm).

Data flow

This is a brief and not so accurate picture of the data flow. It concentrates
on the role of plug-ins.

input module(parser) -> rule engine (custom functions) -> action (with
aggregated output module)

Known Open Issues with Plug-ins

The object model is not yet fully designed, so there is nothing bad about
open issues. I list them, so that the do not get lost.

Probably the number one question is how message-modifying plug-ins can be
created. I think about things like implementing syslog-sign or TLS security. It
is my current, unverified, view that we must have something like "filter-plug-ins"
which can be placed inside the message data flow to modify the message text and/or
the msg object.

Copyright © 2007 by
Rainer Gerhards

Last Updated: 2007-08-30

on the importance of plug-ins for rsyslog

Rsyslog currently offers only very rough support for plug-ins: only the MySQL plugin is available as a plugin. Even the output plug-in structure is not yet finished. So it looks like plug-is are quite unimportant to rsyslog. Right?

Wrong! Totally wrong! If there is a single feature that is absolutely critical to rsyslog, it is plug-in support. Plug-ins offer a way to provide dynamically loadable extensions of the core functionality. Provided the plug-in interface (API) is clean and well-designed, that can come without any performance hit.

Now don’t just think about plug-ins for exotic features. What if almost everything is a plug-in? Well, in that case the code loaded in memory (the footprint) can be exacty tailored to what is needed. This is most benefitial for small, embedded system with limited resources available. On the other hand, this doesn’t limit a highly capable system of offering a very rich functionality. It just loads different plug-ins.

Remember that almost all functionality can be implemented as a plugin. Inputs (E.g. UDP syslog or local domain sockets) and outputs (e.g. database output or message forwarding) make somewhat natural plugins. But plugins can also be used in filtering. For example, the (expensive) regexp functionality could be provided by a plugin. As could be different message parsers.

This is exactly the way rsyslog is heading: we will try to provide an ultry-slim framework which offers just the basic things needed to orchestrate the plug-ins. Most of the functionality will indeed be available via plug-ins, dynamically loaded as needed.

I am not yet sure when we will reach his goal. But the object model design and the overall design direction heads into this area. With that design philosophy, we can make rsyslog really universally available, even on low-powered devices (loading just a few plug-ins). At the high end, systems with a lot of plug-ins loaded will be able to handle the most demanding tasks.

And, of course, plug-ins will hopefully not only be provided by the rsyslog project itself. It is our sincere hope that others will also begin to contribute functionality in the form of plug-ins. To facilitate that, we strive to create very simple plug-in interfaces. For example, all threading details will be handled by the core engine itself and plug-ins will be able to think they are running on a single thread. The core engine will handle the proper sync operations. Of course, plug-ins in need to use themselves a sophisticated threading model can do so – but it is not a requirement. Hopefully, that’ll make it very easy to create plug-ins and thus be very easy to contribute extended functionality for rsyslog. That, we hope, will help create a lively community and thus a breakthrough syslog project.