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);
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. Historiquement, cette limite était appelée RLIMIT_OFILE
sur les BSD.
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)).
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.
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).
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.
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.23 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> ».