Provided by: manpages-fr-dev_3.17.1-1_all bug

NOM

       clone, __clone2 - Créer un processus fils (child)

SYNOPSIS

       #define _GNU_SOURCE
       #include <sched.h>

       int clone(int (*fn)(void *), void *child_stack,
                 int flags, void *arg, ...
                 /* pid_t *pid, struct user_desc *tls, pid_t *ctid */ );

DESCRIPTION

       clone()  crée  un  nouveau processus, exactement comme le fait fork(2).
       clone() est en fait une fonction de bibliothèque s’appuyant sur l’appel
       système  clone() sous‐jacent, mentionné comme sys_clone ci‐dessous. Une
       description de sys_clone se trouve plus bas sur cette page.

       Contrairement à fork(2), cette routine permet le partage  d’une  partie
       du  contexte  d’exécution  entre  le  processus  fils  et  le processus
       appelant. Le partage peut s’appliquer  sur  l’espace  mémoire,  sur  la
       table  des  descripteurs  de  fichiers ou la table des gestionnaires de
       signaux. (Notez que sur cette page de manuel, le « processus appelant »
       correspond  normalement  au «processus père », mais voyez quand même la
       description de CLONE_PARENT plus bas).

       L’appel système  clone()  est  principalement  utilisé  pour  permettre
       l’implémentation  des  threads :  un  programme est scindé en plusieurs
       lignes de contrôle, s’exécutant simultanément dans  un  espace  mémoire
       partagée.

       Quand  le processus fils est créé, avec clone(), il exécute la fonction
       fn(arg) de l’application. Ceci est différent  de  fork(2)  avec  lequel
       l’exécution  continue  dans  le  fils  au  point  de  l’appel  fork(2).
       L’argument fn est un pointeur sur la fonction appelée par le  processus
       fils  lors  de son démarrage. L’argument arg est transmis à la fonction
       fn lors de son invocation.

       Quand la fonction fn(arg) revient, le processus  fils  se  termine.  La
       valeur  entière  renvoyée  par  fn est utilisée comme code de retour du
       processus fils. Ce  dernier  peut  également  se  terminer  de  manière
       explicite  en  invoquant la fonction exit(2) ou après la réception d’un
       signal fatal.

       L’argument child_stack indique l’emplacement de la pile utilisée par le
       processus  fils.  Comme les processus fils et appelant peuvent partager
       de la  mémoire,  il  n’est  généralement  pas  possible  pour  le  fils
       d’utiliser  la  même pile que son père. Le processus appelant doit donc
       préparer un espace mémoire  pour  stocker  la  pile  de  son  fils,  et
       transmettre  à  clone  un  pointeur  sur  cet  emplacement.  Les  piles
       croissent vers le bas sur tous les processeurs implémentant Linux (sauf
       le  HP  PA), donc child_stack doit pointer sur la plus haute adresse de
       l’espace mémoire prévu pour la pile du processus fils.

       L’octet de poids faible de flags contient le numéro du signal qui  sera
       envoyé au père lorsque le processus fils se terminera. Si ce signal est
       différent de SIGCHLD, le processus parent doit également spécifier  les
       options  __WALL  ou  __WCLONE  lorsqu’il  attend  la  fin  du fils avec
       wait(2). Si aucun signal n’est indiqué, le processus parent ne sera pas
       notifié de la terminaison du fils.

       flags permet également de préciser ce qui sera partagé entre le père et
       le fils, en effectuant  un  OU  binaire  entre  une  ou  plusieurs  des
       constantes suivantes :

       CLONE_CHILD_CLEARTID (depuis Linux 2.5.49)
              Effacer  l’ID du thread enfant à child_tidptr dans la mémoire du
              fils lorsqu’il  se  termine,  et  réveiller  le  futex  à  cette
              adresse.  L’adresse  concernée  peut  être  modifiée par l’appel
              système  set_tid_address(2).   Cela   est   utilisé   dans   les
              bibliothèques de gestion de threads.

       CLONE_CHILD_SETTID (depuis Linux 2.5.49)
              Enregistrer l’ID du thread enfant à child_tidptr dans la mémoire
              du fils.

       CLONE_FILES
              Si l’attribut CLONE_FILES est positionné, le processus  appelant
              et le processus fils partagent la même table des descripteurs de
              fichier. Tout descripteur créé par un  processus  est  également
              valide  pour l’autre processus. De même si un processus ferme un
              descripteur, ou modifie ses attributs (en utilisant  l’opération
              fcntl(2) F_SETFD), l’autre processus en est aussi affecté.

              Si  CLONE_FILES  n’est  pas positionné, le processus fils hérite
              d’une copie des descripteurs de fichier ouverts  par  l’appelant
              au  moment  de  l’appel clone(). (Les copies des descripteurs de
              fichier dans le fils sont associées aux  mêmes  descriptions  de
              fichiers  ouverts (voir open(2)) que les descripteurs de fichier
              correspondants  dans  le  processus  appelant.)  Les  opérations
              effectuées  ensuite  sur  un  descripteur  par  un des processus
              n’affectent pas l’autre processus.

       CLONE_FS
              Si l’attribut CLONE_FS est positionné, le processus appelant  et
              le processus fils partagent les mêmes informations concernant le
              système de  fichiers.  Ceci  inclut  la  racine  du  système  de
              fichiers,  le  répertoire  de  travail, et l’umask. Tout appel à
              chroot(2), chdir(2) ou umask(2) effectué par un  processus  aura
              également influence sur l’autre processus.

              Si  CLONE_FS  n’est  pas  choisi, le processus travaille sur une
              copie des informations de l’appelant concernant  le  système  de
              fichiers.  Cette  copie  est  effectuée  lors de l’invocation de
              clone(). Les appels à chroot(2),  chdir(2),  umask(2)  effectués
              par un processus n’affectent pas l’autre processus.

       CLONE_IO (depuis Linux 2.6.25)
              Si  CLONE_IO  est  défini, alors le nouveau processus partage un
              contexte d’entrées-sorties avec le processus  appelant.  Si  cet
              attribut n’est pas défini, alors (comme pour fork(2)) le nouveau
              processus a son propre contexte d’entrées-sorties.

              Le contexte d’entrées-sorties correspond  à  la  visibilité  que
              l’ordonnanceur  de  disques a des entrées-sorties (c’est-à-dire,
              ce que l’ordonnanceur d’entrée-sorties  utilise  pour  modéliser
              l’ordonnancement  des  entrées-sorties  d’un  processus). Si des
              processus partagent le même contexte d’entrées-sorties, ils sont
              traités  comme un seul par l’ordonnanceur d’entrées-sorties. Par
              conséquent, ils partagent le même  temps  d’accès  aux  disques.
              Pour certains ordonnanceurs d’entrées-sorties, si deux processus
              partagent un contexte d’entrées-sorties, ils seront autorisés  à
              intercaler  leurs  accès  disque. Si plusieurs threads utilisent
              des entrées-sorties pour le  même  processus  (aio_read(3),  par
              exemple),  ils  devraient  utiliser  CLONE_IO  pour  obtenir  de
              meilleurs performances d’entrées-sorties.

              Si le noyau n’a pas été configuré  avec  l’option  CONFIG_BLOCK,
              cet attribut n’a aucun effet.

       CLONE_NEWIPC (depuis Linux 2.6.19)
              Si  CLONE_NEWIPC  est  défini,  alors créer le processus dans un
              nouvel espace de noms IPC. Si cet  attribut  n’est  pas  défini,
              alors  (comme  pour  fork(2)) le processus est créé dans le même
              espace de noms IPC que le processus appelant. Cet  attribut  est
              sensé être utilisé pour l’implémentation de conteneurs.

              Un espace de noms IPC consiste en un jeu d’identifiants pour des
              objets  IPC  System V  (ces  objets  sont  créés  en   utilisant
              msgctl(2),  semctl(2)  et  shmctl(2)).  Les objets créés dans un
              espace de noms IPC sont  visibles  des  autres  membres  de  cet
              espace  de  noms,  mais  ne  sont pas visibles des processus des
              autres espaces de noms.

              Quand un espace de noms  est  détruit  (c’est-à-dire,  quand  le
              dernier processus membre de cet espace de noms se termine), tous
              les objets IPC  de  cet  espace  de  noms  sont  automatiquement
              détruits.

              Utiliser  cet  attribut  nécessite : un noyau configuré avec les
              options CONFIG_SYSVIPC et CONFIG_IPC_NS et que le processus soit
              privilégié  (CAP_SYS_ADMIN).  Cet  attribut  ne  peut  pas  être
              utilisé en même temps que CLONE_SYSVSEM.

       CLONE_NEWNET (depuis Linux 2.6.24)
              (L’implémentation de cet attribut n’est toujours  pas  complète,
              mais le sera sûrement aux environs de Linux 2.6.28.)

              Si  CLONE_NEWNET  est  défini,  alors créer le processus dans un
              nouvel espace de noms réseau. SI cet attribut n’est pas  défini,
              alors  (comme  pour  fork(2)) le processus est créé dans le même
              espace de noms réseau que le processus  appelant.  Cet  attribut
              est sensé être utilisé pour l’implémentation de conteneurs.

              Un  espace  de  noms  réseau  fournit  une vue isolée de la pile
              réseau  (interfaces  des   périphériques   réseau,   piles   des
              protocoles  IPv4 et IPv6, tables de routage, règles de pare-feu,
              les  arbres  de  répertoire  /proc/net  et  /sys/class/net,  les
              sockets, etc.). Un périphérique réseau physique ne peut être que
              dans un seul espace de noms réseau. Une paire d’interface réseau
              virtuelle  (« veth »)  fournit  une abstraction similaire à pipe
              qui peut être utilisé pour créer  un  pont  vers  une  interface
              réseau physique d’un autre espace de noms réseau.

              Quand  un  espace de noms réseau est libéré (c’est-à-dire, quand
              le dernier processus  de  l’espace  de  noms  se  termine),  ses
              périphériques  réseau physiques sont remis dans l’espace de noms
              réseau initial (pas celui du processus père).

              Utiliser  cet  attribut  nécessite :  un  noyau  configuré  avec
              l’option  CONFIG_NET_NS  et  que  le  processus  soit privilégié
              (CAP_SYS_ADMIN).

       CLONE_NEWNS (depuis Linux 2.4.19)
              Démarrer le processus dans un nouvel espace de noms de  montage.

              Chaque  processus  se  trouve dans un espace de noms de montage.
              Cet espace de noms du processus regroupe les  données  décrivant
              la  hiérarchie des fichiers vus par le processus (l’ensemble des
              montages).  Après  un  fork(2)  ou   clone()   sans   l’attribut
              CLONE_NEWNS  le  fils  se déroule dans le même espace de noms de
              montage que son père. Les appels système mount(2)  et  umount(2)
              modifient  l’espace de noms de montage du processus appelant, et
              affectent ainsi tous les processus se  déroulant  dans  le  même
              espace  de  noms,  sans  affecter les processus se trouvant dans
              d’autres espaces de noms de montage.

              Après un clone()  avec  l’attribut  CLONE_NEWNS  le  fils  cloné
              démarre  dans  un  nouvel  espace de noms de montage, initialisé
              avec une copie de l’espace de noms du père.

              Seul un processus privilégié (un  processus  ayant  la  capacité
              CAP_SYS_ADMIN)  peut  spécifier l’attribut CLONE_NEWNS. Il n’est
              pas possible de spécifier à la fois CLONE_NEWNS et CLONE_FS pour
              le même appel clone().

       CLONE_NEWPID (depuis Linux 2.6.24)
              Si  CLONE_NEWPID  est  défini,  alors créer le processus dans un
              nouvel espace de noms de PID. Si cet attribut n’est pas  défini,
              alors  (comme  pour  fork(2)) le processus est créé dans le même
              espace de noms de PID que le processus  appelant.  Cet  attribut
              est sensé être utilisé pour l’implémentation de conteneurs.

              Un  espace  de  noms de PID fournit un environnement isolés pour
              les PID : les PID d’un nouvel espace de noms de PID  commence  à
              1, comme pour un système seul, et les appels à fork(2), vfork(2)
              et clone(2) produiront des processus avec des PID  uniques  dans
              l’espace de noms.

              Le  premier  processus  créé  dans  un  nouvel  espace  de  noms
              (c’est-à-dire,  le  processus  créé  en   utilisant   l’attribut
              CLONE_NEWPID)  a  un  PID de 1 et est le processus « init » pour
              l’espace de noms. Les fils qui  deviennent  orphelins  dans  cet
              espace  de  noms  seront adoptés par ce processus plutôt que par
              init(8).  Contrairement  à  l’init  traditionnel,  le  processus
              « init » d’un espace de noms de PID peut se terminer et, s’il le
              fait, tous les  processus  dans  l’espace  de  noms  sont  alors
              terminés.

              Les  espaces  de  noms  de  PID forment une hiérarchie. Quand un
              espace de noms de PID est créé, les processus de cet  espace  de
              noms  sont  visibles depuis l’espace de noms de PID du processus
              qui a créé le nouvel espace de  noms ;  de  la  même  façon,  si
              l’espace  de  noms parent est lui-même le fils d’un autre espace
              de noms de PID, alors les processus du fils et  du  père  seront
              tous  visibles  de l’espace de noms grand-père. À l’inverse, les
              processus de l’espace de noms de PID  fils  ne  voient  pas  les
              processus   de   l’espace  de  noms  parent.  L’existence  d’une
              hiérarchie d’espaces de noms signifie que chaque processus  peut
              désormais  avoir  plusieurs  PID :  un  par  espace de noms dans
              lequel il est visible ; chacun de ces PID est  unique  dans  les
              espaces  de  noms  correspondants. (Un appel à getpid(2) renvoie
              toujours le PID associé  à  l’espace  de  noms  dans  lequel  le
              processus se trouve.)

              Après  avoir créé un nouvel espace de noms, il est utile pour le
              fils de changer son répertoire racine  et  monter  une  nouvelle
              instance  de  procfs  dans  /proc  de telle sorte que des outils
              comme  ps(1)  fonctionnent  correctement.  (Si  CLONE_NEWNS  est
              également  présent  dans flags, alors il n’est pas nécessaire de
              changer de répertorie racine : une nouvelle instance  de  procfs
              peut être monté directement dans /proc.)

              L’utilisation  de  cet  attribut  nécessite : un noyau configuré
              avec l’option CONFIG_PID_NS et que le processus soit  privilégié
              (CAP_SYS_ADMIN).  Cet  attribut ne peut pas être utilisé en même
              temps que CLONE_THREAD.

       CLONE_NEWUTS (depuis Linux 2.6.19)
              Si CLONE_NEWUTS est défini, alors créer  le  processus  dans  un
              nouvel  espace  de  noms  de  UTS,  dont  les  identifiants sont
              initialisé en duplicant les identifiants de l’espace de noms UTS
              du  processus  appelant. Si cet attribut n’est pas défini, alors
              (comme pour fork(2)) le processus est créé dans le  même  espace
              de  noms  UTS  que le processus appelant. Cet attribut est sensé
              être utilisé pour l’implémentation de conteneurs.

              Un espace de noms UTS est l’ensemble des  identifiants  renvoyés
              par uname(2) ; parmi lesquels le nom de domaine et le nom d’hôte
              peuvent  être  modifiés  à   l’aide   de   setdomainname(2)   et
              sethostname(2), respectivement. Les modifications apportés à ces
              identifiants dans un espace de noms UTS sont visibles  par  tous
              les  processus du même espace de noms, mais ne sont pas visibles
              des processus des autres espaces de noms UTS.

              L’utilisation de cet attribut  nécessite :  un  noyau  configuré
              avec  l’option CONFIG_UTS_NS et que le processus soit privilégié
              (CAP_SYS_ADMIN).

       CLONE_PARENT (depuis Linux 2.3.12)
              Si CLONE_PARENT est présent, le père du nouveau fils  (comme  il
              est  indiqué par getppid(2)) sera le même que celui du processus
              appelant.

              Si CLONE_PARENT n’est pas fourni, alors (comme pour fork(2))  le
              père du processus fils sera le processus appelant.

              Remarquez  que  c’est  le  processus  père,  tel  qu’indiqué par
              getppid(2), qui est notifié lors de la fin du  fils.  Ainsi,  si
              CLONE_PARENT  est  présent,  alors  c’est  le  père du processus
              appelant, et non ce dernier, qui sera notifié.

       CLONE_PARENT_SETTID (depuis Linux 2.5.49)
              Enregistrer l’ID  du  thread  enfant  à  parent_tidptr  dans  la
              mémoire  du père et du fils. (Dans Linux 2.5.32-2.5.48 il y a un
              attribut CLONE_SETTID qui fait cela.)

       CLONE_PID (obsolète)
              Si l’attribut CLONE_PID est positionné, les  processus  appelant
              et  fils ont le même numéro de processus. C’est bien pour hacker
              le système, mais autrement il n’est plus utilisé. Depuis 2.3.21,
              cet  attribut  ne  peut  être  utilisé  que  par le processus de
              démarrage du système (PID 0). Il a disparu dans Linux 2.5.16.

       CLONE_PTRACE
              Si l’attribut CLONE_PTRACE est positionné et si  l’appelant  est
              suivi par un débogueur, alors le fils sera également suivi (voir
              ptrace(2)).

       CLONE_SETTLS (depuis Linux 2.5.32)
              Le paramètre newtls est le nouveau descripteur TLS (Thread Local
              Storage). (Voir set_thread_area(2).)

       CLONE_SIGHAND
              Si   l’attribut   CLONE_SIGHAND  est  positionné,  le  processus
              appelant et le  processus  fils  partagent  la  même  table  des
              gestionnaires  de  signaux.  Si  l’appelant, ou le fils, appelle
              sigaction(2) pour modifier le comportement associé à un  signal,
              ce  comportement  est  également  changé pour l’autre processus.
              Néanmoins, l’appelant et le fils ont  toujours  des  masques  de
              signaux  distincts,  et  leurs ensembles de signaux bloqués sont
              indépendants. L’un des processus peut donc bloquer un signal  en
              utilisant sigprocmask(2) sans affecter l’autre processus.

              Si  CLONE_SIGHAND  n’est  pas  utilisé, le processus fils hérite
              d’une copie des gestionnaires de signaux de l’appelant  lors  de
              l’invocation  de  clone().  Les  appels à sigaction(2) effectués
              ensuite depuis un  processus  n’ont  pas  d’effets  sur  l’autre
              processus.

              Depuis  Linux  2.6.0-test6,  l’attribut  CLONE_VM doit également
              être spécifié dans flags si CLONE_SIGHAND l’est.

       CLONE_STOPPED (depuis Linux 2.6.0-test2)
              Si  l’attribut  CLONE_STOPPED  est  positionné,  le   fils   est
              initialement  stoppé  (comme s’il avait reçu le signal SIGSTOP),
              et doit être relancé en lui envoyant le signal SIGCONT.

              Depuis Linux 2.6.25 cet attribut est  dconseill.  Vous  n’avez
              probablement   jamais   voulu   l’utiliser ;   vous  ne  devriez
              certainement pas l’utiliser ; et il sera bientôt supprimé.

       CLONE_SYSVSEM (depuis Linux 2.5.10)
              Si  CLONE_SYSVSEM  est  positionné,  le  fils  et  le  processus
              appelant  partagent la même liste de compteurs « undo » pour les
              sémaphores SystemV (voir semop(2)). Si cet  attribut  n’est  pas
              utilisé,  le  fils  a  une  liste « undo » séparée, initialement
              vide.

       CLONE_THREAD (depuis Linux 2.4.0-test8)
              Si CLONE_THREAD est présent, le fils  est  placé  dans  le  même
              groupe  de  threads  que  le  processus appelant. Afin de rendre
              l’explication de CLONE_THREAD plus lisible, le terme  « thread »
              est  utilisé  pour  parler  des processus dans un même groupe de
              threads.

              Les groupes de threads sont  une  fonctionnalité  ajoutées  dans
              Linux  2.4  pour supporter la notion POSIX d’ensemble de threads
              partageant un même PID. En interne, ce PID  partagé  est  appelé
              identifiant  de  groupe  de  threads  (TGID).Depuis  Linux  2.4,
              l’appel getpid(2) renvoie l’identifiant du groupe de  thread  de
              l’appelant.

              Les  threads  dans  un  groupe  peuvent être distingués par leur
              identifiant de thread (TID, unique sur le système). Le TID  d’un
              nouveau thread est renvoyé par clone() au processus appelant, et
              un thread peut obtenir son propre TID en utilisant gettid(2).

              Quand clone()  est  appelé  sans  positionner  CLONE_THREAD,  le
              nouveau  thread  est placé dans un nouveau groupe de thread dont
              le TGID est identique au TID du nouveau thread. Ce thread est le
              leader du nouveau groupe.

              Un  nouveau  thread  créé  en  utilisant  CLONE_THREAD a le même
              processus père  que  l’appelant  de  clone()  (de  même  qu’avec
              CLONE_PARENT),  ainsi  les appels à getppid(2) renvoient la même
              valeur à tous les threads dans un même groupe. Lorsqu’un  thread
              créé  avec  CLONE_THREAD termine, le thread qui a appelé clone()
              pour le  créer  ne  reçoit  pas  le  signal  SIGCHLD  (ou  autre
              notification  de  terminaison) ; de même, l’état d’un tel thread
              ne peut être obtenu par wait(2). Le thread est dit dtach.

              Lorsque tous les threads d’un groupe de  threads  terminent,  le
              processus  parent  du  groupe reçoit un signal SIGCHLD (ou autre
              indicateur de terminaison).

              Si l’un des threads dans un groupe de threads appelle execve(2),
              tous  les  threads  sauf  le  leader  sont  tués,  et le nouveau
              programme est exécuté dans le leader du groupe de threads.

              Si l’un des threads dans un groupe crée un  fils  avec  fork(2),
              n’importe lequel des threads du groupe peut utiliser wait(2) sur
              ce fils.

              Depuis Linux 2.5.35, l’attribut CLONE_SIGHAND de flags doit être
              positionné si CLONE_THREAD l’est.

              Un  signal  peut  être  envoyé  à  un groupe de threads dans son
              ensemble (c’est‐à‐dire à un TGID) avec kill(2),  ou  bien  à  un
              thread en particulier (à un TID) avec tgkill(2).

              Les  gestions de signaux sont définies au niveau des processus :
              si un signal sans  gestionnaire  est  reçu  par  un  thread,  il
              affectera  (tuera, stoppera, relancera, ou sera ignoré par) tous
              les membres du groupe de threads.

              Chaque thread  a  son  propre  masque  de  signaux,  défini  par
              sigprocmask(2),  mais  les  signaux peuvent être en attente soit
              pour le processus dans son ensemble (donc  peut  être  reçu  par
              n’importe  lequel des threads du groupe), quand ils sont envoyés
              avec kill(2), soit pour un thread particulier,  lorsqu’ils  sont
              envoyés  par  tgkill(2).  Un  appel  à  sigpending(2) renvoie un
              ensemble de signaux qui est l’union  des  processus  en  attente
              pour le processus et ceux en attente pour le thread appelant.

              Si  kill(2)  est  utilisé  pour envoyer un signal à un groupe de
              threads, et si le groupe a  installé  un  gestionnaire  pour  ce
              signal,  alors  le  gestionnaire sera exécuté dans exactement un
              des membres du groupe de threads,  choisi  de  façon  arbitraire
              parmi  ceux qui n’ont pas bloqué ce signal. Si plusieurs threads
              dans  un  groupe  attendent  le   même   signal   en   utilisant
              sigwaitinfo(2),  le  noyau  choisira arbitrairement l’un d’entre
              eux pour délivrer le signal envoyé par kill(2).

       CLONE_UNTRACED (depuis Linux 2.5.46)
              Si l’attribut CLONE_UNTRACED est positionné, alors un  processus
              traçant le père ne peut pas forcer CLONE_PTRACE pour ce fils.

       CLONE_VFORK
              Si  le  bit  CLONE_VFORK  est  actif,  l’exécution  du processus
              appelant est  suspendue  jusqu’à  ce  que  le  fils  libère  ses
              ressources  de  mémoire  virtuelle  par  un  appel  execve(2) ou
              _exit(2) (comme avec vfork(2)).

              Si CLONE_VFORK n’est pas indiqué, alors les deux processus  sont
              ordonnancés  à  partir de la fin de l’appel, et l’application ne
              doit pas considérer que l’ordre d’exécution soit déterminé.

       CLONE_VM
              Si le bit CLONE_VM  est  actif,  le  processus  appelant  et  le
              processus  fils  s’exécutent  dans  le  même  espace mémoire. En
              particulier, les écritures en mémoire effectuées  par  l’un  des
              processus sont visibles par l’autre. De même toute projection en
              mémoire, ou toute suppression  de  projection,  effectuées  avec
              mmap(2)  ou munmap(2) par l’un des processus affectera également
              l’autre processus.

              Si CLONE_VM n’est pas actif, le  processus  fils  utilisera  une
              copie distincte de l’espace mémoire de l’appelant. Le cliché est
              réalisé lors de l’invocation de clone(). Les  écritures  ou  les
              projections  de  fichiers en mémoire effectuées par un processus
              n’affectent pas l’autre processus,  comme  cela  se  passe  avec
              fork(2).

   sys_clone
       L’appel  système  sys_clone  ressemble  plus  à  fork(2),  en  ceci que
       l’exécution dans le processus fils continue à partir du point  d’appel.
       Ainsi sys_clone ne nécessite que les arguments flags et child_stack qui
       ont la même signification que pour clone(). (Notez que l’ordre  de  ces
       arguments est différent de celui dans clone().)

       Une autre différence : pour sys_clone, l’argument child_stack peut être
       nul, puisque la sémantique de  copie-en-écriture  assure  que  le  fils
       recevra  une copie indépendante des pages de la pile dès qu’un des deux
       processus la modifiera. Pour que cela fonctionne, il faut naturellement
       que CLONE_VM ne soit pas présent.

       Depuis  Linux  2.5.49,  l’appel  système  a  cinq  paramètres. Les deux
       nouveaux paramètres sont parent_tidptr qui pointe à l’endroit (dans  la
       mémoire  du père et celle du fils) où l’ID du thread fils sera écrit au
       cas où CLONE_PARENT_SETTID serait spécifié, et child_tidptr qui  pointe
       à l’endroit (dans la mémoire du fils) où l’ID du thread fils sera écrit
       au cas où CLONE_CHILD_SETTID serait spécifié.

