- syslog-ng - lists.balabit.hu

[PATCH 0/3]: Scratch buffers for syslog-ng 3.4
by Gergely Nagy 31 Oct '11

31 Oct '11

Following this mail will come three patches: * One to implement scratch buffers * Another to convert jsonparser to scratch buffers * And a third to convert value-pairs While the implementation works for me (with threaded(yes) and threaded(no) aswell), and I believe it to be correct, there's one thing I'm not quite sure about. But before I get there, let me try to explain how this simple thing is supposed to work! As Bazsi suggested, there are three methods: scratch_buffer_acquire(), scratch_buffer_release(), and scratch_buffers_reset(). All of them work with a thread-local GTrashStack, because my idea was that instead of trying to keep a list of available and used scratch buffers, we'll just store them in a stack, and leave it up to the scratch buffer users to return the buffers properly. This makes the implementation super simple, at the cost of not holding the hands of the scratch users. I believe that's an acceptable compromise. scratch_buffer_acquire() tries to pop an element from the stack, and if there's none, it creates a new one, and returns that. It also takes care of truncating the string to zero length. scratch_buffer_release() simply pushes an element onto the stack. scratch_buffers_reset() pops all elements from the stack, frees up both the GString contained within them, and the scratch buffer itself. Due to the way GTrashStack works, I introduced a new typedef: ScratchBuffer. The first element is a GTrashStack, which users need not care about, the second is the GString. ScratchBuffers are supposed to be used something like this: void test_scratchbuffer (void) { ScratchBuffer *sb = scratch_buffer_acquire(); g_string_printf(sb->s, "Hello %s!", "World"); /* Do something with sb->s */ scratch_buffer_release (sb); } There's one other trick in the implementation, however, and this is the one I'm unsure about: in order to avoid leaking madly, the thread-local scratch buffers MUST be destroyed when a thread finishes. This must also be done at the lowest level possible, to not litter the code with scratch_buffers_reset() calls. I did this with calling scratch_buffers_reset() at the end of main_loop_io_worker_job_start(), after all the finish callbacks have finished already. My reading of the code was that this is the place where threads are already finished, and they won't be needing scratch buffers anymore, and they should have released all of them aswell. All three patches are available on the feature/3.4/scratch-buffers branch of my github tree[0] too. While this is for 3.4, they should apply cleanly to 3.3 aswell (except for the jsonparser part, of course). [0]: https://github.com/algernon/syslog-ng/tree/feature/3.4/scratch-buffers

2 6

[PATCH 0/1]: json-parser()
by Gergely Nagy 31 Oct '11

31 Oct '11

Following this mail, a bigger patch will be sent, that implements a JSON parser - a fairly simple one, for now. I did not want to explain every little detail in the commit message, so this umbrella mail is sent first, with a few details that cannot be found in the commit message (there will be some overlap, though). This patch (and any further developments I make in the future, until the parser is merged) will be available on the feature/3.3/json/parser branch of my new and shiny git tree[1], as soon as I push it out. [1]: git://github.com/algernon/syslog-ng.git First of all, here's a little code snippet that shows how to use the module: ,----[ syslog-ng.conf ] | @module tfjson | @module jsonparser | | source s_json { tcp(port(12345) flags(no-parse)); }; | destination d_json { | file("/var/log/messages.json" | template("$(format-json --scope dot-nv-pairs)\n")); | }; | parser p_json { json-parser(prefix(".json.")); }; | log { source(s_json); parser(p_json); destination (d_json); }; `---- With this config, we can send logs to this source as follows: ,----[ shell ] | $ echo '{"string": "this is a string!\\n\\nmultiline!", "int": 42, "double": 3.14 }' | nc localhost 12345 `---- And 'lo and behold, the destination looks like this: ,----[ /var/log/messages.json ] | {".json.string":"this is a string!\n\nmultiline!",".json.int":"42",".json.double":"3.140000"} `---- Since syslog-ng stores every value as a string, they will all be converted to strings. At some point in the future, when we can also store types, this information will be transmitted through, and format-json will preserve the types. For now, the parser has only one optional parameter: prefix(). I think you can figure out what it does. I think this is pretty darn cool as it is! Now, lets get down to the gory implementation details, as I'm sure you're all very interested in that! At the core, we have a LogJSONParser structure, which holds the configuration (hi, gchar *prefix!), and two GStrings, that are used over and over again during processing. The reason these two GStrings (serialized.key and serialized.value) are there, is to have as few memory allocations as possible: so we allocate the strings once, and reuse them over and over again. We also have a JSON tokener here, for similar reasons. Parsing itself is delegated to json-c, and all the parser does is iterate over the parsed object's keys, coerce them into strings, prepare a key (based on prefix and the parsed key), and store them in a LogMessage. Then we're done. Yes, really. The rest is boilerplate. Of course, life ain't that simple. For now, there's a bug where the JSON can't be parsed, we honour that with a tasty segmentation fault. This will be fixed at a later time.

