If I start a process and then delete the binary of it, I can still recover it from /proc/<pid>/exe
:
$ cp `which sleep` .
$ ./sleep 10m &
[1] 13728
$ rm sleep
$ readlink /proc/13728/exe
/tmp/sleep (deleted)
$ cp /proc/13728/exe ./sleep-copy
$ diff sleep-copy `which sleep` && echo not different
not different
$ stat /proc/13728/exe
File: ‘/proc/13728/exe’ -> ‘/tmp/sleep (deleted)’
Size: 0 Blocks: 0 IO Block: 1024 symbolic link
On the other hand, if I make a symbolic link myself, delete the target and attempt to copy:
cp: cannot stat ‘sleep’: No such file or directory
/proc
is an interface to the kernel. So does this symbolic link actually point to the copy loaded in memory, but with a more useful name? How does the exe
link work, exactly?
Best Answer
/proc/<pid>/exe
does not follow the normal semantics for symbolic links. Technically this might count as a violation of POSIX, but/proc
is a special filesystem after all./proc/<pid>/exe
appears to be a symlink when youstat
it. This is a convenient way for the kernel to export the pathname it knows for the process' executable. But when you actually open that "file", there is none of the normal procedure of reading the following the contents of a symlink. Instead the kernel just gives you access to the open file entry directly.Notice that when you
ls -l
a/proc/<pid>/exe
pseudofile for a process whose executable has been deleted the symlink target has the string " (deleted)" at the end of it. This would normally be non-sensical in a symlink: there definitely isn't a file that lives at the target path with a name that ends with " (deleted)".tl;dr The
proc
filesystem implementation just does its own magic thing with pathname resolution.