Provided by: manpages-fr-dev_4.18.1-1_all bug

NOM

       getrlimit, setrlimit, prlimit - Lire et écrire les limites et utilisations des ressources

BIBLIOTHÈQUE

       Bibliothèque C standard (libc, -lc)

SYNOPSIS

       #include <sys/resource.h>

       int getrlimit(int resource, struct rlimit *rlim);
       int setrlimit(int resource, const struct rlimit *rlim);

       int prlimit(pid_t pid, int resource,
                   const struct rlimit *_Nullable new_limit,
                   struct rlimit *_Nullable old_limit);

   Exigences    de    macros    de   test   de   fonctionnalités   pour   la   glibc   (consulter
   feature_test_macros(7)) :

       prlimit() :
           _GNU_SOURCE

DESCRIPTION

       Les appels  système  getrlimit()  et  setrlimit()  lisent  ou  écrivent  les  limites  des
       ressources  système.  Chaque  ressource a une limite souple et une limite stricte définies
       par la structure rlimit :

           struct rlimit {
             rlim_t rlim_cur; /* limite souple */
             rlim_t rlim_max; /* limite stricte (plafond
                                 de rlim_cur) */
           };

       La limite  souple  est  la  valeur  que  le  noyau  prend  en  compte  pour  la  ressource
       correspondante.  La  limite  stricte  agit  comme  un  plafond  pour la limite souple : un
       processus non privilégié peut seulement modifier sa limite souple dans l'intervalle  entre
       zéro  et  la  limite  stricte, et diminuer (de manière irréversible) sa limite stricte. Un
       processus privilégié (sous Linux : un processus ayant la  capacité  CAP_SYS_RESOURCE  dans
       l'espace de noms initial de l'utilisateur) peut modifier ses deux limites à sa guise.

       La  valeur  RLIM_INFINITY  indique  une  limite infinie pour la ressource (aussi bien pour
       getrlimit() que pour setrlimit()).

       Le paramètre resource doit être l'un des éléments suivants :

       RLIMIT_AS
              Taille maximale de la mémoire virtuelle du processus  (espace  d'adressage).  Cette
              limite  est  exprimée  en  octets et est arrondie à la taille inférieure de la page
              système. Cette limite affecte les  appels  à  brk(2),  mmap(2)  et  mremap(2),  qui
              échouent  avec  l'erreur  ENOMEM  en  cas  de dépassement de cette limite. De même,
              l'extension automatique de la pile échouera (et générera un SIGSEGV  qui  tuera  le
              processus   si   aucune   pile   alternative   n'a  été  définie  par  un  appel  à
              sigaltstack(2)). Comme cette valeur est de type long, sur les machines où  le  type
              long est sur 32 bits, soit cette limite est au plus 2 GiB, soit cette ressource est
              illimitée.

       RLIMIT_CORE
              Taille maximale d'un fichier core (consulter core(5)) qu'un processus peut générer.
              Lorsqu'elle  vaut  zéro,  aucun fichier d'image noyau (Ndt : core dump) n'est créé.
              Lorsqu'elle ne vaut pas zéro, les fichiers d'image noyau plus grands sont  tronqués
              à cette taille.

       RLIMIT_CPU
              Limite  de  temps CPU en secondes consommable par le processus. Lorsqu'un processus
              atteint cette limite souple, il reçoit le signal SIGXCPU. L'action par défaut  pour
              ce  signal  est la terminaison du processus. Mais le signal peut être capturé et le
              gestionnaire peut rendre le  contrôle  au  programme  principal.  Si  le  processus
              continue  à  consommer du temps CPU, il recevra SIGXCPU toutes les secondes jusqu'à
              atteindre la limite stricte, où il recevra SIGKILL. (Ce  dernier  point  décrit  le
              comportement  de  Linux.  Les  implémentations  varient  sur la façon de traiter le
              processus qui continue à consommer du temps CPU  après  dépassement  de  sa  limite
              souple. Les applications portables qui doivent capturer ce signal devraient prévoir
              une terminaison propre dès la première réception de SIGXCPU.)

       RLIMIT_DATA
              Taille maximale du segment de données d'un  processus  (données  initialisées,  non
              initialisées,  et tas). Cette limite est indiquée en octets et arrondie à la taille
              inférieure de la page système. Cette limite affecte les appels brk(2),  sbrk(2)  et
              (depuis  Linux 4.7)  mmap(2)) qui échouent avec l'erreur ENOMEM si la limite souple
              est dépassée.

       RLIMIT_FSIZE
              Taille maximale,  en  octets,  d'un  fichier  que  le  processus  peut  créer.  Les
              tentatives d'extension d'un fichier au‐delà de cette limite aboutissent à un signal
              SIGXFSZ. Par défaut ce signal termine le processus, mais il peut être  capturé,  et
              dans  ce  cas  l'appel  système concerné (par exemple write(2), truncate(2)) échoue
              avec l'erreur EFBIG.

       RLIMIT_LOCKS (de Linux 2.4.0 à Linux 2.4.24)
              Limite pour le nombre combiné de verrous flock(2) et fcntl(2) que le processus peut
              établir.

       RLIMIT_MEMLOCK
              Le  nombre maximal d'octets de mémoire que le processus peut verrouiller en RAM. En
              pratique cette limite est arrondie vers le bas au multiple de la taille de page  le
              plus  proche.  Cette  limite  affecte mlock(2) et mlockall(2) ainsi que l'opération
              MAP_LOCKED de mmap(2). Depuis Linux 2.6.9, elle affecte aussi l'opération  SHM_LOCK
              de  shmctl(2), où elle limite le nombre total d'octets dans des segments de mémoire
              partagée  (consultez  shmget(2))  que  l'UID  réel  du  processus   appelant   peut
              verrouiller.  Les verrous SHM_LOCK de shmctl(2) sont comptés séparément des verrous
              de mémoire par  processus  établis  par  MAP_LOCKED  de  mlock(2),  mlockall(2)  et
              mmap(2) ;  un  processus  peut verrouiller des octets jusqu'à cette limite dans ces
              deux catégories.

              Avant Linux 2.6.9, cette limite contrôlait la quantité de mémoire qui pouvait  être
              verrouillée  par  un  processus privilégié. Depuis Linux 2.6.9, il n'existe plus de
              limite de quantité de mémoire verrouillable  par  un  processus  privilégié,  cette
              limite  gère donc plutôt la quantité de mémoire qu'un processus non privilégié peut
              verrouiller.

       RLIMIT_MSGQUEUE (depuis Linux 2.6.8)
              Indique la limite du nombre  d'octets  pouvant  être  alloués  pour  les  files  de
              messages  POSIX  pour  l'UID réel du processus appelant. Cette limite est appliquée
              pour mq_open(3). Chaque file de message créée par l'utilisateur se calcule (jusqu'à
              sa destruction) par rapport à la limite via la formule suivante :

                  Depuis Linux 3.5 :

                      bytes = attr.mq_maxmsg * sizeof(struct msg_msg) +
                              MIN(attr.mq_maxmsg, MQ_PRIO_MAX) *
                                    sizeof(struct posix_msg_tree_node)+
                                              /* Pour le dépassement */
                              attr.mq_maxmsg * attr.mq_msgsize;
                                              /* Pour les données du message */

                  Linux 3.4 et antérieurs :

                      bytes = attr.mq_maxmsg * sizeof(struct msg_msg *) +
                                              /* Pour le dépassement */
                              attr.mq_maxmsg * attr.mq_msgsize;
                                              /* Pour les données du message */

              où  attr  est la structure mq_attr passée comme quatrième argument à mq_open(3), et
              msg_msg et posix_msg_tree_node sont les structures internes du noyau.

              Le terme de « dépassement » de la formule  représente  les  octets  de  dépassement
              nécessaires à l'implémentation. Ce dépassement assure que l'utilisateur ne peut pas
              créer un nombre illimité de messages vides (ces messages consomment tout de même de
              la mémoire système).

       RLIMIT_NICE (depuis Linux 2.6.12, consultez la section BOGUES ci‐dessous)
              Indique  un  plafond  pour la valeur de politesse du processus pouvant être définie
              par setpriority(2) ou nice(2). Le plafond réel pour  la  valeur  de  politesse  est
              calculé par la formule 20 - rlim_cur. La plage utile pour cette limite est ainsi de
              1 (pour une valeur de politesse de 19) à 40 (pour une valeur de politesse de  -20).
              Cette  bizarrerie  est  nécessaire  car  des  nombres  négatifs ne peuvent pas être
              utilisés comme limite  de  ressource,  en  raison  de  leur  signification  souvent
              particulière.  Par  exemple,  RLIM_INFINITY  est souvent la même chose que -1. Pour
              plus de détails sur la valeur de politesse, consultez sched(7).

       RLIMIT_NOFILE
              Valeur supérieure de 1 au nombre maximal de descripteurs de fichier que peut ouvrir
              ce  processus. Les tentatives d'ouverture (open(2), pipe(2), dup(2), etc) dépassant
              cette limite renverront l'erreur EMFILE (historiquement, cette limite était appelée
              RLIMIT_OFILE sur les BSD).

              Depuis  Linux 4.5, cette limite définit également le nombre maximal de descripteurs
              de fichier qu'un processus non privilégié (sans la capacité CAP_SYS_RESOURCE)  peut
              détenir  « en  vol » sur les autres processus, en les passant à travers des sockets
              du domaine UNIX. Cette limite s'applique à l'appel système sendmsg(2). Pour plus de
              détails, voir unix(7).

       RLIMIT_NPROC
              Limite du nombre de processus étendus (ou, plus précisément, sur Linux, de threads)
              pour l'identifiant de l'utilisateur réel du processus appelant. Tant que le  nombre
              en  cours  de  processus  appartenant  à  l'identifiant  de  l'utilisateur  réel du
              processus est supérieur ou égal  à  cette  limite,  fork(2)  échoue  avec  l'erreur
              EAGAIN.

              La  limite  RLIMIT_NPROC  n'est  pas  gérée  pour les processus qui ont la capacité
              CAP_SYS_ADMIN ou CAP_SYS_RESOURCE, ou bien qui fonctionnent avec l'identifiant réel
              de l'utilisateur 0..

       RLIMIT_RSS
              Indique  la  limite  (en octets) pour la taille de l'ensemble résident du processus
              (le nombre de pages de mémoire virtuelle en RAM). Cette limite n'a d'effet que sous
              Linux 2.4.x   où   x < 30,   et  n'affecte  que  les  appels  madvise(2)  indiquant
              MADV_WILLNEED.

       RLIMIT_RTPRIO (depuis Linux 2.6.12, mais consultez BOGUES)
              Indique un plafond pour la priorité temps‐réel pouvant être appliquée au  processus
              par sched_setscheduler(2) et sched_setparam(2).

              Pour plus de détails sur les règles d'ordonnancement en temps réel, voir sched(7)

       RLIMIT_RTTIME (depuis Linux 2.6.25)
              Indique  une  limite de la quantité de temps (en microsecondes) CPU qu'un processus
              ordonnancé par une  politique  d'ordonnancement  temps  réel  peut  consommer  sans
              provoquer  un appel système bloquant. Pour les besoins de cette limite, le décompte
              du temps CPU qu'il a consommé est remis  à  zéro  à  chaque  fois  qu'un  processus
              exécute  un appel système bloquant. Le décompte du temps CPU n'est pas remis à zéro
              si le processus continue d'essayer d'utiliser le CPU mais est préempté,  ou  si  sa
              tranche de temps expire, ou s'il appelle sched_yield(2).

              Quand  la  limite douce est atteinte, un signal SIGXCPU est envoyé au processus. Si
              le processus attrape ou ignore ce signal et continue  à  consommer  du  temps  CPU,
              alors  un  signal SIGXCPU sera généré une fois par seconde jusqu'à ce que la limite
              stricte soit atteinte, ce qui provoque l'envoi d'un signal SIGKILL au processus.

              L'objectif de cette limite est d'empêcher un processus temps réel fou de bloquer le
              système.

              Pour plus de détails sur les règles d'ordonnancement en temps réel, voir sched(7)

       RLIMIT_SIGPENDING (depuis Linux 2.6.8)
              Spécifie  la  limite  du  nombre  de  signaux  pouvant  être  mis  en  attente pour
              l'identifiant utilisateur réel du processus  appelant.  La  vérification  de  cette
              limite  prend en compte à la fois les signaux classiques et les signaux temps‐réel.
              Cependant, cette limite n'est appliquée que  pour  sigqueue(3) ;  il  est  toujours
              possible  d'utiliser kill(2) pour mettre en attente une instance de tout signal qui
              n'est pas déjà en attente pour le processus.

       RLIMIT_STACK
              La taille maximale de la pile du  processus,  en  octets.  Une  fois  cette  limite
              atteinte,  un signal SIGSEGV est déclenché. Pour gérer ce signal, le processus doit
              utiliser une pile spécifique pour signaux (sigaltstack(2)).

              Depuis Linux 2.6.23, cette limite détermine également la quantité d'espace  utilisé
              pour  les  paramètres  et  les  variables  d'environnement du processus ; consultez
              execve(2) pour plus de détails.

   prlimit()
       L'appel système prlimit()  spécifique à Linux combine  et  étend  les  fonctionnalités  de
       setrlimit() et getrlimit(). Il peut être utilisé pour affecter ou récupérer les limites de
       ressources de tout processus.

       Le paramètre resource a le même sens que dans setrlimit() et getrlimit().

       Si le paramètre new_limit ne vaut pas NULL, alors la structure  rlimit  vers  laquelle  il
       pointe  est  utilisée  pour  affecter de nouvelles valeurs aux limites souples et strictes
       pour resource. Si le paramètres old_limit ne vaut pas NULL, alors un appel à prlimit() qui
       réussit  place les limites antérieures souples et strictes pour resource dans la structure
       rlimit pointée par old_limit.

       L'argument pid spécifie l'identifiant du processus sur lequel l'appel agit. Si pid vaut 0,
       alors  l'appel  s'applique  au  processus  appelant.  Pour  positionner  ou interroger les
       ressources  d'un  processus  autre  que  lui-même,  l'appelant  doit  avoir  la   capacité
       CAP_SYS_RESOURCE  dans  l'espace  de  noms  utilisateur  du  processus dont les limites de
       ressources vont être modifiées ou bien les identifiants d'utilisateur réel, effectif et le
       set-UID  sauvé  du processus cible doivent correspondre à l'identifiant d'utilisateur réel
       de l'appelant et les identifiants de groupe réel  et  effectif  et  le  set-GID  sauvé  du
       processus cible doivent correspondre à l'identifiant de groupe réel de l'appelant.

