cvs commit: src/usr.sbin/syslogd syslogd.c

[Brooks Davis]

On Tue, Apr 11, 2006 at 11:58:02PM -0500, Christian S.J. Peron wrote:
> Brooks Davis wrote:
> >On Fri, Mar 31, 2006 at 09:06:32AM +0000, Robert Watson wrote:
> >  
> >>On Fri, 31 Mar 2006, Peter Jeremy wrote:
> >>
> >>    
> >>>On Thu, 2006-Mar-30 21:04:52 +0000, Christian S.J. Peron wrote:
> >>>      
> >>>>This change allows syslogd to ignore ENOSPC space errors, so that when 
> >>>>the
> >>>>filesystem is cleaned up, syslogd will automatically start logging again
> >>>>without requiring the reset. This makes syslogd(8) a bit more reliable.
> >>>>        
> >>>My sole concern with this is that this means that syslogd will keep 
> >>>trying to write to the full filesystem - and the kernel will log the 
> >>>attempts to write to a full filesystem.  Whilst there's rate limiting in 
> >>>the kernel, this sort of feedback loop is undesirable.
> >>>      
> >>What I'd like to see is an argument to syslogd to specify a maximum full 
> >>level for the target file system.  Log data is valuable, but being able 
> >>to write to /var/tmp/vi.recover is also important.  syslogd -l 90% could 
> >>specify that sylogd should not write log records, perhaps other than an 
> >>"out of space record" to a log file on a file system with >=90% capacity. 
> >>This prevents the kernel from spewing about being out of space also.  The 
> >>accounting code does exactly this, for identical reasons.
> >>    
> >
> >Anyone working on an implementation of this?  I just had more machines
> >blow up due to out of control logs from a crashing process in an
> >infinite coredump loop so I'll take a shot at it if someone else isn't.
> >
> >IMO, what's really important is to keep enough space that newsyslog can
> >do it's job.  I have plenty of log file that should compress at better
> >than 10:1 since they are all the same two lines over and over, but it
> >doesn't do any good when newsyslog can't compress the file and create a
> >new one.
> >
> Yes, I am still interested in solving this problem. I am on the west 
> coast for a couple more days. If it's causing problems, you can go ahead 
> and back it out until we can figure out a better solution.

What's there isn't really a problem for me.  I'm interested in a
solution that reserves space on the volume.  Robert's suggestion would
be plenty sufficent for me.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-all/attachments/20060412/efb695cf/attachment.pgp