/tmp is becoming 100 %

[roobala]

Hi All,

We have a system running HPUX 10.20 (C3600).
Here often we see /tmp is becoming 100% and when we check using du -sk on that filesystem, it will be around 50% only, Once we reboot the filesystem will be back to the normal size and that time the du output will be same of bdf o/p. We couldn't find anything other than rebooting.

What could be the reason, what should we need to do to resolve,

Thanks in Advance

[Michael Tully]

This is quite a normal occurance where someone has attempted to delete a file that is still in memory an in use by a process. So once a system is rebooted, the process will terminate and the filesystem size will return. What you need to do is ensure nobdy attempts to *just* try and delete files, whilst the filesystem is 100% full. You need to terminate the process that is causing it.

There is a tool called 'lsof' that can assist you. You can get it from here.

http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/lsof-4.61/

Here is some examples on it's usage.

To which files are open for a given process id (pid)

# lsof -p

To see all the open files associated with a particular command.

# lsof -c midaemon

User name.

# lsof -u
# lsof -u

processes being used via a socket.

# lsof -i tcp:23
# lsof -i udp:123

[Trond Haugen]

If you haven't already you should start planning for a OS upgrade as 10.20 will be obsoleted by 6/30/03.
(http://www.software.hp.com/RELEASES-MEDIA/history/slide2.html)

Regards,
Trond

[Yogeeraj_1]

hi,
check for which users are causing this "problem"!

another way is to do the following command to check the user creating the files that are filling up your /tmp.

ll -rtl /tmp |tail

if there is nothing you can do, you can cron a job to run a command like:
============================================================
#!/bin/sh
UTIL=/scripts/admin/sys
DIR=/tmp
logfile="$UTIL/logfiles/cleanup-tmp`date +%y%m%d%H%M`.lis"
emailadd1="myemail@domain.mu"

find ${DIR} -xdev -type f -mtime +7 -name '*.*' > $logfile
find ${DIR} -xdev -type f -mtime +7 -name '*.*' -exec rm -f {} \;

/usr/bin/uuencode $logfile "tmp-deleted.lis"|mailx -m -s "Report: Deleted tmp files on `date`" $emailadd1
#YD-15/10/2002
============================================================

hope this helps!

Regards
Yogeeraj

[Jean-Louis Phelix]

Hello,

Be careful with previous script ...

find ${DIR} -xdev -type f -mtime +7 -name '*.*' -exec rm -f {} \;

You will suppress files not modified since 7 days ... But it doesn't mean that this file is not opened by a running process which will need it later. If this file is a logfile and something needs to be written after 7 days of inactivity you will perhaps get in a situation where 'tmp is becoming 100% and when we check using du -sk on that filesystem, it will be around 50%' ... Reboot or kill the process will fix.

Regards,

Jean-Louis.

[Jean-Luc Oudart]

Some application would use TMPDIR or TEMPDIR location. If the variable is not set it would use /tmp by default.
Therefore, if the (temporary) files generated by the application are big this can fill up the /tmp and cause pb to other applications, OS included.
Check for these applications and when possibel have them to point their temporary directory to another file system.

my 2 cents.

Jean-Luc

[Simon Galton]

Another possible cause may be that there are many (many)small files, which are consuming entire blocks but are indivudually very tiny.

BTW, as one other person mentioned, you may want to consider upgrading from 10.20, which is soon to be out-of-support.

Best of luck,
SG

[fuji_ooh]

Hi,

Try fuser -c /tmp
The no with a o at the end are the PID of proc(s) having open files in /tmp.

Cheers
Florian