This permits to include files (like legacy $IncludeConfig) via a
script object. Needless to say, the script object offers more
features:
- include files can now be
- required, with rsyslog aborting when not present
- required, with rsyslog emitting an error message but otherwise
continuing when not present
- optional, which means non-present include files will be
skipped without notice
This is controlled by the "mode" parameter.
- text can be included form e.g. an environment variable
--> ex: include(text=`echo $ENVVAR`)
This finally really obsoletes $IncludeConfig.
closes https://github.com/rsyslog/rsyslog/issues/2151
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
Trying to understand CID 185407, which looks like a false positive. On
the way to this, add attributation which could increase correctness of
compiler code unerstanding and trigger different set of error messages.
when rulesets are nested a segfault can occur when shutting down
rsyslog. the reason is that rule sets are destructed in load order,
which means a "later" ruleset may still be active when an "earlier"
one was already destructed. In these cases, a "call" can invalidly
call into the earlier ruleset, which is destructed and so leads to
invalid memory access. If a segfault actually happens depends on the
OS, but it is highly probable.
The cure is to split the queue shutdown sequence. In a first step,
all worker threads are terminated and the queue set to enqOnly.
While some are terminated, it is still possible that the others
enqueue messages into the queue (which are then just placed into the
queue, not processed). After this happens, a call can no longer
be issued (as there are no more workers). So then we can destruct
the rulesets in any order.
closes https://github.com/rsyslog/rsyslog/issues/1122
The opcode was not handled, what lead to misleading messages
in debug log. Since we run debug builds more strictly, it also
causes an assertion to trigger, thus aborting the test.
...and friends. This uses internals of the json library. It was
required when we used json-c, where distros often shipped versions
that did miss its clean counterpart. Now that we require
libfastjson, we can (and should) use the clean method.
closes https://github.com/rsyslog/rsyslog/issues/941
When running with debugging enabled, we'll often see the following
error:
error: unknown stmt type %u during iterateAll
Where "%u" is 4006 or 4007. This patch silences those errors by
adding them to the "ignore" case.
Error: RESOURCE_LEAK (CWE-772):
rsyslog-7.4.10/runtime/ruleset.c:984: alloc_arg: "rulesetConstruct(ruleset_t **)" allocates memory that is stored into "pRuleset".
rsyslog-7.4.10/runtime/ruleset.c:729:1: alloc_fn: Storage is returned from allocation function "calloc(size_t, size_t)".
rsyslog-7.4.10/runtime/ruleset.c:729:1: var_assign: Assigning: "pThis" = "calloc(1UL, 56UL)".
rsyslog-7.4.10/runtime/ruleset.c:729:1: noescape: Resource "pThis" is not freed or pointed-to in function "rulesetInitialize(ruleset_t *)".
rsyslog-7.4.10/runtime/ruleset.c:726:1: noescape: "rulesetInitialize(ruleset_t *)" does not free or save its pointer parameter "pThis".
rsyslog-7.4.10/runtime/ruleset.c:729:1: var_assign: Assigning: "*ppThis" = "pThis".
rsyslog-7.4.10/runtime/ruleset.c:985: noescape: Resource "pRuleset" is not freed or pointed-to in function "rulesetSetName(ruleset_t *, uchar *)".
rsyslog-7.4.10/runtime/ruleset.c:638:43: noescape: "rulesetSetName(ruleset_t *, uchar *)" does not free or save its pointer parameter "pThis".
rsyslog-7.4.10/runtime/ruleset.c:1011: leaked_storage: Variable "pRuleset" going out of scope leaks the storage it points to.
Error: RESOURCE_LEAK (CWE-772):
rsyslog-7.4.10/runtime/ruleset.c:506: alloc_fn: Storage is returned from allocation function "newActive(batch_t *)".
rsyslog-7.4.10/runtime/ruleset.c:220:2: alloc_fn: Storage is returned from allocation function "malloc(size_t)".
rsyslog-7.4.10/runtime/ruleset.c:220:2: return_alloc_fn: Directly returning storage allocated by "malloc(size_t)".
rsyslog-7.4.10/runtime/ruleset.c:506: var_assign: Assigning: "thenAct" = storage returned from "newActive(pBatch)".
rsyslog-7.4.10/runtime/ruleset.c:509: leaked_storage: Variable "thenAct" going out of scope leaks the storage it points to.
Error: RESOURCE_LEAK (CWE-772):
rsyslog-7.4.10/runtime/ruleset.c:326: alloc_fn: Storage is returned from allocation function "newActive(batch_t *)".
rsyslog-7.4.10/runtime/ruleset.c:220:2: alloc_fn: Storage is returned from allocation function "malloc(size_t)".
rsyslog-7.4.10/runtime/ruleset.c:220:2: return_alloc_fn: Directly returning storage allocated by "malloc(size_t)".
rsyslog-7.4.10/runtime/ruleset.c:326: var_assign: Assigning: "newAct" = storage returned from "newActive(pBatch)".
rsyslog-7.4.10/runtime/ruleset.c:362: leaked_storage: Variable "newAct" going out of scope leaks the storage it points to.
Error: RESOURCE_LEAK (CWE-772):
rsyslog-7.4.10/runtime/ruleset.c:373: alloc_fn: Storage is returned from allocation function "newActive(batch_t *)".
rsyslog-7.4.10/runtime/ruleset.c:220:2: alloc_fn: Storage is returned from allocation function "malloc(size_t)".
rsyslog-7.4.10/runtime/ruleset.c:220:2: return_alloc_fn: Directly returning storage allocated by "malloc(size_t)".
rsyslog-7.4.10/runtime/ruleset.c:373: var_assign: Assigning: "newAct" = storage returned from "newActive(pBatch)".
rsyslog-7.4.10/runtime/ruleset.c:376: leaked_storage: Variable "newAct" going out of scope leaks the storage it points to.
This does not cause issues in v7, but here we have the problem
that the total number of actions, which now is required for wti sizing,
is not available at that early stage. So we needed to delay queue
startup until everything is processed (just as it should have been
already!). Note the previously we could have a segfault on first message
when ruleset queues were used.
