Re: disk full (error log loop) SOLVED
kmself@ix.netcom.com wrote:
>
> On Wed, Apr 26, 2000 at 11:12:18PM -0500, w trillich wrote:
> > okay. it's my fault. i let the log file get huge--but deleting
> > it doesn't recover the space on the partition!
>
> Common mistake.
>
> A file under Linux and Linux-like operating systems isn't deleted until
> all filehandles to it are closed (I think). Deleting a large file to
> free space is often the wrong thin to do. You've removed your ability
> to access and modify the data, but you haven't done anything to the data
> itself.
i'd already checked the data* and just wanted it gone...
> Better solution:
>
> - "empty" the file: cat /dev/null > really-big-file
>
> - Find out who/what is using it: fuser really-big-file
aha! cool!
> - Kill that process -- fuser offers this through "-k"
>
> - If the process is a system log, restart it.
>
> Better, use a facility like logrotate to handle this process for you.
>
> Usually you can zero out a file without going through the kill stages --
> most logs fill relatively slowly.
well the problem here was some infinte apache loop ( x2 !) and
it filled up in a few minutes...
> fuser -mv /mount/point
>
> ...will show all open process (and files) on a mount point.
now THAT's handy. (where's my pen?) ....!
> You can also go through the /proc filesystem process list and look for
> open filehandles with odd characteristics. I forget what a deleted file
> looks like, but it ain't normal <g>
>
> ls -l /proc/[0-9]*/fd/*
*so, any guess which process had the file open?
yup, it was me:
grep -v undefined < /var/log/apache/error.log | more &
(i did the background& after trying it in the foreground and
seeing how long it was taking... but then forgot all about
the background one i'd started. <blush>heh, heh</blush>.)
Reply to: