Quel processus est utilisé pour / proc / self / `?

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

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

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

Le "processus en cours d'exécution" a-t-il quelque chose à voir avec le processus en cours d'exécution sur la CPU, compte tenu du changement de contexte?

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

Cela n'a rien à voir avec les processus de premier plan et d'arrière-plan; cela ne concerne que le processus en cours d'exécution. Lorsque le noyau doit répondre à la question «Qu'est-ce qui /proc/selfpointe vers?», Il sélectionne simplement le pid actuellement planifié , c'est -à- dire le processus en cours d'exécution (sur le processeur logique actuel). L'effet est que /proc/selfpointe toujours vers le pid du programme demandé; si tu cours

ls -l /proc/self

vous verrez lsle pid, si vous écrivez du code qui utilise /proc/selfce code verra son propre pid, etc.

Celui qui accède au lien symbolique (appelle readlink () ou open () sur un chemin le traversant). Il fonctionnerait sur le processeur à ce moment-là, mais ce n'est pas pertinent. Un système multiprocesseur peut avoir plusieurs processus simultanément sur la CPU.

Les processus d'avant-plan et d'arrière-plan sont principalement une construction de shell et il n'y a pas non plus de processus de premier plan unique, car toutes les sessions de shell sur le système en auront un.

La formulation aurait pu être meilleure, mais là encore, toute formulation que vous essayez de composer pour exprimer l’idée de référence à vous-même est source de confusion. Le nom du répertoire est plus descriptif à mon avis.

Fondamentalement, /proc/self/représente le processus en cours de lecture /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 du shell, c'est le shell, etc.

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

Ensuite, chaque processus verra un différent /proc/self/pour de vrai sans pouvoir se voir /proc/self/.

Comment cela marche-t-il?

Eh bien, ce /proc/self/n'est pas vraiment un dossier. Il s’agit d’un pilote de périphérique qui s’expose sous forme de dossier si vous essayez d’y accéder. En effet, il implémente l'API nécessaire aux dossiers. Le /proc/self/répertoire n’est pas la seule chose à faire. Prenez en compte les dossiers partagés montés à partir de serveurs distants ou le montage de clés USB ou de boîtes de dépôt. Ils fonctionnent tous en implémentant le même ensemble d'API qui leur permet de se comporter comme des dossiers.

Lorsqu'un processus tente d'accéder /proc/self/au pilote de périphérique, il génère son contenu de manière dynamique en lisant les données de ce processus. Donc, les fichiers /proc/self/n’existent pas vraiment. C'est un peu comme un miroir reflétant le processus qui tente de l'examiner.

Est-ce vraiment un pilote de périphérique? Vous semblez simplifier à l'extrême!

Oui, c'est vraiment ça. Si vous voulez être pédant, c'est un module du noyau. Mais si vous consultez les publications Usenet sur les différents canaux de développement Linux, la plupart des développeurs du noyau utilisent indifféremment "pilote de périphérique" et "module de noyau". J'avais l'habitude d'écrire des pilotes de périphériques, des ... modules du noyau, pour Linux. Si vous voulez écrire votre propre interface dans /proc/, disons par exemple que vous voulez un /proc/unix.stackexchange/système de fichiers qui retourne les posts de ce site, vous pouvez lire comment le faire dans le vénérable ouvrage "Pilotes de périphérique Linux" publié par O'Reilly. Il est même disponible en version électronique en ligne.

C'est n'importe quel processus qui accède /proc/selfou les fichiers / dossiers qu'il contient.

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 tet le /) car ce sera le processus cat accédant à ce pseudofichier.

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

Ou essayez ceci, pour changer les choses:

$ 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 processus qui accède /proc/selfou les fichiers / dossiers qu’il contient.

/ proc / self est un sucre syntaxique. C'est un raccourci pour contatenating / proc / et le résultat du syscall getpid () (accessible par le biais de la métavariable $$). Cela peut prêter à confusion, cependant, dans le cas de scripts shell, de nombreuses instructions invoquant d'autres processus, complétées par les propres PID ... Les PID qui font référence, le plus souvent, à des processus inactifs. 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' évaluera le chemin du répertoire et le résoudra en tant que / proc / 26563, car il s'agit du PID du processus - le processus / bin / ls nouvellement créé - qui lit le contenu du répertoire. Toutefois, au moment du processus suivant dans le pipeline, dans le cas d'un script shell, ou au retour de l'invite, dans le cas d'un shell interactif, le chemin n'existe plus et la sortie d'informations fait référence à un processus inexistant.

Ceci ne s'applique toutefois qu'aux commandes externes (celles-ci sont de véritables fichiers de programme exécutables, par opposition à celles intégrées au shell). Ainsi, vous obtiendrez des résultats différents si, par exemple, vous utilisez une suppression de nom de fichier pour obtenir une liste du contenu du répertoire, plutôt que de transmettre le nom du chemin au processus 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 généré un nouveau processus, '/ bin / ls', via l'appel système exec (), en passant "/ proc / self / fd" comme argv [1]. '/ bin / ls' a à son tour ouvert le répertoire / proc / self / fd et lu, puis imprimé, son contenu au fur et à mesure de son itération.

La deuxième ligne, cependant, utilise glob () dans les coulisses pour développer la liste des noms de fichiers; ceux-ci sont passés sous forme de tableau de chaînes à écho. (Habituellement implémenté en tant que commande interne, mais il y a souvent aussi un binaire / bin / echo ... mais cette partie est en réalité sans importance, puisque echo ne traite que des chaînes, il ne renvoie jamais à aucun appel système lié à des noms de chemins.)

Maintenant, considérons le cas suivant:

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

Ici, le shell, le processus parent de / bin / ls, a fait un sous-répertoire de / proc / self son répertoire actuel . Ainsi, les noms de chemin relatifs sont évalués de son point de vue. Ma meilleure hypothèse est que cela est lié à la sémantique de fichier POSIX dans laquelle vous pouvez créer plusieurs liens physiques vers un fichier, y compris tous les descripteurs de fichier ouverts. Donc, cette fois, / bin / ls se comporte de la même manière que echo / proc / $$ / fd / *.

Comme le shell appelle des programmes tels que ls dans des processus séparés, / proc / self apparaît sous la forme d'un lien symbolique vers nnnnn , où nnnnn est l'ID du processus ls. Autant que je sache, les shells couramment utilisés ne possèdent pas de fonction de lecture de liens symboliques, mais Perl possède:

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

Donc, / proc / self se comporte comme un lien symbolique, mais le système de fichiers procfs le rend "magiquement" sensible au processus.