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.

One of the things I like about UFS is that it has 8% of reserved space
and when syslogd is running as root, it can still log, even when /var/
is full of users' data. Of course there should be separate /var/log/
partition, but...

In my opinion it'll be good, if we can stop logging various levels when
we hit Avail=0% and stop the rest at Avail=-4% maybe.
Maybe we should take logs only from logpriv when Avail=0%...

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
[EMAIL PROTECTED]                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!

Attachment: pgp0wQir6ywqB.pgp
Description: PGP signature

Reply via email to