Written by Rainer Gerhards (2007-12-17)
Rsyslog aims to be a drop-in replacement for sysklogd. However, version 3 has some considerable enhancements, which lead to some backward compatibility issues both in regard to sysklogd and rsyslog v1 and v2.
Rsyslog v3 is currently under initial development. Compatibility issues may be resolved, so be sure to check back often. Also, comments and suggestions are appreciated. Feedback right in time can now have a big impact on the route we take ;)
A number of command line options have been removed. New config file directives have been added for them. Once we implement compatibiltiy mode, these options will return, but only if running in non-v3-native mode.
The -m command line option is ignored for the time being. There is no default mark period. If you need a 20 minute mark period you need to
$ModLoad immark # wherever this is
$MarkMessageInterval 1800 # 20 minutes
klogd has (finally) been replaced by a loadable input module. To enable klogd functionality, do
$ModLoad imklog
A limited set of klogd command line settings is now supported via rsyslog.conf. That set of configuration directives is to be expanded. So far, we support:
$klogSymbolsTwice [on/off]
$DebugPrintKernelSymbols [on/off] # spits *a lot* of messages at startup
I have decided to move the todo list for v3 also into this document. After all, it is kind of a compatibility issue ;) But, more seriously, I think this is a good place to make sure nothing is forgotten. Remember that as of now, rsyslog v3 is in its early stage of development and so there definitely are some nits that will give you grief. This section here tells you what it is.
needs to be implemented. So far, only -c3 is supported. Everything else does not change anything but just provides a warning message. In short: there is no backwards compatibility yet.
Thread termination in mode 1 needs to be looked at. I begin to think that it is OK if we simply cancel the thread, because we already have a different cleanup function. Otherwise, there is a potential for a race condition after we unblocked the TermOK mutex but before select() is entered. If the signal then occurs, we may have a problem. However, I would like to create the other input modules first so that I have more working experience with termination requirements. Again, I think this will lead to changes in thread termination.
So far, this issue is resolved, but there is still some code present that needs to go away (right now disabled). I keep it in because I will make the final decision based on experience gained during creation of input modules.
In an ideal world, the modules should call back only to some well-defined and specifically exported interface functions. Right now, we do not have an ideal world and the input modules make some calls back into the core. This needs to be re-thought but is accepted for the time being.
As already said in "Call Encapsulation", the modules look like such, but are not really able to work stand alone. The worst in this regard are
But the others are not necessarily better. I have moved the code to the modules, because now at least the majority of code is where it belongs to. But there are still a large number of global variables, cross-function calls and the like. This needs to be solved when we try to claim a real modular design. That's not an easy task, but, hey, aren't we up for that...? ;)