executable ELF is rm-ed from disk, but still running RAM..
Hi all.. As the subject says, I was thinking about that issue. I know that rm-ing a file doesn't delete the data block from the backing device, thus the executable could still survive and running. But logically, we usually expect that once a file is rm-ed, it should also "stop", right? What does POSIX say about this case anyway? Anyone could kindly give his/her opinion? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
On Mon, May 30, 2011 at 09:49:29PM +0700, Mulyadi Santosa wrote:
Hi all..
As the subject says, I was thinking about that issue.
I know that rm-ing a file doesn't delete the data block from the backing device, thus the executable could still survive and running.
But logically, we usually expect that once a file is rm-ed, it should also "stop", right? What does POSIX say about this case anyway? Anyone could kindly give his/her opinion?
I think the point is that the file is still "open", i.e. mapped into the the processes virtual memory, and thus the inode whose seemingly last reference you've just removed is still referenced. I'm guessing that from unlink(2): "If the name was the last link to a file but any processes still have the file open the file will remain in existence until the last file descriptor referring to it is closed." A mapping is not a file desciptor but I believe that it behaves similiarly. But I'm not sure. Thanks, Jonathan Neuschäfer
2011/5/30 Mulyadi Santosa <mulyadi.santosa@gmail.com>:
Hi all..
As the subject says, I was thinking about that issue.
I know that rm-ing a file doesn't delete the data block from the backing device, thus the executable could still survive and running.
But logically, we usually expect that once a file is rm-ed, it should also "stop", right? What does POSIX say about this case anyway? Anyone could kindly give his/her opinion? In my view, i don't expect that rm one file should also stop the related process. If that, in one system, do the thing "rm sysfile" will stop OS running? In my logic, i just think run the executable is the user's choice before "rm it", if the user want to delete file, also who want to stop the process related this file should kill the process themselves. I consider that if the users delete one file uncarefully, should give the chance to recover it and not block current running task.
-- regards,
Mulyadi Santosa Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Best Regards Lin
Hi all.. On Tue, May 31, 2011 at 08:25, Pei Lin <telent997@gmail.com> wrote:
2011/5/30 Mulyadi Santosa <mulyadi.santosa@gmail.com>:
Hi all..
As the subject says, I was thinking about that issue.
I know that rm-ing a file doesn't delete the data block from the backing device, thus the executable could still survive and running.
But logically, we usually expect that once a file is rm-ed, it should also "stop", right? What does POSIX say about this case anyway? Anyone could kindly give his/her opinion? In my view, i don't expect that rm one file should also stop the related process. If that, in one system, do the thing "rm sysfile" will stop OS running? In my logic, i just think run the executable is the user's choice before "rm it", if the user want to delete file, also who want to stop the process related this file should kill the process themselves. I consider that if the users delete one file uncarefully, should give the chance to recover it and not block current running task.
Thanks for sharing your thoughts so far. This came to my mind when I did a project about 2 years ago. At that time, I also came to very much same conclusion: if you want to make sure new binary is executed, sigkill/sigterm the old ones first, remove them and run the new one. Seems trivial, but initially this tiny little detail missed from my mind. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
On Mon, May 30, 2011 at 7:46 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
Hi all..
On Tue, May 31, 2011 at 08:25, Pei Lin <telent997@gmail.com> wrote:
2011/5/30 Mulyadi Santosa <mulyadi.santosa@gmail.com>:
Hi all..
As the subject says, I was thinking about that issue.
I know that rm-ing a file doesn't delete the data block from the backing device, thus the executable could still survive and running.
But logically, we usually expect that once a file is rm-ed, it should also "stop", right? What does POSIX say about this case anyway? Anyone could kindly give his/her opinion? In my view, i don't expect that rm one file should also stop the related process. If that, in one system, do the thing "rm sysfile" will stop OS running? In my logic, i just think run the executable is the user's choice before "rm it", if the user want to delete file, also who want to stop the process related this file should kill the process themselves. I consider that if the users delete one file uncarefully, should give the chance to recover it and not block current running task.
Thanks for sharing your thoughts so far. This came to my mind when I did a project about 2 years ago. At that time, I also came to very much same conclusion: if you want to make sure new binary is executed, sigkill/sigterm the old ones first, remove them and run the new one. Seems trivial, but initially this tiny little detail missed from my mind.
How will "rm /bin/rm" work otherwise ? -- Thanks - Manish
hi.. On Tue, May 31, 2011 at 09:57, Manish Katiyar <mkatiyar@gmail.com> wrote:
How will "rm /bin/rm" work otherwise ?
ok, makes me think another case....suppose we erase the related data blocks in the disk that correlate to running binary.... does Linux kernel follow that with erasing all the related page cache? or is it possible that temporarily cache of the disk blocks still survived? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
On Mon, May 30, 2011 at 8:45 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
hi..
On Tue, May 31, 2011 at 09:57, Manish Katiyar <mkatiyar@gmail.com> wrote:
How will "rm /bin/rm" work otherwise ?
ok, makes me think another case....suppose we erase the related data blocks in the disk that correlate to running binary.... does Linux kernel follow that with erasing all the related page cache? or is it possible that temporarily cache of the disk blocks still survived?
I don't know for sure, but my guess is that the OS wouldn't notice it till it goes out of cache and it has to reload. -- Thanks - Manish
AFAIK Linux removes the directory entry and reduces the reference count of Inode of a running process and rm is successful. So, you can't see it in the file system anymore. However as the program is still running the inode reference count is still not zero and so the Inode and hence file is actually not deleted yet. When the program will terminate, Inode ref count will drop to zero and in that case the Inode and file will be freed. "The design of Unix Operating System" by Maurice J. Bach It covers these basic design principles in good detail. On Tue, May 31, 2011 at 10:12 AM, Manish Katiyar <mkatiyar@gmail.com> wrote:
On Mon, May 30, 2011 at 8:45 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
hi..
On Tue, May 31, 2011 at 09:57, Manish Katiyar <mkatiyar@gmail.com> wrote:
How will "rm /bin/rm" work otherwise ?
ok, makes me think another case....suppose we erase the related data blocks in the disk that correlate to running binary.... does Linux kernel follow that with erasing all the related page cache? or is it possible that temporarily cache of the disk blocks still survived?
I don't know for sure, but my guess is that the OS wouldn't notice it till it goes out of cache and it has to reload.
-- Thanks - Manish
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, May 31, 2011 at 11:56, Vikash Kumar <vikashskumar@gmail.com> wrote:
AFAIK Linux removes the directory entry and reduces the reference count of Inode of a running process and rm is successful. So, you can't see it in the file system anymore. However as the program is still running the inode reference count is still not zero and so the Inode and hence file is actually not deleted yet. When the program will terminate, Inode ref count will drop to zero and in that case the Inode and file will be freed. "The design of Unix Operating System" by Maurice J. Bach It covers these basic design principles in good detail.
Thanks people...you put valuable feedback to me. It's good to see I am around knowledgeable people :) As for the deletion case, I might do further research to see how the very recent Linux kernel behaves. Hopefully, if the time permits... -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
participants (5)
-
Jonathan Neuschäfer -
Manish Katiyar -
Mulyadi Santosa -
Pei Lin -
Vikash Kumar