rsyslog.git/runtime, branch v5.6.5

Merge branch 'v4-stable' into tmp

2011-03-09T12:02:17+00:00

backporting abort condition fix from 5.7.7

2011-03-02T13:10:08+00:00

bugfix: fixed a memory leak and potential abort condition

2011-02-25T13:23:25+00:00

this could happen if multiple rulesets were used and some output batches
contained messages belonging to more than one ruleset.
fixes: http://bugzilla.adiscon.com/show_bug.cgi?id=226
fixes: http://bugzilla.adiscon.com/show_bug.cgi?id=218

bugfix: memory leak when $RepeatedMsgReduction on was used

2011-02-25T10:05:57+00:00

bug tracker: http://bugzilla.adiscon.com/show_bug.cgi?id=225

bugfix: abort if imfile reads file line of more than 64KiB

2011-02-10T16:54:09+00:00

Thanks to Peter Eisentraut for reporting and analysing this problem.
bug tracker: http://bugzilla.adiscon.com/show_bug.cgi?id=221

Merge branch 'v4-stable' into v5-stable

2011-01-26T11:38:02+00:00

imfile bugfix: potential duplication of log content

2011-01-10T07:22:50+00:00

Under some circumstances an invalid truncation was detected. This
code has now been removed, a file change (and thus resent) is only
detected if the inode number changes.

forgot the actual patch with the last commit :(

2010-12-17T17:34:39+00:00

bugfix: imfile potentially duplicates lines

2010-12-17T17:18:57+00:00

This can happen when 0 bytes are read from the input file, and some
writer appends data to the file BEFORE we check if a rollover happens.
The check for rollover uses the inode and size as a criterion. So far,
we checked for equality of sizes, which is not given in this scenario,
but that does not indicate a rollover. From the source code comments:
   Note that when we check the size, we MUST NOT check for equality.
   The reason is that the file may have been written right after we
   did try to read (so the file size has increased). That is NOT in
   indicator of a rollover (this is an actual bug scenario we
   experienced). So we need to check if the new size is smaller than
   what we already have seen!

bug fixes in action processing

2010-12-17T09:43:55+00:00

- bugfix: action processor released mememory too early, resulting in
  potential issue in retry cases (but very unlikely due to another
  bug, which I also fixed -- only after the fix this problem here
  became actually visible).
- bugfix: batches which had actions in error were not properly retried in
  all cases