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>.)
