Provided by: manpages-de-dev_2.15-1build1_all bug

BEZEICHNUNG

       clone, __clone2 - erzeugt einen Kindprozess

ÜBERSICHT

       /* Prototyp für die Glibc-Wrapper-Funktion */

       #define _GNU_SOURCE
       #include <sched.h>

       int clone(int (*fn)(void *), void *child_stack,
                 int flags, void *arg, 
                 /* pid_t *ptid, void *newtls, pid_t *ctid */ );

       /* Für den Prototyp des den rohen Systemaufrufs siehe ANMERKUNGEN */

BESCHREIBUNG

       clone() erzeugt auf eine ähnliche Weise wie fork(2) einen neuen Prozess.

       Diese  Seite  beschreibt  sowohl  die  clone()-Wrapper-Funktion  von  Glibc  als  auch den
       darunterliegenden  Systemaufruf,  auf  dem  sie  basiert.  Der   Haupttext   erklärt   die
       Wrapper-Funktion.  Die  Unterschiede zum rohen Systemaufruf werden gegen Ende dieser Seite
       erläutert.

       Im Gegensatz zu fork(2) erlaubt clone(), dass der Kindprozess Teile seines  Kontextes  mit
       dem  aufrufenden  Prozess  teilt.  Dazu  zählen  der virtuelle Adressraum, 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.)

       clone() wird  benutzt,  um  Threads  zu  implementieren:  mehrere  Steuerflüsse  in  einem
       Programm, die gleichzeitig in einem gemeinsamen Speicherbereich ausgeführt werden.

       Wird  mit  clone()  ein  Kindprozess  erzeugt,  beginnt es die Ausführung durch Aufruf der
       Funktion, auf die das Argument fn zeigt. (Dies ist ein  Unterschied  zu  fork(2),  wo  die
       Ausführung  im Kindprozess vom Punkt des fork(2)-Aufrufs fortfährt.) Das Argument arg wird
       als Argument der Funktion fn übergeben.

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

       Das  Argument  child_stack  bestimmt  den  Ort  des  Stapelspeichers,  der vom Kindprozess
       verwendet wird. Da der aufrufende und der Kindprozess sich Speicherbereiche teilen können,
       kann  der  Kindprozess  nicht  auf  dem  selben  Stapelspeicher wie der aufrufende Prozess
       laufen. Der aufrufende Prozess muss daher einen Speicherbereich als Stapelspeicher für den
       Kindprozess  bereithalten  und per clone einen Zeiger darauf an den Kindprozess übergeben.
       Der Stapelspeicher wächst (mit Ausnahme der PA-Prozessoren von HP)  auf  allen  von  Linux
       unterstützten  Prozessoren  nach unten, so dass child_stack für gewöhnlich auf die oberste
       Adresse im bereitgehaltenen Speicherbereich zeigt.

       Das niederwertige Byte von flags enthält 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.

       flags kann darüber hinaus noch  durch  bitweises  »ODER«  mit  keiner  oder  mehreren  der
       folgenden  Konstanten  verknüpft  werden.  Dadurch wird festgelegt, welche Ressourcen sich
       Eltern- und Kindprozess teilen:

       CLONE_CHILD_CLEARTID (seit Linux 2.5.49)
              Die Kind-Thread-Kennung an der Stelle ctid  im  Kindspeicher  bereinigen  (nullen),
              wenn das Kind existiert und beim Futex (»fast userspace mutual exclusion«/schneller
              gegenseitiger Ausschluss im Userspace) an  dieser  Adresse  aufwachen  lassen.  Die
              betroffene  Adresse  könnte  durch  den  Systemaufruf  set_tid_address(2)  geändert
              werden. Dies wird von Threading-Bibliotheken benutzt.

       CLONE_CHILD_SETTID (seit Linux 2.5.49)
              Speichert  die  Kind-Thread-Kennung  an  der  Stelle  ctid  im  Kindspeicher.   Die
              Speicheraktion  wird abgeschlossen, bevor clone() die Steuerung an den Benutzerraum
              im Kindprozess zurückgibt.  (Beachten  Sie,  dass  die  Speicheraktion  noch  nicht
              abgeschlossen  sein  könnte,  bevor  clone()  den  Elternprozess zurückliefert, was
              relevant wird, wenn auch der Schalter CLONE_VM eingesetzt wird.)

       CLONE_FILES (since Linux 2.0)
              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 gültig. Ebenso wirkt sich
              das  Schließen  eines  Dateideskriptors  oder  das  Ändern der zugehörigen Schalter
              (benutzen der F_SETFD-Operation von fcntl(2)) auf den anderen  Prozess  aus.  Falls
              sich  ein  Prozess  eine  Dateideskriptor-Tabelle teilt und execve(2) aufruft, wird
              seine Dateideskriptor-Tabelle dupliziert (nicht länger geteilt).

              Ist CLONE_FILES nicht gesetzt, erbt der Kindprozess zur Ausführungszeit von clone()
              eine  Kopie  der  aktuell geöffneten Dateideskriptoren. Anschließende Aktionen, die
              Dateideskriptoren öffnen oder schließen bzw. deren Schalter ändern, werden entweder
              vom  aufrufenden  Prozess oder dem Kindprozess durchgeführt und betreffen nicht den
              jeweils  anderen  Prozess.  Beachten  Sie  aber,   dass   sich   die   duplizierten
              Dateideskriptoren   im  Kind  auf  die  gleiche  offene  Dateideskription  wie  der
              korrespondierende Dateideskriptor im aufrufenden Prozess bezieht und sich daher den
              Dateiversatz und die Dateistatusschalter mit diesem teilt (siehe open(2)).

       CLONE_FS (seit Linux 2.0)
              Ist  CLONE_FS  gesetzt,  teilen  sich  aufrufender  Prozess  und  Kindprozess  ihre
              Informationen über das Dateisystem. Dazu zählen 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. Spätere Aufrufe von chroot(2), chdir(2) oder 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-Gültigkeitsbereich des  Platten-Steuerprogramms,
              d.h.  welches  das  E/A-Steuerprogramm  zur  Modellplanung  für  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 müssen sie
              sich  die  gleiche  Plattenzeitzugriffzeit   teilen.   Einige   E/A-Steuerprogramme
              ermöglichen  zwei  Prozessen, die einen E/A-Kontext teilen, ihren Plattenzugriff zu
              verzahnen. Falls mehrere Prozesse E/A im Auftrag des gleichen Prozesses durchführen
              (aio_read(3)  zum  Beispiel),  sollten  sie  für eine bessere E/A-Leistung CLONE_IO
              verwenden.

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

       CLONE_NEWCGROUP (seit Linux 4.6)
              Erstellt  den Prozess in einem neuen cgroup-Namensraum. Falls dieser Schalter nicht
              gesetzt  ist,  dann  wird  (wie  mit  fork(2))  der   Prozess   in   den   gleichen
              cgroup-Namensräumen  wie  der aufrufende Prozess erstellt. Der Schalter ist für die
              Implementierung von Containern gedacht.

              Weitere    Informationen    über    cgroup-Namensräume     finden     Sie     unter
              cgroup_namespaces(7).

              Nur ein privilegierter Prozess (CAP_SYS_ADMIN) kann CLONE_NEWCGROUP angeben.

       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 für die Implementierung von Containern gedacht.

              Ein IPC-Namensraum stellt eine isolierte Ansicht von  System-V-IPC-Objekten  (siehe
              sysvipc(7))    und    (seit    2.6.30)    POSIX-Nachrichtenwarteschlangen    (siehe
              mq_overview(7)) bereit. Das gemeinsame Merkmal  dieser  IPC-Mechanismen  ist,  dass
              IPC-Objekte durch andere Mechanismen als Dateisystempfadnamen identifiziert werden.

              Objekte,  die  in  einem  IPC-Namensraum  erstellt  wurden,  sind  für alle anderen
              Prozesse sichtbar, die Mitglieder des Namensraums sind.  Die  Objekte  sind  jedoch
              nicht für Prozesse in anderen Namensräumen sichtbar.

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

              Nur ein privilegierter Prozess (CAP_SYS_ADMIN) kann  CLONE_NEWIPC  angeben.  Dieser
              Schalter darf nicht zusammen mit CLONE_SYSVSEM angegeben werden.

              Weitere Informationen zu IPC-Namensräumen finden Sie in namespaces(7).

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

              Wenn  CLONE_NEWNET  gesetzt  ist,  dann   wird   der   Prozess   in   einem   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  für  die  Implementierung von Containern
              gedacht.

              Ein Netzwerk-Namensraum stellt eine isolierte Ansicht des  Netzwerk-Stapelspeichers
              (Netzwerkgeräteschnittstellen,     IPv4-     und     IPv6-Protokoll-Stapelspeicher,
              IP-Routing-Tabellen,   Firewall-Regeln,   die   Verzeichnisbäume   /proc/net    und
              /sys/class/net,  Sockets,  etc.) bereit. Ein physisches Netzwerkgerät kann in genau
              einem Netzwerknamensraum  bestehen.  Ein  virtuelles  Netzwerkgerätepaar  (veth(4))
              stellt  eine  einer  Pipe  ähnliche Abstraktion bereit, die benutzt werden kann, um
              Tunnel zwischen Netzwerk-Namensräumen aufzubauen und eine Brücke in ein  physisches
              Netzwerkgerät 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  Netzwerkgeräte  zurück  in  den
              ursprünglichen   Namensraum   verschoben   (nicht   zum   Elternprozess).   Weitere
              Informationen zu Netzwerk-Namensräumen finden Sie in namespaces(7).

              Nur ein privilegierter Prozess (CAP_SYS_ADMIN) kann CLONE_NEWNET angeben.

       CLONE_NEWNS (seit Linux 2.4.19)
              Wenn der Schalter CLONE_NEWNS gesetzt ist, wird der geklonte Kindprozess  in  einem
              neuen,  eingehängten  Namensraum gestartet, der mit einer Kopie des Namensraums des
              Elternprozesses initialisiert wurde. Wenn CLONE_NEWNS nicht gesetzt ist, bleibt der
              Kindprozess im gleichen Namensraum wie der Elternprozess.

              Nur ein privilegierter Prozess (einer der die Fähigkeit 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.

              Für  weitere  Informationen  über  Einhängenamensräume  lesen Sie namespaces(7) und
              mount_namespaces(7)

       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 für die Implementierung von Containern gedacht.

              Weitere   Informationen   zu  PID-Namensräumen  finden  Sie  in  namespaces(7)  und
              pid_namespaces(7).

              Nur ein privilegierter Prozess (CAP_SYS_ADMIN) kann  CLONE_NEWPID  angeben.  Dieser
              Schalter darf nicht zusammen mit CLONE_THREAD oder CLONE_PARENT angegeben werden.

       CLONE_NEWUSER
              (Dieser  Schalter  hatte  für  clone() erstmals in Linux 2.6.23 eine Bedeutung, die
              aktuelle clone()-Semantik wurde in Linux 3.5 aufgenommen und die  letzten  Anteile,
              um   Benutzernamensräume   komplett  nutzbar  zu  bekommen,  wurden  in  Linux  3.8
              aufgenommen.)

              Wenn  CLONE_NEWUSER  gesetzt  ist,  dann  wird   der   Prozess   in   einem   neuen
              Benutzer-Namensraum  erstellt.  Falls  dieser Schalter nicht gesetzt ist, dann wird
              der Prozess (wie mit fork(2)) im gleichen Benutzer-Namensraum  wie  der  aufrufende
              Prozess erstellt.

              Vor  Linux 3.8 verlangte die Verwendung von CLONE_NEWUSER, dass der Aufrufende drei
              Capabilities hatte: CAP_SYS_ADMIN, CAP_SETUID und CAP_SETGID. Seit Linux 3.8 werden
              für die Erstellung eines Benutzernamensraums keine Privilegien benötigt.

              Dieser  Schalter  kann  nicht zusammen mit CLONE_THREAD oder CLONE_PARENT angegeben
              werden. Aus Sicherheitsgründen  darf  CLONE_NEWUSER  nicht  zusammen  mit  CLONE_FS
              angegeben werden.

              Für  weitere  Informationen  über  Benutzernamensräume  lesen Sie namespaces(7) und
              user_namespaces(7).

       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  für  die  Implementierung  von
              Containern gedacht.

              Ein  UTS-Namensraum  ist  eine  Zusammenstellung  von Bezeichnern, die von uname(2)
              zurückgegeben werden; von denen können der Domain-Name und  der  Rechnername  durch
              setdomainname(2) beziehungsweise sethostname(2) geändert werden. Änderungen, die an
              Bezeichnern in einem UTS-Namensraum  vorgenommen  werden,  sind  für  alle  anderen
              Prozesse  im  gleichen  Namensraum  sichtbar,  nicht jedoch für Prozesse in anderen
              UTS-Namensräumen.

              Nur ein privilegierter Prozess (CAP_SYS_ADMIN) kann CLONE_NEWUTS angeben.

              Weitere Informationen zu UTS-Namensräumen finden Sie in namespaces(7).

       CLONE_PARENT (seit Linux 2.3.12)
              Falls CLONE_PARENT gesetzt ist, dann wird der Elternprozess des neuen Kindprozesses
              (wie  er  von getppid(2) zurückgegeben 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) zurückgegeben 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)
              Die Kindprozess-Thread-Kennung an der Stelle ptid im  Elternspeicher  ablegen.  (In
              Linux  2.5.32-2.5.48  gab  es  einen  Schalter  CLONE_SETTID,  der  das  tat.)  Die
              Speicheraktion wird abgeschlossen, bevor clone() die Steuerung an den  Benutzerraum
              zurückgibt.

       CLONE_PID (Linux 2.0 bis 2.5.15)
              Falls  CLONE_PID  gesetzt ist, wird der Kindprozess mit der gleichen Prozesskennung
              wie der aufrufende Prozess erstellt. Dies ist gut, um das System  zu  hacken,  aber
              andererseits  zu  nicht  viel  mehr  zu gebrauchen. Seit Linux 2.3.21 konnte dieser
              Schalter nur durch den Boot-Prozess  angegeben  werden  (PID  0).  Dieser  Schalter
              verschwand  in  Linux  2.5.16 komplett aus den Kernelquellen. Seitdem ignoriert der
              Kernel dieses Bit, falls es in flags festgelegt ist.

       CLONE_PTRACE (seit Linux 2.2)
              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)
              Der TLS (Thread Local Storage)-Deskriptor ist auf newtls gesetzt.

              Die Interpretation von newtls und der resultierende Effekt ist architekturabhängig.
              Auf  X86   ist   newtls   als   ein   struct   user_desc *   interpretiert   (siehe
              set_thread_area(2)).  Auf  X86-64  ist  es  der  neue  für das Basisregister %fs zu
              setzende Wert (siehe das Argument ARCH_SET_FS von arch_prctl(2)). Auf Architekturen
              mit einem dedizierten TLS-Register ist es der neue Wert dieses Registers.

       CLONE_SIGHAND (seit Linux 2.0)
              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 verändern, 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. Daher könnten
              Signale durch Aufruf von sigprocmask(2) für 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. Spätere Aufrufe von sigaction(2)
              durch einen der Prozesse hat dann keine Auswirkung auf den anderen Prozess.

              Seit  Linux 2.6.0 müssen die flags außerdem CLONE_VM enthalten, falls CLONE_SIGHAND
              angegeben wurde.

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

              Dieser Schalter  war  ab  Linux  2.6.25  missbilligt  und  wurde  in  Linux  2.6.38
              vollständig  entfernt. Seitdem ignoriert der Kernel ihn ohne Fehler. Seit Linux 4.6
              wird dasselbe Bit für den Schalter CLONE_NEWCGROUP wiederverwendet.

       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  System-V-Semaphore-Anpassungswerten,  (siehe
              semop(2)). In diesem Fall sammelt die  gemeinsame  Liste  semadj  Werte  über  alle
              Prozesse,  die  die  Liste  gemeinsam  nutzen  und Semaphore-Anpassungen werden nur
              durchgeführt, wenn der letzte Prozess, der die Liste gemeinsam nutzt, sich  beendet
              (oder  mittels  unshare(2)  aufhört,  die Liste mitzunutzen). Falls dieser Schalter
              nicht gesetzt ist, besitzt der Kindprozess eine separate semadj-Liste, die  anfangs
              leer ist.

       CLONE_THREAD (seit Linux 2.4.0)
              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 hinzugefügt  wurde,  um
              den  POSIX-Thread-Gedanken  von  einer Thread-Zusammenstellung zu unterstützen, die
              sich eine einzelne PID teilt. Intern  ist  diese  gemeinsame  PID  ein  sogenannter
              Thread-Gruppen-Bezeichner  (TGID)  für  die  Thread-Gruppe.  Seit  Linux  2.4 geben
              Aufrufe von getpid(2) die TGID des Aufrufers zurück.

              Die Threads innerhalb einer Gruppe  können  durch  ihre  (systemweit)  einheitliche
              Thread-Kennung  (TID)  unterschieden  werden.  Die  TID eines neuen Threads ist als
              Funktionsergebnis verfügbar, das an den Aufrufenden von clone() zurückgegeben 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ührer 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  für  alle  Threads  in  der  Thread-Gruppe  zurückliefern. 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öst
              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)  durchführen,  dann
              werden  alle  Threads außer dem Thread-Führer beendet und das neue Programm wird im
              Thread-Gruppenführer ausgeführt.

              Falls einer der Threads  in  einer  Thread-Gruppe  per  fork(2)  einen  Kindprozess
              erzeugt,  dann  kann  jeder  Thread  in  der  Gruppe wait(2) für diesen Kindprozess
              ausführen.

              Seit Linux 2.5.35 müssen die flags auch CLONE_SIGHAND enthalten, wenn  CLONE_THREAD
              angegeben  wurde.  Beachten  Sie  auch,  dass  seit  Linux 2.6.0 CLONE_SIGHAND auch
              CLONE_VM enthalten muss.

              Signalzuordnungen 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 von sigprocmask(2) gesetzt.

              A signal may be process-directed or thread-directed. A process-directed  signal  is
              targeted  at  a  thread  group  (i.e.,  a TGID), and is delivered to an arbitrarily
              selected thread from among those that are not blocking the signal. A signal may  be
              process  directed  because  it was generated by the kernel for reasons other than a
              hardware exception, or because  it  was  sent  using  kill(2)   or  sigqueue(3).  A
              thread-directed  signal  is  targeted at (i.e., delivered to)  a specific thread. A
              signal  may  be  thread  directed  because  it  was  sent   using   tgkill(2)    or
              pthread_sigqueue(3),  or because the thread executed a machine language instruction
              that triggered a hardware exception (e.g., invalid memory access triggering SIGSEGV
              or a floating-point exception triggering SIGFPE).

              Ein  Aufruf  von sigpending(2) liefert eine Signalmenge zurück, die die Vereinigung
              der  anhängigen  Prozess-orientierten  Signale  und  der  Signale,  die   für   den
              aufrufenden Thread anhängig sind, ist.

              Falls  ein  Prozess-orientiertes Signal an eine Thread-Gruppe ausgeliefert wird und
              die Thread-Gruppe einen Handler für dieses Signal installiert hat, dann  dann  wird
              der  Handler  in  exakt  einem  willkürlich ausgewählten 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 willkürlich auswählen, um das 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 (seit Linux 2.2)
              Falls  CLONE_VFORK  gesetzt  ist,  wird  die  Ausführung  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 Ausführung in einer speziellen Reihenfolge erfolgt.

       CLONE_VM (seit Linux 2.0)
              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 Veränderung 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,  erhält  der  Kindprozess  eine  eigene  Kopie   des
              Speicherbereichs  des aufrufenden Prozesses zur Zeit des clone()-Aufrufs. Führt ein
              Prozess Schreibzugriffe auf den Speicher oder Änderungen  am  Dateispeicher-Mapping
              aus, beeinflussen diese Operationen nicht den jeweils anderen, wie bei fork(2).

