Provided by: manpages-fr-dev_3.27fr1.4-1_all bug

NOM

       clone, __clone2 - Creer un processus fils (child)

SYNOPSIS

       #define _GNU_SOURCE             /* Consultez feature_test_macros(7) */
       #include <sched.h>

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

DESCRIPTION

       clone()  cree  un  nouveau processus, exactement comme le fait fork(2).
       clone() est en fait une fonction de bibliotheque s'appuyant sur l'appel
       systeme  clone() sous-jacent, mentionne comme sys_clone ci-dessous. Une
       description de sys_clone se trouve plus bas sur cette page.

       Contrairement a fork(2), cette routine permet le partage  d'une  partie
       du  contexte  d'execution  entre  le  processus  fils  et  le processus
       appelant. Le partage peut s'appliquer  sur  l'espace  memoire,  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 pere >>, mais voyez
       quand meme la description de CLONE_PARENT plus bas).

       L'appel systeme  clone()  est  principalement  utilise  pour  permettre
       l'implementation  des  threads :  un  programme est scinde en plusieurs
       lignes de controle, s'executant simultanement dans  un  espace  memoire
       partagee.

       Quand  le processus fils est cree, avec clone(), il execute la fonction
       fn(arg) de l'application. Ceci est different  de  fork(2)  avec  lequel
       l'execution  continue  dans  le  fils  au  point  de  l'appel  fork(2).
       L'argument fn est un pointeur sur la fonction appelee par le  processus
       fils  lors  de son demarrage. L'argument arg est transmis a la fonction
       fn lors de son invocation.

       Quand la fonction fn(arg) revient, le processus  fils  se  termine.  La
       valeur  entiere  renvoyee  par  fn est utilisee comme code de retour du
       processus fils. Ce  dernier  peut  egalement  se  terminer  de  maniere
       explicite  en  invoquant la fonction exit(2) ou apres la reception d'un
       signal fatal.

       L'argument child_stack indique l'emplacement de la pile utilisee par le
       processus  fils.  Comme les processus fils et appelant peuvent partager
       de la  memoire,  il  n'est  generalement  pas  possible  pour  le  fils
       d'utiliser  la  meme pile que son pere. Le processus appelant doit donc
       preparer un espace memoire  pour  stocker  la  pile  de  son  fils,  et
       transmettre  a  clone  un  pointeur  sur  cet  emplacement.  Les  piles
       croissent vers le bas sur tous les processeurs implementant Linux (sauf
       le  HP  PA), donc child_stack doit pointer sur la plus haute adresse de
       l'espace memoire prevu pour la pile du processus fils.

       L'octet de poids faible de flags contient le numero du signal qui  sera
       envoye au pere lorsque le processus fils se terminera. Si ce signal est
       different de SIGCHLD, le processus parent doit egalement specifier  les
       options  __WALL  ou  __WCLONE  lorsqu'il  attend  la  fin  du fils avec
       wait(2). Si aucun signal n'est indique, le processus parent ne sera pas
       notifie de la terminaison du fils.

       flags permet egalement de preciser ce qui sera partage entre le pere 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 a ctid dans la memoire du fils
              lorsqu'il se termine, et reveiller le  futex  a  cette  adresse.
              L'adresse  concernee  peut  etre  modifiee  par  l'appel systeme
              set_tid_address(2). Cela est utilise dans les  bibliotheques  de
              gestion de threads.

       CLONE_CHILD_SETTID (depuis Linux 2.5.49)
              Enregistrer  l'ID  du  thread  enfant  a ctid dans la memoire du
              fils.

       CLONE_FILES
              Si l'attribut CLONE_FILES est positionne, le processus  appelant
              et le processus fils partagent la meme table des descripteurs de
              fichier. Tout descripteur cree par un  processus  est  egalement
              valide  pour l'autre processus. De meme si un processus ferme un
              descripteur, ou modifie ses attributs (en utilisant  l'operation
              fcntl(2) F_SETFD), l'autre processus en est aussi affecte.

              Si  CLONE_FILES  n'est  pas positionne, le processus fils herite
              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 associees aux  memes  descriptions  de
              fichiers  ouverts  (consultez  open(2))  que les descripteurs de
              fichier  correspondants  dans  le  processus   appelant.)    Les
              operations  effectuees  ensuite  sur  un  descripteur par un des
              processus n'affectent pas l'autre processus.

       CLONE_FS
              Si l'attribut CLONE_FS est positionne, le processus appelant  et
              le processus fils partagent les memes informations concernant le
              systeme de  fichiers.  Ceci  inclut  la  racine  du  systeme  de
              fichiers,  le  repertoire  de  travail, et l'umask. Tout appel a
              chroot(2), chdir(2) ou umask(2) effectue par un  processus  aura
              egalement 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  systeme  de
              fichiers.  Cette  copie  est  effectuee  lors de l'invocation de
              clone(). Les appels a chroot(2),  chdir(2),  umask(2)  effectues
              par un processus n'affectent pas l'autre processus.

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

              Le contexte d'entrees-sorties correspond  a  la  visibilite  que
              l'ordonnanceur  de  disques a des entrees-sorties (c'est-a-dire,
              ce que l'ordonnanceur d'entree-sorties  utilise  pour  modeliser
              l'ordonnancement  des  entrees-sorties  d'un  processus). Si des
              processus partagent le meme contexte d'entrees-sorties, ils sont
              traites  comme un seul par l'ordonnanceur d'entrees-sorties. Par
              consequent, ils partagent le meme  temps  d'acces  aux  disques.
              Pour certains ordonnanceurs d'entrees-sorties, si deux processus
              partagent un contexte d'entrees-sorties, ils seront autorises  a
              intercaler  leurs  acces  disque. Si plusieurs threads utilisent
              des entrees-sorties pour le  meme  processus  (aio_read(3),  par
              exemple),  ils  devraient  utiliser  CLONE_IO  pour  obtenir  de
              meilleurs performances d'entrees-sorties.

              Si le noyau n'a pas ete configure  avec  l'option  CONFIG_BLOCK,
              cet attribut n'a aucun effet.

       CLONE_NEWIPC (depuis Linux 2.6.19)
              Si  CLONE_NEWIPC  est  defini,  alors creer le processus dans un
              nouvel espace de noms IPC. Si cet  attribut  n'est  pas  defini,
              alors  (comme  pour  fork(2)) le processus est cree dans le meme
              espace de noms IPC que le processus appelant. Cet  attribut  est
              sense etre utilise pour l'implementation de conteneurs.

              Un espace de noms IPC consiste en un jeu d'identifiants pour des
              objets  IPC  System V  (ces  objets  sont  crees  en   utilisant
              msgctl(2),  semctl(2)  et  shmctl(2)).  Les objets crees dans un
              espace de noms IPC sont visibles de tous les 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  detruit  (c'est-a-dire,  quand  le
              dernier processus membre de cet espace de noms se termine), tous
              les objets IPC  de  cet  espace  de  noms  sont  automatiquement
              detruits.

              Utiliser  cet  attribut  necessite : un noyau configure avec les
              options CONFIG_SYSVIPC et CONFIG_IPC_NS et que le processus soit
              privilegie  (CAP_SYS_ADMIN).  Cet  attribut  ne  peut  pas  etre
              utilise en meme temps que CLONE_SYSVSEM.

       CLONE_NEWNET (depuis Linux 2.6.24)
              (L'implementation de cet attribut n'est toujours  pas  complete,
              mais le sera surement aux environs de Linux 2.6.28.)

              Si  CLONE_NEWNET  est  defini,  alors creer le processus dans un
              nouvel espace de noms reseau. SI cet attribut n'est pas  defini,
              alors  (comme  pour  fork(2)) le processus est cree dans le meme
              espace de noms reseau que le processus  appelant.  Cet  attribut
              est sense etre utilise pour l'implementation de conteneurs.

              Un  espace  de  noms  reseau  fournit  une vue isolee de la pile
              reseau  (interfaces  des   peripheriques   reseau,   piles   des
              protocoles  IPv4 et IPv6, tables de routage, regles de pare-feu,
              les  arbres  de  repertoire  /proc/net  et  /sys/class/net,  les
              sockets, etc.). Un peripherique reseau physique ne peut etre que
              dans un seul espace de noms reseau. Une paire d'interface reseau
              virtuelle  (<< veth >>) fournit une abstraction similaire a pipe
              qui peut etre utilise pour creer  un  pont  vers  une  interface
              reseau physique d'un autre espace de noms reseau.

              Quand  un  espace de noms reseau est libere (c'est-a-dire, quand
              le dernier processus  de  l'espace  de  noms  se  termine),  ses
              peripheriques  reseau physiques sont remis dans l'espace de noms
              reseau initial (pas celui du processus pere).

              Utiliser  cet  attribut  necessite :  un  noyau  configure  avec
              l'option  CONFIG_NET_NS  et  que  le  processus  soit privilegie
              (CAP_SYS_ADMIN).

       CLONE_NEWNS (depuis Linux 2.4.19)
              Demarrer 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 donnees decrivant
              la hierarchie des fichiers vus par le processus (l'ensemble  des
              montages).   Apres   un   fork(2)  ou  clone()  sans  l'attribut
              CLONE_NEWNS le fils se deroule dans le meme espace  de  noms  de
              montage  que  son pere. Les appels systeme mount(2) et umount(2)
              modifient l'espace de noms de montage du processus appelant,  et
              affectent  ainsi  tous  les  processus se deroulant dans le meme
              espace de noms, sans affecter les  processus  se  trouvant  dans
              d'autres espaces de noms de montage.

              Apres  un  clone()  avec  l'attribut  CLONE_NEWNS  le fils clone
              demarre dans un nouvel espace de  noms  de  montage,  initialise
              avec une copie de l'espace de noms du pere.

              Seul  un  processus  privilegie  (un processus ayant la capacite
              CAP_SYS_ADMIN) peut specifier l'attribut CLONE_NEWNS.  Il  n'est
              pas possible de specifier a la fois CLONE_NEWNS et CLONE_FS pour
              le meme appel clone().

       CLONE_NEWPID (depuis Linux 2.6.24)
              Si CLONE_NEWPID est defini, alors creer  le  processus  dans  un
              nouvel  espace de noms de PID. Si cet attribut n'est pas defini,
              alors (comme pour fork(2)) le processus est cree  dans  le  meme
              espace  de  noms  de PID que le processus appelant. Cet attribut
              est sense etre utilise pour l'implementation de conteneurs.

              Un espace de noms de PID fournit un  environnement  isoles  pour
              les  PID :  les PID d'un nouvel espace de noms de PID commence a
              1, comme pour un systeme seul, et les appels a fork(2), vfork(2)
              et  clone(2)  produiront des processus avec des PID uniques dans
              l'espace de noms.

              Le  premier  processus  cree  dans  un  nouvel  espace  de  noms
              (c'est-a-dire,   le   processus  cree  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 adoptes par ce processus  plutot  que  par
              init(8).  Contrairement  a  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
              termines.

              Les espaces de noms de PID  forment  une  hierarchie.  Quand  un
              espace  de  noms de PID est cree, les processus de cet espace de
              noms sont visibles depuis l'espace de noms de PID  du  processus
              qui  a  cree  le  nouvel  espace  de noms ; de la meme facon, si
              l'espace de noms parent est lui-meme le fils d'un  autre  espace
              de  noms  de  PID, alors les processus du fils et du pere seront
              tous visibles de l'espace de noms grand-pere. A  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
              hierarchie  d'espaces de noms signifie que chaque processus peut
              desormais 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  a  getpid(2)  renvoie
              toujours  le  PID  associe  a  l'espace  de  noms dans lequel le
              processus se trouve.)

              Apres avoir cree un nouvel espace de noms, il est utile pour  le
              fils  de  changer  son  repertoire 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
              egalement present dans flags, alors il n'est pas  necessaire  de
              changer  de  repertorie racine : une nouvelle instance de procfs
              peut etre monte directement dans /proc.)

              L'utilisation de cet attribut  necessite :  un  noyau  configure
              avec  l'option CONFIG_PID_NS et que le processus soit privilegie
              (CAP_SYS_ADMIN). Cet attribut ne peut pas etre utilise  en  meme
              temps que CLONE_THREAD.

       CLONE_NEWUTS (depuis Linux 2.6.19)
              Si  CLONE_NEWUTS  est  defini,  alors creer le processus dans un
              nouvel espace  de  noms  de  UTS,  dont  les  identifiants  sont
              initialises  en  dupliquant les identifiants de l'espace de noms
              UTS du processus appelant. Si cet  attribut  n'est  pas  defini,
              alors  (comme  pour  fork(2)) le processus est cree dans le meme
              espace de noms UTS que le processus appelant. Cet  attribut  est
              sense etre utilise pour l'implementation de conteneurs.

              Un  espace  de noms UTS est l'ensemble des identifiants renvoyes
              par uname(2) ; parmi lesquels le nom de domaine et le nom d'hote
              peuvent    etre    modifies    respectivement    a   l'aide   de
              setdomainname(2) et sethostname(2). Les modifications apportes a
              ces  identifiants  dans  un espace de noms UTS sont visibles par
              tous les processus du meme espace de  noms,  mais  ne  sont  pas
              visibles des processus des autres espaces de noms UTS.

              L'utilisation  de  cet  attribut  necessite : un noyau configure
              avec l'option CONFIG_UTS_NS et que le processus soit  privilegie
              (CAP_SYS_ADMIN).

       CLONE_PARENT (depuis Linux 2.3.12)
              Si  CLONE_PARENT  est present, le pere du nouveau fils (comme il
              est indique par getppid(2)) sera le meme que celui du  processus
              appelant.

              Si  CLONE_PARENT n'est pas fourni, alors (comme pour fork(2)) le
              pere du processus fils sera le processus appelant.

              Remarquez que  c'est  le  processus  pere,  tel  qu'indique  par
              getppid(2),  qui  est  notifie lors de la fin du fils. Ainsi, si
              CLONE_PARENT est present,  alors  c'est  le  pere  du  processus
              appelant, et non ce dernier, qui sera notifie.

       CLONE_PARENT_SETTID (depuis Linux 2.5.49)
              Enregistrer l'ID du thread enfant a ptid dans la memoire du pere
              et du fils.  (Dans  Linux  2.5.32-2.5.48  il  y  a  un  attribut
              CLONE_SETTID qui fait cela.)

       CLONE_PID (obsolete)
              Si  l'attribut  CLONE_PID est positionne, les processus appelant
              et fils ont le meme numero de processus. C'est bien pour  hacker
              le systeme, mais autrement il n'est plus utilise. Depuis 2.3.21,
              cet attribut ne peut  etre  utilise  que  par  le  processus  de
              demarrage du systeme (PID 0). Il a disparu dans Linux 2.5.16.

       CLONE_PTRACE
              Si  l'attribut  CLONE_PTRACE est positionne et si l'appelant est
              suivi par un debogueur,  alors  le  fils  sera  egalement  suivi
              (consultez ptrace(2)).

       CLONE_SETTLS (depuis Linux 2.5.32)
              Le parametre newtls est le nouveau descripteur TLS (Thread Local
              Storage). (Consultez set_thread_area(2).)

       CLONE_SIGHAND
              Si  l'attribut  CLONE_SIGHAND  est  positionne,   le   processus
              appelant  et  le  processus  fils  partagent  la  meme table des
              gestionnaires de signaux. Si l'appelant,  ou  le  fils,  appelle
              sigaction(2)  pour modifier le comportement associe a un signal,
              ce comportement est egalement  change  pour  l'autre  processus.
              Neanmoins,  l'appelant  et  le  fils ont toujours des masques de
              signaux distincts, et leurs ensembles de  signaux  bloques  sont
              independants.  L'un des processus peut donc bloquer un signal en
              utilisant sigprocmask(2) sans affecter l'autre processus.

              Si CLONE_SIGHAND n'est pas utilise,  le  processus  fils  herite
              d'une  copie  des gestionnaires de signaux de l'appelant lors de
              l'invocation de clone(). Les  appels  a  sigaction(2)  effectues
              ensuite  depuis  un  processus  n'ont  pas  d'effets sur l'autre
              processus.

              Depuis Linux 2.6.0-test6,  l'attribut  CLONE_VM  doit  egalement
              etre specifie dans flags si CLONE_SIGHAND l'est.

       CLONE_STOPPED (depuis Linux 2.6.0-test2)
              Si   l'attribut   CLONE_STOPPED  est  positionne,  le  fils  est
              initialement stoppe (comme s'il avait recu le  signal  SIGSTOP),
              et doit etre relance en lui envoyant le signal SIGCONT.

              Depuis  Linux 2.6.25  cet  attribut est d'econseill'e. Vous n'avez
              probablement  jamais  voulu   l'utiliser ;   vous   ne   devriez
              certainement pas l'utiliser ; et il sera bientot supprime.

       CLONE_SYSVSEM (depuis Linux 2.5.10)
              Si  CLONE_SYSVSEM  est  positionne,  le  fils  et  le  processus
              appelant partagent la meme liste de  compteurs  << undo >>  pour
              les  semaphores  System V  (consultez semop(2)). Si cet attribut
              n'est pas utilise, le  fils  a  une  liste  << undo >>  separee,
              initialement vide.

       CLONE_THREAD (depuis Linux 2.4.0-test8)
              Si  CLONE_THREAD  est  present,  le  fils est place dans le meme
              groupe de threads que le  processus  appelant.  Afin  de  rendre
              l'explication   de   CLONE_THREAD   plus   lisible,   le   terme
              << thread >> est utilise pour parler des processus dans un  meme
              groupe de threads.

              Les  groupes  de  threads  sont une fonctionnalite ajoutees dans
              Linux 2.4 pour supporter la notion POSIX d'ensemble  de  threads
              partageant  un  meme  PID. En interne, ce PID partage est appele
              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  etre  distingues  par  leur
              identifiant  de thread (TID, unique sur le systeme). Le TID d'un
              nouveau thread est renvoye par clone() au processus appelant, et
              un thread peut obtenir son propre TID en utilisant gettid(2).

              Quand  clone()  est  appele  sans  positionner  CLONE_THREAD, le
              nouveau thread est place 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 cree  en  utilisant  CLONE_THREAD  a  le  meme
              processus  pere  que  l'appelant  de  clone()  (de  meme qu'avec
              CLONE_PARENT), ainsi les appels a getppid(2) renvoient  la  meme
              valeur  a tous les threads dans un meme groupe. Lorsqu'un thread
              cree avec CLONE_THREAD termine, le thread qui a  appele  clone()
              pour  le  creer  ne  recoit  pas  le  signal  SIGCHLD  (ou autre
              notification de terminaison) ; de meme, l'etat d'un  tel  thread
              ne peut etre obtenu par wait(2). Le thread est dit d'etach'e.

              Lorsque  tous  les  threads d'un groupe de threads terminent, le
              processus parent du groupe recoit 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  tues,  et  le  nouveau
              programme est execute dans le leader du groupe de threads.

              Si  l'un  des  threads dans un groupe cree 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 etre
              positionne si CLONE_THREAD l'est.

              Un signal peut etre envoye a  un  groupe  de  threads  dans  son
              ensemble  (c'est-a-dire  a  un  TGID) avec kill(2), ou bien a un
              thread en particulier (a un TID) avec tgkill(2).

              Les gestions de signaux sont definies au niveau des  processus :
              si  un  signal  sans  gestionnaire  est  recu  par un thread, il
              affectera (tuera, stoppera, relancera, ou sera ignore par)  tous
              les membres du groupe de threads.

              Chaque  thread  a  son  propre  masque  de  signaux,  defini par
              sigprocmask(2), mais les signaux peuvent etre  en  attente  soit
              pour  le  processus  dans  son ensemble (donc peut etre recu par
              n'importe lequel des threads du groupe), quand ils sont  envoyes
              avec  kill(2),  soit pour un thread particulier, lorsqu'ils sont
              envoyes par tgkill(2).  Un  appel  a  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 utilise pour envoyer un signal  a  un  groupe  de
              threads,  et  si  le  groupe  a installe un gestionnaire pour ce
              signal, alors le gestionnaire sera execute  dans  exactement  un
              des  membres  du  groupe  de threads, choisi de facon arbitraire
              parmi ceux qui n'ont pas bloque ce signal. Si plusieurs  threads
              dans   un   groupe   attendent   le  meme  signal  en  utilisant
              sigwaitinfo(2), le noyau choisira  arbitrairement  l'un  d'entre
              eux pour delivrer le signal envoye par kill(2).

       CLONE_UNTRACED (depuis Linux 2.5.46)
              Si  l'attribut CLONE_UNTRACED est positionne, alors un processus
              tracant le pere ne peut pas forcer CLONE_PTRACE pour ce fils.

       CLONE_VFORK
              Si le  bit  CLONE_VFORK  est  actif,  l'execution  du  processus
              appelant  est  suspendue  jusqu'a  ce  que  le  fils  libere ses
              ressources de  memoire  virtuelle  par  un  appel  execve(2)  ou
              _exit(2) (comme avec vfork(2)).

              Si  CLONE_VFORK n'est pas indique, alors les deux processus sont
              ordonnances a partir de la fin de l'appel, et  l'application  ne
              doit pas considerer que l'ordre d'execution soit determine.

       CLONE_VM
              Si  le  bit  CLONE_VM  est  actif,  le  processus appelant et le
              processus fils s'executent  dans  le  meme  espace  memoire.  En
              particulier,  les  ecritures  en memoire effectuees par l'un des
              processus sont visibles par l'autre. De meme toute projection en
              memoire,  ou  toute  suppression  de projection, effectuees avec
              mmap(2) ou munmap(2) par l'un des processus affectera  egalement
              l'autre processus.

              Si  CLONE_VM  n'est  pas  actif, le processus fils utilisera une
              copie distincte de l'espace memoire de l'appelant. Le cliche est
              realise  lors  de  l'invocation de clone(). Les ecritures ou les
              projections de fichiers en memoire effectuees par  un  processus
              n'affectent  pas  l'autre  processus,  comme  cela se passe avec
              fork(2).

   sys_clone
       L'appel systeme  sys_clone  ressemble  plus  a  fork(2),  en  ceci  que
       l'execution  dans le processus fils continue a partir du point d'appel.
       Ainsi sys_clone ne necessite que les arguments flags et child_stack qui
       ont  la  meme signification que pour clone(). (Notez que l'ordre de ces
       arguments est different de celui dans clone().)

       Une autre difference : pour sys_clone, l'argument child_stack peut etre
       nul,  puisque  la  semantique  de  copie-en-ecriture assure que le fils
       recevra une copie independante des pages de la pile des qu'un des  deux
       processus la modifiera. Pour que cela fonctionne, il faut naturellement
       que CLONE_VM ne soit pas present.

       Sous Linux 2.4 et plus anciens, clone()  ne  prend  pas  les  arguments
       ptid, tls et ctid.

VALEUR RENVOY'EE

       En cas de reussite, le TID du processus fils est renvoye dans le thread
       d'execution de l'appelant. En cas  d'echec,  -1  est  renvoye  dans  le
       contexte  de  l'appelant, aucun fils n'est cree, et errno contiendra le
       code d'erreur.

ERREURS

       EAGAIN Trop de processus en cours d'execution.

       EINVAL CLONE_SIGHAND a ete specifie mais  pas  CLONE_VM  (depuis  Linux
              2.6.0-test6).

       EINVAL CLONE_THREAD  a  ete  specifie  mais  pas CLONE_SIGHAND  (depuis
              Linux 2.5.35).

       EINVAL Les  attributs  CLONE_NEWNS  et  CLONE_FS   ont   ete   indiques
              simultanement dans flags.

       EINVAL Les  attributs  CLONE_NEWIPC  et  CLONE_SYSVSEM ont ete indiques
              simultanement dans flags.

       EINVAL Les attributs CLONE_NEWPID  et  CLONE_THREAD  ont  ete  indiques
              simultanement dans flags.

       EINVAL Renvoyee  par clone() quand une valeur nulle a ete indiquee pour
              le parametre child_stack.

       EINVAL CLONE_NEWIPC a ete indique dans flags, mais le noyau n'a pas ete
              configure avec les options CONFIG_SYSVIPC et CONFIG_IPC_NS.

       EINVAL CLONE_NEWNET a ete indique dans flags, mais le noyau n'a pas ete
              configure avec l'option CONFIG_NET_NS.

       EINVAL CLONE_NEWPID a ete indique dans flags, mais le noyau n'a pas ete
              configure avec l'option CONFIG_PID_NS.

       EINVAL CLONE_NEWUTS a ete indique dans flags, mais le noyau n'a pas ete
              configure avec l'option CONFIG_UTS.

       ENOMEM Pas assez de memoire pour copier  les  parties  du  contexte  du
              processus  appelant qui doivent etre dupliquees, ou pour allouer
              une structure de tache pour le processus fils.

       EPERM  CLONE_NEWIPC,   CLONE_NEWNET,   CLONE_NEWNS,   CLONE_NEWPID   ou
              CLONE_NEWUTS  a  ete  specifie  par  un processus non privilegie
              (processus sans CAP_SYS_ADMIN).

       EPERM  CLONE_PID a ete reclame par un processus autre que le  processus
              0.

VERSIONS

       Il  n'y  a pas de definition pour clone() dans la libc5. glibc2 fournit
       une definition de clone() comme decrit ici.

CONFORMIT'E

       Les appels systeme clone() et sys_clone sont specifiques a Linux et  ne
       doivent pas etre employes dans des programmes portables.

NOTES

       Dans les noyaux 2.4.x, CLONE_THREAD ne rend pas en general le processus
       pere de l'appelant pere du nouveau thread. Cependant, pour les versions
       2.4.7   a   2.4.18   du   noyau,   l'attribut  CLONE_THREAD  impliquait
       CLONE_PARENT (de meme qu'avec les noyaux 2.6).

       CLONE_DETACHED a existe pendant un moment (introduit dans  2.5.32):  le
       pere  ne veut pas de signal a la mort du fils. Dans 2.6.2, la necessite
       d'utiliser ce parametre avec CLONE_THREAD a ete supprimee. Cet attribut
       est toujours defini, mais n'a plus aucun effet.

       Sur  i386,  clone()  ne  devrait  pas  etre  appele  via vsyscall, mais
       directement en utilisant int $0x80.

       Sur IA-64, un appel systeme different est utilise :

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

       L'appel  systeme  __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  bibliotheque C GNU qui gerent la bibliotheque de
       gestion des  threads  NPTL  contiennent  une  fonction  enveloppe  pour
       getpid(2)  qui  effectue un cache des PID. Ce cache necessite une prise
       en charge par l'enveloppe de clone() de la glibc, mais telle qu'il  est
       actuellement  implemente,  le  cache  peut  ne  pas  etre  a  jour sous
       certaines circonstances. En particulier, si un signal est  distribue  a
       un  fils  juste apres l'appel a clone(), alors un appel a getpid() dans
       le gestionnaire de signaux du signal peut renvoyer le PID du  processus
       appelant  (le  pere),  si  l'enveloppe  de clone n'a toujours pas eu le
       temps de mettre le cache de PID a jour pour le fils. (Cette  discussion
       ignore  le  cas  ou le fils a ete cree en utilisant CLONE_THREAD, quand
       getpid() doit renvoyer la meme valeur pour le fils et pour le processus
       qui a appele clone(), puisque l'appelant et le fils se trouvent dans le
       meme groupe de threads. Ce probleme de cache n'apparait pas non plus si
       le  parametre  flags  contient  CLONE_VM.)  Pour  obtenir  la veritable
       valeur, il peut etre necessaire 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.27  du  projet  man-pages
       Linux.  Une description du projet et des instructions pour signaler des
       anomalies      peuvent      etre       trouvees       a       l'adresse
       <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

       Depuis  2010,  cette  traduction est maintenue a l'aide de l'outil po4a
       <URL:http://po4a.alioth.debian.org/>   par   l'equipe   de   traduction
       francophone        au        sein        du       projet       perkamon
       <URL:http://perkamon.alioth.debian.org/>.

       Christophe Blaess  <URL:http://www.blaess.fr/christophe/>  (1996-2003),
       Alain   Portal  <URL:http://manpagesfr.free.fr/>  (2003-2006).   Julien
       Cristau et l'equipe francophone de traduction de Debian (2006-2009).

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

       Vous pouvez toujours avoir acces a la version anglaise de  ce  document
       en utilisant la commande << man -L C <section> <page_de_man> >>.