Como o symlink / proc / pid / exe difere dos links simbólicos comuns?

Question

Se eu iniciar um processo e, em seguida, excluir o binário dele, ainda posso recuperá-lo 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 outro lado, se eu fizer um link simbólico, exclua o alvo e tente copiar:

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

/proc é uma interface para o kernel. Então este link simbólico realmente aponta para a cópia carregada na memória, mas com um nome mais útil? Como funciona o link exe , exatamente?

    

Answer 1

/proc/<pid>/exe não segue a semântica normal para links simbólicos. Tecnicamente, isso pode ser considerado uma violação do POSIX, mas /proc é um sistema de arquivos especial, afinal.

/proc/<pid>/exe parece ser um symlink quando você usa stat . Esta é uma maneira conveniente para o kernel exportar o nome do caminho que ele conhece para o executável do processo. Mas quando você realmente abre esse "arquivo", não há nenhum procedimento normal de ler o seguinte o conteúdo de um link simbólico. Em vez disso, o kernel apenas fornece acesso à entrada de arquivos abertos diretamente.

Observe que quando você ls -l a /proc/<pid>/exe pseudofile para um processo cujo executável foi excluído, o destino do symlink tem a string "(deleted)" no final dele. Isso normalmente não seria sensitivo em um symlink: definitivamente não existe um arquivo que mora no caminho de destino com um nome que termina com "(deleted)".

tl; dr A implementação do sistema de arquivos proc apenas faz sua própria mágica com a resolução do nome do caminho.

    

Answer 2

De acordo com a página man do / proc, no Linux 2.2 e posterior, o arquivo é um link simbólico contendo o nome do caminho real do comando executado. Aparentemente, o binário é carregado na memória e /proc/[pid]/exe aponta para o conteúdo do binário na memória .

Por outro lado, no Linux 2.0 e versões anteriores, /proc/[pid]/exe aparentemente é um ponteiro para o arquivo (no sistema de arquivos) que foi executado.

Portanto, se você executou a mesma lista de comandos no Linux 2.0 ou anterior, presumivelmente você obteria um erro "nenhum arquivo ou diretório".