2 8

preparations for 3.3.2
by Balazs Scheidler 31 Oct '11

31 Oct '11

Hi, Since there are a nice number of fixes accumulated on the 3.3 tree, I'd like to prepare for the 3.3.2 release. Before doing the actual release though, I'd appreciate any kind of feedback you can give. The current state is in git right now, I'll try to create a timestamped tarball later this weekend. Thanks. -- Bazsi

3 4

[PATCH 1/2] pdbtool: Bail out on errors even if validating only.
by Gergely Nagy 31 Oct '11

31 Oct '11

When run with the --validate flag, and an error is detected, short circuit to the next file, instead of running the rest of the validation with garbled data. Reported-by: Peter Czanik <czanik(a)balabit.hu> Signed-off-by: Gergely Nagy <algernon(a)balabit.hu> --- modules/dbparser/pdbtool.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/modules/dbparser/pdbtool.c b/modules/dbparser/pdbtool.c index 13bc7d4..c2f9117 100644 --- a/modules/dbparser/pdbtool.c +++ b/modules/dbparser/pdbtool.c @@ -694,12 +694,14 @@ pdbtool_test(int argc, char *argv[]) { fprintf(stderr, "%s: Unable to detect patterndb version, please write the <patterndb> tag on a single line\n", argv[arg_pos]); failed_to_validate = TRUE; + continue; } g_snprintf(cmd, sizeof(cmd), "xmllint --noout --nonet --schema %s/patterndb-%d.xsd %s", PATH_XSDDIR, version, argv[arg_pos]); if (system(cmd) != 0) { fprintf(stderr, "%s: xmllint returned an error, the executed command was: %s", argv[arg_pos], cmd); failed_to_validate = TRUE; + continue; } } -- 1.7.7.1

2 2

MSGHDR and rewriting PROGRAM macro
by Patrick H. 31 Oct '11

31 Oct '11

I've got a box running syslog-ng 3.2.4, and I have a rewrite changing the PROGRAM macro. The problem is this doesnt affect the contents of the MSGHDR macro. Additionally if you try to do a rewrite on MSGHDR, it complains that MSGHDR is read-only. I'm inclined to say this is a bug, but wanted to get official opinion on the issue. -Patrick

2 1

Parsing Cisco FWSM with device-id
by Martin Holste 30 Oct '11

30 Oct '11

So I have a customer who has enabled the device-id configuration directive on his FWSM, and that means that instead of this from a normal FWSM: <174>%FWSM-6-302013: Built inbound TCP... it sends this: <174>FWSMHostName %FWSM-6-30203: Built inbound TCP... This means that the program name does not get properly parsed as syslog-ng pushes it into the msg field. If I can't convince the customer to remove the device-id setting, what's the least CPU-intensive way of coping with this so that program and msg are set correctly?

3 4

syslog-ng does not start when a destination hostname is unresolvable
by Heiko Gerstung 29 Oct '11

29 Oct '11

