rm not freeing diskspace [closed]

Solution 1:

Restart tomcat, if the file is in use and you remove it, the space becomes available when that process finishes.

Solution 2:

As others suggested, the file probably is still opened by other processes. To find out by which ones, you can do

lsof /opt/tomcat/logs/catalina.out

which lists you the processes. Probably you will find tomcat in that list.

Solution 3:

Your Problem:

Its possible that a running program is still holding on to the file.

Your Solution:

Per the other answers here, you can simply shutdown tomcat to stop it from holding on to the file.

If that is not an option, or if you simply want more details, check out this question: Find and remove large files that are open but have been deleted - it suggests some harsher ways to deal with it that may be more useful to your situation.

More Details:

The linux/unix filesystem considers "opened" files to be another name for them. rm removes the "name" from the file as seen in the directory tree. Until the handles are closed, the files still has more "names" and so the file still exists. The file system doesn't reap files until they are completely unnamed.

It might seem a little odd, but doing it this way allows for useful things like enabling symlinks. Symlinks can essentially be treated as an alternate name for the same file.

This is why it is important to always call your languages equivalent to close() on a file handle if you are done with it. This notifies the OS that the file is no longer being used. Although sometimes this cant be helped - which is likely the case with Tomcat. Refer to Bill Karwin's Answer to read why.

Depending on the file-system, this is usually implemented as a sort of reference count, so there may not be any real names involved. It can also get weird if things like stdin and stderr are redirected to a file or another bytestream (most commonly done with services).

This whole idea is closely related to the concept of 'inodes', so if you are the curious type, i'd recommend checking that out first.

Discussion

It doesn't work so well anymore, but you used to be able to update the entire OS, start up a new http-daemon using the new libraries, and finally close the old one when no more clients are being serviced with it (releasing the old handles) . http clients wouldn't even miss a beat.

Basicly, you can completely wipe out the kernel and all the libraries "from underneath" running programs. But since the "name" still exists for the older copies, the file still exists in memory/disk for that particular program. Then it would be a matter of restarting all the services etc. While this is an advanced usage scenario, it is a reason why some unix system have years of up-time on record.