After call doHUP(), probably there is a internal log in the list. However, it
will not be wrote out immediately, because the mainloop will be blocked at
pselect in wait_timeout() until a long timeout or next message occur.
More deadly, the log may be lost if the deamon exits unexpectedly.
We might as well put processImInternal() after doHUP(), so that the message
will be flushed out immediately.
Fixes: 723f6fdfa6(rsyslogd: Fix race between signals and main loop timeout)
Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
action.errorfile.maxsize has been added to enable
option to limit the amount of bytes dumped to
configured errorfile
fixes#4733
Signed-off-by: Sergio Arroutbi <sarroutb@redhat.com>
When the pthread library fails, errno is referenced even though errno is not set.
Fix to refer to the return code of the pthread library instead of errno.
In rscript, comparison operations on strings did not work correctly
and returned false results. This is cause by a regression in commit
5cec5dd634e0. While it fixed number comparisons, it introduced new
problems in string comparisons, which were not present before. Note
that most items in rsyslog are strings, so this can actually cause
some problems.
The order of execution was changed to a less optimal (more startups,
thus slower) order to work-around a testbench issue. This has been
fixed and so we can restore the original order.
When bulkmode is enabled, and a batch was processed without any
failures (errors is false), the code that increments the indexSuccess
impstats counter was never reached. As fix, we obtain the numitems
first and add them to the indexSuccess impstats counter if
errors is false.
This fix may solve some of the random elasticsearch testbench failures.
closes: https://github.com/rsyslog/rsyslog/issues/4794
This problem occurred when numbers were used in rsyslog.conf in
the set statement, e.g.
set $nbr = 1234;
In this case, during comparisons, the number was actually interpreted
as a string with digits. Thus numerical comparisons lead to unexpected
results. Even more so, as in other places of the code they were
treated as native numbers.
This is now fixed. We cannot outrule that this causes, in border cases,
change of behavior to existing configs. But it is unlikely and the
previous behaviour was a clear bug and very unintuitive. This in our
opinion it is justified to risk a breaking change for an expected
very minor subset of installations, if any such exists at all.
The fix was combined with code refactoring. We did this, because
the fix itself would have been quite hard to read, and the need
for refactoring became obvious.
closes https://github.com/rsyslog/rsyslog/issues/4770
