/ is at 100%

[Dimitri Karagiannis]

My / directory is usually at 35% but checking my syslog I saw that it was increasing every 5 to 8 minutes. It seems that there is a file that is being populated but i can't seem to locate it. The error that it's giving me in /dev/root is:

Pid 28326 received a SIGSEGV for stack growth failure.Possible causes: insufficient memory or swap space,or stack size exceeded maxssiz.

vxfs: mesg 001: vx_nospace - /dev/root file system full (1 block extent)
Memory fault

Your help is appreciated,

Dimitri

[James R. Ferguson · Accepted solution]

Hi:

Check /dev for core files and/or non-special files like /dev/rmt/om instead of /dev/rmt/0m.

...JRF...

[Tracey]

I had a problem once with my /usr/adm/wtmp file growing by leaps and bounds - installing a patch fixed it.

[Victor BERRIDGE]

Theres been a few good replies on the subjet lately in this forum, have a look later..
If it came suddenly, look in /dev if you can find files that have nothing to do with /dev...
It happens when people try to tar to a unknown tape device, so you will find a giant file instead...
Check in each directory whats space consuming...

Good luck

[Rick Garland]

There could be a file that the system is writing to in the / directory. You may not want it there because it is filling up the / filesystem. Some script or process is writing to this file. Find out which file this is and move it elsewhere into a filesystem. Modify the script or process telling it that the file is now in this location.

If the file fills up another filesystem, you don't have to worry about the whole system being affected. This will increase the uptime for the system.

[John Palmer]

Providing the file has not been removed and the process writing to it is still running, try this to help you find it:-

find / -xdev -size +10000000c exec ll {} \;

This will list every file in / (only no mountpoints) bigger than 10Mb.

If the file has been removed, you could try looking for processes that are not functioning correctly.

'fuser -c /' will display all processes that are using / but this will be most of them.

[Dave Wherry]

Another possibility is that a file that was open, being written to, was deleted. That file will continue to grow, but, you can't see it. Since it was deleted "ll" won't list it. The records on the disk appear to be swallowed by a black hole.
The only way I know to fix it is to fsck the file system. Since that file is open you will not be able to umount the file system and you can't umount / anyway. A reboot will work if this is your problem.