cvs commit: src/usr.sbin/syslogd syslogd.c
joao.barros at gmail.com
Fri Mar 31 09:29:50 UTC 2006
On 3/31/06, Robert Watson <rwatson at freebsd.org> 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.
> Robert N M Watson
I was in bed last night and thought about this but also remembered
something: imagine a very busy syslog machine, won't this "free space
check" be a burden?
I have a syslog machine at work that can fill up 30GB of disk in less
than 2 hours and it's busy as it is :-)
The solution as you correctly point out is it being optional.
Take in consideration that checking by percentage can be tricky. On a
very large disk that's inefficient, on a small one dangerous.
Maybe a choice between percentage and real space is best.
Does the kernel automatically starts complaining about out of space at
90%? If so that undermines my previous suggestions, but the questions
More information about the cvs-src