[PATCH 1/2] [dbparser] inherit nvpairs from parent in correlation action
From: Balint Kovacs <blint@blint.hu> This patch implements an inherit-name-value-pairs attribute for message type actions is patterndb correlation. In case this is set to TRUE, the triggering log message is cloned and all name-value pairs are automagically copied to the emitted message. The values set in the values XML subtree overwrite the original values. In case it is set to FALSE or unspecified, a new message is generated and only the values set manually are added to it. <actions> <action> <message inherit-name-value-pairs='TRUE'> <values> <value name="PROGRAM">my-program-name</value> <value name="MSG">Hello new message!</value> <value name="contextid">${session-id}@2</value> </values> </message> </action> </actions> Signed-off-by: Balint Kovacs <blint@blint.hu> --- modules/dbparser/patterndb-int.h | 1 + modules/dbparser/patterndb.c | 32 +++++++++++++++++++++++++++++--- 2 files changed, 30 insertions(+), 3 deletions(-) diff --git a/modules/dbparser/patterndb-int.h b/modules/dbparser/patterndb-int.h index 0434847..154b686 100644 --- a/modules/dbparser/patterndb-int.h +++ b/modules/dbparser/patterndb-int.h @@ -126,6 +126,7 @@ typedef struct _PDBAction guint8 content_type; guint16 rate; guint32 id:8, rate_quantum:24; + gboolean inherit_nvpairs; union { PDBMessage message; diff --git a/modules/dbparser/patterndb.c b/modules/dbparser/patterndb.c index 8720ea0..168a24c 100644 --- a/modules/dbparser/patterndb.c +++ b/modules/dbparser/patterndb.c @@ -388,6 +388,17 @@ pdb_action_set_trigger(PDBAction *self, const gchar *trigger, GError **error) g_set_error(error, 0, 1, "Unknown trigger type: %s", trigger); } +void +pdb_action_set_inheritance(PDBAction *self, const gchar *inherit_nvpairs, GError **error) +{ + if (strcmp(inherit_nvpairs, "TRUE") == 0) + self->inherit_nvpairs = TRUE; + else if (strcmp(inherit_nvpairs, "FALSE") == 0) + self->inherit_nvpairs = FALSE; + else + g_set_error(error, 0, 1, "Unknown inheritance type: %s", inherit_nvpairs); +} + PDBAction * pdb_action_new(gint id) { @@ -398,6 +409,7 @@ pdb_action_new(gint id) self->trigger = RAT_MATCH; self->content_type = RAC_NONE; self->id = id; + self->inherit_nvpairs = FALSE; return self; } @@ -552,9 +564,18 @@ pdb_rule_run_actions(PDBRule *self, gint trigger, PatternDB *db, PDBContext *con case RAC_NONE: break; case RAC_MESSAGE: - genmsg = log_msg_new_empty(); - genmsg->flags |= LF_LOCAL; - genmsg->timestamps[LM_TS_STAMP] = msg->timestamps[LM_TS_STAMP]; + if (action->inherit_nvpairs) + { + LogPathOptions path_options = LOG_PATH_OPTIONS_INIT; + path_options.ack_needed = FALSE; + genmsg = log_msg_clone_cow(msg, &path_options); + } + else + { + genmsg = log_msg_new_empty(); + genmsg->flags |= LF_LOCAL; + genmsg->timestamps[LM_TS_STAMP] = msg->timestamps[LM_TS_STAMP]; + } if (context) { switch (context->key.scope) @@ -942,6 +963,11 @@ pdb_loader_start_element(GMarkupParseContext *context, const gchar *element_name } else if (strcmp(element_name, "message") == 0) { + for (i = 0; attribute_names[i]; i++) + { + if (strcmp(attribute_names[i], "inherit-name-value-pairs") == 0) + pdb_action_set_inheritance(state->current_action, attribute_values[i], error); + } if (!state->in_action) { *error = g_error_new(1, 0, "Unexpected <message> element, it must be inside an action"); -- 1.7.9.5
From: Balint Kovacs <blint@blint.hu> It was quite unintuitive to determine if a previous message exists in the correlation context as the basis of the decision whether an action should be run or not. This patch adds support for the min-messages and max-messages attributes of the action XML node, the action is run only, of the correlation context contains more or equal messages as the min-messages attribute and less or equal messages as the max-messages attribute. This way it is easy to determine if a context contains sufficient amount of messages for the event to be complete and run a different action if it is not, e.g. if 2 messages are needed for an event, this should emit an event message if there are enough messages and an error message if not. <actions> <action min-messages='2'> <message> <values> <value name="PROGRAM">event</value> <value name="MESSAGE">Hello event!</value> </values> </message> </action> <action max-messages='1'> <message> <values> <value name="PROGRAM">error</value> <value name="MESSAGE">Hello error!</value> </values> </message> </action> </actions> Signed-off-by: Balint Kovacs <blint@blint.hu> --- modules/dbparser/patterndb-int.h | 2 ++ modules/dbparser/patterndb.c | 10 +++++++++- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/modules/dbparser/patterndb-int.h b/modules/dbparser/patterndb-int.h index 154b686..9c1385e 100644 --- a/modules/dbparser/patterndb-int.h +++ b/modules/dbparser/patterndb-int.h @@ -122,6 +122,8 @@ enum typedef struct _PDBAction { FilterExprNode *condition; + guint32 min_messages; + guint32 max_messages; guint8 trigger; guint8 content_type; guint16 rate; diff --git a/modules/dbparser/patterndb.c b/modules/dbparser/patterndb.c index 168a24c..715fb4a 100644 --- a/modules/dbparser/patterndb.c +++ b/modules/dbparser/patterndb.c @@ -410,6 +410,8 @@ pdb_action_new(gint id) self->content_type = RAC_NONE; self->id = id; self->inherit_nvpairs = FALSE; + self->min_messages = 0; + self->max_messages = 0; return self; } @@ -557,7 +559,9 @@ pdb_rule_run_actions(PDBRule *self, gint trigger, PatternDB *db, PDBContext *con if ((!action->condition || (!context || filter_expr_eval_with_context(action->condition, (LogMessage **) context->messages->pdata, context->messages->len))) && - pdb_rule_check_rate_limit(self, db, action, msg, buffer)) + (action->min_messages == 0 || action->min_messages <= context->messages->len) && + (action->max_messages == 0 || action->max_messages >= context->messages->len) && + pdb_rule_check_rate_limit(self, db, action, msg, buffer)) { switch (action->content_type) { @@ -958,6 +962,10 @@ pdb_loader_start_element(GMarkupParseContext *context, const gchar *element_name pdb_action_set_condition(state->current_action, state->cfg, attribute_values[i], error); else if (strcmp(attribute_names[i], "rate") == 0) pdb_action_set_rate(state->current_action, attribute_values[i]); + else if (strcmp(attribute_names[i], "min-messages") == 0) + state->current_action->min_messages = atoi(attribute_values[i]); + else if (strcmp(attribute_names[i], "max-messages") == 0) + state->current_action->max_messages = atoi(attribute_values[i]); } state->in_action = TRUE; } -- 1.7.9.5
balint.kovacs@balabit.com writes:
It was quite unintuitive to determine if a previous message exists in the correlation context as the basis of the decision whether an action should be run or not. This patch adds support for the min-messages and max-messages attributes of the action XML node, the action is run only, of the correlation context contains more or equal messages as the min-messages attribute and less or equal messages as the max-messages attribute.
This way it is easy to determine if a context contains sufficient amount of messages for the event to be complete and run a different action if it is not, e.g. if 2 messages are needed for an event, this should emit an event message if there are enough messages and an error message if not.
Now this was confusing at first (and even after in-person explanation, it is still a bit hard to wrap my head around it based on this description). The naming is bad, sorry! Just to clarify it to myself, what happens here, is that the patch introduces two new attributes for the action tag. Since I can't explain what they accomplish too well yet, I'd like to use an example: Lets suppose we have an event we want to corellate from at least five messages: program: session=f00; login; username="user" program: session=f00; task="something" program: session=f00; status="ok" program: session=f00; task="noop" program: session=f00; logout We want to make sure that whenever a corellation action fires, we have all five messages (and we'll assume that the five messages we have are the correct ones): for that, there's the new min-messages attribute. When set to 5, it will only emit a message when there are five or more messages in the context. Add this action to the closing pattern, and missin accomplished. It is most useful for closing patterns, but there's probably use case for using it elsewhere too. And to detect errors, we need a way to emit a message when we receive a closing pattern, but don't have enough messages: that's what max-messages does. Lets say that the noop task did not happen, so when the logout message arrives, we only have four messages in the context. If max-messages is set to 4, then the action will trigger. I find the naming unintuitive, though, it's kind of backwards... How about if-msg-count-ge (min-messages) and if-msg-count-le (max-messages)? I think that would make it slightly easier to understand what they're used for. Transforming your example, this:
<actions> <action min-messages='2'> <message> <values> <value name="PROGRAM">event</value> <value name="MESSAGE">Hello event!</value> </values> </message> </action> <action max-messages='1'> <message> <values> <value name="PROGRAM">error</value> <value name="MESSAGE">Hello error!</value> </values> </message> </action> </actions>
...would turn into: <actions> <action if-msg-count-ge='2'> <message> <values> <value name="PROGRAM">event</value> <value name="MESSAGE">Hello event!</value> </values> </message> </action> <action if-msg-count-le='1'> <message> <values> <value name="PROGRAM">error</value> <value name="MESSAGE">Hello error!</value> </values> </message> </action> </actions> I for one, would understand what this latter does without further explanation. Provided I understood the intent, that is. :) Perhaps we could even drop the if- prefix too, I'm not sure. Any ideas or opinions? -- |8]
In your (new) example, <actions> <action if-msg-count-ge='2'> <message> <values> <value name="PROGRAM">event</value> <value name="MESSAGE">Hello event!</value> </values> </message> </action> <action if-msg-count-le='1'> <message> <values> <value name="PROGRAM">error</value> <value name="MESSAGE">Hello error!</value> </values> </message> </action> </actions> There is only an allowance for the two cases <=1 and >-2 It might be nice to allow for multiple if-msg actions such that I could do something at 3 messages and then another at 15 messages etc. What I see in our logs are warnings that are correlated and repeat, and they never get to an "error" according to the application, but if there are more the 10 such warning, there is a problem state. Some construct that would allow <action if_msg_count='$count ge 2">... <action if_msg_count='($count % 10) eq 0'>... so that I can put an expression into the value and do actions on all kinds of things. In a different application I wrote, I used a "printf" style value. So '(%d %% 10) eq 0' This allows for expressions that contain the value more than once '(%d le 5) or (%d ge 10)'. All of this assumes that there is some way to keep a correlation open and activate multiple triggers to evaluate these actions, which may not be possible. Just thinking out loud. Evan. ________________________________________ From: syslog-ng-bounces@lists.balabit.hu [syslog-ng-bounces@lists.balabit.hu] On Behalf Of Gergely Nagy [algernon@balabit.hu] Sent: Saturday, November 10, 2012 7:36 AM To: Syslog-ng users' and developers' mailing list Subject: Re: [syslog-ng] [PATCH 2/2] [dbparser] min and max message count condition in correlation actions balint.kovacs@balabit.com writes:
It was quite unintuitive to determine if a previous message exists in the correlation context as the basis of the decision whether an action should be run or not. This patch adds support for the min-messages and max-messages attributes of the action XML node, the action is run only, of the correlation context contains more or equal messages as the min-messages attribute and less or equal messages as the max-messages attribute.
This way it is easy to determine if a context contains sufficient amount of messages for the event to be complete and run a different action if it is not, e.g. if 2 messages are needed for an event, this should emit an event message if there are enough messages and an error message if not.
Now this was confusing at first (and even after in-person explanation, it is still a bit hard to wrap my head around it based on this description). The naming is bad, sorry! Just to clarify it to myself, what happens here, is that the patch introduces two new attributes for the action tag. Since I can't explain what they accomplish too well yet, I'd like to use an example: Lets suppose we have an event we want to corellate from at least five messages: program: session=f00; login; username="user" program: session=f00; task="something" program: session=f00; status="ok" program: session=f00; task="noop" program: session=f00; logout We want to make sure that whenever a corellation action fires, we have all five messages (and we'll assume that the five messages we have are the correct ones): for that, there's the new min-messages attribute. When set to 5, it will only emit a message when there are five or more messages in the context. Add this action to the closing pattern, and missin accomplished. It is most useful for closing patterns, but there's probably use case for using it elsewhere too. And to detect errors, we need a way to emit a message when we receive a closing pattern, but don't have enough messages: that's what max-messages does. Lets say that the noop task did not happen, so when the logout message arrives, we only have four messages in the context. If max-messages is set to 4, then the action will trigger. I find the naming unintuitive, though, it's kind of backwards... How about if-msg-count-ge (min-messages) and if-msg-count-le (max-messages)? I think that would make it slightly easier to understand what they're used for. Transforming your example, this:
<actions> <action min-messages='2'> <message> <values> <value name="PROGRAM">event</value> <value name="MESSAGE">Hello event!</value> </values> </message> </action> <action max-messages='1'> <message> <values> <value name="PROGRAM">error</value> <value name="MESSAGE">Hello error!</value> </values> </message> </action> </actions>
...would turn into: <actions> <action if-msg-count-ge='2'> <message> <values> <value name="PROGRAM">event</value> <value name="MESSAGE">Hello event!</value> </values> </message> </action> <action if-msg-count-le='1'> <message> <values> <value name="PROGRAM">error</value> <value name="MESSAGE">Hello error!</value> </values> </message> </action> </actions> I for one, would understand what this latter does without further explanation. Provided I understood the intent, that is. :) Perhaps we could even drop the if- prefix too, I'm not sure. Any ideas or opinions? -- |8] ______________________________________________________________________________ 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
Evan Rempel <erempel@uvic.ca> writes:
There is only an allowance for the two cases <=1 and >-2
It might be nice to allow for multiple if-msg actions such that I could do something at 3 messages and then another at 15 messages etc. What I see in our logs are warnings that are correlated and repeat, and they never get to an "error" according to the application, but if there are more the 10 such warning, there is a problem state. Some construct that would allow
<action if_msg_count='$count ge 2">... <action if_msg_count='($count % 10) eq 0'>...
so that I can put an expression into the value and do actions on all kinds of things.
On my way home, I was thinking about something similar, encoding the relation into the attribute name sounded wrong. I was thinking about: <action msg_count=">= 2">, and implementing all the <, <=, ==, !=, >=, > relations. That's not as flexible as yours, but much easier to implement.
All of this assumes that there is some way to keep a correlation open and activate multiple triggers to evaluate these actions, which may not be possible.
As far as I understand, in the current implementation, multiple actions will trigger: all of those that match the pattern. But only those that have an appropriate message count will emit a message. (dbparser/patterndb things are still a bit fuzzy for me, I'm afraid) -- |8]
hi, what about introducing a template function that expands to the number of elements in the context? that way the condition could use that together with numeric comparisons that are already available. ----- Original message -----
balint.kovacs@balabit.com writes:
It was quite unintuitive to determine if a previous message exists in the correlation context as the basis of the decision whether an action should be run or not. This patch adds support for the min-messages and max-messages attributes of the action XML node, the action is run only, of the correlation context contains more or equal messages as the min-messages attribute and less or equal messages as the max-messages attribute.
This way it is easy to determine if a context contains sufficient amount of messages for the event to be complete and run a different action if it is not, e.g. if 2 messages are needed for an event, this should emit an event message if there are enough messages and an error message if not.
Now this was confusing at first (and even after in-person explanation, it is still a bit hard to wrap my head around it based on this description). The naming is bad, sorry!
Just to clarify it to myself, what happens here, is that the patch introduces two new attributes for the action tag. Since I can't explain what they accomplish too well yet, I'd like to use an example:
Lets suppose we have an event we want to corellate from at least five messages:
program: session=f00; login; username="user" program: session=f00; task="something" program: session=f00; status="ok" program: session=f00; task="noop" program: session=f00; logout
We want to make sure that whenever a corellation action fires, we have all five messages (and we'll assume that the five messages we have are the correct ones): for that, there's the new min-messages attribute. When set to 5, it will only emit a message when there are five or more messages in the context. Add this action to the closing pattern, and missin accomplished.
It is most useful for closing patterns, but there's probably use case for using it elsewhere too.
And to detect errors, we need a way to emit a message when we receive a closing pattern, but don't have enough messages: that's what max-messages does.
Lets say that the noop task did not happen, so when the logout message arrives, we only have four messages in the context. If max-messages is set to 4, then the action will trigger.
I find the naming unintuitive, though, it's kind of backwards...
How about if-msg-count-ge (min-messages) and if-msg-count-le (max-messages)? I think that would make it slightly easier to understand what they're used for.
Transforming your example, this:
<actions> <action min-messages='2'> <message> <values> <value name="PROGRAM">event</value> <value name="MESSAGE">Hello event!</value> </values> </message> </action> <action max-messages='1'> <message> <values> <value name="PROGRAM">error</value> <value name="MESSAGE">Hello error!</value> </values> </message> </action> </actions>
...would turn into:
<actions> <action if-msg-count-ge='2'> <message> <values> <value name="PROGRAM">event</value> <value name="MESSAGE">Hello event!</value> </values> </message> </action> <action if-msg-count-le='1'> <message> <values> <value name="PROGRAM">error</value> <value name="MESSAGE">Hello error!</value> </values> </message> </action> </actions>
I for one, would understand what this latter does without further explanation. Provided I understood the intent, that is. :)
Perhaps we could even drop the if- prefix too, I'm not sure.
Any ideas or opinions?
-- |8]
______________________________________________________________________________ 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
Balazs Scheidler <bazsi77@gmail.com> writes:
what about introducing a template function that expands to the number of elements in the context?
Mmm... that would require extending LogTemplate, and would also mean we have to expand templates in dbparser at action calling time, which sounds inefficient to me. Although things like <action when="$(<= ${.context.count} 10)"> looks cool, it would take quite a bit of work to get that done right I believe, and its performance would, in my opinion, be rather poor. So I'd rather have something like <action when-msg-count="<= N">, without the template magic first. Pros of when-msg-count: - Less code to implement - Better performance Cons: - Less flexible So.. lets have when-msg-count first, and later - if so need be - expand it towards a generic when=, at which point when-msg-count could become a thin, backward-compatibility wrapper around "when". -- |8]
Gergely Nagy <algernon@balabit.hu> writes:
Balazs Scheidler <bazsi77@gmail.com> writes:
what about introducing a template function that expands to the number of elements in the context?
Mmm... that would require extending LogTemplate, and would also mean we have to expand templates in dbparser at action calling time, which sounds inefficient to me.
...and I was so very wrong! While not a template function, but something equally simple was very easy: exporting the context length as the $CONTEXT_LENGTH variable gets pretty much the same thing done. While this solution has the side-effect of always adding CONTEXT_LENGTH to a message when there is a context, it's also a lot lighter than a template function, in my opinion. (The template function would have to go through some hoops while getting called, and would need to look up the context via context_id... a rather long dance) This means that <action condition='"${CONTEXT_LENGTH}" <= "2"'> works, and one can use any kind of template function too, so this would work too: <action condition='"$(% ${CONTENT_LENGTH} 10)" == "0"'> I pushed this - and a slightly reworked <message inherit-properties='TRUE'> patch - to the feature/3.4/dbparser/corellation-improvements branch, and will merge them to merge-queue/3.4 shortly. -- |8]
balint.kovacs@balabit.com writes:
This patch implements an inherit-name-value-pairs attribute for message type actions is patterndb correlation. In case this is set to TRUE, the triggering log message is cloned and all name-value pairs are automagically copied to the emitted message. The values set in the values XML subtree overwrite the original values. In case it is set to FALSE or unspecified, a new message is generated and only the values set manually are added to it.
This looks simple, and is backwards compatible, I like it. Picked it to my feature/3.4/dbparser/corellation-improvements branch for further testing. See my comments below, though.
diff --git a/modules/dbparser/patterndb.c b/modules/dbparser/patterndb.c index 8720ea0..168a24c 100644 --- a/modules/dbparser/patterndb.c +++ b/modules/dbparser/patterndb.c [...] +void +pdb_action_set_inheritance(PDBAction *self, const gchar *inherit_nvpairs, GError **error) +{ + if (strcmp(inherit_nvpairs, "TRUE") == 0) + self->inherit_nvpairs = TRUE; + else if (strcmp(inherit_nvpairs, "FALSE") == 0) + self->inherit_nvpairs = FALSE; + else + g_set_error(error, 0, 1, "Unknown inheritance type: %s", inherit_nvpairs); +}
Although there is no similar thing in patterndb yet (boolean flags of this kind), the xs:boolean type of XML can be "true", "false", "0", or "1", so we should - in my opinion - accept all of those, case insensitively. A simple way would be something like: if (inherit_nvpairs[0] == 't' || inherit_nvpairs[0] == 'T' || inherit_nvpairs[0] == '1') self->inerhit_nvpairs = TRUE; else if (inherit_nvpairs[0] == 'f' || inherit_nvpairs[0] == 'F' || inherit_nvpairs[0] == '0') self->inherit_nvpairs = FALSE; else g_set_error(error, 0, 1, "Unknown inheritance type: %s", inherit_nvpairs); What do you think? This'd allow things like inherit-name-value-pairs="FOR SURE" (and parse it as false), but I can live with that, as long as the valid cases are parsed correctly. This should be added to the XSD aswell, so that patterndb files using it can still pass validation. [...]
+ if (action->inherit_nvpairs) + { + LogPathOptions path_options = LOG_PATH_OPTIONS_INIT; + path_options.ack_needed = FALSE; + genmsg = log_msg_clone_cow(msg, &path_options); + } + else + { + genmsg = log_msg_new_empty(); + genmsg->flags |= LF_LOCAL; + genmsg->timestamps[LM_TS_STAMP] = msg->timestamps[LM_TS_STAMP]; + }
As you mentioned in person, valgrind was a bit upset about the log_msg_clone_cow() here, I'll investigate that once I've written some test cases. Which leads us to the next point: tests! I wants them. But since I need to learn patterndb aswell, I'll write them. -- |8]
On 11/10/2012 04:18 PM, Gergely Nagy wrote:
balint.kovacs@balabit.com writes:
This patch implements an inherit-name-value-pairs attribute for message type actions is patterndb correlation. In case this is set to TRUE, the triggering log message is cloned and all name-value pairs are automagically copied to the emitted message. The values set in the values XML subtree overwrite the original values. In case it is set to FALSE or unspecified, a new message is generated and only the values set manually are added to it. This looks simple, and is backwards compatible, I like it. Picked it to my feature/3.4/dbparser/corellation-improvements branch for further testing. Kewl, thanks.
See my comments below, though.
diff --git a/modules/dbparser/patterndb.c b/modules/dbparser/patterndb.c index 8720ea0..168a24c 100644 --- a/modules/dbparser/patterndb.c +++ b/modules/dbparser/patterndb.c [...] +void +pdb_action_set_inheritance(PDBAction *self, const gchar *inherit_nvpairs, GError **error) +{ + if (strcmp(inherit_nvpairs, "TRUE") == 0) + self->inherit_nvpairs = TRUE; + else if (strcmp(inherit_nvpairs, "FALSE") == 0) + self->inherit_nvpairs = FALSE; + else + g_set_error(error, 0, 1, "Unknown inheritance type: %s", inherit_nvpairs); +} Although there is no similar thing in patterndb yet (boolean flags of this kind), the xs:boolean type of XML can be "true", "false", "0", or "1", so we should - in my opinion - accept all of those, case insensitively. A simple way would be something like:
if (inherit_nvpairs[0] == 't' || inherit_nvpairs[0] == 'T' || inherit_nvpairs[0] == '1') self->inerhit_nvpairs = TRUE; else if (inherit_nvpairs[0] == 'f' || inherit_nvpairs[0] == 'F' || inherit_nvpairs[0] == '0') self->inherit_nvpairs = FALSE; else g_set_error(error, 0, 1, "Unknown inheritance type: %s", inherit_nvpairs);
What do you think?
This'd allow things like inherit-name-value-pairs="FOR SURE" (and parse it as false), but I can live with that, as long as the valid cases are parsed correctly.
This should be added to the XSD aswell, so that patterndb files using it can still pass validation.
[...] Thanks for pointing this out, this is of course more compatible, intuitive, so in short - better.
+ if (action->inherit_nvpairs) + { + LogPathOptions path_options = LOG_PATH_OPTIONS_INIT; + path_options.ack_needed = FALSE; + genmsg = log_msg_clone_cow(msg, &path_options); + } + else + { + genmsg = log_msg_new_empty(); + genmsg->flags |= LF_LOCAL; + genmsg->timestamps[LM_TS_STAMP] = msg->timestamps[LM_TS_STAMP]; + } As you mentioned in person, valgrind was a bit upset about the log_msg_clone_cow() here, I'll investigate that once I've written some test cases.
Which leads us to the next point: tests! I wants them. But since I need to learn patterndb aswell, I'll write them.
Great, thanks again, I'm quite short on time these days. Let me know if I can help. Balint
participants (5)
-
Balazs Scheidler
-
Balint Kovacs
-
balint.kovacs＠balabit.com
-
Evan Rempel
-
Gergely Nagy