¿En qué se diferencia el enlace simbólico / proc / <pid> / exe de los enlaces simbólicos normales?

23

Si inicio un proceso y luego elimino el binario del mismo, aún puedo recuperarlo 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

Por otro lado, si yo mismo hago un enlace simbólico, elimino el objetivo e intento copiar:

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

/proces una interfaz para el kernel. Entonces, ¿este enlace simbólico realmente apunta a la copia cargada en la memoria, pero con un nombre más útil? ¿Cómo exefunciona exactamente el enlace?

linux symlink proc

— muru
fuente

19

/proc/<pid>/exeno sigue la semántica normal para enlaces simbólicos. Técnicamente esto podría contar como una violación de POSIX, pero /proces un sistema de archivos especial después de todo.

/proc/<pid>/exeparece ser un enlace simbólico cuando lo haces stat. Esta es una forma conveniente para que el núcleo exporte el nombre de ruta que conoce para el ejecutable del proceso. Pero cuando realmente abre ese "archivo", no hay ninguno de los procedimientos normales para leer el siguiente contenido de un enlace simbólico. En cambio, el núcleo simplemente le da acceso a la entrada de archivo abierta directamente.

Tenga en cuenta que cuando utiliza ls -lun /proc/<pid>/exepseudofile para un proceso cuyo ejecutable se ha eliminado, el destino del enlace simbólico tiene la cadena "(eliminado)" al final. Esto normalmente no sería sensato en un enlace simbólico: definitivamente no hay un archivo que viva en la ruta de destino con un nombre que termine con "(eliminado)".

tl; dr La procimplementación del sistema de archivos solo hace su propia cosa mágica con la resolución del nombre de ruta.

— Celada
fuente

1

Y la magia vive en proc_exe_link()el procsistema de archivos: lxr.free-electrons.com/source/fs/proc/base.c?v=4.0#L1350

— Stephen Kitt

¿Cómo sabes que definitivamente no hay un archivo con ese nombre? Alguien podría haber creado uno como un experimento; Lo he hecho una vez antes. No es muy probable que exista por alguna otra razón, pero aún así no es imposible.

— flarn2006

4

Según la página de manual de / proc, en Linux 2.2 y posterior, el archivo es un enlace simbólico que contiene el nombre de ruta real del comando ejecutado. Aparentemente, el binario se carga en la memoria y /proc/[pid]/exeapunta al contenido del binario en la memoria .

Por otro lado, bajo Linux 2.0 y versiones anteriores, /proc/[pid]/exeaparentemente es un puntero al archivo (en el sistema de archivos) que se ejecutó.

Entonces, si ejecutó la misma lista de comandos en Linux 2.0 o anterior, presumiblemente obtendría un error "no existe tal archivo o directorio".

— dr01
fuente

¿Qué página de manual? linux.die.net/man/5/proc y manpages.ubuntu.com/manpages/utopic/en/man5/proc.5.html dicen "intentar abrirlo abrirá el ejecutable", pero no dice dónde viene de.

— muru

1

Estoy bastante seguro de que el kernel le brinda el contenido de los inodes para el binario, en lugar de su copia en memoria. Es improbable que la copia en memoria contenga todas las secciones del archivo. Los inodos, por otro lado, se cuentan por referencia y no se sobrescribirán mientras existan referencias. El núcleo mantendrá una referencia a la ejecución de archivos para que pueda cargar secciones adicionales si es necesario.

— Mark