VALEUR RENVOYÉE

       Ces appels système renvoient 0 en cas de succès ou -1 en cas d'échec, auquel cas errno est
       positionné pour indiquer l'erreur.

ERREURS

       EFAULT L'un des arguments pointe en dehors de l'espace d'adressage accessible.

       EINVAL La valeur spécifiée dans resource n'est pas autorisée ;  ou,  pour  setrlimit()  ou
              prlimit(), rlim->rlim_cur est plus grand que rlim->rlim_max.

       EPERM  Un  processus  non  privilégié a essayé d’augmenter la limite stricte ; la capacité
              CAP_SYS_RESOURCE est nécessaire pour faire cela.

       EPERM  L'appelant a essayé d'augmenter la limite stricte RLIMIT_NOFILE  au-delà  de  celle
              maximale définie dans /proc/sys/fs/nr_open (voir proc(5))

       EPERM  (prlimit())  Le processus appelant n'avait pas les droits pour fixer des limites au
              processus indiqué par pid.

       ESRCH  Impossible de trouver un processus dont l'identifiant est indiqué par pid.

VERSIONS

       L'appel système prlimit() est disponible depuis Linux 2.6.36 ; la prise en charge dans  la
       glibc est disponible depuis la version 2.13.

ATTRIBUTS

       Pour une explication des termes utilisés dans cette section, consulter attributes(7).

       ┌────────────────────────────────────────────────────────┬──────────────────────┬─────────┐
       │InterfaceAttributValeur  │
       ├────────────────────────────────────────────────────────┼──────────────────────┼─────────┤
       │getrlimit(), setrlimit(), prlimit()                     │ Sécurité des threads │ MT-Safe │
       └────────────────────────────────────────────────────────┴──────────────────────┴─────────┘

