Die clone()-Wrapper-Funktion¶

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

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

Die verbliebenen Argumente für clone() werden unten behandelt.

clone3()¶

Wie bei fork(2) kehrt clone3() sowohl im Eltern- als auch im Kindprozess zurück. Er liefert 0 im Kindprozess und die PID des Kindprozesses im Elternprozess zurück.

Das Argument cl_args von clone3() ist eine Struktur der folgenden Form:

struct clone_args {
    u64 flags;        /* Schalter-Bit-Maske */
    u64 pidfd;        /* Wo der PID-Dateideskriptor gespeichert
                         werden soll (pid_t *) */
    u64 child_tid;    /* Wo die Kind-TID gespeichert werden soll,
                         im Speicher des Kindes (pid_t *) */
    u64 parent_tid;   /* Wo die Kind-TID gespeichert werden soll,
                         im Speicher des Elternprozesses (int *) */
    u64 exit_signal;  /* Beim Beenden des Kindprozesses an den Elternprozess
                         zu sendendes Signal */
    u64 stack;        /* Zeiger auf das niedrigste Byte des Stacks */
    u64 stack_size;   /* Größe des Stacks */
    u64 tls;          /* Ort eines neuen TLS */
};

Das an clone3() übergebene Argument size sollte auf die Größe dieser Struktur initialisiert werden. (Die Existenz des Arguments size ermöglicht zukünftige Erweiterungen der clone_args-Struktur.)

Der Stack für den Kindprozess wird in cl_args.stack, der auf das niedrigste Byte des Stack-Bereichs zeigt, und cl_args.stack_size, der die Größe des Stack-Bereichs in Byte festlegt, festgelegt. Falls der Schalter CLONE_VM (siehe unten) festgelegt ist, muss ein Stack explizit reserviert und festgelegt werden. Andernfalls können diese Felder als NULL und 0 festgelegt werden, wodurch der Kindprozess den gleichen Stack-Bereich wie der Elternprozess verwendet (im eigenen virtuellen Adressraum des Kindprozesses).

Die verbliebenen Felder im Argument cl_args werden unten behandelt.

Äquivalenz zwischen den Argumenten von clone() und clone3()¶

Die folgende Tabelle zeigt die Äquivalenz zwischen den Argumenten von clone() und den Feldern in den an clone3() übergebenen clone_args:

Das Kind-Beendigungssignal¶

Die Schaltermaske¶

Die flags-Maske wird als bitweises ODER von Null oder mehreren der oben aufgeführten Konstanten festgelegt. Falls nicht unten anders angegeben, sind diese Schalter sowohl in clone() als auch clone3() verfügbar (und haben die gleiche Wirkung).

CLONE_CHILD_CLEARTID (seit Linux 2.5.49)

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

CLONE_CHILD_SETTID (seit Linux 2.5.49)

Speichert die Kind-Thread-Kennung an der Stelle, auf die child_tid (clone()) oder cl_args.child_tid (clone3()) 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 CLONE_VM eingesetzt wird.)

CLONE_DETACHED (historisch)

Eine Zeit lang (während der Linux-2.5-Entwicklungsserie) gab es einen Schalter CLONE_DETACHED, 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 CLONE_THREAD 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 CLONE_THREAD zusammen anzugeben.

Dieser Schalter ist noch definiert, wird aber beim Aufruf von clone() normalerweise ignoriert. Siehe allerdings die Beschreibung von CLONE_PIDFD für einige Ausnahmen.

CLONE_FILES (since Linux 2.0)

Ist CLONE_FILES gesetzt, teilen sich der aufrufende und der Kindprozess ihre Dateideskriptor-Tabellen. Jeder Dateideskriptor, der im aufrufenden Prozess oder vom Kindprozess erzeugt wird, ist auch im anderen Prozess gültig. Ebenso wirkt sich das Schließen eines Dateideskriptors oder das Ändern der zugehörigen Schalter (benutzen der F_SETFD-Operation von fcntl(2)) auf den anderen Prozess aus. Falls sich ein Prozess eine Dateideskriptor-Tabelle teilt und execve(2) aufruft, wird seine Dateideskriptor-Tabelle dupliziert (nicht länger geteilt).

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

CLONE_FS (seit Linux 2.0)

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

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

