imdiag/imtcp had a modload race condition (as imdiag is a testing aid,
this has no implications for production deployments). Also, I replaced
netcat by a custom program to talk to imdiag. This, for the first time ever,
is now a Java program. I plan to add some GUI troubleshooting tools and
thought it is a good idea to start doing things in Java that can simply
be done in that language.
Well, actually this and a lot of related things. I improved the
testbench so that the new capabilities are automatically tested and
also did some general cleanup. The current multiple tcp listener
solution will probably receive some further cleanup, too, but looks
quite OK so far. I also reviewed the way tcpsrv et all work, in
preparation of using this code for imdiag. I need to document the
findings, especially as the code is rather complicated "thanks" to
the combination of plain tcp and gssapi transport modes.
... needed to split the old single counter into two. I wouldn't bet that
I made some mistakes while doing so, but at least some ad-hoc tests plus
the testbench do no longer indicate errors.
Only run omod-if-array.sh and parsertest.sh test if omstdout plugin is
enabled.
Remove the comment and fix the help output for --enable-stdout (default
was "no", not "yes")
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
... on the way to the ultra-reliable queue modes (redesign doc). This
version does not really work, but is a good commit point. Next comes
queue size calculation. DA mode does not yet work.
The problem is that the rsyslog engine writes messages too quickly, so
that the queue never enters DA mode. We still have some look contemption.
One possible solution (hopefully) is to finally move the parser code out
of imtcp and onto the next thread. Need to address these issues first, then
come back to the test case.
It is checked that many tcp connections are properly handled. While
adding this test, I noticed that there is a bug in imtcp that prevents
creation of more than 200 connections. This bug still exists, so the
test suite currently fails (what is correct). Will be addressed soon.
We noticed this race issue under Solaris (thanks to its different
scheduler, I guess). In some cases, the previous instance of rsyslogd
was not terminated, resulting in a failure on the next test. Now
handled correctly.
The testbench has now a generic driver that can run a whole class
of test suites just by providing a config file and test cases. This
does not cover all testing needs, but a lot.
We have now added one test for the new array-passing output plugin
interface.
I finally removed the tcl script because tcl costs a lot of
time if you do not invest the full learning cycle, plus I have
not everything avaible I need on Solaris. With C, I am quicker and
I also can create a superior solution. So I finally switched. Took
much less time than the initial tcl script...
worked on ways to provide a better test suite:
- added -T rsyslogd command line option, enables to specify a directory
where to chroot() into on startup. This is NOT a security feature but
introduced to support testing. Thus, -T does not make sure chroot()
is used in a secure way. (may be removed later)
- added omstdout module for testing purposes. Spits out all messages to
stdout - no config option, no other features
- modified $ModLoad statement so that for modules whom's name starts with
a dot, no path is prepended (this enables relative-pathes and should
not break any valid current config)
