| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
plugins/imrelp/imrelp.c
|
| | | | |
|
| | | | |
|
| | | |\ |
|
| | | | | |
|
| | | |\|
| | | |
| | | |
| | | |
| | | | |
Conflicts:
plugins/imrelp/imrelp.c
|
| | | | | |
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
ChangeLog
|
| | | | | | |
|
| | | | | | |
|
| |\| | | | |
|
| | |\ \ \ \
| | | |_|/
| | |/| |
| | | | |
| | | | | |
Conflicts:
plugins/imrelp/imrelp.c
|
| | | | | |
| | | | |
| | | | |
| | | | | |
[if librelp != 1.0.0 is used]
|
| |\| | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
...for the main queue if an active DA queue existed. This had no relevance
to real deployments (assuming they are not running the debug/diagnostic
module...), but sometimes caused grief and false alerts in the
testbench.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This was a recently introduced regression.
|
| |\| | | | |
|
| | |\ \ \ \
| | | |/ /
| | |/| | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Max size is now 32K.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
- bugfix: solved potential (temporary) stall of messages when the queue was
almost empty and few new data added (caused testbench to sometimes hang!)
- fixed some race condition in testbench
- added more elaborate diagnostics to parts of the testbench
- solved a potential race inside the queue engine
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
made shutdown more reliable by makeing sure that the main queue DA worker
is only cancelled if this is actually unavoidable. Also moved down the
deletion of rsyslogd's pid file to immediately before termination, so
that absence of the file is a proper indication that rsyslogd has
finished (in the past, e.g. the testbench accidently ran two intances
as the pid file was deleted too early). Also some improvments to the
testbench, namely to handle aborts more intelligently (but still not
perfect).
|
| | | | | | |
|
| |\| | | | |
|
| | |\| | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This resulted in wrong values. The most prominent victim was the
directory creation mode, which was set to zero in some cases. For
details, see related blog post:
http://blog.gerhards.net/2009/10/another-note-on-hard-to-find-bugs.html
This replaces the improper bugfix from two commits ago with a proper one.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
one-time write to the mode, then all works. However, if no such write
is done, the variable always remains zero. I have used the memory
debugger as well as shuffled the code around and used guard variables
nothing changed. The problem always moved with the changes I did. So
I now consider the one-time write a usable work-around, because it
definitely fixes the issue even though it does not explain why it
happens.
|
| |\| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
runtime/rsyslog.h
tcpsrv.c
|
| | | | | | |
|
| | |\| | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
runtime/rsyslog.h
|
| | | | | | |
|
| | | | | | |
|
| | |\ \ \ \
| | | |_|/
| | |/| |
| | | | |
| | | | |
| | | | | |
Conflicts:
runtime/rsyslog.h
tools/syslogd.c
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
improperly handled.
This was a regression of one of the last bugfixes, so no previously released
version contained this bug (thus it does not show up in the ChangeLog).
|
| | |\| | |
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
configure.ac
doc/manual.html
runtime/datetime.h
runtime/parser.c
runtime/rsyslog.h
tools/syslogd.c
v4-stable had a bug with RFC5424-formatted structured data, which showed
was detected by the enhanced automatted testbench of v4-beta.
|
| | | |\| |
|
| | | | |\ |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Until now, they were forwarded to processing, but this makes no sense
Also, it looks like the system seems to provide a zero return code
on a UDP recvfrom() from time to time for some internal reasons. These
"receives" are now silently ignored.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
could lead to mis-addressing and potential memory corruption/segfault
|
| | | | | | |
|
| | | | | | |
|
| |\| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
we needed to release ALL resources (including file handles!) only
after the the async writer thread has terminated (else it may access
them). In this case, we had a file handle leak, because the handle was
sometimes only opened in the async writer, but the close was attempted
before the writer even started (in some cases).
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
...after we seem to have identified the root cause of the segfault.
I leave them commented out so that we can re-activate it if need
arises (aka "get some practice drill first").
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Most severely affected omfile. The problem was that some buffers were
freed before the asynchronous writer thread was shut down. So the
writer thread accessed invalid data, which may even already be
overwritten. Symptoms (with omfile) were segfaults, grabled data
and files with random names placed around the file system (most
prominently into the root directory). Special thanks to Aaron for
helping to track this down.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
if the buffer was too small, we would see more API calls, but no
failure, so this is no fix!
|