ANMERKUNGEN

       Beachten  Sie,  dass  die Glibc-Wrapperfunktion clone() einige Änderungen am Speicher, auf
       den  child_stack  zeigt,  vornimmt  (Änderungen,  um  den  Stack  korrekt  für  das   Kind
       einzurichten),  bevor  der  Systemaufruf  clone()  ausgelöst  wird. Verwenden Sie daher in
       Fällen, in denen clone() zur rekursiven Erstellung von Kindern verwandt  wird,  nicht  den
       Puffer, der für den Stack der Eltern eingesetzt wird, als Stack der Kinder.

   Unterschiede C-Bibliothek/Kernel
       Der  rohe  sys_clone-Systemaufruf  entspricht  eher  fork(2), da er mit der Ausführung des
       Kindprozesses am Zeitpunkt des Aufrufs fortfährt. Von daher werden die  Argumente  fn  und
       arg der clone()-Wrapper-Funktion weggelassen.

       Ein  weiterer  Unterschied  für  den  rohen  Systemaufruf  clone() besteht darin, dass das
       Argument child_stack NULL sein könnte, so dass in diesem Fall das Kind eine  Dublette  des
       Stacks  des  Elternprozesses  verwendet. (»Copy-on-write«-Semantik stellt sicher, dass der
       Kindprozess getrennte Kopien des Stapelspeichers erhält, wenn einer  der  beiden  Prozesse
       den  Stapelspeicher  verändert.) In diesem Fall sollte die Option CLONE_VM nicht angegeben
       werden, damit es korrekt  funktioniert.  (Falls  das  Kind  sich  aufgrund  des  Schalters
       CLONE_VM    mit    dem    Elternprozess    den    Speicher   teilt,   dann   tritt   keine
       copy-on-write-Duplizierung auf und wahrscheinlich tritt Chaos ein.

       Die Reihenfolge der Argumente unterscheidet sich auch im rohen Systemaufruf  und  es  gibt
       über  die  Architekturen  hinweg  Variationen in den Argumenten, wie dies in den folgenden
       Absätzen dargestellt wird.

       Die rohe Schnittstelle für Systemaufrufe auf  x86-64  und  einigen  anderen  Architekturen
       (darunter Sh, Tile, Ia-64 und Alpha) sieht so aus:

           long clone(unsigned long flags, void *child_stack,
                      int *ptid, int *ctid,
                      unsigned long newtls);

       Auf  x86-32  und  mehreren  anderen  häufigen  Architekturen (darunter Score, ARM, ARM 64,
       PA-RISC, Arc, Power PC, Xtensa und MIPS) ist die Reihenfolge der  letzten  zwei  Argumente
       gedreht:

           long clone(unsigned long flags, void *child_stack,
                     int *ptid, unsigned long newtls,
                     int *ctid);

       Auf der Cris- und S30-Architektur ist die Reihenfolge der ersten zwei Argumente gedreht:

           long clone(void *child_stack, unsigned long flags,
                      int *ptid, int *ctid,
                      unsigned long newtls);

       Auf der Microblaze-Architektur wird ein zusätzliches Argument übergeben:

           long clone(unsigned long flags, void *child_stack,
                      int stack_size,         /* Größe des Stacks */
                      int *ptid, int *ctid,
                      unsigned long newtls);

   Blackfin, M68k und Sparc
       Die  Konventionen der Argumentübergabe weichen auf Blackfin, M68k und Sparc von der obigen
       Beschreibung ab. Einzelheiten finden Sie in der Kernel- (und Glibc-) Quelle.

   Ia64
       Auf ia64 wird eine andere Schnittstelle benutzt:

           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 */ );

       Der oben gezeigte Prototyp ist für die Glibc-Wrapper-Funktion; für den Systemaufruf selbst
       wird  der  Prototyp  wie  folgt  beschrieben  (er  ist  identisch zum clone()-Prototyp auf
       Microblaze):

           long clone2(unsigned long flags, void *child_stack_base,
                       int stack_size,         /* Größe des Stacks */
                       int *ptid, int *ctid,
                       unsigned long tls);

       __clone2() arbeitet auf die gleiche Weise wie clone(), außer dass child_stack_base auf die
       niedrigste  Adresse  im  Stapelspeicherbereich  des Kindprozesses zeigt und stack_size die
       Größe des Stapelspeichers angibt, auf die child_stack_base zeigt.

   Linux 2.4 und früher
       Unter Linux 2.4 und früher gab es die Argumente ptid, tls und ctid noch nicht.

