Date: Thu, 09 Sep 2004 12:42:03 -0500 From: Paul Schmehl <pauls@utdallas.edu> To: Bill Moran <wmoran@potentialtech.com> Cc: questions@freebsd.org Subject: Re: Phantom /var full messages Message-ID: <4F74CEAE598E547F3B43C2C3@utd49554.utdallas.edu> In-Reply-To: <20040909130333.67242dc4.wmoran@potentialtech.com> References: <44A044721750C2FA9877513F@utd49554.utdallas.edu> <20040909130333.67242dc4.wmoran@potentialtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--On Thursday, September 09, 2004 01:03:33 PM -0400 Bill Moran <wmoran@potentialtech.com> wrote: >> >> Any hints would be welcomed. What's the best way to troubleshoot this >> problem? > > First, if you could isolate it to just snort or just MySQL. > > Typically, folks have this problem because they try to rotate log files > without restarting the program that's logging to them. The rotate program > compresses the current log file into a new file, then deletes the original > file ... but the program is still logging to it. Thus the space fills up, > but there is no file to see the space in. Restarting the program doing > the logging causes the old file to disappear, and a new log file to be > created. > > On a guess, Snort would be the first thing I'd look at. However, MySQL > can create a TON of data if logging is enabled, so you may want to look > closely at it as well. > Thanks, Bill. That's really helpful. I suspected it was snort, but I wasn't sure. I'll shut down one process at a time and see when df "returns to normal". I am using newsyslog.conf which *should* HUP processes when logs are turned over, but maybe I missed something. Paul Schmehl (pauls@utdallas.edu) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F74CEAE598E547F3B43C2C3>