| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|\
| |
| |
| |
| | |
Conflicts:
runtime/stream.c
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|\| | |
|
| | |
| | |
| | |
| | |
| | | |
The last fix was incomplete. Thanks to Christiano for testing
and suggestions.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|/ / |
|
| | |
|
| | |
|
| |
| |
| |
| | |
also add test parameter to be able to set key
|
| |
| |
| |
| | |
rough baseline, needs to be extended for actual use.
|
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
also fixed a couple of smaller issues along that way
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
configure.ac
doc/manual.html
plugins/imfile/imfile.c
plugins/imklog/bsd.c
plugins/imklog/imklog.c
plugins/imklog/imklog.h
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
File lines that were incomplete (LF missing) *at the time imfile polled
the file* were partially discarded. That part of the line that was read
without the LF was discarded, and the rest of the line was submitted in
the next polling cycle. This is now changed so that the partial content
is saved until the complete line is read. Note that the patch affects
only read mode 0.
|
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This could happen if a dynafile was destructed before the first write.
In practice, this could happen if few lines were written to a file and
it then became evicted from the dynafile cache. This would probably
look very random, because it depended on the timing in regard to
message volume and dynafile cache size.
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
doc/v7compatibility.html
|
|\ \ \ \
| |/ / /
|/| / /
| |/ /
| | |
| | | |
Conflicts:
configure.ac
doc/manual.html
|
| |/
| |
| |
| | |
... due to too small timeout for enqueue processing --> messages got lost
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| | |
Conflicts:
ChangeLog
configure.ac
doc/rsyslog_conf_global.html
runtime/stream.c
tools/omfile.c
|
| |
| |
| |
| |
| | |
This was achieved by somewhat reducing the robustness of the zip
archive. This is controlled by the new setting $OMFileVeryReliableZip.
|
| |
| |
| |
| | |
Thanks to Andre Lorbach for mentioning this.
|
|\|
| |
| |
| |
| | |
Conflicts:
runtime/ruleset.c
|
| |
| |
| |
| |
| | |
... it could pass a NULL pointer to unlink. Depending on OS implementation,
this could (or could not...) lead to a segfault.
|
|/
|
|
| |
This is done to prevent name claches with libraries.
|
| |
|
|
|
|
|
|
| |
when a file that was to be monitored did not exist BUT the state file
actually existed. Mostly a cosmetic issue. Root cause was incomplete
error checking in stream.c; so patch may affect other code areas.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Leaks could occur under some circumstances if the file stream handler
errored out during the open call. Among others, this could cause very
big memory leaks if there were a problem with unreadable disk queue
files. In regard to the memory leak, this
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=256
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
|
| |\| |
|
| | |
| | |
| | |
| | |
| | |
| | | |
Under some circumstances an invalid truncation was detected. This
code has now been removed, a file change (and thus resent) is only
detected if the inode number changes.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This can happen when 0 bytes are read from the input file, and some
writer appends data to the file BEFORE we check if a rollover happens.
The check for rollover uses the inode and size as a criterion. So far,
we checked for equality of sizes, which is not given in this scenario,
but that does not indicate a rollover. From the source code comments:
Note that when we check the size, we MUST NOT check for equality.
The reason is that the file may have been written right after we
did try to read (so the file size has increased). That is NOT in
indicator of a rollover (this is an actual bug scenario we
experienced). So we need to check if the new size is smaller than
what we already have seen!
|
| | |
| | |
| | |
| | | |
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
|
|/ /
| |
| |
| |
| |
| |
| | |
The original code had quite some issues, which are fixed by this
commit. Also we do more error checking now.
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
|
|\|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
configure.ac
runtime/cfsysline.c
tools/ompipe.c
|