The rsyslog engine did not guard itself against output modules that do
not properly convey back the tryResume() behaviour. This then leads to
what looks like an endless loop. I consider this to be a bug of the
engine not only because it should be hardened against plugin misbehaviour,
but also because plugins may not be totally able to avoid this situation
(depending on the type of and processing done by the plugin).
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)
- bugfix: queues in direct mode could case a segfault, especially if an
action failed for action queues. The issue was an invalid increment of
a stack-based pointer which lead to destruction of the stack frame and
thus a segfault on function return.
Thanks to Michael Biebl for alerting us on this problem.
[backport from 5.5.2]
- bugfix: wrong memory assignment for a config variable (probably
without causing any harm) [backport from 5.2.2]
another milestone commit: the program works, the new interface
is used, some more cleanup is needed and the per-ruleset config
options are still missing. But we are getting closer...
... but this brings a lot of problems with it. The issue is that
we still have a sequential store and we do not know how we could
delete the one entry right in the middle of processing. I keep this
branch if we intend to move on with it - but for now I look into a
different solution...
however, this had no negative effect, as the message processing state
was not evaluated when a batch was deleted, and that was the only case
where the state could be wrong.
simplified and thus speeded up the queue engine, also fixed some
potential race conditions (in very unusual shutdown conditions)
along the way. The threading model has seriously changes, so there may
be some regressions.
NOTE: the code passed basic tests, but there is still more work
and testing to be done. This commit should be treated with care.
this option permites to process mark messages under all circumstances,
even if an action was recently called. This can be useful to use mark
messages as a kind of heartbeat.
optimized substring processing, should bring a small enhancement when
forwarding with the default forwarding templates. Also did some uchar
cleanup in msg.c (thus so many changes, in reality they are few...).
It is intentionally quick & dirty, as I would like to do some
better patch, if possible. For that, I probably need the commented-out
code, thus no delete.
this bug was introduced by a recent change which was a bit too agressive
in avoiding locking. We can probably do better than with this patch, but
I think I'll move that into the v5 engine.
the string area that is used to build the string being passed to
the output module is now part of the action structure. As such,
access to it must also be guarded by the action mutex (an even more
optimal solution may be to store it in thread-local storage, but
there always must remain some room for improvement ;)).
This was a complex manual merge, especially in action.c. So if
there occur some problems, this would be a good point to start
troubleshooting. I run a couple of tests before commiting and
they all went well.
Conflicts:
action.c
action.h
runtime/queue.c
runtime/queue.h
runtime/wti.c
runtime/wti.h
Note that this was NOT a trivial merge, and there may be
some issues. This needs to be seen when we continue developing.
Conflicts:
runtime/msg.h
runtime/obj.h
runtime/queue.c
runtime/srUtils.h
runtime/stream.c
runtime/stream.h
runtime/wti.c
tests/Makefile.am
tools/omfile.c
tools/syslogd.c
also adds speed, because you do no longer need to run the whole file
system in sync mode. New testbench and new config directives:
- $MainMsgQueueSyncQueueFiles
- $ActionQueueSyncQueueFiles
So far, the consumer was responsible for destroying objects. However, this
does not work well with ultra-reliable queues. This is the first move to
support them.
- added $GenerateConfigGraph configuration command which can be used
to generate nice-looking (and very informative) rsyslog configuration
graphs.
- added $ActionName configuration directive (currently only used for
graph generation, but may find other uses)
The action state machine now works correctly and has been verified a
few hand-picked cases. I am missing automatted tests, though, this is
not easy to achive... Anyhow, I've improved omtesting, so that it can
be used in such automatted tests.
