This commit applies the new canonical formatting style using `clang-format` with custom settings (notably 4-space indentation), as part of our shift toward automated formatting normalization.
⚠️ No functional changes are included — only whitespace and layout modifications as produced by `clang-format`.
This change is part of the formatting modernization strategy discussed in:
https://github.com/rsyslog/rsyslog/issues/5747
Key context:
- Formatting is now treated as a disposable view, normalized via tooling.
- The `.clang-format` file defines the canonical style.
- A fixup script (`devtools/format-code.sh`) handles remaining edge cases.
- Formatting commits are added to `.git-blame-ignore-revs` to reduce noise.
- Developers remain free to format code however they prefer locally.
The previous approach was more or less delay based. We have now
changed the code to enable imdiag to detect if HUP is underway
and wait until it is completed. The new method still employs some
kind of timeout, but is now quite reliable. Most importantly,
it works great with long-running HUP processing, which can happen
e.g. when querying the system name takes long or some actions need
longer time to persist their HUP processing.
The new approach will most likely reduce CI flakes and also speed
up testbench runs. The speedup happens from not having to wait a
full delay in cases where we detect HUP is completed (plus reduced
timeout when we cannot clearly detect this - see code comments why
the new method is still considered more reliable than the old one).
Code note: we needed to slightly re-structure the way actual HUP
processing and the "HUP mutex" is handled. After best analysis,
this does not affect the reliability or speed in production
settings.
closes https://github.com/rsyslog/rsyslog/issues/5192
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.
so far, we checked only the main queue size to become zero, ignoring
the sizes of action queues. For some tests, this caused racieness and
unreliability. Now, we check all queues. This should make matters
much more stable.
This does not cause issues in v7, but here we have the problem
that the total number of actions, which now is required for wti sizing,
is not available at that early stage. So we needed to delay queue
startup until everything is processed (just as it should have been
already!). Note the previously we could have a segfault on first message
when ruleset queues were used.
The "queue.xxx" parameter set was not supported, and legacy ruleset
config statements did not work (by intention). The fix introduces the
"queue.xxx" parameter set. It has some regression potential, but only
for the new functionality. Note that using that interface it is possible
to specify duplicate queue file names, which will cause trouble. This
will be solved in v7.3, because there is a too-large regression
potential for the v7.2 stable branch.
I cleaned up a lot of config variable access along the way. This
version compiles and runs, but does not yet offer any enhanced
functionality. pmrfc5424 is just a dummy that is not yet being used.
now cleaner and hopefully usuable as a basis for loadable parser
modules. I also cleaned up/consolidated some of the internal
message generation functionality in rsyslogd.
... by moving code to stream.c. Thanks to the new design, new cases are
not really needed, resulting in cleaner code.
I also did a cleanup of header file usage as a side-activity.
... this was long overdue, and I finlly tackeld it. It turned out to
be more complex than I initially thought. The next step now probably is
to actually implement multiple rule sets and the beauty that comes
with them.
This enables us to use more efficient calling conventions and
also helps us keep the on-disk structure of a msg object more
consistent in future releases.
Message parsing is now done as part of main message queue worker
processing (was part of the input thread) This should also improve
performance, as potentially more work is done in parallel.
This enhances performance and, as some have pointed out, is
probably also more consistent with what users expect how
the various output-timestamp related function should work. This
commit needs some more testing.
...which enables to work with
less acurate timestamps in favor of performance. This enables querying
of the time only every n-th time if imudp is running in the tight
receive loop (aka receiving messsages at a high rate)
