mirror of
https://github.com/rsyslog/rsyslog.git
synced 2025-12-17 05:50:41 +01:00
81 lines
4.2 KiB
HTML
81 lines
4.2 KiB
HTML
<html><head>
|
|
<title>Writing syslog Data to MySQL</title>
|
|
<meta name="KEYWORDS" content="syslog, mysql, syslog to mysql, howto">
|
|
</head>
|
|
<body>
|
|
<h1>Compatibility notes for rsyslog v3</h1>
|
|
<P><small><i>Written by
|
|
<a href="http://www.gerhards.net/rainer">Rainer
|
|
Gerhards</a> (2007-12-17)</i></small></P>
|
|
<P>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.</P>
|
|
<P>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 ;)</P>
|
|
<h2>command line options</h2>
|
|
<p>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.</p>
|
|
<h2>-m command line option</h2>
|
|
<P>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</P>
|
|
<P><b>$ModLoad immark # wherever this is<br>
|
|
$MarkMessageInterval 1800 # 20 minutes</b></P>
|
|
<h2>-r command line option</h2>
|
|
<p>Is also no longer available. Use</p>
|
|
<p><b>$ModLoad imudp<br>
|
|
$UDPListenPort <port></b></p>
|
|
<p>config file directives.</p>
|
|
<h2>klogd</h2>
|
|
<P>klogd has (finally) been replaced by a loadable input module. To enable klogd
|
|
functionality, do</P>
|
|
<P><b>$ModLoad imklog</b></P>
|
|
<P>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:</P>
|
|
<P>$klogSymbolsTwice [on/off]<br>
|
|
$DebugPrintKernelSymbols [on/off] # spits *a lot* of messages at startup</P>
|
|
<h1>TODO List</h1>
|
|
<P>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.</P>
|
|
<h2>-c option</h2>
|
|
<P>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.</P>
|
|
<h2>Thread Termination</h2>
|
|
<p>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.</p>
|
|
<p>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.</p>
|
|
<h2>Call Encapsulation</h2>
|
|
<p>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.</p>
|
|
<h2>No real Modules yet</h2>
|
|
<p>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</p>
|
|
<ul>
|
|
<li>imudp/omfwd/syslogd.c</li>
|
|
<li>imtcp</li>
|
|
</ul>
|
|
<p>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...? ;)</p>
|
|
<p> </p>
|
|
</body>
|
|
</html>
|