Wenn ich einen Prozess starte und dann die Binärdatei davon lösche, kann ich ihn immer noch von /proc/<pid>/exe wiederherstellen :
$ 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
Wenn ich andererseits selbst einen symbolischen Link erstelle, lösche das Ziel und versuche zu kopieren:
cp: cannot stat ‘sleep’: No such file or directory
/proc ist eine Schnittstelle zum Kernel. Zeigt dieser symbolische Link also tatsächlich auf die im Speicher geladene Kopie, aber mit einem nützlicheren Namen? Wie funktioniert die exe Link funktioniert, genau?
Akzeptierte Antwort:
/proc/<pid>/exe folgt nicht der normalen Semantik für symbolische Links. Technisch könnte dies als Verletzung von POSIX gelten, aber /proc ist immerhin ein spezielles Dateisystem.
/proc/<pid>/exe scheint ein symbolischer Link zu sein, wenn Sie stat eingeben es. Dies ist eine praktische Möglichkeit für den Kernel, den ihm bekannten Pfadnamen für die ausführbare Datei des Prozesses zu exportieren. Aber wenn Sie diese „Datei“ tatsächlich öffnen, gibt es keine der normalen Prozeduren zum Lesen des folgenden Inhalts eines Symlinks. Stattdessen gewährt Ihnen der Kernel nur direkten Zugriff auf den geöffneten Dateieintrag.
Beachten Sie das, wenn Sie ls -l a /proc/<pid>/exe Pseudodatei für einen Prozess, dessen ausführbare Datei gelöscht wurde, hat das Symlink-Ziel die Zeichenfolge „(gelöscht)“ am Ende. Dies wäre normalerweise in einem Symlink unsinnig:Es gibt definitiv keine Datei, die im Zielpfad lebt und deren Name auf „(gelöscht)“ endet.
tl;dr Der proc Die Dateisystemimplementierung macht mit der Auflösung von Pfadnamen einfach ihre eigene magische Sache.