From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 5 12:10:44 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 78D0416A4CE for ; Mon, 5 Apr 2004 12:10:44 -0700 (PDT) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EA2F43D2D for ; Mon, 5 Apr 2004 12:10:44 -0700 (PDT) (envelope-from cliftonr@lava.net) Received: by malasada.lava.net (Postfix, from userid 102) id 41E16153882; Mon, 5 Apr 2004 09:10:38 -1000 (HST) Date: Mon, 5 Apr 2004 09:10:37 -1000 From: Clifton Royston To: Paul Khavkine Message-ID: <20040405191037.GA17961@lava.net> Mail-Followup-To: Paul Khavkine , freebsd-hackers@freebsd.org References: <20040405190053.8145D16A4D1@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040405190053.8145D16A4D1@hub.freebsd.org> User-Agent: Mutt/1.4.2i 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:10:44 -0000 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