/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?
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.
0

Experts Exchange Solution brought to you by ConnectWise

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.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.