It highly depends on what you're doing.
There's a list of open file descriptors for a process located in /proc/<PID>/fd
. "ls -l
" will tell you more information about the file descriptor (e.g. which file descriptor is linked to the deleted file). You could then truncate that file to clear the file and free up some space. For example, let's say your application only has one file open (other than the default stdin, stderr, and stdout). Normally your deleted open file would be open with file descriptor 3. So you would truncate that file (pretend your PID is 12345)
echo -n '' > ./3
Remember, before truncating any file descriptor associated with a process be sure that you're operating on the right one with "ls -l
As far as I know there's no good way to reestablish the hard link of the deleted file. If you need to recover the data from the deleted log you could tail -f the file descriptor
tail -c +0 -f /proc/12345/fd/3 > /path/filename
It will also get all subsequent writes to that file since the -f option is set for tail.
There is a github project which attempts to resolve the "restore a deleted hard link" problem called fdlink
however I have not used that kernel module myself. I'd just recommend using the tail -f command and clearing the file descriptor every once in a while (because the file descriptor and the file will essentially be doubling the data produced on the HDD).
You can read more about the proc filesystem in the kernel documentation proc.txt
See this behavior in action
You can play with this behavior using a python interactive prompt.
$ mkdir ~/sandbox
$ cd ~/sandbox
In interactive python mode,
f.write("my log test 1\n")
In bash, while python interactive check the contents of the log file.
$ cat test.log
my log test 1
Open the file again in python interactive,
f.write("my log test 2\n")
In bash, delete test.log while python has it open. Check it out to see that it was deleted. Check the python process ID and then visit the open file descriptor (pretend lsof reported a PID of 12345).
$ rm test.log
$ lsof | grep deleted | grep test.log
$ cd /proc/12345/fd
$ ls -l
$ cat 3
my log test 1
$ echo -n '' > ./3
$ cat 3
$ tail -c +0 -f ./3 > ~/sandbox/test.log
Now in the python interactive prompt your last f.write() command hasn't been committed to disk. This will happen when you close the file of which the previous tail command will catch. In python interactive,
You can now stop the tail -f command since the file has been closed for writing. Go ahead and cat your new test.log file. You should see the last written lines.
$ cat ~/sandbox/test.log
my log test 2
Kind of a neat little experiment.