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.
When a to-be-monitored file is being rotated, some messages may be lost or
duplicated. In case of duplication, many file lines may be duplicated
depending on actual timing. The whole bug was primarily timing depenedent
in general. It most often was visible in practice when the monitored
file was very frequently rotated (we had some report with every few
seconds).
Note that while we try hard to not lose any messages, input file
rotation always has some loss potential. This is inevitable if
the monitored file is being truncated.
Also note that this bugfix affects imfile, only. It has nothing to do
and no relation to rsyslog output files being rotated on HUP.
closes: https://github.com/rsyslog/rsyslog/issues/4797
The zstd library provides better and faster compression than zlib.
This patch integrates zstd as a dynamically-loadable functionality.
As such, no further dependencies need to be added to the rsyslog
base package.
Due to the increased performance, usage of zstd is highly recommended
for high-volume use cases.
This patch also refactor zlib compression in order to unify handling
in both compression cases.
The new parameter permits to specify a replacement to be configured
when "escapeLF" is set to "on". Previously, a fixed replacement string
was used ("#012"/"\n") depending on circumstances. If the parameter is
set to an empty string, the LF is simply discarded.
closes https://github.com/rsyslog/rsyslog/issues/3889
A change in the inode was not detected under all circumstances,
most importantly not in some logrotate cases.
Includes new tests made by Andre Lorbach. They now use the
logrotate tool natively to reproduce the issue.
previously, truncation was only detected at end of file. Especially with
busy files that could cause loss of data and possibly also stall imfile
reading. The new code now also checks during each read. Obviously, there
is some additional overhead associated with that, but this is unavoidable.
It still is highly recommended NOT to turn on "reopenOnTruncate" in imfile.
Note that there are also inherant reliability issues. There is no way to
"fix" these, as they are caused by races between the process(es) who truncate
and rsyslog reading the file. But with the new code, the "problem window"
should be much smaller and, more importantly, imfile should not stall.
see also https://github.com/rsyslog/rsyslog/issues/2659
see also https://github.com/rsyslog/rsyslog/issues/1605
This adds support for endmsg.regex. It is similar to
startmsg.regex except that it matches the line that denotes
the end of the message, rather than the start of the next message.
This is primarily for container log file use cases such as this:
date stdout P start of message
date stdout P middle of message
date stdout F end of message
The `F` means this is the line which contains the final part of
the message. The fully assembled message should be
`start of message middle of message end of message`.
`startmsg.regex="^[^ ]+ stdout F "` will match.
As it seems, different C compilers have different rules/interpretations
on inline functions. The current code base did not properly obey all C99
rules. We fix this by converting some functions to macros and others to
include the necessary C99 plumbing. We also remove some inline attributes
for functions where this seems to be to agressive (aka "function to big").
This fixes build problems in some environments and is a general code
cleanup measure.
Attempt to fix#511. This is an enhanced version based on
https://github.com/rsyslog/rsyslog/pull/514, works fine for us so far.
As discussed before, I added an opt-in flag 'reopenOnTruncate' and
default is "off".
This is a preliminary patch, which needs to undergo further testing
in cases where rsyslogd is shut down with partial messages read.
see also https://github.com/rsyslog/rsyslog/issues/144
The datatype of the argument to SetiMaxFileSize() was too small and
could overflow.
The SetMaxFileSize() interface wasn't used at all (possibly confused
with SetiMaxFileSize()) and was dropped.
Previosly, this case could not be detected, so if a file was overwritten
or rotated away while rsyslog was stopped, some data was missing. This
is now detected and the new file being forwarded right from the
beginning.
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=228
This stream is primarily used for state tracking, and has been
modified to do just that. This results in considerable less io
being done and the respective speedup.
Most importantly, the last patch for imfile contained a number
of glitches, which are fixed by this commit (a memory leak under
unusual conditions, partial message loss when rsyslog was
terminated in the interim & mixing file data to the wrong files
when multiple monitors were used [due to static variable]). The
commit is actually a re-write of the patch, based on its core
idea.
Also some other minor cleanup was done.
another concept that did not prove valuable enough to be kept active. For
the last couple of releases, the dead code was kept inside the project as
we thought we could probably reuse it. Doesn't look so...
In async write mode, we use modular arithmetic to index the output
buffer array. However, the counter variables accidently were signed,
thus resulting in negative indizes after integer overflow. That in turn
could lead to segfaults, but was depending on the memory layout of
the instance in question (which in turn depended on a number of
variables, like compile settings but also configuration). The counters
are now unsigned (as they always should have been) and so the dangling
mis-indexing does no longer happen. This bug potentially affected all
installations, even if only some may actually have seen a segfault.
