Root Filesystem growing ...

[cycleroadie]

I have a system where my root (/) filesystem is using up disk, but I don't see any large files growing in / ?? I use ls- la and nothing out of the ordinary. The largest file I see is the sulog at 238K and virtually everything is a directory out of that Filesystem as you would expect, very few files. . But the filesystem is 90% full with it set at 768 Mb. Can anyone help me out as to where this space is being used and how to retrieve it or stop it from being chewed up ?? I don't have unlimited disks available so I have to stop the bleeding.

Thanks !!

Lloyd Campbell

 

[columb]

The key to this is the -mount flag in the find command

Try

find / -mount -type f -size +10000 -mtime -1

This will identify files that are (a)in the / file system (-mount), (b)actual files (-type f), (c)reasonably big (-size +10000) and (d)modified in the last 24 hrs (-mtime -1)

That should give some clues

On the internet no one knows you're a dog

Columb Healy

 

[KenCunningham]

Try a find / -size +10000 in the first instance, to give you an idea of any other files which have grown or are growing. My money's on something under /var!

I want to be good, is that not enough?

 

[KenCunningham]

Ah Columb. Great minds think (almost) alike!

I want to be good, is that not enough?

 

[cycleroadie]

Ok, how could something under /var (or any other different filesystem for that matter) affect the / filesystem when they are seperate mount points ?? I am now confused !!

 

[KenCunningham]

Sorry for the confusion - I had assumed that /var might be part of the / filesystem, as it is sometimes. If that's not the case, something else must be causing the problem.

I want to be good, is that not enough?

 

[columb]

Somethign in /var wont affect the / filesytem is they are separate (they are on my AIX 5.1 systems).

Important The AIX uses -xdev, not -mount (which is the linux version).

The root mailbox could be significant


On the internet no one knows you're a dog

Columb Healy

 

[cycleroadie]

OK, while I have you guys scratching your heads, let me ask this, on (a different) box, with another fielsystem issue, that I think I have IDentified... I have the following files ....

-rw-r--r-- 1 root system 3932160 Oct 21 2003 dat-4298.tar
-rw-r--r-- 1 root system 3962880 Oct 22 2003 dat-4299.tar
-rw-r--r-- 1 root system 4433920 Jun 14 2004 dat-4366.tar
-rw-r--r-- 1 root system 4454400 Jun 22 2004 dat-4367.tar
-rw-r--r-- 1 root system 4474880 Jun 29 2004 dat-4370.tar

IF I do a rm dat-4298.tar logged in as root I get "rm: dat-4298.tar: A file or directory in the path name does not exist."

What the ????

Thanks !!!

 

[cycleroadie]

On my original issue, I might have the cluprit, can I just zero out the failedlogin file without any issues ??

 

[KenCunningham]

Maybe the files have some sort of rogue character at the beginning or the end. Have you tried rm -i *dat-4298.tar*?

Be careful that your asterisks aren't separated from the filename!


I want to be good, is that not enough?

 

[KenCunningham]

If you don't use the failedlogin file I guess so. However, maybe better practice (audit-wise) to copy it to tape or a filesystem with more space? Do you know why the failedlogins file has grown - some sort of attack?

I want to be good, is that not enough?

 

[cycleroadie]

Thanks Ken, the wild cards do seem to work, I have a script that should be cleaning them up but with this crazy character, it is failing. Not sure on the failedlogin file, I think once I clear it maybe I can see a pattern, it's an internal box behind a firewall, so unless soemone inside the company is pounding it, not sure why all these entries....

 

[p5wizard]

Uh guys, on AIX, shouldn't that be

[tt]find / [red]-xdev[/red] -type f -size +10000 -mtime -1[/tt]



HTH,

p5wizard

 

[KenCunningham]

P5, you're correct, but Columb made that clear earlier in the thread.

I want to be good, is that not enough?

 

[MoreFeo]

We once had a similar problem (/ filesystem growing but with no big files). It was that a process opened a file, started writing to it, and then this file got deleted.
When this happens the process continues to write to disk making the filesystem grow, but the file no longer appears.

With "fuser -dV" it lists all the processes writing to a file that no longer exists. Killing/restarting these processes should free the space assigned to the no-more-existant file.

 

[spamly]

The last couple of times that I filled up / was because I turned on auditing or was dumping to a tape "device" that didn't actually exist.