Linux – How does the /proc//exe symlink differ from ordinary symlinks

linuxprocsymlink

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 you stat 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.

Related Question