Florian Forster [Sat, 28 Feb 2009 09:29:08 +0000 (10:29 +0100)]
dns plugin: Don't pass a NULL pointer to `pcap_open_live'.
Although the documentation states clearly, that passing a NULL pointer
as device is okay and handled like "any", doing so will crash the daemon
on some systems, most notably *BSDs but Linux users have reported this
behavior, too.
This patch passes "any" when the pointer it NULL, which reportedly
resulted in a different behavior, but still crashing the daemon. We'll
keep trying ;)
Sebastian Harl [Tue, 24 Feb 2009 10:27:22 +0000 (11:27 +0100)]
src/common.c: Fixed a race condition in check_create_dir().
Between checking for the existence of a directory using stat() and creating
the directory using mkdir(), another thread might have already created the
directory thus causing mkdir() to fail with errno == EEXIST. This case is now
handled sanely, no longer causing the function (and thus some write callback)
to fail in this case.
Most likely, this only happens during startup when creating the data
directories - later, no two threads should try to create the same directory.
Interestingly enough, I frequently encountered this issue on a single core
machine.
Florian Forster [Tue, 24 Feb 2009 09:08:29 +0000 (10:08 +0100)]
src/plugin.c: Assure that targets get dynamically allocated memory.
If targets want to replace the values, they will have to use dynamically
allocated memory. If they can't free the values, because the pointer
might point to statically allocated memory, memory will be lost.
Unfortunately stack allocation will not do, since we will then not be able
to detect multiple replacements.
To impose as little a performance issue as possible, the dynamic allo-
cation is only done when either chain is present. If the filter mecha-
nism is not used, the values will not be copied.
Florian Forster [Mon, 23 Feb 2009 17:59:04 +0000 (18:59 +0100)]
java plugin: Add support for `match' callbacks.
Holy crap, that one needed some serious magic.. The problem is, that the
filter chains are created before the initialization functions are run.
Since the Java plugin used to initialize the JVM and load the classes in
the init function, the match callbacks were not available in time.
The behavior is now: Create the JVM as soon as the the first `LoadPlugin'
option is found and load and configure all Java plugins while in the
configuration phase. (I. e. exactly like C plugins.)
Florian Forster [Sat, 21 Feb 2009 17:39:57 +0000 (18:39 +0100)]
java plugin: Use the changed plugin infrastructure to call read and write functions directly.
The read and write functions implemented in Java are now registered with
the "complex" interface as "java:<class name>". This way the cjni_read and
cjni_write functions can determine which Java function to call.
The patch is bigger than it'd need to be, because the order of some
functions has been changed..
These read callbacks will receive a user pointer. This is nice for the
Java plugin, because the plugin infrastructure can now call one specific
Java read function.
Florian Forster [Sat, 21 Feb 2009 08:13:43 +0000 (09:13 +0100)]
java plugin: Implement a reference counter for the JVMEnv pointers.
This way one thread entering the Java plugin twice, e. g. with the
following call-chain, will not detach itself from the JVM before it is
completely done with it.
The problematic situation is:
-> cjni_read
-> ALLOC JVM
-> `Read' (in Java)
-> `DispatchValues' (in Java)
-> plugin_dispatch_values
-> cjni_write
-> ALLOC JVM (this is a no-op!)
-> `Write' (in Java)
-> DEALLOC JVM
This last dealloc is prematurely, because the thread is not done with
the JVM yet: It'd like to continue and return from `DispatchValues' to
execute some more Java code..
This function differs from `plugin_dispatch_values' in that it will add
the value_list_t to a queue rather than calling the write functions
right away. This as at least two advantages:
- The _async function will often return faster, since no file
operation is done.
- The ``read thread'' and the ``write thread'' are not the same
thread. This makes it much easier for plugins that provide both,
`read' and `write' callbacks.
Sebastian Harl [Thu, 19 Feb 2009 11:09:46 +0000 (12:09 +0100)]
contrib/cussh.pl: Fixed and improved command parsing.
The input line is now split into separate tokens which are either quoted or
unquoted strings. This simplifies e.g. the parsing of identifiers as the whole
token may be interpreted as just the id string. This allows for specifying a
somewhat greedy regex which before led to the whole remainder of the input
line ending up in the type or type instance.
Sebastian Harl [Thu, 19 Feb 2009 12:14:35 +0000 (13:14 +0100)]
table plugin, src/common: Un-escape '\t', '\n' and '\r' in column separators.
For this purpose, the function strunescape() has been added to the "common"
module. Currently, any escape sequence that's not '\t', '\n' or '\r' will be
expanded to the literal escaped character.
Sebastian Harl [Thu, 19 Feb 2009 07:56:37 +0000 (08:56 +0100)]
tables plugin: Added a generic plugin to parse tabular data.
Currently, the main purpose of this plugin is to be able to get information
from the Linux proc filesystem but it should be flexible enough to get data
from other sources as well.
Values are selected based on a given column separator and column numbers. The
configuration is a kind of a mix of the tail and *sql plugins' configurations.
A sample configuration might look like this:
On Mon, 16 February 2009 Florian Forster wrote:
> The new plugins are:
>
> * BIND: Name-server and zone statistics
A few bugs are hidden there, attached is a patch that fixes most
of those I've discovered untils now.
- Url parameter never considered
- missing type definition for dns_reject
- MemoryStats is linked to the wrong variable
(TODO: memory stats seem not to work, probably dispatch_counter()
for gauge value ...)
- SOAOutv6 should be translated to SOA-IPv6 instead of SOA-IPv4
in order to be saved correctly and not cause timestamp collisions
Florian Forster [Wed, 18 Feb 2009 11:49:56 +0000 (12:49 +0100)]
java plugin: Added the ability to have `Write' callbacks in Java modules.
I think right now having both, a `Read' and a `Write' function, would be
a problem, because the same thread would enter the JVM twice, possibly
detaching itself from the JVM when the write callback is finished, while
it actually still is in the read callback. Adding a `dispatch thread' or
something similar should take care of this problem.
Other than that, converting `data_set_t' and `value_list_t' to their
Java equivalents and back works fine now.
Florian Forster [Tue, 17 Feb 2009 22:45:40 +0000 (23:45 +0100)]
java plugin: Add an early prototype of a Java binding, similar to the Perl plugin.
It's totally proof-of-concept, but it's possible to dispatch values from
a Java class using the ValueList implementation provided by Doug
MacEachern from Hyperic. The other way around is not yet implemented,
but that's just a matter of time and code. Configuration, notifications,
targets, matches - all that is still missing.
Right now, the code requires JNI version 1.2. Maybe I'll try to
introduce compatibility with JNI 1.1 at a later point, if it's really
useful for somebody.
Sebastian Harl [Mon, 16 Feb 2009 21:41:19 +0000 (22:41 +0100)]
postgresql: Fixed calculation of a database's max_params_num.
This parameter is used to store the size of a frequently used temporary list
and allows that it may be efficiently stored on the stack. It was accidentally
lost in commit 4d380d9, triggering an assertion in c_psql_exec_query_params().