On Mon, 26 May 2014 16:11:52 +0200, Dag-Erling Smørgrav wrote:
> > "Ronald F. Guilmette" <[email protected]> writes:
>> I forgot that newsyslog(8) should limit the size of /var/log/messages, and
>> 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]"

Reply via email to