imudp introduced it's own (feature-limited) rate-limiting capability for
message on disallowed senders before we had central rate-limiters
inside rsyslog. Also, that code evolved from running on a single
thread to running on multiple threads, which introduced data races
and so made unreliable.
Now we removed the old rate-limiting capability and depend on the
system rate limiter for internal rsyslog messages.
closes https://github.com/rsyslog/rsyslog/issues/2467
While extremely unlikely, imuxsock could abort if a file descriptor
> 1024 was received during the startup phase (never occured in
practice, but theoretically could if imfile monitored a large number
of files and were loaded before imuxsock - and maybe other
strange cases).
see also https://github.com/rsyslog/rsyslog/issues/2615
The modules used strtok(), which is not thread-safe. So it will potentially
segfault when multiple instances are spawned (what e.g. happens on busy
systems).
This patch replaces strtok() with its thread-safe counterpart
strtok_r().
see also https://github.com/rsyslog/rsyslog/issues/1359
The preloaded library causes some side-effect, which we so far
did not find. We try to avoid making CI always fail, and so we
skip the test on FreeBSD for now.
Until now maxDataSize was not set correctly because of the
following order of events.
* MaxMessageSize default value is set.
* MaxDataSize default value is set by maxMessageSize.
* Only now maxMessageSize is set as the configured value.
Because of that, maxDataSize never had the configured maxMessageSize value.
See: https://github.com/rsyslog/rsyslog/issues/1782#issuecomment-352027757
Now maxMessageSize is set before being used by maxDataSize as default, as
described here:
https://github.com/rsyslog/rsyslog/pull/1525#issuecomment-384179393
provide better error messages and make sure errors detected by
the script optimizer are also output if rsyslog aborts early
due to config error.
Also a bit of code improvement (errno etc).
The following errors must be made in rsyslog.conf:
* no action present
* a call statement is used on an undefined ruleset
In this case, rsyslog emits an error message on the missing actions and
then segfaults. Depending on memory layout, it may also continue to run
but do nothing except accepting messages as no action is configured.
This patch make rsyslog properly terminate after the error message. It
is a change in behavior, but there really is no reason why a defunct
instance should be kept running.
closes https://github.com/rsyslog/rsyslog/issues/2399
When a "call" script statement was used with a non-existing ruleset AND
debug logginf was active for rainerscript.c, valgrind complained and
one debug message could potentially be incorrect (stating a queue
where non was).
This was caused by not initializing a variable which was probed in
debug mode before it was set. Non-debug mode was not affected.
see also https://github.com/rsyslog/rsyslog/issues/2399#issuecomment-384890873
