En quoi le lien symbolique / proc / <pid> / exe diffère-t-il des liens symboliques ordinaires?

23

Si je démarre un processus et que j'en supprime le binaire, je peux toujours le récupérer à partir de /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

En revanche, si je crée moi-même un lien symbolique, supprimez la cible et essayez de copier:

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

/procest une interface vers le noyau. Ce lien symbolique pointe-t-il réellement vers la copie chargée en mémoire, mais avec un nom plus utile? Comment exefonctionne exactement le lien?

linux symlink proc

— muru
source

19

/proc/<pid>/exene suit pas la sémantique normale des liens symboliques. Techniquement, cela peut être considéré comme une violation de POSIX, mais /procc'est un système de fichiers spécial après tout.

/proc/<pid>/exesemble être un lien symbolique lorsque vous statle faites . C'est un moyen pratique pour le noyau d'exporter le chemin qu'il connaît pour l'exécutable du processus. Mais lorsque vous ouvrez réellement ce "fichier", il n'y a pas de procédure normale pour lire le contenu d'un lien symbolique suivant. Au lieu de cela, le noyau vous donne directement accès à l'entrée du fichier ouvert.

Notez que lorsque vous créez ls -lun /proc/<pid>/exepseudofichier pour un processus dont l'exécutable a été supprimé, la cible du lien symbolique a la chaîne "(supprimé)" à la fin de celui-ci. Cela ne serait normalement pas sensé dans un lien symbolique: il n'y a certainement pas de fichier vivant sur le chemin cible avec un nom qui se termine par "(supprimé)".

tl; dr L' procimplémentation du système de fichiers fait juste sa propre chose magique avec la résolution du nom de chemin.

— Celada
source

1

Et la magie vit dans proc_exe_link()le procsystème de fichiers: lxr.free-electrons.com/source/fs/proc/base.c?v=4.0#L1350

— Stephen Kitt

Comment savez-vous qu'il n'y a certainement pas de fichier avec un tel nom? Quelqu'un aurait pu en créer un à titre d'expérience; Je l'ai déjà fait une fois. Il est peu probable qu'il existerait pour toute autre raison, mais toujours pas impossible.

— flarn2006

4

Selon la page de manuel de / proc, sous Linux 2.2 et versions ultérieures, le fichier est un lien symbolique contenant le chemin d'accès réel de la commande exécutée. Apparemment, le binaire est chargé en mémoire et /proc/[pid]/exepointe vers le contenu du binaire en mémoire .

D'un autre côté, sous Linux 2.0 et versions antérieures, /proc/[pid]/exeest apparemment un pointeur vers le fichier (dans le système de fichiers) qui a été exécuté.

Donc, si vous exécutez la même liste de commandes sur Linux 2.0 ou une version antérieure, vous obtiendrez probablement une erreur "aucun fichier ou répertoire".

— dr01
source

Quelle page de manuel? linux.die.net/man/5/proc et manpages.ubuntu.com/manpages/utopic/en/man5/proc.5.html disent "tenter de l'ouvrir ouvrira l'exécutable", mais ne dit pas où il vient de.

— muru du

1

Je suis sûr que le noyau vous donne le contenu des inodes pour le binaire, plutôt que sa copie en mémoire. Il est peu probable que la copie en mémoire contienne toutes les sections du fichier. Les inodes, en revanche, sont comptés par référence et ne seront pas écrasés tant qu'il existe des références. Le noyau gardera une référence à l'exécution des fichiers afin de pouvoir charger des sections supplémentaires si nécessaire.

— Mark