Triggering condition:
- action queue in disk mode (or DA)
- batch is being processed by failed action in retry mode
- rsyslog is shut down without resuming action
In these cases messages may be lost by not properly writing them
back to the disk queue.
closes https://github.com/rsyslog/rsyslog/issues/2760
Added them after intensive checking that these are indeed false positives.
Among other, checks via TSAN as well as intensive manual debugging of that
issue. Also, no other platform shows the issues. So I conclude that it is
safe to suppress it.
when writing disk queue files during shutdown, access to freed
memory can occur under these circumstances:
- action A is processing data, but could not complete it
most importantly, the current in-process batch needs not to
be totally completed. Most probable cause for this scenario
is a suspended action in retry mode.
- action A is called from a ruleset RA which
- does not have a queue assigned
- where RA is called from a ruleset RO which is bound
to the input from which the message originated
- RO must be defined before RA inside the expanded config
- Disk queues (or the disk part of a DA queue) must be utilized
by A
When re-injecting the unprocessed messages from A into the disk queue, the
name of ruleset RO is accessed (for persisting to disk). However, RO is
already destructed at this point in time.
The patch changes the shutdown processing of rulesets, so that all
shutdown processing is done before any ruleset data is destructed. This
ensures that all data items which potentially need to be accessed
remain valid as long as some part may potentially try to access them.
This follows a the approach used in
https://github.com/rsyslog/rsyslog/pull/1857
where obviously that part of the problem was not noticed.
see also https://github.com/rsyslog/rsyslog/issues/1122
closes https://github.com/rsyslog/rsyslog/issues/2742
Make the skeleton easier to understand by removing transaction support.
Also, transaction failures did not work as explained in the skeleton,
because of issue #2420. In the future, a 'plugin-with-transactions.py'
example can be added, ideally once the issue is solved.
When authmode is configured, it is checked if the value is
valid, before using it.
If the value is invalid an error message is put out.
closes https://github.com/rsyslog/rsyslog/issues/2743
https://github.com/rsyslog/rsyslog/issues/2721
Was not working on python3 - must use `encode()` to convert the
string to a `bytes` object.
Also run the server with python -u to make sure we get the log
output from the kubernetes test server.
Based on discussion, the error level is being adjusted to reflect
that the action (reloading the lookup table) is normal/expected
and not an actual error condition.
refs rsyslog/rsyslog#2713
When the option is set and a new file is created after rsyslog startup,
freshStartTail is also applied to it. That is data written quickly to it
(before rsyslog can process it) will potentially be discarded. If so,
and how much, depends on the timing between rsyslog and the logging process.
This problem is most likely to be seen in polling mode, where a relatively
long time may be required for rsyslog to find the new file.
This is changed so that now freshStartTail only applies to files that
are already-existing during rsyslog's initial processing of the file
monitors. HOWEVER, depending on the number and location (network?) of
existing files, this initial startup processing may take some time as
well. If another process creates a new file at exactly the time of
startup processing and writes data to it, rsyslog might detect this
file and it's data as prexisting and may skip it. This race is inevitable.
So when freshStartTail is used, some risk of data loss exists. The same
holds true if between the last shutdown of rsyslog and its restart log
file content has been added. This is no rsyslog bug if it occurs.
As such, the rsyslog team advises against activating the freshStartTail
option.
closes https://github.com/rsyslog/rsyslog/issues/2464
