Qual processo é '/ proc / self /' para?

Question

link  diz

The /proc/self/ directory is a link to the currently running process.

Há sempre vários processos em execução simultaneamente, de modo que o processo é "o processo atualmente em execução"?

O "processo atualmente em execução" tem algo a ver com qual processo está sendo executado atualmente na CPU, considerando a troca de contexto?

O "processo atualmente em execução" não tem nada a ver com os processos de primeiro e segundo plano?

    

Answer 1

Isso não tem nada a ver com os processos de primeiro e segundo planos; só tem a ver com o processo atualmente em execução. Quando o kernel tem que responder a pergunta "O que é que /proc/self aponta?", Simplesmente escolhe o pid agendado atualmente , ie o processo atualmente em execução (na CPU lógica atual). O efeito é que /proc/self sempre aponta para o pid do programa solicitante; se você correr

ls -l /proc/self

você verá o pid de ls , se você escrever um código que use /proc/self esse código verá seu próprio pid, etc.

    

Answer 2

Aquele que acessa o symlink (chama readlink () ou abre () em um caminho através dele). Ele estaria sendo executado na CPU no momento, mas isso não é relevante. Um sistema multiprocessador pode ter vários processos na CPU simultaneamente.

Os processos de primeiro plano e plano de fundo são principalmente uma construção de shell, e não há nenhum processo exclusivo de primeiro plano, já que todas as sessões de shell no sistema terão uma.

    

Answer 3

O texto poderia ter sido melhor, mas, novamente, qualquer texto que você tente compor para expressar a ideia de auto-referência será confuso. O nome do diretório é mais descritivo na minha opinião.

Basicamente, /proc/self/ representa o processo que está lendo /proc/self/ . Portanto, se você tentar abrir /proc/self/ de um programa em C, ele representará esse programa. Se você tentar fazer isso a partir do shell, então é o shell, etc.

Mas e se você tiver um processador quad core capaz de executar 4 processos simultaneamente, de verdade, não de multitarefa?

Em seguida, cada processo verá um /proc/self/ diferente para o real sem poder ver o /proc/self/ um do outro.

Como isso funciona?

Bem, /proc/self/ não é realmente uma pasta. É um driver de dispositivo que se expõe como uma pasta se você tentar acessá-lo. Isso porque ele implementa a API necessária para pastas. O diretório /proc/self/ não é a única coisa que faz isso. Considere pastas compartilhadas montadas a partir de servidores remotos ou montando miniaturas USB ou dropbox. Todos eles funcionam implementando o mesmo conjunto de APIs que os fazem se comportar como pastas.

Quando um processo tenta acessar /proc/self/ , o driver de dispositivo gera seu conteúdo dinamicamente lendo os dados desse processo. Portanto, os arquivos em /proc/self/ não existem realmente. É como um espelho que reflete sobre o processo que tenta olhar para ele.

É realmente um driver de dispositivo? Você parece estar simplificando demais as coisas!

Sim, é mesmo. Se você quer ser pedante, é um módulo do kernel. Mas se você verificar as postagens da usenet nos vários canais de desenvolvedores Linux, a maioria dos desenvolvedores de kernel usa o "driver de dispositivo" e o "módulo do kernel" de maneira intercambiável. Eu costumava escrever drivers de dispositivo, err ... módulos do kernel, para Linux. Se você quiser escrever sua própria interface em /proc/ , por exemplo, você quer um sistema de arquivos /proc/unix.stackexchange/ que retorne posts deste site, você pode ler sobre como fazê-lo no venerável livro "Linux Device Drivers" publicado pela O ' Reilly. Está disponível como cópia eletrônica on-line.

    

Answer 4

É o processo que está acessando /proc/self ou os arquivos / pastas nele.

Experimente cat /proc/self/cmdline . Você obterá, surpresa surpresa, cat /proc/self/cmdline , (na verdade, em vez de um espaço, haverá um caractere nulo entre o t e o / ) porque será o processo do gato acessar esse pseudofile.

Quando você faz um ls -l /proc/self , você verá o pid do próprio processo ls. Ou que tal ls -l /proc/self/exe ; ele apontará para o executável ls.

Ou tente isso, para variar:

