Provided by: manpages-fr-dev_4.15.0-9_all 
NOM
getrlimit, setrlimit, prlimit - Lire et écrire les limites et utilisations des ressources
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 *new_limit,
struct rlimit *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 (Linux 2.4.0 à 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.
Dans les noyaux Linux antérieurs au 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érieur :
bytes = attr.mq_maxmsg * sizeof(struct msg_msg *) +
/* Pour le dépassement */
attr.mq_maxmsg * attr.mq_msgsize;
/* Pour les données de 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.
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
On success, these system calls return 0. On error, -1 is returned, and errno is set to
indicate the error.
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).
┌────────────────────────────────────────────────────────┬──────────────────────┬─────────┐
│Interface │ Attribut │ Valeur │
├────────────────────────────────────────────────────────┼──────────────────────┼─────────┤
│getrlimit(), setrlimit(), prlimit() │ Sécurité des threads │ MT-Safe │
└────────────────────────────────────────────────────────┴──────────────────────┴─────────┘
CONFORMITÉ
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 version 2.13, les fonctions d'enrobage 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 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. Cela 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.
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 version 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 <stdint.h>
#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=%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)
errExit("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)
COLOPHON
Cette page fait partie de la publication 5.13 du projet man-pages Linux. Une description
du projet et des instructions pour signaler des anomalies et la dernière version de cette
page peuvent être trouvées à l'adresse https://www.kernel.org/doc/man-pages/.
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⟩.