Root fs getting a little full.

[Steven E. Protter]

Prior to my last Red Hat update.

/ fs was around 46% full, set for 500 Meg.

Now its 77%

The new kernels' wouldn't boot, so I did this:

cd /boot
rm the offending kernels and their source ans system files

vi grub/grub.conf

Adjusted the setting there to remove the delete kernels.

I did not touch any file named vmxxxxx

I'm still hanging around 72%

Any ideas on how to find and safely cut the fat?

On my HP-UX enterprise servers at work, we have a maintenance window and I can down the servers, put them in single user mode and just poke around the root with nothing mounted.

Interestingly enough, I can't do that with the Red Hat box so easily because its a 24/7 web hosting business.

Yes, I have a backup server, but I've not tested my switchover methodology yet and I want to do some cron work so that the DNS server BIND and httpd servers are always the same as the production server.

Then, down the network on prod, up the network by script on backup and we're on the backup server.

I really feel the need to clear the root fs now though. So, what other files can I safely delete.

I'm assuming some of the vmxxx files can go, but am not sure which ones.

What other areas of root fs do I need to look out to clear out those nasty new kernels?

Thanks.

Points will be awarded liberally for useful help.

Heck, tell me the weather, and I'll give you two points.

Steve

[Vincent Stedema]

Hi Steve,

It depends on how what your partition table looks like. Is /usr on it's own partition? If not, use "make clean" of "make mrproper" in /usr/src/linux to clean up compiled kernel drivers etc.

To find out which directories might be responsible for / growing larger and larger, use

find / -xdev -type d

Regards,

Vincent

[Jochen Heuer]

Hi Steve,

run this

$ du -sm `ls -A /` | sort -n

and check for the biggest directory / files that are *not* mountpoints.

If you're not sure what to do then just post results of the above command and from

$ df

Regards,

Jochen

[Steven E. Protter]

Thank you, I'll give it a try this evening and post results.

[Steven E. Protter]

Just wondering based on this output where to look...

[root@jerusalem /]# du -sm `ls -A /` | sort -n
du: `proc/12981/fd/3': No such file or directory
0 .autofsck
1 dev
1 initrd
1 lost+found
1 misc
1 mnt
1 opt
1 proc
1 tmp
6 bin
6 etc
10 sbin
22 boot
34 root
79 backups
217 var
240 home
247 lib
1808 usr

sbin looks a little fat, boot looks a little fat, everything else is a mounted fs

[Stuart Browne]

I would have used a slightly different command:

du -xm --max-depth=1

(only show sub-dirs on the current file-system, one level deep)

'sbin' at about 5-10 MB doesn't look all that un-usual.

Here's a dump from one of my systems (RH7.2), with only / and /boot filesystems:

1 ./lost+found
202 ./var
1 ./tmp
1 ./dev
11 ./etc
3141 ./usr
6 ./bin
1267 ./home
44 ./lib
34 ./mnt
47 ./opt
1866 ./root
10 ./sbin
1 ./.automount
1 ./tftpboot

Are /home, /root, and /var on the root FS, or on another?

Either show us a mount table, or the output from the command above, and we'll help you a bit further, but it doesn't really look as if anything is out-of-place.

[Jochen Heuer]

Hi Steve,

/lib is taking lots of space. Have a look at /lib/modules. Check for how many kernels there are modules available? Are they all required?

Regards,

Jochen

[Steven E. Protter]

So many great suggestions. I will cut and paste and run a few commands and see if I can find the fat.

I'm never comfortable running a root fs over 50%. Since this one is a 512 MB fs, that should be a reasonable goal.

Thanks and keep them coming, the best is going into a script for future use ad posting to thos forum.

Steve

[Steven E. Protter]

Stuart, your command is the winner.

Its now part of my toolkit.

Steve

Post another reply to pick up the full 10 points.

[Trever Furnish]

Hey, Steve,

The weather here in Indianapolis is clear and cold, with bright sunshine.

;-)