when a queue was restarted from disk file, it almost always
emitted a message claiming
"file opened for non-append write, but already contains xxx bytes"
This message was wrong and did not indicate a real error condition.
The predicate check was incorrect.
The timeout feature for multiline reads does not correctly work
for files for which a state file existed. This is usually the
case for files that had been processed by a previous run and
that still exist on the new start. For all other files,
especially those monitored by a wildcard and newly created after
the rsyslog start, timeout worked as expected.
closes https://github.com/rsyslog/rsyslog/issues/1445
Those messages previously went only to the debug log, as due to
design limitations inside the error message subsystem they could
not be emitted at the related code locations. This has changed now,
and so we can improve error reporting.
This is useful for tracking queue corruption. Was added as part
of tracking down github issue #1404.
As an unrelated small change, we slightly improve the debug
information imuxsock emits.
see also https://github.com/rsyslog/rsyslog/issues/1404
This causes a segfault. It happens whenever an object state larger
than 4095 byte is persisted. Then, incorrectly a try to rollover to
a new state file is tried, which will lead to a division by zero
as the necessary variables for this operation are not set because we
are NOT in circular mode.
This problem can happen wherever state files are written. It has been
experienced with imfile and queue files.
Many thanks to github user mostolog for his help in reproducing the
issue, which was very important to finally nail down this long-standing
bug.
closes https://github.com/rsyslog/rsyslog/issues/1239
closes https://github.com/rsyslog/rsyslog/issues/1162
closes https://github.com/rsyslog/rsyslog/issues/1074
When writing fails for file with error codes ENOTCONN or EIO, then file probably locates in network mounted partition, and thus needs to be closed and reopened.
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.
the function can no longer fail and it is not expected that this
will ever happen again in the future. So we remove the return value,
giving a small speedup to the code.
Note that this is below the usual 10MiB default, but should cause
no issues (output threads already use 4MiB stack size, for example).
This also addresses issues introduced by micro-libc's which only
provide very limited stack space by default.
closes https://github.com/rsyslog/rsyslog/issues/996
Remove the use sizeof(char) or sizeof(uchar) in calculations for memory
allocation or string length. There are no known platforms for which
sizeof(char) or sizeof(uchar) is not 1, and c99 has defined sizeof(char)
to be 1 (section 6.5.3.4 of c99).
we still ignore the return code, as this probably is the best we
can do in this case. Generating an error may result in a death spiral
or error messages. At least, we now output a message into the debug log.
Issue was detected by clang static analyzer.
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".
