.\" 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 .\" .\" FIXME Document CLONE_NEWUSER, which is new in 2.6.23 .\" (also supported for unshare()?) .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH CLONE 2 "27 février 2014" Linux "Manuel du programmeur Linux" .SH NOM clone, __clone2 \- Créer un processus fils (child) .SH SYNOPSIS .nf /* Prototype de la fonction d'appel d'enrobage de glibc */ \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, struct user_desc *\fP\fItls\fP\fB, pid_t *\fP\fIctid\fP\fB */ );\fP /* Prototype de l'appel système brut */ \fBlong clone(unsigned long \fP\fIflags\fP\fB, void *\fP\fIchild_stack\fP\fB,\fP \fB void *\fP\fIptid\fP\fB, void *\fP\fIctid\fP\fB,\fP \fB struct pt_regs *\fP\fIregs\fP\fB);\fP .fi .sp .in -4n Conditions requises par la macro de test de fonctionnalités pour la fonction d'enrobage de glibc (consultez \fBfeature_test_macros\fP(7))\ : .in .sp \fBclone\fP()\ : .ad l .RS 4 .PD 0 .TP 4 À partir de glibc\ 2.14\ : _GNU_SOURCE .TP 4 .\" See http://sources.redhat.com/bugzilla/show_bug.cgi?id=4749 Avant glibc\ 2.14\ : _BSD_SOURCE || _SVID_SOURCE /* _GNU_SOURCE est également suffisant */ .PD .RE .ad b .SH DESCRIPTION \fBclone\fP() crée un nouveau processus, de façon analogue à \fBfork\fP(2). Cette page présente à la fois la fonction d'enrobage \fBclone\fP() de glibc et l'appel système sous\-jacent sur lequel elle s'appuie. Le texte principal décrit la fonction d'enrobage\ ; les différences avec l'appel système brut sont précisées plus bas dans l'article. Contrairement à \fBfork\fP(2), \fBclone\fP() permet le partage d'une partie du contexte d'exécution entre le processus fils et le processus appelant. Le partage peut s'appliquer sur l'espace mémoire, sur la table des descripteurs de fichiers ou la table des gestionnaires de signaux. (Notez que sur cette page de manuel, le «\ processus appelant\ » correspond normalement au «\ processus père\ », mais voyez quand même la description de \fBCLONE_PARENT\fP plus bas). L'appel système \fBclone\fP() est principalement utilisé pour permettre l'implémentation des threads\ : un programme est scindé en plusieurs lignes de contrôle, s'exécutant simultanément dans un espace mémoire partagée. Quand le processus fils est créé par \fBclone\fP(), il exécute la fonction \fIfn\fP(\fIarg\fP). Ceci est différent de \fBfork\fP(2), pour lequel l'exécution continue dans le processus fils à partir du moment de l'appel de \fBfork\fP(2). L'argument \fIfn\fP est un pointeur vers la fonction appelée par le processus fils lors de son démarrage. L'argument \fIarg\fP est transmis à la fonction \fIfn\fP lors de son invocation. Quand la fonction \fIfn\fP(\fIarg\fP) revient, le processus fils se termine. La valeur entière renvoyée par \fIfn\fP est utilisée comme code de retour du processus fils. Ce dernier peut également se terminer de manière explicite en invoquant la fonction \fBexit\fP(2) ou après la réception d'un signal fatal. L'argument \fIchild_stack\fP indique l'emplacement de la pile utilisée par le processus fils. Comme les processus fils et appelant peuvent partager de la mémoire, il n'est généralement pas possible pour le fils d'utiliser la même pile que son père. Le processus appelant doit donc préparer un espace mémoire pour stocker la pile de son fils, et transmettre à \fBclone\fP un pointeur sur cet emplacement. Les piles croissent vers le bas sur tous les processeurs implémentant Linux (sauf le HP PA), donc \fIchild_stack\fP doit pointer sur la plus haute adresse de l'espace mémoire prévu pour la pile du processus fils. L'octet de poids faible de \fIflags\fP contient le numéro du signal qui sera envoyé au père lorsque le processus fils se terminera. Si ce signal est différent de \fBSIGCHLD\fP, le processus parent doit également spécifier les options \fB__WALL\fP ou \fB__WCLONE\fP lorsqu'il attend la fin du fils avec \fBwait\fP(2). Si aucun signal n'est indiqué, le processus parent ne sera pas notifié de la terminaison du fils. \fIflags\fP permet également de préciser ce qui sera partagé entre le père et le fils, en effectuant un OU binaire entre une ou plusieurs des constantes suivantes\ : .TP \fBCLONE_CHILD_CLEARTID\fP (depuis Linux 2.5.49) Effacer l'ID du thread enfant à \fIctid\fP dans la mémoire du fils lorsqu'il se termine, et réveiller le futex à cette adresse. L'adresse concernée peut être modifiée par l'appel système \fBset_tid_address\fP(2). Cela est utilisé dans les bibliothèques de gestion de threads. .TP \fBCLONE_CHILD_SETTID\fP (depuis Linux 2.5.49) Enregistrer l'ID du thread enfant à \fIctid\fP dans la mémoire du fils. .TP \fBCLONE_FILES\fP (depuis Linux 2.0) Si l'attribut \fBCLONE_FILES\fP est positionné, le processus appelant et le processus fils partagent la même table des descripteurs de fichier. Tout descripteur créé par un processus est également valide pour l'autre processus. De même si un processus ferme un descripteur, ou modifie ses attributs (en utilisant l'opération \fBfcntl\fP(2) \fBF_SETFD\fP), l'autre processus en est aussi affecté. Si \fBCLONE_FILES\fP n'est pas positionné, le processus fils hérite d'une copie des descripteurs de fichier ouverts par l'appelant au moment de l'appel \fBclone\fP(). (Les copies des descripteurs de fichier dans le fils sont associées aux mêmes descriptions de fichiers ouverts (consultez \fBopen\fP(2)) que les descripteurs de fichier correspondants dans le processus appelant.) Les opérations effectuées ensuite sur un descripteur par un des processus n'affectent pas l'autre processus. .TP \fBCLONE_FS\fP (depuis Linux 2.0) Si l'attribut \fBCLONE_FS\fP est positionné, le processus appelant et le processus fils partagent les mêmes informations concernant le système de fichiers. Ceci inclut la racine du système de fichiers, le répertoire de travail, et l'umask. Tout appel à \fBchroot\fP(2), \fBchdir\fP(2) ou \fBumask\fP(2) effectué par un processus aura également influence sur l'autre processus. Si \fBCLONE_FS\fP n'est pas choisi, le processus travaille sur une copie des informations de l'appelant concernant le système de fichiers. Cette copie est effectuée lors de l'invocation de \fBclone\fP(). Les appels à \fBchroot\fP(2), \fBchdir\fP(2), \fBumask\fP(2) effectués par un processus n'affectent pas l'autre processus. .TP \fBCLONE_IO\fP (depuis Linux 2.6.25) Si \fBCLONE_IO\fP est défini, alors le nouveau processus partage un contexte d'entrées\-sorties avec le processus appelant. Si cet attribut n'est pas défini, alors (comme pour \fBfork\fP(2)) le nouveau processus a son propre contexte d'entrées\-sorties. .\" The following based on text from Jens Axboe .\" the anticipatory and CFQ scheduler .\" with CFQ and AS. Le contexte d'entrées\-sorties correspond à la visibilité que l'ordonnanceur de disques a des entrées\-sorties (c'est\-à\-dire, ce que l'ordonnanceur d'entrée\-sorties utilise pour modéliser l'ordonnancement des entrées\-sorties d'un processus). Si des processus partagent le même contexte d'entrées\-sorties, ils sont traités comme un seul par l'ordonnanceur d'entrées\-sorties. Par conséquent, ils partagent le même temps d'accès aux disques. Pour certains ordonnanceurs d'entrées\-sorties, si deux processus partagent un contexte d'entrées\-sorties, ils seront autorisés à intercaler leurs accès disque. Si plusieurs threads utilisent des entrées\-sorties pour le même processus (\fBaio_read\fP(3), par exemple), ils devraient utiliser \fBCLONE_IO\fP pour obtenir de meilleurs performances d'entrées\-sorties. Si le noyau n'a pas été configuré avec l'option \fBCONFIG_BLOCK\fP, cet attribut n'a aucun effet. .TP \fBCLONE_NEWIPC\fP (depuis Linux 2.6.19) Si \fBCLONE_NEWIPC\fP est défini, alors créer le processus dans un nouvel espace de noms IPC. Si cet attribut n'est pas défini, alors (comme pour \fBfork\fP(2)) le processus est créé dans le même espace de noms IPC que le processus appelant. Cet attribut est sensé être utilisé pour l'implémentation de conteneurs. .\" commit 7eafd7c74c3f2e67c27621b987b28397110d643f .\" https://lwn.net/Articles/312232/ Un espace de noms IPC fournit une vue isolée des objets IPC en System V (consultez \fBsvipc\fP(7)) et (à partir de Linux 2.6.30) des files d'attente de messages POSIX (consultez \fBmq_overview\fP(7)). Le point commun entre ces mécanismes IPC est que les objets IPC y sont identifiés par d'autres moyens que des chemins d'accès dans des systèmes de fichiers. Les objets créés dans un espace de noms IPC sont visibles pour tous les processus qui sont membres de cet espace de noms, mais ne sont pas visibles pour les processus des autres espaces de noms IPC. Quand un espace de noms est détruit (c'est\-à\-dire, quand le dernier processus membre de cet espace de noms se termine), tous les objets IPC de cet espace de noms sont automatiquement détruits. Utiliser cet attribut nécessite\ : un noyau configuré avec les options \fBCONFIG_SYSVIPC\fP et \fBCONFIG_IPC_NS\fP et que le processus soit privilégié (\fBCAP_SYS_ADMIN\fP). Cet attribut ne peut pas être utilisé en même temps que \fBCLONE_SYSVSEM\fP. .TP \fBCLONE_NEWNET\fP (depuis Linux 2.6.24) .\" FIXME Check when the implementation was completed (L'implémentation de cet attribut n'est complète que depuis le noyau 2.6.29.) Si \fBCLONE_NEWNET\fP est défini, alors créer le processus dans un nouvel espace de noms réseau. Si cet attribut n'est pas défini, alors (comme pour \fBfork\fP(2)) le processus est créé dans le même espace de noms réseau que le processus appelant. Cet attribut est sensé être utilisé pour l'implémentation de conteneurs. .\" FIXME Add pointer to veth(4) page when it is eventually completed Un espace de noms réseau fournit une vue isolée de la pile réseau (interfaces des périphériques réseau, piles des protocoles IPv4 et IPv6, tables de routage, règles de pare\-feu, les arbres de répertoire \fI/proc/net\fP et \fI/sys/class/net\fP, les sockets, etc.). Un périphérique réseau physique ne peut être que dans un seul espace de noms réseau. Une paire d'interface réseau virtuelle («\ veth\ ») fournit une abstraction similaire à pipe qui peut être utilisé pour créer un pont vers une interface réseau physique d'un autre espace de noms réseau. Quand un espace de noms réseau est libéré (c'est\-à\-dire, quand le dernier processus de l'espace de noms se termine), ses périphériques réseau physiques sont remis dans l'espace de noms réseau initial (pas celui du processus père). Utiliser cet attribut nécessite\ : un noyau configuré avec l'option \fBCONFIG_NET_NS\fP et que le processus soit privilégié (\fBCAP_SYS_ADMIN\fP). .TP \fBCLONE_NEWNS\fP (depuis Linux 2.4.19) Démarrer le processus dans un nouvel espace de noms de montage. Chaque processus se trouve dans un espace de noms de montage. Cet \fIespace de noms\fP du processus regroupe les données décrivant la hiérarchie des fichiers vus par le processus (l'ensemble des montages). Après un \fBfork\fP(2) ou \fBclone\fP() sans l'attribut \fBCLONE_NEWNS\fP le fils se déroule dans le même espace de noms de montage que son père. Les appels système \fBmount\fP(2) et \fBumount\fP(2) modifient l'espace de noms de montage du processus appelant, et affectent ainsi tous les processus se déroulant dans le même espace de noms, sans affecter les processus se trouvant dans d'autres espaces de noms de montage. Après un \fBclone\fP() avec l'attribut \fBCLONE_NEWNS\fP le fils cloné démarre dans un nouvel espace de noms de montage, initialisé avec une copie de l'espace de noms du père. Seul un processus privilégié (un processus ayant la capacité \fBCAP_SYS_ADMIN\fP) peut spécifier l'attribut \fBCLONE_NEWNS\fP. Il n'est pas possible de spécifier à la fois \fBCLONE_NEWNS\fP et \fBCLONE_FS\fP pour le même appel \fBclone\fP(). .TP \fBCLONE_NEWPID\fP (depuis 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 Si \fBCLONE_NEWPID\fP est défini, alors créer le processus dans un nouvel espace de noms de PID. Si cet attribut n'est pas défini, alors (comme pour \fBfork\fP(2)) le processus est créé dans le même espace de noms de PID que le processus appelant. Cet attribut est sensé être utilisé pour l'implémentation de conteneurs. Un espace de noms de PID fournit un environnement isolés pour les PID\ : les PID d'un nouvel espace de noms de PID commence à 1, comme pour un système seul, et les appels à \fBfork\fP(2), \fBvfork\fP(2) et \fBclone\fP() produiront des processus avec des PID uniques dans l'espace de noms. Le premier processus créé dans un nouvel espace de noms (c'est\-à\-dire, le processus créé en utilisant l'attribut \fBCLONE_NEWPID\fP) a un PID de 1 et est le processus «\ init\ » pour l'espace de noms. Les fils qui deviennent orphelins dans cet espace de noms seront adoptés par ce processus plutôt que par \fBinit\fP(8). Contrairement à l'\fBinit\fP traditionnel, le processus «\ init\ » d'un espace de noms de PID peut se terminer et, s'il le fait, tous les processus dans l'espace de noms sont alors terminés. Les espaces de noms de PID forment une hiérarchie. Quand un espace de noms de PID est créé, les processus de cet espace de noms sont visibles depuis l'espace de noms de PID du processus qui a créé le nouvel espace de noms\ ; de la même façon, si l'espace de noms parent est lui\-même le fils d'un autre espace de noms de PID, alors les processus du fils et du père seront tous visibles de l'espace de noms grand\-père. À l'inverse, les processus de l'espace de noms de PID fils ne voient pas les processus de l'espace de noms parent. L'existence d'une hiérarchie d'espaces de noms signifie que chaque processus peut désormais avoir plusieurs PID\ : un par espace de noms dans lequel il est visible\ ; chacun de ces PID est unique dans les espaces de noms correspondants. (Un appel à \fBgetpid\fP(2) renvoie toujours le PID associé à l'espace de noms dans lequel le processus se trouve.) .\" mount -t proc proc /proc Après avoir créé un nouvel espace de noms, il est utile pour le fils de changer son répertoire racine et monter une nouvelle instance de procfs dans \fI/proc\fP de telle sorte que des outils comme \fBps\fP(1) fonctionnent correctement. (Si \fBCLONE_NEWNS\fP est également présent dans \fIflags\fP, alors il n'est pas nécessaire de changer de répertorie racine\ : une nouvelle instance de procfs peut être monté directement dans \fI/proc\fP.) L'utilisation de cet attribut nécessite\ : un noyau configuré avec l'option \fBCONFIG_PID_NS\fP et que le processus soit privilégié (\fBCAP_SYS_ADMIN\fP). Cet attribut ne peut pas être utilisé en même temps que \fBCLONE_THREAD\fP. .TP \fBCLONE_NEWUTS\fP (depuis Linux 2.6.19) Si \fBCLONE_NEWUTS\fP est défini, alors créer le processus dans un nouvel espace de noms de UTS, dont les identifiants sont initialisés en dupliquant les identifiants de l'espace de noms UTS du processus appelant. Si cet attribut n'est pas défini, alors (comme pour \fBfork\fP(2)) le processus est créé dans le même espace de noms UTS que le processus appelant. Cet attribut est sensé être utilisé pour l'implémentation de conteneurs. Un espace de noms UTS est l'ensemble des identifiants renvoyés par \fBuname\fP(2)\ ; parmi lesquels le nom de domaine et le nom d'hôte peuvent être modifiés respectivement à l'aide de \fBsetdomainname\fP(2) et \fBsethostname\fP(2). Les modifications apportés à ces identifiants dans un espace de noms UTS sont visibles par tous les processus du même espace de noms, mais ne sont pas visibles des processus des autres espaces de noms UTS. L'utilisation de cet attribut nécessite\ : un noyau configuré avec l'option \fBCONFIG_UTS_NS\fP et que le processus soit privilégié (\fBCAP_SYS_ADMIN\fP). .TP \fBCLONE_PARENT\fP (depuis Linux 2.3.12) Si \fBCLONE_PARENT\fP est présent, le père du nouveau fils (comme il est indiqué par \fBgetppid\fP(2)) sera le même que celui du processus appelant. Si \fBCLONE_PARENT\fP n'est pas fourni, alors (comme pour \fBfork\fP(2)) le père du processus fils sera le processus appelant. Remarquez que c'est le processus père, tel qu'indiqué par \fBgetppid\fP(2), qui est notifié lors de la fin du fils. Ainsi, si \fBCLONE_PARENT\fP est présent, alors c'est le père du processus appelant, et non ce dernier, qui sera notifié. .TP \fBCLONE_PARENT_SETTID\fP (depuis Linux 2.5.49) Enregistrer l'ID du thread enfant à \fIptid\fP dans la mémoire du père et du fils. (Dans Linux 2.5.32\-2.5.48 il y a un attribut \fBCLONE_SETTID\fP qui fait cela.) .TP \fBCLONE_PID\fP (obsolète) Si l'attribut \fBCLONE_PID\fP est positionné, les processus appelant et fils ont le même numéro de processus. C'est bien pour hacker le système, mais autrement il n'est plus utilisé. Depuis 2.3.21, cet attribut ne peut être utilisé que par le processus de démarrage du système (PID 0). Il a disparu dans Linux 2.5.16. .TP \fBCLONE_PTRACE\fP (depuis Linux 2.2) Si l'attribut \fBCLONE_PTRACE\fP est positionné et si l'appelant est suivi par un débogueur, alors le fils sera également suivi (consultez \fBptrace\fP(2)). .TP \fBCLONE_SETTLS\fP (depuis Linux 2.5.32) Le paramètre \fInewtls\fP est le nouveau descripteur TLS (Thread Local Storage). (Consultez \fBset_thread_area\fP(2).) .TP \fBCLONE_SIGHAND\fP (depuis Linux 2.0) Si l'attribut \fBCLONE_SIGHAND\fP est positionné, le processus appelant et le processus fils partagent la même table des gestionnaires de signaux. Si l'appelant, ou le fils, appelle \fBsigaction\fP(2) pour modifier le comportement associé à un signal, ce comportement est également changé pour l'autre processus. Néanmoins, l'appelant et le fils ont toujours des masques de signaux distincts, et leurs ensembles de signaux bloqués sont indépendants. L'un des processus peut donc bloquer un signal en utilisant \fBsigprocmask\fP(2) sans affecter l'autre processus. Si \fBCLONE_SIGHAND\fP n'est pas utilisé, le processus fils hérite d'une copie des gestionnaires de signaux de l'appelant lors de l'invocation de \fBclone\fP(). Les appels à \fBsigaction\fP(2) effectués ensuite depuis un processus n'ont pas d'effets sur l'autre processus. Depuis Linux 2.6.0\-test6, l'attribut \fBCLONE_VM\fP doit également être spécifié dans \fIflags\fP si \fBCLONE_SIGHAND\fP l'est. .TP \fBCLONE_STOPPED\fP (depuis Linux 2.6.0\-test2) Si l'attribut \fBCLONE_STOPPED\fP est positionné, le fils est initialement stoppé (comme s'il avait reçu le signal \fBSIGSTOP\fP), et doit être relancé en lui envoyant le signal \fBSIGCONT\fP. .\" glibc 2.8 removed this defn from bits/sched.h Cet attribut est marqué comme obsolète depuis Linux 2.6.25, et a été complètement supprimé dans Linux 2.6.38. .TP \fBCLONE_SYSVSEM\fP (depuis Linux 2.5.10) Si \fBCLONE_SYSVSEM\fP est positionné, le fils et le processus appelant partagent la même liste de compteurs «\ undo\ » pour les sémaphores System\ V (consultez \fBsemop\fP(2)). Si cet attribut n'est pas utilisé, le fils a une liste «\ undo\ » séparée, initialement vide. .TP \fBCLONE_THREAD\fP (depuis Linux 2.4.0\-test8) Si \fBCLONE_THREAD\fP est présent, le fils est placé dans le même groupe de threads que le processus appelant. Afin de rendre l'explication de \fBCLONE_THREAD\fP plus lisible, le terme «\ thread\ » est utilisé pour parler des processus dans un même groupe de threads. Les groupes de threads sont une fonctionnalité ajoutées dans Linux 2.4 pour supporter la notion POSIX d'ensemble de threads partageant un même PID. En interne, ce PID partagé est appelé identifiant de groupe de threads (TGID).Depuis Linux 2.4, l'appel \fBgetpid\fP(2) renvoie l'identifiant du groupe de thread de l'appelant. Les threads dans un groupe peuvent être distingués par leur identifiant de thread (TID, unique sur le système). Le TID d'un nouveau thread est renvoyé par \fBclone\fP() au processus appelant, et un thread peut obtenir son propre TID en utilisant \fBgettid\fP(2). Quand \fBclone\fP() est appelé sans positionner \fBCLONE_THREAD\fP, le nouveau thread est placé dans un nouveau groupe de thread dont le TGID est identique au TID du nouveau thread. Ce thread est le \fIleader\fP du nouveau groupe. Un nouveau thread créé en utilisant \fBCLONE_THREAD\fP a le même processus père que l'appelant de \fBclone\fP() (de même qu'avec \fBCLONE_PARENT\fP), ainsi les appels à \fBgetppid\fP(2) renvoient la même valeur à tous les threads dans un même groupe. Lorsqu'un thread créé avec \fBCLONE_THREAD\fP termine, le thread qui a appelé \fBclone\fP() pour le créer ne reçoit pas le signal \fBSIGCHLD\fP (ou autre notification de terminaison)\ ; de même, l'état d'un tel thread ne peut être obtenu par \fBwait\fP(2). Le thread est dit \fIdétaché\fP. Lorsque tous les threads d'un groupe de threads terminent, le processus parent du groupe reçoit un signal \fBSIGCHLD\fP (ou autre indicateur de terminaison). Si l'un des threads dans un groupe de threads appelle \fBexecve\fP(2), tous les threads sauf le leader sont tués, et le nouveau programme est exécuté dans le leader du groupe de threads. Si l'un des threads dans un groupe crée un fils avec \fBfork\fP(2), n'importe lequel des threads du groupe peut utiliser \fBwait\fP(2) sur ce fils. Depuis Linux 2.5.35, l'attribut \fBCLONE_SIGHAND\fP de \fIflags\fP doit être positionné si \fBCLONE_THREAD\fP l'est. Depuis Linux\ 2.6.0\-test6, \fBCLONE_SIGHAND\fP a également besoin de \fBCLONE_THREAD\fP. Un signal peut être envoyé à un groupe de threads dans son ensemble (c'est\(hyà\(hydire à un TGID) avec \fBkill\fP(2), ou bien à un thread en particulier (à un TID) avec \fBtgkill\fP(2). Les gestions de signaux sont définies au niveau des processus\ : si un signal sans gestionnaire est reçu par un thread, il affectera (tuera, stoppera, relancera, ou sera ignoré par) tous les membres du groupe de threads. Chaque thread a son propre masque de signaux, défini par \fBsigprocmask\fP(2), mais les signaux peuvent être en attente soit pour le processus dans son ensemble (donc peut être reçu par n'importe lequel des threads du groupe), quand ils sont envoyés avec \fBkill\fP(2), soit pour un thread particulier, lorsqu'ils sont envoyés par \fBtgkill\fP(2). Un appel à \fBsigpending\fP(2) renvoie un ensemble de signaux qui est l'union des processus en attente pour le processus et ceux en attente pour le thread appelant. Si \fBkill\fP(2) est utilisé pour envoyer un signal à un groupe de threads, et si le groupe a installé un gestionnaire pour ce signal, alors le gestionnaire sera exécuté dans exactement un des membres du groupe de threads, choisi de façon arbitraire parmi ceux qui n'ont pas bloqué ce signal. Si plusieurs threads dans un groupe attendent le même signal en utilisant \fBsigwaitinfo\fP(2), le noyau choisira arbitrairement l'un d'entre eux pour délivrer le signal envoyé par \fBkill\fP(2). .TP \fBCLONE_UNTRACED\fP (depuis Linux 2.5.46) Si l'attribut \fBCLONE_UNTRACED\fP est positionné, alors un processus traçant le père ne peut pas forcer \fBCLONE_PTRACE\fP pour ce fils. .TP \fBCLONE_VFORK\fP (depuis Linux 2.2) Si le bit \fBCLONE_VFORK\fP est actif, l'exécution du processus appelant est suspendue jusqu'à ce que le fils libère ses ressources de mémoire virtuelle par un appel \fBexecve\fP(2) ou \fB_exit\fP(2) (comme avec \fBvfork\fP(2)). Si \fBCLONE_VFORK\fP n'est pas indiqué, alors les deux processus sont ordonnancés à partir de la fin de l'appel, et l'application ne doit pas considérer que l'ordre d'exécution soit déterminé. .TP \fBCLONE_VM\fP (depuis Linux 2.0) Si le bit \fBCLONE_VM\fP est actif, le processus appelant et le processus fils s'exécutent dans le même espace mémoire. En particulier, les écritures en mémoire effectuées par l'un des processus sont visibles par l'autre. De même toute projection en mémoire, ou toute suppression de projection, effectuées avec \fBmmap\fP(2) ou \fBmunmap\fP(2) par l'un des processus affectera également l'autre processus. Si \fBCLONE_VM\fP n'est pas actif, le processus fils utilisera une copie distincte de l'espace mémoire de l'appelant. Le cliché est réalisé lors de l'invocation de \fBclone\fP(). Les écritures ou les projections de fichiers en mémoire effectuées par un processus n'affectent pas l'autre processus, comme cela se passe avec \fBfork\fP(2). .SS "L'interface de l'appel système brut" L'appel système \fBclone\fP ressemble plus à \fBfork\fP(2), en ceci que l'exécution dans le processus fils continue à partir du point d'appel. À ce titre, les arguments \fIfn\fP et \fIarg\fP de la fonction d'enrobage de \fBclone\fP() sont omis. De plus, l'ordre des arguments change. L'interface de l'appel système brut sur x86 et sur plusieurs autres architectures est à peu près\ : .in +4 .nf \fBlong clone(unsigned long \fP\fIflags\fP\fB, void *\fP\fIchild_stack\fP\fB,\fP \fB void * \fP\fIptid\fP\fB, void *\fP\fIctid\fP\fB,\fP \fB struct pt_regs *\fP\fIregs\fP\fB);\fP .fi .in Une autre différence\ : pour l'appel système brut, l'argument \fIchild_stack\fP peut être nul, puisque la sémantique de copie\-en\-écriture assure que le fils recevra une copie indépendante des pages de la pile dès qu'un des deux processus la modifiera. Pour que cela fonctionne, il faut naturellement que \fBCLONE_VM\fP ne soit pas présent. Pour certaines architectures, l'ordre des arguments de l'appel système diffère de ce qui est décrit ci\-dessus. Sur les architectures score, microblaze, ARM, ARM 64, PA\-RISC, arc, Power PC, xtensa, et MIPS, l'ordre des quatrième et cinquième arguments est inversé. Sur les architectures cris et s390, l'ordre des premier et deuxième arguments est inversé. .SS "blackfin, m68k, et sparc" Les conventions de passage des arguments sur blackfin, m68k et sparc sont différentes de celles décrites précédemment. Pour plus de détails, se référer aux sources du noyau (et de glibc). .SS ia64 Sur ia64, une interface différente est utilisée\ : .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, pid_t *\fP\fIctid\fP\fB */ );\fP .fi .PP Le prototype présenté plus haut correspond à la fonction intermédiaire de glibc\ ; l'interface de l'appel système brut ne reconnaît pas les arguments \fIfn\fP ou \fIarg\fP, et modifie l'ordre des arguments, de sorte que \fIflags\fP devient le premier argument, et \fItls\fP le dernier. .PP \fB__clone2\fP() fonctionne comme \fBclone\fP(), aux différences suivantes près\ : \fIchild_stack_base\fP pointe sur la plus petite adresse de la pile du fils, et \fIstack_size\fP indique la taille de la pile sur laquelle pointe \fIchild_stack_base\fP. .SS "Linux 2.4 et antérieurs" Sous Linux\ 2.4 et plus anciens, \fBclone\fP() ne prend pas les arguments \fIptid\fP, \fItls\fP et \fIctid\fP. .SH "VALEUR RENVOYÉE" .\" gettid(2) returns current->pid; .\" getpid(2) returns current->tgid; En cas de réussite, le TID du processus fils est renvoyé dans le thread d'exécution de l'appelant. En cas d'échec, \-1 est renvoyé dans le contexte de l'appelant, aucun fils n'est créé, et \fIerrno\fP contiendra le code d'erreur. .SH ERREURS .TP \fBEAGAIN\fP Trop de processus en cours d'exécution. .TP \fBEINVAL\fP \fBCLONE_SIGHAND\fP a été spécifié mais pas \fBCLONE_VM\fP (depuis 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 a été spécifié mais pas \fBCLONE_SIGHAND\fP (depuis Linux 2.5.35). .TP \fBEINVAL\fP Les attributs \fBCLONE_NEWNS\fP et \fBCLONE_FS\fP ont été indiqués simultanément dans \fIflags\fP. .TP \fBEINVAL\fP Les attributs \fBCLONE_NEWIPC\fP et \fBCLONE_SYSVSEM\fP ont été indiqués simultanément dans \fIflags\fP. .TP \fBEINVAL\fP Les attributs \fBCLONE_NEWPID\fP et \fBCLONE_THREAD\fP ont été indiqués simultanément dans \fIflags\fP. .TP \fBEINVAL\fP Renvoyée par \fBclone\fP() quand une valeur nulle a été indiquée pour le paramètre \fIchild_stack\fP. .TP \fBEINVAL\fP \fBCLONE_NEWIPC\fP a été indiqué dans \fIflags\fP, mais le noyau n'a pas été configuré avec les options \fBCONFIG_SYSVIPC\fP et \fBCONFIG_IPC_NS\fP. .TP \fBEINVAL\fP \fBCLONE_NEWNET\fP a été indiqué dans \fIflags\fP, mais le noyau n'a pas été configuré avec l'option \fBCONFIG_NET_NS\fP. .TP \fBEINVAL\fP \fBCLONE_NEWPID\fP a été indiqué dans \fIflags\fP, mais le noyau n'a pas été configuré avec l'option \fBCONFIG_PID_NS\fP. .TP \fBEINVAL\fP \fBCLONE_NEWUTS\fP a été indiqué dans \fIflags\fP, mais le noyau n'a pas été configuré avec l'option \fBCONFIG_UTS\fP. .TP \fBENOMEM\fP Pas assez de mémoire pour copier les parties du contexte du processus appelant qui doivent être dupliquées, ou pour allouer une structure de tâche pour le processus fils. .TP \fBEPERM\fP \fBCLONE_NEWIPC\fP, \fBCLONE_NEWNET\fP, \fBCLONE_NEWNS\fP, \fBCLONE_NEWPID\fP ou \fBCLONE_NEWUTS\fP a été spécifié par un processus non privilégié (processus sans \fBCAP_SYS_ADMIN\fP). .TP \fBEPERM\fP \fBCLONE_PID\fP a été réclamé par un processus autre que le processus 0. .SH VERSIONS Il n'y a pas de définition pour \fBclone\fP() dans la libc5. glibc2 fournit une définition de \fBclone\fP() comme décrit ici. .SH CONFORMITÉ \fBclone\fP() est spécifique à Linux et ne doit pas être utilisé dans des programmes conçus pour être portables. .SH NOTES Dans les noyaux 2.4.x, \fBCLONE_THREAD\fP ne rend pas en général le processus père de l'appelant père du nouveau thread. Cependant, pour les versions 2.4.7 à 2.4.18 du noyau, l'attribut \fBCLONE_THREAD\fP impliquait \fBCLONE_PARENT\fP (de même qu'avec les noyaux 2.6). \fBCLONE_DETACHED\fP a existé pendant un moment (introduit dans 2.5.32): le père ne veut pas de signal à la mort du fils. Dans 2.6.2, la nécessité d'utiliser ce paramètre avec \fBCLONE_THREAD\fP a été supprimée. Cet attribut est toujours défini, mais n'a plus aucun effet. Sur i386, \fBclone\fP() ne devrait pas être appelé via vsyscall, mais directement en utilisant \fIint $0x80\fP. .SH BOGUES Les versions de la bibliothèque C GNU qui gèrent la bibliothèque de gestion des threads NPTL contiennent une fonction enveloppe pour \fBgetpid\fP(2) qui effectue un cache des PID. Ce cache nécessite une prise en charge par l'enveloppe de \fBclone\fP() de la glibc, mais telle qu'il est actuellement implémenté, le cache peut ne pas être à jour sous certaines circonstances. En particulier, si un signal est distribué à un fils juste après l'appel à \fBclone\fP(), alors un appel à \fBgetpid\fP(2) dans le gestionnaire de signaux du signal peut renvoyer le PID du processus appelant (le père), si l'enveloppe de clone n'a toujours pas eu le temps de mettre le cache de PID à jour pour le fils. (Cette discussion ignore le cas où le fils a été créé en utilisant \fBCLONE_THREAD\fP, quand \fBgetpid\fP(2) \fIdoit\fP renvoyer la même valeur pour le fils et pour le processus qui a appelé \fBclone\fP(), puisque l'appelant et le fils se trouvent dans le même groupe de threads. Ce problème de cache n'apparaît pas non plus si le paramètre \fIflags\fP contient \fBCLONE_VM\fP.) Pour obtenir la véritable valeur, il peut être nécessaire d'utiliser quelque chose comme ceci\ : .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 EXEMPLE Le programme suivant décrit l'usage de \fBclone\fP() dans le but de créer un processus fils qui s'exécute dans un espace de noms UTS distinct. Le processus fils change le nom d'hôte (hostname) dans son propre espace UTS. Les processus père et fils affichent chacun le nom d'hôte qui leur correspond, permettant ainsi de constater la différence des noms d'hôtes dans leurs espaces de noms UTS respectifs. .SS "Code du programme" .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 /* Commencer la fonction pour le fils cloné */ childFunc(void *arg) { struct utsname uts; /* Modifier le nom d'hôte dans l'espace de noms UTS du processus fils */ if (sethostname(arg, strlen(arg)) == \-1) errExit("sethostname"); /* Récupérer et afficher le nom d'hôte */ if (uname(&uts) == \-1) errExit("uname"); printf("uts.nodename dans le fils\ : %s\en", uts.nodename); /* Rester en sommeil (fonction sleep) pour conserver l'espace de noms ouvert pendant un moment. Cela permet de réaliser quelques expérimentations — par exemple, un autre processus pourrait rejoindre l'espace de noms. */ sleep(200); return 0; /* Le processus fils se termine à ce moment */ } #define STACK_SIZE (1024 * 1024) /* Taille de la pile pour le fils cloné */ int main(int argc, char *argv[]) { char *stack; /* Début du tampon de la pile */ char *stackTop; /* Fin du tampon de la pile */ pid_t pid; struct utsname uts; if (argc < 2) { fprintf(stderr, "Utilisation\ : %s \en", argv[0]); exit(EXIT_SUCCESS); } /* Allouer la pile pour le processus fils */ stack = malloc(STACK_SIZE); if (stack == NULL) errExit("malloc"); stackTop = stack + STACK_SIZE; /* Pile supposée s'étendre vers le bas */ /* Créer un processus fils disposant de son propre espace de noms UTS\ ; le processus fils débute son exécution dans childFunc() */ pid = clone(childFunc, stackTop, CLONE_NEWUTS | SIGCHLD, argv[1]); if (pid == \-1) errExit("clone"); printf("clone() a renvoyé %ld\en", (long) pid); /* C'est ici que le processus père échoue */ sleep(1); /* Laisser le temps au processus fils de changer son nom d'hôte */ /* Afficher le nom d'hôte pour l'espace de noms UTS du processus père. Celui\-ci sera différent du nom d'hôte pour l'espace de noms UTS du processus fils. */ if (uname(&uts) == \-1) errExit("uname"); printf("uts.nodename dans le père\ : %s\en", uts.nodename); if (waitpid(pid, NULL, 0) == \-1) /* Attendre le processus fils */ errExit("waitpid"); printf("Fin du processus fils\en"); exit(EXIT_SUCCESS); } .fi .SH "VOIR AUSSI" \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), \fBpthreads\fP(7) .SH COLOPHON Cette page fait partie de la publication 3.65 du projet \fIman\-pages\fP Linux. Une description du projet et des instructions pour signaler des anomalies peuvent être trouvées à l'adresse \%http://www.kernel.org/doc/man\-pages/. .SH TRADUCTION Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a par l'équipe de traduction francophone au sein du projet perkamon . .PP Christophe Blaess (1996-2003), Alain Portal (2003-2006). Julien Cristau et l'équipe francophone de traduction de Debian\ (2006-2009). .PP Veuillez signaler toute erreur de traduction en écrivant à ou par un rapport de bogue sur le paquet \fBmanpages\-fr\fR. .PP Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la commande «\ \fBman\ \-L C\fR \fI
\fR\ \fI\fR\ ».