[ale] weird behavior

[Bob Toxen]

> From: Mir Shafiqul Islam <mir at oisp.gsu.edu>
> Subject: Re: [ale] weird behavior
> To: terry at esc1.com (Terry Lee Tucker)
> Date: Mon, 13 Apr 1998 12:47:32 -0400 (EDT)
> Cc: ale at cc.gatech.edu (ale)

> I thought about the log files, but all log files are fine and the main log
> file is apache log files, those are on separate file system and not on the
> root system.

> Plus, how would you explain that all the space coming back after rebooting
> ? If it was log files, it would still occupy the space. Wouldn't it ?

> Thanks.

> Mir
>  > 
> > You must have some process that is dumping hugh amount of data to a log
> > file. Try using find with the -size option to get a listing of the very
> > large files on your system.  That will narrow down the search quite a
> > bit.
> > Here's the command on my RedHat 4.2 system:
> > 
> > [root at Gateway /] # find / -size +2000000c
> > 
> > This will give a list of all files that are over 2 megs and over.  The
> > "c" means bytes.  Also, I have seen something like this on SCO systems. 
> > The culprit was mail bouncing messages in a loop and generating tons of
> > errors to a mail log.  I think Linux is probably smarter than that
> > though :^)
> > 
> > Later...
> > The Gates of hell shall NOT prevail...

> -- 
> Mir S Islam

One possibility is that a program uses creat() to create a file and repeatedly
write to the end of it, thus growing it.  If either that process or another
process does a "rm" or "unlink()" on it then the file will vanish from the
directory structure but it still will exist.

Thus it will continue to grow but you cannot find it.  This "unnamed" file
will continue to exist so long as at least one program has it open (which
stops upon reboot).

The only easy to find this problem is to use "top" or "ps" repeatedly to find
processes that are using lots of CPU.  Kill these processes, on at a time,
until free space jumps.  Then you can do a "strings" command on the program
and try to guess the file (or fix the program).

Please let me know if this helps.

Bob Toxen
bob at cavu.com
http://www.cavu.com
http://www.cavu.com/sunset.html   [Sunset Computer]
Fly-By-Day Consulting, Inc.
N79879 C-172 based PDK, Atlanta, GA
Hiroshima '45           Chernobyl '86           Windows '95
"Venimus, Vidimus, Dolavimus" (We came, we saw, we hacked)