CLONE_IO (seit Linux 2.6.25)

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

Der E/A-Kontext entspricht dem E/A-Gültigkeitsbereich des Platten-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 (aio_read(3) zum Beispiel), sollten sie für eine bessere E/A-Leistung CLONE_IO verwenden.

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

CLONE_NEWCGROUP (seit Linux 4.6)

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

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

Nur ein privilegierter Prozess (CAP_SYS_ADMIN) kann CLONE_NEWCGROUP angeben.

CLONE_NEWIPC (seit Linux 2.6.19)

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

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

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

CLONE_NEWNET (seit Linux 2.6.24)

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

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

Weitere Informationen zu Netzwerk-Namensräumen finden Sie in network_namespaces(7).

Nur ein privilegierter Prozess (CAP_SYS_ADMIN) kann CLONE_NEWNET angeben.

CLONE_NEWNS (seit Linux 2.4.19)

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

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

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

CLONE_NEWPID (seit Linux 2.6.24)

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

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

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

CLONE_NEWUSER

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

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

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

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

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

CLONE_NEWUTS (seit Linux 2.6.19)

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

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

Nur ein privilegierter Prozess (CAP_SYS_ADMIN) kann CLONE_NEWUTS angeben.

CLONE_PARENT (seit Linux 2.3.12)

Falls CLONE_PARENT gesetzt ist, dann wird der Elternprozess des neuen Kindprozesses (wie er von getppid(2) zurückgegeben wird) der gleiche wie der aufrufende Prozess sein.

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

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

CLONE_PARENT_SETTID (seit Linux 2.5.49)

Die Kindprozess-Thread-Kennung an der Stelle im Elternspeicher ablegen, auf die parent_tid (clone()) oder cl_args.child_tid (clone3()) zeigt. (In Linux 2.5.32-2.5.48 gab es einen Schalter CLONE_SETTID, der das tat.) Die Speicheraktion wird abgeschlossen, bevor der Clone-Aufruf die Steuerung an den Benutzerraum zurückgibt.

CLONE_PID (Linux 2.0 bis 2.5.15)

Falls CLONE_PID gesetzt ist, wird der Kindprozess mit der gleichen Prozesskennung wie der aufrufende Prozess erstellt. Dies ist gut, um das System zu hacken, aber andererseits zu nicht viel mehr zu gebrauchen. Seit Linux 2.3.21 konnte dieser Schalter nur durch den Boot-Prozess 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 flags-Maske festgelegt wurde. Viel später wurde das Bit für die Verwendung als Schalter CLONE_PIDFD recyclet.

CLONE_PIDFD (seit Linux 5.2)

Falls dieser Schalter festgelegt ist, wird ein PID-Dateideskriptor, der sich auf einen Kindprozess bezieht, reserviert und an dem festgelegten 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 pidfd_open(2) beschriebenen Zwecke verwandt werden.

Es ist derzeit nicht möglich, diesen Schalter zusammen mit CLONE_THREAD zu verwenden. Das bedeutet, dass ein durch den PID-Dateideskriptor identifizierter Prozess immer der Prozessgruppenleiter sein wird.

Falls der veraltete Schalter CLONE_DETACHED beim Aufruf von clone() zusammen mit CLONE_PIDFD festgelegt wird, wird ein Fehler zurückgeliefert. Falls CLONE_DETACHED beim Aufruf von clone3() festgelegt wird, wird auch ein Fehler zurückgeliefert. Dieses Fehlerverhalten stellt sicher, dass das CLONE_DETACHED entsprechende Bit für weitere PID-Dateideskriptorenfunktionalitäten in der Zukunft recyclet werden kann.

CLONE_PTRACE (seit Linux 2.2)

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

CLONE_SETTLS (seit Linux 2.5.32)

Der TLS (Thread Local Storage)-Deskriptor ist auf tls gesetzt.

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

Der Einsatz dieses Schalters verlangt detaillierte Kenntnisse und sollte im Allgemeinen nicht erfolgen, außer in einigen Bibliotheken, die Threading implementieren.

CLONE_SIGHAND (seit Linux 2.0)

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

Ist CLONE_SIGHAND nicht gesetzt, erbt der Kindprozess zum Zeitpunkt des Clone-Aufrufs eine Kopie des Signal-Handlers vom aufrufenden Prozess. Spätere Aufrufe von sigaction(2) durch einen der Prozesse hat dann keine Auswirkung auf den anderen Prozess.

