.\" -*- coding: UTF-8 -*- .\" Copyright (c) 1993 by Thomas Koenig .\" and Copyright (c) 2004 by Michael Kerrisk .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\" Modified Sat Jul 24 13:30:06 1993 by Rik Faith .\" Modified Sun Aug 21 17:42:42 1994 by Rik Faith .\" (Thanks to Koen Holtman ) .\" Modified Wed May 17 15:54:12 1995 by Rik Faith .\" To remove *'s from status in macros (Thanks to Michael Shields). .\" Modified as suggested by Nick Duffek , aeb, 960426 .\" Modified Mon Jun 23 14:09:52 1997 by aeb - add EINTR. .\" Modified Thu Nov 26 02:12:45 1998 by aeb - add SIGCHLD stuff. .\" Modified Mon Jul 24 21:37:38 2000 by David A. Wheeler .\" - noted thread issues. .\" Modified 26 Jun 01 by Michael Kerrisk .\" Added __WCLONE, __WALL, and __WNOTHREAD descriptions .\" Modified 2001-09-25, aeb .\" Modified 26 Jun 01 by Michael Kerrisk, .\" Updated notes on setting disposition of SIGCHLD to SIG_IGN .\" 2004-11-11, mtk .\" Added waitid(2); added WCONTINUED and WIFCONTINUED() .\" Added text on SA_NOCLDSTOP .\" Updated discussion of SA_NOCLDWAIT to reflect 2.6 behavior .\" Much other text rewritten .\" 2005-05-10, mtk, __W* flags can't be used with waitid() .\" 2008-07-04, mtk, removed erroneous text about SA_NOCLDSTOP .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH wait 2 "5 février 2023" "Pages du manuel de Linux 6.03" .SH NOM wait, waitpid, waitid \- Attendre la fin d'un processus .SH BIBLIOTHÈQUE Bibliothèque C standard (\fIlibc\fP, \fI\-lc\fP) .SH SYNOPSIS .nf \fB#include \fP .PP \fBpid_t wait(int *_Nullable \fP\fIwstatus\fP\fB);\fP \fBpid_t waitpid(pid_t \fP\fIpid\fP\fB, int *_Nullable \fP\fIwstatus\fP\fB, int \fP\fIoptions\fP\fB);\fP .PP \fBint waitid(idtype_t \fP\fIidtype\fP\fB, id_t \fP\fIid\fP\fB, siginfo_t *\fP\fIinfop\fP\fB, int \fP\fIoptions\fP\fB);\fP /* Il s'agit de l'interface de glibc et POSIX\ ; consultez les NOTES pour des informations sur les appels système bruts. */ .fi .PP .RS -4 Exigences de macros de test de fonctionnalités pour la glibc (consulter \fBfeature_test_macros\fP(7))\ : .RE .PP \fBwaitid\fP()\ : .nf .\" (_XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED) Depuis la glibc 2.26 : _XOPEN_SOURCE >= 500 || _POSIX_C_SOURCE >= 200809L Pour la glibc antérieure et égale à 2.25 : _XOPEN_SOURCE || /* Depuis la glibc 2.12: */ _POSIX_C_SOURCE >= 200809L || /* glibc <= 2.19: */ _BSD_SOURCE .fi .SH DESCRIPTION Tous ces appels système attendent qu'un des enfants du processus appelant change d'état et permettent d'obtenir des informations sur l'enfant en question. Un processus est considéré comme changeant d'état s'il termine, s'il est stoppé par un signal ou s'il est relancé par un signal. Dans le cas d'un enfant qui se termine, l'attendre permet au système de libérer les ressources qui lui étaient allouées\ ; si le processus n'est pas attendu, il reste en état de «\ zombie\ » (voir les NOTES plus bas). .PP Si un enfant a déjà changé d'état, ces appels système retournent immédiatement. Sinon, ils bloquent jusqu'à ce qu'un enfant change d'état ou qu'un gestionnaire de signal interrompe l'appel (sauf si les appels système sont relancés automatiquement par l'option \fBSA_RESTART\fP de \fBsigaction\fP(2)). Dans la suite de cette page, un enfant qui a changé d'état et qui n'a pas été attendu est appelé \fIprêt\fP (\fIwaitable\fP). .SS "wait() et waitpid()" L'appel système \fBwait\fP() suspend l'exécution du processus appelant jusqu'à ce que l'un de ses enfants se termine. L'appel \fIwait(&status)\fP est équivalent à\ : .PP .in +4n .EX waitpid(\-1, &wstatus, 0); .EE .in .PP L'appel système \fBwaitpid\fP() suspend l'exécution du processus appelant jusqu'à ce qu'un enfant spécifié par l'argument \fIpid\fP change d'état. Par défaut, \fBwaitpid\fP() n'attend que les enfants terminés, mais ce comportement peut être modifié par l'argument \fIoptions\fP, de la façon décrite ci\-dessous. .PP La valeur de \fIpid\fP peut être l'une des suivantes\ : .TP < \fB\-1\fP Attendre la fin de n'importe quel processus enfant appartenant au groupe de processus d'ID \fI\-pid\fP. .TP \fB\-1\fP Attendre n'importe lequel des processus enfant. .TP \fB0\fP Attendre la fin de n'importe quel processus enfant dont l'identifiant de groupe du processus est égal à celui du processus appelant au moment de l'appel à \fBwaitpid\fP(). .TP > \fB0\fP Attendre la fin d'un enfant dont l'identifiant du processus est égal à la valeur du processus numéro \fIpid\fP. .PP La valeur de l'argument option \fIoptions\fP est un \fIOU\fP binaire entre zéro ou plus des constantes suivantes\ : .TP \fBWNOHANG\fP Ne pas bloquer si aucun enfant ne s'est terminé. .TP \fBWUNTRACED\fP Recevoir l'information concernant également les enfants bloqués (mais non suivis par \fBptrace\fP(2)). L'état des enfants suivis qui se sont terminés est fourni même sans cette option. .TP \fBWCONTINUED\fP (Depuis Linux 2.6.10) Renvoyer également si un processus enfant stoppé a été relancé par le signal \fBSIGCONT\fP. .PP (Pour les options spécifiques à Linux, voir plus bas.) .PP Si \fIwstatus\fP n'est pas NULL, \fBwait\fP() et \fBwaitpid\fP() stockent l'état de l'enfant dans la variable de type \fIint\fP pointée. Cet entier peut être évalué avec les macros suivantes (qui prennent l'entier lui\-même comme argument, et pas un pointeur vers celui\-ci, comme le font \fBwait\fP() et \fBwaitpid\fP()\ !)\ : .TP \fBWIFEXITED(\fP\fIwstatus\fP\fB)\fP Vrai si l'enfant s'est terminé normalement, c'est\-à\-dire par un appel à \fBexit\fP(3) ou \fB_exit\fP(2) ou par un \fIreturn\fP depuis main(). .TP \fBWEXITSTATUS(\fP\fIwstatus\fP\fB)\fP Donne le code de retour, consistant en les 8\ bits de poids faible du paramètre \fIstatus\fP fourni à \fBexit\fP(3) ou \fB_exit\fP(2) ou dans le \fIreturn\fP de la routine main(). Cette macro ne peut être évaluée que si \fBWIFEXITED\fP a renvoyé vrai. .TP \fBWIFSIGNALED(\fP\fIwstatus\fP\fB)\fP Vrai si l'enfant s'est terminé à cause d'un signal. .TP \fBWTERMSIG(\fP\fIwstatus\fP\fB)\fP Donne le numéro du signal qui a causé la fin de l'enfant. Cette macro ne peut être évaluée que si \fBWIFSIGNALED\fP a renvoyé vrai. .TP \fBWCOREDUMP(\fP\fIwstatus\fP\fB)\fP Vrai si le processus enfant a produit une image mémoire («\ core dump\ ») (voir \fBcore\fP(5)). Cette macro ne doit être évaluée que si \fBWIFSIGNALED\fP a renvoyé vrai. .IP Cette macro n'est pas décrite par POSIX.1\-2001 et n'est pas disponible sur certaines implémentations d'UNIX (par exemple AIX ou SunOS). N'utilisez cette macro qu'entourée de \fI#ifdef WCOREDUMP ... #endif\fP. .TP \fBWIFSTOPPED(\fP\fIwstatus\fP\fB)\fP Vrai si le processus enfant a été arrêté par l'envoi d'un signal. Cela n'est possible que si l'on a effectué l'appel avec l'option \fBWUNTRACED\fP ou si l'enfant est suivi (voir \fBptrace\fP(2)). .TP \fBWSTOPSIG(\fP\fIwstatus\fP\fB)\fP Donne le numéro du signal qui a causé l'arrêt de l'enfant. Cette macro ne peut être évaluée que si \fBWIFSTOPPED\fP renvoie vrai. .TP \fBWIFCONTINUED(\fP\fIwstatus\fP\fB)\fP (Depuis Linux\ 2.6.10) Vrai si le processus enfant a été relancé par \fBSIGCONT\fP. .SS waitid() L'appel système \fBwaitid\fP(), disponible depuis Linux\ 2.6.9, fournit des moyens plus fins de contrôler quels changements d'états attendre. .PP Les arguments \fIidtype\fP et \fIid\fP sélectionnent le(s) enfant(s) à attendre, comme suit\ : .TP \fIidtype\fP == \fBP_PID\fP Attendre la fin de l'enfant dont l'identifiant du processus correspond à \fIid\fP. .TP \fIidtype\fP == \fBP_PIDFD\fP (depuis Linux 5.4) .\" commit 3695eae5fee0605f316fbaad0b9e3de791d7dfaf Attendre la fin de l'enfant auquel fait référence le descripteur de fichier PID spécifié dans \fIid\fP (voir \fBpidfd_open\fP(2) pour plus d'informations à propos des descripteurs de fichier PID). .TP \fIidtype\fP == \fBP_PGID\fP .\" commit 821cc7b0b205c0df64cce59aacc330af251fa8f7 Attendre la fin de l'enfant dont l'identifiant de groupe du processus correspond à \fIid\fP. depuis Linux\ 5.4, si \fIid\fP vaut zéro, attendre pour n'importe quel enfant qui est dans le même groupe de processus que le groupe de processus de l'appelant au moment de l'appel. .TP \fIidtype\fP == \fBP_ALL\fP Attendre n'importe quel enfant\ ; l'argument \fIid\fP est ignoré. .PP Les changements d'état à attendre sont indiqués par un OU binaire des attributs suivants dans le paramètre \fIoptions\fP\ : .TP \fBWEXITED\fP Attendre les enfants qui se sont terminés. .TP \fBWSTOPPED\fP Attendre les enfants qui ont été arrêtés par un signal. .TP \fBWCONTINUED\fP Attendre les enfants précédemment arrêtés qui ont été relancés par le signal \fBSIGCONT\fP. .PP Les attributs suivants peuvent également être utilisés dans \fIoptions\fP\ : .TP \fBWNOHANG\fP Comme pour \fBwaitpid\fP(). .TP \fBWNOWAIT\fP Laisser l'enfant dans un état prêt\ ; un appel ultérieur à wait() pourra de nouveau fournir des informations sur l'état de l'enfant. .PP Si l'appel réussit, \fBwaitid\fP() remplit les champs suivants de la structure \fIsiginfo_t\fP pointée par \fIinfop\fP\ : .TP \fIsi_pid\fP L'identifiant de processus de l'enfant. .TP \fIsi_uid\fP L'UID réel de l'enfant. Ce champ n'est pas rempli par la plupart des autres implémentations. .TP \fIsi_signo\fP Toujours \fBSIGCHLD\fP. .TP \fIsi_status\fP Soit le code de retour de l'enfant donné à \fB_exit\fP(2) ou \fBexit\fP(3), soit le signal ayant provoqué la terminaison, l'arrêt ou la relance de l'enfant. Le champ \fIsi_code\fP permet de savoir comment interpréter ce champ. .TP \fIsi_code\fP L'un de \fBCLD_EXITED\fP (l'enfant a appelé \fB_exit\fP(2)), \fBCLD_KILLED\fP (l'enfant a été tué par un signal), \fBCLD_DUMPED\fP (l'enfant a été tué par un signal et a produit une image mémoire (core dump)), \fBCLD_STOPPED\fP (l'enfant a été arrêté par un signal), \fBCLD_TRAPPED\fP (l'enfant suivi a été capturé) ou \fBCLD_CONTINUED\fP (l'enfant a été relancé par \fBSIGCONT\fP). .PP Si \fBWNOHANG\fP est utilisé dans \fIoptions\fP et si aucun enfant n'est prêt, \fBwaitid\fP() renvoie \fB0\fP immédiatement et l'état de la structure \fIsiginfo_t\fP pointée par \fIinfop\fP dépend de l'implémentation. Pour différencier (de façon portable) ce cas de celui où un des enfants était prêt, définissez à zéro le champ \fIsi_pid\fP avant l'appel, et vérifiez que sa valeur est différente de zéro après le renvoi de l'appel. .PP .\" POSIX.1-2001 leaves this possibility unspecified; most .\" implementations (including Linux) zero out the structure .\" in this case, but at least one implementation (AIX 5.1) .\" does not -- MTK Nov 04 Le premier rectificatif technique POSIX.1\-2008 (2013) ajoute l'exigence que quand \fBWNOHANG\fP est spécifié dans \fIoptions\fP et si aucun enfant n'est prêt, \fBwaitid\fP() doit définir à zéro les champs \fIsi_pid\fP et \fIsi_signo\fP de la structure. Dans Linux et d'autres implémentations qui respectent cette exigence, il n'est pas nécessaire de définir à zéro le champ \fIsi_pid\fP avant l'appel à \fBwaitid\fP(). Néanmoins, toutes les implémentations ne suivent pas la spécification de POSIX.1 sur ce point. .SH "VALEUR RENVOYÉE" \fBwait\fP()\ : en cas de réussite, l'identifiant du processus enfant terminé est renvoyé\ ; en cas d'échec, la valeur de retour est \fB\-1\fP. .PP \fBwaitpid\fP()\ : s'il réussit, l'appel renvoie l'identifiant du processus enfant dont l'état a changé\ ; si \fBWNOHANG\fP est utilisé et si un enfant (ou plus) spécifié par \fIpid\fP existe, mais n'a pas encore changé d'état, la valeur renvoyée est \fB0\fP. En cas d'échec, \fB\-1\fP est renvoyé. .PP .\" FIXME As reported by Vegard Nossum, if infop is NULL, then waitid() .\" returns the PID of the child. Either this is a bug, or it is intended .\" behavior that needs to be documented. See my Jan 2009 LKML mail .\" "waitid() return value strangeness when infop is NULL". \fBwaitid\fP()\ : renvoie \fB0\fP s'il réussit ou si \fBWNOHANG\fP est utilisé et siaucun enfant spécifié dans \fIid\fP n'a encore changé d'état. En cas d'échec, renvoie \fB\-1\fP. .PP En cas d'échec, chacun de ces appels définit \fIerrno\fP pour préciser l'erreur. .SH ERREURS .TP \fBEAGAIN\fP Le descripteur de fichier PID spécifié dans \fIid\fP n'est pas bloquant et le processus auquel il fait référence ne s'est pas terminé. .TP \fBECHILD\fP (pour \fBwait\fP()) Le processus appelant n'a pas d'enfants qui n'ont pas été attendus. .TP \fBECHILD\fP (pour \fBwaitpid\fP() ou \fBwaitid\fP()) Le processus indiqué par \fIpid\fP (\fBwaitpid\fP()) ou \fIidtype\fP et \fIid\fP (\fBwaitid\fP()) n'existe pas ou n'est pas un enfant du processus appelant. (Cela peut arriver pour son propre enfant si l'action de \fBSIGCHLD\fP est définie à \fBSIG_IGN\fP\ ; voir également le passage de la section \fINotes sur Linux\fP concernant les threads.) .TP \fBEINTR\fP \fBWNOHANG\fP n'est pas indiqué et un signal à intercepter ou \fBSIGCHLD\fP a été reçu\ ; consultez \fBsignal\fP(7). .TP \fBEINVAL\fP L'argument \fIoptions\fP n'est pas valable. .TP \fBESRCH\fP (pour \fBwait\fP() ou \fBwaitpid\fP()) \fIpid\fP est équivalent à \fBINT_MIN\fP. .SH STANDARDS SVr4, 4.3BSD, POSIX.1\-2001. .SH NOTES Un enfant qui se termine mais n'a pas été attendu devient un «\ zombie\ ». Le noyau conserve des informations minimales sur le processus zombie (identifiant, code de retour, informations d'utilisation des ressources) pour permettre au parent de l'attendre plus tard et d'obtenir des informations sur l'enfant. Tant que le zombie n'est pas effacé du système par une attente, il prendra un emplacement dans la table des processus du noyau, et si cette table est remplie, il sera impossible de créer de nouveaux processus. Si un processus parent se termine, ses enfants zombies (s'il y en a) sont adoptés par \fBinit\fP(1) (ou par le processus suppresseur (\fIsubreaper\fP) le plus proche tel que défini par l'utilisation de l'opération \fBPR_SET_CHILD_SUBREAPER\fP de \fBprctl\fP(2))\ ; \fBinit\fP(1) les attend automatiquement pour supprimer les zombies. .PP POSIX.1\-2001 indique que si l'action pour \fBSIGCHLD\fP est définie à \fBSIG_IGN\fP ou si l'attribut \fBSA_NOCLDWAIT\fP est indiqué pour \fBSIGCHLD\fP (voir \fBsigaction\fP(2)), les enfants qui se terminent ne deviennent pas des zombies et un appel à \fBwait\fP() ou \fBwaitpid\fP() sera bloquant jusqu'à ce que tous les enfants soient terminés, et échouera ensuite en positionnant \fIerrno\fP à \fBECHILD\fP. (La norme POSIX originale ne décrivait pas le comportement si l'action pour \fBSIGCHLD\fP était \fBSIG_IGN\fP. Veuillez noter que même si la disposition par défaut de \fBSIGCHLD\fP est «\ ignore\ », la configuration explicite de la disposition de \fBSIG_IGN\fP entraîne un traitement différent des processus enfants zombies.) .PP Linux\ 2.6 est conforme aux préconisations de POSIX. Cependant, Linux\ 2.4 et les versions antérieures ne l'étaient pas. Lorsqu'un appel \fBwait\fP() ou \fBwaitpid\fP() était exécuté en ignorant \fBSIGCHLD\fP, les appels se comportaient comme si \fBSIGCHLD\fP était pris en compte, c'est à dire que l'appel restait bloqué en attendant que l'enfant suivant se termine, puis renvoyait l'identifiant de processus et l'état de cet enfant. .SS "Notes pour Linux" Dans le noyau Linux, un thread ordonnancé par le noyau n'est pas différent d'un simple processus. En fait, un thread est juste un processus qui est créé à l'aide de la routine \(em spécifique à Linux \(em \fBclone\fP(2). Les routines portables, comme \fBpthread_create\fP(3), sont implémentées en appelant \fBclone\fP(2). Avant Linux\ 2.4, un thread était simplement un cas particulier de processus, et en conséquence un thread ne pouvait pas attendre les enfants d'un autre thread, même si ce dernier appartenait au même groupe de threads. Toutefois, POSIX réclame une telle fonctionnalité, et depuis Linux\ 2.4 un thread peut, par défaut, attendre les enfants des autres threads du même groupe. .PP .\" commit 91c4e8ea8f05916df0c8a6f383508ac7c9e10dba Les \fIoptions\fP suivantes sont spécifiques à Linux et servent pour les enfants créés avec \fBclone\fP(2)\ ; elles peuvent aussi, depuis Linux\ 4.7, être utilisées avec \fBwaitid\fP()\ : .TP \fB__WCLONE\fP .\" since 0.99pl10 Attendre uniquement des enfants clones. Sinon, attendre uniquement les enfants non\-clones (un enfant «\ clone\ » est un enfant qui n'envoie pas de signal ou un autre signal que \fBSIGCHLD\fP à son père à sa terminaison). Cette option est ignorée si \fB__WALL\fP est aussi indiqué. .TP \fB__WALL\fP (depuis Linux 2.4) .\" since patch-2.3.48 Attendre tous les enfants, quel que soit leur type (clone ou non\-clone). .TP \fB__WNOTHREAD\fP (Depuis Linux 2.4) .\" since patch-2.4.0-test8 Ne pas attendre les enfants des autres threads du même groupe de threads. Cela était le cas par défaut avant Linux\ 2.4. .PP .\" commit bf959931ddb88c4e4366e96dd22e68fa0db9527c .\" prevents cases where an unreapable zombie is created if .\" /sbin/init doesn't use __WALL. Depuis Linux\ 4.7, l'attribut \fB__WALL\fP est automatiquement impliqué si l'enfant est suivi. .SS "différences entre bibliothèque C et noyau" \fBwait\fP() est en fait une fonction de bibliothèque implémentée (dans glibc) en tant qu'appel système à \fBwait4\fP(). .PP .\" e.g., i386 has the system call, but not x86-64 sur certaines architectures, il n'y a pas d'appel système \fBwaitpid\fP()\ ; à la place, cette interface est implémentée au moyen d'une fonction d'enveloppe de la bibliothèque\ C qui appelle \fBwait4\fP(2). .PP L'appel système brut \fBwaitid\fP() prend un cinquième paramètre, de type \fIstruct rusage\ *\fP. Si ce paramètre n'est pas NULL, il est utilisé pour renvoyer les informations d'utilisation des ressources au sujet du thread enfant, de la même façon que \fBwait4\fP(2). Consultez \fBgetrusage\fP(2) pour plus de détails. .SH BOGUES Selon la norme POSIX.1\-2008, une application appelant \fBwaitid\fP() doit garantir que \fIinfop\fP pointe sur une structure \fIsiginfo_t\fP (c'est\-à\-dire qu'elle ne pointe pas sur NULL). Sur Linux, si \fIinfop\fP est NULL, \fBwaitid\fP() réussit, et renvoie l'identificateur du processus enfant attendu. Dans la mesure du possible, les applications doivent éviter d'avoir recours à cette fonctionnalité incohérente, non standard et superflue. .SH EXEMPLES .\" fork.2 refers to this example program. Le programme suivant montre l'utilisation de \fBfork\fP(2) et de \fBwaitpid\fP(). Le programme crée un processus enfant. Si aucun argument n'est fourni dans la ligne de commande du programme, l'enfant suspend son exécution avec \fBpause\fP(2), pour que l'utilisateur puisse lui envoyer des signaux. Sinon, l'enfant se termine immédiatement en utilisant l'entier fourni sur la ligne de commande comme code de retour. Le processus père boucle en surveillant l'état de l'enfant avec \fBwaitpid\fP() et utilise les macros W*() décrites ci\-dessus pour analyser le code d'état de l'enfant. .PP La session interactive suivante montre l'utilisation de ce programme\ : .PP .in +4n .EX $\fB ./a.out &\fP Le PID de l'enfant est 32360 [1] 32359 $\fB kill \-STOP 32360\fP arrêté par le signal 19 $\fB kill \-CONT 32360\fP relancé $\fB kill \-TERM 32360\fP tué par le signal 15 [1]+ Done ./a.out $ .EE .in .SS "Source du programme" .\" SRC BEGIN (wait.c) \& .EX #include #include #include #include #include int main(int argc, char *argv[]) { int wstatus; pid_t cpid, w; cpid = fork(); if (cpid == \-1) { perror("fork"); exit(EXIT_FAILURE); } if (cpid == 0) { /* Code exécuté par l'enfant */ printf("Le PID de l'enfant est %jd\en", (intmax_t) getpid()); if (argc == 1) pause(); /* Attendre un signal */ _exit(atoi(argv[1])); } else { /* Code exécuté par le parant */ do { w = waitpid(cpid, &wstatus, WUNTRACED | WCONTINUED); if (w == \-1) { perror("waitpid"); exit(EXIT_FAILURE); } if (WIFEXITED(wstatus)) { printf("terminé, code=%d\en", WEXITSTATUS(wstatus)); } else if (WIFSIGNALED(wstatus)) { printf("tué par le signal %d\en", WTERMSIG(wstatus)); } else if (WIFSTOPPED(status)) { printf("arrêté par le signal %d\\en", WSTOPSIG(wstatus)); } else if (WIFCONTINUED(wstatus)) { printf("relancé\en"); } } while (!WIFEXITED(wstatus) && !WIFSIGNALED(wstatus)); exit(EXIT_SUCCESS); } } .EE .\" SRC END .SH "VOIR AUSSI" \fB_exit\fP(2), \fBclone\fP(2), \fBfork\fP(2), \fBkill\fP(2), \fBptrace\fP(2), \fBsigaction\fP(2), \fBsignal\fP(2), \fBwait4\fP(2), \fBpthread_create\fP(3), \fBcore\fP(5), \fBcredentials\fP(7), \fBsignal\fP(7) .PP .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-Pierre Giraud . .PP 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. .PP 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 .