this can happen if imfile reads a state file. On each open, memory for the
file name can be lost.
We detected this while working on imfile refactoring, there is no related
bug report. No specific test has been crafted, as the refactored imfile
tests catch it (as soon as they are merged).
Bug is actually in stream object, but currently exposed only via imfile.
Happens when in readMode 0 a partial line is read and no more data is
present in the file during that iteration. One partial message is lost
in this case.
closes https://github.com/rsyslog/rsyslog/issues/2421
The currently done buffer modification (add of '\0') is bad, especially when
multiple threads access the same string. It is not really an issue that needs
to be urgently fixed, as always the same data is written. However, among others,
it will pollute the thread debugger and as such prevent more elaborate automatted
tests.
closes https://github.com/rsyslog/rsyslog/issues/1993
if a file cannot be opened but would need to be for the crypto provider
to work correctly, an error message is now emitted.
Root issue detected by Coverity scan, CID 185338
We ensure that the previous line segment is always valid... actually this
was already done with existing code, but Coverity scan did not detect this.
Maybe we now get a control flow issue because we do what already happened
in this case...
CID 185423
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.
