| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
this enables us to work with the "usual" environment tweaks (for
debugging and other purposes), without the need for any special
handling in nettester itself
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| | |
accidently, the time zone information was kept inside some
to-be-checked-for responses
|
|\|
| |
| |
| |
| | |
Conflicts:
ChangeLog
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Also made sure that /dev/log will not be processed by imuxsock
when running under Solaris -- otherwise, the module may had
accidently deleted the log socket and cause problems.
|
| |
| |
| |
| | |
imklog now basically works, but needs quite some more work to do
|
| |
| |
| |
| |
| | |
saving this area of work, because some further clarification
is needed. Do not try to run the current imklog, it will fail.
|
| | |
|
|\ \
| | |
| | |
| | | |
into v4-stable-solaris
|
| |\| |
|
| | | |
|
|/ /
| |
| |
| | |
... far from being functional at this time!
|
| | |
|
|\|
| |
| |
| |
| | |
Conflicts:
ChangeLog
|
| |
| |
| |
| |
| |
| | |
a3e48b697fa664110567fcd0027d24ea5a239041
... so that the testbench continues to work
|
| |
| |
| |
| | |
it permits to specifiy if asynchronous writing should be done or not
|
| | |
|
| |
| |
| |
| | |
On some platforms, the default is too low to carry out all test cases
|
| | |
|
|\ \
| | |
| | |
| | | |
git+ssh://rger@git.adiscon.com/git/rsyslog into v4-stable-solaris
|
| | |
| | |
| | |
| | | |
subsecond sleep did not work on all platforms
|
|\ \ \
| |/ /
|/| /
| |/
| | |
Conflicts:
ChangeLog
|
| |
| |
| |
| |
| | |
some versions of autotools seem to require it. The file itself is NOT
of interest for the project
|
| |
| |
| |
| |
| |
| |
| | |
Further testing turned out that the rsyslog core works correctly and
this fix is not needed. The concurrency we saw was actually caused by
other actions (even processes) during directory creation. See commit
9e5b31fc44136dbcc1e443cfe7714e9daf97d844 for further details.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some types of malformed messages could trigger an off-by-one error
(for example, \0 or \n as the last character, and generally control
character escaption is questionable). This is due to not strictly
following a the \0 or string counted string paradigm (during the last
optimization on the cstring class). As a temporary fix, we have
introduced a proper recalculation of the size. However, a final
patch is expected in the future. See bug tracker for further details
and when the final patch will be available:
http://bugzilla.adiscon.com/show_bug.cgi?id=184
Note that the current patch is considered sufficient to solve the
situation, but it requires a bit more runtime than desirable.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This bug was triggered by an open failure. The the cache was full and
a new entry needed to be placed inside it, a victim for eviction was
selected. That victim was freed, then the open of the new file tried. If
the open failed, the victim entry was still freed, and the function
exited. However, on next invocation and cache search, the victim entry
was used as if it were populated, most probably resulting in a segfault.
|
| |
| |
| |
| |
| |
| |
| | |
If multiple files try to create a directory at (almost) the same time,
some of them may fail. This is a data race and also exists with other
processes that may create the same directory. We do now check for this
condition and gracefully handle it.
|
| |
| |
| |
| |
| |
| | |
The old code looks a bit "strange", though not necessarily incorrect.
The new code looks correct and is probably less irritating during bug
hunting.
|
| |
| |
| |
| |
| |
| |
| | |
when dynaCache is enabled, the cache is full, a new entry needs to
be allocated, thus the LRU discarded, then a new entry is opend and that
fails. In that case, it looks like the discarded stream may be reused
improperly (based on code analysis, test case and confirmation pending)
|
| | |
|
| |
| |
| |
| | |
[backport of Stefen Sledz' patch for v5]
|
| | |
|
|\| |
|
| | |
|
|\| |
|
| | |
|
| |
| |
| |
| | |
Most importantly, this keeps the thread debugger output clean.
|
| |
| |
| |
| |
| |
| |
| | |
properly initialized.
However, in practice the loader initializes them with zero, the
desired value, so there were no actual issue in almost all cases.
|
| | |
|
| | |
|
| |
| |
| |
| | |
This is what caused the new test to fail...
|
| |
| |
| |
| |
| | |
note that so far no patch is provided. This has not yet been made
part of "make check"
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
file instance
In theory, the rsyslog core should never call in parallel into an output
module for the same instance. However, it looks like this seems to happen
under (strange?) circumstances. I have now enhanced omfile so that it guards
itself against being called in parallel on the same instance data. This is
done to help troubleshooting and may stay as an interim solution if it
proves to solve an anomaly we see in at least one installation (to trigger
this problem, an extremely large traffic volume is needed).
|
| |
| |
| |
| | |
also improved nettester testbench tool a bit
|
| | |
|
| |
| |
| |
| | |
the test cases actually have some races, not the code to be tested
|