Hi! I am using syslog-ng for my network appliance and came across a problem with unresolved destination hosts. But first of all I have to say that from all the syslog daemons I looked at, syslog-ng really stands out as the most versatile and flexible solution. So, thank you for this great piece of software! In my configuration it is possible to specify a number of remote syslog servers, to which my device forwards all log entries via TCP or UDP/514 in addition to logging everything to local files (/var/log/messages etc.). Now, when a customer enters an unresolvable hostname, syslog-ng does not start at all and therefore the whole system is without a syslog daemon. My current workaround is to try and resolve the configured hostnames myself and only write them to the generated syslog-ng.conf file when this succeeds, but I wonder if there is no configuration option or commandline switch that prevents syslog-ng from completely stopping to work when it cannot resolve a hostname. And, is this really the intended default behavior? On my system (and on almost every other system I assume), syslog-ng starts long before network connectivity is available in order to provide logging services during the boot sequence. I would have expected that, if one of the destinations cannot be resolved, syslog-ng starts without it and periodically tries to resolve it later. I did not find anything about this in the documentation (manpages of syslog-ng and syslog-ng.conf) or in the FAQ, the only thing I found was a bug in bugzilla (https://bugzilla.balabit.com/show_bug.cgi?id=63) which has been filed in 11/2009 and reports that --syntax-only does not catch unresolved _sources_ although this is considered a critical error and prevents syslog-ng from starting. I would assume that this is the same for unresolved destinations. Any comments on this? I know that ntpd tries to resolve configured servers in a separate thread which retries resolving them every once in a while and starts using such a host as soon as it could be resolved. Best Regards, Heiko

2 1

[PATCH] logproto: Fix log_proto_file_writer_flush()'s partial construction.
by Gergely Nagy 29 Oct '11

29 Oct '11

When log_proto_file_writer_flush() encountered a partial write, and tried to construct a self->partial buffer, that contains all the data we didn't write yet, the starting offset computation was... interesting. What we want to copy into self->partial, is whatever is left in the last, partially processed buffer (i0), then append the full contents of the rest. Calculating the starting offset of this first buffer was done in a quite convoluted way, involving the sum of the length of the buffers we already touched, the lenght of the last fully processed buffer, and the total number of bytes already written. This makes my head spin, especially since it can be simplified to substracting the number of bytes to copy from the first buffer from the total length of it. The attached patch simplifies the offset calculation, and it also fixes a subtle bug! Lets assume 5 buffers, the first one 100, the second 200, the third 300, the fourth 400 and the fifth 500 bytes, totalling to 1500 bytes. Lets assume we managed to write out the first three buffers, and half of the fourht: 800 bytes. In this case, rc will be 800, sum will be 1000, i0 will be 3, and ofs will be 200. So far, all is well. But when we try to compute the starting offset within the first partial buffer, we end up with: rc - (sum - buf[i0 - 1].length), which, when values are substituted becomes: 800 - (1000 - 300) = 100! This is obviously not correct: we've already written out half of the fourth buffer, yet, we start copying from the 100th byte instead of the 200th! After the fix, when the starting position is buffer[i0].length - ofs, we get the correct value of 200, and all is well. Reported-by: SZALAY Attila <sasa(a)balabit.hu> Signed-off-by: Gergely Nagy <algernon(a)balabit.hu> --- lib/logproto.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/logproto.c b/lib/logproto.c index bdf9695..5047c98 100644 --- a/lib/logproto.c +++ b/lib/logproto.c @@ -299,7 +299,7 @@ log_proto_file_writer_flush(LogProto *s) /* allocate and copy the remaning data */ self->partial = (guchar *)g_malloc(self->partial_len); ofs = sum - rc; /* the length of the remaning (not processed) chunk in the first message */ - memcpy(self->partial, self->buffer[i0].iov_base + rc - (i0 > 0 ? (sum - self->buffer[i0 - 1].iov_len) : 0), ofs); + memcpy(self->partial, self->buffer[i0].iov_len - ofs, ofs); i = i0 + 1; while (i < self->buf_count) { -- 1.7.7.1

3 5

[PATCH] tfjson: Make $(format-json) have less unneccessary whitespace.
by Gergely Nagy 29 Oct '11

29 Oct '11

When compiling with jsonc, use a custom formatter, so that the generated JSON does not have superflous whitespace between elements, and the only whitespace in the JSON is in the content parts. Signed-off-by: Gergely Nagy <algernon(a)balabit.hu> --- modules/tfjson/tfjson.c | 32 ++++++++++++++++++++++++++++++++ 1 files changed, 32 insertions(+), 0 deletions(-) diff --git a/modules/tfjson/tfjson.c b/modules/tfjson/tfjson.c index 65daadd..eba2147 100644 --- a/modules/tfjson/tfjson.c +++ b/modules/tfjson/tfjson.c @@ -28,7 +28,9 @@ #include "config.h" #ifdef HAVE_JSON_C +#include <printbuf.h> #include <json.h> +#include <json_object_private.h> #endif #ifdef HAVE_JSON_GLIB @@ -54,6 +56,35 @@ tf_json_prepare(LogTemplateFunction *self, LogTemplate *parent, } #if HAVE_JSON_C +static int +tf_json_object_to_string (struct json_object *jso, + struct printbuf *pb) +{ + int i = 0; + struct json_object_iter iter; + sprintbuf (pb, "{"); + + json_object_object_foreachC (jso, iter) + { + gchar *esc; + + if (i) + sprintbuf (pb, ","); + sprintbuf (pb, "\""); + esc = g_strescape (iter.key, NULL); + sprintbuf (pb, esc); + g_free (esc); + sprintbuf (pb, "\":"); + if (iter.val == NULL) + sprintbuf (pb, "null"); + else + iter.val->_to_json_string (iter.val, pb); + i++; + } + + return sprintbuf(pb, "}"); +} + static gboolean tf_json_foreach (const gchar *name, const gchar *value, gpointer user_data) { @@ -72,6 +103,7 @@ tf_json_append(GString *result, ValuePairs *vp, LogMessage *msg) struct json_object *json; json = json_object_new_object(); + json->_to_json_string = tf_json_object_to_string; value_pairs_foreach(vp, tf_json_foreach, msg, 0, json); -- 1.7.7.1

2 3

Re: [syslog-ng] syslog-ng 100% cpu utilization issue
by Jain, Vaibhav (GE Healthcare) 29 Oct '11

29 Oct '11

Hi, I am using RHEL 5.5 and the syslog-ng version present in below link is for EL 6. Can you please share syslog-ng 64 bit for RHEL 5.5 http://download.fedora.redhat.com/pub/epel/6/x86_64/repoview/syslog-ng.h tml Thanks in advance for your support. Regards, Vaibhav -----Original Message----- From: Pillai Pramod-a23020 [mailto:pramod.p_pillai@nsn.com] Sent: Friday, October 28, 2011 6:38 PM To: Jain, Vaibhav (GE Healthcare) Subject: RE: [syslog-ng] syslog-ng 100% cpu utilization issue The client and server uses the same software. The client and server is distinguished by the config file. Pramod -----Original Message----- From: syslog-ng-bounces(a)lists.balabit.hu [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of Jain, Vaibhav (GE Healthcare) Sent: Friday, October 28, 2011 6:32 PM To: Syslog-ng users' and developers' mailing list Subject: Re: [syslog-ng] syslog-ng 100% cpu utilization issue Thanks for sharing syslog-ng. Can you please share syslog-ng client and server both ? In the below link only one RPM is there. I don't know whether this is client or server. http://download.fedora.redhat.com/pub/epel/6/x86_64/repoview/syslog-ng.h tml -----Original Message----- From: syslog-ng-bounces(a)lists.balabit.hu [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of Balazs Scheidler Sent: Thursday, October 27, 2011 8:20 PM To: Syslog-ng users' and developers' mailing list Subject: Re: [syslog-ng] syslog-ng 100% cpu utilization issue On Thu, 2011-10-27 at 16:12 +0200, Gergely Nagy wrote: > "Jain, Vaibhav (GE Healthcare)" <Vaibhav.Jain(a)ge.com> writes: > > > Can you please share the syslog-ng client and server RPMs of > > syslog-ng > > 3.2.4 or above 64 bit for RHEL OS? > > http://download.fedora.redhat.com/pub/epel/6/x86_64/repoview/syslog-ng > .html > > If that's for a too new OS version, then I do not know any ready made > RPMs for older RHEL versions. > syslog-ng binaries are supplied as a part of EPEL (community maintained packages for RHEL) for free and as far as I remember syslog-ng is part of that. ======================================================================== ======= shameless plug follows (don't read if you are not interested in paid offerings) ======================================================================== ======= [Please Scroll down] The Premium Edition of syslog-ng does support a wide range of RHEL versions (starting with RHEL2 to RHEL6). With syslog-ng PE 4.0 it support 46 different OS version / architecture combinations, which are quality checked with thourough automatic testing on each. So if you have a wide variety of platforms, you can check that out. Not to mention that in case you have a problem, you can ask support for help. -- Bazsi ________________________________________________________________________ ______ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq ________________________________________________________________________ ______ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq

2 3