GETRLIMIT
Section : Manuel du programmeur Linux (
2)
Mise à jour de la version anglaise : 20 septembre 2005
Index
Menu principal
NOM
getrlimit, setrlimit - Lire/définir les limites 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);
DESCRIPTION
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 que le processus
peut verrouiller en RAM.
Cette limite est arrondie vers le bas au plus proche multiple
de la taille de page système.
Cette limite affecte les appels
mlock(2)
et
mlockall(2)
et l'opération
MAP_LOCKED
de
mmap(2).
Depuis Linux 2.6.9, cela affecte également l'opération
SHM_LOCK
de
shmctl(2),
où est configuré un maximum sur le nombre total d'octets
dans les segments de mémoire partagée (voir
shmget(2))
qui peut être verrouillée par l'UID réel du processus appelant.
Les verrous
SHM_LOCK
de
shmctl(2)
sont comptabilisés de manière séparée des verrous mémoire
par processus effectués par
mlock(2), mlockall(2)
et l'opération
MAP_LOCKED
de
mmap(2) ;
un processus peut verrouiller autant d'octets jusqu'à sa limite
dans chacune de ces deux catégories.
Dans les noyaux Linux antérieurs à la version 2.6.9, cette limite contrôlait
la quantité de mémoire qu'un processus privilégié pouvait verrouiller.
Depuis Linux 2.6.9, il n'y a aucune limite sur la quantité de mémoire
qu'un processus privilégié peut verrouiller, et cette limite concerne
plutôt les processus non privilégiés.
- RLIMIT_MSGQUEUE (Depuis Linux 2.6.8)
-
Indique la limite du nombre d'octets qui peuvent être alloués
aux 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 que l'utilisateur créé compte
(jusqu'à ce qu'elle soit supprimée)
dans cette limite suivant la formule :
octets = attr.mq_maxmsg * sizeof(struct msg_msg *) +
attr.mq_maxmsg * attr.mq_msgsize
où
attr
est la structure
mq_attr
spécifiée comme le quatrième argument de
mq_open(3).
Le premier cumulateur dans la formule, qui inclut
sizeof(struct msg_msg *)
(4 octets sur Linux/i386), s'assure que l'utilisateur ne puisse pas créer
un nombre illimité de messages de taille nulle (de tels messages
consomment néanmoins chacun un peu de mémoire)
- RLIMIT_NICE (depuis Linux 2.6.12, mais voir la section BOGUES plus loin)
-
Indique un plafond que la valeur de priorité du processus
peut atteindre avec
setpriority(2)
ou
nice(2).
Le plafond actuel pour la valeur de priorité est calculé
de la manière suivante :
20 - rlim_cur.
(Cette bizarrerie apparaît car on ne peut pas donner des valeurs négatives
comme valeurs de limites de ressources car elles ont une signification
particulière.
Par exemple,
RLIM_INFINITY
vaut -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.
- 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 la section BOGUES)
-
Indique un plafond pour la priorité temps réel pouvant être appliqué
au processus par
sched_setscheduler(2)
et
sched_setparam(2).
- RLIMIT_SIGPENDING (Depuis Linux 2.6.8)
-
Indique la limite du nombre de signaux pouvant être mis
en file d'attente pour l'UID réel du processus appelant.
Les signaux standard et temps réel sont additionnés en vue de vérifier
cette limite.
Toutefois, la limite n'est appliquée que pour
sigqueue(2) ;
il est toujours possible d'utiliser
kill(2)
pour mettre en file d'attente une instance de tout signal
qui ne soit pas encore dans la file d'attence du 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)).
RLIMIT_OFILE
est le nom BSD pour
RLIMIT_NOFILE.
VALEUR RENVOYÉE
Ces appels système renvoient 0 s'ils réussissent, ou -1 s'il échouent,
auquel cas
errno
est renseignée en conséquence.
ERREURS
- EFAULT
-
rlim
pointe en dehors de l'espace d'adressage disponible.
- EINVAL
-
resource
n'est pas valide ;
ou, pour
setrlimit() :
rlim->rlim_cur
était 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
les limites au-dessus des maxima du noyau
(NR_OPEN).
CONFORMITÉ
SVr4, BSD 4.3, POSIX.1-2001.
RLIMIT_MEMLOCK
et
RLIMIT_NPROC
viennent de BSD et ne sont pas spécifiées dans POSIX.1-2001 ;
elles sont présentes sur les systèmes BSD et Linux
et mais sur peu d'autres implémentations.
RLIMIT_RSS
vient de BSD et n'est pas spécifiée dans POSIX.1-2001 ;
elle est néanmoins présente sur la plupart des implémentations.
RLIMIT_MSGQUEUE,
RLIMIT_NICE,
RLIMIT_RTPRIO
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).
BOGUES
Dans les anciens noyaux Linux, les signaux
SIGXCPU
et
SIGKILL,
envoyés lorsqu'un processus dépassait les limites
RLIMIT_CPU
souple et stricte, étaient envoyés une seconde (CPU) plus tard
qu'ils n'auraient dû l'être.
Ceci a été corrigé dans le noyau 2.6.8.
Dans les noyaux 2.6.x antérieurs au 2.6.17, une limite
RLIMIT_CPU
de 0 était faussement interprété comme « pas de limite » (comme
RLIM_INFINITY).
Depuis Linux 2.6.17, définir une limite de 0 a un effet mais est
actuellement interprété comme une limite de 1 seconde.
Un bogue du noyau fait que
RLIMIT_RTPRIO
ne fonctionne pas dans le noyau 2.6.12 ;
cela a été corrigé dans le noyau 2.6.13.
Dans le noyau 2.6.12, il y avait un écart de 1 entre l'intervalle
de priorité renvoyé par
getpriority(2)
et
RLIMIT_NICE.
Cela a pour effet que le plafond actuel de la valeur de priorité
était calculé de la façon suivante :
19 - rlim_cur.
Cela a été corrigé dans le noyau 2.6.13.
Les noyaux antérieurs au 2.4.22 ne détectaient pas l'erreur
EINVAL
pour
setrlimit()
lorsque
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)
TRADUCTION
Ce document est une traduction réalisée par Christophe Blaess
<http://www.blaess.fr/christophe/> le 11 octobre 1996
et révisée le 24 juin 2008.
L'équipe de traduction a fait le maximum pour réaliser une adaptation
française de qualité. La version anglaise la plus à jour de ce document est
toujours consultable via la commande : « LANG=C man 2 getrlimit ».
N'hésitez pas à signaler à l'auteur ou au traducteur, selon le cas, toute
erreur dans cette page de manuel.
Index
- NOM
-
- SYNOPSIS
-
- DESCRIPTION
-
- VALEUR RENVOYÉE
-
- ERREURS
-
- CONFORMITÉ
-
- NOTES
-
- BOGUES
-
- VOIR AUSSI
-
- TRADUCTION
-
Dernière mise à jour : 24 juin 2008