/tmp size

Have a Ultra 3000 w/Sol 2.5.1 on it.  Getting /tmp file system full every now and again.  When I look at /tmp, sure enough, it's 100% full, but the overall size of /tmp has been decreases from some 600M to 88K!  When I remove some files from /tmp, the overall size goes down 33K!  /tmp is mounted on swap.  I'm going to take a stab and say that a process is writing to swap or /tmp.  If this sounds like the case, how do I tell what that proc is?  If this is not the case, pls help me see the light!!!!
terryt121697Asked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

dhmCommented:
On Solaris 2.5.1 (& earlier, but I don't know how far back) /tmp is basically a ramdisk.  It uses system RAM, and swap, to hold files.  However, the tmpfs filesystem isn't the only thing using system RAM/swap space; all the programs running use that space too.  When you have a lot of progs running, or they're using up a lot of space, the capacity of your /tmp is reduced accordingly.  (Also, if you have a lot of stuff in /tmp, the amount of virtual memory available to processes is reduced.)

When you start having problems, look for big files in /tmp (use "ls -l") and big processes (use "ps -el" or "ps -alx"; the size of the process is reported in the "SZ" column).  That will allow you to find the culprit in most cases.  One case that escapes, though, is when a program creates a file in /tmp, then deletes it, but keeps a handle to the file and continues to write to it.  This will gobble up space in /tmp, but you won't be able to see the file when you do "ls -l".  I think you can detect that this is happening by comparing the output of the commands "du -s /tmp" and "df /tmp".  Du gives you the number of blocks (or kbytes or something) in files that are in /tmp; df gives you the absolute partition usage.  The du number should be about the same as the df "Used" number (or about half/twice as much, if one or the other reports in 512-byte blocks instead of kbytes).  If the numbers are significantly different, you may have an "invisible" file (caused as I described above).  If you suspect that you have such a file, you can use "fuser -c /tmp" to get a list of all process IDs that are using /tmp for any reason (e.g. they have an open file there, /tmp is their current directory, etc.)  Then you can do "fuser /tmp/*" to get a list of processes using each file in /tmp.  Any processes listed in the first list with "o" after their ID but not listed in the second list have open handles to files that have been deleted.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
terryt121697Author Commented:
Thanx, it was the proc writing to /tmp and keeping the handle.  That is why I couldn't see em'.  For now, I have increased /tmp and will fire off an e-mail to the programmers.  Thanx.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Unix OS

From novice to tech pro — start learning today.