RÜCKGABEWERT

       Bei  Erfolg  wird  im  ausgeführten  Thread  des  Aufrufenden   die   Thread-Kennung   des
       Kindprozesses   zurückgegeben.   Im   Fehlerfall   wird  im  Kontext  des  Aufrufenden  -1
       zurückgegeben, kein Kindprozess erzeugt und errno entsprechend gesetzt.

FEHLER

       EAGAIN Es laufen bereits zu viele Prozesse; siehe fork(2).

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

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

       EINVAL CLONE_THREAD wurde festgelegt, aber der aktuelle Prozess  hatte  vorher  unshare(2)
              mit  dem  Schalter  CLONE_NEWPID  aufgerufen oder setns(2) verwandt, um sich wieder
              einem PID-Namensraum zuzuordnen.

       EINVAL In flags wurden sowohl CLONE_FS als auch CLONE_NEWNS angegeben.

       EINVAL (seit Linux 3.9)
              In flags wurden sowohl CLONE_NEWUSER als auch CLONE_FS angegeben.

       EINVAL In flags wurden sowohl CLONE_NEWIPC als auch CLONE_SYSVSEM angegeben.

       EINVAL Eines (oder beides) von CLONE_NEWPID oder CLONE_NEWUSER und eines (oder beides) von
              CLONE_THREAD oder CLONE_PARENT wurde in flags angegeben.

       EINVAL Wird  von  der Glibc-Wrapper-Funktion clone() zurückgegeben, wenn ein Wert von Null
              für fn oder child_stack angegeben wurde.

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

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

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

       EINVAL In  flags  wurde  CLONE_NEWUSER  angegeben,  der  Kernel wurde jedoch nicht mit der
              Option CONFIG_USER_NS konfiguriert.

       EINVAL In flags wurde CLONE_NEWUTS angegeben, der Kernel wurde jedoch nicht mit der Option
              CONFIG_UTS_NS konfiguriert.

       EINVAL child_stack   ist   nicht   an   einer  geeigneten  Grenze  für  diese  Architektur
              ausgerichtet. Beispielsweise muss child_stack auf Aarch64  ein  Vielfaches  von  16
              sein.

       ENOMEM Es  kann  nicht  ausreichend  Speicher  für eine Aufgabenstruktur des Kindprozesses
              reserviert werden oder um benötigte Teile vom Kontext des Aufrufenden zu kopieren.

       ENOSPC (seit Linux 3.7)
              CLONE_NEWPID wurde in flags angegeben, aber die Begrenzung der geschachtelten Tiefe
              der PID-Namensräume würde überschritten; siehe pid_namespaces(7).

       ENOSPC (seit Linux 4.9; vorher EUSERS)
              CLONE_NEWUSER  wurde  in flags angegeben und der Aufruf würde dazu führen, dass die
              Anzahl  der   geschachtelten   Benutzernamensräume   überschritten   würde.   Siehe
              user_namespaces(7).

              Von Linux 3.11 bis Linux 4.8 war der in diesem Fall diagnostizierte Fehler EUSERS.

       ENOSPC (seit Linux 4.9)
              Einer  der  Werte  in  flags  legte die Erstellung eines neuen Benutzer-Namensraums
              fest, dadurch  würde  aber  die  in  der  enstprechenden  Datei  in  /proc/sys/user
              festgelegte Begrenzung überschritten. Für weitere Details siehe namespaces(7).

       EPERM  CLONE_NEWCGROUP,   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. (Dieser Fehler
              tritt nur unter Linux 2.5.15 und früheren Versionen auf.)

       EPERM  CLONE_NEWUSER wurde in flags festgelegt, aber weder die  effektive  Benutzerkennung
              noch  die  effektive  Gruppenkennung  des  Aufrufenden  hat  eine  Abbildung in den
              Elternnamensraum (siehe user_namespaces(7)).

       EPERM (seit Linux 3.9)
              CLONE_NEWUSER  wurde  in  flags  angegeben  und  der  Aufrufende   ist   in   einer
              Chroot-Umgebung  (d.h.  das  Wurzelverzeichnis  des  Aufrufenden  passt  nicht  zum
              Wurzelverzeichnis des Einhängenahmensraums, in dem es liegt).

       ERESTARTNOINTR (seit Linux 2.6.17)
              Ein Systemaufruf wurde durch ein Signal unterbrochen und wird neu gestartet.  (Dies
              wird nur während einer Verfolgung sichtbar sein.)

       EUSERS (Linux 3.11 bis Linux 4.8)
              CLONE_NEWUSER   wurde   in  flags  angegeben  und  die  Anzahl  der  geschachtelten
              Benutzernamensräume würde überschritten. Siehe die  Diskussion  von  ENOSPC  weiter
              oben.

