while we solved valgrind false positives during shutdown in
2700badfda76c701fa9169c31c9ec4f7993dc0b8, we continue to see
related messages for thread-local-storages. Rather than suppressing
these as well we now refactored the code so that it does not use
detached threads.
This shall improve robustness. In case it does not, we have enhanced
debug messages under CI runs, so potentially still-existing problem
areas should be easier to diagnose.
see also https://github.com/rsyslog/rsyslog/issues/2902
The last commit (yesterday) did not properly convey when we actually
needed to cancel a thread. This commit corrects this and also
provides better information on the actual cancel operation and
some tipps for the user on how to solve it (timeout mentioned).
This internal state was improperly handled and most probably caused
(hard to see) issues when action instances were run on multiple worker
threads. It looks like the state variable was forgotten to move over
to worker state when action workers were introduced. This patch
fixes that.
closes https://github.com/rsyslog/rsyslog/issues/2046
I consider the C99 semantics to be pretty broken. Rather than
duplicating code for the inline variant and the non-inline one,
I replace the functions in question by macros. We do not loose
much in terms of type-safety.
see also https://github.com/rsyslog/rsyslog/pull/2246
This function returns a boolean indicating if the previous action is
suspended (0 - no, 1 - yes). This is useful if arbitrary processing
(other than calling actions) should be made depending on that state.
A prime example for this is probably calling a ruleset.
closes https://github.com/rsyslog/rsyslog/issues/1939
This permits script functions that could fail to report errors back, so
that the user can handle them if desired. We use an errno-style of
interface. That means script_error() needs to be called after functions
that supports it. It will return either 0 (all OK) or something else
(an error condition).
The commit also modifies the parse_time() function to use the new
interface. First of all, this is useful for users, and secondly we
needed a capability to craft a testbench test.
closes https://github.com/rsyslog/rsyslog/issues/1978
During e.g. shutdown it could happen that a worker thread was started
and immediately be requested to terminate. In such situations there was
a race the prevented proper initialization. This could lead to follow-on
problems.
We believe (but could not proof) that this also could lead to a hang of
the termination process. Thus we claim to close an issue tracker down
here below, but are not 100% certain it really closes it (we hope for
user feedback on this). In any case, the thread debuger showed invalid
operations and this has been fixed, so it is useful in any case.
closes https://github.com/rsyslog/rsyslog/issues/1959
The action engine does not emit "action suspended" messages but "resumed"
ones in retry processing. This is wrong, as they are a strong indication
that something does not work correctly. Nevertheless, "resumed" messages
were emitted, which was very puzzling for the user.
This patch fixes it so that "suspend" messages are given during retry
processing. These do not contain a retry timestamp, providing evidence
that a retry is currently being tried.
closes https://github.com/rsyslog/rsyslog/issues/1069
As it seems, different C compilers have different rules/interpretations
on inline functions. The current code base did not properly obey all C99
rules. We fix this by converting some functions to macros and others to
include the necessary C99 plumbing. We also remove some inline attributes
for functions where this seems to be to agressive (aka "function to big").
This fixes build problems in some environments and is a general code
cleanup measure.
This was a rather complicated merge as we needed to migrate some
per-action settings (v7) to action instance settings (v8).
Conflicts:
action.c
action.h
doc/global.html
runtime/glbl.c
We now re-use once allocated string template memory for as long
as the worker thread exists. This saves us from doing new memory
allocs (and their free counterpart) when the next message is
processed. The drawback is that the cache always is the size of
the so-far largest message processed. This is not considered a
problem, as in any case a single messages' memory footprint should
be far lower than that of a whole set of messages (especially on
busy servers).
