On 11/04/2006 Todd Troxell wrote: > Thanks for you report. no problem.
> > Security Events > > =-=-=-=-=-=-=-= > > Mar 16 22:31:56 resivo syslog-ng[6932]: Log statistics; > > processed='source(s_all)=2186', processed='destination(df_auth)=407', > > processed='destination(df_news_dot_notice)=0', > > processed='destination(df_news_dot_err)=0', > > processed='destination(df_uucp)=0', processed='destination(df_mail)=0', > > processed='destination(df_user)=126', > > processed='destination(df_facility_dot_notice)=0', > > processed='destination(df_daemon)=1415', > > processed='destination(df_facility_dot_crit)=0', > > processed='destination(df_debug)=28' > > I have tested this with a couple of versions of logcheck and I'm unable to > reproduce. It is worth nothing that the string caught above contains > substrings that would trigger a violation, and therefore needs a line in > violations.ignore.d as well. I suspect this is a configuration issue. > > Please let me know your findings. i used latest logcheck from debian/unstable, and i've reproduced this bug on at least three machines. i found out now, that not the line length is the problem, but the word 'debug' in the line. if i change the word 'debug' to 'debux' or whatever else, logcheck doesn't stumble over the line. so are there some rules to not ignore lines containing 'debug', regardless whether a ignore rule matches them or not? ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
