ompgsql

rsyslog 8.22.0 (v8-stable) released

We have released rsyslog 8.22.0.

This release is mostly for maintenance. It has a somewhat improved error output for config file syntax errors, a bugfix for omhiredis and general code cleanup and improvment. The only new function is the added template support for ompgsql.

To get a full overview over the changes, please take a look at the Changelog.
ChangeLog:

Changelog for 7.6.0 (v7-stable)

Version 7.6.0 [v7.6-stable] 2014-01-??
This starts a new stable branch based on 7.5.8 plus the following changes:

  • bugfix: imuxsock input parameters were not accepted due to copy&paste error.
    Thanks to Andy Goldstein for the fix.
  • added ProcessInternalMessages global system parameter
    This permits to inject rsyslog status messages into *another* main syslogd or the journal.
  • new dependency: liblogging-stdlog (for submitting to external logger)
  • bugfix: json templates are improperly created
    Strings miss the terminating NUL character, which obviously can lead to all sorts of problems.
    See also: https://github.com/rsyslog/rsyslog/issues/27
    Thanks to Alain for the analysis and the patch.
  • ompgsql bugfix: improper handling of auto-backgrounding mode
    If rsyslog was set to auto-background itself (default code behaviour, but many distros now turn it off for good reason), ompgsql could not properly connect. This could even lead to a segfault. The core reason was that a PG session handle was kept open over a fork, something that is explicitely forbidden in the PG API.
    Thanks to Alain for the analysis and the patch.

Changelog for 7.4.10 (v7-stable)

Version 7.4.10 [v7.4-stable] 2014-02-12

  • bugfix: json templates are improperly created
    Strings miss the terminating NUL character, which obviously can lead to all sorts of problems.
    See also: https://github.com/rsyslog/rsyslog/issues/27
    Thanks to Alain for the analysis and the patch.
  • ompgsql bugfix: improper handling of auto-backgrounding mode
    If rsyslog was set to auto-background itself (default code behaviour, but many distros now turn it off for good reason), ompgsql could not properly connect. This could even lead to a segfault. The core reason was that a PG session handle was kept open over a fork, something that is explicitely forbidden in the PG API.
    Thanks to Alain for the analysis and the patch.
Scroll to top