Seit Linux 2.6.0 muss die flags-Maske außerdem CLONE_VM enthalten, falls CLONE_SIGHAND festgelegt wurde.

CLONE_STOPPED (seit Linux 2.6.0)

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

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

CLONE_SYSVSEM (seit Linux 2.5.10)

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

CLONE_THREAD (seit Linux 2.4.0)

Falls CLONE_THREAD gesetzt ist, wird der Kindprozess in die gleiche Thread-Gruppe wie der aufrufende Prozess platziert. Um den Rest der Diskussion von CLONE_THREAD leserlicher zu machen, wird der Begriff »Thread« benutzt, um Bezug auf Prozesse innerhalb einer Thread-Gruppe zu nehmen.

Thread-Gruppen waren ein Leistungsmerkmal, das in Linux 2.4 hinzugefügt wurde, um den POSIX-Thread-Gedanken von einer Thread-Zusammenstellung zu unterstützen, die sich eine einzelne PID teilt. Intern ist diese gemeinsame PID ein sogenannter Thread-Gruppen-Bezeichner (TGID) für die Thread-Gruppe. Seit Linux 2.4 geben Aufrufe von getpid(2) die TGID des Aufrufers zurück.

Die Threads innerhalb einer Gruppe können durch ihre (systemweit) einheitliche Thread-Kennung (TID) unterschieden werden. Die TID eines neuen Threads ist als Funktionsergebnis verfügbar, das an den Aufrufenden zurückgegeben wird. Ein Thread kann durch Benutzen von gettid(2) seine eigene TID erhalten.

Wenn Clone ohne Angabe von CLONE_THREAD aufgerufen wurde, dann wird der resultierende Thread in eine neue Thread-Gruppe platziert, deren TGID der TID des Threads entspricht. Dieser Thread ist der Führer der neuen Thread-Gruppe.

Ein neuer mit CLONE_THREAD erzeugter Thread hat den gleichen Elternprozess wie der, der Clone aufrufen hat (d.h. wie CLONE_PARENT), so dass Aufrufe von getppid(2) den gleichen Wert für alle Threads in der Thread-Gruppe zurückliefern. Wenn ein CLONE_THREAD-Thread endet, wird dem Thread, der ihn erstellt hat, weder ein SIGCHLD-Signal (oder ein anderes Ende-Signal) gesandt, noch kann der Status eines solchen Threads per wait(2) abgefragt werden. (Der Thread wird als losgelöst bezeichnet.)

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

Falls einige der Threads in einer Thread-Gruppe ein execve(2) durchführen, dann werden alle Threads außer dem Thread-Führer beendet und das neue Programm wird im Thread-Gruppenführer ausgeführt.

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

Seit Linux 2.5.35 muss die flags-Maske auch CLONE_SIGHAND enthalten, wenn CLONE_THREAD festgelegt wurde. Beachten Sie auch, dass seit Linux 2.6.0 CLONE_SIGHAND auch CLONE_VM enthalten muss.

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

