Vous êtes dans : GNU/Linux Astuces / Pages man [Section2 - Appels système]

CLONE

Index

1. NOM
2. SYNOPSIS
3. DESCRIPTION
   1. sys_clone
4. VALEUR RENVOYÉE
5. ERREURS
6. DISPONIBILITÉ
7. NOTES
8. CONFORMITÉ
9. BOGUES
10. VOIR AUSSI
11. TRADUCTION

NOM

SYNOPSIS

#include <sched.h>

int clone(int (*fn)(void *), void *child_stack, int flags, void *arg);

_syscall2(int, clone, int, flags, void *, child_stack)

_syscall5(int, clone, int, flags, void *, child_stack,
 int *, parent_tidptr, struct user_desc *, newtls,
 int *, child_tidptr)
    /* Il peut être préférable d'utiliser syscall(2) ; voir intro(2) */

DESCRIPTION

CLONE_PARENT (depuis Linux 2.3.12)

Si CLONE_PARENT est présent, le père du nouveau fils (comme il est indiqué par getppid(2)) sera le même que celui du processus appelant.
Si CLONE_PARENT n'est pas fourni, alors (comme pour fork(2)) le père du processus fils sera le processus appelant.
Remarquez que c'est le processus père, tel qu'indiqué par getppid(2), qui est notifié lors de la fin du fils. Ainsi, si CLONE_PARENT est présent, alors c'est le père du processus appelant, et non ce dernier, qui sera notifié.

CLONE_FS

Si l'attribut CLONE_FS est positionné, les processus appelant et 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 à chroot(2), chdir(2) ou umask(2) effectué par un processus aura également influence sur l'autre processus.
Si CLONE_FS 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 clone(). Les appels à chroot(2), chdir(2), umask(2) effectués par un processus n'affectent pas l'autre processus.

CLONE_FILES

Si l'attribut CLONE_FILES est positionné, les processus appelant et fils partagent la même table des descripteurs de fichiers. 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 fcntl(2) F_SETFD), l'autre processus en est aussi affecté.
Si CLONE_FILES n'est pas positionné, le processus fils hérite d'une copie des descripteurs de fichiers ouverts par l'appelant au moment de l'appel clone(). (Les copies des descripteurs de fichiers dans le fils sont associées aux mêmes descriptions de fichiers ouverts (voir open(2)) que les descripteurs de fichiers correspondants dans le processus appelant.) Les opérations effectuées ensuite sur un descripteur par un des processus n'affectent pas l'autre processus.

CLONE_NEWNS (depuis Linux 2.4.19)

