Les espaces de noms PID isolent les espaces de numéros d'identifiants de processus, ce qui signifie que des processus de différents espaces de noms PID peuvent avoir le même PID. Les espaces de noms PID permettent aux conteneurs de fournir des possibilités telles que la suspension et la reprise de l’ensemble des processus d’un conteneur et la migration du conteneur vers un nouvel hôte tout en permettant aux processus du conteneur de conserver leurs PID.
Dans un nouvel espace de noms PID, la numérotation commence à 1 comme pour un système autonome et les appels à fork(2), vfork(2) ou clone(2) génèrent des identifiants de processus uniques dans l'espace de noms PID.
Le noyau doit avoir été configuré avec l'option CONFIG_PID_NS pour permettre l'utilisation des espaces noms PID.
Si le processus « init » d'un espace de noms PID se termine, le noyau tue tous les processus de cet espace de noms au moyen du signal SIGKILL. Ce comportement illustre le fait que le processus « init » est essentiel au bon fonctionnement de l'espace de noms PID. Dans ce cas, une commande fork(2) ultérieure dans cet espace de noms PID échouera en renvoyant l'erreur ENOMEM. Il n'est plus possible de créer des processus dans un espace de noms PID dont le processus « init » est terminé. Cela peut, par exemple, se produire lorsqu'un processus utilise un descripteur de fichier ouvert pour un fichier /proc/pid/ns/pid correspondant à un processus d'un espace de noms pour une réassociation (setns(2)) dans cet espace de noms après que le processus « init » soit terminé. Un autre scénario est possible après un appel à unshare(2) : si le premier enfant créé par un appel à fork(2) se termine, alors les appels ultérieurs à fork(2) échoueront en renvoyant l'erreur ENOMEM.
Seuls les signaux pour lesquels le processus « init » a défini un gestionnaire de signal peuvent être envoyés au processus « init » par les autres processus de l'espace de noms PID. Cette règle s'applique également aux processus disposant de privilèges et permet d'éviter qu'un processus membre de l'espace de noms PID ne tue accidentellement le processus « init ».
De même, un processus d'un espace ancêtre peut --- en tenant compte des vérifications de droits habituelles décrites dans kill(2) --- envoyer des signaux au processus « init » d’un espace de noms enfant, à la condition que le processus « init » ait établi un gestionnaire pour ce signal. Le champ si_pid de siginfo_t décrit dans sigaction(2) pour ce gestionnaire vaudra zéro. SIGKILL et SIGSTOP font figure d'exception : ces signaux seront appliqués « de force » lorsqu'ils sont émis depuis un espace de noms PID ancêtre. Ces signaux ne peuvent pas être interceptés par le processus « init » et les actions associées à ces processus seront exécutées (respectivement, tuer ou suspendre l'exécution du processus).
Depuis Linux 3.4, l’appel système reboot(2) déclenche l'envoi d'un signal aux processus « init » des espaces de noms. Consultez reboot(2) pour obtenir plus d'informations.
Un processus est visible de tous les processus de son espace de noms PID, et de tous les processus des espaces de noms PID ancêtres qui le séparent de l'espace PID « root ». Ici, on entend par « visible » qu'un autre processus peut être la cible d’opérations d’un autre processus utilisant des appels système qui précisent l’ID du processus. Inversement, les processus d'un espace de noms PID enfant ne peuvent pas voir les processus de l’espace parent et des espaces de noms ancêtre éloignés. En résumé, un processus peut seulement voir (c'est-à-dire envoyer des signaux avec kill(2), définir des valeurs de courtoisie avec setpriority(2), etc.) les processus de son propre espace de noms PID et des espaces de noms de sa descendance.
Un processus a un identifiant dans chaque niveau de la hiérarchie des espaces de noms PID dans lequel il est visible, et ce en remontant chaque espace de noms ancêtre jusqu'à l'espace de noms PID « root ». Les appels système qui s'exécutent sur des identifiants de processus s'appliquent à l'identifiant du processus qui est visible dans l’espace de noms PID de l'appelant. Un appel à getpid(2) renvoie toujours le PID associé à l'espace de noms dans lequel le processus a été créé.
Certains processus d'un espace de noms PID peuvent avoir des parents en dehors de cet espace. Par exemple, le parent du processus initial de l'espace de noms (init(1), processus dont le PID est 1) se trouve forcément en dehors de cet espace. De même, l’enfant direct d'un processus qui a invoqué setns(2) pour que son enfant rejoigne un espace de noms PID, se trouve dans un espace de noms PID différent de celui de l'appelant à setns(2). Les appels à getppid(2) pour de tels processus renvoient 0.
Alors que les processus peuvent descendre librement dans les espaces de noms enfant (par exemple, en utilisant setns(2) avec un descripteur de fichier d’espace de noms PID), ils ne peuvent pas se déplacer dans l’autre direction. Cela veut dire que les processus ne peuvent entrer dans aucun espace de noms ancêtre (parent, grand-parent, etc.). La modification d’espace de noms PID est une opération à sens unique.
L’opération NS_GET_PARENT d’ioctl(2) peut être utilisée pour découvrir la relation parentale entre les espaces de noms PID. Consultez ioctl_nsfs(2).
Pour présenter les choses différemment, l'appartenance d'un processus à un espace de noms PID est déterminée lors de la création du processus et ne peut plus être changée ensuite. Cela signifie que la relation parent-enfant entre processus reproduit la relation parentale entre des espaces de noms PID : le parent d'un processus est soit dans le même espace de noms, soit dans l'espace de noms PID du parent immédiat.
Un processus peut appeler unshare(2) avec l’indicateur CLONE_NEWPID seulement une fois. Après avoir réalisé cette opération, son lien symbolique /proc/pid/ns/pid_for_children sera vide jusqu’à la création du premier enfant dans l’espace de noms.
De plus dans les premières versions de Linux, CLONE_NEWPID n’était pas autorisé (échouant avec l’erreur EINVAL) en combinaison avec CLONE_SIGHAND (avant Linux 4.3) ainsi que CLONE_VM (avant Linux 3.12). Les modifications qui ont apporté ces restrictions ont été aussi portées sur les précédents noyaux stables.
Après la création d'un nouvel espace de noms PID, un enfant peut avoir intérêt à changer son répertoire racine et à monter une nouvelle instance procfs sur /proc afin d'assurer que des commandes comme ps(1) fonctionneront correctement. Si un nouvel espace de noms montage est créé simultanément en invoquant clone(2) ou unshare(2) avec l'argument CLONE_NEWNS, il n'est alors pas nécessaire de changer le répertoire racine : une nouvelle instance procfs peut être montée directement dans /proc.
Depuis un interpréteur de commandes, la commande permettant de monter /proc est :
$ mount -t proc proc /proc
L'appel de readlink(2) appliqué au chemin /proc/self affiche les identifiants des processus de l'appelant dans l'espace de noms PID du montage procfs (c'est-à-dire l'espace de noms PID du processus qui a monté procfs). Cela peut être utile lorsque qu'un processus a besoin de connaître son PID dans un autre espace de noms.
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à