From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 5 12:14:27 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B84BB16A4CE for ; Mon, 5 Apr 2004 12:14:27 -0700 (PDT) Received: from smtp.distributel.net (cns2.distributel.NET [66.38.181.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52D3443D1D for ; Mon, 5 Apr 2004 12:14:27 -0700 (PDT) (envelope-from paul@colba.net) Received: from nat.mtl.distributel.net (OUT.NAT01.MTNDODS.distributel.NET [66.38.181.24]) by smtp.distributel.net (8.12.6/8.12.6) with ESMTP id i35JEQLs026296; Mon, 5 Apr 2004 15:14:26 -0400 (EDT) Received: from colba.net (paul@[10.14.61.42])i35IIl7w096364; Mon, 5 Apr 2004 14:18:48 -0400 (EDT) (envelope-from paul@colba.net) Sender: paul@nat.mtl.distributel.net Message-ID: <4071AFF2.50790D48@colba.net> Date: Mon, 05 Apr 2004 15:13:54 -0400 From: Paul Khavkine Organization: DISTRIBUTEL X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Clifton Royston References: <20040405190053.8145D16A4D1@hub.freebsd.org> <20040405191037.GA17961@lava.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.36 cc: freebsd-hackers@freebsd.org Subject: Re: File system full X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2004 19:14:27 -0000 I see. Any way to find out what process is doing it ? I doubt it's a local DoS since noone has shell access to the machine. Thanx Paul Clifton Royston wrote: > On Mon, Apr 05, 2004 at 12:00:53PM -0700, freebsd-hackers-request@freebsd.org wrote: > > Date: Mon, 05 Apr 2004 14:49:42 -0400 > > From: Paul Khavkine > > Subject: File system full > > To: freebsd-hackers@freebsd.org > ... > > > > Today for i have noticed that the /tmp partition on one of our mail > > servers was reported as > > full. I have checked if there's any files in /tmp but found that it > > wasn't true. > > > > du reports that /tmp is only using 50K. > > > > After a few minutes the size changed from 100% to 66%. > > > > Even that makes no sense: > > > > %df -h > > .. > > /dev/amrd0s1f 492M 298M 155M 66% /tmp > > > > %du -skh /tmp/ > > 16K /tmp/ > > > > > > Any clues to why it behaves that way ? > > Almost certainly a classic all-Un*x problem: > > There are long-lived running processes holding already-deleted files > open in /tmp. Such files have already removed from the directories, > and hence are not visible to ls or du, but can not be freed by the > operating system until the process which opened them terminates, hence > their space shows up in df and is not free for allocation. This can be > a form of local DOS, but it's more likely a coding/design error. > > I've particularly run into this with Apache + mod_perl on a high-load > website. Apache keeps processes around for a relatively long time, and > in the persistent perl environment, if files are not explicitly closed > they remain open by the interpreter - so a Perl script which creates > temp files and doesn't explicitly close them at the end of each > execution pass can really rack up the disk space with "invisible" > files. > > -- Clifton > > -- > Clifton Royston -- cliftonr@tikitechnologies.com > Tiki Technologies Lead Programmer/Software Architect > Did you ever fly a kite in bed? Did you ever walk with ten cats on your head? > Did you ever milk this kind of cow? Well we can do it. We know how. > If you never did, you should. These things are fun, and fun is good. > -- Dr. Seuss