Démarrer le processus dans un nouvel espace de noms.
Chaque processus se trouve dans un espace de noms. Cet espace de noms du processus regroupe les données décrivant la hiérarchie des fichiers vus par le processus (l'ensemble des montages). Après un fork(2) ou clone(2) sans l'attribut CLONE_NEWNS le fils se déroule dans le même espace de nom que son père. Les appels système mount(2) et umount(2) modifient l'espace de noms du processus appelant, et affectent ainsi tous les processus se déroulant dans le même espace, sans affecter les processus se trouvant dans d'autres espaces.
Après un clone(2) avec l'attribut CLONE_NEWNS le fils cloné démarre dans un nouvel espace de noms, initialisé avec une copie de l'espace du père.
Seul un processus privilégié (un processus ayant la capacité CAP_SYS_ADMIN) peut spécifier l'attribut CLONE_NEWNS. Il n'est pas possible de spécifier à la fois CLONE_NEWNS et CLONE_FS pour le même appel clone().

CLONE_SIGHAND

Si l'attribut CLONE_SIGHAND est positionné, les processus appelant et fils partagent la même table des gestionnaires de signaux. Si l'appelant, ou le fils, appelle sigaction(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 sigprocmask(2) sans affecter l'autre processus.
Si CLONE_SIGHAND n'est pas utilisé, le processus fils hérite d'une copie des gestionnaires de signaux de l'appelant lors de l'invocation de clone(). Les appels à sigaction(2) effectués ensuite depuis un processus n'ont pas d'effets sur l'autre processus.
Depuis Linux 2.6.0-test6, l'attribut CLONE_VM doit également être spécifié dans flags si CLONE_SIGHAND l'est.

CLONE_PTRACE

Si l'attribut CLONE_PTRACE est positionné et si l'appelant est suivi par un débogueur, alors le fils sera également suivi (voir ptrace(2)).

CLONE_UNTRACED (depuis Linux 2.5.46)

Si l'attribut CLONE_UNTRACED est positionné, alors un processus traçant le père ne peut pas forcer CLONE_PTRACE pour ce fils.

CLONE_STOPPED (depuis Linux 2.6.0-test2)

Si l'attribut CLONE_STOPPED est positionné, le fils est initialement stoppé (comme s'il avait reçu le signal SIGSTOP), et doit être relancé en lui envoyant le signal SIGCONT.

CLONE_VFORK

Si le bit CLONE_VFORK 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 execve(2) ou _exit(2) (comme avec vfork(2)).
Si CLONE_VFORK 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é.

CLONE_VM

Si le bit CLONE_VM est actif, les processus père et 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 mmap(2) ou munmap(2) par l'un des processus affectera également l'autre processus.
Si CLONE_VM 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 clone(). 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 fork(2).

CLONE_PID (obsolète)

Si l'attribut CLONE_PID 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.

CLONE_THREAD (depuis Linux 2.4.0-test8)

Si CLONE_THREAD est présent, le fils est placé dans le même groupe de threads que le processus appelant. Afin de rendre l'explication de CLONE_THREAD 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 getpid(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 clone() au processus appelant, et un thread peut obtenir son propre TID en utilisant gettid(2).
Quand clone(2) est appelé sans positionner CLONE_THREAD, 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 leader du nouveau groupe.
Un nouveau thread créé en utilisant CLONE_THREAD a le même processus père que l'appelant de clone() (de même qu'avec CLONE_PARENT), ainsi les appels à getppid(2) renvoient la même valeur à tous les threads dans un même groupe. Lorsqu'un thread créé avec CLONE_THREAD termine, le thread qui a appelé clone() pour le créer ne reçoit pas le signal SIGCHLD (ou autre notification de terminaison) ; de même, l'état d'un tel thread ne peut être obtenu par wait(2). Le thread est dit détaché.
Lorsque tous les threads d'un groupe de threads terminent, le processus parent du groupe reçoit un signal SIGCHLD (ou autre indicateur de terminaison).
Si l'un des threads dans un groupe de threads appelle execve(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 fork(2), n'importe lequel des threads du groupe peut utiliser wait(2) sur ce fils.
Depuis Linux 2.5.35, l'attribut CLONE_SIGHAND de flags doit être positionné si CLONE_THREAD l'est.
Un signal peut être envoyé à un groupe de threads dans son ensemble (c'est-à-dire à un TGID) avec kill(2), ou bien à un thread en particulier (à un TID) avec tgkill(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 sigprocmask(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 kill(2), soit pour un thread particulier, lorsqu'ils sont envoyés par tgkill(2). Un appel à sigpending(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 kill(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 sigwaitinfo(2), le noyau choisira arbitrairement l'un d'entre eux pour délivrer le signal envoyé par kill(2).

CLONE_SYSVSEM (depuis Linux 2.5.10)

Si CLONE_SYSVSEM est positionné, le fils et le processus appelant partagent la même liste de compteurs « undo » pour les sémaphores System V (voir semop(2)). Si cet attribut n'est pas utilisé, le fils a une liste « undo » séparée, initialement vide.

CLONE_SETTLS (depuis Linux 2.5.32)

Le paramètre newtls est le nouveau descripteur TLS (Thread Local Storage). (Voir set_thread_area(2).)

CLONE_PARENT_SETTID (depuis Linux 2.5.49)

Enregistrer l'ID du thread enfant à parent_tidptr dans la mémoire du père et du fils. (Dans Linux 2.5.32-2.5.48 il y a un attribut CLONE_SETTID qui fait cela.)

CLONE_CHILD_SETTID (depuis Linux 2.5.49)

Enregistrer l'ID du thread enfant à child_tidptr dans la mémoire du fils.

CLONE_CHILD_CLEARTID (depuis Linux 2.5.49)

Effacer l'ID du thread enfant à child_tidptr 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 set_tid_address(2). Cela est utilisé dans les bibliothèques de gestion de threads.

sys_clone

VALEUR RENVOYÉE

ERREURS

EAGAIN

Trop de processus en cours d'exécution.

EINVAL

CLONE_SIGHAND a été spécifié mais pas CLONE_VM (Depuis Linux 2.6.0-test6.)

EINVAL

CLONE_THREAD a été spécifié mais pas CLONE_SIGHAND (depuis Linux 2.5.35).

EINVAL

Les attributs CLONE_NEWNS et CLONE_FS ont été indiqués simultanément dans flags.

EINVAL

Renvoyée par clone() quand une valeur nulle a été indiquée pour le paramètre child_stack.

ENOMEM

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.

EPERM

CLONE_NEWNS a été spécifié par un processus non root (processus sans CAP_SYS_ADMIN).

EPERM

CLONE_PID a été réclamé par un processus autre que le processus 0.

DISPONIBILITÉ

NOTES

CONFORMITÉ

BOGUES

    #include <syscall.h>

    pid_t mypid;

    mypid = syscall(SYS_getpid);

VOIR AUSSI

TRADUCTION