Provided by: manpages-fr-dev_3.07.1-1_all bug

NOM

       getrlimit,  setrlimit  -  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);

DESCRIPTION

       getrlimit()  et  setrlimit()  lisent  ou  écrivent  les   limites   des
       ressources systèmes. 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()).

       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
              (voir  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 inclue sizeof(struct msg_msg
              *) (4octets 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, voir 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.

       RLIMIT_NPROC
              Le nombre maximum 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 voir 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 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)).

       RLIMIT_OFILE est le nom BSD pour RLIMIT_NOFILE.

VALEUR RENVOYÉE

       En cas de réussite, zéro est renvoyé, sinon -1  est  renvoyé  et  errno
       contient le code d’erreur.

ERREURS

       EFAULT rlim pointe en dehors de l’espace d’adressage disponible.

       EINVAL resource n’est pas valide ; ou, pour setrlimit(), rlim->rlim_cur
              est plus grand que rlim->rlim_max.

       EPERM  Un processus non privilégié a essayé d’utiliser setrlimit() pour
              augmenter  ses  limites  souple ou stricte au delà de l’actuelle
              limite stricte ; la  capacité  CAP_SYS_RESOURCE  est  nécessaire
              pour   pouvoir   faire   cela.  Ou  alors  le  processus  essaye
              d’augmenter  avec  setrlimit()  la  limite  souple  ou   stricte
              RLIMIT_NOFILE au‐dessus des maxima du noyau (NR_OPEN).

CONFORMITÉ

       SVr4, BSD 4.3, POSIX.1-2001. 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).

BOGUES

       Dans  d’anciens  noyaux  Linux,  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.07  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

       Cette  page  de  manuel  a  été  traduite et mise à jour par Christophe
       Blaess <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis  par
       Alain  Portal  <aportal AT univ-montp2 DOT fr> jusqu’en 2006, et mise à
       disposition sur http://manpagesfr.free.fr/.

       Les mises à jour et corrections de la version présente dans Debian sont
       directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
       francophone de traduction de Debian.

       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> ».