file system is full

[Paul Wahner]

When I try to use the "man" command on anything, I get the following error message:

/tmp: write failed, file system is full

bdf indicates my /tmp is no where near full (47% used).

Any ideas why I get this and what I can do to correct it?

Thanks,
Paul Wahner

[Patrick Wallek]

How large is your /tmp area? If it is small, then you may be running out of space.

When you do a 'man some_command' it creates some files in your /tmp directory. I did a 'man vgchange' on one of my boxes. I then brought up another window while the man page is up and did an 'ls -lt /tmp | head' to see the newest files in /tmp. There are several that are related to the man command.

-rw-rw-rw- 1 root sys 26386 Mar 12 13:02 cat18670
-rw-rw-rw- 1 root sys 13554 Mar 12 13:02 man18670

When you are finished with the man command these files disappear. As you can see, these files don't take up much disk space, but if you are VERY short on disk space in /tmp and these files can't be created, then that may very well be your problem.

[Kurtkarl]

Hi,

Check your /tmp filesystem permission if it allows you to write on it using your account. Try this:
- umount /tmp (probably on single user)
- then once it's unmounted, check for the
file permission of /tmp directory if
it allows other accounts to write on it.
- if not, change the permission
- mount the filesystem back by doing:
mount /dev/vgxx/lvolx /tmp
- then try to run again what you have been
doing before.

Joey

[Marcel Boon]

Hi Paul,

Patrick gives a good explanation, asign him some points please.

To extend the /tmp:

First check diskspace before extending /tmp.
use for example vgdisplay -v volumegroup

1 Go to Single User mode (you can't umount /tmp in higher run level)
2 lvextend (see man lvextend)
example: lvextend -L 100 /dev/vg00/lvol4
3 extendfs (see man extendfs)
example: extendfs -F vxfs /dev/vg00/rlvol4
4 mount logical_volume onm /tmp
example: mount /dev/vg00/lvol4 /tmp
5 and go to your normally run-level (3)

Hope it helps

Marcel

[Paul Wahner]

Thanks for the responses. I did get things to work by cleaning out some of the files in /tmp and installing patch PHCO_23089. Actually, just removing some of the files in my /tmp gave me enough of something to at least run a 'man' command.

I still believe there is a problem somewhere because before I started removing files from /tmp there was ~177 Mb free. When I finished removing files there was ~204 Mb free. The /tmp partition was setup with ~400 Mb.

If I see this problem again, I still have the option to extend /tmp.

Thanks again.

Paul Wahner

[Satish Y]

Can u please explain what this patch does?..

[Bill McNAMARA_1]

You should use
bdf or df to show disk space.

Just thought I'd add that since noone else did.

Later,
Bill

[Paul Wahner]

Satish,
Patch PHCO_23089 is the S700_800 10.20 man(1)patch. The defect is the man command is creating unnecessary temporary files. The patch changes the code to no longer create these unnecessary files.

Bill,
The bdf and df commands is what I have been using to check my disk space. So unless these commands are grossly under reporting my available disk space I don't believe the overall problem I was having is/was related to my diskspace.

This then leads to my next question. If bdf and df say I have just over 177Mb in my /tmp partition, what tells the man command that this isn't enough space to create a temporary file? Conversely, when I cleaned out some files to get to bdf and df reporting my available space as just over 204Mb, what tells the man command that this is enough space to create the temporary files it needs and allow the man command to work?

[Danny Engelbarts]

Paul,

Another possability is that you were running out of inodes on that disk, i've seen exactly the same error message on a disk that disn't seem full at all (20% used) but had a _huge_ amount of nearly zero sized files on it!
In my experience files in /tmp are usually small to very small and so the number of inodes could be a problem.

Greetz, Danny

[Bill McNAMARA_1]

Okay sorry,
I believe that patch had something to do with a
local security root exploit had it not.
Exactly related to these tmp files and the
permissions on them. Related to this what is
the t bit? I'll ask in a seperate question
when I find that local exploit link again.


Later,
Bill

[Danny Engelbarts]

Hi,

In my last reply i forgot to mention how to check the number of inodes being used;

df -i [filesystem]

Regards, Danny