The timeout could be reduced by mutex wait time, which was not the
intended behaviour and could lead the the input thread being
cancelled while it would have been perfectly legal to shut it down
cleanly.
Noticed during working on the CI system. May explain some testbench
instability and may have caused trouble with state files (not)
properly being written by inputs.
This is purely for debugging, and aimed at helping find some race
within the testbench. We know it happens, but it is unfortunately
totally unreproducible, so we try to gather data as less invasive
as possible.
This fixes a potential race that valgrind's helgrind found on some
very few occasions, and right now only on CentOS 7. However, it
looks like the variable was actually not correctly protected.
see also https://github.com/rsyslog/rsyslog/issues/2012
this in almost all cases indicates a real problem that the user
should be made aware of
For a case where the missing error message caused confusion
see also https://github.com/rsyslog/rsyslog/issues/1867
Note that this is below the usual 10MiB default, but should cause
no issues (output threads already use 4MiB stack size, for example).
This also addresses issues introduced by micro-libc's which only
provide very limited stack space by default.
closes https://github.com/rsyslog/rsyslog/issues/996
The entry point was called at the wrong spot, only when the thread
had not already terminated by itself. This could cause various
cleanup to not be done.
closes https://github.com/rsyslog/rsyslog/issues/882
This is considered cosmetic as multiple threads tried to write exactly
the same value into the same memory location without sync. The method
has been changed so this can no longer happen.
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>
This was introduced when we re-enabled non-cancel thread termination
a few commits ago. This code has never been released as a tarball,
so that is no bugfix for a release but rather a WiP regression fix
and thus does not need to be mentioned in the ChangeLog.
...where possible. This provides a more reliable mode of
rsyslogd termination (canceling threads my result in not properly
freed resouces and potential later hangs, even though we perform
proper cancel handling in our code). This is part of an effort to
reduce thread cnacellation as much as possible in rsyslog.
NOTE: some comments indicated that there were problems with some code
that has been re-activated. Testing did not show any issues. My current
assumption is that these issues were related to some other code that
has been removed/changed during the previous restructuring events.
In any case, if there is a shutdown issue, one should carefully look
at this change here!
a bug showed up during further testing. As this was a side-activity,
I'll probably disable it for the time being and check what's going on
somewhat later (I'll do it tomorrow if I can find it quickly)
... but an alternate approach via pthread_kill. This is somewhat safer as we
do not need to think about the cancel-safeness of all libraries we use.
However, not all inputs can easily supported, so this now is a feature
that can be requested by the input module (the most important ones
request it).
was specified in rsyslog.conf
- fixed a bug that caused a segfault on queues with types other than "disk"
- removed the now longer needed thread TermSyncTool
See newsgroup posting for details on the issue:
http://groups.google.com/group/comp.programming.threads/msg/330b9675f17
a1ad6 I tried some mutex operations but came to the conclusion that
this does not really help. So I have now switched to plain thread
cancellation, which so far seems to be OK. Need more practical
experience with other input modules to make a final decision. Thus I
leave all code in and have just disabled the problematic code.
