Date: Sun, 23 Feb 2003 21:55:21 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Garance A Drosihn <drosih@rpi.edu> Cc: Wes Peters <wes@softweyr.com>, arch@FreeBSD.ORG Subject: Re: NEWSYSLOG changes Message-ID: <3E59B3C9.650144CC@mindspring.com> References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> <p05200f08ba7b59fffe0a@[128.113.24.47]> <p05200f0cba7b6990a408@[128.113.24.47]> <200302231911.14264.wes@softweyr.com> <p05200f1bba7f40fe23c0@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
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). > 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. 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-). -- Terry 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?3E59B3C9.650144CC>