| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
At least one case where this can occur is during thread shutdown, which
may be initiated by lower activity. In most cases, this is quite
unlikely to happen. However, if it does, data structures may be
corrupted which could lead to fatal failure and segfault. I detected
this via a testbench test, not a user report. But I assume that some
users may have had unreproducable aborts that were cause by this bug.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=254
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This permits to read the time a message was submitted to the system
log socket. Most importantly, this is provided in microsecond resolution.
So we are able to obtain high precision timestampis even for messages
that were - as is usual - not formatted with them. This also simplifies
things in regard to local time calculation in chroot environments.
Many thanks to Lennart Poettering for suggesting this feature,
providing some guidance on implementing it and coordinating getting the
necessary support into the Linux kernel.
|
|\| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
runtime/rsyslog.h
|
| |\| | | | |
|
| | |\| | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
runtime/datetime.c
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=271
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
I overlooked a border case, which came up on a larger testbench run.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=270 (not yet confirmed!)
|
| |\| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
doc/rsyslog_conf_global.html
|
| | | | | | |
|
| | | | | | |
|
|\| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
ChangeLog
tcpsrv.c
|
| |\| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
tcpsrv.c
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
so that we can improve v5's testbench as well
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This leak is tied to error conditions which lead to incorrect cleanup
of some data structures.
Note: this is a backport from v6. In v5, we currently do not have
the toolchain to verify the original problem and that it is solved.
So this patch is preliminary and subject to change as work progresses.
|
| | | | | | |
|
|\ \ \ \ \ \
| | |_|_|/ /
| |/| | | |
| | | | | |
| | | | | | |
Conflicts:
tcpsrv.c
|
| |\ \ \ \ \
| | | |/ / /
| | |/| | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This leak is tied to error conditions which lead to incorrect cleanup
of some data structures. [backport from v6, limited testing under v4]
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
...as well as in the debug output. This functionality has now
been fully tested.
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
so far untested, test follows
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Conflicts:
ChangeLog
configure.ac
|
| | | | | | | |
|
| | |_|/ / /
| |/| | | | |
|
| |\ \ \ \ \
| | | |/ / /
| | |/| | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
|\ \ \ \ \ \
| | |_|/ / /
| |/| | | | |
|
| |\ \ \ \ \
| | | |/ / /
| | |/| | | |
|
| | | | | | |
|
| |\| | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
... am I really that dumb... ;)
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
this has not yet been added to imtcp, but could be done on request
|
| | | | | | |
|
|\ \ \ \ \ \
| | |_|/ / /
| |/| | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
prevents confusion during testbench run
|
| |\ \ \ \ \
| | | |/ / /
| | |/| | |
| | | | | |
| | | | | | |
Conflicts:
runtime/queue.c
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
If the the multi-submit interface was used and a QUEUE_FULL condition
occured, the failed message was properly destructed. However, the
rest of the input batch, if it existed, was not processed. So this
lead to potential loss of messages and a memory leak. The potential
loss of messages was IMHO minor, because they would have been dropped
in most cases due to the queue remaining full, but very few lucky ones
from the batch may have made it. Anyhow, this has now been changed so
that the rest of the batch is properly tried to be enqueued and, if
not possible, destructed.
|
| | | | | | |
|