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
In theory, TZ should be set by the OS. Unfortuantely, this seems
to be not the case any longer on many Linux distros. We now check
it and set it appropriate if not already given.
closes https://github.com/rsyslog/rsyslog/issues/2054
This parser is used whenever a module (e.g. omprog) needs to process
command lines. On each action definitions for actions that use the
parser a small amount of memory was leakd. It is an uncritical leak
as it only occurs during config parsing. So it leaks a couple of
KiB during startup but does not grow during actual message processing.
This is a regression in 8.32.0.
This parser is used whenever a module (e.g. omprog) needs to process
command lines. If command parameters were given, memory misadressing
occured. This could lead to a segfault.
This is a regression in 8.32.0.
closes https://github.com/rsyslog/rsyslog/issues/2408
It can be useful to ctl-c out of rsyslog, even if it is started via
-n, especially inside containers. The new config setting permits
to enable this capability.
closes https://github.com/rsyslog/rsyslog/issues/533
The currently done buffer modification (add of '\0') is bad, especially when
multiple threads access the same string. It is not really an issue that needs
to be urgently fixed, as always the same data is written. However, among others,
it will pollute the thread debugger and as such prevent more elaborate automatted
tests.
closes https://github.com/rsyslog/rsyslog/issues/1993
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 helps to diagnose issue - unfortunately we need more
work to ensure that the messages always make it to the user. This
is a start and hopefully useful at least for the testbench, possibly
more.
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