VALEUR RENVOYÉE

       En cas de réussite, le TID du processus fils est renvoyé dans le thread
       d’exécution  de  l’appelant.  En  cas  d’échec,  -1 est renvoyé dans le
       contexte de l’appelant, aucun fils n’est créé, et errno  contiendra  le
       code d’erreur.

ERREURS

       EAGAIN Trop de processus en cours d’exécution.

       EINVAL CLONE_SIGHAND  a  été  spécifié  mais pas CLONE_VM (depuis Linux
              2.6.0-test6).

       EINVAL CLONE_THREAD a été  spécifié  mais  pas  CLONE_SIGHAND   (depuis
              Linux 2.5.35).

       EINVAL Les   attributs   CLONE_NEWNS   et  CLONE_FS  ont  été  indiqués
              simultanément dans flags.

       EINVAL Les attributs CLONE_NEWIPC et  CLONE_SYSVSEM  ont  été  indiqués
              simultanément dans flags.

       EINVAL Les  attributs  CLONE_NEWPID  et  CLONE_THREAD  ont été indiqués
              simultanément dans flags.

       EINVAL Renvoyée par clone() quand une valeur nulle a été indiquée  pour
              le paramètre child_stack.

       EINVAL CLONE_NEWIPC a été indiqué dans flags, mais le noyau n’a pas été
              configuré avec les options CONFIG_SYSVIPC et CONFIG_IPC_NS.

       EINVAL CLONE_NEWNET a été indiqué dans flags, mais le noyau n’a pas été
              configuré avec l’option CONFIG_NET_NS.

       EINVAL CLONE_NEWPID a été indiqué dans flags, mais le noyau n’a pas été
              configuré avec l’option CONFIG_PID_NS.

       EINVAL CLONE_NEWUTS a été indiqué dans flags, mais le noyau n’a pas été
              configuré avec l’option CONFIG_UTS.

       ENOMEM Pas  assez  de  mémoire  pour  copier les parties du contexte du
              processus appelant qui doivent être dupliquées, ou pour  allouer
              une structure de tâche pour le processus fils.

       EPERM  CLONE_NEWIPC,   CLONE_NEWNET,   CLONE_NEWNS,   CLONE_NEWPID,  ou
              CLONE_NEWUTS a été spécifié par un processus non root (processus
              sans CAP_SYS_ADMIN).

       EPERM  CLONE_PID  a été réclamé par un processus autre que le processus
              0.

