Date: Wed, 26 Feb 2003 21:50:34 -0800 From: Wes Peters <wes@softweyr.com> To: Terry Lambert <tlambert2@mindspring.com>, Garance A Drosihn <drosih@rpi.edu> Cc: arch@FreeBSD.ORG Subject: Re: NEWSYSLOG changes Message-ID: <200302262150.34760.wes@softweyr.com> In-Reply-To: <3E59B3C9.650144CC@mindspring.com> References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> <p05200f1bba7f40fe23c0@[128.113.24.47]> <3E59B3C9.650144CC@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 23 February 2003 09:55 pm, Terry Lambert wrote:
> Garance A Drosihn wrote:
> > Yes, I have an idea of what I want to do for that, but it will be
> > done as a separate patch. I have several different changes in
> > mind, and I'm trying to figure out the best order to make them.
>
> I'm pretty happy with what Garance has said he intends to do in
> this area.
>
> > Note that the problem isn't the first roll (where the 40-meg file
> > turns into /var/log/somelog.0), it's that later checking may see
> > that /var/log/somelog is 0 bytes (particularly if /var/log is out
> > of disk space), and thus the 40-meg logfile is *never* rotated
> > after that first shot.
>
> Actually, the problem in the case of the InterJet was that in the
> case of an out-of-space, the space was not available, not that
> there would not be subsequent log rolls, as you imply here.
>
> Specifically, there are a lot of things that go on /var besides
> log files. One of these is the pid files for various programs,
> which fail to start if they cannot be created, and many of which
> do not necessarily run as root. Another is temporary files, for
> things like mail queue entries, which may occur on /var/tmp, if
> it is the designated /tmp directory. This is a common case,
> when /var is the only writeable FS in the system (for example).
Oh, hell, that's easy, you solve that with a /log filesystem.
> > Once I add the -R option, and once you add the improvements to
> > syslogd itself, then the situation that Terry describes is less
> > likely to happen. I do want to do something about it, though.
>
> As long as it's possible to set *some* option up to drain the FS
> down to a less than full state, I'm mostly agnostic on the method
> used to specifically do it. I've stated my preferences, from a
> product design and remote support perspective (rewrite history
> and save only the last XXX of the last log file); I think that's
> the most reasonable approach, but there's also something to be said
> about saving the events around the time the failure started that
> ended up leaving me with a full disk. So... I'm mostly agnostic.
Being smart about sensing that something has gone bonkers and is
babbling into the logs would be an excellent step forward. The
"last line repeated XXX times" cache is perhaps a few entries too
short...
> I never fixed this at Whistle because it was Archie's code, and
> the best way to piss off your coworkers is to rewrite their code
> out from under them. 8-) 8-).
Really? We used to have races to see who could fix each others
bugs quickest at DoBox. ;^)
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200302262150.34760.wes>