Porting advice for gcc 10:
A common mistake in C is omitting <code>extern</code> when declaring a global
variable in a header file. If the header is included by several files it
results in multiple definitions of the same variable. In previous GCC versions
this error is ignored. GCC 10 defaults to <code>-fno-common</code>, which
means a linker error will now be reported. To fix this, use <code>extern</code>
in header files when declaring global variables, and ensure each global is
defined in exactly one C file. As a workaround, legacy C code can be compiled
with -fcommon.
Support added in omfwd as instance parameter:
streamdriver.TlsVerifyDepth
Support added in imtcp as module parameter:
streamdriver.TlsVerifyDepth
Can be 2 or higher.
Support added into ossl driver
Support added into gtls driver
Added testcases for both drivers.
Parameter
streamdriver.TlsVerifyDepth
closes: https://github.com/rsyslog/rsyslog/issues/4035
This patch updates prepareBackground() in tools/rsyslogd.c to reopen any file
descriptors used for random number generation in the child process. This fixes
an issue on Linux systems where the file descriptor obtained for /dev/urandom
by seedRandomNumber() in runtime/srutils.c was left closed after the fork. This
could be observed in procfs, where /proc/fd/ would show no open descriptors to
/dev/urandom in the forked process. /dev/urandom is reopened as the child may be
be operating in a jail, and so should not continue to use file descriptors from
outside the jail (i.e. inherited from the parent process).
I found that this issue led to rsyslog intermittently hanging during seedIV()
in runtime/libgcry.c. After the fork, the closed file descriptor number tended
to get re-assigned. randomNumber() would then read from an incorrect (although
still valid) file descriptor, and could block (depending on the state of that
file descriptor). This gave rise to the intermittent hang that I observed.
Signed-off-by: Simon Haggett <simon.haggett@gmail.com>
The main loop sleeps in a select() call for a long interval in order to
periodically run housekeeping tasks. The main loop is also responsible for
responding to flags set by signal handlers, so this sleeping should be
interrupted by signals so that it can check those flags.
However, a signal could be delivered between when the flags are checked and
when select() is called. In which case the main loop will block for the
full interval (currently 10 minutes) before handling the signal. If this
occurs, it could take up to 10 minutes for rsyslogd to terminate after a
SIGTERM or respond to SIGHUP.
Fix this by blocking signals before checking the flags and using pselect()
to unblock the signals while waiting. This is recommended by the select(2)
manual page to avoid this very issue.
Signed-off-by: John Brooks <jbrooks@ciena.com>
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.
