Provided by:
manpages-fr-dev_3.32d0.2p4-1_all 
NOM
getrlimit, setrlimit, prlimit - Lire/ecrire 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 fonctionnalites pour la glibc (consultez
feature_test_macros(7)) :
prlimit() : _GNU_SOURCE
DESCRIPTION
Les appels systeme getrlimit() et setrlimit() lisent ou ecrivent les
limites des ressources systeme. Chaque ressource a une limite souple et
une limite stricte definies 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 privilegie peut seulement modifier
sa limite souple dans l'intervalle entre zero et la limite stricte, et
diminuer (de maniere irreversible) sa limite stricte. Un processus
privilegie (sous Linux : un processus ayant la capacite
CAP_SYS_RESOURCE) peut modifier ses deux limites a sa guise.
La valeur RLIM_INFINITY indique une limite infinie pour la ressource
(aussi bien pour getrlimit() que pour setrlimit()).
Le parametre resource doit etre l'un des elements suivants :
RLIMIT_AS
Taille maximum de la memoire virtuelle du processus en octets.
Cette limite affecte les appels a brk(2), mmap(2) et mremap(2),
qui echouent avec l'erreur ENOMEM en cas de depassement de cette
limite. De meme, l'extension de la pile automatique echouera (et
generera un SIGSEGV qui tuera le processus si aucune pile
alternative n'a ete definie par un appel a sigaltstack(2)).
Depuis que cette valeur est de type long, sur les machines ou le
type long est sur 32 bits, soit cette limite est au plus 2 GiB,
soit cette ressource est illimitee.
RLIMIT_CORE
Taille maximum du fichier core. Lorsqu'elle vaut zero, aucun
fichier d'image noyau (Ndt : core dump) n'est cree. Lorsqu'elle
ne vaut pas zero, les fichiers d'image noyau plus grands sont
tronques a cette taille.
RLIMIT_CPU
Limite de temps CPU en secondes. Si un processus atteint cette
limite souple, il recoit le signal SIGXCPU. L'action par defaut
en est la terminaison du processus. Mais le signal peut etre
capture et le gestionnaire peut renvoyer le controle au
programme principal. Si le processus continue a consommer du
temps CPU, il recevra SIGXCPU toutes les secondes jusqu'a
atteindre sa limite stricte, ou il recevra SIGKILL. (Ceci
correspond au comportement de Linux 2.2 a 2.6. Les
implementations varient sur le comportement vis-a-vis d'un
processus qui continue a consommer du temps CPU apres
depassement de sa limite souple. Les applications portables qui
doivent capturer ce signal devraient prevoir une terminaison
propre des la premiere reception de SIGXCPU.)
RLIMIT_DATA
Taille maximale du segment de donnees d'un processus (donnees
initialisees, non initialisees, et tas). Cette limite affecte
les appels brk(2) et sbrk(2), qui echouent avec l'erreur ENOMEM
si la limite souple est depassee.
RLIMIT_FSIZE
Taille maximale d'un fichier que le processus peut creer. Les
tentatives d'extension d'un fichier au-dela de cette limite
resultent en un signal SIGXFSZ. Par defaut ce signal termine le
processus, mais il peut etre capture, et dans ce cas l'appel
systeme concerne (par exemple write(2), truncate(2)) echoue avec
l'erreur EFBIG.
RLIMIT_LOCKS (Premiers Linux 2.4 seulement)
Une limite sur le nombre combine de verrous flock(2) et fcntl(2)
que le processus peut etablir.
RLIMIT_MEMLOCK
Le nombre maximal d'octets de memoire 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'operation MAP_LOCKED de mmap(2). Depuis Linux 2.6.9, elle
affecte aussi l'operation SHM_LOCK de shmctl(2), ou elle limite
le nombre total d'octets dans des segments de memoire partagee
(consultez shmget(2)) que l'UID reel du processus appelant peut
verrouiller. Les verrous de shmctl(2) SHM_LOCK sont comptes
separement des verrous de memoire par processus etablis par
mlock(2), mlockall(2) et mmap(2) MAP_LOCKED ; un processus peut
verrouiller des octets jusqu'a la limite dans chacune de ces
categories. Dans les noyaux anterieurs a 2.6.9, cette limite
controlait la quantite de memoire qu'un processus privilegie
pouvait verrouiller. Depuis Linux 2.6.9, un processus privilegie
peut verrouiller autant de memoire qu'il le souhaite, et cette
limite controle la quantite de memoire pouvant etre verrouillee
par un processus non privilegie.
RLIMIT_MSGQUEUE (depuis Linux 2.6.8)
Indique la limite du nombre d'octets pouvant etre alloues pour
les files de messages POSIX pour l'UID reel du processus
appelant. Cette limite est appliquee pour mq_open(3). Le nombre
d'octets pour chaque file de messages creee par l'utilisateur
(jusqu'a sa destruction) est determine par la formule suivante :
octets = attr.mq_maxmsg * sizeof(struct msg_msg *) +
attr.mq_maxmsg * attr.mq_msgsize
ou attr est la structure mq_attr passee comme quatrieme argument
a 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 creer un nombre illimite de messages vides (ces messages
consomment tout de meme de la memoire systeme).
RLIMIT_NICE (depuis Linux 2.6.12, consultez la section BOGUES ci-
dessous)
Indique un plafond pour la valeur de politesse du processus
pouvant etre definie par setpriority(2) ou nice(2). Le plafond
reel pour la valeur de politesse est calcule par la formule
20 - rlim_cur. (Cette bizarrerie apparait car des nombres
negatifs ne peuvent pas etre utilises comme limites de
ressources, en raison de leur signification souvent
particuliere. Par exemple, RLIM_INFINITY est souvent la meme
chose que -1.)
RLIMIT_NOFILE
Le nombre maximal de descripteurs de fichier qu'un processus
peut ouvrir simultanement. Les tentatives d'ouverture (open(2),
pipe(2), dup(2), etc) depassant cette limite renverront l'erreur
EMFILE. Historiquement, cette limite etait appelee RLIMIT_OFILE
sur les BSD.
RLIMIT_NPROC
Le nombre maximal de processus (ou plus precisement, sous Linux,
de threads) qui peuvent etre crees pour l'UID reel du processus
appelant. Une fois cette limite atteinte, fork(2) echoue avec
l'erreur EAGAIN.
RLIMIT_RSS
Indique la limite (en pages) pour la taille de l'ensemble
resident du processus (le nombre de pages de memoire virtuelle
en RAM). Cette limite n'a d'effet que sous Linux 2.4.x ou
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 priorite temps-reel pouvant etre
appliquee au processus par sched_setscheduler(2) et
sched_setparam(2).
RLIMIT_RTTIME (depuis Linux 2.6.25)
Indique une limite de la quantite de temps (en microsecondes)
CPU qu'un processus ordonnance par une politique
d'ordonnancement temps reel peut consommer sans bloquer lors de
l'execution d'un appel systeme. A cause de cette limite le
decompte du temps CPU qu'il a consomme est remis a zero a chaque
fois qu'un processus execute un appel systeme bloquant. Le
decompte du temps CPU n'est pas remis a zero si le processus
continue d'essayer d'utiliser le CPU mais est preempte, ou si sa
tranche de temps expire, ou s'il appelle sched_yield(2).
Quand la limite douce est atteinte, un signal SIGXCPU est envoye
au processus. Si le processus attrape ou ignore ce signal et
continue a consommer du temps CPU, alors un signal SIGXCPU sera
genere une fois par seconde jusqu'a 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'empecher un processus temps
reel fou de bloquer le systeme.
RLIMIT_SIGPENDING (Depuis Linux 2.6.8)
Specifie la limite du nombre de signaux pouvant etre mis en
attente pour l'UID reel du processus appelant. La verification
de cette limite prend en compte a la fois les signaux classiques
et les signaux temps-reel. Cependant, cette limite n'est
appliquee 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 deja 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 declenche. Pour
gerer ce signal, le processus doit utiliser une pile specifique
pour signaux (sigaltstack(2)).
Depuis Linux 2.6.23, cette limite determine egalement la
quantite d'espace utilise pour les parametres et les variables
d'environnement du processus ; consultez execve(2) pour plus de
details.
prlimit()
L'appel systeme prlimit() specifique a Linux combine et etend les
fonctionnalites de setrlimit() et getrlimit(). Il peut etre utilise
pour affecter ou recuperer les limites de ressources de tout processus.
Le parametre resource a le meme sens que dans setrlimit() et
getrlimit().
Si le parametre new_limit ne vaut pas NULL, alors la structure rlimit
vers laquelle il pointe est utilisee pour affecter de nouvelles valeurs
aux limites souples et strictes pour resource. Si le parametres
old_limit ne vaut pas NULL, alors un appel a prlimit() qui reussit
place les limites anterieures souples et strictes pour resource dans la
structure rlimit pointee par old_limit.
L'argument pid specifie 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-meme, soit l'appelant a la capacite CAP_SYS_RESOURCE, soit les
identifiants d'utilisateur reel et effectif et le set-UID sauve du
processus cible correspond a l'identifiant d'utilisateur reel de
l'appelant et les identifiants de groupe reel et effectif et le set-GID
sauve du processus cible correspond a l'identifiant de groupe reel du
processus.
VALEUR RENVOY'EE
Ces appels systeme renvoient 0 en cas de succes, ou -1 en cas d'echec,
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 specifiee 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 privilegie a essaye d'augmenter la limite
stricte ; la capacite CAP_SYS_RESOURCE est necessaire pour
pouvoir faire cela. Ou le processus a essaye 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 specifie par pid.
ESRCH Impossible de trouver un processus dont l'identifiant est
indique par pid.
VERSIONS
L'appel systeme prlimit() est disponible depuis Linux 2.6.36 ; la prise
en charge dans la glibc est disponible depuis la version 2.13.
CONFORMIT'E
getrlimit(), setrlimit() : SVr4, BSD 4.3, POSIX.1-2001.
prlimit() : specifique a Linux.
RLIMIT_MEMLOCK et RLIMIT_NPROC proviennent de BSD et ne sont pas
definis dans POSIX.1-2001 ; ils sont presents dans les BSD et Linux,
mais dans peu d'autres implementations. RLIMIT_RSS vient de BSD et
n'est pas defini dans POSIX.1-2001 ; cependant, il est present sur la
plupart des implementations. RLIMIT_MSGQUEUE, RLIMIT_NICE,
RLIMIT_RTPRIO, RLIMIT_RTTIME et RLIMIT_SIGPENDING sont specifiques a
Linux.
NOTES
Un processus fils cree avec fork(2) herite des limites de ressource de
son pere. Les limites de ressource sont preservees a travers un
execve(2).
On peut fixer les limites de ressources de l'interpreteur de commandes
en utilisant la commande interne ulimit (limit dans csh(1)). Les
limites de ressources de l'interpreteur de commandes sont heritees par
les processus qu'il cree pour executer les commandes.
Des systemes anciens fournissent une fonction vlimit() qui remplit le
meme role que setrlimit(). Pour des raisons de compatibilite
ascendante, la glibc fournit aussi une fonction vlimit(), mais toutes
les nouvelles applications devraient utiliser setrlimit().
EXEMPLE
Le programme ci-dessous demontre l'utilisation de prlimit().
#define _GNU_SOURCE
#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/resource.h>
int
main(int argc, char *argv[])
{
struct rlimit64 old, new;
struct rlimit64 *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;
}
/* Definir la limite de temps CPU du processus cible ;
recuperer et afficher la limite de temps CPU anterieure */
if (prlimit(pid, RLIMIT_CPU, newp, &old) == -1)
errExit("prlimit-1");
printf("Limites precedentes : souple=%lld; stricte=%lld\n",
(long long) old.rlim_cur, (long long) old.rlim_max);
/* Recuperer 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);
}
BOGUES
Dans les noyaux Linux plus anciens, les signaux SIGXCPU et SIGKILL
envoyes lorsqu'un processus depassait les limites souple et stricte
pour RLIMIT_CPU etaient envoyes une seconde (CPU) plus tard qu'ils
n'auraient du l'etre. Cela a ete corrige dans le noyau 2.6.8.
Dans les noyaux de la serie 2.6 anterieurs a 2.6.17, une limite
RLIMIT_CPU a 0 est interpretee par erreur comme << pas de limite >>
(comme RLIM_INFINITY). Depuis Linux 2.6.17, fixer la limite a 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 probleme a ete corrige dans le noyau 2.6.13.
Dans le noyau 2.6.12, il y avait une difference de 1 entre les valeurs
de priorite renvoyees par getpriority(2) et RLIMIT_NICE. Du coup, la
limite reelle pour la valeur de politesse etait calculee comme
19 - rlim_cur. Ceci est corrige depuis le noyau 2.6.13.
Les noyaux anterieurs a 2.4.22 ne detectaient pas l'erreur EINVAL pour
setrlimit() quand rlim->rlim_cur etait 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.32 du projet man-pages
Linux. Une description du projet et des instructions pour signaler des
anomalies peuvent etre trouvees a l'adresse
<URL:http://www.kernel.org/doc/man-pages/>.
TRADUCTION
Depuis 2010, cette traduction est maintenue a l'aide de l'outil po4a
<URL:http://po4a.alioth.debian.org/> par l'equipe de traduction
francophone au sein du projet perkamon
<URL:http://perkamon.alioth.debian.org/>.
Christophe Blaess <URL:http://www.blaess.fr/christophe/> (1996-2003),
Alain Portal <URL:http://manpagesfr.free.fr/> (2003-2006). Julien
Cristau et l'equipe francophone de traduction de Debian (2006-2009).
Veuillez signaler toute erreur de traduction en ecrivant a
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
paquet manpages-fr.
Vous pouvez toujours avoir acces a la version anglaise de ce document
en utilisant la commande << man -L C <section> <page_de_man> >>.
Linux 3 decembre 2010 GETRLIMIT(2)