From owner-cvs-src@FreeBSD.ORG Wed Apr 12 14:56:48 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49D6F16A401; Wed, 12 Apr 2006 14:56:48 +0000 (UTC) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FA1143D5E; Wed, 12 Apr 2006 14:56:38 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k3CEubKT031166; Wed, 12 Apr 2006 07:56:37 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k3CEubAK031165; Wed, 12 Apr 2006 07:56:37 -0700 Date: Wed, 12 Apr 2006 07:56:37 -0700 From: Brooks Davis To: "Christian S.J. Peron" Message-ID: <20060412145637.GC28966@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> <443C88DA.5000309@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XWOWbaMNXpFDWE00" Content-Disposition: inline In-Reply-To: <443C88DA.5000309@FreeBSD.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: src-committers@FreeBSD.org, Brooks Davis , Peter Jeremy , cvs-all@FreeBSD.org, Robert Watson , cvs-src@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/syslogd syslogd.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2006 14:56:48 -0000 --XWOWbaMNXpFDWE00 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > =20 > >>On Fri, 31 Mar 2006, Peter Jeremy wrote: > >> > >> =20 > >>>On Thu, 2006-Mar-30 21:04:52 +0000, Christian S.J. Peron wrote: > >>> =20 > >>>>This change allows syslogd to ignore ENOSPC space errors, so that whe= n=20 > >>>>the > >>>>filesystem is cleaned up, syslogd will automatically start logging ag= ain > >>>>without requiring the reset. This makes syslogd(8) a bit more reliabl= e. > >>>> =20 > >>>My sole concern with this is that this means that syslogd will keep=20 > >>>trying to write to the full filesystem - and the kernel will log the= =20 > >>>attempts to write to a full filesystem. Whilst there's rate limiting = in=20 > >>>the kernel, this sort of feedback loop is undesirable. > >>> =20 > >>What I'd like to see is an argument to syslogd to specify a maximum ful= l=20 > >>level for the target file system. Log data is valuable, but being able= =20 > >>to write to /var/tmp/vi.recover is also important. syslogd -l 90% coul= d=20 > >>specify that sylogd should not write log records, perhaps other than an= =20 > >>"out of space record" to a log file on a file system with >=3D90% capac= ity.=20 > >>This prevents the kernel from spewing about being out of space also. T= he=20 > >>accounting code does exactly this, for identical reasons. > >> =20 > > > >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=20 > coast for a couple more days. If it's causing problems, you can go ahead= =20 > 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 --=20 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 --XWOWbaMNXpFDWE00 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEPRUkXY6L6fI4GtQRAjYBAKCbWbGXydEW+UaNvzR/NTP9hsMSLwCgw/6h SUTQdMmHrzPbl482fEetOlk= =zcZA -----END PGP SIGNATURE----- --XWOWbaMNXpFDWE00--