Provided by: manpages-fr_4.19.0-7_all 
NOM
pid_namespaces - Présentation des espaces de noms d'identifiants de processus (ou PID)
sous Linux
DESCRIPTION
Pour une présentation générale des espaces de noms, consultez namespaces(7).
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.
Le processus d'initialisation (init) de l'espace de noms
Le premier processus créé dans un nouvel espace de noms (c'est-à-dire le processus créé
par clone(2) avec l'attribut CLONE_NEWPID ou le premier processus enfant créé après un
appel à unshare(2) avec l'attribut CLONE_NEWPID) a pour PID 1. Il est le processus
« init » pour l'espace de noms (consultez init(1)). Ce processus devient le parent pour
n’importe quel processus enfant qui devient orphelin parce qu’un processus résidant dans
cet espace de noms PID se termine (voir ci-après pour plus de détails).
If the "init" process of a PID namespace terminates, the kernel terminates all of the
processes in the namespace via a SIGKILL signal. This behavior reflects the fact that the
"init" process is essential for the correct operation of a PID namespace. In this case, a
subsequent fork(2) into this PID namespace fail with the error ENOMEM; it is not possible
to create a new process in a PID namespace whose "init" process has terminated. Such
scenarios can occur when, for example, a process uses an open file descriptor for a
/proc/pid/ns/pid file corresponding to a process that was in a namespace to setns(2) into
that namespace after the "init" process has terminated. Another possible scenario can
occur after a call to unshare(2): if the first child subsequently created by a fork(2)
terminates, then subsequent calls to fork(2) fail with 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 ».
Likewise, a process in an ancestor namespace can—subject to the usual permission checks
described in kill(2)—send signals to the "init" process of a child PID namespace only if
the "init" process has established a handler for that signal. (Within the handler, the
siginfo_t si_pid field described in sigaction(2) will be zero.) SIGKILL or SIGSTOP are
treated exceptionally: these signals are forcibly delivered when sent from an ancestor PID
namespace. Neither of these signals can be caught by the "init" process, and so will
result in the usual actions associated with those signals (respectively, terminating and
stopping the process).
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.
Imbrication des espaces de noms PID
Les espaces de noms PID peuvent être imbriqués : tous les espaces de noms PID ont un
parent, sauf l'espace de noms PID initial (« root »). Le parent d'un espace de noms PID
est l'espace de noms PID du processus qui a créé l'espace de noms à l’aide de clone(2) ou
unshare(2). Les espaces de noms PID forment donc une arborescence dans laquelle chaque
espace de noms peut remonter jusqu'à l'espace « root ». Depuis Linux 3.7, le noyau limite
la profondeur maximale d’imbrication pour les espace de noms PID à 32.
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_ns(2).
Sémantiques de setns(2) et de unshare(2)
Calls to setns(2) that specify a PID namespace file descriptor and calls to unshare(2)
with the CLONE_NEWPID flag cause children subsequently created by the caller to be placed
in a different PID namespace from the caller. (Since Linux 4.12, that PID namespace is
shown via the /proc/pid/ns/pid_for_children file, as described in namespaces(7).) These
calls do not, however, change the PID namespace of the calling process, because doing so
would change the caller's idea of its own PID (as reported by getpid()), which would break
many applications and libraries.
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.
A process may call unshare(2) with the CLONE_NEWPID flag only once. After it has
performed this operation, its /proc/pid/ns/pid_for_children symbolic link will be empty
until the first child is created in the namespace.
Adoption d’un enfant orphelin
Quand un processus enfant devient orphelin, il est réapparenté au processus « init » dans
l’espace de noms PID de son parent (sinon un des ancêtres les plus proches du parent
employé dans la commande PR_SET_CHILD_SUBREAPER de prctl(2) pour être marqué comme le
récupérateur des processus de descendants orphelins). Il est à noter qu’à cause des
sémantiques de setns(2) et unshare(2) décrites ci-dessus, cela peut être le processus
« init » dans l’espace de noms PID qui est le parent de l’espace de noms PID de l’enfant,
plutôt que le processus « init » dans le propre espace de noms PID de l’enfant.
Compatibilité de CLONE_NEWPID avec les autres attributs CLONE_*
In current versions of Linux, CLONE_NEWPID can't be combined with CLONE_THREAD. Threads
are required to be in the same PID namespace such that the threads in a process can send
signals to each other. Similarly, it must be possible to see all of the threads of a
process in the proc(5) filesystem. Additionally, if two threads were in different PID
namespaces, the process ID of the process sending a signal could not be meaningfully
encoded when a signal is sent (see the description of the siginfo_t type in sigaction(2)).
Since this is computed when a signal is enqueued, a signal queue shared by processes in
multiple PID namespaces would defeat that.
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.
/proc et espaces de noms PID
A /proc filesystem shows (in the /proc/pid directories) only processes visible in the PID
namespace of the process that performed the mount, even if the /proc filesystem is viewed
from processes in other namespaces.
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.
Fichiers /proc
/proc/sys/kernel/ns_last_pid (depuis Linux 3.3)
Ce fichier (virtualisé par espace de noms PID) affiche le dernier PID qui a été
alloué dans cet espace de noms PID. Quand le prochain PID est alloué, le noyau
recherchera le plus petit PID non alloué qui est supérieur à cette valeur, et quand
ce fichier est lu ultérieurement, il affiche ce PID.
Un processus peut écrire sur ce fichier s’il a la capacité CAP_SYS_ADMIN ou (depuis
Linux 5.9) CAP_CHECKPOINT_RESTORE à l’intérieur de l’espace de noms utilisateur qui
possède l’espace de noms PID. Cela rend possible de déterminer le PID qui est
alloué au prochain processus créé dans cet espace de noms PID.
Divers
Lorsqu'un identifiant de processus est transmis à l’aide d’un socket de domaine UNIX à un
processus d'un autre espace de noms PID (consultez SCM_CREDENTIALS dans unix(7)), il est
transformé pour devenir le PID correspondant dans l'espace de noms PID du processus
recevant.
STANDARDS
Les espaces de noms sont propres à Linux.
EXEMPLES
Consultez user_namespaces(7).
VOIR AUSSI
clone(2), reboot(2), setns(2), unshare(2), proc(5), capabilities(7), credentials(7),
mount_namespaces(7), namespaces(7), user_namespaces(7), switch_root(8)
TRADUCTION
La traduction française de cette page de manuel a été créée par Christophe Blaess
<https://www.blaess.fr/christophe/>, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry
Vignaud <tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>,
Jean-Philippe Guérard <fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-
luc.coulon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux
<thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin
Duneau <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis
Barbier <barbier@debian.org>, David Prévot <david@tilapin.org>, Cédric Boutillier
<cedric.boutillier@gmail.com>, Frédéric Hantrais <fhantrais@gmail.com> et Jean-Paul
Guillonneau <guillonneau.jeanpaul@free.fr>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General
Public License version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 à ⟨debian-l10n-french@lists.debian.org⟩.