Provided by: manpages-fr-dev_3.65d1p1-1_all 
NOM
getrlimit, setrlimit, prlimit - Lire et é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 && _FILE_OFFSET_BITS == 64
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 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 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'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, 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).
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 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.
À 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).
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().
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, 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 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.
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 à 2.4.22 ne détectaient pas l'erreur EINVAL pour setrlimit() quand rlim->rlim_cur
était plus grand que rlim->rlim_max.
EXEMPLE
Le programme ci-dessous démontre l'utilisation de prlimit().
#define _GNU_SOURCE
#define _FILE_OFFSET_BITS 64
#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/resource.h>
#define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \
} while (0)
int
main(int argc, char *argv[])
{
struct rlimit old, new;
struct rlimit *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);
}
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), signal(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> ».