root file system full

[Mohamed K Ahmed]

Dear all,
I have an AS4100 running Tru64 UNIX V 4.0G that has root file system full at 102%.
I tried everything that is mentioned in the forums to delete unwanted files, but it is still full, I can't get it to decrese the space used.
Any thoughts...ideas...things I missed?

MO

[Michael Schulte zur Sur]

Hi,

please post:
showfdmn -k root_domain
du -kxs /
df -k

thanks,

Michael

[Mohamed K Ahmed]

The system is running on UFS not AdvFS
Attached is the outputs you wanted

MO

[Hein van den Heuvel]

Try this:

find / -mount -size +500k -exec ls -g {} \;

-mount

will find files on the same file system as the current starting path name so it will NOT go down /usr and so on.

-size +2000k

Start out looking at the somewhat bigger (2MB) files.
It may find a stray tar/dump or core file.
Perhaps a few too many vmunix versions?


- exec ls -f {} \;

show details for matching files.


Once you explained the biggies, take it a step down like:
find / -mount -size -2000k -size +500k

(any file on /rz8a between 1/2MB and 2MB)



hth,
Hein.

[Ravi_8]

Hi

rebooting the m/c once will release some space

[Michael Schulte zur Sur]

Hi,

1. Is there a reason, you use ufs?
2. / is quite small, you should increase it.
3. There is more than 50mb difference between du and df. Boot machine in single user mode and look for files in the mount points, which are now hidden by the mounted file systems.

greetings,

Michael

[Ralf Puchner]

reboot to single user mode to be sure no processes have opened files which are hidden if using "du".

delete old kernels lying around and use
du -k /. Have a closer look to the /tmp and /dev directory.

[Mohamed K Ahmed]

he output is attached, I don't think that I have multiple or so big files
I think maybe rebooting the machine will release some space, I will do this during the weekend, but why??

MO

[Michael Schulte zur Sur]

Mohamed,

when you delete a file, that is opened by a process, the space is not released. du is fooled by the absence of the file and does not count the space. Please boot the machine into single user mode and look into the mount directories for files.

hth,

Michael

[Hein van den Heuvel]

Michael wrote: "look for files in the mount points, which are now hidden by the mounted file systems."

Yeah, good point. I forgot to mention that.
Let's say you had /tmp with a few file in it.
No you create a new device and mount on /tmp.
The old files there will be 'hidden'.
But you do not APPEAR to have a mountpoint that qualifies for that. Still...

The 'big' file list shows nothing excessive really. It suggestes some moving/cleanup in /sys/binary.

but really, as others wrote, maybe / was just made too small.

next step would be
find -s /* -mount
or
find -s /*/* -mount

That will point you to the directories that have enough block to worry about.

Hein.

[Ralf Puchner]

check /dev for "big" devices created by wrong handling.... (as written in my previous answer).

[Michael Schulte zur Sur]

Hi,

how did it work out?

Michael

[Mohamed K Ahmed]

Well, I didn't get a chance to reboot the system this last weekend.
I have another question, In the /etc directory, there are a set of files that starts with #.mrg.. and another set starts with .new.. and a third set starts with .proto..
Can I delete the files starting with #.mrg..?

[Hein van den Heuvel]

> Can I delete the files starting with #.mrg..?

Time to check the doc!

At any rate. Do NOT just delete.
At the very least make a parallel structure under /usr, maybe called /usr/backup_root and load that with say
cp -pR /etc /usr/backup_root
cp -pR /dev /usr/backup_root
and so on...

But you 'owe' us much more feedback.
Many more concrete question were asked.
We believe that as you try to answer them you will stumble into the rigth solution eventually.

Cheers,
Hein.

[Ralf Puchner]

Hein,

cp is not a valid choice, use vdump, vrestore instead (as described within the admin guide).

[Michael Schulte zur Sur]

Hi,

I would not fiddle with the system files and delete what you suggested. I wonder, if you could save much space with that?
Could you post
du -kx /
please.

thanks,

Michael

[Michael Schulte zur Sur]

as attachment please!

forgot to say that.

Michael

[Ralf Puchner]

maybe time to study previous postings....

du counts the real filelength not the minimum space reserved (e.g. file with 900 bytes will use 1024 bytes on disk as minimum, but du counts 900).

df uses the allocated size (1024 bytes).

so you have a difference. If the disklabel size differ from df size there must be a "hidden" file somewhere (as explained by other forum members). So killing the process or reboot with single user mode is the only chance to get rid of it.

If disklabel and df have equal sizes look for unnecessary file or new files created. /dev is a good starter....

[Mohamed K Ahmed]

Here is the output for the du -kx / and the df -k output
I will post a summary at the end, when I solve this problem.
I am starting to believe that whe I reboot, this will clear the problem, but I would like to go to the end to find out what made it happened and where is the big files (if there is any)

tell me what do you think regarding the outputs attached

MO

[Michael Schulte zur Sur]

Hi,

if it still takes time for a shutdown and reboot, there is one thing, you may do.
move /sys/binary to antother place and replace it with a link to that place.
Ralf, correct me, but I think this dir is only used for kernel built.

hth,

Michael

[Mohamed K Ahmed]

Good idea...Is this thing confirmed?
does the link has to be setup in a certain way or permissions? or link it as it is now?
will moving this directoyry change the dates of the files or cause any problems in the future?

MO

[Ralf Puchner]

Mohammed,

read my postings again! Do not delete any system files!!!!!!

du and df is useless if problem occures from a "hidden" file. This was written before and I don't believe you really understand my previous postings!

Reboot is not the only option, due to the fact that every application returns open file handles, resources etc. to the os if it will be terminated the simples solution is to restart the application.

[Mohamed K Ahmed]

Are these resources in the /proc directory?

[Ralf Puchner]

why? proc is only an API reflecting internals.

Why not using the simple "ps" command and restart your applications? It could be only one of your private applications....

But be sure partition size and df does not match! If so your filesystem is really full and you must delete one of the other files.
(PS: be sure no mountpoint overlays existing files e.g. /mnt contains files but is now mounted to /dev/rz5c)

[Mohamed K Ahmed]

Ralf,

The disklabel partition size on rz8a is 128.351 MB
The df -k reports total size 129.110 and used is 128.586
Do you think that the root partition is getting smaller or is full and now I need to enlarge the partition somehow??