.\" -*- 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 "19 novembre 2019" Linux "Manuel du programmeur Linux" .SH NOM clone, __clone2, clone3 \- Créer un processus enfant (child) .SH SYNOPSIS .nf /* Prototype de la fonction enveloppe de la glibc */ .PP \fB#define _GNU_SOURCE\fP \fB#include \fP .PP \fBint clone(int (*\fP\fIfn\fP\fB)(void *), void *\fP\fIstack\fP\fB, int \fP\fIflags\fP\fB, void *\fP\fIarg\fP\fB, ... \fP \fB /* pid_t *\fP\fIparent_tid\fP\fB, void *\fP\fItls\fP\fB, pid_t *\fP\fIchild_tid\fP\fB */ );\fP .PP /* Pour le prototype de l'appel système clone() brut, voir REMARQUES */ .PP \fBlong clone3(struct clone_args *\fP\fIcl_args\fP\fB, size_t \fP\fIsize\fP\fB);\fP .fi .PP \fIRemarque\fP\ : il n'y pas encore d'enveloppe glibc pour \fBclone3\fP()\ ; voir les REMARQUES. .SH DESCRIPTION Ces appels système créent un nouveau processus «\ enfant\ », de façon analogue à \fBfork\fP(2). .PP Contrairement à \fBfork\fP(2), ces appels système offrent un contrôle plus précis du contexte d'exécution partagé entre le processus appelant et son enfant. Par exemple, en utilisant ces appels système, l'appelant peut contrôler si les deux processus partagent ou non l'espace d'adresse virtuel, la table des descripteurs de fichier et celle des gestionnaires de signal. Ces appels système permettent également au nouveau processus enfant d'aller dans un \fBnamespaces\fP(7) à part. .PP Remarquez que dans cette page de manuel, «\ processus appelant\ » correspond généralement à «\ processus parent\ ». Mais voir la description de \fBCLONE_PARENT\fP ci\-dessous. .PP Cette page décrit les interfaces suivantes\ : .IP * 3 Cette page présente à la fois la fonction enveloppe \fBclone\fP() de la glibc et l'appel système sous\-jacent sur lequel elle s'appuie. Le texte principal décrit la fonction enveloppe\ ; les différences avec l'appel système brut sont précisées vers la fin de cette page. .IP * Le nouvel appel système \fBclone3\fP(). .PP .\" Dans la suite de cette page, le terme «\ appel clone\ » est utilisé pour évoquer les détails applicables à toutes ces interfaces, .SS "La fonction enveloppe clone()" .PP Quand le processus enfant est créé par la fonction enveloppe \fBclone\fP(), il débute son exécution par un appel à la fonction vers laquelle pointe l'argument \fIfn\fP (cela est différent de \fBfork\fP(2), pour lequel l'exécution continue dans le processus enfant à partir du moment de l'appel de \fBfork\fP(2)). L'argument \fIarg\fP est passé comme argument de la fonction \fIfn\fP. .PP Quand la fonction \fIfn\fP(\fIarg\fP) renvoie, le processus enfant se termine. La valeur entière renvoyée par \fIfn\fP est utilisée comme code de retour du processus enfant. 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. .PP L'argument \fIstack\fP indique l'emplacement de la pile utilisée par le processus enfant. Comme les processus enfant et appelant peuvent partager de la mémoire, il n'est généralement pas possible pour l'enfant d'utiliser la même pile que son parent. Le processus appelant doit donc préparer un espace mémoire pour stocker la pile de son enfant, 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 \fIstack\fP doit pointer sur la plus haute adresse de l'espace mémoire prévu pour la pile du processus enfant. Remarquez que \fBclone\fP() ne fournit aucun moyen pour que l'appelant puisse informer le noyau de la taille de la zone de la pile. .PP .\" Les paramètres restant à \fBclone\fP() sont décrits ci\-dessous. .SS clone3() .PP L'appel système \fBclone3\fP() fournit un sur\-ensemble de la fonctionnalité de l'ancienne interface de \fBclone\fP(). Il offre également un certain nombre d'améliorations de l'API dont\ : un espace pour des bits d'attributs supplémentaires, une séparation plus propre dans l'utilisation de plusieurs paramètres et la possibilité d'indiquer la taille de la zone de la pile de l'enfant. .PP Comme avec \fBfork\fP(2), \fBclone3\fP() renvoie à la fois au parent et à l'enfant. Il renvoie \fB0\fP dans le processus enfant et il renvoie le PID de l'enfant dans le parent. .PP Le paramètre \fIcl_args\fP de \fBclone3\fP() est une structure ayant la forme suivante\ : .PP .in +4n .EX struct clone_args { u64 flags; /* Masque de bit flags */ u64 pidfd; /* Où stocker le descripteur de fichier du PID (\fIpid_t *\fP) */ u64 child_tid; /* Où stocker le TID de l'enfant, dans la mémoire de l'enfant (\fIpid_t *\fP) */ u64 parent_tid; /* Où stocker le TID de l'enfant, dans la mémoire du parent (\fIint *\fP) */ u64 exit_signal; /* Signal à envoyer au parent quand l'enfant se termine */ u64 stack; /* Pointeur vers l'octet le plus faible de la pile */ u64 stack_size; /* Taille de la pile */ u64 tls; /* Emplacement du nouveau TLS */ }; .EE .in .PP Le paramètre \fIsize\fP fourni à \fBclone3\fP() doit être initialisé à la taille de cette structure (l'existence du paramètre \fIsize\fP autorise des extensions futures de la structure \fIclone_args\fP). .PP La pile du processus enfant est indiquée avec \fIcl_args.stack\fP, qui pointe vers l'octet le plus faible de la zone de la pile, et avec \fIcl_args.stack_size\fP, qui indique la taille de la pile en octets. Si l'attribut \fBCLONE_VM\fP est indiqué (voir ci\-dessous), une pile doit être explicitement allouée et indiquée. Sinon, ces deux champs peuvent valoir NULL et \fB0\fP, ce qui amène l'enfant à utiliser la même zone de pile que son parent (dans l'espace d'adressage virtuel de son propre enfant). .PP .\" Les autres champs du paramètre \fIcl_args\fP sont abordés ci\-dessous. .SS "Équivalence entre les paramètres de clone() et de clone3()" .PP Contrairement à l'ancienne interface \fBclone\fP(), où les paramètres sont passés individuellement, ceux de la nouvelle interface \fBclone3\fP() sont empaquetés dans la structure \fIclone_args\fP présentée ci\-dessus. Cette structure permet de passer un ensemble d'informations à l’aide des arguments de \fBclone\fP(). .PP Le tableau suivant montre l'équivalence entre les paramètres de \fBclone\fP() et les champs du paramètre \fIclone_args\fP fournis à \fBclone3\fP()\ : .RS .TS lb lb lb l l l li li l. clone() clone(3) Notes Champ \fIcl_args\fP attributs & ~0xff attributs Pour la plupart des attributs\ ; détails ci\-dessous parent_tid pidfd Voir CLONE_PIDFD child_tid child_tid Voir CLONE_CHILD_SETTID parent_tid parent_tid Voir CLONE_PARENT_SETTID attributs & 0xff exit_signal pile pile \fI\-\-\-\fP stack_size tls tls Voir CLONE_SETTLS .TE .RE .\" .SS "Signal de fin de l'enfant" .PP .\" Quand le processus enfant se termine, un signal peut être envoyé au parent. Le signal de fin est indiqué dans l'octet de poids faible de \fIflags\fP (\fBclone\fP()) ou dans \fIcl_args.exit_signal\fP (\fBclone3\fP()). 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 de l'enfant avec \fBwait\fP(2). Si aucun signal n'est indiqué (donc zéro), le processus parent ne sera pas notifié de la terminaison de l'enfant. .SS "Le masque flags" .PP Tant \fBclone\fP() que \fBclone3\fP() permettent d'utiliser un masque de bit flags pour modifier leur comportement, et elles permettent à l'appelant d'indiquer ce qui est partagé entre le processus appelant et son enfant. Ce masque de bit \- le paramètre \fIflags\fP de \fBclone\fP() ou le champ \fIcl_args.flags\fP passé à \fBclone3\fP() \- est désigné comme le masque \fIflags\fP dans le reste de cette page. .PP Le masque \fIflags\fP est indiqué comme un OU bit à bit de zéro ou plus des constantes ci\-dessous. Sauf explicitement indiqué, ces attributs sont disponibles (et ont le même effet) dans \fBclone\fP() et dans \fBclone3\fP(). .TP \fBCLONE_CHILD_CLEARTID\fP (depuis Linux 2.5.49) Effacer (zéro) l'ID du thread enfant situé là où pointe \fIchild_tid\fP (\fBclone\fP()) ou \fIcl_args.child_tid\fP (\fBclone3\fP()) dans la mémoire de l'enfant lorsqu'il existe, et provoquer le réveil avec 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 de l'enfant là où pointe \fIchild_tid\fP ((\fBclone\fP()) ou \fIcl_args.child_tid\fP (\fBclone3\fP()) dans la mémoire de l'enfant. L'opération d'enregistrement se termine avant que l'appel clone ne redonne le contrôle à l'espace utilisateur dans le processus enfant (remarquez que l'opération d'enregistrement se termine avant que l'appel clone ne renvoie au processus parent, ce qui sera pertinent si l'attribut \fBCLONE_VM\fP est également utilisé). .TP \fBCLONE_DETACHED\fP (historique) .\" added in 2.5.32; removed in 2.6.0-test4 Pendant un moment (pendant la série de versions au cours du développement de Linux 2.5), il y a eu un attribut \fBCLONE_DETACHED\fP, avec lequel le parent ne recevait pas de signal quand l'enfant se terminait. Au final, l'effet de cet attribut a été inhibé par l'attribut \fBCLONE_THREAD\fP et quand Linux 2.6.0 a été publié, cet attribut n'avait pas d'effet. À partir de Linux 2.6.2, il n'a plus été nécessaire de fournir cet attribut avec \fBCLONE_THREAD\fP. .IP Cet attribut est toujours défini, mais il est généralement ignoré lors d'un appel \fBclone\fP(). Toutefois, voir la description de \fBCLONE_PIDFD\fP pour certaines exceptions. .TP \fBCLONE_FILES\fP (depuis Linux 2.0) Si l'attribut \fBCLONE_FILES\fP est positionné, le processus appelant et le processus enfant partagent la même table de 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 un processus qui partage une table de descripteurs de fichier appelle \fBexecve\fP(2), sa table est dupliquée (non partagée). .IP Si \fBCLONE_FILES\fP n'est pas positionné, le processus enfant hérite d'une copie des descripteurs de fichier ouverts par l'appelant au moment de l'appel \fBclone\fP(). Les opérations d'ouverture et de fermeture ou de modification d'attributs du descripteur de fichier subséquentes, effectuées par le processus appelant ou son enfant, ne concernent pas l'autre processus. Remarquez toutefois que les copies des descripteurs de fichier dans l'enfant sont associées aux mêmes descriptions de fichiers ouverts que les descripteurs de fichier correspondants dans le processus appelant, partageant ainsi les attributs de position et d’états du fichier (consultez \fBopen\fP(2)). .TP \fBCLONE_FS\fP (depuis Linux 2.0) Si l'attribut \fBCLONE_FS\fP est positionné, le processus appelant et le processus enfant partagent les mêmes informations concernant le système de fichiers. Cela 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. .IP Si \fBCLONE_FS\fP n'est pas positionné, le processus enfant travaille sur une copie des informations de l'appelant concernant le système de fichiers au moment de l'appel clone. Les appels à \fBchroot\fP(2), \fBchdir\fP(2), \fBumask\fP(2) effectués ensuite 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. .IP .\" 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ées\-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. .IP Si le noyau n'a pas été configuré avec l'option \fBCONFIG_BLOCK\fP, cet attribut n'a aucun effet. .TP \fBCLONE_NEWCGROUP\fP (depuis Linux 4.6) Créer le processus dans un nouvel espace de noms cgroup. Si cet attribut n'est pas invoqué, alors (comme pour \fBfork\fP(2)) le processus est créé dans le même espace de noms cgroup que le processus appelant. .IP Pour plus d'informations sur les espaces de noms cgroup, consultez \fBcgroup_namespaces\fP(7). .IP .\" Seul un processus disposant de privilèges (\fBCAP_SYS_ADMIN\fP) peut utiliser \fBCLONE_NEWCGROUP\fP. .TP \fBCLONE_NEWIPC\fP (depuis Linux 2.6.19) Si \fBCLONE_NEWIPC\fP est invoqué, alors le processus est créé dans un nouvel espace de noms utilisateur IPC. Si cet attribut n'est pas invoqué, alors (comme pour \fBfork\fP(2)) le processus est créé dans le même espace de noms utilisateur IPC que le processus appelant. .IP Pour plus d'informations sur les espaces de noms IPC, reportez vous à \fBipc_namespaces\fP(7). .IP Seul un processus disposant de privilèges (\fBCAP_SYS_ADMIN\fP) peut utiliser \fBCLONE_NEWIPC\fP. Cet attribut ne peut pas être employé en association avec \fBCLONE_SYSVSEM\fP. .TP \fBCLONE_NEWNET\fP (depuis Linux 2.6.24) (L'implémentation de cet attribut n'est complète que depuis le noyau 2.6.29.) .IP Si \fBCLONE_NEWNET\fP est invoqué, alors le processus est créé dans un nouvel espace de noms réseau. Si cet attribut n'est pas invoqué, alors (comme pour \fBfork\fP(2)) le processus est créé dans le même espace de noms réseau que le processus appelant. .IP Pour plus d'informations sur les espaces de noms réseau, reportez vous à \fBnetwork_namespaces\fP(7). .IP Seul un processus disposant de privilèges (\fBCAP_SYS_ADMIN\fP) peut appeler \fBCLONE_NEWNET\fP. .TP \fBCLONE_NEWNS\fP (depuis Linux 2.4.19) Si l'attribut \fBCLONE_NEWNS\fP est invoqué, l'enfant cloné démarre dans un nouvel espace de noms montage, initialisé avec une copie de l'espace de noms du parent. Si \fBCLONE_NEWNS\fP n'est pas invoqué, alors l'enfant existe dans le même espace de noms montage que le parent. .IP Pour plus d'informations sur les espaces de noms montage, consultez \fBnamespaces\fP(7) et \fBmount_namespaces\fP(7). .IP .\" See https://lwn.net/Articles/543273/ Seul un processus disposant de privilèges (\fBCAP_SYS_ADMIN\fP) peut utiliser 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 clone. .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 invoqué, alors le processus est créé dans un nouvel espace de noms PID. Si cet attribut n'est pas invoqué, alors (comme pour \fBfork\fP(2)) le processus est créé dans le même espace de noms PID que le processus appelant. .IP Pour plus d'informations sur les espaces de noms PID, consultez \fBnamespaces\fP(7) et \fBpid_namespaces\fP(7). .IP Seul un processus disposant de privilèges (\fBCAP_SYS_ADMIN\fP) peut utiliser \fBCLONE_NEWPID\fP. Cet attribut ne peut pas être utilisé en association avec \fBCLONE_THREAD\fP ou avec \fBCLONE_PARENT\fP. .TP \fBCLONE_NEWUSER\fP (Cet attribut est apparu dans \fBclone\fP() pour la première fois dans Linux 2.6.23, les sémantiques actuelles de \fBclone\fP() ont été ajoutées dans Linux 3.5, et les derniers modules rendant les espaces de noms utilisateur complètement opérationnels sont apparus dans Linux 3.8.) .IP Si \fBCLONE_NEWUSER\fP est invoqué, alors le processus est créé dans un nouvel espace de noms utilisateur. Si cet attribut n'est pas invoqué, alors (comme pour \fBfork\fP(2)) le processus est créé dans le même espace de noms utilisateur que le processus appelant. .IP Pour plus d'informations sur les espaces de noms utilisateur, consultez \fBnamespaces\fP(7) et \fBuser_namespaces\fP(7). .IP .\" Before Linux 2.6.29, it appears that only CAP_SYS_ADMIN was needed Avant Linux 3.8, les processus appelant devaient disposer de trois capacités pour utiliser \fBCLONE_NEWUSER\fP\ : \fBCAP_SYS_ADMIN\fP, \fBCAP_SETUID\fP et \fBCAP_SETGID\fP. À partir de Linux 3.8, il n'est plus nécessaire de disposer de privilèges pour créer des espaces de noms utilisateur. .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. Cet attribut ne peut pas être utilisé en association avec \fBCLONE_THREAD\fP ou avec \fBCLONE_PARENT\fP. Pour des raisons de sécurité, \fBCLONE_NEWUSER\fP ne peut pas être utilisé en association avec \fBCLONE_FS\fP. .TP \fBCLONE_NEWUTS\fP (depuis Linux 2.6.19) Si \fBCLONE_NEWUTS\fP est défini, créez le processus dans un nouvel espace de noms 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. .IP Pour obtenir plus d'informations sur les espaces de noms UTS, consultez \fBnamespaces\fP(7). .IP Seul un processus disposant de privilèges (\fBCAP_SYS_ADMIN\fP) peut utiliser \fBCLONE_NEWUTS\fP. .TP \fBCLONE_PARENT\fP (depuis Linux 2.3.12) Si \fBCLONE_PARENT\fP est présent, le parent du nouvel enfant (comme il est indiqué par \fBgetppid\fP(2)) sera le même que celui du processus appelant. .IP Si \fBCLONE_PARENT\fP n'est pas fourni, alors (comme pour \fBfork\fP(2)) le parent du processus enfant sera le processus appelant. .IP Remarquez que c'est le processus parent, tel qu'indiqué par \fBgetppid\fP(2), qui est notifié lors de la fin de l'enfant. Ainsi, si \fBCLONE_PARENT\fP est présent, alors c'est le parent 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 à l'endroit vers lequel pointe \fIparent_tid\fP (\fBclone\fP()) ou \fIcl_args.child_tid\fP (\fBclone3\fP()) dans la mémoire du parent. (Dans Linux 2.5.32\-2.5.48 il y a un attribut \fBCLONE_SETTID\fP qui fait cela.) L'opération d'enregistrement se termine avant que l'appel clone ne redonne le contrôle à l'espace utilisateur. .TP \fBCLONE_PID\fP (Linux 2.0 à 2.5.15) Si l'attribut \fBCLONE_PID\fP est positionné, les processus appelant et enfant ont le même numéro de processus. C'est bien pour hacker le système, mais autrement il n'est plus utilisé. Depuis Linux 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. Si bien que le noyau ignorait silencieusement le bit s'il était indiqué dans le masque \fIflags\fP. Bien plus tard, le même bit a été recyclé pour être utilisé comme attribut de \fBCLONE_PIDFD\fP. .TP \fBCLONE_PIDFD\fP (depuis Linux 5.2) .\" commit b3e5838252665ee4cfa76b82bdf1198dca81e5be Si cet attribut est indiqué, un descripteur de fichier PID renvoyant au processus enfant est alloué et placé à un endroit donné dans la mémoire du parent. L'attribut close\-on\-exec est positionné sur ce nouveau descripteur de fichier. Les descripteurs de fichier PID peuvent être utilisés pour des objectifs décrits dans \fBpidfd_open\fP(2). .RS .IP * 3 Quand on utilise \fBclone3\fP(), le descripteur de fichier PID est placé à un endroit vers lequel pointe \fIcl_args.pidfd\fP. .IP * Quand on utilise \fBclone\fP(), le descripteur de fichier PID est placé à un endroit vers lequel pointe \fIparent_tid\fP. Comme le paramètre \fIparent_tid\fP est utilisé pour renvoyer le descripteur de fichier PID, \fBCLONE_PIDFD\fP ne peut pas être utilisé avec \fBCLONE_PARENT_SETTID\fP lors d'un appel \fBclone\fP(). .RE .IP Il n'est pas possible actuellement d'utiliser cet attribut avec \fBCLONE_THREAD.\fP Cela veut dire que le processus identifié par le descripteur de fichier PID sera toujours un leader dans le groupe de threads. .IP Si l'attribut obsolète \fBCLONE_DETACHED\fP est indiqué avec \fBCLONE_PIDFD\fP lors d'un appel à \fBclone\fP(), une erreur est renvoyée. Une erreur se produit aussi si \fBCLONE_DETACHED\fP est spécifié lors d'un appel à \fBclone3\fP(). Ce comportement garantit que le bit qui correspond à \fBCLONE_DETACHED\fP pourra être utilisé à l'avenir pour des fonctionnalités supplémentaires du descripteur de fichier PID. .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 l'enfant sera également suivi (consultez \fBptrace\fP(2)). .TP \fBCLONE_SETTLS\fP (depuis Linux 2.5.32) Le descripteur TLS (Thread Local Storage) est positionné sur \fItls\fP. .IP L'interprétation de \fItls\fP et les effets qui en découlent dépendent de l'architecture. Sur x86, \fItls\fP est interprété comme une \fIstruct user_desc\ *\fP (voir \fBset_thread_area\fP(2)). Sur x86\-64, il s'agit de la nouvelle valeur à positionner pour le registre de base %fs (voir le paramètre \fBARCH_SET_FS\fP de \fBarch_prctl\fP(2)). Sur les architectures ayant un registre TLS dédié, il s'agit de la nouvelle valeur de ce registre. .IP L'utilisation de cet attribut exige une connaissance détaillée et n'est généralement pas souhaitable, sauf dans l'implémentation de bibliothèques de gestion des threads. .TP \fBCLONE_SIGHAND\fP (depuis Linux 2.0) Si l'attribut \fBCLONE_SIGHAND\fP est positionné, le processus appelant et le processus enfant partagent la même table de gestionnaires de signaux. Si l'appelant, ou l'enfant, 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 l'enfant ont toujours des masques de signaux distincts, et leurs ensembles de signaux bloqués sont indépendants. L'un des processus peut donc bloquer ou débloquer un signal en utilisant \fBsigprocmask\fP(2) sans affecter l'autre processus. .IP Si \fBCLONE_SIGHAND\fP n'est pas utilisé, le processus enfant 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. .IP .\" Precisely: Linux 2.6.0-test6 Depuis Linux 2.6.0, le masque \fIflags\fP doit aussi inclure \fBCLONE_VM\fP si \fBCLONE_SIGHAND\fP est spécifié .TP \fBCLONE_STOPPED\fP (depuis Linux 2.6.0) .\" Precisely: Linux 2.6.0-test2 Si l'attribut \fBCLONE_STOPPED\fP est positionné, l'enfant est initialement stoppé (comme s'il avait reçu le signal \fBSIGSTOP\fP), et doit être relancé en lui envoyant le signal \fBSIGCONT\fP. .IP .\" glibc 2.8 removed this defn from bits/sched.h Cet attribut a été rendu \fIobsolète\fP par Linux 2.6.25, puis il a été \fIsupprimé\fP dans Linux 2.6.38. Depuis lors, le noyau l'ignore silencieusement sans erreur. À partir de Linux 4.6, le même bit a été réutilisé comme attribut de \fBCLONE_NEWCGROUP\fP. .TP \fBCLONE_SYSVSEM\fP (depuis Linux 2.5.10) Si \fBCLONE_SYSVSEM\fP est positionné, l'enfant et le processus appelant partagent la même liste de compteurs «\ undo\ » pour les sémaphores System\ V (consultez \fBsemop\fP(2)). Dans ce cas, cette liste regroupe toutes les valeurs \fIsemadj\fP des processus partageant cette liste, et les modifications des sémaphores sont effectuées seulement lorsque le dernier processus de la liste se termine (ou cesse de partager la liste en invoquant \fBunshare\fP(2)). Si cet attribut n'est pas utilisé, l'enfant a une liste «\ undo\ » séparée, initialement vide. .TP \fBCLONE_THREAD\fP (depuis Linux 2.4.0) .\" Precisely: Linux 2.6.0-test8 Si \fBCLONE_THREAD\fP est présent, l'enfant 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. .IP Les groupes de threads sont une fonctionnalité ajoutée 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. .IP 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). .IP Quand clone 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. .IP Un nouveau thread créé en utilisant \fBCLONE_THREAD\fP a le même processus parent 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 pas être obtenu par \fBwait\fP(2). Le thread est dit \fIdétaché\fP. .IP 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). .IP 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. .IP Si l'un des threads dans un groupe crée un enfant avec \fBfork\fP(2), n'importe lequel des threads du groupe peut utiliser \fBwait\fP(2) sur cet enfant. .IP .\" Precisely: Linux 2.6.0-test6 Depuis Linux 2.5.35, le masque \fIflags\fP doit aussi inclure \fBCLONE_SIGHAND\fP si \fBCLONE_THREAD\fP est spécifié (et remarquez que depuis Linux\ 2.6.0, \fBCLONE_SIGHAND\fP a également besoin de \fBCLONE_VM\fP). .IP 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. .IP Chaque thread a son propre masque de signal, tel que défini par \fBsigprocmask\fP(2). .IP Un signal peut être adressé à un processus ou à un thread. S'il s'adresse à un processus, il cible un groupe de threads (c'est\-à\-dire un TGID), et il est envoyé à un thread choisi arbitrairement parmi ceux ne bloquant pas les signaux. Un signal peut s'adresser à un processus car il est généré par le noyau pour d'autres raisons qu'une exception matériel, ou parce qu'il a été envoyé en utilisant \fBkill\fP(2) ou \fBsigqueue\fP(3). Si un signal s'adresse à un thread, il cible (donc est envoyé) à un thread spécifique. Un signal peut s'adresser à un thread du fait d'un envoi par \fBtgkill\fP(2) ou \fBpthread_sigqueue\fP(3), ou parce que le thread a exécuté une instruction en langage machine qui a provoqué une exception matériel (comme un un accès invalide en mémoire, provoquant \fBSIGSEGV\fP, ou une exception de virgule flottante provoquant un \fBSIGFPE\fP). .IP Un appel à \fBsigpending\fP(2) renvoie un jeu de signaux qui réunit les signaux en attente adressés au processus et ceux en attente pour le thread appelant. .IP Si un signal adressé à un processus est envoyé à 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 recevoir le signal. .TP \fBCLONE_UNTRACED\fP (depuis Linux 2.5.46) Si l'attribut \fBCLONE_UNTRACED\fP est positionné, alors un processus traçant le parent ne peut pas forcer \fBCLONE_PTRACE\fP pour cet enfant. .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 l'enfant libère ses ressources de mémoire virtuelle par un appel \fBexecve\fP(2) ou \fB_exit\fP(2) (comme avec \fBvfork\fP(2)). .IP 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 devrait pas considérer que l'ordre d'exécution est déterminé dans un ordre particulier. .TP \fBCLONE_VM\fP (depuis Linux 2.0) Si le bit \fBCLONE_VM\fP est actif, le processus appelant et le processus enfant 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ée avec \fBmmap\fP(2) ou \fBmunmap\fP(2) par l'un des processus affectera également l'autre processus. .IP Si \fBCLONE_VM\fP n'est pas actif, le processus enfant utilisera une copie distincte de l'espace mémoire de l'appelant au moment de l'appel clone. Les écritures ou les associations/désassociations de fichiers en mémoire effectuées par un processus n'affectent pas l'autre processus, comme cela se passe avec \fBfork\fP(2). .SH NOTES .PP Une utilisation de ces appels systèmes consiste à implémenter des threads\ : un programme est scindé en plusieurs lignes de contrôle, s'exécutant simultanément dans un espace mémoire partagée. .PP La glibc ne fournit pas d'enveloppe pour \fBclone3\fP()\ ; appelez\-la en utilisant \fBsyscall\fP(2). .PP .\" Remarquez que la fonction enveloppe \fBclone\fP() de la glibc effectue des changements dans la mémoire vers laquelle pointe \fIstack\fP (ce sont des changements nécessaires pour positionner correctement la pile pour l'enfant) \fIavant\fP de recourir à l'appel système \fBclone\fP(). Dès lors, lorsque \fBclone\fP() est utilisé pour créer des enfants de manière récursive, n'utilisez pas le tampon servant à la pile du parent en tant que pile de l'enfant. .SS "différences entre bibliothèque C et noyau" L'appel système \fBclone\fP brut ressemble plus à \fBfork\fP(2), en ceci que l'exécution dans le processus enfant continue à partir du point d'appel. À ce titre, les arguments \fIfn\fP et \fIarg\fP de la fonction enveloppe de \fBclone\fP() sont omis. .PP Contrairement à l'enveloppe de la glibc, l'appel système brut \fBclone\fP() accepte NULL en paramètre de \fIstack\fP (et de même, \fBclone3\fP() permet à \fIcl_args.stack\fP d'être NULL). Dans ce cas l'enfant utilise une copie de la pile du parent (la sémantique de copie\-en\-écriture assure que l'enfant 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 (si l'enfant \fIpartage\fP la mémoire du parent du fait d'une utilisation de \fBCLONE_VM\fP, aucune duplication via la copie\-en\-écriture ne se produit et il peut s'ensuivre probablement un grand chaos). .PP L'ordre des paramètres change aussi dans l'appel système brut et des variations existent dans les paramètres en fonction des architectures, comme indiqué dans les paragraphes suivants. .PP L'interface de l'appel système brut sur des architectures x86\-64 et quelques autres (dont sh, tile et alpha), est\ : .PP .in +4 .EX \fBlong clone(unsigned long \fP\fIflags\fP\fB, void *\fP\fIstack\fP\fB,\fP \fB int *\fP\fIparent_tid\fP\fB, int *\fP\fIchild_tid\fP\fB,\fP \fB unsigned long \fP\fItls\fP\fB);\fP .EE .in .PP .\" CONFIG_CLONE_BACKWARDS Sur x86\-32 et d'autres architectures classiques (dont score, ARM, ARM 64, PA\-RISC, arc, Power PC, xtensa et MIPS), l'ordre des deux derniers paramètres est inversé\ : .PP .in +4 .EX \fBlong clone(unsigned long \fP\fIflags\fP\fB, void *\fP\fIstack\fP\fB,\fP \fB int *\fP\fIparent_tid\fP\fB, unsigned long \fP\fItls\fP\fB,\fP \fB int *\fP\fIchild_tid\fP\fB);\fP .EE .in .PP .\" CONFIG_CLONE_BACKWARDS2 Sur les architectures cris et s390, l'ordre des deux premiers paramètres est inversé\ : .PP .in +4 .EX \fBlong clone(void *\fP\fIstack\fP\fB, unsigned long \fP\fIflags\fP\fB,\fP \fB int *\fP\fIparent_tid\fP\fB, int *\fP\fIchild_tid\fP\fB,\fP \fB unsigned long \fP\fItls\fP\fB);\fP .EE .in .PP .\" CONFIG_CLONE_BACKWARDS3 Sur l'architecture microblaze, il existe un paramètre supplémentaire\ : .PP .in +4 .EX \fBlong clone(unsigned long \fP\fIflags\fP\fB, void *\fP\fIstack\fP\fB,\fP \fB int \fP\fIstack_size\fP\fB,\fP /* Taille de la pile */ \fB int *\fP\fIparent_tid\fP\fB, int *\fP\fIchild_tid\fP\fB,\fP \fB unsigned long \fP\fItls\fP\fB);\fP .EE .in .\" .SS "blackfin, m68k, et sparc" .\" Mike Frysinger noted in a 2013 mail: .\" these arches don't define __ARCH_WANT_SYS_CLONE: .\" blackfin ia64 m68k 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 la glibc). .SS ia64 Sur ia64, une interface différente est utilisée\ : .PP .in +4 .EX \fBint __clone2(int (*\fP\fIfn\fP\fB)(void *), \fP \fB void *\fP\fIstack_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\fIparent_tid\fP\fB, struct user_desc *\fP\fItls\fP\fB,\fP \fB pid_t *\fP\fIchild_tid\fP\fB */ );\fP .EE .in .PP Le prototype présenté ci\-dessus vaut pour la fonction enveloppe de la glibc\ ; pour l'appel système lui\-même, il peut être décrit comme suit (il est identique au prototype \fBclone\fP() sur microblaze)\ : .PP .in +4 .EX \fBlong clone2(unsigned long \fP\fIflags\fP\fB, void *\fP\fIstack_base\fP\fB,\fP \fB int \fP\fIstack_size\fP\fB,\fP /* Taille de la pile */ \fB int *\fP\fIparent_tid\fP\fB, int *\fP\fIchild_tid\fP\fB,\fP \fB unsigned long \fP\fItls\fP\fB);\fP .EE .in .PP \fB__clone2\fP() fonctionne comme \fBclone\fP(), sauf que \fIstack_base\fP pointe sur la plus petite adresse de la pile de l'enfant et que \fIstack_size\fP indique la taille de la pile sur laquelle pointe \fIstack_base\fP. .SS "Linux 2.4 et antérieurs" Sous Linux\ 2.4 et plus anciens, \fBclone\fP() ne prend pas les paramètres \fIparent_tid\fP, \fItls\fP, et \fIchild_tid\fP. .SH "VALEUR RENVOYÉE" .\" gettid(2) returns current->pid; .\" getpid(2) returns current->tgid; En cas de réussite, le TID du processus enfant est renvoyé dans le thread d'exécution de l'appelant. En cas d'échec, \fB\-1\fP est renvoyé dans le contexte de l'appelant, aucun enfant n'est créé, et \fIerrno\fP contiendra le code d'erreur. .SH ERREURS .TP \fBEAGAIN\fP Trop de processus en cours d'exécution. Consultez \fBfork\fP(2). .TP \fBEINVAL\fP .\" Precisely: Linux 2.6.0-test6 \fBCLONE_SIGHAND\fP a été spécifié dans le masque \fIflags\fP, mais pas \fBCLONE_VM\fP (depuis 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 a été spécifié dans le masque \fIflags\fP, mais pas \fBCLONE_SIGHAND\fP (depuis Linux 2.5.35). .TP \fBEINVAL\fP \fBCLONE_THREAD\fP a été indiqué dans le masque \fIflags\fP mais le processus actuel avait appelé \fBunshare\fP(2) avec l'attribut \fBCLONE_NEWPID\fP ou il utilisait \fBsetns\fP(2) pour se réassocier à l'espace de noms PID. .TP \fBEINVAL\fP .\" commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71 Tant \fBCLONE_FS\fP que \fBCLONE_NEWNS\fP ont été indiqués dans le masque \fIflags\fP. .TP \fBEINVAL\fP (depuis Linux 3.9) Tant \fBCLONE_NEWUSER\fP que \fBCLONE_FS\fP ont été indiqués dans le masque \fIflags\fP. .TP \fBEINVAL\fP Tant \fBCLONE_NEWIPC\fP que \fBCLONE_SYSVSEM\fP ont été indiqués dans le masque \fIflags\fP. .TP \fBEINVAL\fP \fBCLONE_NEWPID\fP ou \fBCLONE_NEWUSER\fP, et \fBCLONE_THREAD\fP ou \fBCLONE_PARENT\fP, ont été indiqués, seuls ou ensemble, dans le masque \fIflags\fP. .TP \fBEINVAL\fP Renvoyée par l'enveloppe glibc de \fBclone\fP() quand \fIfn\fP ou \fIstack\fP valent NULL. .TP \fBEINVAL\fP \fBCLONE_NEWIPC\fP a été spécifié dans le masque \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é spécifié dans le masque \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é spécifié dans le masque \fIflags\fP, mais le noyau n'a pas été configuré avec l'option \fBCONFIG_PID_NS\fP. .TP \fBEINVAL\fP \fBCLONE_NEWUSER\fP a été spécifié dans le masque \fIflags\fP, mais le noyau n'a pas été configuré avec l'option \fBCONFIG_USER_NS\fP. .TP \fBEINVAL\fP \fBCLONE_NEWUTS\fP a été spécifié dans le masque \fIflags\fP, mais le noyau n'a pas été configuré avec l'option \fBCONFIG_UTS_NS\fP. .TP \fBEINVAL\fP \fIstack\fP n'est pas alignée sur une limite adaptée à cette architecture. Par exemple, sur arch64, \fIstack\fP doit être un multiple de 16. .TP \fBEINVAL\fP (\fBclone3\fP() seulement) \fBCLONE_DETACHED\fP a été spécifié dans le masque \fIflags\fP. .TP \fBEINVAL\fP (\fBclone\fP() seulement) \fBCLONE_PIDFD\fP a été indiqué avec \fBCLONE_DETACHED\fP dans le masque \fIflags\fP. .TP \fBEINVAL\fP \fBCLONE_PIDFD\fP a été indiqué avec \fBCLONE_THREAD\fP dans le masque \fIflags\fP. .TP \fBEINVAL \fP(\fBclone\fP() seulement) \fBCLONE_PIDFD\fP a été indiqué avec \fBCLONE_PARENT_SETTID\fP dans le masque \fIflags\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 enfant. .TP \fBENOSPC\fP (depuis Linux 3.7) .\" commit f2302505775fd13ba93f034206f1e2a587017929 \fBCLONE_NEWPID\fP a été spécifié dans le masque \fIflags\fP, et l'appel provoquerait un dépassement de la limite du nombre maximal d'espaces de noms utilisateur imbriqués. Consultez \fBpid_namespaces\fP(7). .TP \fBENOSPC\fP (depuis Linux 4.9\ ; auparavant \fBEUSERS\fP) \fBCLONE_NEWUSER\fP a été spécifié dans le masque \fIflags\fP, et l'appel provoquerait un dépassement de la limite du nombre maximal d'espaces de noms utilisateur imbriqués. Consultez \fBuser_namespaces\fP(7). .IP De Linux 3.11 à Linux 4.8, l'erreur indiquée dans ce cas était \fBEUSERS\fP. .TP \fBENOSPC\fP (depuis Linux 4.9) Une des valeurs dans le masque \fIflags\fP indiquait de créer un nouvel espace de noms utilisateur, mais cela aurait provoqué un dépassement de la limite définie par le fichier correspondant dans \fI/proc/sys/user\fP. Pour plus de détails, voir \fBnamespaces\fP(7). .TP \fBEPERM\fP \fBCLONE_NEWCGROUP\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é spécifié par un processus autre que le processus 0 (cette erreur n'arrive que sur Linux 2.5.15 et antérieurs). .TP \fBEPERM\fP \fBCLONE_NEWUSER\fP a été spécifié dans le masque \fIflags\fP, mais l'identifiant utilisateur effectif ou l'identifiant de groupe effectif de l'appelant n'a pas de correspondance dans l'espace de noms parent (consultez \fBuser_namespaces\fP(7)). .TP \fBEPERM\fP (depuis Linux 3.9) .\" commit 3151527ee007b73a0ebd296010f1c0454a919c7d .\" FIXME What is the rationale for this restriction? \fBCLONE_NEWUSER\fP a été spécifié dans le masque \fIflags\fP et l'appelant se trouve dans un environnement chroot (c'est\-à\-dire que le répertoire racine de l'appelant ne correspond pas au répertoire racine de l'espace de noms montage dans lequel il se trouve). .TP \fBERESTARTNOINTR\fP (depuis Linux 2.6.17) .\" commit 4a2c7a7837da1b91468e50426066d988050e4d56 L'appel système a été interrompu par un signal et va être redémarré (cela n'est visible qu'à l'occasion d'un \fBtrace\fP()). .TP \fBEUSERS\fP (Linux 3.11 à Linux 4.8) \fBCLONE_NEWUSER\fP a été spécifié dans le masque \fIflags\fP, et l'appel provoquerait un dépassement de la limite du nombre maximal d'espaces de noms utilisateur imbriqués. Voir le point sur l'erreur \fBENOSPC\fP ci\-dessus. .SH VERSIONS .\" There is no entry for .\" .BR clone () .\" in libc5. .\" glibc2 provides .\" .BR clone () .\" as described in this manual page. L'appel système \fBclone3\fP() est apparu pour la première fois dans Linux 5.3. .SH CONFORMITÉ Ces appels système sont spécifiques à Linux et ne doivent pas être utilisés dans des programmes conçus pour être portables. .SH NOTES L'appel système \fBkcmp\fP(2) peut être utilisé pour vérifier si deux processus partagent des ressources, telles qu'une table de descripteurs de fichier, des opérations Annuler de sémaphore sur System\ V ou un espace d'adressage virtuel. .PP .PP Les gestionnaires enregistrés en utilisant \fBpthread_atfork\fP(3) ne sont pas exécutés pendant un appel clone. .PP Dans les noyaux 2.4.x, \fBCLONE_THREAD\fP ne fait en général pas du processus parent du nouveau thread un processus identique au parent du processus appelant. 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.0 et supérieurs). .PP 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 jusqu'à la 2.24 comprise contenaient une fonction enveloppe pour \fBgetpid\fP(2) qui effectuait un cache des PID. Ce cache nécessitait une prise en charge par l'enveloppe de \fBclone\fP() de la glibc, mais des limites dans l'implémentation faisaient que le cache pouvait ne pas être à jour sous certaines circonstances. En particulier, si un signal était distribué à un enfant juste après l'appel à \fBclone\fP(), alors un appel à \fBgetpid\fP(2) dans le gestionnaire de signaux du signal pouvait renvoyer le PID du processus appelant (le parent), si l'enveloppe de clone n'avait toujours pas eu le temps de mettre le cache de PID à jour pour l'enfant. (Ce point ignore le cas où l'enfant a été créé en utilisant \fBCLONE_THREAD\fP, quand \fBgetpid\fP(2) \fIdoit\fP renvoyer la même valeur pour l'enfant et pour le processus qui a appelé \fBclone\fP(), puisque l'appelant et l'enfant 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\ : .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 Suite à un problème de cache ancien, ainsi qu'à d'autres problèmes traités dans \fBgetpid\fP(2), la fonctionnalité de mise en cache du PID a été supprimée de la glibc 2.25. .SH EXEMPLE Le programme suivant décrit l'usage de \fBclone\fP() dans le but de créer un processus enfant qui s'exécute dans un espace de noms UTS distinct. Le processus enfant change le nom d'hôte (hostname) dans son propre espace UTS. Les processus parent et enfant 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. Pour un exemple d’utilisation de ce programme, consultez \fBsetns\fP(2). .PP Dans le programme d'exemple, nous allouons la mémoire qui doit être utilisée pour la pile de l'enfant en utilisant \fBmmap\fP(2) au lieu de \fBmalloc\fP(3) pour les raisons suivantes\ : .IP * 3 \fBmmap\fP(2) alloue un bloc de mémoire commençant à la limite d'une page et multiple de la taille de la page. Cela est utile si on veut établir une page de protection (avec \fBPROT_NONE\fP) à la fin de la pile en utilisant \fBmprotect\fP(2). .IP * On peut indiquer l'attribut \fBMAP_STACK\fP pour demander une association adaptée à une pile. Pour le moment, cet attribut n'est pas opérationnel sur Linux, mais il existe et a des effets sur d'autres systèmes, donc on doit l'inclure pour la portabilité. .SS "Source du programme" .EX #define _GNU_SOURCE #include #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 l'enfant cloné */ childFunc(void *arg) { struct utsname uts; /* Modifier le nom d'hôte dans l'espace de noms UTS du processus enfant */ 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 l'enfant : %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 enfant se termine à ce moment */ } #define STACK_SIZE (1024 * 1024) /* Taille de la pile pour l'enfant 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 mémoire à utiliser pour la pile du processus enfant */ 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; /* On suppose que la pile grandit vers le bas */ /* Créer un processus enfant disposant de son propre espace de noms UTS\ ; le processus enfant 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); /* Le parent se retrouve ici */ sleep(1); /* Laisser le temps au processus enfant de changer son nom d'hôte */ /* Afficher le nom d'hôte pour l'espace de noms UTS du processus parent. Celui\-ci sera différent du nom d'hôte pour l'espace de noms UTS du processus enfant. */ if (uname(&uts) == \-1) errExit("uname"); printf("uts.nodename dans le parent : %s\en", uts.nodename); if (waitpid(pid, NULL, 0) == \-1) /* Attendre le processus enfant */ errExit("waitpid"); printf("Fin du processus enfant\en"); exit(EXIT_SUCCESS); } .EE .SH "VOIR AUSSI" \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 COLOPHON Cette page fait partie de la publication\ 5.04 du projet \fIman\-pages\fP Linux. Une description du projet et des instructions pour signaler des anomalies et la dernière version de cette page peuvent être trouvées à l'adresse \%https://www.kernel.org/doc/man\-pages/. .SH TRADUCTION La traduction française de cette page de manuel a été créée par Christophe Blaess , Stéphan Rafin , Thierry Vignaud , François Micaux, Alain Portal , Jean-Philippe Guérard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas François , Florentin Duneau , Simon Paillard , Denis Barbier , David Prévot , Cédric Boutillier , Frédéric Hantrais et Jean-Philippe MENGUAL . Cette traduction est une documentation libre ; veuillez vous reporter à la .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License version 3 .UE concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE. Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à .MT debian-l10n-french@lists.debian.org .ME .