rsyslog.git/tools, branch v4.6.2

$OMFileAsyncWriting directive did not work properly

2010-03-25T16:36:50+00:00

new feature: $OMFileAsyncWriting directive added

2010-03-25T14:23:39+00:00

it permits to specifiy if asynchronous writing should be done or not

undo experimental commit dccadb677c5a6b8379f631e4c1f14c8c4089d4a6

2010-03-25T07:13:58+00:00

Further testing turned out that the rsyslog core works correctly and
this fix is not needed. The concurrency we saw was actually caused by
other actions (even processes) during directory creation. See commit
9e5b31fc44136dbcc1e443cfe7714e9daf97d844 for further details.

bugfix: potential segfault in dynafile cache

2010-03-25T06:56:03+00:00

This bug was triggered by an open failure. The the cache was full and
a new entry needed to be placed inside it, a victim for eviction was
selected. That victim was freed, then the open of the new file tried. If
the open failed, the victim entry was still freed, and the function
exited. However, on next invocation and cache search, the victim entry
was used as if it were populated, most probably resulting in a segfault.

streamline dynafile cache entry deletion a bit

2010-03-23T13:21:33+00:00

The old code looks a bit "strange", though not necessarily incorrect.
The new code looks correct and is probably less irritating during bug
hunting.

bugfix: potential re-use of free()ed file stream object in omfile

2010-03-23T13:11:50+00:00

when dynaCache is enabled, the cache is full, a new entry needs to
be allocated, thus the LRU discarded, then a new entry is opend and that
fails. In that case, it looks like the discarded stream may be reused
improperly (based on code analysis, test case and confirmation pending)

previous (experimental) patch was somewhat incorrect, fixed

2010-03-22T13:22:22+00:00

This is what caused the new test to fail...

exp: made omfile ensure that it is not called twice in parallel on the same file instance

2010-03-21T17:52:51+00:00

In theory, the rsyslog core should never call in parallel into an output
module for the same instance. However, it looks like this seems to happen
under (strange?) circumstances. I have now enhanced omfile so that it guards
itself against being called in parallel on the same instance data. This is
done to help troubleshooting and may stay as an interim solution if it
proves to solve an anomaly we see in at least one installation (to trigger
this problem, an extremely large traffic volume is needed).

fixed regression from previos (yet unrelease) $omfileFlushOnTXEnd fix

2010-03-19T08:42:46+00:00

The previous fix fixed an issue with on/off bying used in the exact wrong
semantic. It corrected the situation, but failed to fix one spot where the
wrong semantics were used. This is done with this commit.

Note that this is NOT a bug seen in any released version.

new feature: "." action type added to support writing files to relative pathes

2010-03-17T15:25:24+00:00

(this is primarily meant as a debug aid)