Path: usenet.ee.pdx.edu!cs.uoregon.edu!sgiblab!uhog.mit.edu!europa.eng.gtefsd.com!gatech!concert!bigblue.oit.unc.edu!kahn
From: kahn@physics.unc.edu (Dan Kahn)
Newsgroups: comp.sys.sun.admin
Subject: Re: NOTICE: alloc: /: file system full
Date: 17 Aug 1994 03:07:42 GMT
Organization: UNC Dept. of Physics and Astronomy
Lines: 54
Message-ID: <32rutu$13nf@bigblue.oit.unc.edu>
References: <1994Aug16.092233.7725@inca.comlab.ox.ac.uk> <32rqkb$o6h@mother.usf.edu>
NNTP-Posting-Host: hercules.physics.unc.edu

     Himanshu Gohel wrote in article <32rqkb$o6h@mother.usf.edu> :
>
>In article 7725@inca.comlab.ox.ac.uk, ruprecht@mildred.physics.ox.ac.uk (Peter Ruprecht) writes:
>>
>>I have a somewhat related question, however.  We occasionally get the
>>  alloc: /: file system full
>>error message, but at times when we should have about 3MB available in /.
>>This space does NOT seem to be taken up in any files; I have searched particularly
>>carefully through all of /var.  If I reboot, the missing 3MB reappears.  Does 
>>anyone have any ideas where it might have gone to?  Is it a leak of some sort?
>
>Funny thing.  Just the other day we noticed a similar problem.  I was modifying
>'xv' to recognize another file format.  The resulting binary seemed to work
>great, but soon after we started using it to quickly view 100s of images, we
>got an error message from xv, and then from the system about insufficient space.
>The system proceeds to lock up and a reboot is necessary.  This problem has been
>reproduced on two machines.
>
>Like you said, /tmp (or /var/tmp) had a little space, but there are no large
>files.  It turns out there are supposedly unreferenced files which get cleared
>via fsck and the space is retrieved on rebooting.
>
>What I would like to find out is how to determine who is creating these
>unref files, and if this modified version of xv is creating them, when and
>where.  Anyone have hints on how to do this?
>

This often occurs when a program creates a file and then unlinks the
file *before* closing it.  This is a common trick because when the
program exits the file system automatically deletes the file so you
don't get leftover files if the program exits with an error.

from man page:

DESCRIPTION
     unlink() removes the directory entry named by  the  pathname
     pointed to by path and decrements the link count of the file
     referred to by that entry.  If this entry was the last  link
     to  the  file,  and  no  process has the file open, then all
     resources associated with the file are reclaimed.  If,  how-
     ever,  the file was open in any process, the actual resource
     reclamation is delayed until it is closed, even  though  the
     directory entry has disappeared.

I'm not sure how you go about finding out what program is using this
space easily.  One method is to start killing programs and checking
the filesystem after killing each one.

An alternative might be to use a program like "lsof" which can tell
you what files each program has open.  It is available on the net,
though I don't remember where.

--dan
--