VERSIONS

       Il n’y a pas de définition pour clone() dans la libc5.  glibc2  fournit
       une définition de clone() comme décrit ici.

CONFORMITÉ

       Les  appels système clone() et sys_clone sont spécifiques à Linux et ne
       doivent pas être employés dans des programmes portables.

NOTES

       Dans les noyaux 2.4.x, CLONE_THREAD ne rend pas en général le processus
       père de l’appelant père du nouveau thread. Cependant, pour les versions
       2.4.7  à  2.4.18   du   noyau,   l’attribut   CLONE_THREAD   impliquait
       CLONE_PARENT (de même qu’avec les noyaux 2.6).

       CLONE_DETACHED  a  existé pendant un moment (introduit dans 2.5.32): le
       père ne veut pas de signal à la mort du fils. Dans 2.6.2, la  nécessité
       d’utiliser ce paramètre avec CLONE_THREAD a été supprimée. Cet attribut
       est toujours défini, mais n’a plus aucun effet.

       Sur i386, clone()  ne  devrait  pas  être  appelé  via  vsyscall,  mais
       directement en utilisant int $0x80.

       Sur IA-64, un appel système différent est utilisé :

       int __clone2(int (*fn)(void *),
                    void *child_stack_base, size_t stack_size,
                    int flags, void *arg, ...
                 /* pid_t *pid, struct user_desc *tls, pid_t *ctid */ );

       L’appel   système   __clone2()   fonctionne  comme  clone(),  sauf  que
       child_stack_base pointe sur la plus petite adresse de la pile du  fils,
       et  stack_size  indique  la  taille  de  la  pile  sur  laquelle pointe
       child_stack_base.

