cvs commit: src/usr.sbin/syslogd syslogd.c
brooks at one-eyed-alien.net
Wed Apr 12 14:56:48 UTC 2006
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
> >>>>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.
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
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-all/attachments/20060412/efb695cf/attachment.pgp
More information about the cvs-all