| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | |
| | | | |
| | | | |
| | | | | |
plus some cleanup...
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
... by moving code to stream.c. Thanks to the new design, new cases are
not really needed, resulting in cleaner code.
I also did a cleanup of header file usage as a side-activity.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
this regression was introduced last friday, so this is *NOT* present
in any released version.
|
| | | | |
| | | | |
| | | | |
| | | | | |
now contain a copy of the config line that (most likely) caused the error
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
so we now can define multiple rule sets, we just can not use them ;)
That means we have the foundation to bind listeners to different
rule sets.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
... actually, it was not broken, but just very slow. I have now
reduced the number of test messages so that make check will not be
held for an extended period of time.
|
| | | | |
| | | | |
| | | | |
| | | | | |
and another problem, both introduced today. Also did some general cleanup.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
... this was long overdue, and I finlly tackeld it. It turned out to
be more complex than I initially thought. The next step now probably is
to actually implement multiple rule sets and the beauty that comes
with them.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
also adds speed, because you do no longer need to run the whole file
system in sync mode. New testbench and new config directives:
- $MainMsgQueueSyncQueueFiles
- $ActionQueueSyncQueueFiles
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
... restoring missing functionality after the restructuring of imfile. As
a side-effect, this also lays the foundation for even more reliable queue
engine operations (but this is not yet done).
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
now cleand up omfile and straighted out some things. The only commented-out
code left is code that must be moved/merged to the stream class, my next target.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
now some basic operations are carried out via the stream class.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
... and also made it callable via an rsyslog interface rather then
relying on the OS loader (important if we go for using it inside
loadbale modules, which we soon possible will)
|
| |\| | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
this does not mean the v4 engine will support batches and output
transactions, but I can now write plugins that will work equally well
with v4 AND v5. I consider this useful during the rewrite of omfile.
|
| | | | |
| | | | |
| | | | |
| | | | | |
so they can now be processed with the "regular" gzip tools
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This DOES NOT work sufficiently well, I just wanted to verify that
zip writing is possible and files are readable. Will be refined
soon.
|
|\ \ \ \ \
| | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | | |
Conflicts:
runtime/rsyslog.h
tests/Makefile.am
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
this permits us to keep a persistent test environment between
v4 and v5, most importantly using the same tools. As far as the
actual tests are concerned, some had issues. I had no time to check
if that was an issue with the test or an actual issue with the
v3/4 engine. Will do that at some later stage.
|
|\| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
ChangeLog
runtime/rsyslog.h
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
(in addition to rather specific syslog tcp server)
|
| |\| |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
runtime/rsyslog.h
|
| | |\|
| | | |
| | | |
| | | |
| | | | |
Conflicts:
runtime/rsyslog.h
|
| | | |
| | | |
| | | |
| | | |
| | | | |
... I know I should not have done this to a stable branch... Thankfully
nothing was yet released.
|
|\| | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
tests/Makefile.am
|
| |\| |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
tests/Makefile.am
|
| | |\|
| | | |
| | | |
| | | |
| | | | |
Conflicts:
tests/Makefile.am
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
is detected.
This change is considered important but small enough
to apply it directly to the stable version. [But it is a border case,
the change requires more code than I had hoped. Thus I have NOT tried
to actually catch all cases, this is left for the current devel
releases, if necessary]
|
| | | |
| | | |
| | | |
| | | | |
Include <string.h> for memcpy and strlen.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
The enhanced testbench now runs without failures, again
|
| | | |
| | | |
| | | |
| | | |
| | | | |
also changed DA queue mode in that the regular workers now run
concurrently.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
... in preparation for some larger changes - I need to apply some
serious design changes, as the current system does not play well
at all with ultra-reliable queues. Will do that in a totally new version.
|
| | | |
| | | |
| | | |
| | | | |
slightly improved situation, would like to save it before carrying on
|
|\| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
tests/Makefile.am
tests/diskqueue.sh
tests/imtcp-multiport.sh
tests/manytcp.sh
tests/memq-persist.sh
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The imdiag module now can very effectively inject messages, which also
frees us from uncertainties of tcp reception and processing. All shell
script based tests have been modularized, what makes it far easier to
create new tests. Also, the test bench now executes more reliable and
much faster, because we can now rely on actual engine information where
we previously did just a dumb sleep.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
... and also improved the test suite. There is a design issue in the
v3 queue engine that manifested to some serious problems with the new
processing mode. However, in v3 shutdown may take eternally if a queue
runs in DA mode, is configured to preserve data AND the action fails and
retries immediately. There is no cure available for v3, it would
require doing much of the work we have done on the new engine. The window
of exposure, as one might guess from the description, is very small. That
is probably the reason why we have not seen it in practice.
|
|\| | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
|\| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
tests/Makefile.am
tests/diskqueue.sh
|
| | | |
| | | |
| | | |
| | | |
| | | | |
which enables to talk to the rsyslog core at runtime. The current
implementation is only a beginning, but can be expanded over time
|
| | | | |
|
| | | | |
|
|\| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
runtime/rsyslog.h
tests/Makefile.am
tools/syslogd.c
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|