root partion full ( / )

[Barry Ashcroft]

Hi,

I'm running version 5.1A on a Tru 64 server and the root partion is sitting at 99% when checking "df". I'm not able to connect to the server or indeed login. I'm in single user mode and looking for advice on the best way to find suitable files to delete from the root partition to increase available space. (i'm assuming this is why i cannot log in to the server??)

thanks

[Kapil Jha]

hi
you are rite,you are not able to login because / is full,do to single user mode
at / give du -sk *|sort -n
and fin which file is having lot of space would come at the end....
if possible null wtmp file in /var (by >wtmp).
You can remove crash data if it old......
rest recursivery use du -sk *|sort -n to file which files are taking lot of space.....
this would help i think ;)

[Hein van den Heuvel]

Maybe you have /tmp still assigned to root?
In that case, sart by clearing /tmp
It should really be a softlink to /var/tmp or /usr/tmp

Other than that, you have to assume/hope it is a single, or a few, large log files getting out of control. I would probably use 'find / -size +1000k' to find those.

Finally, is there anything special which has been done on the server recently? Like rebuilding the kernel?
Check ls -ltr /vmu*
Maybe there are a few too many kernels hanging around? They tend to be god sized.

hth,
Hein.

[Barry Ashcroft]

Hi,

thanks for the suggestions. i'm logged in as single user (boot -fl s, mount -u /)so when i try to use the "du" command i get an error saying "du: not found". So i cant do the sorts to see if there are any real large files. As far as i can see there is only one copy of the kernel in /vmunix and a few system files over +1000k in size. Theses are the kernel, /sbin/sulogin, /shlib/libc.so & libc_r.so, /sys/BINARY/advfs.mod & std_kern.mod, /genvmunix, /vmunix.

the /tmp file has a couple of small files in it but when i try to delete them i get ": Read only file system" and therefore cannot delete.

thanks again in anticipation of any help you guys can give me

[Hein van den Heuvel]

You may need to do 'mountroot' instead of the mount -u (which used to be enough).

In single user mode only the statically linked /sbin images are available. Apparently su is not one of the. You'll need to mount /usr and then use /usr/bin/du

(you could put /usr/bin in you path to make that easier).

The 'big' files you mention soudn normal.
Here is what I get:

find / -xdev -size +1000k
/sbin/mount
/sbin/sulogin
/sbin/ufs_fsck
/sbin/mount_advfs
/shlib/libc.so
/shlib/libc_r.so
/shlib/libc_r.so.OLD
/proc
/sys/BINARY/std_kern.mod
/sys/BINARY/advfs.mod
/genvmunix
/vmunix
/vmunix.PrePatch

Hein.

[Barry Ashcroft]

Hi Hein,

Thanks for your advice!!!!

I cannot get (| "pipe") on single user mode but managed to output the result of du -sk * to a file of somesorts. Doesnt seem to be anything too big in there that i would be confident of deleting, no core dumps etc.

What would cause this to fill up??, although there probably wasnt too much free space on it anyway.

I have backups so it looks as though a restore is the best thing i can do, then resize the partitions.

I suppose its a good way to learn!!!

thanks

barry

[jim owens_1]

At least a /sbin/showfdmn -k root_domain would be something, the best we can do with "I'm on 5.1A and my disk is 99% full" is give you wild guesses...

- disk was originally partitioned too small. I think all standard disk labels on Tru64 are too small unless you are running a V4.0 release.

- patching up requires more space.

- missing mounts or missing symlinks caused the root_domain to get data it should not have.

- a bad application or script is placing data in the root_domain.

- the "root" user usually has their "home directory" on / and has grown their space used from applications like mail or web browsers.

- someone besides "root" has their home directory on / (very bad!)

- something has been recently added under /, use "ls -Rlt" or "find / -mtime 7" (7 days, pick your own count) to look for those things.

A quick solution to get to multi-user is to delete /vmunix.PrePatch because that is just an old kernel from before the last patch install. If it isn't present, someone probably deleted it because of previous space issues.

If you are going to do a reinstall (which you must do for a bigger root file system), I suggest 5.1B.