Se avvio un processo e poi elimino il file binario di esso, posso comunque recuperarlo da /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
D'altra parte, se creo io stesso un collegamento simbolico, elimino il target e provo a copiare:
cp: cannot stat ‘sleep’: No such file or directory
/proc è un'interfaccia per il kernel. Quindi questo collegamento simbolico punta effettivamente alla copia caricata in memoria, ma con un nome più utile? Come funziona exe il collegamento funziona, esattamente?
Risposta accettata:
/proc/<pid>/exe non segue la normale semantica per i collegamenti simbolici. Tecnicamente questo potrebbe essere considerato una violazione di POSIX, ma /proc dopotutto è un filesystem speciale.
/proc/<pid>/exe sembra essere un collegamento simbolico quando stat esso. Questo è un modo conveniente per il kernel di esportare il percorso che conosce per l'eseguibile del processo. Ma quando apri effettivamente quel "file", non c'è nessuna della normale procedura di lettura di quanto segue il contenuto di un collegamento simbolico. Invece il kernel ti dà semplicemente accesso direttamente alla voce del file aperto.
Nota che quando ls -l un /proc/<pid>/exe pseudofile per un processo il cui eseguibile è stato cancellato la destinazione del collegamento simbolico ha la stringa "(cancellato)" alla fine di esso. Questo normalmente non avrebbe senso in un collegamento simbolico:non esiste sicuramente un file che risiede nel percorso di destinazione con un nome che termina con "(cancellato)".
tl;dr Il proc l'implementazione del filesystem fa semplicemente la sua cosa magica con la risoluzione del percorso.