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
pgpRmqXAuy8Kd.pgp
Description: PGP signature
