[Logcheck-devel] Comments in ignore files

Lars Wirzenius liw at iki.fi
Tue Oct 23 06:25:18 UTC 2007


ma, 2007-10-22 kello 18:08 -0500, Karl Schmidt kirjoitti:
> I'm not sure if I'm allowed to put comments in the ignore files?
> 
> If not, I suppose the documentation should say so. If so, the docs should have an example of 
> how.
> 
> If not - I would want to add this as a wishlist item - I think being able to comment the 
> rues would be quite useful...
> 
> Please cc me if responding..

I've wanted to do the same thing, and as far as I understand, it's not
currently possible.

In fact, I wanted to go one step further, and include test data for each
rule. I maintain a private liw-logcheck-database package, which has
additional rules tailored for my personal needs, and for that I wrote a
little script to read a new kind of input file and write out the input
files that logcheck actually wants. The new input file looks like this:

        # init(8) reports when it switches run levels. On a desktop machine,
        # having logcheck flag every shutdown or reboot is excessive, so we ignore
        # switches to run level 0.
        Level: workstation
        Log: Jul 26 04:58:03 agnes init: Switching to runlevel: 0
        Match: ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ init: Switching to runlevel: 0$
        
        Level: workstation
        Log: Aug 31 12:31:36 agnes init: Trying to re-exec init
        Match: ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ init: Trying to re-exec init$

I have another script that reads these new kind of files and verifies
that all sample log messages (there can be any number of them per match
rule) are actually matched by their rules. This is so that I can apply a
bit of Test Driven Development to my rules database: whenever there is a
new log message that should be ignored, I add first add it as a sample
line, and then write or tweak the rule. If, for instance, the wording of
init's messages above changes in a future version, I can just add the
new wording, and make sure the rules match both the old and new
messages.

I wonder, would this be welcome to the main logcheck database, too? The
scripts I have are run at build time, so no actual changes to logcheck
itself would be needed (and, thus, no performance impact, either).

-- 
Those who do, decide.





More information about the Logcheck-devel mailing list