[Logwatch-Devel] Ideas for 6.1: Normalized Umatched processing
blues at ds.pg.gda.pl
Thu Feb 24 15:14:11 MST 2005
On Thu, 24 Feb 2005, Kenneth Porter wrote:
> I'd like to suggest moving all Unmatched processing to Logwatch.pm.
> Currently it's handled in two distinct ways: Either by appending the
> unmatched strings to an array (which generates tons of lines in the
> report for some noisy services) or by building a hash of incidence
> counts keyed by content. The hash loses the original ordering of
> multi-line stuff, though. Perhaps the hash could remember the order that
> lines are first seen, and report them in that order.
> I noticed the noisiness of this as a result of debugging my ntp config
> yesterday, so I've got a lot of unrecognized startup/shutdown strings
> repeated many times in the report.
I think that more important thing is to prepare some common
Now every filter makes own displaying, very raw. It takes a lot of code,
needs a lot of care and gives various efects.
Good set of functions would be really nice and will allow to prepare new
filters really easy...
pozdr. Paweł Gołaszewski
If you think of MS-DOS as mono, and Windows as stereo,
then Linux is Dolby Pro-Logic Surround Sound with Bass Boost
and all the music is free.
More information about the Logwatch-Devel