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

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