NOM¶
signal - Panorama des signaux
DESCRIPTION¶
Linux prend en charge à la fois les signaux POSIX classiques
(« signaux standards ») et les signaux POSIX
temps-réel.
Dispositions de signaux¶
Chaque signal a une
disposition courante, qui détermine le
comportement du processus lorsqu'il reçoit ce signal.
Les symboles de la colonne « Action » indiquent
l'action par défaut pour chaque signal, avec la signification
suivante :
- Term
- Par défaut, terminer le processus.
- Ign
- Par défaut, ignorer le signal.
- Core
- Par défaut, créer un fichier core et terminer le processus
(consultez core(5)).
- Stop
- Par défaut, arrêter le processus.
- Cont
- Par défaut, continuer le processus s'il est actuellement
arrêté.
Un processus peut changer la disposition d'un signal avec
sigaction(2) ou
signal(2) (la deuxième option est moins portable quand on
définit un gestionnaire de signal ; consultez
signal(2)
pour plus de détails). Avec ces appels système, un processus
peut choisir de se comporter de l'une des façons suivantes lorsqu'il
reçoit ce signal : effectuer l'action par défaut, ignorer
le signal, ou rattraper le signal avec un
gestionnaire de
signal, c'est-à-dire une fonction définie par le
programme, qui est invoquée automatiquement lorsque le signal est
distribué. (Par défaut, le gestionnaire de signaux est
appelé sur la pile normale des processus. Il est possible de s'arranger
pour que le gestionnaire de signaux utilise une autre pile ; consultez
sigaltstack(2) pour une discussion sur comment faire ceci et quand
ça peut être utile.)
La disposition d'un signal est un attribut du processus : dans une
application multithreadée, la disposition d'un signal particulier est
la même pour tous les threads.
Un fils créé par
fork(2) hérite d'une copie des
dispositions de signaux de son père. Lors d'un
execve(2), les
dispositions des signaux pris en charge sont remises aux valeurs par
défaut ; les dispositions des signaux ignorés ne sont pas
modifiées.
Envoyer un signal¶
Les appels système suivants permettent à l'appelant d'envoyer un
signal :
- raise(3)
- Envoie un signal au thread appelant.
- kill(2)
- Envoie un signal au processus indiqué, à tous les membres du
groupe de processus indiqué, ou à tous les processus du
système.
- killpg(2)
- Envoie un signal à tous les membres du groupe de processus
indiqué.
- pthread_kill(3)
- Envoie un signal au thread POSIX indiqué, dans le même
processus que l'appelant.
- tgkill(2)
- Envoie un signal au thread indiqué, à l'intérieur
d'un processus donné. (C'est l'appel système qui
était utilisé pour implémenter
pthread_kill(3))
- sigqueue(3)
- Envoie un signal temps-réel, avec ses données jointes, au
processus indiqué.
Attente de la capture d'un signal¶
Les appels système suivants suspendent l'exécution du processus ou
du thread appelant jusqu'à ce qu'un signal soit attrapé (ou
qu'un signal non pris en charge termine le processus) :
- pause(2)
- Suspend l'exécution jusqu'à ce que n'importe quel signal
soit reçu.
- sigsuspend(2)
- Change temporairement le masque de signaux (voir ci-dessous) et suspend
l'exécution jusqu'à ce qu'un des signaux masqué soit
reçu.
Accepter un signal de façon synchrone¶
Au lieu de rattraper un signal de façon asynchrone avec un gestionnaire
de signal, il est possible accepter un signal de façon synchrone,
c'est-à-dire de bloquer l'exécution jusqu'à ce qu'un
signal soit distribué. À ce moment, le noyau renvoie des
informations concernant le signal à l'appelant. Il y a deux
façon générale pour faire cela :
- *
- sigwaitinfo(2), sigtimedwait(2) et sigwait(3)
suspendent l'exécution jusqu'à ce qu'un des signaux dans
l'ensemble indiqué soit distribué. Chacun de ces appels
renvoie des informations concernant le signal distribué.
- *
- signalfd(2) renvoie un descripteur de fichier qui peut être
utilisé pour lire des informations concernant les signaux qui sont
distribué à l'appelant. Chaque read(2) dans ce
descripteur de fichier est bloquant jusqu'à ce que des signaux de
l'ensemble fournit à signalfd(2) soit distribué
à l'appelant. Le tampon renvoyé par read(2) contient
une structure qui décrit le signal.
Masque de signaux et signaux en attente¶
Un signal peut être
bloqué, ce qui signifie qu'il ne sera
pas reçu par le processus avant d'être débloqué.
Entre sa création et sa réception, le signal est dit
en
attente.
Chaque thread d'un processus a un
masque de signaux indépendant,
qui indique l'ensemble des signaux bloqués par le thread. Un thread
peut modifier son masque de signaux avec
pthread_sigmask(3). Dans une
application traditionnelle, à un seul thread,
sigprocmask(2)
peut être utilisée pour modifier le masque de signaux.
Un processus fils créé avec
fork(2) hérite d'une
copie du masque de signaux de son père ; le masque de signaux
est conservé au travers d'un
execve(2).
Un signal peut être créé (et donc mis en attente) pour un
processus dans son ensemble (par exemple avec
kill(2)), ou pour un
thread en particulier (par exemple, certains signaux comme
SIGSEGV et
SIGFPE sont générés suite à une instruction
particulière en langage machine, et sont dirigés vers un thread,
de même que les signaux envoyés avec
pthread_kill(3)). Un
signal envoyé à un processus peut être traité par
n'importe lequel des threads qui ne le bloquent pas. Si plus d'un thread ne
bloque pas le signal, le noyau choisit l'un de ces threads arbitrairement, et
lui envoie le signal.
Un thread peut obtenir l'ensemble des signaux en attente avec
sigpending(2). Cet ensemble est l'union des signaux en attente
envoyés au processus, et de ceux en attente pour le thread appelant.
Un fils créé avec
fork(2) démarre avec un ensemble
de signaux en attente vide ; l'ensemble de signaux en attente est
conservé au travers d'un
execve(2).
Signaux standards¶
Linux prend en charge les signaux standards indiqués ci-dessous.
Plusieurs d'entre eux dépendent de l'architecture, comme on le voit
dans la colonne « Valeur ». Lorsque trois valeurs
sont indiquées, la première correspond normalement aux
architectures Alpha et Sparc, la seconde aux architectures x86, Arm, ainsi que
la majorité des autres architectures, et la dernière aux Mips.
(Les valeurs pour l'architecture Parisc
ne sont
pas
indiquées ; consultez les sources du noyau Linux pour la
numérotation des signaux sur cette architecture.) Un
« - » dénote un signal absent pour
l'architecture correspondante.
Voici tout d'abord les signaux décrits dans le standard POSIX.1-1990
original :
Signal |
Valeur |
Action |
Commentaire |
|
|
|
|
SIGHUP |
1 |
Term |
Déconnexion détectée sur le terminal |
|
|
|
de contrôle ou mort du processus de |
|
|
|
contrôle. |
SIGINT |
2 |
Term |
Interruption depuis le clavier. |
SIGQUIT |
3 |
Core |
Demande « Quitter » depuis le clavier. |
SIGILL |
4 |
Core |
Instruction illégale. |
SIGABRT |
6 |
Core |
Signal d'arrêt depuis abort(3). |
SIGFPE |
8 |
Core |
Erreur mathématique virgule flottante. |
SIGKILL |
9 |
Term |
Signal « KILL ». |
SIGSEGV |
11 |
Core |
Référence mémoire invalide. |
SIGPIPE |
13 |
Term |
Écriture dans un tube sans |
|
|
|
lecteur. |
SIGALRM |
14 |
Term |
Temporisation alarm(2) écoulée. |
SIGTERM |
15 |
Term |
Signal de fin. |
SIGUSR1 |
30,10,16 |
Term |
Signal utilisateur 1. |
SIGUSR2 |
31,12,17 |
Term |
Signal utilisateur 2. |
SIGCHLD |
20,17,18 |
Ign |
Fils arrêté ou terminé. |
SIGCONT |
19,18,25 |
Cont |
Continuer si arrêté. |
SIGSTOP |
17,19,23 |
Stop |
Arrêt du processus. |
SIGTSTP |
18,20,24 |
Stop |
Stop invoqué depuis le terminal. |
SIGTTIN |
21,21,26 |
Stop |
Lecture sur le terminal en arrière-plan. |
SIGTTOU |
22,22,27 |
Stop |
Écriture dans le terminal en arrière-plan. |
Les signaux
SIGKILL et
SIGSTOP ne peuvent ni capturés ni
ignorés.
Ensuite, les signaux non décrits par POSIX.1-1990, mais présents
dans les spécifications SUSv2 et POSIX.1-2001 :
Signal |
Valeur |
Action |
Commentaire |
|
|
|
|
SIGBUS |
10,7,10 |
Core |
Erreur de bus (mauvais accès mémoire). |
SIGPOLL |
|
Term |
Événement « pollable »
(System V). |
|
|
|
Synonyme de SIGIO. |
SIGPROF |
27,27,29 |
Term |
Expiration de la temporisation |
|
|
|
pour le suivi. |
SIGSYS |
12,31,12 |
Core |
Mauvais argument de fonction (SVr4). |
SIGTRAP |
5 |
Core |
Point d'arrêt rencontré. |
SIGURG |
16,23,21 |
Ign |
Condition urgente sur socket (BSD 4.2). |
SIGVTALRM |
26,26,28 |
Term |
Alarme virtuelle (BSD 4.2). |
SIGXCPU |
24,24,30 |
Core |
Limite de temps CPU dépassée (BSD 4.2). |
SIGXFSZ |
25,25,31 |
Core |
Taille de fichier excessive (BSD 4.2). |
Jusqu'à Linux 2.2 inclus, l'action par défaut pour
SIGSYS,
SIGXCPU,
SIGXFSZ et (sur les architectures autres
que Sparc ou Mips)
SIGBUS était de terminer simplement le
processus, sans fichier core. (Sur certains UNIX, l'action par défaut
pour
SIGXCPU et
SIGXFSZ est de finir le processus sans fichier
core). Linux 2.4 se conforme à POSIX.1-2001 pour ces signaux et
termine le processus avec un fichier core.
Puis quelques signaux divers :
Signal |
Valeur |
Action |
Commentaire |
|
|
|
|
SIGIOT |
6 |
Core |
Arrêt IOT. Un synonyme de SIGABRT. |
SIGEMT |
7,-,7 |
Term |
|
SIGSTKFLT |
-,16,- |
Term |
Erreur de pile sur coprocesseur (inutilisé). |
SIGIO |
23,29,22 |
Term |
E/S à nouveau possible(BSD 4.2). |
SIGCLD |
-,-,18 |
Ign |
Synonyme de SIGCHLD. |
SIGPWR |
29,30,19 |
Term |
Chute d'alimentation (System V). |
SIGINFO |
29,-,- |
|
Synonyme de SIGPWR. |
SIGLOST |
-,-,- |
Term |
Perte de verrou de fichier (inusité). |
SIGWINCH |
28,28,20 |
Ign |
Fenêtre redimensionnée (BSD 4.3, Sun). |
SIGUNUSED |
-,31,- |
Core |
Synonyme de SIGSYS |
(Le signal 29 est
SIGINFO /
SIGPWR sur Alpha mais
SIGLOST
sur Sparc).
SIGEMT n'est pas spécifié par POSIX.1-2001 mais
apparaît néanmoins sur la plupart des UNIX, avec une action par
défaut typique correspondant à une fin du processus avec fichier
core.
SIGPWR (non spécifié dans POSIX.1-2001) est typiquement
ignoré sur les autres UNIX où il apparaît.
SIGIO (non sécifié par POSIX.1-2001) est ignoré par
défaut sur plusieurs autres systèmes UNIX.
Si défini,
SIGUNUSED est synonyme de
SIGSYS sur la plupart
des architectures.
Signaux temps-réel¶
Linux prend en charge les signaux temps-réel tels qu'ils ont
été définis à l'origine dans les extensions
temps-réel POSIX.1b (et inclus à présent dans
POSIX.1-2001). L'intervalle des signaux temps-réels gérés
est défini par les macros
SIGRTMIN et
SIGRTMAX.
POSIX.1-2001 exige qu'une implémentation gère au moins
_POSIX_RTSIG_MAX (8) signaux temps-réels.
Le noyau Linux gère une gamme de 32 signaux temps-réel,
numérotés de 33 à 64. Cependant, l'implémentation
des threads POSIX de la glibc utilise en interne deux (pour
l'implémentation NPTL) ou trois (pour l'implémentation
LinuxThreads) signaux temps-réel (consultez
pthreads(7)) et
ajuste la valeur de
SIGRTMIN en conséquence (à 34 ou 35).
Comme la gamme de signaux temps-réel varie en fonction de
l'implémentation des threads par la glibc (et cette
implémentation peut changer à l'exécution en fonction du
noyau et de la glibc) et que la gamme de signaux temps-réel varie bien
sûr également suivant les systèmes UNIX, les programmes
ne devraient
jamais faire référence à des
signaux temps-réel en utilisant des numéros, mais devraient
toujours à la place utiliser des signaux temps-réel avec la
notation
SIGRTMIN+n en vérifiant à l'exécution que
SIGRTMIN+n ne dépasse pas
SIGRTMAX.
Contrairement aux signaux standards, les signaux temps-réel n'ont pas de
signification prédéfinie : l'ensemble complet de ces
signaux peut être utilisé à des fins spécifiques
à l'application.
L'action par défaut pour un signal temps-réel non capturé
est de terminer le processus récepteur.
Les signaux temps-réel se distinguent de leurs homologues classiques
ainsi :
- 1.
- Plusieurs instances d'un signal temps-réel peuvent être
empilées. Au contraire, si plusieurs instances d'un signal standard
arrivent alors qu'il est bloqué, une seule instance sera
mémorisée.
- 2.
- Si le signal est envoyé en utilisant sigqueue(3), il peut
être accompagné d'une valeur (un entier ou un pointeur). Si
le processus récepteur positionne un gestionnaire en utilisant
l'attribut SA_SIGINFO de l'appel sigaction(2) alors il peut
accéder à la valeur transmise dans le champ si_value
de la structure siginfo_t passée en second argument au
gestionnaire. De plus, les champs si_pid et si_uid de cette
structure fournissent le PID et l'UID réel du processus
émetteur.
- 3.
- Les signaux temps-réel sont délivrés dans un ordre
précis. Les divers signaux temps-réel du même type
sont délivrés dans l'ordre où ils ont
été émis. Si différents signaux
temps-réel sont envoyés au processus, ils sont
délivrés en commençant par le signal de numéro
le moins élevé (le signal de plus fort numéro est
celui de priorité la plus faible). Par contre, si plusieurs signaux
standards sont en attente dans un processus, l'ordre dans lequel ils sont
délivrés n'est pas défini.
Si des signaux standards et des signaux temps-réel sont
simultanément en attente pour un processus, Posix ne précise pas
d'ordre de délivrance. Linux, comme beaucoup d'autres
implémentations, donne priorité aux signaux temps-réel
dans ce cas.
D'après POSIX, une implémentation doit permettre l'empilement d'au
moins
_POSIX_SIGQUEUE_MAX (32) signaux temps-réel pour un
processus. Néanmoins, Linux fonctionne différemment. Jusqu'au
noyau 2.6.7 inclus, Linux impose une limite pour l'ensemble des signaux
empilés sur le système pour tous les processus. Cette limite
peut être consultée, et modifiée (avec les
privilèges adéquats) grâce au fichier
/proc/sys/kernel/rtsig-max. Un fichier associé,
/proc/sys/kernel/rtsig-nr, indique combien de signaux temps-réel
sont actuellement empilés. Dans Linux 2.6.8, ces interfaces
/proc ont été remplacées par la limite de
ressources
RLIMIT_SIGPENDING, qui spécifie une limite par
utilisateur pour les signaux empilés ; voir
setrlimit(2)
pour plus de détails.
Fonctions pour signaux sûr asynchrones¶
Un gestionnaire de signal doit prendre beaucoup de précautions, puisqu'il
peut interrompre à n'importe quel endroit l'exécution du
programme. POSIX possède la notion de « fonctions
sûres ». Si un signal interrompt l'exécution d'une
fonction non sûre, et que le
gestionnaire appelle une fonction
non sûre, alors le comportement du programme n'est pas défini.
POSIX.1-2004 (également appelée « POSIX.1-2001
Technical Corrigendum 2 ») impose qu'une implémentation
garantisse que les fonctions suivantes puissent être appelée
sans risque à l'intérieur d'un gestionnaire de signal :
_Exit()
_exit()
abort()
accept()
access()
aio_error()
aio_return()
aio_suspend()
alarm()
bind()
cfgetispeed()
cfgetospeed()
cfsetispeed()
cfsetospeed()
chdir()
chmod()
chown()
clock_gettime()
close()
connect()
creat()
dup()
dup2()
execle()
execve()
fchmod()
fchown()
fcntl()
fdatasync()
fork()
fpathconf()
fstat()
fsync()
ftruncate()
getegid()
geteuid()
getgid()
getgroups()
getpeername()
getpgrp()
getpid()
getppid()
getsockname()
getsockopt()
getuid()
kill()
link()
listen()
lseek()
lstat()
mkdir()
mkfifo()
open()
pathconf()
pause()
pipe()
poll()
posix_trace_event()
pselect()
raise()
read()
readlink()
recv()
recvfrom()
recvmsg()
rename()
rmdir()
select()
sem_post()
send()
sendmsg()
sendto()
setgid()
setpgid()
setsid()
setsockopt()
setuid()
shutdown()
sigaction()
sigaddset()
sigdelset()
sigemptyset()
sigfillset()
sigismember()
signal()
sigpause()
sigpending()
sigprocmask()
sigqueue()
sigset()
sigsuspend()
sleep()
sockatmark()
socket()
socketpair()
stat()
symlink()
sysconf()
tcdrain()
tcflow()
tcflush()
tcgetattr()
tcgetpgrp()
tcsendbreak()
tcsetattr()
tcsetpgrp()
time()
timer_getoverrun()
timer_gettime()
timer_settime()
times()
umask()
uname()
unlink()
utime()
wait()
waitpid()
write()
POSIX.1-2008 supprime fpathconf(), pathconf() et sysconf() de la liste ci-dessus
et ajoute les fonctions suivantes :
execl()
execv()
faccessat()
fchmodat()
fchownat()
fexecve()
fstatat()
futimens()
linkat()
mkdirat()
mkfifoat()
mknod()
mknodat()
openat()
readlinkat()
renameat()
symlinkat()
unlinkat()
utimensat()
utimes()
Interruption des appels système et des fonctions de bibliothèque par des gestionnaires de signal¶
Si un gestionnaire de signal est invoqué pendant qu'un appel
système ou une fonction de bibliothèque est bloqué,
alors :
- *
- soit l'appel est automatiquement redémarré après le
retour du gestionnaire de signal ;
- *
- soit l'appel échoue avec l'erreur EINTR.
Lequel de ces deux comportements se produira dépend de l'interface et de
si le gestionnaire de signal a été mis en place avec l'attribut
SA_RESTART (consultez
sigaction(2)). Les détails varient
selon les systèmes UNIX ; voici ceux pour Linux.
Si un appel bloqué à l'une des interfaces suivantes est interrompu
par un gestionnaire de signal, l'appel sera automatiquement
redémarré après le retour du gestionnaire de signal si
l'attribut
SA_RESTART a été indiqué ;
autrement, l'appel échouera avec l'erreur
EINTR :
- *
- Les appels read(2), readv(2), write(2),
writev(2) et ioctl(2) sur des périphériques
« lents ». Un périphérique
« lent » est un périphérique
où un appel d'entrées-sorties peut bloquer pendant un temps
infini, par exemple un terminal, un tube ou une socket. (Selon cette
définition, un disque n'est pas un périphérique
lent.) Si un appel d'entrées-sorties sur un
périphérique lent a déjà
transféré des données au moment où il est
interrompu par un gestionnaire de signal, l'appel renverra un code de
succès (normalement, le nombre d'octets
transférés).
- *
- open (2), s'il peut bloquer (par exemple, lors de l'ouverture d'une
FIFO ; consultez fifo(7)).
- *
- wait(2), wait3(2), wait4(2), waitid(2), et
waitpid(2).
- *
- Interfaces de sockets : accept(2), connect(2),
recv(2), recvfrom(2), recvmsg(2), send(2),
sendto(2) et sendmsg(2), à moins qu'une temporisation
n'ai été placée sur la socket (voir ci-dessous).
- *
- Interfaces de verrouillage de fichiers : opération
F_SETLKW de flock(2) et fcntl(2).
- *
- Interfaces de files de messages POSIX : mq_receive(3),
mq_timedreceive(3), mq_send(3) et
mq_timedsend(3).
- *
- Opération FUTEX_WAIT de futex(2) (depuis
Linux 2.6.22 ; auparavant, échouait toujours avec
l'erreur EINTR).
- *
- Interfaces de sémaphores POSIX : sem_wait(3) et
sem_timedwait(3) (depuis Linux 2.6.22 ; auparavant,
échouait toujours avec l'erreur EINTR).
Les interfaces suivantes ne sont jamais relancées après avoir
été interrompues par un gestionnaire de signal, quelle que soit
l'utilisation de
SA_RESTART ; elles échouent toujours
avec l'erreur
EINTR lorsqu'elles sont interrompues par un gestionnaire
de signal :
- *
- Les interfaces de socket, quand une temporisation a été
définie sur la socket en utilisant setsockopt(2) ;
accept(2), recv(2), recvfrom(2) et recvmsg(2),
si un délai de réception ( SO_RCVTIMEO) a
été défini ; connect(2),
send(2), sendto(2) et sendmsg(2), si un délai
de transmission ( SO_SNDTIMEO) a été
défini.
- *
- Interfaces utilisées pour attendre des signaux :
pause(2), sigsuspend(2), sigtimedwait(2) et
sigwaitinfo(2).
- *
- Interfaces de multiplexage de descripteurs de fichier :
epoll_wait(2), epoll_pwait(2), poll(2),
ppoll(2), select(2) et pselect(2).
- *
- Interfaces IPC de System V : msgrcv(2),
msgsnd(2), semop(2) et semtimedop(2).
- *
- Interfaces de sommeil : clock_nanosleep(2),
nanosleep(2) et usleep(3).
- *
- read(2) sur un descripteur de fichier inotify(7).
- *
- io_getevents(2).
La fonction
sleep(3) n'est également jamais relancée si
elle est interrompue par un gestionnaire, mais elle renvoie un code de retour
de succès, le nombre de secondes restantes pour le sommeil.
Interruption des appels système et des fonctions de bibliothèque par des signaux d'arrêt¶
Sous Linux, même en l'absence de gestionnaires de signal, certaines
interfaces en mode bloquant peuvent échouer avec l'erreur
EINTR
après que le processus a été arrêté par
l'un des signaux d'arrêt et relancé avec le signal
SIGCONT. Ce comportement n'est pas ratifié par POSIX.1 et
n'apparaît pas sur d'autres systèmes.
Les interfaces Linux qui affichent ce comportement sont :
- *
- Les interfaces de socket, quand une temporisation a été
définie sur la socket en utilisant setsockopt(2) ;
accept(2), recv(2), recvfrom(2) et recvmsg(2),
si un délai de réception ( SO_RCVTIMEO) a
été défini ; connect(2),
send(2), sendto(2) et sendmsg(2), si un délai
de transmission ( SO_SNDTIMEO) a été
défini.
- *
- epoll_wait(2), epoll_pwait(2).
- *
- semop(2), semtimedop(2).
- *
- sigtimedwait(2), sigwaitinfo(2).
- *
- read(2) sur un descripteur de fichier inotify(7).
- *
- Linux 2.6.21 et antérieurs : opération
FUTEX_WAIT de futex(2), sem_timedwait(3),
sem_wait(3).
- *
- Linux 2.6.8 et antérieurs : msgrcv(2),
msgsnd(2).
- *
- Linux 2.4 et antérieurs : nanosleep(2).
POSIX.1, sauf indication contraire.
VOIR AUSSI¶
kill(1),
getrlimit(2),
kill(2),
killpg(2),
restart_syscall(2),
rt_sigqueueinfo(2),
setitimer(2),
setrlimit(2),
sgetmask(2),
sigaction(2),
sigaltstack(2),
signal(2),
signalfd(2),
sigpending(2),
sigprocmask(2),
sigsuspend(2),
sigwaitinfo(2),
abort(3),
bsd_signal(3),
longjmp(3),
raise(3),
pthread_sigqueue(3),
sigqueue(3),
sigset(3),
sigsetops(3),
sigvec(3),
sigwait(3),
strsignal(3),
sysv_signal(3),
core(5),
proc(5),
pthreads(7),
sigevent(7)
COLOPHON¶
Cette page fait partie de la publication 3.65 du projet
man-pages 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/.
TRADUCTION¶
Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a
<
http://po4a.alioth.debian.org/> par l'équipe de traduction
francophone au sein du projet perkamon
<
http://perkamon.alioth.debian.org/>.
Christophe Blaess <
http://www.blaess.fr/christophe/> (1996-2003), Alain
Portal <
http://manpagesfr.free.fr/> (2003-2006). Julien Cristau et
l'équipe francophone de traduction de Debian (2006-2009).
Veuillez signaler toute erreur de traduction en écrivant à
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
paquet
manpages-fr.
Vous pouvez toujours avoir accès à la version anglaise de ce
document en utilisant la commande «
man -L C
<section>
<page_de_man> ».