BOGUES

       Les versions de la bibliothèque C GNU qui  gèrent  la  bibliothèque  de
       gestion  des  threads  NPTL  contiennent  une  fonction  enveloppe pour
       getpid(2) qui effectue un cache des PID. Ce cache nécessite  une  prise
       en  charge par l’enveloppe de clone() de la glibc, mais telle qu’il est
       actuellement implémenté,  le  cache  peut  ne  pas  être  à  jour  sous
       certaines  circonstances.  En particulier, si un signal est distribué à
       un fils juste après l’appel à clone(), alors un appel à  getpid()  dans
       le  gestionnaire de signaux du signal peut renvoyer le PID du processus
       appelant (le père), si l’enveloppe de clone  n’a  toujours  pas  eu  le
       temps  de mettre le cache de PID à jour pour le fils. (Cette discussion
       ignore le cas où le fils a été créé en  utilisant  CLONE_THREAD,  quand
       getpid() doit renvoyer la même valeur pour le fils et pour le processus
       qui a appelé clone(), puisque l’appelant et le fils se trouvent dans le
       même groupe de threads. Ce problème de cache n’apparaît pas non plus si
       le paramètre  flags  contient  CLONE_VM.)  Pour  obtenir  la  véritable
       valeur, il peut être nécessaire d’utiliser quelque chose comme ceci :

           #include <syscall.h>

           pid_t mypid;

           mypid = syscall(SYS_getpid);

VOIR AUSSI

       fork(2),    futex(2),    getpid(2),    gettid(2),   set_thread_area(2),
       set_tid_address(2),  tkill(2),  unshare(2),  wait(2),  capabilities(7),
       pthreads(7)

COLOPHON

       Cette  page  fait  partie  de  la  publication 3.17 du projet man-pages
       Linux. Une description du projet et des instructions pour signaler  des
       anomalies       peuvent       être       trouvées      à      l’adresse
       http://www.kernel.org/doc/man-pages/.

TRADUCTION

       Cette page de manuel a été traduite  et  mise  à  jour  par  Christophe
       Blaess  <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis par
       Alain Portal <aportal AT univ-montp2 DOT fr> jusqu’en 2006, et  mise  à
       disposition sur http://manpagesfr.free.fr/.

       Les mises à jour et corrections de la version présente dans Debian sont
       directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
       francophone de traduction de Debian.

       Veuillez   signaler   toute   erreur   de   traduction  en  écrivant  à
       <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
       paquet manpages-fr.

       Vous  pouvez  toujours avoir accès à la version anglaise de ce document
       en utilisant la commande « man -L C <section> <page_de_man> ».