Number of files in /tmp

[Dan Coyle_1]

Hello, On HP-UX 11 23, is there a limit on the number of files in /tmp. Yesterday I ran into a situation where many of my apps would not start. Rebooted twice, sent dump to Hp, problem returned. By luck we found we could not create any file in the /tmp dir. bdf showed it was at 33% full. There were may zero byt files in /tmp, once we rm the files, apps began executing normally. I have located the culprit that creates the byte files and corrrect the problem. I am concerned that I may have an underlying problem. Thanks for any thoughts on this.

[Mike Shilladay · Accepted solution]

Hi Dan,

Sounds like you ran out of inodes before you ran out of space. If you have cured the program that created the zero length files then you should be now ok.

Mike.

[Geoff Wild]

Not a limit based on /tmp - but on the number of inodes asigned to it...

You can use df -i to check inodes...

# df -i /tmp
/tmp (/dev/vg00/lvol4 ) : 31264 total i-nodes
30282 free i-nodes
982 used i-nodes
3 % i-nodes used


Rgds...Geoff

[James R. Ferguson]

Hi Dan:

As a VxFS filesystem you should not run out of inodes and there should therefore be an "unlimited" ability to create files.

I suspect that your application cannot create a file because there is already one by the same name but owned by a different user (Uid), AND the sticky bit is set on the '/tmp' directory. This means that only root and the file's owner can delete it.

Applications should not be using '/tmp' but rathter '/var/tmp' although the same would apply there.

Regards!

...JRF...

[Dan Coyle_1]

Our spooler vendor directed to the /tmp directory. His app could not create any files. I did a touch testfilez (logged on as root), and it would not create. VxFS should have allowed the file to create. After removing the zero byte files, all was well. I agree that /tmp should not be used in this manner, some of these third party apps do not follow the rules.

[Dennis Handly]

>some of these third party apps do not follow the rules.

Ideally they should look at $TMPDIR or some such to control this.

I once found out /var/tmp was full of here document files because of a ksh bug with exec. It ran out of filenames because the PID got reused.