KONFORM ZU

       clone() ist Linux-spezifisch und sollte nicht in portierbaren Programmen benutzt werden.

ANMERKUNGEN

       Der  Systemaufruf  kcmp(2) kann zum Testen, ob zwei Prozesse sich verschiedene Ressourcen,
       wie die Dateideskriptortabelle, die Rücksetz-Aktionen der System-V-Semaphoren  oder  einen
       virtuellen Adressraum, teilen, verwandt werden.

       Handler,  die mittels pthread_atfork(3) registriert sind, werden während eines Aufrufs von
       clone() nicht ausgeführt.

       In der Linux 2.4.x-Serie gibt CLONE_THREAD generell dem neuen Prozess nicht  den  gleichen
       Elternprozess,  wie  dem  aufrufenden  Prozess.  Für 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.0 und neuer).

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

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

FEHLER

       GNU-C-Bibliotheksversionen  2.3.4 bis einschließlich 2.24 enthielten eine Wrapper-Funktion
       für getpid(2), die Zwischenspeichern von PIDs vornahm.  Dieses  Zwischenspeichern  beruhte
       auf  der  Unterstützung  in  dem  Glibc-Wrapper  von  clone(), aber Einschränkungen in der
       Implementierung bedeuteten,  dass  unter  einigen  Umständen  der  Zwischenspeicher  nicht
       aktuell  war.  Insbesondere  wenn  ein  Signal  sofort  nach  dem  clone()-Aufruf  an  den
       Kindprozess gesandt wurde, konnte ein Aufruf von getpid(2) in einem Signal-Handler die PID
       des  aufrufenden  Prozesses  (des  »Elternprozesses«) zurückgeben, 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 zurückgeben  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  flags  CLONE_VM enthält.) Um die Wahrheit zu erfahren, war es manchmal notwendig
       gewesen, Code wie den folgenden zu verwenden:

           #include <syscall.h>

           pid_t mypid;

           mypid = syscall(SYS_getpid);

       Aufgrund des Problems mit dem  nicht  mehr  frischem  Zwischenspeicher  sowie  anderen  in
       getpid(2)  bemerkten  Problemen,  wurde  die  Funktionalität des PID-Zwischenspeicherns in
       Glibc 2.25 entfernt.

