.\" -*- coding: UTF-8 -*- .\" Copyright (c) 1992 Drew Eckhardt , March 28, 1992 .\" and Copyright (c) Michael Kerrisk, 2001, 2002, 2005, 2013, 2019 .\" .\" %%%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 "1. November 2020" Linux Linux\-Programmierhandbuch .SH BEZEICHNUNG clone, __clone2, clone3 \- erzeugt einen Kindprozess .SH ÜBERSICHT .nf /* Prototyp für die Glibc\-Wrapper\-Funktion */ .PP \fB#define _GNU_SOURCE\fP \fB#include \fP .PP \fBint clone(int (*\fP\fIfn\fP\fB)(void *), void *\fP\fIStapel\fP\fB, int \fP\fISchalter\fP\fB, void *\fP\fIarg\fP\fB, …\fP \fB /* pid_t *\fP\fIEltern_tid\fP\fB, void *\fP\fItls\fP\fB, pid_t *\fP\fIKind_tid\fP\fB */ );\fP .PP /* Für den Prototyp des rohen clone()\-Systemaufrufs siehe ANMERKUNGEN */ .PP \fBlong clone3(struct clone_args *\fP\fIcl_args\fP\fB, size_t \fP\fIsize\fP\fB);\fP .fi .PP \fIHinweis:\fP Es gibt noch keinen Glibc\-Wrapper für \fBclone3\fP(); siehe ANMERKUNGEN. .SH BESCHREIBUNG Diese Systemaufrufe erzeugen auf eine ähnliche Weise wie \fBfork\fP(2) einen neuen Prozess (»Kind«). .PP Im Gegensatz zu \fBfork\fP(2) bieten diese Systemaufrufe eine genauere Kontrolle darüber, welche Teile des Ausführungskontextes vom aufrufenden und vom Kindprozess gemeinsam benutzt werden. Beispielsweise kann der Aufrufende mittels dieser Systemaufrufe steuern, ob die zwei Prozesse den virtuellen Adressraum, die Tabelle der Dateideskriptoren und die Tabelle der Signal\-Handler gemeinsam benutzen. Diese Systemaufrufe ermöglichen es auch, den neuen Kindprozess in einen separaten Namensraum (siehe \fBnamespaces\fP(7)) abzulegen. .PP Beachten Sie, dass in dieser Handbuchseite der »aufrufende Prozess« normalerweise der »Elternprozess« ist. Siehe aber auch die nachfolgende Beschreibung von \fBCLONE_PARENT\fP und \fBCLONE_THREAD\fP. .PP Diese Seite beschreibt die folgenden Schnittstellen: .IP * 3 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. .IP * Der neuere Systemaufruf \fBclone3\fP(). .PP .\" Im Rest der Seite wird die Terminologie »der Clone\-Aufruf« verwandt, wenn Details erklärt werden, die auf alle diese Schnittstellen zutreffen. .SS "Die clone()\-Wrapper\-Funktion" Wird mit der \fBclone\fP()\-Wrapper\-Funktion ein Kindprozess erzeugt, beginnt es die Ausführung durch Aufruf der Funktion, auf die das Argument \fIfn\fP zeigt. (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 \fIarg\fP wird als Argument der Funktion \fIfn\fP übergeben. .PP 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\-Status des Kindprozesses. Der Kindprozess kann auch durch den expliziten Aufruf von \fBexit\fP(2) oder durch den Empfang eines fatalen Signals beendet werden. .PP Das Argument \fIStapel\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 \fIStapel\fP für gewöhnlich auf die oberste Adresse im bereitgehaltenen Speicherbereich zeigt. Beachten Sie, dass \fBclone\fP() keine Möglichkeit bereitstellt, mit der der Aufrufende den Kernel über die Größe des Stapel\-Bereichs informieren könnte. .PP .\" Die verbliebenen Argumente für \fBclone\fP() werden unten behandelt. .SS clone3() Der Systemaufruf \fBclone3\fP() stellt eine Obermenge der Funktionalität der älteren Schnittstelle \fBclone\fP() bereit. Er stellt auch eine Reihe von API\-Verbesserungen bereit, einschließlich: Platz für zusätzliche Schalter\-Bits; deutlichere Trennung beim Einsatz der verschiedenen Argumente, die Möglichkeit, die Größe des Stapel\-Bereichs des Kindprozesses festzulegen. .PP Wie bei \fBfork\fP(2) kehrt \fBclone3\fP() sowohl im Eltern\- als auch im Kindprozess zurück. Er liefert 0 im Kindprozess und die PID des Kindprozesses im Elternprozess zurück. .PP Das Argument \fIcl_args\fP von \fBclone3\fP() ist eine Struktur der folgenden Form: .PP .in +4n .EX struct clone_args { u64 flags; /* Schalter\-Bit\-Maske */ u64 pidfd; /* Wo der PID\-Dateideskriptor gespeichert werden soll (\fIpid_t *\fP) */ u64 child_tid; /* Wo die Kind\-TID gespeichert werden soll, im Speicher des Kindes (\fIpid_t *\fP) */ u64 parent_tid; /* Wo die Kind\-TID gespeichert werden soll, im Speicher des Elternprozesses (\fIint *\fP) */ u64 exit_signal; /* Beim Beenden des Kindprozesses an den Elternprozess zu sendendes Signal */ u64 stack; /* Zeiger auf das niedrigste Byte des Stapels */ u64 stack_size; /* Größe des Stapels */ u64 tls; /* Ort eines neuen TLS */ u64 set_tid; /* Zeiger auf ein \fIpid_t\fP\-Feld (seit Linux 5.5) */ u64 set_tid_size; /* Anzahl von Elementen in \fIset_tid\fP (seit Linux 5.5) */ u64 cgroup; /* Dateideskriptor für Ziel\-Cgroup eines Kindes (seit Linux 5.7) */ }; .EE .in .PP Das an \fBclone3\fP() übergebene Argument \fIsize\fP sollte auf die Größe dieser Struktur initialisiert werden. (Die Existenz des Arguments \fIsize\fP ermöglicht zukünftige Erweiterungen der \fIclone_args\fP\-Struktur.) .PP Der Stapel für den Kindprozess wird in \fIcl_args.stack\fP, der auf das niedrigste Byte des Stapel\-Bereichs zeigt, und \fIcl_args.stack_size\fP, der die Größe des Stapel\-Bereichs in Byte festlegt, angegeben. Falls der Schalter \fBCLONE_VM\fP (siehe unten) angegeben ist, muss ein Stapel explizit reserviert und festgelegt werden. Andernfalls können diese Felder als NULL und 0 angegeben werden, wodurch der Kindprozess den gleichen Stapel\-Bereich wie der Elternprozess verwendet (im eigenen virtuellen Adressraum des Kindprozesses). .PP .\" Die verbliebenen Felder im Argument \fIcl_args\fP werden unten behandelt. .SS "Äquivalenz zwischen den Argumenten von clone() und clone3()" Anders als die ältere \fBclone\fP()\-Schnittstelle, bei der die Argumente individuell übergeben werden, werden die Argumente bei der neueren \fBclone3\fP()\-Schnittstelle in die oben gezeigte Struktur \fIclone_args\fP gepackt. Diese Struktur erlaubt es, dass eine Obermenge an Informationen über die \fBclone\fP()\-Argumente übergeben wird. .PP Die folgende Tabelle zeigt die Äquivalenz zwischen den Argumenten von \fBclone\fP() und den Feldern in den an \fBclone3\fP() übergebenen \fIclone_args\fP: .RS .TS lb lb lb l l l li li l. clone() clone3() Hinweise Feld \fIcl_args\fP Schalter & \(ti0xff flags Für die meisten Schalter; Details unten parent_tid pidfd Siehe CLONE_PIDFD child_tid child_tid Siehe CLONE_CHILD_SETTID parent_tid parent_tid Siehe CLONE_PARENT_SETTID Schalter & 0xff exit_signal Stapel Stapel \fI\-\-\-\fP stack_size tls tls Siehe CLONE_SETTLS \fI\-\-\-\fP set_tid Siehe weiter unten für Details. \fI\-\-\-\fP set_tid_size \fI\-\-\-\fP cgroup Siehe CLONE_INTO_CGROUP .TE .RE .\" .SS "Das Kind\-Beendigungssignal" .\" Wenn sich der Kindprozess beendet, kann ein Signal an den Elternprozess gesandt werden. Das Beendigungssignal wird in den niedrigen Bytes von \fISchalter\fP (\fBclone\fP()) oder in \fIcl_args.exit_signal\fP (\fBclone3\fP()) angegeben. 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 (d.h. Null) angegeben wurde, wird dem Elternprozess nicht signalisiert, wenn der Kindprozess endet. .SS "Das Feld set_tid" Standardmäßig wählt der Kernel die nächste sequenzielle PID für den neuen Prozess in jedem der PID\-Namensräume, in denen er vorhanden ist. Beim Erstellen eines Prozesses mit \fBclone3\fP() kann das (seit Linux 5.5 verfügbare) Feld \fIset_tid\fP zur Auswahl bestimmter PIDs für den Prozess in einem oder allen der PID\-Namensräume, in denen er vorhanden ist, eingesetzt werden. Falls die PID des neu erstellten Prozesses nur im aktuellen PID\-Namensraum oder in dem neu erstellten PID\-Namensraum (falls \fISchalter\fP \fBCLONE_NEWPID\fP enthält) gesetzt werden soll, dann muss das erste Element in dem Feld \fIset_tid\fP auf die gewünschte PID gesetzt werden und \fIset_tid_size\fP muss 1 sein. .PP Falls die PID des neu erstellten Prozesses einen bestimmten Wert in mehreren PID\-Namensräumen haben soll, dann kann dass Feld \fIset_tid\fP über mehrere Einträge verfügen. Der erste Eintrag definiert die PID im am tiefsten verschachtelten PID\-Namensraum und jeder der nachfolgenden Einträge enthält die PID in dem entsprechenden Vorfahren\-PID\-Namensraum. Die Anzahl der PID\-Namensräume in denen eine PID gesetzt werden soll, wird mit \fIset_tid_size\fP gesetzt; dieser Wert kann nicht größer als die Anzahl der derzeit verschachtelten PID\-Namensräume sein. .PP Um einen Prozess zu erzeugen, der die nachfolgenden PIDs in einem PID\-Namensraum hat: .RS .TS lb lb lb l l l. PID\-NS\-Stufe Angeforderte PID Hinweise 0 31496 Äußerster PID\-Namensraum 1 42 2 7 Innerster PID\-Namensraum .TE .RE .PP Setzen Sie das Feld auf: .PP .in +4n .EX set_tid[0] = 7; set_tid[1] = 42; set_tid[2] = 31496; set_tid_size = 3; .EE .in .PP Falls nur die PIDs in den zwei innersten PID\-Namensräumen festgelegt werden müssen, setzen Sie das Feld auf: .PP .in +4n .EX set_tid[0] = 7; set_tid[1] = 42; set_tid_size = 2; .EE .in .PP Die PID in den PID\-Namensräumen außerhalb der zwei innersten PID\-Namensräume wird genauso wie jede andere PID ausgewählt. .PP .\" commit 124ea650d3072b005457faed69909221c2905a1f .\" commit 1caef81da05a84a40dbf02110e967ce6d1135ff6 Die Funktionalität \fIset_tid\fP benötigt \fBCAP_SYS_ADMIN\fP oder (seit Linux 5.9) \fBCAP_CHECKPOINT_RESTORE\fP in allen Benutzernamensräumen, die dem des Ziel\-PID\-Namensraumes gehören. .PP .\" Aufrufende dürfen in einem gegebenen PID\-Namensraum nur eine PID größer als 1 auswählen, falls ein \fBinit\fP\-Prozess (d.h. ein Prozess mit der PID 1) in diesem Namensraum bereits existiert. Andernfalls muss der PID\-Eintrag für diesen PID\-Namensraum 1 sein. .SS "Die Schaltermaske" Sowohl \fBclone\fP() als auch \fBclone3\fP() erlauben eine Schalter\-Bit\-Maske, die das Verhalten verändert und dem Aufrufenden festzulegen erlaubt, was von dem aufrufenden Prozess und dem Kindprozess gemeinsam benutzt wird. Diese Bitmaske\(emdas Argument \fISchalter\fP von \fBclone\fP() oder das an \fBclone3\fP() übergebene Feld \fIcl_args.flags\fP\(emwird im Rest dieser Handbuchseite als die \fISchalter\fP\-Maske bezeichnet. .PP Die \fISchalter\fP\-Maske wird als bitweises ODER von Null oder mehreren der oben aufgeführten Konstanten angegeben. Falls nicht unten anders angegeben, sind diese Schalter sowohl in \fBclone\fP() als auch \fBclone3\fP() verfügbar (und haben die gleiche Wirkung). .TP \fBCLONE_CHILD_CLEARTID\fP (seit Linux 2.5.49) Die Kind\-Thread\-Kennung an der durch \fIKind_tid\fP gezeigten Stelle (\fBclone\fP()) oder \fIcl_args.child_tid\fP (\fBclone3\fP()) im Kindspeicher bereinigen (nullen), wenn das Kind sich beendet 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\-Kennung an der Stelle, auf die \fIKind_tid\fP (\fBclone\fP()) oder \fIcl_args.child_tid\fP (\fBclone3\fP()) zeigt, im Kindspeicher. Die Speicheraktion wird abgeschlossen, bevor der Clone\-Aufruf die Steuerung an den Benutzerraum im Kindprozess zurückgibt. (Beachten Sie, dass die Speicheraktion noch nicht abgeschlossen sein könnte, bevor der Clone\-Aufruf den Elternprozess zurückliefert, was relevant wird, wenn auch der Schalter \fBCLONE_VM\fP eingesetzt wird.) .TP \fBCLONE_CLEAR_SIGHAND\fP (seit Linux 5.5) .\" commit b612e5df4587c934bd056bf05f4a1deca4de4f75 Standardmäßig sind die Signal\-Zuordnungen im Kind\-Thread identisch zu denen im Eltern\-Prozess. Falls dieser Schalter angegeben ist, dann werden alle Signale, die im Eltern\-Prozess gehandhabt werden, im Kind\-Thread auf ihre Standardzuordnung (\fBSIG_DFL\fP) zurückgesetzt. .IP Es ergibt keinen Sinn, diesen Schalter zusammen mit \fBCLONE_SIGHAND\fP anzugeben; daher ist diese Kombination nicht erlaubt. .TP \fBCLONE_DETACHED\fP (historisch) .\" added in 2.5.32; removed in 2.6.0-test4 Eine Zeit lang (während der Linux\-2.5\-Entwicklungsserie) gab es einen Schalter \fBCLONE_DETACHED\fP, der dazu führte, dass der Elternprozess kein Signal empfing, wenn sich das Kind beendete. Schließlich wurde die Auswirkung dieses Schalters in dem Schalter \fBCLONE_THREAD\fP mit aufgenommen und zum Zeitpunkt der Veröffentlichung von Linux 2.6.0 hatte dieser Schalter keine Auswirkung. Beginnend mit Linux 2.6.2 verschwand die Notwendigkeit, diesen Schalter mit \fBCLONE_THREAD\fP zusammen anzugeben. .IP Dieser Schalter ist noch definiert, wird aber beim Aufruf von \fBclone\fP() normalerweise ignoriert. Siehe allerdings die Beschreibung von \fBCLONE_PIDFD\fP für einige Ausnahmen. .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). .IP Ist \fBCLONE_FILES\fP 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 \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. .IP Ist \fBCLONE_FS\fP nicht gesetzt, arbeitet der Kindprozess mit einer Kopie der Dateisysteminformationen des aufrufenden Prozesses zur Zeit des Clone\-Aufrufs. Spätere Aufrufe von \fBchroot\fP(2), \fBchdir\fP(2) oder \fBumask\fP(2) beeinflussen den anderen Prozess nicht. .TP \fBCLONE_INTO_CGROUP\fP (seit Linux 5.7) .\" commit ef2c41cf38a7559bbf91af42d5b6a4429db8fc68 Standardmäßig wird ein Kindprozess in die gleiche Version\-2\-Cgroup wie sein Elternprozess abgelegt. Der Schalter \fBCLONE_INTO_CGROUP\fP ermöglicht es, den Kindprozess in einer anderen Version\-2\-Cgroup zu erstellen. (Beachten Sie, dass \fBCLONE_INTO_CGROUP\fP nur für Version\-2\-Cgroups wirksam wird.) .IP Um den Kindprozess in eine andere Cgroup abzulegen, legt der Aufrufende \fBCLONE_INTO_CGROUP\fP in \fIcl_args.flags\fP fest und übergibt im Feld \fIcl_args.cgroup\fP einen Dateideskriptor, der sich auf eine Version\-2\-Cgroup bezieht. (Dieser Dateideskriptor kann erhalten werden, indem ein Cgroup\-v2\-Verzeichnis mittels des Schalters \fBO_RDONLY\fP oder \fBO_PATH\fP geöffnet wird.) Beachten Sie, dass sämtliche übliche Einschränkungen (beschrieben in \fBcgroups\fP(7)) über das Ablegen eines Prozesses in einer Version\-2\-Cgroup gültig bleiben. .IP Folgende Anwendungsfälle für \fBCLONE_INTO_CGROUP\fP sind unter anderen möglich: .RS .IP * 3 Das Erzeugen eines Prozesses in einer Cgroup, die sich von der des Elternprozesses unterscheidet, ermöglicht es einem Diensteverwalter, neue Dienste direkt in dedizierte Cgroups zu erzeugen. Dies beseitigt das Flackern bei der Buchführung, das erzeugt würde, falls der Kindprozess erst in der gleichen Cgroup wie der Elternprozess erzeugt und dann in die Ziel\-Cgroup verschoben würde. Desweiteren ist die Erzeugung des Kindprozesses direkt in der Ziel\-Cgroup deutlich billiger als das Verschieben des Kindprozesses in die Ziel\-Cgroup, nachdem er erstellt wurde. .IP * Der Schalter \fBCLONE_INTO_CGROUP\fP erlaubt auch die Erstellung eingefrorener Kindprozesse durch Erzeugung dieser in einer eingefrorenen Cgroup. (Siehe \fBcgroups\fP(7) für eine Beschreibung des Einfrier\-Controllers.) .IP * Für Anwendungen mit Threads (oder sogar Thread\-Implementierungen, die Cgroups verwenden, um einzelne Threads zu begrenzen) ist es möglich, ein festes Cgroup\-Layout zu errichten, bevor jeder Thread direkt in seine Ziel\-Cgroup erzeugt wird. .RE .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. .IP .\" 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\-Schedulers, d.h. welches der E/A\-Scheduler zur Modellplanung für E/As des Prozesses benutzt. Falls sich Prozesse den gleichen E/A\-Kontext teilen, werden sie vom E/A\-Scheduler als ein einziger betrachtet. Als Konsequenz daraus müssen sie sich die gleiche Plattenzeitzugriffzeit teilen. Einige E/A\-Scheduler 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. .IP Falls der Kernel nicht mit der Option \fBCONFIG_BLOCK\fP konfiguriert wurde, bewirkt dieser Schalter nichts. .TP \fBCLONE_NEWCGROUP\fP (seit Linux 4.6) Der Prozess wird in einem neuen cgroup\-Namensraum erstellt. Falls dieser Schalter nicht gesetzt ist, dann wird der Prozess (wie mit \fBfork\fP(2)) im gleichen cgroup\-Namensraum wie der aufrufende Prozess erstellt. .IP Weitere Informationen über cgroup\-Namensräume finden Sie unter \fBcgroup_namespaces\fP(7). .IP .\" Nur ein privilegierter Prozess (\fBCAP_SYS_ADMIN\fP) kann \fBCLONE_NEWCGROUP\fP angeben. .TP \fBCLONE_NEWIPC\fP (seit Linux 2.6.19) Wenn \fBCLONE_NEWIPC\fP gesetzt ist, dann wird der Prozess in einem neuen IPC\-Namensraum erstellt. Falls dieser Schalter nicht gesetzt ist, dann wird der Prozess (wie mit \fBfork\fP(2)) im gleichen IPC\-Namensraum wie der aufrufende Prozess erstellt. .IP Weitere Informationen zu IPC\-Namensräumen finden Sie in \fBipc_namespaces\fP(7). .IP Nur ein privilegierter Prozess (\fBCAP_SYS_ADMIN\fP) kann \fBCLONE_NEWIPC\fP angeben. Dieser Schalter darf nicht zusammen mit \fBCLONE_SYSVSEM\fP angegeben werden. .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.) .IP 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. .IP Weitere Informationen zu Netzwerk\-Namensräumen finden Sie in \fBnetwork_namespaces\fP(7). .IP 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. .IP Für weitere Informationen über Einhängenamensräume lesen Sie \fBnamespaces\fP(7) und \fBmount_namespaces\fP(7) .IP .\" 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 Clone anzugeben. .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, dann wird der Prozess (wie mit \fBfork\fP(2)) im gleichen PID\-Namensraum wie der aufrufende Prozess erstellt. .IP Weitere Informationen zu PID\-Namensräumen finden Sie in \fBnamespaces\fP(7) und \fBpid_namespaces\fP(7). .IP 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.) .IP 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. .IP Für weitere Informationen über Benutzernamensräume lesen Sie \fBnamespaces\fP(7) und \fBuser_namespaces\fP(7). .IP .\" 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. .IP .\" 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. .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. .IP Weitere Informationen zu UTS\-Namensräumen finden Sie in \fButs_namespaces\fP(7). .IP Nur ein privilegierter Prozess (\fBCAP_SYS_ADMIN\fP) kann \fBCLONE_NEWUTS\fP angeben. .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. .IP Falls \fBCLONE_PARENT\fP nicht gesetzt ist (wie bei \fBfork\fP(2)), dann ist der Elternprozess des Kindprozesses der aufrufende Prozess. .IP 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. .IP Der Schalter \fBCLONE_PARENT\fP kann in Clone\-Aufrufen durch den globalen Init\-Prozess (PID 1 im anfänglichen PID\-Namensraum) und in Init\-Prozessen in anderen PID\-Namensräumen nicht verwandt werden. Diese Einschränkung verhindert die Erstellung von Prozessbäumen mit mehreren Wurzeln sowie die Erstellung von nicht zerstörbaren Zombies im anfänglichen PID\-Namensraum. .TP \fBCLONE_PARENT_SETTID\fP (seit Linux 2.5.49) Die Kindprozess\-Thread\-Kennung an der Stelle im Elternspeicher ablegen, auf die \fIEltern_tid\fP (\fBclone\fP()) oder \fIcl_args.parent_tid\fP (\fBclone3\fP()) zeigt. (In Linux 2.5.32\-2.5.48 gab es einen Schalter \fBCLONE_SETTID\fP, der das tat.) Die Speicheraktion wird abgeschlossen, bevor der Clone\-Aufruf die Steuerung an den Benutzerraum zurückgibt. .TP \fBCLONE_PID\fP (Linux 2.0 bis 2.5.15) Falls \fBCLONE_PID\fP 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 festgelegt werden (PID 0). Dieser Schalter verschwand in Linux 2.5.16 komplett aus den Kernelquellen. In der Folge ignorierte der Kernel dieses Bit, falls es in der \fISchalter\fP\-Maske angegeben wurde. Viel später wurde das Bit für die Verwendung als Schalter \fBCLONE_PIDFD\fP recyclet. .TP \fBCLONE_PIDFD\fP (seit Linux 5.2) .\" commit b3e5838252665ee4cfa76b82bdf1198dca81e5be Falls dieser Schalter angegeben ist, wird ein PID\-Dateideskriptor, der sich auf einen Kindprozess bezieht, reserviert und an dem angegebenen Ort im Speicher des Elternprozesses abgelegt. Der Schalter »close\-on\-exec« wird bei diesem neuen Dateideskriptor gesetzt. PID\-Dateideskriptoren können für die in \fBpidfd_open\fP(2) beschriebenen Zwecke verwandt werden. .RS .IP * 3 Bei der Verwendung von \fBclone3\fP() wird der PID\-Dateideskriptor an dem durch \fIcl_args.pidfd\fP angezeigten Ort abgelegt. .IP * Bei der Verwendung von \fBclone\fP() wird der PID\-Dateideskriptor an dem Ort abgelegt, auf den \fIEltern_tid\fP zeigt. Da das Argument \fIEltern_tid\fP zur Rückgabe des PID\-Dateideskriptors verwandt wird, kann \fBCLONE_PIDFD\fP beim Aufruf von \fBclone\fP() nicht mit \fBCLONE_PARENT_SETTID\fP benutzt werden. .RE .IP Es ist derzeit nicht möglich, diesen Schalter zusammen mit \fBCLONE_THREAD\fP zu verwenden. Das bedeutet, dass ein durch den PID\-Dateideskriptor identifizierter Prozess immer der Prozessgruppenleiter sein wird. .IP Falls der veraltete Schalter \fBCLONE_DETACHED\fP beim Aufruf von \fBclone\fP() zusammen mit \fBCLONE_PIDFD\fP angegeben wird, wird ein Fehler zurückgeliefert. Falls \fBCLONE_DETACHED\fP beim Aufruf von \fBclone3\fP() angegeben wird, wird auch ein Fehler zurückgeliefert. Dieses Fehlerverhalten stellt sicher, dass das \fBCLONE_DETACHED\fP entsprechende Bit für weitere PID\-Dateideskriptorenfunktionalitäten in der Zukunft recyclet werden kann. .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 \fItls\fP gesetzt. .IP Die Interpretation von \fItls\fP und der resultierende Effekt ist architekturabhängig. Auf X86 ist \fItls\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 \fBARCH_SET_FS\fP von \fBarch_prctl\fP(2)). Auf Architekturen mit einem dedizierten TLS\-Register ist es der neue Wert dieses Registers. .IP Der Einsatz dieses Schalters verlangt detaillierte Kenntnisse und sollte im Allgemeinen nicht erfolgen, außer in einigen Bibliotheken, die Threading implementieren. .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. Daher könnten Signale durch Aufruf von \fBsigprocmask\fP(2) für einen Prozess geblockt oder zugelassen werden ohne den anderen Prozess zu beeinflussen. .IP Ist \fBCLONE_SIGHAND\fP nicht gesetzt, erbt der Kindprozess zum Zeitpunkt des Clone\-Aufrufs 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. .IP .\" Precisely: Linux 2.6.0-test6 Seit Linux 2.6.0 muss die \fISchalter\fP\-Maske außerdem \fBCLONE_VM\fP enthalten, falls \fBCLONE_SIGHAND\fP angegeben wurde. .TP \fBCLONE_STOPPED\fP (seit Linux 2.6.0) .\" Precisely: 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. .IP .\" 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) .\" Precisely: Linux 2.6.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. .IP 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. .IP 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 zurückgegeben wird. Ein Thread kann durch Benutzen von \fBgettid\fP(2) seine eigene TID erhalten. .IP Wenn Clone 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. .IP Ein neuer mit \fBCLONE_THREAD\fP erzeugter Thread hat den gleichen Elternprozess wie der, der Clone aufrufen hat (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 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.) .IP Nachdem alle Threads in einer Thread\-Gruppe beendet sind, wird dem Elternprozess ein \fBSIGCHLD\fP\-Signal (oder ein anderes Ende\-Signal) gesandt. .IP 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. .IP 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. .IP .\" Precisely: Linux 2.6.0-test6 Seit Linux 2.5.35 muss die \fISchalter\fP\-Maske auch \fBCLONE_SIGHAND\fP enthalten, wenn \fBCLONE_THREAD\fP angegeben wurde. Beachten Sie auch, dass seit Linux 2.6.0 \fBCLONE_SIGHAND\fP auch \fBCLONE_VM\fP enthalten muss. .IP 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). .IP Jeder Thread hat seine eigene Signalmaske, wie von \fBsigprocmask\fP(2) gesetzt. .IP Ein Signal kann Prozess\-orientiert oder Thread\-orientiert sein. Ein Prozess\-orientiertes Signal kann auf eine Thread\-Gruppe (d.h. einer TGID) abzielen und wird an einen beliebig ausgewählten Thread innerhalb dieser, der das Signal nicht blockiert, ausgeliefert. Ein Signal kann Prozess\-orientiert sein, da es vom Kernel aus anderen Gründen (neben Hardware\-Ausnahmebehandlungen) erstellt wurde oder da mittels \fBkill\fP(2) oder \fBsigqueue\fP(3) gesandt wurde\&. Ein Thread\-orientiertes Signal zielt auf ein bestimmten Thread (d.h. wird an ihn ausgeliefert). Ein Signal kann Thread\-orientiert sein, da es mittels \fBtgkill\fP(2) oder \fBpthread_sigqueue\fP(3) gesandt wurde oder da der Thread einen Maschinensprachenbefehl ausführte, der eine Hardware\-Ausnahmebehandlung auslöste (z.B. löst ein ungültiger Speicherzugriff \fBSIGSEGV\fP oder eine Fließkommaausnahmebehandlung \fBSIGFPE\fP aus). .IP Ein Aufruf von \fBsigpending\fP(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. .IP 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 \fBsigwaitinfo\fP(2) zu akzeptieren, wird der Kernel einen dieser Threads willkürlich auswählen, um das 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. .IP 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. .IP Ist \fBCLONE_VM\fP nicht gesetzt, erhält der Kindprozess eine eigene Kopie des Speicherbereichs des aufrufenden Prozesses zum Zeitpunkt 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 \fBfork\fP(2). .IP Falls der Schalter \fBCLONE_VM\fP angegeben und der Schalter \fBCLONE_VM\fP nicht angegeben ist, dann wird jeder alternative Stapel, der durch \fBsigaltstack\fP(2) etabliert wurde, im Kindprozess bereinigt. .SH RÜCKGABEWERT .\" gettid(2) returns current->pid; .\" getpid(2) returns current->tgid; 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 \fIerrno\fP entsprechend gesetzt. .SH FEHLER .TP \fBEAGAIN\fP Es laufen bereits zu viele Prozesse; siehe \fBfork\fP(2). .TP \fBEBUSY\fP (nur \fBclone3\fP()) \fBCLONE_INTO_CGROUP\fP wurde in \fIcl_args.flags\fP angegeben, aber der in \fIcl_args.cgroup\fP angegebene Dateideskriptor bezieht sich auf eine Version\-2\-Cgroup, in der ein Domain\-Controller aktiviert wurde. .TP \fBEEXIST\fP (nur \fBclone3\fP()) Eine (oder mehrere) der in \fIset_tid\fP festgelegten PIDs existiert im entsprechenden PID\-Namensraum bereits. .TP \fBEINVAL\fP In der \fISchalter\fP\-Maske wurden sowohl \fBCLONE_SIGHAND\fP als auch \fBCLONE_CLEAR_SIGHAND\fP festgelegt. .TP \fBEINVAL\fP .\" Precisely: Linux 2.6.0-test6 \fBCLONE_SIGHAND\fP wurde in der \fISchalter\fP\-Maske festgelegt, aber nicht \fBCLONE_VM\fP. (Seit Linux 2.6.0.) .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 in der \fISchalter\fP\-Maske festgelegt, aber nicht \fBCLONE_SIGHAND\fP. (Seit Linux 2.5.35.) .TP \fBEINVAL\fP \fBCLONE_THREAD\fP wurde in der \fISchalter\fP\-Maske festgelegt, aber der aktuelle Prozess hatte vorher \fBunshare\fP(2) mit dem Schalter \fBCLONE_NEWPID\fP aufgerufen oder \fBsetns\fP(2) verwandt, um sich wieder einem PID\-Namensraum zuzuordnen. .TP \fBEINVAL\fP .\" commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71 In der \fISchalter\fP\-Maske wurden sowohl \fBCLONE_FS\fP als auch \fBCLONE_NEWNS\fP festgelegt. .TP \fBEINVAL\fP (seit Linux 3.9) In der \fISchalter\fP\-Maske wurden sowohl \fBCLONE_NEWUSER\fP als auch \fBCLONE_FS\fP festgelegt. .TP \fBEINVAL\fP In der \fISchalter\fP\-Maske wurden sowohl \fBCLONE_NEWIPC\fP als auch \fBCLONE_SYSVSEM\fP festgelegt. .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 der \fISchalter\fP\-Maske festgelegt. .TP \fBEINVAL\fP (seit Linux 2.6.32) .\" commit 123be07b0b399670a7cc3d82fef0cb4f93ef885c \fBCLONE_PARENT\fP wurde angegeben und der Aufrufende ist ein Init\-Prozess. .TP \fBEINVAL\fP Wird von der Glibc\-Wrapper\-Funktion \fBclone\fP() zurückgegeben, wenn ein Wert von NULL für \fIfn\fP oder \fIStapel\fP festgelegt wurde. .TP \fBEINVAL\fP \fBCLONE_NEWIPC\fP wurde in der \fISchalter\fP\-Maske festgelegt, aber der Kernel ist nicht mit den Optionen \fBCONFIG_SYSVIPC\fP und \fBCONFIG_IPC_NS\fP konfiguriert. .TP \fBEINVAL\fP \fBCLONE_NEWNET\fP wurde in der \fISchalter\fP\-Maske festgelegt, aber der Kernel ist nicht mit der Option \fBCONFIG_NET_NS\fP konfiguriert. .TP \fBEINVAL\fP \fBCLONE_NEWPID\fP wurde in der \fISchalter\fP\-Maske festgelegt, aber der Kernel ist nicht mit der Option \fBCONFIG_PID_NS\fP konfiguriert. .TP \fBEINVAL\fP \fBCLONE_NEWUSER\fP wurde in der \fISchalter\fP\-Maske festgelegt, aber der Kernel ist nicht mit der Option \fBCONFIG_USER_NS\fP konfiguriert. .TP \fBEINVAL\fP \fBCLONE_NEWUTS\fP wurde in der \fISchalter\fP\-Maske festgelegt, aber der Kernel ist nicht mit der Option \fBCONFIG_UTS_NS\fP konfiguriert. .TP \fBEINVAL\fP \fIStapel\fP ist nicht an einer geeigneten Grenze für diese Architektur ausgerichtet. Beispielsweise muss \fIStapel\fP auf Aarch64 ein Vielfaches von 16 sein. .TP \fBEINVAL\fP (nur \fBclone3\fP()) In der \fISchalter\fP\-Maske wurden \fBCLONE_DETACHED\fP festgelegt. .TP \fBEINVAL\fP (nur \fBclone\fP()) \fBCLONE_PIDFD\fP wurde zusammen mit \fBCLONE_DETACHED\fP in der \fISchalter\fP\-Maske festgelegt. .TP \fBEINVAL\fP \fBCLONE_PIDFD\fP wurde zusammen mit \fBCLONE_THREAD\fP in der \fISchalter\fP\-Maske festgelegt. .TP \fBEINVAL \fP(nur \fBclone\fP()) \fBCLONE_PIDFD\fP wurde zusammen mit \fBCLONE_PARENT_SETTID\fP in der \fISchalter\fP\-Maske festgelegt. .TP \fBEINVAL\fP (nur \fBclone3\fP()) \fIset_tid_size\fP ist größer als die Anzahl der geschachtelten PID\-Namensräume. .TP \fBEINVAL\fP (nur \fBclone3\fP()) Eine der in \fIset_tid\fP festgelegten PIDs war ungültig. .TP \fBEINVAL\fP (nur AArch64, Linux 4.6 und älter) \fIStapel\fP war nicht an einer 126\-Bit\-Grenze ausgerichtet. .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 \fBENOSPC\fP (seit Linux 3.7) .\" commit f2302505775fd13ba93f034206f1e2a587017929 \fBCLONE_NEWPID\fP wurde in der \fISchalter\fP\-Maske festgelegt, aber die Begrenzung der Verschachtelungstiefe von PID\-Namensräumen würde überschritten; siehe \fBpid_namespaces\fP(7). .TP \fBENOSPC\fP (seit Linux 4.9; vorher \fBEUSERS\fP) \fBCLONE_NEWUSER\fP wurde in der \fISchalter\fP\-Maske festgelegt und der Aufruf würde zu einer Überschreitung der Begrenzung für die Anzahl von verschachtelten Benutzernamensräumen führen. Siehe \fBuser_namespaces\fP(7). .IP Von Linux 3.11 bis Linux 4.8 war der in diesem Fall diagnostizierte Fehler \fBEUSERS\fP. .TP \fBENOSPC\fP (seit Linux 4.9) Einer der Werte in der \fISchalter\fP\-Maske legte die Erstellung eines neuen Benutzer\-Namensraums fest, dadurch würde aber die in der enstprechenden Datei in \fI/proc/sys/user\fP festgelegte Begrenzung überschritten. Für weitere Details siehe \fBnamespaces\fP(7). .TP \fBEOPNOTSUPP\fP (nur \fBclone3\fP()) \fBCLONE_INTO_CGROUP\fP wurde in \fIcl_args.flags\fP angegeben, aber der in \fIcl_args.cgroup\fP angegebene Dateideskriptor bezieht sich auf eine Version\-2\-Cgroup, die im Zustand \fIDomain ungültig\fP ist. .TP \fBEPERM\fP \fBCLONE_NEWCGROUP\fP, \fBCLONE_NEWIPC\fP, \fBCLONE_NEWNET\fP, \fBCLONE_NEWNS\fP, \fBCLONE_NEWPID\fP oder \fBCLONE_NEWUTS\fP wurde von einem nicht privilegierten Prozess festgelegt (Prozess ohne \fBCAP_SYS_ADMIN\fP). .TP \fBEPERM\fP \fBCLONE_PID\fP wurde von einem anderen Prozess als Prozess 0 festgelegt. (Dieser Fehler tritt nur unter Linux 2.5.15 und früheren Versionen auf.) .TP \fBEPERM\fP \fBCLONE_NEWUSER\fP wurde in der \fISchalter\fP\-Maske festgelegt, aber weder die effektive Benutzerkennung noch die effektive Gruppenkennung des Aufrufenden hat eine Abbildung in den Namensraum der Eltern (siehe \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 der \fISchalter\fP\-Maske festgelegt und der Aufrufende ist in einer Chroot\-Umgebung (d.h. das Wurzelverzeichnis des Aufrufenden passt nicht zum Wurzelverzeichnis des Einhängenamensraums, in dem er sich befindet). .TP \fBEPERM\fP (nur \fBclone3\fP()) \fIset_tid_size\fP war größer als Null und dem Aufrufenden fehlt in einem oder mehreren Benutzernamensräumen, dem die entsprechenden PID\-Namensräume gehören, die Capability \fBCAP_SYS_ADMIN\fP. .TP \fBERESTARTNOINTR\fP (seit Linux 2.6.17) .\" commit 4a2c7a7837da1b91468e50426066d988050e4d56 Ein Systemaufruf wurde durch ein Signal unterbrochen und wird neu gestartet. (Dies wird nur während einer Verfolgung sichtbar sein.) .TP \fBEUSERS\fP (Linux 3.11 bis Linux 4.8) \fBCLONE_NEWUSER\fP wurde in der \fISchalter\fP\-Maske festgelegt und die Begrenzung für die Anzahl von verschachtelten Benutzernamensräumen würde überschritten. Siehe die Diskussion des Fehlers \fBENOSPC\fP oben. .SH VERSIONEN .\" There is no entry for .\" .BR clone () .\" in libc5. .\" glibc2 provides .\" .BR clone () .\" as described in this manual page. Der Systemaufruf \fBclone3\fP() erschien erstmalig in Linux 5.3. .SH "KONFORM ZU" Diese Systemaufrufe sind Linux\-spezifisch und sollten nicht in portierbaren Programmen benutzt werden. .SH ANMERKUNGEN Diese Systemaufrufe werden benutzt, um Threads zu implementieren: mehrere Steuerflüsse in einem Programm, die gleichzeitig in einem gemeinsamen Speicherbereich ausgeführt werden. .PP Glibc stellt keinen Wrapper für \fBclone3\fP() bereit; rufen Sie ihn mittels \fBsyscall\fP(2) auf. .PP Beachten Sie, dass die Glibc\-Wrapperfunktion \fBclone\fP() einige Änderungen am Speicher, auf den \fIStapel\fP zeigt, vornimmt (Änderungen, um den Stapel korrekt für das Kind einzurichten), \fIbevor\fP der Systemaufruf \fBclone\fP() ausgelöst wird. Verwenden Sie daher in Fällen, in denen \fBclone\fP() zur rekursiven Erstellung von Kindern verwandt wird, nicht den Puffer, der für den Stapel der Eltern eingesetzt wird, als Stapel der Kinder. .PP Der Systemaufruf \fBkcmp\fP(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. .PP Handler, die mittels \fBpthread_atfork\fP(3) registriert sind, werden während eines Clone\-Aufrufs nicht ausgeführt. .PP 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). .PP .\" Auf i386\-Architekturen sollte \fBclone\fP() nicht durch vsyscall aufgerufen werden, sondern direkt durch \fIint $0x80\fP. .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. .PP Im Gegensatz zum Glibc\-Wrapper akzeptiert der rohe Systemaufruf \fBclone\fP() NULL als \fIStapel\fP\-Argument (und \fBclone3\fP() erlaubt entsprechend \fIcl_args.stack\fP NULL zu sein). In diesem Fall verwendet das Kind eine Dublette des Stapels des Elternprozesses. (»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 \fBCLONE_VM\fP nicht angegeben werden, damit es korrekt funktioniert. (Falls das Kind sich aufgrund des Schalters \fBCLONE_VM\fP mit dem Elternprozess den Speicher \fIteilt\fP, dann tritt keine copy\-on\-write\-Duplizierung auf und wahrscheinlich tritt Chaos ein. .PP 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. .PP Die rohe Schnittstelle für Systemaufrufe auf x86\-64 und einigen anderen Architekturen (darunter Sh, Tile und Alpha) sieht so aus: .PP .in +4n .EX \fBlong clone(unsigned long \fP\fISchalter\fP\fB, void *\fP\fIStapel\fP\fB,\fP \fB int *\fP\fIEltern_tid\fP\fB, int *\fP\fIKind_tid\fP\fB,\fP \fB unsigned long \fP\fItls\fP\fB);\fP .EE .in .PP .\" 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: .PP .in +4n .EX \fBlong clone(unsigned long \fP\fISchalter\fP\fB, void *\fP\fIStapel\fP\fB,\fP \fB int *\fP\fIEltern_tid\fP\fB, unsigned long \fP\fItls\fP\fB,\fP \fB int *\fP\fIKind_tid\fP\fB);\fP .EE .in .PP .\" CONFIG_CLONE_BACKWARDS2 Auf der Cris\- und S30\-Architektur ist die Reihenfolge der ersten zwei Argumente gedreht: .PP .in +4n .EX \fBlong clone(void *\fP\fIStapel\fP\fB, unsigned long \fP\fISchalter\fP\fB,\fP \fB int *\fP\fIEltern_tid\fP\fB, int *\fP\fIKind_tid\fP\fB,\fP \fB unsigned long \fP\fItls\fP\fB);\fP .EE .in .PP .\" CONFIG_CLONE_BACKWARDS3 Auf der Microblaze\-Architektur wird ein zusätzliches Argument übergeben: .PP .in +4n .EX \fBlong clone(unsigned long \fP\fISchalter\fP\fB, void *\fP\fIStapel\fP\fB,\fP \fB int \fP\fIStapelgröße\fP\fB,\fP /* Größe des Stapels */ \fB int *\fP\fIEltern_tid\fP\fB, int *\fP\fIKind_tid\fP\fB,\fP \fB unsigned long \fP\fItls\fP\fB);\fP .EE .in .\" .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: .PP .in +4n .EX \fBint __clone2(int (*\fP\fIfn\fP\fB)(void *),\fP \fB void *\fP\fIStapelbasis\fP\fB, size_t \fP\fIStapelgröße\fP\fB,\fP \fB int \fP\fISchalter\fP\fB, void *\fP\fIarg\fP\fB, …\fP \fB /* pid_t *\fP\fIEltern_tid\fP\fB, struct user_desc *\fP\fItls\fP\fB,\fP \fB pid_t *\fP\fIKind_tid\fP\fB */ );\fP .EE .in .PP 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 \fBclone\fP()\-Prototyp auf Microblaze): .PP .in +4n .EX \fBlong clone2(unsigned long \fP\fISchalter\fP\fB, void *\fP\fIStapelbasis\fP\fB,\fP \fB int \fP\fIStapelgröße\fP\fB,\fP /* Größe des Stapels */ \fB int *\fP\fIEltern_tid\fP\fB, int *\fP\fIKind_tid\fP\fB,\fP \fB unsigned long \fP\fItls\fP\fB);\fP .EE .in .PP \fB__clone2\fP() arbeitet auf die gleiche Weise wie \fBclone\fP(), außer dass \fIStapelbasis\fP auf die niedrigste Adresse im Stapelspeicherbereich des Kindprozesses zeigt und \fIstack_size\fP die Größe des Stapelspeichers angibt, auf die \fIStapelbasis\fP zeigt. .SS "Linux 2.4 und älter" Unter Linux 2.4 und früher gab es die Argumente \fIEltern_tid\fP, \fItls\fP und \fIKind_tid\fP noch nicht. .SH FEHLER GNU\-C\-Bibliotheksversionen 2.3.4 bis einschließlich 2.24 enthielten eine Wrapper\-Funktion für \fBgetpid\fP(2), die Zwischenspeichern von PIDs vornahm. Dieses Zwischenspeichern beruhte auf der Unterstützung in dem Glibc\-Wrapper von \fBclone\fP(), aber Einschränkungen in der Implementierung bedeuteten, dass unter einigen Umständen der Zwischenspeicher nicht aktuell war. Insbesondere wenn ein Signal sofort nach dem \fBclone\fP()\-Aufruf an den Kindprozess gesandt wurde, konnte 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 \fISchalter\fP \fBCLONE_VM\fP enthält.) Um die Wahrheit zu erfahren, war es manchmal notwendig gewesen, Code wie den folgenden zu verwenden: .PP .in +4n .EX #include pid_t mypid; mypid = syscall(SYS_getpid); .EE .in .\" See also the following bug reports .\" https://bugzilla.redhat.com/show_bug.cgi?id=417521 .\" http://sourceware.org/bugzilla/show_bug.cgi?id=6910 .PP Aufgrund des Problems mit dem nicht mehr frischem Zwischenspeicher sowie anderen in \fBgetpid\fP(2) bemerkten Problemen, wurde die Funktionalität des PID\-Zwischenspeicherns in Glibc 2.25 entfernt. .SH BEISPIELE 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). .PP Innerhalb des Beispielprogramms reservieren wir Speicher, der für den Stapel des Kindprogramms verwandt werden soll. Dabei verwenden wir aus den folgenden Gründen \fBmmap\fP(2) statt \fBmalloc\fP(3): .IP * 3 \fBmmap\fP(2) reserviert einen Speicherblock, der an einer Seitengrenze beginnt und ein Vielfaches der Seitengröße groß ist. Dies ist nützlich, um am Ende des Stapels mittels \fBmprotect\fP(2) eine Wächterseite (eine Seite mit dem Schutz \fBPROT_NONE\fP) einzurichten. .IP * Wir können den Schalter \fBMAP_STACK\fP angeben, um ein für den Stapel geeignetes Mapping festzulegen. Derzeit führt dieser Schalter unter Linux zu keiner Aktion, aber er existiert und hat auf anderen Systemen Auswirkungen, daher sollten wir ihn zwecks Portabilität aufnehmen. .SS Programmquelltext .EX #define _GNU_SOURCE #include #include #include #include #include #include #include #include #include #define errExit(Nachricht) do { perror(Nachricht); 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); } /* Speicher für den Stapel des Kindprozess reservieren */ stack = mmap(NULL, STACK_SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_STACK, \-1, 0); if (stack == MAP_FAILED) errExit("mmap"); 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 %jd zurück\en", (intmax_t) 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); } .EE .SH "SIEHE AUCH" \fBfork\fP(2), \fBfutex\fP(2), \fBgetpid\fP(2), \fBgettid\fP(2), \fBkcmp\fP(2), \fBmmap\fP(2), \fBpidfd_open\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 5.10 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 , Dr. Tobias Quathamer und Helge Kreutzmann erstellt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License Version 3 .UE 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 die .MT debian-l10n-german@\:lists.\:debian.\:org Mailingliste der Übersetzer .ME .