On Mon, 26 May 2014 16:11:52 +0200, Dag-Erling Sm=F8rgrav wrote: > > "Ronald F. Guilmette" <[email protected]> writes: >> I forgot that newsyslog(8) should limit the size of /var/log/messages, a= nd >> that as long as you limit the size of that to a reasnable value, and as >> long as you have newsyslog(8) only keeping a finite & reasonable number >> of "rotated out" copies, then /var won't fill up. > It can still happen, since newsyslog only runs once per hour. If = > /var fills up between two newsyslog runs, there is no guarantee that = > the space freed up by deleting the oldest logs is sufficient to = > compress the newest log. The only way to really handle this issue = > would be to fold newsyslog into syslog. Mitigating that - in the case of single repeating messages at least - is = that syslog accumulates these and reports totals at a certain interval. At 5.5-stable (yes, I know) it was 10 minutes, just one example: May 16 19:17:05 x inetd[5768]: pop3 from 92.247.169.210 exceeded counts/min= (limit 4/min) May 16 19:17:26 x last message repeated 30 times May 16 19:19:37 x last message repeated 55 times May 16 19:29:44 x last message repeated 450 times May 16 19:39:44 x last message repeated 367 times [.. every 10 minutes until ..] May 16 22:09:42 x last message repeated 349 times May 16 22:10:57 x last message repeated 54 times Of course just to blow my case, tonight I find 967 lines in 82418 bytes = from two hosts apparently in Mexico doing the same gig in parallel, for = less than two minutes - over a very slow ADSL line. syslog doesn't need = the complication of attempts at such pattern matching. Rather than merging the two, might syslog trigger adhoc rotations by = newsyslog - of a particular log, not all - after learning how to measure = 'stress', perhaps by rates of delta filesize, diskspace consumption etc? Then newsyslog would only need to learn how to be so invoked? just a thought, Ian _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"