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. I am working to combine the two lists, but for now you need to visit both.

This list has last been updated on 2005-09-26 by Rainer Gerhards.

rsyslogd

multi-threading and BSD

Multi-threading does currently not work reliably on BSD, at least not upon program termination. It looks like this is related with the way BSD handles signals. I am currently looking at it. In the mean time, compile BSD builds without threading support (the default).

REPEATED LOG LINES

If multiple log lines with the exact same content are received, the duplicates are NOT suppressed. This is done by sysklogd in all cases. We plan to add this as an optional feature, but as of now every line is logged.

ERRORS ON STARTUP

Error reporting on startup is not particular good. We handle all errors correctly, but sometimes a message is only reported if running in debug mode. If you experience some strange behaviour I suggest to run the syslogd interactively with debugging enabled. As of August, 2005, the situation has much improved. Keep in mind, thought, that debug mode is your friend ;)

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 template definition. I also strongly doubt I will ever support this, because it does not make an awful lot of sense (after all, why not use two template names...).

MEMORY LEAK ON HUPING

Currently, the template memory is NOT freed when SIGHUP is received. This causes a small memory leak on each HUP. Will be fixed soon and should not cause real trouble unless you HUP syslogd quite frequently.

WALLMSG FORMAT (* selector)

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 instances does not work. Use TCP instead.