$ cp /proc/self/cmdline /tmp/cmd
$ hexdump -C /tmp/cmd
00000000  63 70 00 2f 70 72 6f 63  2f 73 65 6c 66 2f 63 6d  |cp./proc/self/cm|
00000010  64 6c 69 6e 65 00 2f 74  6d 70 2f 63 6d 64 00     |dline./tmp/cmd.|
0000001f

ou até mesmo

$ hexdump -C /proc/self/cmdline 
00000000  68 65 78 64 75 6d 70 00  2d 43 00 2f 70 72 6f 63  |hexdump.-C./proc|
00000010  2f 73 65 6c 66 2f 63 6d  64 6c 69 6e 65 00        |/self/cmdline.|
0000001e

Como eu disse, é qualquer processo que esteja acessando /proc/self ou os arquivos / pastas nele.

    

Answer 5

/ proc / self é o açúcar sintático. É um atalho para a contatenação / proc / e o resultado do getysc () do syscall (acessível no bash como o metavariable $$). Pode ficar confuso, no caso do shell de script, já que muitas das instruções invocam outros processos, completos com os próprios PIDs ... PIDs que se referem, na maioria das vezes, a processos mortos. Considere:

root@vps01:~# ls -l /proc/self/fd
total 0
lrwx------ 1 root root 64 Jan  1 01:51 0 -> /dev/pts/0
lrwx------ 1 root root 64 Jan  1 01:51 1 -> /dev/pts/0
lrwx------ 1 root root 64 Jan  1 01:51 2 -> /dev/pts/0
lr-x------ 1 root root 64 Jan  1 01:51 3 -> /proc/26562/fd
root@vps01:~# echo $$
593

'/ bin / ls' irá avaliar o caminho para o diretório, resolvendo-o como / proc / 26563, já que esse é o PID do processo - o recém-criado processo / bin / ls - que lê o conteúdo do diretório. Mas no momento em que o próximo processo no pipeline, no caso de scripts de shell, ou no momento em que o prompt volta, no caso de um shell interativo, o caminho não existe mais e as informações saída refere-se a um processo inexistente.

Isso só se aplica a comandos externos, no entanto (aqueles que são arquivos de programas executáveis reais, ao invés de serem embutidos no próprio shell). Assim, você obterá resultados diferentes se, digamos, usar o globbing de nomes de arquivos para obter uma lista do conteúdo do diretório, em vez de passar o nome do caminho para o processo externo / bin / ls:

root@vps01:~# ls /proc/self/fd
0  1  2  3
root@vps01:~/specs# echo /proc/self/fd/*
/proc/self/fd/0 /proc/self/fd/1 /proc/self/fd/2 /proc/self/fd/255 /proc/self/fd/3

Na primeira linha, o shell gerou um novo processo, '/ bin / ls', através do exec () syscall, passando "/ proc / self / fd" como argv [1]. '/ bin / ls', por sua vez, abriu o diretório / proc / self / fd e leu, em seguida, imprimiu seu conteúdo à medida que era iterado sobre eles.

A segunda linha, no entanto, usa glob () nos bastidores para expandir a lista de nomes de arquivos; estes são passados como um array de strings para ecoar. (Geralmente implementado como um comando interno, mas muitas vezes há também um bin / bin / echo ... mas essa parte é irrelevante, já que echo está lidando apenas com strings que nunca são alimentadas por syscalls relacionados a nomes de caminhos.)

Agora, considere o seguinte caso:

root@vps01:~# cd /proc/self/fd
root@vps01:~# ls
0  1  2  255

Aqui, o shell, o processo pai / bin / ls, criou um subdiretório de / proc / self em seu diretório atual . Assim, caminhos relativos são avaliados a partir de sua perspectiva. Meu melhor palpite é que isso está relacionado à semântica do arquivo POSIX, onde você pode criar vários hard links para um arquivo, incluindo qualquer descritor de arquivo aberto. Então, desta vez, / bin / ls se comporta de maneira semelhante a echo / proc / $$ / fd /*.

    

Answer 6

Como o shell invoca programas como ls em processos separados, / proc / self aparecerá como um symlink para nnnnn , onde nnnnn é o ID do processo do processo ls. Até onde eu sei, os shells comumente usados não têm built-in para ler links simbólicos, mas o Perl tem:

perl -e 'print "/ proc / link próprio:", readlink ("/ proc / self"), "- pid $$ \ n";'

Então / proc / self se comporta como um link simbólico, mas o sistema de arquivos procfs faz com que ele seja "magicamente" sensível ao processo.