Date: Mon, 05 Apr 2004 15:13:54 -0400 From: Paul Khavkine <paul@colba.net> To: Clifton Royston <cliftonr@lava.net> Cc: freebsd-hackers@freebsd.org Subject: Re: File system full Message-ID: <4071AFF2.50790D48@colba.net> References: <20040405190053.8145D16A4D1@hub.freebsd.org> <20040405191037.GA17961@lava.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <paul@colba.net> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4071AFF2.50790D48>