This commit adds to new flags which can be set to allow
1) checking of extendedKeyUsage certificate field
2) stricter checking of certificate name/adresses
When the janitor cleans out timed-out files, it does not
properly indicate the entry is gone. Especially when running
in async mode this can lead to use-after-free and thus
memory corruption or segfault.
see also https://github.com/rsyslog/rsyslog/issues/3756
If there is a burst of log messages during a time when rsyslog is unable
to output (either during log rotation, an out-of-space condition, or
some other similar condition), rsyslog can SEGFAULT due to a mutex
double-unlock.
when omfile was HUPed it did not sufficiently clear all dynafile
cache maintenance data structures. This usually lead to misadressing
and could result in various issues, including a hang of rsyslog
processing or segfaults. It could also have "no effect" by pure
luck of not hitting anything important. This actually seems to
have been the most frequent case.
This seems to be a long-standing bug, but the likelyhood of its
appearance seems to have been increased by commit 62fbef7
introduced in 8.1905. Note: the commit itself has no regression,
just increases the likelyhood to trigger the pre-existing bug.
special thanks to Alexandre Guédon for his help in analyzing
the issue - without him, we would probably still not know
what actually went wrong.
closes https://github.com/rsyslog/rsyslog/issues/3686
also fix a problem in handling this parameter when rsyslog processed
internal messages itself (it did not work). As the parameter was
introduced today, we do not flag this follow-up commit as "bugfix".
The issue was noticed when we added the additional tests.
see also https://github.com/rsyslog/rsyslog/issues/3650
see also https://github.com/rsyslog/rsyslog/issues/3639
root cause seems to be that SIGTERM is delivered differently under
FreeBSD. This causes the main thread to not be awaken, and so it
takes until the next janitor interval to come back to life - which
can be far too long. Fixed this bug explicitley awaking the main
thread.
also
* re-enable test that did not work because of this
* fix invalid message on SIGTERM in debug log
permits to specify a severity filter for internal message. Only
messages with this severity level or more severe are logged.
Orignally this was done in rsyslog.conf as usual: you can filter
rsyslog messages on severity, just like any other. But with systemd,
we now emit primarily to the journal, and this is outside of rsyslog's
rule engine and so regular filters do not apply (at least in regard
to the journal). Logging to journal is good, because finally
folks begin to see the messages (traditional distro configs discard
them, for whatever is the reason).
This commit implements a global setting for a severity-based filter
for internal messages, before submitted to journal. So it's not 100%
of what rsyslog can do, but at least some way to customize.
see also https://github.com/rsyslog/rsyslog/issues/3639
The flush was only done to the last dynafile in use at end of
transactions. Dynafiles that were also modified during the
transaction were not flushed.
Special thanks to Duy Nguyen for pointing us to the bug and
suggesting a solution.
This commit also contains a bit of cosmetic cleanup inside
the file stream class.
closes https://github.com/rsyslog/rsyslog/issues/2502
Introduces the capability to create an output config file that explodes
all "includes" into a single file. This provides a much better overview
of how exactly the configuration is crafted. That could often be a great
troubleshooting aid.
This commit also contains some slight not-really-related cleanup.
closes https://github.com/rsyslog/rsyslog/issues/3634
These options generate warning messages that they will go away
for years now. Nobody has complained about this fact (the message
request that). So we assume it is safe to finally remove them.
This helps to clean up rsyslog code and remove unneeded cruft.
Add new global setting 'reportChildProcessExits' with possible values
'none|errors|all' (default 'errors'), and new global function
'glblReportChildProcessExit' to report the exit status of a child
process according to the setting.
Invoke the report function whenever rsyslog reaps a child, namely in:
- rsyslogd.c (SIGCHLD signal handler)
- omprog
- mmexternal
- srutils.c (execProg function, invoked from stream.c and omshell)
Remove redundant "reaped by main loop" info log in omprog.
Promote debug message in mmexternal indicating that the child has
terminated prematurely to a warning log, like in omprog.
Closes#3281
The new Option can have one of the following values:
on = Expired certificates are allowed
off = Expired certificates are not allowed
warn = Expired certificates are allowed but warning will be logged (Default)
Includes necessary tests to validate new code.
closes https://github.com/rsyslog/rsyslog/issues/3364
gtls and ossl driver used a default buffersize of 8 x 1024 bytes to store
received TLS packets. When tls read returned more than buffersize, the additional
buffer was not processed until new data arrived on the socket again.
TLS RFCs require up to 16KB buffer for a single TLS record.
closes https://github.com/rsyslog/rsyslog/issues/3325
When liblogging-stdlog was available but configure option "--disable-liblogging-stdlog"
was set, rsyslog was still linking against liblogging-stdlog.
This commit will ensure that rsyslog will only link against liblogging-stdlog when
"--enable-liblogging-stdlog" was set.
Bug: https://bugs.gentoo.org/667836
This happens only during auto-backgrouding, where we cannot any longer
access stderr. Whatever is opened with fd2 receives some debug messages.
Note that the specific feature is usually turned on only in CI runs.
On Linux it seems common that the TZ variable is NOT properly set.
There are some concerns that the warning related to rsyslog correcting
this confuses users. It also seems that the corrective action rsyslog
takes is right, and so there is no hard need to inform users on that.
In Linux containers, however, the warning seems to be useful as the
timezone setup there seems to be frequently-enough different and
rsyslog's corrective action may not be correct.
So we now check if we are running under Linux and not within a container.
If so, we do not emit the warning. In all other case, we do. This is
based on the assumption that other unixoid systems still should have
TZ properly set.
closes https://github.com/rsyslog/rsyslog/issues/2994
When rsyslog is not run as a service (under SRC control), HUP does not
awake the main loop timeout. In theory, it should do so, but in practice
this does not happen. As a work-around we now implement a kind of
ressource-saving busy waiting where we awake every half second to check
if HUP (or something else noteworthy) happened. This should not cause
any real issue in any case, because running rsyslog as a non-service
is very uncommon and probably only happens during testbench runs.
closes https://github.com/rsyslog/rsyslog/issues/2997
The config plumbing itself provides an error message. The one given here
was also totally wrong ;-)
Thanks to Frank Bicknell for spotting this message and making me alert.
