Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Apr 2006 23:58:02 -0500
From:      "Christian S.J. Peron" <csjp@FreeBSD.org>
To:        Brooks Davis <brooks@one-eyed-alien.net>
Cc:        src-committers@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org>, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org
Subject:   Re: cvs commit: src/usr.sbin/syslogd syslogd.c
Message-ID:  <443C88DA.5000309@FreeBSD.org>
In-Reply-To: <20060411184559.GA14844@odin.ac.hmc.edu>
References:  <200603302104.k2UL4qF7086165@repoman.freebsd.org> <20060331080654.GB776@turion.vk2pj.dyndns.org> <20060331090421.I9972@fledge.watson.org> <20060411184559.GA14844@odin.ac.hmc.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
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.
>
> -- Brooks
>
>   
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.

Cheers

-- 
Christian S.J. Peron
csjp@FreeBSD.ORG
FreeBSD Committer
FreeBSD Security Team




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?443C88DA.5000309>