On 01/17/2011 07:22 PM, [email protected] wrote:
Attached is a test file to test various modes of imfile, the results of
the test, and a consolodated patch going back to
f7c20920046ebcb94eadadf1ebad97b634a12a2d (your merge of the other imfile
fixes)

I have merged this as well now. Please re-check, but I think it is OK. I will merge this into v5-devel tomorrow if I don't hear anything against that :)


It turned out that there were a lot of problems in my code, so there's
not much left of my initial patch. This is why I didn't just send in an
update to the prior patch

It would be good to have the config changes broken out as a separate
patch (as much for future educational benifits as anything else). I will
try and figure out how I can manipulate git to do this.

One other problem I had is that I couldn't make the extra parameter work
with ReadMultiLine, it would segfault every time, since nothing else
uses ReadLine, I ended up adding the paramter to Readline and
eliminating ReadMultiLine completely

I think this is a good solution. If we need to change that again, we can always do that.

One thing that surprised me is that it doesn't appear that control
characters in imfile are escaped the way that network received logs are
escaped. Did I miss some way to enable this? Initially I thought that
possibly only \n wasn't escaped, but some of my mistakes generated other
control characters.

I guess this issue simply never came up. The way imfile works, it needs to do the sanitazion itself. Because that would happen in the parsing step, but imfile data can not be run through the parser.

Please also have a look at this forum post:
http://kb.monitorware.com/viewtopic.php?f=37&t=10622

Not sure how serious this approach is, but it sounds interesting.

Rainer

David Lang


On Thu, 13 Jan 2011, [email protected] wrote:

Date: Thu, 13 Jan 2011 02:02:51 -0800 (PST)
From: [email protected]
Reply-To: rsyslog-users <[email protected]>
To: Rainer Gerhards <[email protected]>
Cc: rsyslog-users <[email protected]>
Subject: Re: [rsyslog] imfile paragraph patch

thanks. I will try to go over both of these tomorrow, but will
definantly do so no later than this weekend.

David Lang

On Thu, 13 Jan 2011, Rainer Gerhards wrote:

Date: Thu, 13 Jan 2011 10:43:37 +0100
From: Rainer Gerhards <[email protected]>
To: [email protected], rsyslog-users <[email protected]>
Subject: Re: imfile paragraph patch

I have now also created a new branch for this patch:
v5-devel-david-imfile

I added the config variable. See the commit log for useful
information and steps. While I was a bit hesitant to merge this patch
soon to the official branch (due to the problems I had with imfile),
I begin to think this is over-cautious. It should really not harm any
existing code. So please let me know when you have finished your
testing of the new code, I'll probably merge soon then.

Thanks!
Rainer

On 12/14/2010 04:57 AM, [email protected] wrote:
I discovered UnreadChar and so now mode 2 (indented follow-up lines)
has
a chance of working. again compile tested (and visually
code-reviewed by
someone else), but not executed.

David Lang

On Mon, 13 Dec 2010, [email protected] wrote:

This is a first cut of a modification to imfile to let it read
multi-line files.

As-is, this should have no effect on a system as it hard-codes the
mode to reading single lines (I really don't understand how to set a
config variable, but for someone who does, it should be simple to
replace the '0' in imfile.c with the value of the config file)

With this config option change, it should be possible to real logfiles
that have blank lines between multi-line log entries and have those
log entries treated as a single line.

I also have code in place (but disabled) to try and deal with the more
complicated layout where all lines after the first one are indented if
they are part of the same log entry. The problem I have is that when I
discover that I have finished reading a log entry I have already read
the first character of the next log entry. This extra character needs
to be put pack into the input buffer, but I don't know if that is
possible or not. If this isn't the case, I need a function that will
let me peek at the next character in the input buffer and make my
decision based on that.

This compiles, but I have not tested it anywhere yet. with the
hardcoded mode 0 for ('LF termination), there should be no change
other than an extra test against a constant for each character read
from a file.

David Lang


_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com


_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

Reply via email to