Root file system at 100% unable to reduce 1

[oglet]

I am working on a SUN 6000 server running solaris 2.5.1. We are running volume manager and oracle 7.3. when you do a on / (root) directory it states 0 avalable capacity 100%. When I look in the directory there is a directory called /proc that has all these humungus files but I am unabele to delete them out. Is there a way to <br>
delete these files without crashing the system? Should /proc be mounted as a seprate mount point?

 

[AndyBo]

Don't delete /proc! It's a virtual file system that contains details of running processes. As such, it's not actually taking up any physical disk space anywhere. It's just a mapping of some information in RAM onto a virtual FS.<br>
<br>
Have another look around / for anything else that might be taking up space.<br>

 

[jfk]

Oglet:<br>
<br>
Can you give us the output of df -k, so that we can have an idea as to the filesystem layout?<br>
<br>
Thanks,<br>
jfk

 

[evaz]

Also you may want to look at the crotab file to see if it logging infor to your / and hence taking it to 100%. Also can you state size of drive.

 

[Bhodi]

Check system mail, and application mail files.<br>
Often if the /usr is under root ( not a good idea )<br>
These mail files will fill up during development or implementation. They are safe to move or ftp to another system for review. I would look at the /var/adm/messages files as well. This may not be pruned often enough. If ther have been numerous reboots or a hardware problem this will become large as well.

 

[slars]

One thing I found with {l}users is that they wrote to /dev accidentally. They thought they were writing to /dev/rmt/0m (hp-ux world), but really wrote the backup to /dev/rmt/om - a much different beast! This filled up the root partition in a hurry, as well.<br>
<br>
You may want to go to single user (if possible), umount everything that is not necessary, and do a du -sk, and look for suspicious sizes (such as a 20mg /etc or 10mg /dev).<br>
<br>
Hope this helps.<br>
<br>
slars

 

[pankaj100]

<br>
move openwin directory to another file system and provide a link for it in /. this will straight away remove a lot of space being occupied by it.<br>
<br>
Also if the server is also a mail server then move /var/mail to another file system and provide a link in /<br>
<br>
i hope this helps you

 

[Guest_imported]

I have seen this symtom before on Suns but I ran into this a lot on AIX. One of the things to check is the open files and consider what has been cleaned up. Sometimes, if an open file is emptied or unlinked from the directory tree the disk space is not deallocated until the owning process has been terminated or restarted. The result is an unexplainable loss of diskspace. If this is the cause a reboot would clear it up. If you can't reboot consider any process the would be logging to that partition as a suspect and check all of your logs for any entries that imply rapid errors in a process.<br>
<br>
Another possibility is that the space has been used in an area that is now covered by a mounted filesystem. It is not uncommon if your system has failed boot at some point and entered system management mode, during which time in efforts to correct the problem moved or wrote something into one of the directories that are overlaid later, thinking that the filesystems were mounted. This has caused me a late night before. <br>
<br>
I guess the proper sequence would be looking at killable/restartable processes that do logging, then go for the reboot if possible and preferably boot to single user mode or better yet init state 1. This will give you the chance to verify the reduction in disk space. If it is still full, then look around in the directories that will be hidden by mounted filesystems in higher init states. That is probably the scenario that I would follow...<br>
<br>
Good luck, if it turns out to be some strange and exotic problem please post your solution.<br>
<br>
Thanks,<br>
Murray Chase

 

[bigscouse]

Editors such as vi often write there buffer to /tmp and /var/tmp. If they crash out during a large edit this will leave a large file with a spurious name. This has often caused the problem you describe on the systems that I have supported.<br>
<p>Ged Jones<br><a href=mailto:gedejones@hotmail.com>gedejones@hotmail.com</a><br><a href= > </a><br>

 

[OpenSys]

I know this is older post but if its not been resolved, there is a possibility that if you use the CDE or OpenWIN maybe files have been deleted through the Desktop and although are logically deleted they are still in the wastebasket, therefore still occupying disk space in another location.

 

[uudavid]

If you are running POP3 on this box, I have noticed a tendency for users getting a lot of mail to kill thier mail client because they think it has become stuck, and then pop will sometimes leave behind large files in /tmp. If you have a user do this several times in a row with a mail spool that is a couple of meg. in size it doesn't take long to fill the disk.