ls

The entertaining part comes into play when you realize that an open file has its ref count moved up. This prevents you from removing a file out from beneath some poor, hapless program.

So, you've got a machine with no space in /var and you find to your horror that your cron logs are vast.

So you remove that log file.

The disk space stays the same.

The file is still there on the disk, and will remain there until its reference count goes to zero. Only the name is missing. You'll have to restart cron at this point, to get it to close the log.

The correct way to deal with huge files when shutting off the service to clean the log file is not an option is to cat /dev/null into them, which obliterates the contents: cat /dev/null > huge_file . This may also render it unparsable to log parsing tools if an incomplete log line ends up at the head of the file, so make sure it's genuinely not possible to shut down the service for the 30 seconds or so it would take to clean the log file normally

(Some admins object to using this trick since the resulting log file can get corrupted. YMMV - your mileage may vary).

One side benefit of this behavior comes into play for certain security situations. You can open a temporary file and unlink it before shoving data into it. So long as you never close it you can continue to use that file with no one knowing it exists. Well, except lsof .

Originally submitted by Ben Woodard on 21dec99.