Inwiefern unterscheidet sich der Symlink / proc / <pid> / exe von normalen Symlinks?

23

Wenn ich einen Prozess starte und dann dessen Binärdatei lösche, kann ich ihn trotzdem wiederherstellen von /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

Wenn ich andererseits selbst einen symbolischen Link erstelle, lösche ich das Ziel und versuche zu kopieren:

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

/procist eine Schnittstelle zum Kernel. Verweist dieser symbolische Link also tatsächlich auf die im Speicher geladene Kopie, jedoch mit einem nützlicheren Namen? Wie funktioniert der exeLink genau?

linux symlink proc

— muru
quelle

19

/proc/<pid>/exefolgt nicht der normalen Semantik für symbolische Links. Technisch mag dies als Verletzung von POSIX gelten, ist aber /procimmerhin ein spezielles Dateisystem.

/proc/<pid>/exescheint ein Symlink zu sein, wenn Sie states. Dies ist eine bequeme Möglichkeit für den Kernel, den Pfadnamen zu exportieren, den er für die ausführbare Datei des Prozesses kennt. Aber wenn Sie diese "Datei" tatsächlich öffnen, gibt es keine normale Prozedur zum Lesen des folgenden Inhalts eines Symlinks. Stattdessen können Sie über den Kernel direkt auf den geöffneten Dateieintrag zugreifen.

Beachten Sie, dass beim Erstellen ls -leiner /proc/<pid>/exePseudodatei für einen Prozess, dessen ausführbare Datei gelöscht wurde, am Ende des Symlink-Ziels die Zeichenfolge "(gelöscht)" steht. Dies ist normalerweise in einem Symlink nicht sinnvoll: Es gibt definitiv keine Datei, die sich im Zielpfad befindet und deren Name mit "(gelöscht)" endet.

tl; dr Die procDateisystemimplementierung macht mit der Pfadnamenauflösung einfach ihre eigene magische Sache.

— Celada
quelle

1

Und die Magie lebt in proc_exe_link()im procDateisystem: lxr.free-electrons.com/source/fs/proc/base.c?v=4.0#L1350

— Stephen Kitt

Woher weißt du, dass es definitiv keine Datei mit einem solchen Namen gibt? Jemand könnte eine als Experiment erstellt haben; Ich habe es schon einmal gemacht. Es ist nicht sehr wahrscheinlich, dass es aus einem anderen Grund existiert, aber immer noch nicht unmöglich.

— Flarn2006

4

Laut der Manpage von / proc ist die Datei unter Linux 2.2 und höher eine symbolische Verknüpfung, die den tatsächlichen Pfadnamen des ausgeführten Befehls enthält. Anscheinend wird die Binärdatei in den Speicher geladen und /proc/[pid]/exezeigt auf den Inhalt der Binärdatei im Speicher .

Andererseits ist unter Linux 2.0 und früher /proc/[pid]/exeanscheinend ein Zeiger auf die Datei (im Dateisystem), die ausgeführt wurde.

Wenn Sie also dieselbe Befehlsliste unter Linux 2.0 oder früher ausführen, erhalten Sie vermutlich die Fehlermeldung "Keine solche Datei oder solches Verzeichnis".

— dr01
quelle

Welche Manpage? linux.die.net/man/5/proc und manpages.ubuntu.com/manpages/utopic/en/man5/proc.5.html sagen wir „versuchen , es zu öffnen , wird die ausführbare Datei öffnen“, aber nicht sagen , wo es kommt von.

— muru

1

Ich bin mir ziemlich sicher, dass der Kernel Ihnen den Inhalt der Inodes für die Binärdatei und nicht die In-Memory-Kopie liefert . Es ist unwahrscheinlich, dass die speicherinterne Kopie alle Abschnitte der Datei enthält. Die Inodes hingegen werden mit Verweisen gezählt und nicht überschrieben, solange Verweise vorhanden sind. Der Kernel behält einen Verweis auf die Ausführung von Dateien bei, damit er bei Bedarf zusätzliche Abschnitte laden kann.

— Markieren Sie