Summary: root space is full & can't telnet?

From: Chen, Sunny (Sunny.Chen@gtedc.gte.com)
Date: Tue Aug 18 1998 - 12:39:37 CDT


Hello Sun Gurus,

Thanks for everybody's help, I got a lot of replies after post the
original message. Since there are too many people who replied my
previous message, I got valuable tips to check my Sparc 20 station,
thank you all very much. Below I post my question message (partial,
since the original message was too long), and some feedback I think it
will help others next time. I only removed core dump file and removed
some old files I found which were stored in /var/tmp long time ago.
There are some information which are more than removing core file or
checking /var directory, I still post it below and it might help someone
else.

Thank you all for the kindness help.

Sunny ^_^

Original Question:
> Hello Sun Gurus,
>
> I was opening a Netscape window and couple telnet section
windows on my
> Sun Sparc 20 station, when I was trying to move one of the
telnet
> window, suddenly, all the telnet window disappeared. No
matter how many
> new windows I opened and tried to connect to the net, there's
no
> reaction of telnet any more.
>
> I checked the disk space (df -k) and found that the root
directory is in
> 100% usage. > I checked the directory under /root, found that
/proc is taking the
largest space in /root.

> Some files in /proc are back to May, I guess if I can remove
those "old"
> files in /proc, maybe I can reduce the root space and the
telnet might
> work again.
>
> Is it correct? If so, how to remove the files in /proc and to
reduce the
> root capacity?

Feedback Tips:

(1) The files in /proc don't take up any space. The sizes in there just
give you an idea of how big each running process on the system is.
Removing the big ones might cause you too much pain.
Start by removing /core, and then check in /var for things to delete, or
at least compress, especially things like:
        /var/cron/log
        /var/adm/messages.*
        /var/log/syslog.*

du -sk will also give you a better clue as to how much space is being
consumed by each directory.

(2) Here's a list of files you should check:
/var/adm/wtmpx
/var/adm/wtmp
/var/adm/utmpx
/var/adm/utmp
/var/cron/log
/var/log/syslog*
/var/adm/messages*
/var/preserve/*

If a backup was done manually, you should also look at your /dev
directory. A common typo is to specify the backup device with a "o"
instead of a "0".
(3) ** since "rm core" and check directories under /var have helped me a
lot, I still post this answer for people who might need it later. **

Don't remove the files in /proc. This will cause major problems with
your system. Doing an ls -l doesn't give you the complete picture. You
need to look at the du command. This command will tell you how many
blocks each file and directory is taking up. ie let's say that in the
/etc directory you had 20 files that each took up 10 blocks then du
would report that /etc is using 200 blocks.
As to /proc it is a list of all of the processes running on your system.
Removing these files will cause those proccesses to crash. You could
inadvertantly kill a very important process. The best way to clean up
is to reboot. Also is /var directory on your root slice. If so this is
more than likely the cause of your problems. Check and cleanup some log
files.
        Failing this you are going to have to backup everything to tape
re-format the drive and restore the tape information. Before you do
that
there are a few other options that you have:
1) Install Solstice Disk Suite and use growfs. (You will need to
install another HDD)
2) Do a search for all core files and delete them. find / -name
core -print (You could get fancy here and have find automatically delete
files.
3) Make sure that /opt, /usr, /var, & user home directories are all
on seperate slices. These are the ones that will grow when you install
applications, patches...etc and will cause your root file system to
become full.

(4) For starters, you can probably trash the core file... that will free
up a little space. You could clean out your lost+found directory as
well if necessary.

(5) FYI, if you can't telnet in, If have found that sometimes rsh
requires fewer resources than telnet (actually rshd vs. telnetd/login)
But it sounds like you have one session open. You might try comparing
du -sk -mount / against df -k / They should be the same. If not, maybe
you have files on / underneath a mount point. boot in single user mode
or off cdrom and mount / but nothing else, and you may find it.



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:46 CDT