STANDARDS

       getrlimit(), setrlimit() : POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD.

       prlimit() : spécifique à Linux.

       RLIMIT_MEMLOCK  et  RLIMIT_NPROC  proviennent de BSD et ne sont pas définis dans POSIX.1 ;
       ils sont présents  dans  les  BSD  et  Linux,  mais  dans  peu  d'autres  implémentations.
       RLIMIT_RSS  vient  de BSD et n'est pas défini dans POSIX.1 ; cependant, il est présent sur
       la plupart des implémentations. RLIMIT_MSGQUEUE, RLIMIT_NICE, RLIMIT_RTPRIO, RLIMIT_RTTIME
       et RLIMIT_SIGPENDING sont spécifiques à Linux.

NOTES

       Un  processus  enfant créé avec fork(2) hérite des limites de ressource de son parent. Les
       limites de ressource sont préservées à travers un execve(2).

       Les limites de ressource sont des attributs par processus partagés par  tous  les  threads
       d'un processus.

       Descendre  la  limite  souple  d'une ressource en dessous de l'actuelle utilisation par le
       processus de cette ressource fonctionne (mais  cela  empêchera  le  processus  d'augmenter
       ultérieurement sa consommation de cette ressource).

       On  peut  définir  les limites de ressource de l'interpréteur de commandes en utilisant la
       commande interne ulimit (limit dans csh(1)). Les limites de ressource de l'interpréteur de
       commandes sont héritées par les processus qu'il crée pour exécuter les commandes.

       À  partir  de  Linux  2.6.24, les limites de ressource de n'importe quel processus peuvent
       être examinées en consultant /proc/pid/limits ; consultez proc(5).

       Les systèmes anciens fournissent une fonction  vlimit()  qui  remplit  le  même  rôle  que
       setrlimit().  Pour  des  raisons  de  compatibilité ascendante, la glibc fournit aussi une
       fonction vlimit(), mais toutes les nouvelles applications devraient utiliser setrlimit().

   Différences entre la bibliothèque C et l'ABI du noyau
       A partir de la glibc 2.13, les fonctions d'enveloppe  getrlimit()  et  setrlimit()  de  la
       glibc  n'appellent  plus les appels systèmes correspondant, mais utilisent prlimit(), pour
       les raisons indiquées dans BUGS.

       Le nom de la fonction enveloppe dans la glibc est prlimit() ; l'appel système  sous-jacent
       est prlimit64().

