Provided by: manpages-fr-dev_3.32d0.2p4-1_all bug

NOM

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

SYNOPSIS

       #include <sys/time.h>
       #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 *new_limit,
        struct rlimit *old_limit);

   Exigences    de    macros    de   test   de   fonctionnalités   pour   la   glibc   (consultez
   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 (l'argument rlim de getrlimit() et setrlimit()) :

           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)  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 maximum de la mémoire virtuelle du processus en octets. 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  de  la  pile  automatique
              é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)). Depuis que 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 maximum du fichier core. 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. Si un processus atteint cette  limite  souple,  il
              reçoit  le  signal SIGXCPU. L'action par défaut en est la terminaison du processus.
              Mais le signal peut être capturé et le gestionnaire peut renvoyer  le  contrôle  au
              programme  principal. Si le processus continue à consommer du temps CPU, il recevra
              SIGXCPU toutes les secondes jusqu'à atteindre sa  limite  stricte,  où  il  recevra
              SIGKILL.  (Ceci  correspond au comportement de Linux 2.2 à 2.6. Les implémentations
              varient sur le comportement vis‐à‐vis d'un 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 affecte  les  appels  brk(2)  et  sbrk(2),  qui
              échouent avec l'erreur ENOMEM si la limite souple est dépassée.

       RLIMIT_FSIZE
              Taille   maximale  d'un  fichier  que  le  processus  peut  créer.  Les  tentatives
              d'extension d'un fichier au‐delà de cette limite résultent en  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 (Premiers Linux 2.4 seulement)
              Une  limite  sur 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 virtuelle 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  de  shmctl(2)  SHM_LOCK  sont   comptés
              séparément  des  verrous de mémoire par processus établis par mlock(2), mlockall(2)
              et mmap(2) MAP_LOCKED ; un processus peut verrouiller des octets jusqu'à la  limite
              dans  chacune  de  ces catégories. Dans les noyaux antérieurs à 2.6.9, cette limite
              contrôlait la quantité de mémoire qu'un processus privilégié  pouvait  verrouiller.
              Depuis  Linux  2.6.9,  un  processus  privilégie peut verrouiller autant de mémoire
              qu'il le souhaite, et cette limite contrôle la quantité  de  mémoire  pouvant  être
              verrouillée par un processus non privilégié.

       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).  Le  nombre  d'octets  pour  chaque  file  de  messages créée par
              l'utilisateur (jusqu'à sa destruction) est déterminé par la formule suivante :

                 octets = attr.mq_maxmsg * sizeof(struct msg_msg *) +
                          attr.mq_maxmsg * attr.mq_msgsize

              où attr est la structure mq_attr passée comme quatrième argument à mq_open(3).

              Le premier terme de la formule, qui inclut sizeof(struct msg_msg *)  (4 octets  sur
              Linux/i386)  garantit  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. (Cette bizarrerie apparaît  car  des  nombres
              négatifs  ne  peuvent  pas  être utilisés comme limites de ressources, en raison de
              leur signification souvent particulière. Par exemple, RLIM_INFINITY est souvent  la
              même chose que -1.)

       RLIMIT_NOFILE
              Le   nombre  maximal  de  descripteurs  de  fichier  qu'un  processus  peut  ouvrir
              simultanément. 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.

       RLIMIT_NPROC
              Le nombre maximal de processus (ou plus précisément, sous Linux,  de  threads)  qui
              peuvent  être  créés  pour  l'UID réel du processus appelant. Une fois cette limite
              atteinte, fork(2) échoue avec l'erreur EAGAIN.

       RLIMIT_RSS
              Indique la limite (en pages) 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).

       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
              bloquer lors de l'exécution d'un appel système. À cause 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
              dure soit atteinte, ce qui provoque l'envoie 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.

       RLIMIT_SIGPENDING (Depuis Linux 2.6.8)
              Spécifie la limite du nombre de signaux pouvant être mis en attente pour l'UID 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(2) ; 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,  soit  l'appelant  a  la  capacité
       CAP_SYS_RESOURCE, soit les identifiants d'utilisateur réel et effectif et le set-UID sauvé
       du  processus  cible  correspond  à  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  correspond
       à l'identifiant de groupe réel du processus.

VALEUR RENVOYÉE

       Ces  appels  système  renvoient 0 en cas de succès, ou -1 en cas d'échec, auquel cas errno
       contient le code d'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  valide ;  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 pouvoir faire cela. Ou le processus  a  essayé
              d'augmenter la limite stricte RLIMIT_NOFILE au‐dessus du maximum (NR_OPEN) du noyau
              actuel. Ou alors le processus appelant n'avait pas la  permission  de  changer  les
              limites du processus spécifié 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.

CONFORMITÉ

       getrlimit(), setrlimit() : SVr4, BSD 4.3, POSIX.1-2001.
       prlimit() : spécifique à Linux.

       RLIMIT_MEMLOCK  et  RLIMIT_NPROC  proviennent  de  BSD  et  ne  sont  pas   définis   dans
       POSIX.1-2001 ;  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-2001 ;
       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 fils créé avec fork(2) hérite des limites  de  ressource  de  son  père.  Les
       limites de ressource sont préservées à travers un execve(2).

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

       Des  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().

EXEMPLE

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

       #define _GNU_SOURCE
       #include <stdio.h>
       #include <time.h>
       #include <stdlib.h>
       #include <unistd.h>
       #include <sys/resource.h>

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

           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)
               errExit("prlimit-1");
           printf("Limites précédentes : souple=%lld; stricte=%lld\n",
                   (long long) old.rlim_cur, (long long) old.rlim_max);

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

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

           exit(EXIT_FAILURE);
       }

BOGUES

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

       Dans les noyaux de la série 2.6 antérieurs  à  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,
       fixer 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  le  noyau  2.6.12 ;  le
       problème a été corrigé dans le noyau 2.6.13.

       Dans  le  noyau  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. Ceci est corrigé depuis le noyau 2.6.13.

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

VOIR AUSSI

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

COLOPHON

       Cette  page  fait partie de la publication 3.32 du projet man-pages Linux. Une description
       du projet et des  instructions  pour  signaler  des  anomalies  peuvent  être  trouvées  à
       l'adresse <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

       Depuis    2010,    cette   traduction   est   maintenue   à   l'aide   de   l'outil   po4a
       <URL:http://po4a.alioth.debian.org/> par l'équipe de traduction  francophone  au  sein  du
       projet perkamon <URL:http://perkamon.alioth.debian.org/>.

       Christophe   Blaess   <URL:http://www.blaess.fr/christophe/>   (1996-2003),  Alain  Portal
       <URL: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> ».