getrlimit(2) System Calls Manual getrlimit(2)
NOM
getrlimit, setrlimit, prlimit - Lire et écrire les limites et utilisa-
tions 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 pri-
vilé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 arron-
die à la taille inférieure de la page système. Cette limite af-
fecte 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 res-
source est illimitée.
RLIMIT_CORE
Taille maximale d'un fichier core (consulter core(5)) qu'un pro-
cessus 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 termi-
naison du processus. Mais le signal peut être capturé et le ges-
tionnaire 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 Li-
nux. Les implémentations varient sur la façon de traiter le pro-
cessus qui continue à consommer du temps CPU après dépassement
de sa limite souple. Les applications portables qui doivent cap-
turer 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 indi-
quée en octets et arrondie à la taille inférieure de la page
système. Cette limite affecte les appels brk(2), sbrk(2) et (de-
puis 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 ver-
rouiller en RAM. En pratique cette limite est arrondie vers le
bas au multiple de la taille de page le plus proche. Cette li-
mite 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 to-
tal d'octets dans des segments de mémoire partagée (consultez
shmget(2)) que l'UID réel du processus appelant peut ver-
rouiller. 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 ver-
rouiller des octets jusqu'à cette limite dans ces deux catégo-
ries.
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 pri-
vilé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 appe-
lant. Cette limite est appliquée pour mq_open(3). Chaque file de
message créée par l'utilisateur se calcule (jusqu'à sa destruc-
tion) 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 struc-
tures 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-des-
sous)
Indique un plafond pour la valeur de politesse du processus pou-
vant ê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 fi-
chier que peut ouvrir ce processus. Les tentatives d'ouverture
(open(2), pipe(2), dup(2), etc) dépassant cette limite renver-
ront 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 maxi-
mal 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 ap-
partenant à 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 ap-
pliquée au processus par sched_setscheduler(2) et sched_setpa-
ram(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'ordonnance-
ment 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 pro-
cessus 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 at-
tente 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 quan-
tité d'espace utilisé pour les paramètres et les variables d'en-
vironnement 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 getrli-
mit().
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_li-
mit 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'es-
pace de noms utilisateur du processus dont les limites de ressources
vont être modifiées ou bien les identifiants d'utilisateur réel, effec-
tif 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 ac-
cessible.
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 indi-
qué 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 │
└─────────────────────────────────────┴──────────────────────┴─────────┘
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éfi-
nis 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 li-
mites 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é ascen-
dante, 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 se-
trlimit() de la glibc n'appellent plus les appels systèmes correspon-
dant, 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 en-
voyé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 li-
mite » (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 li-
mite 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 RLI-
MIT_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 conti-
nue de consommer du temps processeur, jusqu'à ce que la limite stricte
soit atteinte, auquel cas le processus est tué. D'autres implémenta-
tions 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 évi-
ter de tabler sur ce comportement. La limite propre à Linux RLIMIT_RT-
TIME se comporte de façon analogue lorsque la limite souple est at-
teinte.
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() uti-
lisent 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 fi-
chier : 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'af-
fecter à une limite de ressource une valeur trop grande pour être re-
pré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 setr-
limit() 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), uli-
mit(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 Chris-
tophe Blaess <https://www.blaess.fr/christophe/>, Stéphan Rafin <ste-
phan.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.cou-
lon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux
<thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centra-
liens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard <si-
mon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@de-
bian.org>, David Prévot <david@tilapin.org>, Cédric Boutillier <ce-
dric.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⟩.
Pages du manuel de Linux 6.03 5 février 2023 getrlimit(2)
Generated by dwww version 1.15 on Sat Jun 29 00:52:48 CEST 2024.