| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |_|_|_|_|_|_|_|_|_|/
|/| | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
...this improves performance and consistency and also fixes
a bug where subsecond time properties generated by imfile, imklog and
internal messages could be slightly inconsistent.
|
| | | | | | | | | | | |
|
|\ \ \ \ \ \ \ \ \ \ \ |
|
| |\| | | | | | | | | |
| | |_|_|_|_|_|_|_|_|/
| |/| | | | | | | | | |
|
| | |\| | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Conflicts:
runtime/net.c
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
because getnameinfo() is not cancel-safe, but was not guarded against
being cancelled. pthread_cancel() is routinely being called during
HUP processing.
|
| | | | | | | | | | | |
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
thanks to Michael Biebl for suggesting it
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
problem source is that getnameinfo() is not cancel-safe,
not that it is not thread-safe. It is now guarded against
cancellation.
|
| | | | | | | | | | | |
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
... but removed the mutex, as the problem seems to be in cancel
processing, so the mutex is no longer necessary
|
|/ / / / / / / / / /
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
- changed sequence when awakening thread
- removed no longer needed condition variable
- EXPERIMENTALLY added mutex guarding to hostname lookups
this is to be removed if it does not have any verifyable
useful effect
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
I am changing the way the version number is bumped so that
viewer git merge conflicts happen. In the future, it will
be bumped immediately before release and not immediately after
(though this means I need to be more careful with interim
versions).
|
|\ \ \ \ \ \ \ \ \ \
| | |_|_|_|_|_|_|_|/
| |/| | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Conflicts:
ChangeLog
|
| | |_|_|_|_|_|_|/
| |/| | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
- removed newly-introduced potential deadlock in debug system
- removed unnecessary pthread_cond_signal
- a bit general cleanup
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
multi-threading
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
destructor not yet permitted because verification is
missing that a atomic opration is sufficient for the
job required
|
| |\ \ \ \ \ \ \ \
| | | |_|_|_|_|_|/
| | |/| | | | | | |
|
| |\ \ \ \ \ \ \ \
| | | |_|_|_|_|_|/
| | |/| | | | | | |
|
| | |_|_|_|_|_|/
| |/| | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The code was potentially race, at least on systems where
a memory barrier was needed. Fix not fully tested yet.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
There was a wrong order of mutex lock operations. It is hard to
believe that really caused problems, but in theory it could and with
threading we often see that theory becomes practice if something is only
used long enough on a fast enough machine with enough CPUs ;)
|
| | | | | | | | |
|
| | |_|_|_|_|/
| |/| | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
|\ \ \ \ \ \ \
| |_|_|/ / / /
|/| | | / / /
| | |_|/ / /
| |/| | | |
| | | | | | |
Conflicts:
doc/troubleshoot.html
|
| |\ \ \ \ \
| | | |_|/ /
| | |/| | | |
|
| | | | | | |
|
|\| | | | |
| |_|_|/ /
|/| | | | |
|
| |\| | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
... as $...OnlyIfPrev... in some parts of the documentation. Thanks to
Lorenzo M. Catucci for reporting this bug.
|
|\| | | |
| |_|/ /
|/| | | |
|
| |\| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
|
| | | |
| | | |
| | | |
| | | |
| | | | |
It did not properly de-init a variable acting as a linked list head.
That resulted in trying to access freed memory blocks after the HUP.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
... but did not manage to avoid doing at least one call. So
this change introduced performance benefit only in a few
non-common situations. Anyhow, it hopefully levels ground
for better things to come.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
in one case, which was not on the focus of the initial testing
cases.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
removed
thanks to David Lang for his excellent performance analysis
|
|\| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
runtime/rsyslog.h
tools/syslogd.c
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This probably happened during a branch merge and was not detected.
Fixed now, should not haved any harm.
|
| |\| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
runtime/datetime.h
runtime/rsyslog.h
|
| | |\|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
ChangeLog
syslogd.c
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
this caused a very minor issue with re-formatting a RFC3164 date when the
message was invalidly formatted and had a colon immediately after the date.
This was in the code for some years (even v1 had it) and I think it never
had any effect at all in practice. Though, it should be fixed - but definitely
nothing to worry about.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This has now been corrected. Required change to the
internal ParseTIMESTAMP3164() interface.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
resulting in strange operations.
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
default discard severity was incorrectly set to 4, which lead
to discard-on-queue-full to be enabled by default. That could cause
message loss where non was expected. The default has now been changed
to the correct value of 8, which disables the functionality. This
problem applied both to the main message queue and the action queues.
Thanks to Raoul Bhatia for pointing out this problem.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Queue full is now -2074 and -2025 is unique again.
(did cause no real problem
except for troubleshooting)
|