BEISPIEL

       Das  folgende  Programm  demonstriert  die  Benutzung  von  clone()  zum  Erzeugen   eines
       Kindprozesses,  der  in  einem  separaten  UTS-Namensraum ausgeführt wird. Der Kindprozess
       ändert in seinem UTS-Namensraum den Rechnernamen. Dann  zeigen  sowohl  Eltern-  als  auch
       Kindprozess  den  Rechnernamen des Systems an, wodurch sichtbar wird, dass der Rechnername
       sich im UTS-Namensraum von Eltern- und Kindprozess unterscheidet.  Ein  Beispiel  für  die
       Verwendung dieses Programms finden Sie in setns(2).

   Programmquelltext
       #define _GNU_SOURCE
       #include <sys/wait.h>
       #include <sys/utsname.h>
       #include <sched.h>
       #include <string.h>
       #include <stdio.h>
       #include <stdlib.h>
       #include <unistd.h>

       #define errExit(msg)    do { perror(msg); exit(EXIT_FAILURE); \
                               } while (0)

       static int              /* Startfunktion für geklonten Kindprozess */
       childFunc(void *arg)
       {
           struct utsname uts;

           /* Rechnername im UTS-Namensraum des Kindprozesses ändern */

           if (sethostname(arg, strlen(arg)) == -1)
               errExit("sethostname");

           /* Rechnernamen abfragen und anzeigen */

           if (uname(&uts) == -1)
               errExit("uname");
           printf("uts.nodename im Kindprozess:  %s\n", uts.nodename);

           /* Der Namensraum wird für eine Weile durch Schlafen offen gehalten.
              Dies ermöglicht etwas zu experimentieren –  zum Beispiel
              kann ein weiterer Prozess dem Namensraum beitreten. */

           sleep(200);

           return 0;           /* Kindprozess wird nun beendet */
       }

       #define STACK_SIZE (1024 * 1024)    /* Stapelspeichergröße für geklonten
                                              Kindprozess */

       int
       main(int argc, char *argv[])
       {
           char *stack;                    /* Start des Stapelspeicherpuffers */
           char *stackTop;                 /* Ende des Stapelspeicherpuffers */
           pid_t pid;
           struct utsname uts;

           if (argc < 2) {
               fprintf(stderr, "Aufruf: %s <Kindprozess-Rechnername>\n", argv[0]);
               exit(EXIT_SUCCESS);
           }

           /* Stapelspeicher für Kindprozess reservieren */

           stack = malloc(STACK_SIZE);
           if (stack == NULL)
               errExit("malloc");
           stackTop = stack + STACK_SIZE;  /* Annahme, dass Stapelspeicher nach
                                              unten wächst */

           /* Es wird ein Kindprozess erzeugt, der seinen eigenen Namensraum hat.
              Der Kindprozess beginnt die Ausführung in childFunc() */

           pid = clone(childFunc, stackTop, CLONE_NEWUTS | SIGCHLD, argv[1]);
           if (pid == -1)
               errExit("clone");
           printf("clone() gab %ld zurück\n", (long) pid);

           /* Elternprozess fällt bis hierher durch */

           sleep(1);   /* gibt dem Kindprozess Zeit zum Ändern des Rechnernamens */

           /* Den Rechnernamen im UTS-Namensraum des Elternprozesses anzeigen.
              Dieser wird sich vom Rechnernamen im UTS-Namensraum des Kindprozesses
              unterscheiden. */

           if (uname(&uts) == -1)
               errExit("uname");
           printf("uts.nodename im Elternprozess: %s\n", uts.nodename);

           if (waitpid(pid, NULL, 0) == -1)    /* Warten auf Kindprozess */
               errExit("waitpid");
           printf("Kindprozess wurde beendet\n");

           exit(EXIT_SUCCESS);
       }

SIEHE AUCH

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

KOLOPHON

       Diese Seite  ist  Teil  der  Veröffentlichung  5.02  des  Projekts  Linux-man-pages.  Eine
       Beschreibung  des  Projekts,  Informationen,  wie  Fehler gemeldet werden können sowie die
       aktuelle Version dieser Seite finden sich unter https://www.kernel.org/doc/man-pages/.

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde von Daniel  Kobras  <kobras@linux.de>,
       Chris  Leick  <c.leick@vollbio.de>,  Mario Blättermann <mario.blaettermann@gmail.com>, Dr.
       Tobias Quathamer <toddy@debian.org> und Helge Kreutzmann <debian@helgefjell.de> erstellt.

       Diese Übersetzung ist Freie Dokumentation;  lesen  Sie  die  GNU  General  Public  License
       Version   3  oder  neuer  bezüglich  der  Copyright-Bedingungen.  Es  wird  KEINE  HAFTUNG
       übernommen.

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