rsyslog 5.8.6 (v5-stable) released

This is a maintenance release offering bug fixes. For example for a small bug in property-based filter and a fix for $ActionExecOnlyOnce and more .For more detailed information, please read the changelog.

ChangeLog:

http://www.rsyslog.com/changelog-for-5-8-6-v5-stable/

Download:

http://www.rsyslog.com/rsyslog-5-8-6-v5-stable/

As always, feedback is appreciated.

Best regards,

Tim Eifler

Sending messages with tags larger than 32 characters

The relevant syslog RFCs 3164 and 5424 limit the syslog tag to 32 characters max. Messages with larger tag length are malformed and may be discarded by receivers. Anyhow, some folks sometimes need to send tags longer than permitted.

To do so, a new template must be created and used when sending. The simplest way is to start with the standard forwarding template. The standard templates are hardcoded inside rsyslog. Thus they do not show up in your configuration file (but you can obtain them from the source, of course). In 5.8.6, the forwarding template is defined as follows:

template (name="ForwardFormat" type="string" string="<%PRI%>%TIMESTAMP:::date-rfc3339% %HOSTNAME%
%syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%")

NOTE: all templates are on one line in rsyslog.conf. They are broken here for readability.

This template is RFC-compliant. Now look at the part in red. It specifies the tag. Note that, via the property replacer, it is restricted to 32 characters (from position 1 to position 32 inclusive). This is what you need to change. To remove the limit … just remove it ;-) This leads to a template like this:

template (name="LongTagForwardFormat" type="string" string="<%PRI%>%TIMESTAMP:::date-rfc3339% %HOSTNAME%
%syslogtag%%msg:::sp-if-no-1st-sp%%msg%")

Note that I have renamed the template in order to avoid conflicts with build-in templates. As it is a custom template, it is not hardcoded, so you need to actually configure it in your rsyslog.conf. Then, you need to use that template if you want to send messages to a remote host. This can be done via the usual way. Let’s assume you use legacy plain TCP syslog. Then the line looks as follows:

action(type="omfwd" 
Target="server.example.net"
Port="10514"
Protocol="tcp"
Template="LongTagForwardFormat"
)

This will bind the forwarding action to the newly defined template. Now tags of any size will be forwarded. Please keep in mind that receivers may have problems with large tags and may truncate them or drop the whole message. So check twice that the receiver handles long tags well.

Rsyslog supports tags to a build-defined maximum. The current (5.8.6) default is 511 characters, but this may be different if you install from a package, use a newer version of rsyslog or use sources obtained from someone else. So double-check.

Changelog for 5.8.6 (v5-stable)

Version 5.8.6  [V5-stable] 2011-10-21

  • bugfix: missing whitespace after property-based filter was not detected
  • bugfix: $OMFileFlushInterval period was doubled – now using correct value
  • bugfix: ActionQueue could malfunction due to index error
    Thanks to Vlad Grigorescu for the patch
  • bugfix: $ActionExecOnlyOnce interval did not work properly
    Thanks to Tomas Heinrich for the patch
  • bugfix: race condition when extracting program name, APPNAME, structured data and PROCID (RFC5424 fields) could lead to invalid characters e.g. in dynamic file names or during forwarding (general malfunction of these fields in templates, mostly under heavy load)
  • bugfix: imuxsock did no longer ignore message-provided timestamp, if so configured (the *default*). Lead to no longer sub-second timestamps.
    closes: http://bugzilla.adiscon.com/show_bug.cgi?id=281
  • bugfix: omfile returns fatal error code for things that go really wrong previously, RS_RET_RESUME was returned, which lead to a loop inside the rule engine as omfile could not really recover.
  • bugfix: imfile did invalid system call under some circumstances when a file that was to be monitored did not exist BUT the state file actually existed. Mostly a cosmetic issue. Root cause was incomplete error checking in stream.c; so patch may affect other code areas.
  • bugfix: rsyslogd -v always said 64 atomics were not present
    Thanks to mono_matsuko for the patch

rsyslog 6.3.6 (v6-devel) released

We have just released a new development version of rsyslog v6. This is primarily a maintenance release fixing a really annoying problem with reading the config file.

ChangeLog:

http://www.rsyslog.com/changelog-for-6-3-6-v6-devel/

Download:

http://www.rsyslog.com/rsyslog-6-3-6-v6-devel/

As always, feedback is appreciated.

Best regards,
Florian Riedl

rsyslog 4.8.0 (v4-stable) released

There are no changes compared to 4.7.5, just a re-release with the new version number as new v4-stable. The most important new feature (for the v4-stable branch!) is Solaris support.

Note: major new development to v4 is concluded  and will only be done for custom projects.

ChangeLog:

http://www.rsyslog.com/changelog-for-4-8-0-v4-stable/

Download:

http://www.rsyslog.com/rsyslog-4-8-0-v4-stable/

As always, feedback is appreciated.

Best regards,
Tim Eifler

Scroll to top