Provided by: manpages-fr_4.13-4_all bug

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).

       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.

   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)
       Les appels à setns(2) qui indiquent un descripteur de fichier d'un espace de noms  PID  et
       les  appels  à  unshare(2)  avec l'attribut CLONE_NEWPID font que les processus enfant qui
       seront créés par la suite seront placés dans un espace de noms PID différent de  celui  de
       l'appelant.  Depuis  Linux 4.12,  cet  espace  de noms PID est affiché à l’aide du fichier
       /proc/[pid]/ns/pid_for_children, comme décrit dans namespaces(7). Cependant, ces appels ne
       changent pas l’espace de noms PID du processus appelant, parce que le faire modifierait la
       perception par l'appelant de son propre PID (comme  indiqué  dans  getpid()),  cassant  de
       nombreuses applications et bibliothèques.

       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.

   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_*
       Dans  les  versions  actuelles  de  Linux,  CLONE_NEWPID  ne  peut  pas  être combiné avec
       CLONE_THREAD. Les threads doivent être dans le même espace de noms PID de telle façon  que
       les  threads  puissent s’envoyer des signaux les uns aux autres. De la même façon, il doit
       être possible de voir tous les threads d’un processus dans le système de fichiers proc(5).
       De  plus,  si  deux  threads  étaient  dans  des  espaces  de noms PID différents, l’ID de
       processus du processus envoyant un signal ne pourrait pas être encodé judicieusement  lors
       de  l’envoi  d’un  signal  (consultez la description du type siginfo_t dans sigaction(2)).
       Puisque que cela a du sens lorsqu'un signal est mis en file d’attente, une file de signaux
       partagée par des processus dans plusieurs espaces de noms PID irait à l’encontre de cela.

       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
       Un système de fichiers /proc ne  présente  (dans  les  répertoires  /proc/[pid])  que  les
       processus  visibles dans l'espace de noms PID du processus qui a effectué le montage, même
       si le système de fichiers /proc est vu par des processus appartenant à d'autres espaces de
       noms.

       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.

CONFORMITÉ

       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)

COLOPHON

       Cette  page  fait partie de la publication 5.10 du projet man-pages Linux. Une description
       du projet et des instructions pour signaler des anomalies et la dernière version de  cette
       page peuvent être trouvées à l'adresse https://www.kernel.org/doc/man-pages/.

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 ⟨⟩.