BOGUES

       Dans  les  noyaux  Linux  plus  anciens,  les signaux SIGXCPU et SIGKILL envoyés lorsqu'un
       processus dépassait les limites souples et strictes pour RLIMIT_CPU  étaient  envoyés  une
       seconde (CPU) plus tard qu'ils n'auraient dû l'être. Cela a été corrigé dans Linux 2.6.8.

       Dans les noyaux Linux de la série 2.6 antérieurs à Linux 2.6.17, une limite RLIMIT_CPU à 0
       est  interprétée  par  erreur  comme  « pas  de  limite »  (comme  RLIM_INFINITY).  Depuis
       Linux 2.6.17, définir la limite à 0 a un effet, mais la limite est en fait d'une seconde.

       En raison d'un bogue du noyau, RLIMIT_RTPRIO ne marche pas dans Linux 2.6.12 ; le problème
       a été corrigé dans Linux 2.6.13.

       Dans Linux 2.6.12, il y avait une différence de 1 entre les valeurs de priorité  renvoyées
       par  getpriority(2)  et RLIMIT_NICE. Du coup, la limite réelle pour la valeur de politesse
       était calculée comme 19 - rlim_cur. Cela est corrigé depuis Linux 2.6.13.

       A partir de Linux 2.6.12, si un processus atteint sa limite  souple  RLIMIT_CPU  et  qu'il
       dispose  d'un  gestionnaire  pour  SIGXCPU,  alors  en  plus d'invoquer le gestionnaire de
       signal, le noyau augmente la limite souple d'une seconde. Ce comportement se répète si  le
       processus continue de consommer du temps processeur, jusqu'à ce que la limite stricte soit
       atteinte, auquel cas le processus est tué. D'autres implémentations ne  modifient  pas  la
       limite  souple  RLIMIT_CPU  de  cette  façon,  et  le  comportement  de  Linux n'est alors
       probablement pas conforme aux standards ; pour cette raison,  les  applications  portables
       doivent  éviter  de  tabler sur ce comportement. La limite propre à Linux RLIMIT_RTTIME se
       comporte de façon analogue lorsque la limite souple est atteinte.

       Les noyaux antérieurs à Linux 2.4.22 ne détectaient pas l'erreur EINVAL  pour  setrlimit()
       quand rlim->rlim_cur était plus grand que rlim->rlim_max.

       Pour  des  raisons  de compatibilité, Linux ne renvoie pas d'erreur quand une tentative de
       positionnement de RLIMIT_CPU a échoué.

   Représentation des limites de ressources de grande taille sur les plate-formes 32 bits
       Les fonctions d'enrobage de la glibc getrlimit() et setrlimit() utilisent un type  64 bits
       rlim_t, et ce même sur les plateformes 32 bits. Cependant, le type rlim_t utilisé dans les
       appels systèmes getrlimit() et setrlimit() est en fait un unsigned long (de  32 bits).  De
       plus,  sur  Linux,  le  noyau traite les limites de ressources sur les systèmes 32 bits au
       moyen du type unsigned long. Un type 32 bits n'est pourtant pas assez grand. Dans  le  cas
       présent,  la limite la plus pertinente est RLIMIT_FSIZE, qui indique la taille maximum que
       peut atteindre un fichier : pour être utilisable, cette limite doit être  représentée  par
       un type de la même taille que celui utilisé pour représenter les positions de curseur dans
       le fichier — c'est à dire, de la  taille  d'un  off_t  64  bits  (en  considérant  que  le
       programme a été compilé avec l'option _FILE_OFFSET_BITS=64).

       Pour  contourner  cette limitation du noyau, si un programme tente d'affecter à une limite
       de ressource une valeur trop grande pour être représentée par un type unsigned long de  32
       bits,  la fonction d'enrobage de la glibc setrlimit() change implicitement la valeur de la
       limite en RLIM_INFINITY. Autrement dit, l'affectation de la limite de ressource n'est  pas
       prise en compte, et cela sans aucune notification.

       Depuis la glibc 2.13, la glibc contourne ces limitations des appels système getrlimit() et
       setrlimit() en implémentant les fonctions setrlimit() et  getrlimit()  qui  font  appel  à
       prlimit().

EXEMPLES

       Le programme ci-dessous démontre l'utilisation de prlimit().

       #define _GNU_SOURCE
       #define _FILE_OFFSET_BITS 64
       #include <err.h>
       #include <stdint.h>
       #include <stdio.h>
       #include <stdlib.h>
       #include <sys/resource.h>
       #include <time.h>

       int
       main(int argc, char *argv[])
       {
           pid_t          pid;
           struct rlimit  old, new;
           struct rlimit  *newp;

           if (!(argc == 2 || argc == 4)) {
               fprintf(stderr, "Usage: %s <pid> [<nouvelle-limite-souple> "
                       "<nouvelle-limite-stricte>]\n", argv[0]);
               exit(EXIT_FAILURE);
           }

           pid = atoi(argv[1]);        /* PID du processus cible */

           newp = NULL;
           if (argc == 4) {
               new.rlim_cur = atoi(argv[2]);
               new.rlim_max = atoi(argv[3]);
               newp = &new;
           }

           /* Définir la limite de temps CPU du processus cible ;
              récupérer et afficher la limite de temps CPU antérieure */

           if (prlimit(pid, RLIMIT_CPU, newp, &old) == -1)
               err(EXIT_FAILURE, "prlimit-1");
           printf("Limites précédentes : souple=%jd; stricte=%jd\n",
                  (intmax_t) old.rlim_cur, (intmax_t) old.rlim_max);

           /* Récupérer et afficher la nouvelle limite de temps CPU */

           if (prlimit(pid, RLIMIT_CPU, NULL, &old) == -1)
               err(EXIT_FAILURE, "prlimit-2");
           printf("Nouvelles limites : souple=%jd; stricte=%jd\n",
                  (intmax_t) old.rlim_cur, (intmax_t) old.rlim_max);

           exit(EXIT_SUCCESS);
       }

VOIR AUSSI

       prlimit(1),   dup(2),   fcntl(2),   fork(2),  getrusage(2),  mlock(2),  mmap(2),  open(2),
       quotactl(2),  sbrk(2),   shmctl(2),   malloc(3),   sigqueue   (3),   ulimit(3),   core(5),
       capabilities(7), cgroups(7), credentials(7), signal(7)

TRADUCTION

       La  traduction  française  de  cette  page  de  manuel  a  été créée par Christophe Blaess
       <https://www.blaess.fr/christophe/>, Stéphan  Rafin  <stephan.rafin@laposte.net>,  Thierry
       Vignaud  <tvignaud@mandriva.com>,  François Micaux, Alain Portal <aportal@univ-montp2.fr>,
       Jean-Philippe   Guérard   <fevrier@tigreraye.org>,   Jean-Luc   Coulon   (f5ibh)    <jean-
       luc.coulon@wanadoo.fr>,    Julien    Cristau    <jcristau@debian.org>,    Thomas   Huriaux
       <thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin
       Duneau  <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis
       Barbier  <barbier@debian.org>,  David  Prévot   <david@tilapin.org>,   Cédric   Boutillier
       <cedric.boutillier@gmail.com>,  Frédéric  Hantrais  <fhantrais@gmail.com> et Jean-Philippe
       MENGUAL <jpmengual@debian.org>

       Cette traduction est une documentation libre ; veuillez vous reporter  à  la  GNU  General
       Public   License   version 3  ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩  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 à ⟨debian-l10n-french@lists.debian.org⟩.