Quel process est `/ proc / self /` pour?

https://www.centos.org/docs/5/html/5.2/Deployment_Guide/s3-proc-self.html dit

Le /proc/self/ est un lien vers le process en cours d'exécution.

Il y a toujours plusieurs process qui s'exécutent simultanément, alors quel process est "le process en cours d'exécution"?

Est-ce que "le process en cours d'exécution" a quelque chose à voir avec quel process est en cours d'exécution sur le CPU, en tenant count du changement de context?

Le process en cours d'exécution n'a-t-il rien à voir avec les process de premier plan et d'arrière-plan?

    Cela n'a rien à voir avec les process de premier plan et d'arrière-plan; cela n'a à voir qu'avec le process en cours d'exécution. Lorsque le kernel doit répondre à la question "À quoi /proc/self pointer?", Il choisit simplement le pid actuellement programmé , c'est -à- dire le process en cours d'exécution (sur la CPU logique actuelle). L'effet est que /proc/self pointe toujours vers le pid du programme requestur; si tu cours

     ls -l /proc/self 

    vous verrez le pid de ls , si vous écrivez du code qui utilise /proc/self ce code verra son propre pid, etc.

    Celui qui accède au lien symbolique (appelle readlink () sur celui-ci, ou ouvre () sur un path à travers). Il serait en cours d'exécution sur le processeur à l'époque, mais ce n'est pas pertinent. Un système multiprocesseur pourrait avoir plusieurs process sur le CPU simultanément.

    Les process de premier plan et d'arrière-plan sont principalement une construction de shell, et il n'y a pas de process de premier plan unique, car toutes les sessions de shell du système en auront une.

    Le libellé aurait pu être mieux, mais encore une fois, tout libellé que vous essayez de composer pour exprimer l'idée de l'autoreference va être source de confusion. Le nom du directory est plus descriptif à mon avis.

    Fondamentalement, /proc/self/ représente le process qui lit /proc/self/ . Donc, si vous essayez d'ouvrir /proc/self/ partir d'un programme C, il représente ce programme. Si vous essayez de le faire à partir de la coquille alors c'est la coquille etc.

    Mais que se passe-t-il si vous avez un processeur quad core capable d'exécuter 4 process simultanément, pour de vrai, pas de multitâche?

    Ensuite, chaque process verra un /proc/self/ for réel différent sans pouvoir voir les uns les autres /proc/self/ .

    Comment cela marche-t-il?

    Eh bien, /proc/self/ n'est pas vraiment un dossier. Il s'agit d'un pilote de périphérique qui se présente sous la forme d'un dossier si vous essayez d'y accéder. C'est parce qu'il implémente l'API nécessaire pour les dossiers. Le /proc/self/ n'est pas la seule chose qui fait cela. Envisagez les dossiers partagés montés à partir de servers distants ou le assembly de keys USB ou de boîtes de repository. Ils travaillent tous en implémentant le même set d'API qui les font se comporter comme des dossiers.

    Lorsqu'un process tente d'accéder à /proc/self/ le pilote de périphérique génère son contenu dynamicment en lisant datatables de ce process. Ainsi, les files dans /proc/self/ n'existent pas vraiment. C'est un peu comme un miroir qui réfléchit sur le process qui essaie de le regarder.

    Est-ce vraiment un pilote de périphérique? Tu as l'air de trop simplifier les choses!

    Oui, c'est vraiment. Si vous voulez être pédant, c'est un module kernel. Mais si vous consultez les messages d'usenet sur les différents canaux des développeurs Linux, la plupart des développeurs du kernel utilisent indifféremment «driver de périphérique» et «module kernel». J'avais l'habitude d'écrire des pilotes de périphériques, err … des modules de kernel, pour Linux. Si vous voulez écrire votre propre interface dans /proc/ , dites par exemple que vous voulez un /proc/unix.stackexchange/ système de files qui renvoie des messages de ce site, vous pouvez lire comment le faire dans le livre vénérable "Linux Device Drivers" publié par O'Reilly. Il est même disponible en version papier en ligne.

    C'est le process qui accède à /proc/self ou les files / dossiers qui s'y trouvent.

    Essayez cat /proc/self/cmdline . Vous obtiendrez, surprise surprise, cat /proc/self/cmdline , (en fait, au lieu d'un espace, il y aura un caractère nul entre le t et le / ) car ce sera le process cat accédant à ce pseudofile.

    Quand vous faites un ls -l /proc/self , vous verrez le pid du process ls lui-même. Ou que diriez-vous de ls -l /proc/self/exe ; il pointera vers l'exécutable ls.

    Ou essayez ceci, pour un changement:

     $ 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 même

     $ 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 

    Comme je l'ai dit, c'est le process qui accède à /proc/self ou aux files / dossiers qui s'y trouvent.

    / proc / self est le sucre syntactique. C'est un raccourci vers contatenating / proc / et le résultat de getpid () syscall (accessible dans bash comme le metavariable $$). Cela peut prêter à confusion, alors que dans le cas des scripts shell, beaucoup d'instructions invoquent d'autres process, complétés par les propres PID … PID qui font reference, le plus souvent, aux process morts. Considérer:

     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' va évaluer le path vers le directory, en le résolvant comme / proc / 26563, puisque c'est le PID du process – le nouveau process / bin / ls – qui lit le contenu du directory. Mais au moment où le process suivant dans le pipeline, dans le cas du script shell, ou au moment où l'invite revient, dans le cas d'un shell interactif, le path n'existe plus et la sortie d'information se réfère à un process inexistant.

    Ceci s'applique uniquement aux commands externes (celles qui sont des files de programme exécutables réels, par opposition à être embeddedes dans le shell lui-même). Vous obtiendrez donc des résultats différents si vous utilisez, par exemple, le nom de file globbing pour get une list du contenu du directory, plutôt que de passer le nom du path au process externe / 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 

    Dans la première ligne, le shell a donné naissance à un nouveau process, '/ bin / ls', via le syscall exec (), en passant par "/ proc / self / fd" comme argv [1]. '/ bin / ls', à son tour, a ouvert le directory / proc / self / fd et a lu, puis imprimé, son contenu tel qu'il itéré sur eux.

    La deuxième ligne, cependant, utilise glob () dans les coulisses pour développer la list des noms de files; ceux-ci sont passés sous la forme d'un tableau de strings à écho. (Habituellement implémenté en tant que command interne, mais il y a souvent aussi un binary / bin / echo … mais cette partie n'est pas pertinente car echo ne traite que les strings qu'il n'alimente jamais avec les noms de paths).

    Maintenant, considérez le cas suivant:

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

    Ici, le shell, le process parent de / bin / ls, a fait un sous-directory de / proc / self son directory courant . Ainsi, les paths relatifs sont évalués de son sharepoint vue. Ma meilleure supposition est que cela est lié à la sémantique des files POSIX où vous pouvez créer plusieurs liens physiques vers un file, y compris tous les descripteurs de files ouverts. Donc cette fois, / bin / ls se comporte comme echo / proc / $$ / fd / *.

    Comme le shell invoque des programmes comme ls dans des process séparés, / proc / self apparaîtra comme un lien symbolique vers nnnnn , où nnnnn est l'ID de process du process ls. Pour autant que je sache, les coquilles couramment utilisées n'ont pas embedded pour la lecture des liens symboliques, mais Perl a:

    perl -e 'print "/ proc / self lien:", readlink ("/ proc / self"), "- pid $$ \ n";'

    So / proc / self se comporte comme un lien symbolique, mais le système de files procfs le rend "magiquement" sensible au process.