Provided by: manpages-de-dev_0.10-1_all bug

BEZEICHNUNG

       clone, __clone2 - erzeugt einen Kindprozess

"UBERSICHT

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

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

BESCHREIBUNG

       clone()  erzeugt  einen neuen Prozess auf eine ahnliche Art wie fork(2)
       Tatsachlich ist es  eine  Bibliotheksfunktion,  die  zuoberst  auf  dem
       darunterliegenden  Systemaufruf clone() aufsetzt, nachfolgend sys_clone
       genannt. Eine Beschreibung von sys_clone findet sich gegen Ende  dieser
       Seite.

       Im  Gegensatz  zu  fork(2) erlauben diese Aufrufe, dass der Kindprozess
       Teile seines Kontextes mit dem aufrufenden Prozess teilt.  Dazu  zahlen
       der  Speicherplatz,  die  Tabelle der Dateideskriptoren und die Tabelle
       der Signal-Handler. (Beachten Sie,  dass  >>aufrufender  Prozess<<  auf
       dieser  Handbuchseite  >>Elternprozess<<  entspricht. Aber lesen Sie im
       Folgenden die Beschreibung von CLONE_PARENT.)

       Hauptsachlich wird  clone()  benutzt,  um  Threads  zu  implementieren:
       mehrere  Steuer-Threads  in  einem  Programm, die gleichzeitig in einem
       gemeinsamen Speicherbereich ausgefuhrt werden.

       Wird   mit   clone()   ein   Kindprozess   erzeugt,   fuhrt   er    das
       Funktionsprogramm fn(arg) aus. (Dies ist ein Unterschied zu fork(2), wo
       die Ausfuhrung im Kindprozess vom Punkt des fork(2)-Aufrufs fortfahrt.)
       Das  Argument  fn ist ein Zeiger auf eine Funktion, die vom Kindprozess
       zu Beginn seiner Ausfuhrung abgearbeitet wird. arg wird der Funktion fn
       als Argument ubergeben.

       Kehrt die Funktion fn(arg) zuruck, so beendet sich der Kindprozess. Der
       Ganzzahlwert, der von fn zuruckgeliefert wird, entspricht dem Exit-Code
       des  Kindprozesses.  Der  Kindprozess  kann  auch  durch den expliziten
       Aufruf von exit(2) oder durch den Empfang eines fatalen Signals beendet
       werden.

       Das  Argument  kind_stack bestimmt den Ort des Stapelspeichers, der vom
       Kindprozess verwendet wird. Da der aufrufende und der Kindprozess  sich
       Speicherbereiche  teilen  konnen,  kann  der  Kindprozess nicht auf dem
       selben Stapelspeicher wie der aufrufende Prozess laufen. Der aufrufende
       Prozess  muss  daher  einen  Speicherbereich als Stapelspeicher fur den
       Kindprozess bereithalten und per  clone  einen  Zeiger  darauf  an  den
       Kindprozess  ubergeben.  Der  Stapelspeicher  wachst  (mit Ausnahme der
       PA-Prozessoren von HP) auf allen von  Linux  unterstutzten  Prozessoren
       nach  unten,  so dass kind_stack fur gewohnlich auf die oberste Adresse
       im bereitgehaltenen Speicherbereich zeigt.

       Das  niederwertige  Byte  von   schalter   enthalt   die   Nummer   des
       Beendigungssignals,  das  an  den  Elternprozess gesandt wird, wenn der
       Kindprozess endet. Falls dieses Signal als etwas  anderes  als  SIGCHLD
       angegeben  wurde,  dann muss der Elternprozess die Optionen __WALL oder
       __WCLONE angeben, wenn er mit wait(2) auf den Kindprozess wartet. Falls
       kein Signal angegeben wurde, wird dem Elternprozess nicht signalisiert,
       wenn der Kindprozess endet.

       schalter kann daruber hinaus noch durch bitweises >>Oder<<  mit  keiner
       oder  mehreren  der folgenden Konstanten verknupft werden. Dadurch wird
       festgelegt, welche Ressourcen sich Eltern- und Kindprozess teilen:

       CLONE_CHILD_CLEARTID (seit Linux 2.5.49)
              Kind-Thread-ID an der Stelle ctid im Kindspeicher loschen,  wenn
              das  Kind  existiert  und  beim  Futex  (>>fast userspace mutual
              exclusion<</schneller gegenseitiger Ausschluss im Userspace)  an
              dieser  Adresse  aufwachen lassen. Die betroffene Adresse konnte
              durch den Systemaufruf set_tid_address(2) geandert werden.  Dies
              wird von Threading-Bibliotheken benutzt.

       CLONE_CHILD_SETTID (seit Linux 2.5.49)
              Speichert die Kind-Thread-ID an der Stelle ctid im Kindspeicher

       CLONE_FILES
              Ist  CLONE_FILES  gesetzt,  teilen  sich  der aufrufende und der
              Kindprozess      ihre      Dateideskriptor-Tabellen.       Jeder
              Dateideskriptor, der im aufrufenden Prozess oder vom Kindprozess
              erzeugt wird, ist auch im anderen Prozess gultig.  Ebenso  wirkt
              sich  das  SchlieBen  eines Dateideskriptors oder das Andern der
              zugehorigen  Schalter  (benutzen   der   F_SETFD-Operation   von
              fcntl(2)) auf den anderen Prozess aus.

              Ist   CLONE_FILES   nicht  gesetzt,  erbt  der  Kindprozess  zur
              Ausfuhrungszeit von clone() eine Kopie  der  aktuell  geoffneten
              Dateideskriptoren.    (Die    kopierten   Dateideskriptoren   im
              Kindprozess   beziehen   sich   auf   die    gleichen    offenen
              Dateideskriptoren   (siehe   open(2))   wie  die  entsprechenden
              Dateideskriptoren   im   aufrufenden   Prozess.)   AnschlieBende
              Operationen,  die  Dateideskriptoren  offnen oder schlieBen bzw.
              deren Schalter andern, werden entweder vom  aufrufenden  Prozess
              oder  dem  Kindprozess  durchgefuhrt  und  betreffen  nicht  den
              jeweils anderen Prozess.

       CLONE_FS
              Ist  CLONE_FS  gesetzt,  teilen  sich  aufrufender  Prozess  und
              Kindprozess ihre Informationen uber das Dateisystem. Dazu zahlen
              der    Ort    des     Wurzelverzeichnisses,     das     aktuelle
              Arbeitsverzeichnis   und   die   Maske  der  Dateizugriffsrechte
              (umask). Jeder Aufruf von  chroot(2),  chdir(2)  oder  umask(2),
              entweder  durch  den  aufrufenden  Prozess oder den Kindprozess,
              beeinflusst auch den jeweils anderen Prozess.

              Ist CLONE_FS nicht gesetzt, arbeitet der Kindprozess von clone()
              mit  einer  Kopie  der  Dateisysteminformationen des aufrufenden
              Prozesses zur Zeit  des  clone()-Aufrufs.  Spatere  Aufrufe  von
              chroot(2),   chdir(2)  und  umask(2)  beeinflussen  den  anderen
              Prozess nicht.

       CLONE_IO (seit Linux 2.6.25)
              Ist  CLONE_FS  gesetzt,  teilt  sich  der  neue  Prozess   einen
              E/A-Kontext  mit  dem aufrufenden Prozess. Falls dieser Schalter
              nicht gesetzt ist (wie bei fork(2)), hat der neue Prozess seinen
              eigenen E/A-Kontext.

              Der   E/A-Kontext   entspricht  dem  E/A-Gultigkeitsbereich  des
              Platten-Steuerprogramms, d.h.,  welches  das  E/A-Steuerprogramm
              zur  Modellplanung  fur  E/As  des Prozesses benutzt. Falls sich
              Prozesse  den  gleichen  E/A-Kontext  teilen,  werden  sie   vom
              E/A-Steuerprogramm  als  ein einziger betrachtet. Als Konsequenz
              daraus  mussen  sie  sich  die  gleiche   Plattenzeitzugriffzeit
              teilen.  Einige  E/A-Steuerprogramme ermoglichen zwei Prozessen,
              die einen E/A-Kontext teilen, ihren Plattenzugriff zu verzahnen.
              Falls  mehrere  Prozesse  E/A  im Auftrag des gleichen Prozesses
              durchfuhren (aio_read(3) zum Beispiel),  sollten  sie  fur  eine
              bessere E/A-Leistung CLONE_IO verwenden.

              Falls  der Kernel nicht mit der Option CONFIG_BLOCK konfiguriert
              wurde, bewirkt dieser Schalter nichts.

       CLONE_NEWIPC (seit Linux 2.6.19)
              Ist CLONE_NEWIPC gesetzt, dann wird der Prozess in  einem  neuen
              IPC-Namensraum  erstellt.  Falls  dieser  Schalter nicht gesetzt
              ist, dann  wird  der  Prozess  (wie  bei  fork(2))  im  gleichen
              IPC-Namensraum  wie  der  aufrufende  Prozess  erstellt.  Dieser
              Schalter ist fur die Implementierung von Containern gedacht.

              Ein  IPC-Namensraum  besteht  aus  einer  Zusammenstellung   von
              Bezeichnern  fur  System-V-IPC-Objekte.  (Zur  Erstellung dieser
              Objekte wurden  msgctl(2),  semctl(2)  und  shmctl(2)  benutzt).
              Objekte,  die  in einem IPC-Namensraum erstellt wurden, sind fur
              alle anderen Prozesse sichtbar, die Mitglieder  des  Namensraums
              sind.  Die  Objekte  sind  jedoch  nicht fur Prozesse in anderen
              Namensraumen sichtbar.

              Wenn ein IPC-Namensraum zerstort wird,  d.h.,  wenn  der  letzte
              Prozess  im  Namensraum beendet wird, werden alle IPC-Objekte im
              Namensraum automatisch zerstort.

              Die Benutzung dieses Schalters benotigt einen  Kernel,  der  mit
              den   Optionen  CONFIG_SYSVIPC  und  CONFIG_IPC_NS  konfiguriert
              wurde,  und  erfordert,  dass  der  Prozess   privilegiert   ist
              ((CAP_SYS_ADMIN).  Dieser  Schalter kann nicht in Verbindung mit
              CLONE_SYSVSEM angegeben werden.

       CLONE_NEWNET (seit Linux 2.6.24)
              (Die  Implementierung  dieses  Schalters  wurde  erst  mit   der
              Kernel-Version 2.6.29 abgeschlossen.)

              Wenn CLONE_NEWNET gesetzt ist, dann wird der Prozess einen neuen
              Netzwerk-Namensraum  erstellt.  Falls  dieser   Schalter   nicht
              gesetzt ist, dann wird der Prozess (wie mit fork(2)) im gleichen
              Netzwerk-Namensraum wie der aufrufende Prozess erstellt.  Dieser
              Schalter ist fur die Implementierung von Containern gedacht.

              Ein   Netzwerk-Namensraum  stellt  eine  isolierte  Ansicht  des
              Netzwerk-Stapelspeichers  (Netzwerkgerateschnittstellen,   IPv4-
              und      IPv6-Protokoll-Stapelspeicher,     IP-Routing-Tabellen,
              Firewall-Regeln,    die    Verzeichnisbaume    /proc/net     und
              /sys/class/net,   Sockets,   etc.)    bereit.   Ein   physisches
              Netzwerkgerat kann in genau einem  Netzwerknamensraum  bestehen.
              Ein  virtuelles  Netzwerkgeratepaar (>>veth<<) stellt eine einer
              Pipe ahnliche Abstraktion bereit, die benutzt  werden  kann,  um
              Tunnel zwischen Netzwerk-Namensraumen aufzubauen und eine Brucke
              in ein physisches Netzwerkgerat in einem anderen  Namensraum  zu
              erstellen.

              Wenn  ein  Netzwerk-Namensraum  freigegeben  wird, d.h. wenn der
              letzte  Prozess  im  Namensraum  beendet  wird,   werden   seine
              physischen   Netzwerkgerate   zuruck   in   den   ursprunglichen
              Namensraum verschoben (nicht zum Elternprozess).

              Die Benutzung dieses Schalters benotigt einen  Kernel,  der  mit
              der   Option   CONFIG_NET_NS   konfiguriert   wurde,  und  einen
              privilegierten Prozess (CAP_SYS_ADMIN).

       CLONE_NEWNS (seit Linux 2.4.19)
              Den Kindprozess in einem neu eingehangten Namensraum starten

              Jeder Prozess >>lebt<< in einem Namensraum. Der Namensraum eines
              Prozesses    besteht    aus    den   Daten   (den   eingehangten
              Zusammenstellungen), die die  Dateihierarchie  beschreiben,  wie
              sie  von  diesem  Prozess  gesehen wird. Nach einem fork(2) oder
              clone(), bei dem der Schalter  CLONE_NEWNS  nicht  gesetzt  ist,
              >>lebt<<  der  Kindprozess  im gleichen eingehangten Namensraum,
              wie der Elternprozess. Die Systemaufrufe mount(2) und  umount(2)
              andern den eingehangten Namensraum des aufrufenden Prozesses und
              beeinflussen daher alle Prozesse im gleichen Namensraum,  jedoch
              keine Prozesse in einem anderen eingehangten Namensraum.

              Nach  einem  clone(),  bei  dem der Schalter CLONE_NEWNS gesetzt
              ist, wird der geklonte Kindprozess in einem neuen,  eingehangten
              Namensraum  gestartet,  der  mit einer Kopie des Namensraums des
              Elternprozesses initialisiert wurde.

              Nur  ein  privilegierter  Prozess  (einer  der   die   Fahigkeit
              CAP_SYS_ADMIN hat) kann den Schalter CLONE_NEWNS angeben. Es ist
              nicht erlaubt sowohl CLONE_NEWNS als auch CLONE_FS  im  gleichen
              Aufruf von clone() anzugeben.

       CLONE_NEWPID (seit Linux 2.6.24)
              Wenn  CLONE_NEWPID  gesetzt  ist, dann wird der Prozess in einem
              neuen  PID-Namensraum  erstellt.  Falls  dieser  Schalter  nicht
              gesetzt  ist  (wie  mit  fork(2)),  dann wird der Prozess in dem
              gleichen PID-Namensraum wie der aufrufende Prozess erstellt. Der
              Schalter ist fur die Implementierung von Containern gedacht.

              Ein  PID-Namensraum  stellt  eine  isolierte  Umgebung  fur PIDs
              bereit: PIDs in einem neuen Namensraum beginnen bei 1, etwa  wie
              ein  alleinstehendes  System  und  Aufrufe wie fork(2), vfork(2)
              oder clone() werden Prozesse mit PIDs erstellen,  die  innerhalb
              dieses Namensraums eindeutig sind.

              Der  erste Prozess, der in einem neuen Namensraum erstellt wird,
              d.h. der Prozess, der unter Benutzung des Schalters CLONE_NEWPID
              erstellt  wird hat die PID 1 und ist der >>init<<-Prozess dieses
              Namensraums.  Kindprozesse,  die   innerhalb   des   Namensraums
              verwaist  sind,  werden  eher  diesem  Prozess untergeordnet als
              init(8). Im Gegensatz zum traditionellen init-Prozess  kann  der
              >>init<<-Prozess eines PID-Namensraums beendet werden. Wenn dies
              geschieht, werden alle Prozesse im Namensraum beendet.

              PID-Namensraume  bilden  eine   Hierarchie.   Wenn   ein   neuer
              PID-Namensraum   erzeugt  wird,  sind  die  Prozesse  in  diesem
              Namensraum im PID-Namensraum des  Prozesses  sichtbar,  der  den
              Prozess  im  neuen  Namensraum erzeugt hat; ist entsprechend der
              Eltern-PID-Namensraum selbst Kind eines anderen PID-Namensraums,
              dann   sind  sowohl  Kind-  als  auch  Eltern-PID-Namensraum  im
              GroBeltern-Namensraum sichtbar. Umgekehrt sehen die Prozesse  im
              >>Kind<<-PID-Namensraum nicht die Prozesse im Eltern-Namensraum.
              Die Existenz einer Namensraum-Hierarchie  bedeutet,  dass  jeder
              Prozess nun mehrere PIDs haben kann: einen fur jeden Namensraum,
              in dem er sichtbar ist;  jede  dieser  PIDs  ist  innerhalb  des
              dazugehorigen  Namensraums  eindeutig. (Ein Aufruf von getpid(2)
              gibt immer die PID fur den Namensraum zuruck, in der der Prozess
              >>lebt<<.)

              Nach  dem  Erstellen  eines  neuen  Namensraums  ist  es fur den
              Kindprozess nutzlich, sein Wurzelverzeichnis zu andern und  eine
              neue  Procfs-Instanz in /proc einzuhangen, so dass Werkzeuge wie
              ps(1) korrekt  arbeiten.  (Falls  auBerdem  CLONE_NEWNS  zu  den
              Schaltern  gehort, dann ist es nicht notig das Wurzelverzeichnis
              zu andern: Eine  neue  Procfs-Instanz  kann  direkt  uber  /proc
              eingehangt werden.)

              Die  Benutzung  dieses  Schalters benotigt einen Kernel, der mit
              der  Option   CONFIG_PID_NS   konfiguriert   wurde   und   einen
              privilegierten  Prozess  (CAP_SYS_ADMIN).  Dieser  Schalter kann
              nicht zusammen mit CLONE_THREAD angegeben werden.

       CLONE_NEWUTS (seit Linux 2.6.19)
              Falls CLONE_NEWUTS gesetzt ist, erzeugt der Prozess einen  neuen
              UTS-Namensraum,   dessen   Bezeichner   durch   Duplizieren  der
              Bezeichner aus  dem  UTS-Namensraum  des  aufrufenden  Prozesses
              initialisiert  werden.  Wenn  dieser  Schalter nicht gesetzt ist
              (wie  mit  fork(2)),  dann  wird   der   Prozess   im   gleichen
              UTS-Namensraum   wie  der  aufrufende  Prozess  erzeugt.  Dieser
              Schalter ist fur die Implementierung von Containern gedacht.

              Ein UTS-Namensraum ist eine  Zusammenstellung  von  Bezeichnern,
              die  von  uname(2)  zuruckgegeben  werden;  von denen konnen der
              Domain-Name   und   der   Rechnername   durch   setdomainname(2)
              beziehungsweise  sethostname(2) geandert werden. Anderungen, die
              an Bezeichnern in einem UTS-Namensraum vorgenommen werden,  sind
              fur alle anderen Prozesse im gleichen Namensraum sichtbar, nicht
              jedoch fur Prozesse in anderen UTS-Namensraumen.

              Die Benutzung dieses Schalters setzt einen  Kernel  voraus,  der
              mit  der  Option  CONFIG_UTS_NS  konfiguriert wurde und dass der
              Prozess privilegiert ist (CAP_SYS_ADMIN).

       CLONE_PARENT (seit Linux 2.3.12)
              Falls CLONE_PARENT gesetzt ist, dann wird der Elternprozess  des
              neuen  Kindprozesses  (wie er von getppid(2) zuruckgegeben wird)
              der gleiche wie der aufrufende Prozess sein.

              Falls CLONE_PARENT nicht gesetzt ist (wie bei fork(2)), dann ist
              der Elternprozess des Kindprozesses der aufrufende Prozess.

              Beachten  Sie,  dass  dem  Elternprozess,  wie er von getppid(2)
              zuruckgegeben  wird,  signalisiert  wird  wenn  der  Kindprozess
              endet.   Wenn   also   CLONE_PARENT   gesetzt   ist,   wird  dem
              Elternprozess des aufrufenden Prozesses anstatt dem  aufrufenden
              Prozess selbst das Signal gesandt.

       CLONE_PARENT_SETTID (seit Linux 2.5.49)
              Kindprozess-Thread-ID an Stelle ptid im Eltern- und Kindspeicher
              ablegen.  (In  Linux  2.5.32-2.5.48  gab   es   einen   Schalter
              CLONE_SETTID, der das tat.)

       CLONE_PID (veraltet)
              Falls  CLONE_PID  gesetzt  ist,  wird  der  Kindprozess  mit der
              gleichen Prozess-ID wie der aufrufende  Prozess  erstellt.  Dies
              ist  gut,  um  das  System zu hacken, aber andererseits zu nicht
              viel mehr zu gebrauchen. Seit 2.3.21 konnte dieser Schalter  nur
              durch  den  Boot-Prozess angegeben werden (PID 0). Er verschwand
              in Linux 2.5.16.

       CLONE_PTRACE
              Falls CLONE_PTRACE angegeben  ist  und  der  aufrufende  Prozess
              verfolgt  wird,  dann  wird  der  Kindprozess ebenfalls verfolgt
              (siehe ptrace(2)).

       CLONE_SETTLS (seit Linux 2.5.32)
              Das Argument newtls ist der neue  TLS-Desktiptor  (Thread  Local
              Storage). (Lesen Sie set_thread_area(2).)

       CLONE_SIGHAND
              Ist  CLONE_SIGHAND  gesetzt,  teilen sich der aufrufende Prozess
              und der Kindprozess die Tabelle der Signal-Handler.  Ruft  einer
              der  beiden  Prozesse  sigaction(2) auf, um das Antwortverhalten
              auf ein Signal zu verandern, so betrifft dies auch  den  anderen
              Prozess.  Jedoch  besitzen  aufrufender  Prozess und Kindprozess
              nach wie vor getrennte Signalmasken  und  getrennte  Listen  der
              noch  ausstehenden Signale. Einzelne Signale konnten daher durch
              Aufruf  von  sigprocmask(2)  fur  einen  Prozess  geblockt  oder
              zugelassen werden ohne den anderen Prozess zu beeinflussen.

              Ist  CLONE_SIGHAND nicht gesetzt, erbt der Kindprozess durch den
              clone-Aufruf eine  Kopie  des  Signal-Handlers  vom  aufrufenden
              Prozess.  Spatere  Aufrufe  von  sigaction(2)  durch  einen  der
              Prozesse hat dann keine Auswirkung auf den anderen Prozess.

              Seit Linux 2.6.0-test6 mussen  die  schalter  auBerdem  CLONE_VM
              enthalten, falls CLONE_SIGHAND angegeben wurde.

       CLONE_STOPPED (seit Linux 2.6.0-test2)
              Falls  CLONE_STOPPED  gesetzt  ist,  ist der Kindprozess anfangs
              gestoppt (als ob ein SIGSTOP-Signal gesendet  worden  ware)  und
              muss  durch  Senden  eines  SIGCONT-Signals  wieder  aufgenommen
              werden.

              Ab Linux 2.6.25 wird dieser Schalter missbilligt. Wahrscheinlich
              wollten  Sie  ihn  niemals  benutzen, sicherlich sollten sie ihn
              nicht benutzen und bald wird er verschwinden.

       CLONE_SYSVSEM (seit Linux 2.5.10)
              Wenn CLONE_SYSVSEM gesetzt ist, dann teilen sich der Kindprozess
              und  der  aufrufende  Prozess  eine einzige Liste von Werten, um
              System-V-Semaphoren ruckgangig zu machen (siehe semop(2)). Falls
              dieser  Schalter nicht gesetzt ist, besitzt der Kindprozess eine
              eigene List zum Ruckgangig machen, die anfangs leer ist.

       CLONE_THREAD (seit Linux 2.4.0-test8)
              Falls CLONE_THREAD gesetzt ist,  wird  der  Kindprozess  in  die
              gleiche  Thread-Gruppe  wie der aufrufende Prozess platziert. Um
              den Rest der Diskussion von CLONE_THREAD leserlicher zu  machen,
              wird  der  Begriff  >>Thread<<  benutzt,  um  Bezug auf Prozesse
              innerhalb einer Thread-Gruppe zu nehmen.

              Thread-Gruppen waren ein  Leistungsmerkmal,  das  in  Linux  2.4
              hinzugefugt   wurde,  um  den  POSIX-Thread-Gedanken  von  einer
              Thread-Zusammenstellung zu unterstutzen, die sich eine  einzelne
              PID  teilt.  Intern  ist  diese  gemeinsame  PID ein sogenannter
              Thread-Gruppen-Bezeichner (TGID)  fur  die  Thread-Gruppe.  Seit
              Linux  2.4  geben  Aufrufe  von getpid(2) die TGID des Aufrufers
              zuruck.

              Die  Threads  innerhalb   einer   Gruppe   konnen   durch   ihre
              (systemweit)  einheitliche Thread-ID (TID) unterschieden werden.
              Die TID eines neuen Threads ist als Funktionsergebnis verfugbar,
              das  an  den  Aufrufenden  von  clone()  zuruckgegeben wird. Ein
              Thread kann  durch  Benutzen  von  gettid(2)  seine  eigene  TID
              erhalten.

              Wenn clone() ohne Angabe von CLONE_THREAD aufgerufen wurde, dann
              wird  der  resultierende  Thread  in  eine  neue   Thread-Gruppe
              platziert,  deren  TGID  der  TID des Threads entspricht. Dieser
              Thread ist der F"uhrer der neuen Thread-Gruppe.

              Ein neuer mit CLONE_THREAD erzeugter  Thread  hat  den  gleichen
              Elternprozess   wie   der,   der   clone()   aufruft  (d.h.  wie
              CLONE_PARENT), so dass Aufrufe von getppid(2) den gleichen  Wert
              fur  alle  Threads  in der Thread-Gruppe zuruckliefern. Wenn ein
              CLONE_THREAD-Thread endet, wird dem Thread, der ihn per  clone()
              erstellt   hat,  weder  ein  SIGCHLD-Signal  (oder  ein  anderes
              Ende-Signal) gesandt, noch kann der Status eines solchen Threads
              per  wait(2)  abgefragt  werden.  (Der Thread wird als losgel"ost
              bezeichnet.)

              Nachdem alle Threads in einer Thread-Gruppe beendet  sind,  wird
              dem   Elternprozess   ein   SIGCHLD-Signal   (oder  ein  anderes
              Ende-Signal) gesandt.

              Falls einige der Threads in einer  Thread-Gruppe  ein  execve(2)
              durchfuhren,  dann  werden  alle Threads auBer dem Thread-Fuhrer
              beendet und  das  neue  Programm  wird  im  Thread-Gruppenfuhrer
              ausgefuhrt.

              Falls einer der Threads in einer Thread-Gruppe per fork(2) einen
              Kindprozess erzeugt,  dann  kann  jeder  Thread  in  der  Gruppe
              wait(2) fur diesen Kindprozess ausfuhren.

              Seit   Linux  2.5.35  mussen  die  schalter  auch  CLONE_SIGHAND
              enthalten, wenn CLONE_THREAD angegeben wurde.

              Signale konnen an eine Thread-Gruppe als Ganzes geschickt werden
              (d.h.  einer  TGID)  unter  Benutzung  von kill(2) oder an einen
              bestimmten Thread unter Benutzung von tgkill(2).

              Signalanordnungen und Aktionen sind prozessweit: Falls ein nicht
              abgefangenes  Signal  an den Thread geschickt wird, dann wird es
              alle Mitglieder  in  der  Thread-Gruppe  beeinflussen  (beenden,
              stoppen, fortfahren, darin ignoriert werden).

              Jeder   Thread   hat  seine  eigene  Signalmaske,  wie  sie  von
              sigprocmask(2) gesetzt wird, Signale konnen  aber  entweder  fur
              den   ganzen  Prozess  anstehen  (d.h.  an  jedes  Mitglied  der
              Thread-Gruppe zu liefern sein), wenn  sie  mit  kill(2)  gesandt
              wurden  oder  fur einen einzelnen Thread, wenn sie mit tgkill(2)
              gesandt  wurden.  Ein  Aufruf  von   sigpending(2)   gibt   eine
              Signalzusammenstellung  zuruck, die eine Verbindung ausstehender
              Signale fur den ganzen Prozess und der Signale ist, die fur  den
              aufrufenden Prozess anstehen.

              Falls  kill(2) benutzt wird, um ein Signal an eine Thread-Gruppe
              zu senden und die Thread-Gruppe einen Handler fur dieses  Signal
              installiert  hat,  dann  dann  wird  der  Handler in exakt einem
              willkurlich ausgewahlten Mitglied  der  Thread-Gruppe  aufrufen,
              das  das  Signal  nicht  blockiert hat. Falls mehrere Threads in
              einer Gruppe darauf warten das gleiche Signal per sigwaitinfo(2)
              zu akzeptieren, wird der Kernel einen dieser Threads willkurlich
              auswahlen, um das per kill(2) gesandt Signal zu empfangen.

       CLONE_UNTRACED (seit Linux 2.5.46)
              Falls  CLONE_UNTRACED  angegeben  ist,  kann  ein   verfolgender
              Prozess kein CLONE_PTRACE auf diesem Kindprozess erzwingen.

       CLONE_VFORK
              Falls   CLONE_VFORK   gesetzt   ist,  wird  die  Ausfuhrung  des
              aufrufenden Prozesses aufgeschoben  bis  der  Kindprozess  seine
              virtuellen  Speicherressourcen durch Aufrufen von execve(2) oder
              _exit(2) (wie bei vfork(2)) freigibt.

              Falls CLONE_VFORK nicht gesetzt  ist,  dann  werden  sowohl  der
              aufrufende  Prozess,  als  auch  der Kindprozess nach dem Aufruf
              planbar und eine Anwendung sollte sich nicht  darauf  verlassen,
              dass die Ausfuhrung in einer speziellen Reihenfolge erfolgt.

       CLONE_VM
              Ist CLONE_VM gesetzt, laufen aufrufender Prozess und Kindprozess
              im selben Speicherbereich. Insbesondere sind Schreibzugriffe des
              aufrufenden  Prozesses oder des Kindprozesses in den gemeinsamen
              Speicher  auch  vom  anderen   Prozess   aus   sichtbar.   Zudem
              beeinflusst  jede  Veranderung der Speicher-Mappings mit mmap(2)
              oder  munmap(2)  durch  den  Kindprozess  oder  den  aufrufenden
              Prozess auch den jeweils anderen Prozess.

              Ist  CLONE_VM  nicht gesetzt, erhalt der Kindprozess eine eigene
              Kopie des Speicherbereichs des aufrufenden  Prozesses  zur  Zeit
              des  clone()-Aufrufs.  Fuhrt ein Prozess Schreibzugriffe auf den
              Speicher   oder   Anderungen   am   Dateispeicher-Mapping   aus,
              beeinflussen  diese  Operationen  nicht den jeweils anderen, wie
              bei fork(2).

   sys_clone
       Der  sys_clone-Systemaufruf  entspricht  eher  fork(2),  der  mit   der
       Ausfuhrung  des  Kindprozesses  am  Zeitpunkt  des  Aufrufs  fortfahrt.
       Folglich benotigt sys_clone nur die Argumente schalter und  kind_stack,
       die  die  gleiche  Bedeutung wie fur clone() haben. (Beachten Sie, dass
       die Reihenfolge dieser Argumente sich von clone() unterscheidet.)

       Ein weiterer Unterschied fur sys_clone besteht darin, dass das Argument
       kind_stack    Null    sein    konnte,    so   dass   in   diesem   Fall
       >>copy-on-write<<-Semantik sicherstellt, dass der Kindprozess getrennte
       Kopien   des   Stapelspeichers   erhalt,   wenn   beide   Prozesse  den
       Stapelspeicher verandern. In diesem Fall  sollte  die  Option  CLONE_VM
       nicht angegeben werden, damit es korrekt funktioniert.

       In  Linux  2.4  und fruher gab es die Argumente ptid, tls und ctid noch
       nicht.

R"UCKGABEWERT

       Bei Erfolg wird im ausgefuhrten Thread des  Aufrufenden  die  Thread-ID
       des  Kindprozesses  zuruckgegeben.  Im  Fehlerfall  wird im Kontext des
       Aufrufenden  -1  zuruckgegeben,  kein  Kindprozess  erzeugt  und  errno
       entsprechend gesetzt.

FEHLER

       EAGAIN Es laufen bereits zu viele Prozesse.

       EINVAL CLONE_SIGHAND  wurde angegeben, aber nicht CLONE_VM. (Seit Linux
              2.6.0-test6.)

       EINVAL CLONE_THREAD wurde angegeben, aber  nicht  CLONE_SIGHAND.  (Seit
              Linux 2.5.35.)

       EINVAL In   schalter   wurden  sowohl  CLONE_FS  als  auch  CLONE_NEWNS
              angegeben.

       EINVAL In schalter wurden sowohl CLONE_NEWIPC  als  auch  CLONE_SYSVSEM
              angegeben.

       EINVAL In  schalter  wurden  sowohl  CLONE_NEWPID als auch CLONE_THREAD
              angegeben.

       EINVAL Wird von clone() zuruckgegeben,  wenn  ein  Wert  von  Null  fur
              kind_stack angegeben wurde.

       EINVAL In  schalter  wurde  CLONE_NEWIPC  angegeben,  der  Kernel wurde
              jedoch nicht mit den Optionen CONFIG_SYSVIPC  und  CONFIG_IPC_NS
              konfiguriert.

       EINVAL In  schalter  wurde  CLONE_NEWNET  angegeben,  der  Kernel wurde
              jedoch nicht mit der Option CONFIG_NET_NS konfiguriert.

       EINVAL In schalter  wurde  CLONE_NEWPID  angegeben,  der  Kernel  wurde
              jedoch nicht mit der Option CONFIG_PID_NS konfiguriert.

       EINVAL In  schalter  wurde  CLONE_NEWUTS  angegeben,  der  Kernel wurde
              jedoch nicht mit der Option CONFIG_UTS konfiguriert.

       ENOMEM Es kann nicht ausreichend Speicher fur eine Aufgabenstruktur des
              Kindprozesses  reserviert  werden  oder  um  benotigte Teile vom
              Kontext des Aufrufenden zu kopieren.

       EPERM  CLONE_NEWIPC,  CLONE_NEWNET,  CLONE_NEWNS,   CLONE_NEWPID   oder
              CLONE_NEWUTS   wurde  von  einem  nicht  privilegierten  Prozess
              angegeben (Prozess ohne CAP_SYS_ADMIN).

       EPERM  CLONE_PID  wurde  von  einem  anderen  Prozess  als  Prozess   0
              angegeben.

VERSIONEN

       Es  gibt in libc5 keinen clone()-Eintrag. glibc2 stellt clone(), wie in
       dieser Handbuchseite beschrieben, zur Verfugung.

KONFORM ZU

       Die Aufrufe clone() und sys_clone  sind  Linux-spezifisch  und  sollten
       nicht in portablen Programmen benutzt werden.

ANMERKUNGEN

       In den 2.4.x-Kerneln gibt CLONE_THREAD generell dem neuen Prozess nicht
       den gleichen  Elternprozess,  wie  dem  aufrufenden  Prozess.  Fur  die
       Kernel-Versionen 2.4.7 bis 2.4.18 implizierte der Schalter CLONE_THREAD
       jedoch den Schalter CLONE_PARENT (wie in Kernel 2.6).

       Fur  eine  Weile  gab  es  CLONE_DETACHED   (eingefuhrt   in   2.5.32):
       Elternprozesse  wollen  kein  Ende-Signal  des  Kindprozesses. In 2.6.2
       verschwand  die  Notwendigkeit,  dies  zusammen  mit  CLONE_THREAD   zu
       ubergeben.  Dieser  Schalter  ist  immer noch definiert, hat aber keine
       Auswirkungen.

       Auf i386-Architekturen sollte clone() nicht durch  vsyscall  aufgerufen
       werden, aber direkt durch int $0x80.

       Auf ia64-Architekturen wird ein anderer Systemaufruf benutzt:

       int __clone2(int (*fn)(void *),
                    void *kind_stack_basis, size_t stack_groesse,
                    int schalter, void *arg, ...
                 /* pid_t *ptid, struct user_desc *tls,
                    pid_t *ctid */ );

       Der Systemaufruf __clone2() arbeitet auf die gleiche Weise wie clone(),
       auBer   dass   kind_stack_basis   auf   die   niedrigste   Adresse   im
       Stapelspeicherbereich  des  Kindprozesses  zeigt  und stack_groesse die
       GroBe des Stapelspeichers angibt, auf die kind_stack_basis zeigt.

FEHLER

       Versionen  der  GNU-C-Bibiliothek,  die  die  NPTL-Threading-Bibliothek
       enthalten,  enthalten  eine  Wrapper-Funktion  fur  getpid(2),  die die
       Zwischenspeicherung  der  PIDs  verrichtet.  Diese  Zwischenspeicherung
       beruht   auf  der  Unterstutzung  fur  clone()  im  Glibc-Wrapper,  der
       Zwischenspeicher konnte  aber  der  derzeitigen  Implementierung  unter
       Umstanden  nicht aktuell sein. Insbesondere wenn ein Signal sofort nach
       dem clone()-Aufruf an den Kindprozess gesandt wird, konnte  ein  Aufruf
       von getpid(2) in einem Signal-Handler die PID des aufrufenden Prozesses
       (des >>Elternprozesses<<) zuruckgeben,  falls  der  Clone-Wrapper  noch
       keine   Chance   hatte   den  PID-Zwischenspeicher  im  Kindprozess  zu
       aktualisieren.  (Diese  Diskussion  ignoriert  den   Fall,   dass   der
       Kindprozess  mit  CLONE_THREAD  erstellt  wurde,  in  dem getpid(2) den
       gleichen Wert im Kindprozess zuruckgeben sollte  und  im  Prozess,  der
       clone()  aufrief,  wie  sich  der Aufrufende und der Kindprozess in der
       gleichen Thread-Gruppe befinden. Das Problem des  nicht  mehr  frischen
       Zwischenspeichers  tritt  auch auf, wenn das Argument schalter CLONE_VM
       enthalt.) Um die Wahrheit zu erfahren, konnte es notig  sein  Kode  wie
       den folgenden zu verwenden:

           #include <syscall.h>

           pid_t mypid;

           mypid = syscall(SYS_getpid);

SIEHE AUCH

       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)

KOLOPHON

       Diese   Seite   ist   Teil   der  Veroffentlichung  3.32  des  Projekts
       Linux-man-pages. Eine Beschreibung des Projekts und Informationen,  wie
       Fehler     gemeldet     werden     konnen,     finden     sich    unter
       http://www.kernel.org/doc/man-pages/.

"UBERSETZUNG

       Die deutsche Ubersetzung dieser Handbuchseite wurde von  Daniel  Kobras
       <kobras@linux.de> und Chris Leick <c.leick@vollbio.de> erstellt.

       Diese  Ubersetzung  ist  Freie Dokumentation; lesen Sie die GNU General
       Public  License  Version  3  oder  neuer   bezuglich   der   Copyright-
       Bedingungen. Es wird KEINE HAFTUNG ubernommen.

       Wenn  Sie  Fehler  in  der  Ubersetzung  dieser  Handbuchseite  finden,
       schicken     Sie     bitte     eine     E-Mail     an     <debian-l10n-
       german@lists.debian.org>.