In che modo il symlink / proc / <pid> / exe differisce dai normali symlink?

23

Se avvio un processo e quindi elimino il file binario, posso ancora 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 un collegamento simbolico da solo, elimino il target e provo a copiare:

cp: cannot stat ‘sleep’: No such file or directory

/procè un'interfaccia per il kernel. Quindi questo link simbolico in realtà punta alla copia caricata in memoria, ma con un nome più utile? Come exefunziona esattamente il collegamento?

linux symlink proc

— Muru
fonte

19

/proc/<pid>/exenon segue la semantica normale per i collegamenti simbolici. Tecnicamente questo potrebbe essere considerato una violazione di POSIX, ma /procdopo tutto è un file system speciale.

/proc/<pid>/exesembra essere un link simbolico quando lo fai stat. Questo è un modo conveniente per il kernel di esportare il percorso che conosce per l'eseguibile del processo. Ma quando si apre effettivamente quel "file", non c'è nessuna delle normali procedure per leggere quanto segue il contenuto di un collegamento simbolico. Invece il kernel ti dà solo accesso direttamente alla voce del file aperto.

Si noti che quando si utilizza ls -luno /proc/<pid>/exepseudofile per un processo il cui eseguibile è stato eliminato, il target del collegamento simbolico ha la stringa "(cancellata)" alla fine di esso. Normalmente ciò non sarebbe sensato in un collegamento simbolico: sicuramente non esiste un file che si trova sul percorso di destinazione con un nome che termina con "(eliminato)".

tl; dr L' procimplementazione del filesystem fa proprio la sua cosa magica con la risoluzione del percorso.

— Celada
fonte

1

E la magia vive proc_exe_link()nel procfile system: lxr.free-electrons.com/source/fs/proc/base.c?v=4.0#L1350

— Stephen Kitt

Come fai a sapere che sicuramente non esiste un file con un nome simile? Qualcuno potrebbe averne creato uno come esperimento; L'ho già fatto una volta. Non molto probabilmente esisterebbe per qualsiasi altra ragione, ma ancora non impossibile.

— flarn2006,

4

Secondo la pagina man di / proc, in Linux 2.2 e versioni successive, il file è un collegamento simbolico contenente il percorso effettivo del comando eseguito. Apparentemente, il binario viene caricato in memoria e /proc/[pid]/exepunta al contenuto del binario in memoria .

D'altra parte, sotto Linux 2.0 e precedenti, /proc/[pid]/exeapparentemente è un puntatore al file (nel filesystem) che è stato eseguito.

Quindi, se avessi eseguito lo stesso elenco di comandi su Linux 2.0 o precedenti, presumibilmente otterrai un errore "nessun file o directory".

— DR01
fonte

Quale manpage? linux.die.net/man/5/proc e manpages.ubuntu.com/manpages/utopic/en/man5/proc.5.html diciamo "il tentativo di aprire si aprirà l'eseguibile", ma non dice dove viene da.

— muru,

1

Sono abbastanza sicuro che il kernel ti dia il contenuto degli inode per il binario, piuttosto che la sua copia in memoria. È improbabile che la copia in memoria contenga tutte le sezioni del file. Gli inode, d'altro canto, vengono contati come riferimento e non verranno sovrascritti mentre esistono riferimenti. Il kernel manterrà un riferimento all'esecuzione dei file in modo da poter caricare sezioni aggiuntive se necessario.

— Segna