Date: Tue, 11 Apr 2006 11:46:00 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: Robert Watson <rwatson@FreeBSD.org> Cc: src-committers@FreeBSD.org, "Christian S.J. Peron" <csjp@FreeBSD.org>, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/syslogd syslogd.c Message-ID: <20060411184559.GA14844@odin.ac.hmc.edu> In-Reply-To: <20060331090421.I9972@fledge.watson.org> References: <200603302104.k2UL4qF7086165@repoman.freebsd.org> <20060331080654.GB776@turion.vk2pj.dyndns.org> <20060331090421.I9972@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > >> This change allows syslogd to ignore ENOSPC space errors, so that when= =20 > >> the > >> filesystem is cleaned up, syslogd will automatically start logging aga= in > >> 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 tryi= ng=20 > >to write to the full filesystem - and the kernel will log the attempts t= o=20 > >write to a full filesystem. Whilst there's rate limiting in the kernel,= =20 > >this sort of feedback loop is undesirable. >=20 > What I'd like to see is an argument to syslogd to specify a maximum full= =20 > level for the target file system. Log data is valuable, but being able t= o=20 > write to /var/tmp/vi.recover is also important. syslogd -l 90% could=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% capacit= y. =20 > This prevents the kernel from spewing about being out of space also. The= =20 > 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. -- 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 --envbJBWh7q8WU6mo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEO/lnXY6L6fI4GtQRAiFJAKDmUiOAlSWCEFCj/vpGJ9uPqSexkwCfYgxn Z73HsqD+5ynuUOXhfXNrOpo= =FVmX -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060411184559.GA14844>