Virtual file or memory?

Hi Experts
I encountered a situation recently. I wanted to discuss here and understand the reason behind this. My scenario is something like this:

yes > temp  &

The above command keeps writing the output to the file temp. And this file keeps growing every second. And in the every passing second, the file system is slowly getting full. Now a user, user1, unknowingly deletes this file temp.

rm temp

Now user2 logs in, and realizes file system is getting full. He searches for all the big files and deletes them, still over a period of time, its getting full because the earlier process is still alive .

I have 2 questions.

  1. The moment i kill the process "yes > temp", my file system size comes back to normal(in my actual case from 100 to 27) which makes me understand the process was writing somewhere. Once it got killed, the space got freed. Where was it writing at since the temp file does not exist?

  2. The user1 having deleted the file temp, is there any way in which I can associate a file to the process now?

Please advice.

Guru.

lsof

lsof will show you.. actually it would be a hidden file after deletion associated with that process.

---------- Post updated at 00:27 ---------- Previous update was at 00:09 ----------

refer Recovering Deleted Files With lsof � ServerWatch.com

Using that technique you will be able to find the file.

The file is not truly deleted until all references to it are closed. Until then, it is kept on disk, generally inaccessible to anything except the programs that still have it open.

You should truncate logfiles instead of deleting them to clear space:

: > logfile

...will reset its size to zero, after which it will slowly fill up again as long as the program feeding it continues to write.

@thegeek
Thanks for the very useful link. I got almost done what I wanted. However, once I got the process to write to a new file temp1, the file is not growing. Its constant with the same size as how it was at the time of restoring even though the process is still writing.

Also, when I go to the appropriate proc directory(/proc/<mypid>/fd/1), it still shows the output descriptor 1 being attached to my original output file temp, and not temp1.

@Corona668
Thanks for your reply . However, on trying your option, the file did get truncated, but it was not growing anymore. It was stagnant at size 0. Perhaps I am doing something wrong.

Guru.

The program you're using won't reseek to the beginning of the file when its logfile is truncated, then. If it doesn't accept SIGHUP to tell it to reopen its logfiles, you may have to restart the process to safely clear its logfile.

You could also redirect its output into split -l 10000 instead of into a file. This will create many seperate files of 10000 lines each which you can delete individually, only the one not finished will still be held open.