Re: Preliminary log matching support

[Jan-Henrik Haukeland]

Very nice and an excellent function! The only thing I would change is  
to maybe use a bigger line buffer, STRLEN(256 bytes) seems to short  
as a general buffer? When I run this on my httpd-log I get for  
instance 353 as the longest line, the same for my mail log.

awk '{if(length($0)>l){l=length($0);i=$0;}}END{printf("MAX=%d [%s] 
\n",l,i);}' access_log


On 1. aug. 2005, at 14.37, Christian Hopp wrote:

> Hi!
>
> Good news everyone...
>
> I have made a first version for "logfile matching".  It lacks
> documentation and some verbose logging issues.  But it could be used
> for testing.
>
> Usage:
>
> check file foobar.log with path /tmp/foobar.log
>         if match "foo.*bar" then alert
>
> You need regex support in order to use this (without regex it makes no
> sense to me).  The initial read point is the file end. Upon inode
> change or filesize reduction the read counter is reseted to zero.  In
> case a file changes (increases) and is moved, the rest of the old one
> is gone and is not matched!  Only lines with "\n" or lines with the
> length of STRLEN are matched.
>
> Please have a look at it and give me some feedback for further changes
> or wishes.  As always the patch needs to applied agains todays CVS.
>
> Bye,
>
> Christian
>
> --
> Christian Hopp                                email: address@hidden 
> clausthal.de
> Institut für Elektrische Informationstechnik             fon:  
> +49-5323-72-2113
> TU Clausthal, Leibnizstr. 28, 38678 Clausthal-Zellerf.   fax:  
> +49-5323-72-3197
>                              pgpkey: https://www.iei.tu- 
> clausthal.de/pgp-keys/
> <monit_logmatch_prelim1.patch>

smime.p7s
Description: S/MIME cryptographic signature