Provided by: manpages-fr_4.18.1-1_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).

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