.\" -*- coding: UTF-8 -*- .\" Copyright (c) 1992 Drew Eckhardt , March 28, 1992 .\" and Copyright (c) Michael Kerrisk, 2001, 2002, 2005, 2013 .\" .\" %%%LICENSE_START(GPL_NOVERSION_ONELINE) .\" May be distributed under the GNU General Public License. .\" %%%LICENSE_END .\" .\" Modified by Michael Haardt .\" Modified 24 Jul 1993 by Rik Faith .\" Modified 21 Aug 1994 by Michael Chastain : .\" New man page (copied from 'fork.2'). .\" Modified 10 June 1995 by Andries Brouwer .\" Modified 25 April 1998 by Xavier Leroy .\" Modified 26 Jun 2001 by Michael Kerrisk .\" Mostly upgraded to 2.4.x .\" Added prototype for sys_clone() plus description .\" Added CLONE_THREAD with a brief description of thread groups .\" Added CLONE_PARENT and revised entire page remove ambiguity .\" between "calling process" and "parent process" .\" Added CLONE_PTRACE and CLONE_VFORK .\" Added EPERM and EINVAL error codes .\" Renamed "__clone" to "clone" (which is the prototype in ) .\" various other minor tidy ups and clarifications. .\" Modified 26 Jun 2001 by Michael Kerrisk .\" Updated notes for 2.4.7+ behavior of CLONE_THREAD .\" Modified 15 Oct 2002 by Michael Kerrisk .\" Added description for CLONE_NEWNS, which was added in 2.4.19 .\" Slightly rephrased, aeb. .\" Modified 1 Feb 2003 - added CLONE_SIGHAND restriction, aeb. .\" Modified 1 Jan 2004 - various updates, aeb .\" Modified 2004-09-10 - added CLONE_PARENT_SETTID etc. - aeb. .\" 2005-04-12, mtk, noted the PID caching behavior of NPTL's getpid() .\" wrapper under BUGS. .\" 2005-05-10, mtk, added CLONE_SYSVSEM, CLONE_UNTRACED, CLONE_STOPPED. .\" 2005-05-17, mtk, Substantially enhanced discussion of CLONE_THREAD. .\" 2008-11-18, mtk, order CLONE_* flags alphabetically .\" 2008-11-18, mtk, document CLONE_NEWPID .\" 2008-11-19, mtk, document CLONE_NEWUTS .\" 2008-11-19, mtk, document CLONE_NEWIPC .\" 2008-11-19, Jens Axboe, mtk, document CLONE_IO .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH CLONE 2 "12. Dezember 2016" Linux Linux\-Programmierhandbuch .SH BEZEICHNUNG clone, __clone2 \- erzeugt einen Kindprozess .SH ÜBERSICHT .nf /* Prototyp für die Glibc\-Wrapper\-Funktion */ \fB#define _GNU_SOURCE\fP \fB#include \fP \fBint clone(int (*\fP\fIfn\fP\fB)(void *), void *\fP\fIchild_stack\fP\fB,\fP \fB int \fP\fIflags\fP\fB, void *\fP\fIarg\fP\fB, … \fP \fB /* pid_t *\fP\fIptid\fP\fB, void *\fP\fInewtls\fP\fB, pid_t *\fP\fIctid\fP\fB */ );\fP /* Für den Prototyp des den rohen Systemaufrufs siehe ANMERKUNGEN */ .fi .SH BESCHREIBUNG \fBclone\fP() erzeugt auf eine ähnliche Weise wie \fBfork\fP(2) einen neuen Prozess. Diese Seite beschreibt sowohl die \fBclone\fP()\-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 \fBfork\fP(2) erlaubt \fBclone\fP(), dass der Kindprozess Teile seines Kontextes mit dem aufrufenden Prozess teilt. Dazu zählen 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 \fBCLONE_PARENT\fP.) \fBclone\fP() wird benutzt, um Threads zu implementieren: mehrere Steuer\-Threads in einem Programm, die gleichzeitig in einem gemeinsamen Speicherbereich ausgeführt werden. Wird mit \fBclone\fP() ein Kindprozess erzeugt, führt er die Funktion \fIfn\fP(\fIarg\fP) aus. (Dies ist ein Unterschied zu \fBfork\fP(2), wo die Ausführung im Kindprozess vom Punkt des \fBfork\fP(2)\-Aufrufs fortfährt.) Das Argument \fIfn\fP ist ein Zeiger auf eine Funktion, die vom Kindprozess zu Beginn seiner Ausführung abgearbeitet wird. \fIarg\fP wird der Funktion \fIfn\fP als Argument übergeben. Kehrt die Funktion \fIfn\fP(\fIarg\fP) zurück, so beendet sich der Kindprozess. Der Ganzzahlwert, der von \fIfn\fP zurückgeliefert wird, entspricht dem Exit\-Code des Kindprozesses. Der Kindprozess kann auch durch den expliziten Aufruf von \fBexit\fP(2) oder durch den Empfang eines fatalen Signals beendet werden. Das Argument \fIchild_stack\fP 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 \fBclone\fP 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 \fIchild_stack\fP für gewöhnlich auf die oberste Adresse im bereitgehaltenen Speicherbereich zeigt. Das niederwertige Byte von \fIflags\fP enthält die Nummer des \fIBeendigungssignals\fP, das an den Elternprozess gesandt wird, wenn der Kindprozess endet. Falls dieses Signal als etwas anderes als \fBSIGCHLD\fP angegeben wurde, dann muss der Elternprozess die Optionen \fB__WALL\fP oder \fB__WCLONE\fP angeben, wenn er mit \fBwait\fP(2) auf den Kindprozess wartet. Falls kein Signal angegeben wurde, wird dem Elternprozess nicht signalisiert, wenn der Kindprozess endet. \fIflags\fP 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: .TP \fBCLONE_CHILD_CLEARTID\fP (seit Linux 2.5.49) Die Kind\-Thread\-ID an der Stelle \fIctid\fP 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 \fBset_tid_address\fP(2) geändert werden. Dies wird von Threading\-Bibliotheken benutzt. .TP \fBCLONE_CHILD_SETTID\fP (seit Linux 2.5.49) Speichert die Kind\-Thread\-ID an der Stelle \fIctid\fP im Kindspeicher. Die Speicheraktion wird abgeschlossen, bevor \fBclone\fP() die Steuerung an den Benutzerraum zurückgibt. .TP \fBCLONE_FILES\fP (since Linux 2.0) Ist \fBCLONE_FILES\fP 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 \fBF_SETFD\fP\-Operation von \fBfcntl\fP(2)) auf den anderen Prozess aus. Falls sich ein Prozess eine Dateideskriptor\-Tabelle teilt und \fBexecve\fP(2) aufruft, wird seine Dateideskriptor\-Tabelle dupliziert (nicht länger geteilt). Ist \fBCLONE_FILES\fP nicht gesetzt, erbt der Kindprozess zur Ausführungszeit von \fBclone\fP() 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 \fBopen\fP(2)). .TP \fBCLONE_FS\fP (seit Linux 2.0) Ist \fBCLONE_FS\fP 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 \fBchroot\fP(2), \fBchdir\fP(2) oder \fBumask\fP(2), entweder durch den aufrufenden Prozess oder den Kindprozess, beeinflusst auch den jeweils anderen Prozess. Ist \fBCLONE_FS\fP nicht gesetzt, arbeitet der Kindprozess von \fBclone\fP() mit einer Kopie der Dateisysteminformationen des aufrufenden Prozesses zur Zeit des \fBclone\fP()\-Aufrufs. Spätere Aufrufe von \fBchroot\fP(2), \fBchdir\fP(2) und \fBumask\fP(2) beeinflussen den anderen Prozess nicht. .TP \fBCLONE_IO\fP (seit Linux 2.6.25) Ist \fBCLONE_FS\fP gesetzt, teilt sich der neue Prozess einen E/A\-Kontext mit dem aufrufenden Prozess. Falls dieser Schalter nicht gesetzt ist (wie bei \fBfork\fP(2)), hat der neue Prozess seinen eigenen E/A\-Kontext. .\" The following based on text from Jens Axboe .\" the anticipatory and CFQ scheduler .\" with CFQ and AS. 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 (\fBaio_read\fP(3) zum Beispiel), sollten sie für eine bessere E/A\-Leistung \fBCLONE_IO\fP verwenden. Falls der Kernel nicht mit der Option \fBCONFIG_BLOCK\fP konfiguriert wurde, bewirkt dieser Schalter nichts. .TP \fBCLONE_NEWCGROUP\fP (seit Linux 4.6) Erstellt den Prozess in einem neuen cgroup\-Namensraum. Falls dieser Schalter nicht gesetzt ist, dann wird (wie mit \fBfork\fP(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 \fBcgroup_namespaces\fP(7). .\" Nur ein privilegierter Prozess (\fBCAP_SYS_ADMIN\fP) kann \fBCLONE_NEWCGROUP\fP angeben. .TP \fBCLONE_NEWIPC\fP (seit Linux 2.6.19) Ist \fBCLONE_NEWIPC\fP gesetzt, dann wird der Prozess in einem neuen IPC\-Namensraum erstellt. Falls dieser Schalter nicht gesetzt ist, dann wird der Prozess (wie bei \fBfork\fP(2)) im gleichen IPC\-Namensraum wie der aufrufende Prozess erstellt. Dieser Schalter ist für die Implementierung von Containern gedacht. .\" commit 7eafd7c74c3f2e67c27621b987b28397110d643f .\" https://lwn.net/Articles/312232/ Ein IPC\-Namensraum stellt eine isolierte Ansicht von System\-V\-IPC\-Objekten (siehe \fBsvipc\fP(7)) und (seit 2.6.30) POSIX\-Nachrichtenwarteschlangen (siehe \fBmq_overview\fP(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 (\fBCAP_SYS_ADMIN\fP) kann \fBCLONE_NEWIPC\fP angeben. Dieser Schalter darf nicht zusammen mit \fBCLONE_SYSVSEM\fP angegeben werden. Weitere Informationen zu IPC\-Namensräumen finden Sie in \fBnamespaces\fP(7). .TP \fBCLONE_NEWNET\fP (seit Linux 2.6.24) (Die Implementierung dieses Schalters wurde erst ungefähr mit der Kernel\-Version 2.6.29 abgeschlossen.) Wenn \fBCLONE_NEWNET\fP gesetzt ist, dann wird der Prozess in einem neuen Netzwerk\-Namensraum erstellt. Falls dieser Schalter nicht gesetzt ist, dann wird der Prozess (wie mit \fBfork\fP(2)) im gleichen Netzwerk\-Namensraum wie der aufrufende Prozess erstellt. Dieser Schalter ist für die Implementierung von Containern gedacht. .\" FIXME . Add pointer to veth(4) page when it is eventually completed 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 \fI/proc/net\fP und \fI/sys/class/net\fP, Sockets, etc.) bereit. Ein physisches Netzwerkgerät kann in genau einem Netzwerknamensraum bestehen. Ein virtuelles Netzwerkgerätepaar (»veth«) 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 \fBnamespaces\fP(7). Nur ein privilegierter Prozess (\fBCAP_SYS_ADMIN\fP) kann \fBCLONE_NEWNET\fP angeben. .TP \fBCLONE_NEWNS\fP (seit Linux 2.4.19) Wenn der Schalter \fBCLONE_NEWNS\fP gesetzt ist, wird der geklonte Kindprozess in einem neuen, eingehängten Namensraum gestartet, der mit einer Kopie des Namensraums des Elternprozesses initialisiert wurde. Wenn \fBCLONE_NEWNS\fP nicht gesetzt ist, bleibt der Kindprozess im gleichen Namensraum wie der Elternprozess. .\" See https://lwn.net/Articles/543273/ Nur ein privilegierter Prozess (einer der die Fähigkeit \fBCAP_SYS_ADMIN\fP hat) kann den Schalter \fBCLONE_NEWNS\fP angeben. Es ist nicht erlaubt, sowohl \fBCLONE_NEWNS\fP als auch \fBCLONE_FS\fP im gleichen Aufruf von \fBclone\fP() anzugeben. Für weitere Informationen über Einhängenamensräume lesen Sie \fBnamespaces\fP(7) und \fBmount_namespaces\fP(7) .TP \fBCLONE_NEWPID\fP (seit Linux 2.6.24) .\" This explanation draws a lot of details from .\" http://lwn.net/Articles/259217/ .\" Authors: Pavel Emelyanov .\" and Kir Kolyshkin .\" .\" The primary kernel commit is 30e49c263e36341b60b735cbef5ca37912549264 .\" Author: Pavel Emelyanov Wenn \fBCLONE_NEWPID\fP gesetzt ist, dann wird der Prozess in einem neuen PID\-Namensraum erstellt. Falls dieser Schalter nicht gesetzt ist (wie mit \fBfork\fP(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 \fBnamespaces\fP(7) und \fBpid_namespaces\fP(7). Nur ein privilegierter Prozess (\fBCAP_SYS_ADMIN\fP) kann \fBCLONE_NEWPID\fP angeben. Dieser Schalter darf nicht zusammen mit \fBCLONE_THREAD\fP oder \fBCLONE_PARENT\fP angegeben werden. .TP \fBCLONE_NEWUSER\fP (Dieser Schalter hatte für \fBclone\fP() erstmals in Linux 2.6.23 eine Bedeutung, die aktuelle \fBclone\fP()\-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 \fBCLONE_NEWUSER\fP gesetzt ist, dann wird der Prozess in einem neuen Benutzer\-Namensraum erstellt. Falls dieser Schalter nicht gesetzt ist, dann wird der Prozess (wie mit \fBfork\fP(2)) im gleichen Benutzer\-Namensraum wie der aufrufende Prozess erstellt. Für weitere Informationen über Benutzernamensräume lesen Sie \fBnamespaces\fP(7) und \fBuser_namespaces\fP(7) .\" Before Linux 2.6.29, it appears that only CAP_SYS_ADMIN was needed Vor Linux 3.8 verlangte die Verwendung von \fBCLONE_NEWUSER\fP, dass der Aufrufende drei Capabilities hatte: \fBCAP_SYS_ADMIN\fP, \fBCAP_SETUID\fP und \fBCAP_SETGID\fP. Seit Linux 3.8 werden für die Erstellung eines Benutzernamensraums keine Privilegien benötigt. .\" commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71 .\" https://lwn.net/Articles/543273/ .\" The fix actually went into 3.9 and into 3.8.3. However, user namespaces .\" were, for practical purposes, unusable in earlier 3.8.x because of the .\" various filesystems that didn't support userns. Dieser Schalter kann nicht zusammen mit \fBCLONE_THREAD\fP oder \fBCLONE_PARENT\fP angegeben werden. Aus Sicherheitsgründen darf \fBCLONE_NEWUSER\fP nicht zusammen mit \fBCLONE_FS\fP angegeben werden. Weitere Informationen über Benutzer\-Namensräume finden Sie unter \fBnamespaces\fP(7). .TP \fBCLONE_NEWUTS\fP (seit Linux 2.6.19) Falls \fBCLONE_NEWUTS\fP 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 \fBfork\fP(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 \fBuname\fP(2) zurückgegeben werden; von denen können der Domain\-Name und der Rechnername durch \fBsetdomainname\fP(2) beziehungsweise \fBsethostname\fP(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 (\fBCAP_SYS_ADMIN\fP) kann \fBCLONE_NEWUTS\fP angeben. Weitere Informationen zu UTS\-Namensräumen finden Sie in \fBnamespaces\fP(7). .TP \fBCLONE_PARENT\fP (seit Linux 2.3.12) Falls \fBCLONE_PARENT\fP gesetzt ist, dann wird der Elternprozess des neuen Kindprozesses (wie er von \fBgetppid\fP(2) zurückgegeben wird) der gleiche wie der aufrufende Prozess sein. Falls \fBCLONE_PARENT\fP nicht gesetzt ist (wie bei \fBfork\fP(2)), dann ist der Elternprozess des Kindprozesses der aufrufende Prozess. Beachten Sie, dass dem Elternprozess, wie er von \fBgetppid\fP(2) zurückgegeben wird, signalisiert wird wenn der Kindprozess endet. Wenn also \fBCLONE_PARENT\fP gesetzt ist, wird dem Elternprozess des aufrufenden Prozesses anstatt dem aufrufenden Prozess selbst das Signal gesandt. .TP \fBCLONE_PARENT_SETTID\fP (seit Linux 2.5.49) Die Kindprozess\-Thread\-ID an der Stelle \fIptid\fP im Elternspeicher ablegen. (In Linux 2.5.32\-2.5.48 gab es einen Schalter \fBCLONE_SETTID\fP, der das tat.) Die Speicheraktion wird abgeschlossen, bevor \fBclone\fP() die Steuerung an den Benutzerraum zurückgibt. .TP \fBCLONE_PID\fP (veraltet) Falls \fBCLONE_PID\fP 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. Seitdem ignoriert der Kernel ihn ohne Fehler. .TP \fBCLONE_PTRACE\fP (seit Linux 2.2) Falls \fBCLONE_PTRACE\fP angegeben ist und der aufrufende Prozess verfolgt wird, dann wird der Kindprozess ebenfalls verfolgt (siehe \fBptrace\fP(2)). .TP \fBCLONE_SETTLS\fP (seit Linux 2.5.32) Der TLS (Thread Local Storage)\-Deskriptor ist auf \fInewtls\fP gesetzt. Die Interpretation von \fInewtls\fP und der resultierende Effekt ist architekturabhängig. Auf X86 ist \fInewtls\fP als ein \fIstruct user_desc *\fP interpretiert (siehe \fBset_thread_area\fP(2)). Auf X86_64 ist es der neue für das Basisregister %fs zu setzende Wert (siehe das Argument \fIARCH_SET_FS\fP von \fBarch_prctl\fP(2)). Auf Architekturen mit einem dedizierten TLS\-Register ist es der neue Wert dieses Registers. .TP \fBCLONE_SIGHAND\fP (seit Linux 2.0) Ist \fBCLONE_SIGHAND\fP gesetzt, teilen sich der aufrufende Prozess und der Kindprozess die Tabelle der Signal\-Handler. Ruft einer der beiden Prozesse \fBsigaction\fP(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. Einzelne Signale könnten daher durch Aufruf von \fBsigprocmask\fP(2) für einen Prozess geblockt oder zugelassen werden ohne den anderen Prozess zu beeinflussen. Ist \fBCLONE_SIGHAND\fP nicht gesetzt, erbt der Kindprozess durch den \fBclone\fP\-Aufruf eine Kopie des Signal\-Handlers vom aufrufenden Prozess. Spätere Aufrufe von \fBsigaction\fP(2) durch einen der Prozesse hat dann keine Auswirkung auf den anderen Prozess. Seit Linux 2.6.0\-test6 müssen die \fIflags\fP außerdem \fBCLONE_VM\fP enthalten, falls \fBCLONE_SIGHAND\fP angegeben wurde. .TP \fBCLONE_STOPPED\fP (seit Linux 2.6.0\-test2) Falls \fBCLONE_STOPPED\fP gesetzt ist, ist der Kindprozess anfangs gestoppt (als ob ein \fBSIGSTOP\fP\-Signal gesendet worden wäre) und muss durch Senden eines \fBSIGCONT\fP\-Signals wieder aufgenommen werden. .\" glibc 2.8 removed this defn from bits/sched.h Dieser Schalter war ab Linux 2.6.25 \fImissbilligt\fP und wurde in Linux 2.6.38 vollständig \fIentfernt\fP. Seitdem ignoriert der Kernel ihn ohne Fehler. Seit Linux 4.6 wird dasselbe Bit für den Schalter \fBCLONE_NEWCGROUP\fP wiederverwendet. .TP \fBCLONE_SYSVSEM\fP (seit Linux 2.5.10) Wenn \fBCLONE_SYSVSEM\fP gesetzt ist, dann teilen sich der Kindprozess und der aufrufende Prozess eine einzige Liste von System\-V\-Semaphore\-Anpassungswerten, (siehe \fBsemop\fP(2)). In diesem Fall sammelt die gemeinsame Liste \fIsemadj\fP 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 \fBunshare\fP(2) aufhört, die Liste mitzunutzen). Falls dieser Schalter nicht gesetzt ist, besitzt der Kindprozess eine separate \fIsemadj\fP\-Liste, die anfangs leer ist. .TP \fBCLONE_THREAD\fP (seit Linux 2.4.0\-test8) Falls \fBCLONE_THREAD\fP gesetzt ist, wird der Kindprozess in die gleiche Thread\-Gruppe wie der aufrufende Prozess platziert. Um den Rest der Diskussion von \fBCLONE_THREAD\fP 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 \fBgetpid\fP(2) die TGID des Aufrufers zurück. Die Threads innerhalb einer Gruppe können durch ihre (systemweit) einheitliche Thread\-ID (TID) unterschieden werden. Die TID eines neuen Threads ist als Funktionsergebnis verfügbar, das an den Aufrufenden von \fBclone\fP() zurückgegeben wird. Ein Thread kann durch Benutzen von \fBgettid\fP(2) seine eigene TID erhalten. Wenn \fBclone\fP() ohne Angabe von \fBCLONE_THREAD\fP aufgerufen wurde, dann wird der resultierende Thread in eine neue Thread\-Gruppe platziert, deren TGID der TID des Threads entspricht. Dieser Thread ist der \fIFührer\fP der neuen Thread\-Gruppe. Ein neuer mit \fBCLONE_THREAD\fP erzeugter Thread hat den gleichen Elternprozess wie der, der \fBclone\fP() aufruft (d.h. wie \fBCLONE_PARENT\fP), so dass Aufrufe von \fBgetppid\fP(2) den gleichen Wert für alle Threads in der Thread\-Gruppe zurückliefern. Wenn ein \fBCLONE_THREAD\fP\-Thread endet, wird dem Thread, der ihn per \fBclone\fP() erstellt hat, weder ein \fBSIGCHLD\fP\-Signal (oder ein anderes Ende\-Signal) gesandt, noch kann der Status eines solchen Threads per \fBwait\fP(2) abgefragt werden. (Der Thread wird als \fIlosgelöst\fP bezeichnet.) Nachdem alle Threads in einer Thread\-Gruppe beendet sind, wird dem Elternprozess ein \fBSIGCHLD\fP\-Signal (oder ein anderes Ende\-Signal) gesandt. Falls einige der Threads in einer Thread\-Gruppe ein \fBexecve\fP(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 \fBfork\fP(2) einen Kindprozess erzeugt, dann kann jeder Thread in der Gruppe \fBwait\fP(2) für diesen Kindprozess ausführen. Seit Linux 2.5.35 müssen die \fIflags\fP auch \fBCLONE_SIGHAND\fP enthalten, wenn \fBCLONE_THREAD\fP angegeben wurde. Beachten Sie auch, dass seit Linux 2.6.0\-test6 \fBCLONE_SIGHAND\fP auch \fBCLONE_VM\fP enthalten muss. Signale können an eine Thread\-Gruppe als Ganzes geschickt werden (d.h. einer TGID) unter Benutzung von \fBkill\fP(2) oder an einen bestimmten Thread unter Benutzung von \fBtgkill\fP(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 \fBsigprocmask\fP(2) gesetzt wird, Signale können aber entweder für den ganzen Prozess anstehen (d.h. an jedes Mitglied der Thread\-Gruppe zu liefern sein), wenn sie mit \fBkill\fP(2) gesandt wurden oder für einen einzelnen Thread, wenn sie mit \fBtgkill\fP(2) gesandt wurden. Ein Aufruf von \fBsigpending\fP(2) gibt eine Signalzusammenstellung zurück, die eine Verbindung ausstehender Signale für den ganzen Prozess und der Signale ist, die für den aufrufenden Prozess anstehen. Falls \fBkill\fP(2) benutzt wird, um ein Signal an eine Thread\-Gruppe zu senden 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 \fBsigwaitinfo\fP(2) zu akzeptieren, wird der Kernel einen dieser Threads willkürlich auswählen, um das per \fBkill\fP(2) gesandt Signal zu empfangen. .TP \fBCLONE_UNTRACED\fP (seit Linux 2.5.46) Falls \fBCLONE_UNTRACED\fP angegeben ist, kann ein verfolgender Prozess kein \fBCLONE_PTRACE\fP auf diesem Kindprozess erzwingen. .TP \fBCLONE_VFORK\fP (seit Linux 2.2) Falls \fBCLONE_VFORK\fP gesetzt ist, wird die Ausführung des aufrufenden Prozesses aufgeschoben bis der Kindprozess seine virtuellen Speicherressourcen durch Aufrufen von \fBexecve\fP(2) oder \fB_exit\fP(2) (wie bei \fBvfork\fP(2)) freigibt. Falls \fBCLONE_VFORK\fP 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. .TP \fBCLONE_VM\fP (seit Linux 2.0) Ist \fBCLONE_VM\fP 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 \fBmmap\fP(2) oder \fBmunmap\fP(2) durch den Kindprozess oder den aufrufenden Prozess auch den jeweils anderen Prozess. Ist \fBCLONE_VM\fP nicht gesetzt, erhält der Kindprozess eine eigene Kopie des Speicherbereichs des aufrufenden Prozesses zur Zeit des \fBclone\fP()\-Aufrufs. Führt ein Prozess Schreibzugriffe auf den Speicher oder Änderungen am Dateispeicher\-Mapping aus, beeinflussen diese Operationen nicht den jeweils anderen, wie bei \fBfork\fP(2). .SS "Unterschiede C\-Bibliothek/Kernel" Der rohe \fBsys_clone\fP\-Systemaufruf entspricht eher \fBfork\fP(2), da er mit der Ausführung des Kindprozesses am Zeitpunkt des Aufrufs fortfährt. Von daher werden die Argumente \fIfn\fP und \fIarg\fP der \fBclone\fP()\-Wrapper\-Funktion weggelassen. Zudem wird die Reihenfolge der Argumente geändert. Die rohe Schnittstelle für Systemaufrufe auf x86\-64 und einigen anderen Architekturen (darunter Sh, Tile und Alpha) sieht ungefähr so aus: .in +4 .nf \fBlong clone(unsigned long \fP\fIflags\fP\fB, void *\fP\fIchild_stack\fP\fB,\fP \fB int *\fP\fIptid\fP\fB, int *\fP\fIctid\fP\fB,\fP \fB unsigned long \fP\fInewtls\fP\fB);\fP .fi .in .\" CONFIG_CLONE_BACKWARDS 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: .in +4 .nf \fBlong clone(unsigned long \fP\fIflags\fP\fB, void *\fP\fIchild_stack\fP\fB,\fP \fB int *\fP\fIptid\fP\fB, unsigned long \fP\fInewtls\fP\fB,\fP \fB int *\fP\fIctid\fP\fB);\fP .fi .in .\" CONFIG_CLONE_BACKWARDS2 Auf der Cris\- und S30\-Architektur ist die Reihenfolge der ersten zwei Argumente gedreht: .in +4 .nf \fBlong clone(void *\fP\fIchild_stack\fP\fB, unsigned long \fP\fIflags\fP\fB,\fP \fB int *\fP\fIptid\fP\fB, int *\fP\fIctid\fP\fB,\fP \fB unsigned long \fP\fInewtls\fP\fB);\fP .fi .in .\" CONFIG_CLONE_BACKWARDS3 Auf der Microblaze\-Architektur wird ein zusätzliches Argument übergeben: .in +4 .nf \fBlong clone(unsigned long \fP\fIflags\fP\fB, void *\fP\fIchild_stack\fP\fB,\fP \fB int \fP\fIstack_size\fP\fB,\fP /* Größe des Stacks */ \fB int *\fP\fIptid\fP\fB, int *\fP\fIctid\fP\fB,\fP \fB unsigned long \fP\fInewtls\fP\fB);\fP .fi .in .\" Ein weiterer Unterschied für den rohen Systemaufruf besteht darin, dass das Argument \fIchild_stack\fP Null sein könnte, so dass in diesem Fall »copy\-on\-write«\-Semantik sicherstellt, dass der Kindprozess getrennte Kopien des Stapelspeichers erhält, wenn einer der beiden Prozesse den Stapelspeicher verändert. In diesem Fall sollte die Option \fBCLONE_VM\fP nicht angegeben werden, damit es korrekt funktioniert. .SS "Blackfin, M68k und Sparc" .\" Mike Frysinger noted in a 2013 mail: .\" these arches don't define __ARCH_WANT_SYS_CLONE: .\" blackfin ia64 m68k 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. .SS Ia64 Auf ia64 wird eine andere Schnittstelle benutzt: .nf \fBint __clone2(int (*\fP\fIfn\fP\fB)(void *), \fP \fB void *\fP\fIchild_stack_base\fP\fB, size_t \fP\fIstack_size\fP\fB,\fP \fB int \fP\fIflags\fP\fB, void *\fP\fIarg\fP\fB, … \fP \fB /* pid_t *\fP\fIptid\fP\fB, struct user_desc *\fP\fItls\fP\fB,\fP \fB pid_t *\fP\fIctid\fP\fB */ );\fP .fi .PP Der oben gezeigte Prototyp ist für die Glibc\-Wrapper\-Funktion. Die rohe Systemaufrufschnittstelle hat kein \fIfn\fP\- oder \fIarg\fP\-Argument und ändert die Reihenfolge der Argumente, so dass \fIflags\fP das erste und \fItls\fP das letzte Argument ist. .PP \fB__clone2\fP() arbeitet auf die gleiche Weise wie \fBclone\fP(), außer dass \fIchild_stack_base\fP auf die niedrigste Adresse im Stapelspeicherbereich des Kindprozesses zeigt und \fIstack_size\fP die Größe des Stapelspeichers angibt, auf die \fIchild_stack_base\fP zeigt. .SS "Linux 2.4 und früher" Unter Linux 2.4 und früher gab es die Argumente \fIptid\fP, \fItls\fP und \fIctid\fP noch nicht. .SH RÜCKGABEWERT .\" gettid(2) returns current->pid; .\" getpid(2) returns current->tgid; Bei Erfolg wird im ausgeführten Thread des Aufrufenden die Thread\-ID des Kindprozesses zurückgegeben. Im Fehlerfall wird im Kontext des Aufrufenden \-1 zurückgegeben, kein Kindprozess erzeugt und \fIerrno\fP entsprechend gesetzt. .SH FEHLER .TP \fBEAGAIN\fP Es laufen bereits zu viele Prozesse; siehe \fBfork\fP(2). .TP \fBEINVAL\fP \fBCLONE_SIGHAND\fP wurde angegeben, aber nicht \fBCLONE_VM\fP. (Seit Linux 2.6.0\-test6.) .TP \fBEINVAL\fP .\" .TP .\" .B EINVAL .\" Precisely one of .\" .B CLONE_DETACHED .\" and .\" .B CLONE_THREAD .\" was specified. .\" (Since Linux 2.6.0-test6.) \fBCLONE_THREAD\fP wurde angegeben, aber nicht \fBCLONE_SIGHAND\fP. (Seit Linux 2.5.35.) .TP \fBEINVAL\fP .\" commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71 In \fIflags\fP wurden sowohl \fBCLONE_FS\fP als auch \fBCLONE_NEWNS\fP angegeben. .TP \fBEINVAL\fP (seit Linux 3.9) In \fIflags\fP wurden sowohl \fBCLONE_NEWUSER\fP als auch \fBCLONE_FS\fP angegeben. .TP \fBEINVAL\fP In \fIflags\fP wurden sowohl \fBCLONE_NEWIPC\fP als auch \fBCLONE_SYSVSEM\fP angegeben. .TP \fBEINVAL\fP Eines (oder beides) von \fBCLONE_NEWPID\fP oder \fBCLONE_NEWUSER\fP und eines (oder beides) von \fBCLONE_THREAD\fP oder \fBCLONE_PARENT\fP wurde in \fIflags\fP angegeben. .TP \fBEINVAL\fP Wird von der Glibc\-Wrapper\-Funktion \fBclone\fP() zurückgegeben, wenn ein Wert von Null für \fIfn\fP oder \fIchild_stack\fP angegeben wurde. .TP \fBEINVAL\fP In \fIflags\fP wurde \fBCLONE_NEWIPC\fP angegeben, der Kernel wurde jedoch nicht mit den Optionen \fBCONFIG_SYSVIPC\fP und \fBCONFIG_IPC_NS\fP konfiguriert. .TP \fBEINVAL\fP In \fIflags\fP wurde \fBCLONE_NEWNET\fP angegeben, der Kernel wurde jedoch nicht mit der Option \fBCONFIG_NET_NS\fP konfiguriert. .TP \fBEINVAL\fP In \fIflags\fP wurde \fBCLONE_NEWPID\fP angegeben, der Kernel wurde jedoch nicht mit der Option \fBCONFIG_PID_NS\fP konfiguriert. .TP \fBEINVAL\fP In \fIflags\fP wurde \fBCLONE_NEWUTS\fP angegeben, der Kernel wurde jedoch nicht mit der Option \fBCONFIG_UTS\fP konfiguriert. .TP \fBEINVAL\fP \fIchild_stack\fP is not aligned to a suitable boundary for this architecture. For example, on aarch64, \fIchild_stack\fP must be a multiple of 16. .TP \fBENOMEM\fP Es kann nicht ausreichend Speicher für eine Aufgabenstruktur des Kindprozesses reserviert werden oder um benötigte Teile vom Kontext des Aufrufenden zu kopieren. .TP \fBEPERM\fP \fBCLONE_NEWIPC\fP, \fBCLONE_NEWNET\fP, \fBCLONE_NEWNS\fP, \fBCLONE_NEWPID\fP oder \fBCLONE_NEWUTS\fP wurde von einem nicht privilegierten Prozess angegeben (Prozess ohne \fBCAP_SYS_ADMIN\fP). .TP \fBEPERM\fP \fBCLONE_PID\fP wurde von einem anderen Prozess als Prozess 0 angegeben. .TP \fBEPERM\fP \fBCLONE_NEWUSER\fP was specified in \fIflags\fP, but either the effective user ID or the effective group ID of the caller does not have a mapping in the parent namespace (see \fBuser_namespaces\fP(7)). .TP \fBEPERM\fP (seit Linux 3.9) .\" commit 3151527ee007b73a0ebd296010f1c0454a919c7d .\" FIXME What is the rationale for this restriction? \fBCLONE_NEWUSER\fP wurde in \fIflags\fP 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). .TP \fBERESTARTNOINTR\fP (seit Linux 2.6.17) .\" commit 4a2c7a7837da1b91468e50426066d988050e4d56 System call was interrupted by a signal and will be restarted. (This can be seen only during a trace.) .TP \fBEUSERS\fP (seit Linux 3.11) .\" .SH VERSIONS .\" There is no entry for .\" .BR clone () .\" in libc5. .\" glibc2 provides .\" .BR clone () .\" as described in this manual page. \fBCLONE_NEWUSER\fP wurde in \fIflags\fP angegeben und der Aufruf würde dazu führen, dass die Anzahl der geschachtelten Benutzernamensräume überschritten würde. Siehe \fBuser_namespaces\fP(7). .SH "KONFORM ZU" \fBclone\fP() ist Linux\-spezifisch und sollte nicht in portierbaren Programmen benutzt werden. .SH ANMERKUNGEN The \fBkcmp\fP(2) system call can be used to test whether two processes share various resources such as a file descriptor table, System V semaphore undo operations, or a virtual address space. In der Linux 2.4.x\-Serie gibt \fBCLONE_THREAD\fP 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 \fBCLONE_THREAD\fP jedoch den Schalter \fBCLONE_PARENT\fP (wie in Kernel 2.6.0 und neuer). Für eine Weile gab es \fBCLONE_DETACHED\fP (eingeführt in 2.5.32): Elternprozesse wollen kein Ende\-Signal des Kindprozesses. In Linux 2.6.2 verschwand die Notwendigkeit, dies zusammen mit \fBCLONE_THREAD\fP zu übergeben. Dieser Schalter ist immer noch definiert, hat aber keine Auswirkungen. Auf i386\-Architekturen sollte \fBclone\fP() nicht durch vsyscall aufgerufen werden, sondern direkt durch \fIint $0x80\fP. .SH FEHLER Versionen der GNU\-C\-Bibiliothek, die die NPTL\-Threading\-Bibliothek enthalten, enthalten eine Wrapper\-Funktion für \fBgetpid\fP(2), die die Zwischenspeicherung der PIDs verrichtet. Diese Zwischenspeicherung beruht auf der Unterstützung für \fBclone\fP() im Glibc\-Wrapper, der Zwischenspeicher könnte aber der derzeitigen Implementierung unter Umständen nicht aktuell sein. Insbesondere wenn ein Signal sofort nach dem \fBclone\fP()\-Aufruf an den Kindprozess gesandt wird, könnte ein Aufruf von \fBgetpid\fP(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 \fBCLONE_THREAD\fP erstellt wurde, in dem \fBgetpid\fP(2) den gleichen Wert im Kindprozess zurückgeben \fIsollte\fP und im Prozess, der \fBclone\fP() 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 \fIflags\fP \fBCLONE_VM\fP enthält.) Um die Wahrheit zu erfahren, könnte es nötig sein, Kode wie den folgenden zu verwenden: .nf #include pid_t mypid; mypid = syscall(SYS_getpid); .fi .\" See also the following bug reports .\" https://bugzilla.redhat.com/show_bug.cgi?id=417521 .\" http://sourceware.org/bugzilla/show_bug.cgi?id=6910 .SH BEISPIEL Das folgende Programm demonstriert die Benutzung von \fBclone\fP() 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 \fBsetns\fP(2). .SS Programmquelltext .nf #define _GNU_SOURCE #include #include #include #include #include #include #include #define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \e } 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\en", 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 \en", 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\en", (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\en", uts.nodename); if (waitpid(pid, NULL, 0) == \-1) /* Warten auf Kindprozess */ errExit("waitpid"); printf("Kindprozess wurde beendet\en"); exit(EXIT_SUCCESS); } .fi .SH "SIEHE AUCH" \fBfork\fP(2), \fBfutex\fP(2), \fBgetpid\fP(2), \fBgettid\fP(2), \fBkcmp\fP(2), \fBset_thread_area\fP(2), \fBset_tid_address\fP(2), \fBsetns\fP(2), \fBtkill\fP(2), \fBunshare\fP(2), \fBwait\fP(2), \fBcapabilities\fP(7), \fBnamespaces\fP(7), \fBpthreads\fP(7) .SH KOLOPHON Diese Seite ist Teil der Veröffentlichung 4.09 des Projekts Linux\-\fIman\-pages\fP. 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/. .SH ÜBERSETZUNG Die deutsche Übersetzung dieser Handbuchseite wurde von Daniel Kobras , Chris Leick , Mario Blättermann und Helge Kreutzmann 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 .