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.
Using str...() family of functions is unsafe on objects not declared
to be strings. This was pretty old code. Gcc 8 warnings brought up
the problem. So it looks there were no problem in practice (as it work
for ~30 years).
This happens if utmp.h and friends are not available and stems back to
the original syslogd. Nowadas, 32 is more appropriate and now being used
in that (now very unlikely) case. The detection logic for UT_NAMESIZE has
also been streamlined.
closes https://github.com/rsyslog/rsyslog/issues/2834
This provides a new-style alternative to $AbortOnUncleanConfig.
Note that a testbench test was changed to the new syntax. Adding
an additional test did not look useful, as the testbench still
sufficiently tests old and new method.
closes https://github.com/rsyslog/rsyslog/issues/2744
Liblogging-stdlog was introduced to provide a broader ability to send rsyslog
internal logs to different sources. However, most distros did not pick up
that capability and so instead we do a regular syslog() call. We assume that
the actual functionality is never used in practice, so we plan to retire it.
That makes building rsyslog from source easier.
The plan is to disable use of liblogging-stdlog by default during
configure. So users (and distros!) can still opt-in to have it enabled if
they desire.
A couple of releases later, we want to completely remove the functionality,
except if there has desire been shown in the meantime which justifies to keep
liblogging-stdlog.
This patch is for disabling liblogging-stdlog by default. We now also
emit a warning message ("liblogging-stdlog will go away") so that users
know what is going on and my react.
closes https://github.com/rsyslog/rsyslog/issues/2705
see also https://github.com/rsyslog/rsyslog/issues/2706
In the community we frequently discuss handling of oversize messages.
David Lang rightfully suggested to create a central capability inside
rsyslog core to handle them.
We need to make a distinction between input and output messages. Also,
input messages frequently need to have some size restrictions done at
a lower layer (e.g. protocol layer) for security reasons. Nevertheless,
we should have a central capability
* for cases where it need not be handled at a lower level
* as a safeguard when a module invalidly emits it (imfile is an example,
see https://github.com/rsyslog/rsyslog/pull/2632 for a try to fix it
on the module level - we will replace that with the new capability
described here).
The central capability works on message submission, and so cannot be
circumvented. It has these capabilities:
* overisze message handling modes:
- truncate message
- split message
this is of questionable use, but also often requested. In that mode,
the oversize message content is split into multiple messages. Usually,
this ends up with message segments where all but the first is lost
anyhow as the regular filter rules do not match the other fragments.
As it is requested, we still implemented it.
- accept message as is, even if oversize
This may be required for some cases. Most importantly, it makes
quite some sense when writing messages to file, where oversize
does not matter (accept from a DoS PoV).
* report message to a special "oversize message log file" (not via the
regular engine, as that would obviously cause another oversize message)
This commit, as the title says, handles oversize INPUT messages.
see also https://github.com/rsyslog/rsyslog/issues/2190
closes https://github.com/rsyslog/rsyslog/issues/2681
closes https://github.com/rsyslog/rsyslog/issues/498
Note: this commit adds global parameters:
* "oversizemsg.errorfile",
is used to specify the location of the oversize message log file.
* "oversizemsg.report",
is used to control if an error shall be reported when an oversize
message is seen. The default it "on".
* add global parameter "oversizemsg.input.mode"
is used to specify the mode with which oversized messages will
be handled.
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
To allow the same source address to be used regardless of the egress
interface taken, an option is added for an address to bind the datagram
socket to. Similarly to imudp, it is necessary to add an ipfreebind
option which is set by default, so as to avoid an excess of errors at
startup before the network interface has come up. This enhancement
allows a usecase on networking devices, by which a source interface
that is typically a loopback is specified, on which an address to bind
to is configured. This is so that the same source address is used for
all packets from rsyslog. Support for the TCP case can be added later.
Signed-off-by: Mike Manning <mmanning@att.com>
as it looks, some compiler versions (e.g. gcc 7) seem to be rather
picky on the position where this attribute is applied. So this
commit moves them to the position where they are properly detected.
We also add missing attributes. Some are missing due to conditional
compilation what we did not detect in our regular development
environments. This now comes up as we have enabled the corresponding
warning globally, and so they now also show up on those platforms.
Expression is actually constant under given code. To be on the safe
side for future code changes, I put in a guard assert().
detected by lgtm.com static analyzer