Jeder Thread hat seine eigene Signalmaske, wie von sigprocmask(2) gesetzt.

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 kill(2) oder sigqueue(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 tgkill(2) oder pthread_sigqueue(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 SIGSEGV oder eine Fließkommaausnahmebehandlung SIGFPE aus).

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

Falls ein Prozess-orientiertes Signal an eine Thread-Gruppe ausgeliefert wird und die Thread-Gruppe einen Handler für dieses Signal installiert hat, dann dann wird der Handler in exakt einem willkürlich ausgewählten Mitglied der Thread-Gruppe aufrufen, das das Signal nicht blockiert hat. Falls mehrere Threads in einer Gruppe darauf warten das gleiche Signal per sigwaitinfo(2) zu akzeptieren, wird der Kernel einen dieser Threads willkürlich auswählen, um das Signal zu empfangen.

CLONE_UNTRACED (seit Linux 2.5.46)

Falls CLONE_UNTRACED festgelegt ist, kann ein verfolgender Prozess kein CLONE_PTRACE auf diesem Kindprozess erzwingen.

CLONE_VFORK (seit Linux 2.2)

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

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

CLONE_VM (seit Linux 2.0)

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

Ist CLONE_VM nicht gesetzt, erhält der Kindprozess eine eigene Kopie des Speicherbereichs des aufrufenden Prozesses 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 fork(2).

Unterschiede C-Bibliothek/Kernel¶

Im Gegensatz zum Glibc-Wrapper akzeptiert der rohe Systemaufruf clone() NULL als stack-Argument (und clone3() erlaubt entsprechend cl_args.stack NULL zu sein). In diesem Fall verwendet das Kind eine Dublette des Stacks 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 CLONE_VM nicht festgelegt werden, damit es korrekt funktioniert. (Falls das Kind sich aufgrund des Schalters CLONE_VM mit dem Elternprozess den Speicher teilt, dann tritt keine copy-on-write-Duplizierung auf und wahrscheinlich tritt Chaos ein.

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

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

long clone(unsigned long flags, void *stack,
           int *parent_tid, int *child_tid,
           unsigned long tls);

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

long clone(unsigned long flags, void *stack,
          int *parent_tid, unsigned long tls,
          int *child_tid);

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

long clone(void *stack, unsigned long flags,
           int *parent_tid, int *child_tid,
           unsigned long tls);

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

long clone(unsigned long flags, void *stack,
           int stack_size,         /* Größe des Stacks */
           int *parent_tid, int *child_tid,
           unsigned long tls);

Blackfin, M68k und Sparc¶

Ia64¶

int __clone2(int (*fn)(void *), 
             void *stack_base, size_t stack_size,
             int flags, void *arg, … 
          /* pid_t *parent_tid, struct user_desc *tls,
             pid_t *child_tid */ );

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

long clone2(unsigned long flags, void *stack_base,
            int stack_size,         /* Größe des Stacks */
            int *parent_tid, int *child_tid,
            unsigned long tls);

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

Linux 2.4 und älter¶

Programmquelltext¶

#define _GNU_SOURCE
#include <sys/wait.h>
#include <sys/utsname.h>
#include <sched.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>
#define errExit(Nachricht)    do { perror(Nachricht); exit(EXIT_FAILURE); \
                        } while (0)
static int              /* Startfunktion für geklonten Kindprozess */
childFunc(void *arg)
{
    struct utsname uts;
    /* Rechnername im UTS-Namensraum des Kindprozesses ändern */
    if (sethostname(arg, strlen(arg)) == -1)
        errExit("sethostname");
    /* Rechnernamen abfragen und anzeigen */
    if (uname(&uts) == -1)
        errExit("uname");
    printf("uts.nodename im Kindprozess:  %s\n", uts.nodename);
    /* Der Namensraum wird für eine Weile durch Schlafen offen gehalten.
       Dies ermöglicht etwas zu experimentieren –  zum Beispiel
       kann ein weiterer Prozess dem Namensraum beitreten. */
    sleep(200);
    return 0;           /* Kindprozess wird nun beendet */
}
#define STACK_SIZE (1024 * 1024)    /* Stapelspeichergröße für geklonten
                                       Kindprozess */
int
main(int argc, char *argv[])
{
    char *stack;                    /* Start des Stapelspeicherpuffers */
    char *stackTop;                 /* Ende des Stapelspeicherpuffers */
    pid_t pid;
    struct utsname uts;
    if (argc < 2) {
        fprintf(stderr, "Aufruf: %s <Kindprozess-Rechnername>\n", argv[0]);
        exit(EXIT_SUCCESS);
    }
    /* Speicher für den Stack 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 %ld zurück\n", (long) pid);
    /* Elternprozess fällt bis hierher durch */
    sleep(1);   /* gibt dem Kindprozess Zeit zum Ändern des Rechnernamens */
    /* Den Rechnernamen im UTS-Namensraum des Elternprozesses anzeigen.
       Dieser wird sich vom Rechnernamen im UTS-Namensraum des Kindprozesses
       unterscheiden. */
    if (uname(&uts) == -1)
        errExit("uname");
    printf("uts.nodename im Elternprozess: %s\n", uts.nodename);
    if (waitpid(pid, NULL, 0) == -1)    /* Warten auf Kindprozess */
        errExit("waitpid");
    printf("Kindprozess wurde beendet\n");
    exit(EXIT_SUCCESS);
}