From 8eceb79ccdd1177a89c30a386916b64ef4df433b Mon Sep 17 00:00:00 2001 From: Rainer Gerhards Date: Tue, 12 Feb 2008 14:49:40 +0000 Subject: updated some trackers; changed tracking system --- doc/bugs.html | 39 ++++++--------------------------------- doc/features.html | 34 +++++----------------------------- 2 files changed, 11 insertions(+), 62 deletions(-) diff --git a/doc/bugs.html b/doc/bugs.html index 8f775600..a12c43f3 100644 --- a/doc/bugs.html +++ b/doc/bugs.html @@ -4,37 +4,14 @@

rsyslog bugs and annoyances

This page lists the known bugs rsyslog has to offer. Please note that -we also have a - -bug tracker at sourceforge.net. This list here contains more architectural -things while the bug tracker most often lists things that you will actually -experience. Please be sure to visit the bug tracker in addition to this list -here.

This list has last been updated on 2007-07-30 by +

This page lists the known bugs rsyslog has to offer. It lists +old and esoteric bugs. A live list of bugs is contained in our bugzilla. +Please visit +http://www.rsyslog.com/bugs to see what we +have. There, you can also open your own bug report if you think you found one.

This list has last been updated on 2008-02-12 by Rainer Gerhards.

rsyslogd

stability in multithreaded mode

We have some reports that rsyslogd, if compiled with multi-threading enabled, -segfaults in some environments. We are actively looking at fixing this issue, -but as it does not occur in our lab environment, that unfortunately takes some -time. If you experience a segfault, please report it. As a work-around, you can -compile rsyslog without multi-threading:

./configure --disable-pthreads
-make clean
-make
-make install

This somewhat reduces the ability to handle large message bursts, but even in -single-threaded mode rsyslogd offers great performance (just think that stock -sysklogd has always been using a single thread, only).

forwarding remotely received messages

Sysklogd does not forward remotely received messages to other network -destination except when the -h option is given. This code is currently defunct. -No matter if -h is specified or not, messages are ALWAYS forwarded. It is -currently under review if the sysklogd's functionality is actually needed. -Please see my -blog -post on this topic for further detail.

EQUALLY-NAMED TEMPLATES

If multiple templates with the SAME name are created, all but the first definition is IGNORED. So you can NOT (yet) replace a @@ -46,10 +23,6 @@ names...).

This format is actually not 100% compatible with stock syslogd - the date is missing. Will be fixed soon and can also be fixed just via the proper template. Anyone up for this? ;)

SIGPIPE HANDLING

Currently, SIGPIPE is ignored. This is necessary to handle broken TCP - connections. We should further look into this issue and see which other - ways exist to handle the situation.

MULTIPLE INSTANCES

If multiple instances are running on a single machine, the one with the -r switch must start first. Also, UDP-based syslog forwarding between the diff --git a/doc/features.html b/doc/features.html index 2899cd76..c71194dc 100644 --- a/doc/features.html +++ b/doc/features.html @@ -53,36 +53,12 @@ is going on, you can also subscribe to the feature -request tracker at sourceforge.net. This tracker has things typically within +feature +request tracker at our bugzilla. This tracker has things typically within reach of implementation. Users are encouraged to submit feature requests there -(or via our forums). If we like them but they look quite long-lived (aka "not -soon to be implemented"), they will possibly be migrated to this list here and -at some time moved back to the sourceforge tracker.

create a plug-in-interface - we are very close to this. A neat interface is - already used internally for output modules and the MySQL module already - works as a plug-in. However, no interface definition is yet formally - published.
implement native email-functionality in - selector (probably best done as a plug-in)
port it to more *nix variants - (eg AIX and HP UX) - this needs volunteers with access to those machines and - knowledge
provide an on-disk queue for syslog messages; should be - combined with reliable delivery to the next hop
support for native SSL enryption of plain tcp syslog sessions. This will - most probably happen based on syslog-transport-tls.
even more enhanced multi-threading, - with a message queue for each action (when implementing this, search - for CHECKMULTIQUEUE comments in the source - they already contain hints of - what to look at). Some detail information on this can already be found in - - Rainer's blog.
pcre filtering - maybe (depending on feedback) - simple regex already - partly added. So far, this seems sufficient so that there is no urgent need - to do pcre
support for RFC 3195 as a sender - this is currently unlikely to happen, because there is no real - demand for it. Any work on RFC 3195 has been suspend until we see some real - interest in it. It is probably much better to use TCP-based syslog, - which is interoperable with a large number of applications. You may also - read my blog post on the future of liblogging, which contains interesting - information about the - - future of RFC 3195 in rsyslog.

+(or via our forums). Please note that rsyslog v2 is feature-complete. New +features will be implemented in the v3 branch only. Version 3 already has a +number of very exciting additional features.

To see when each feature was added, see the rsyslog change log (online only).

-- cgit