Si inicio un proceso y luego elimino el binario, todavía puedo recuperarlo desde /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
Por otro lado, si yo mismo hago un enlace simbólico, elimino el destino e intento copiar:
cp: cannot stat ‘sleep’: No such file or directory
/proc es una interfaz para el núcleo. Entonces, ¿este enlace simbólico realmente apunta a la copia cargada en la memoria, pero con un nombre más útil? ¿Cómo funciona el exe enlace funciona, exactamente?
Respuesta aceptada:
/proc/<pid>/exe no sigue la semántica normal de los enlaces simbólicos. Técnicamente, esto podría contar como una violación de POSIX, pero /proc es un sistema de archivos especial después de todo.
/proc/<pid>/exe parece ser un enlace simbólico cuando stat eso. Esta es una forma conveniente para que el kernel exporte el nombre de ruta que conoce para el ejecutable del proceso. Pero cuando realmente abre ese "archivo", no existe el procedimiento normal de leer el siguiente contenido de un enlace simbólico. En su lugar, el kernel solo le da acceso a la entrada del archivo abierto directamente.
Tenga en cuenta que cuando ls -l un /proc/<pid>/exe pseudoarchivo para un proceso cuyo ejecutable ha sido eliminado, el destino del enlace simbólico tiene la cadena "(eliminado)" al final. Esto normalmente no tendría sentido en un enlace simbólico:definitivamente no hay un archivo que viva en la ruta de destino con un nombre que termine con "(eliminado)".
tl;dr El proc La implementación del sistema de archivos simplemente hace su propia magia con la resolución de nombres de ruta.