getrlimit(2) System Calls Manual getrlimit(2) NOM getrlimit, setrlimit, prlimit - Lire et ecrire les limites et utilisations des ressources BIBLIOTHEQUE Bibliotheque C standard (libc, -lc) SYNOPSIS #include 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 fonctionnalites pour la glibc (consulter 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 : 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 dans l'espace de noms initial de l'utilisateur) 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 maximale de la memoire virtuelle du processus (espace d'adressage). Cette limite est exprimee en octets et est arrondie a la taille inferieure de la page systeme. 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 automatique de la pile echouera (et generera un SIGSEGV qui tuera le processus si aucune pile alternative n'a ete definie par un appel a sigaltstack(2)). Comme 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 maximale d'un fichier core (consulter core(5)) qu'un processus peut generer. 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 consommable par le processus. Lorsqu'un processus atteint cette limite souple, il recoit le signal SIGXCPU. L'action par defaut pour ce signal est la terminaison du processus. Mais le signal peut etre capture et le gestionnaire peut rendre le controle au programme principal. Si le processus continue a consommer du temps CPU, il recevra SIGXCPU toutes les secondes jusqu'a atteindre la limite stricte, ou il recevra SIGKILL. (Ce dernier point decrit le comportement de Linux. Les implementations varient sur la facon de traiter le 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 est indiquee en octets et arrondie a la taille inferieure de la page systeme. Cette limite affecte les appels brk(2), sbrk(2) et (depuis Linux 4.7) mmap(2)) qui echouent avec l'erreur ENOMEM si la limite souple est depassee. RLIMIT_FSIZE Taille maximale, en octets, d'un fichier que le processus peut creer. Les tentatives d'extension d'un fichier au-dela de cette limite aboutissent a 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 (de Linux 2.4.0 a Linux 2.4.24) Limite pour le nombre combine de verrous flock(2) et fcntl(2) que le processus peut etablir. RLIMIT_MEMLOCK Le nombre maximal d'octets de memoire 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 SHM_LOCK de shmctl(2) sont comptes separement des verrous de memoire par processus etablis par MAP_LOCKED de mlock(2), mlockall(2) et mmap(2) ; un processus peut verrouiller des octets jusqu'a cette limite dans ces deux categories. Avant Linux 2.6.9, cette limite controlait la quantite de memoire qui pouvait etre verrouillee par un processus privilegie. Depuis Linux 2.6.9, il n'existe plus de limite de quantite de memoire verrouillable par un processus privilegie, cette limite gere donc plutot la quantite de memoire qu'un processus non privilegie peut verrouiller. 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). Chaque file de message creee par l'utilisateur se calcule (jusqu'a sa destruction) par rapport a 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 depassement */ attr.mq_maxmsg * attr.mq_msgsize; /* Pour les donnees du message */ Linux 3.4 et anterieurs : bytes = attr.mq_maxmsg * sizeof(struct msg_msg *) + /* Pour le depassement */ attr.mq_maxmsg * attr.mq_msgsize; /* Pour les donnees du message */ ou attr est la structure mq_attr passee comme quatrieme argument a mq_open(3), et msg_msg et posix_msg_tree_node sont les structures internes du noyau. Le terme de << depassement >> de la formule represente les octets de depassement necessaires a l'implementation. Ce depassement assure 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. La plage utile pour cette limite est ainsi de 1 (pour une valeur de politesse de 19) a 40 (pour une valeur de politesse de -20). Cette bizarrerie est necessaire car des nombres negatifs ne peuvent pas etre utilises comme limite de ressource, en raison de leur signification souvent particuliere. Par exemple, RLIM_INFINITY est souvent la meme chose que -1. Pour plus de details sur la valeur de politesse, consultez sched(7). RLIMIT_NOFILE Valeur superieure de 1 au nombre maximal de descripteurs de fichier que peut ouvrir ce processus. 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). Depuis Linux 4.5, cette limite definit egalement le nombre maximal de descripteurs de fichier qu'un processus non privilegie (sans la capacite CAP_SYS_RESOURCE) peut detenir << en vol >> sur les autres processus, en les passant a travers des sockets du domaine UNIX. Cette limite s'applique a l'appel systeme sendmsg(2). Pour plus de details, voir unix(7). RLIMIT_NPROC Limite du nombre de processus etendus (ou, plus precisement, sur Linux, de threads) pour l'identifiant de l'utilisateur reel du processus appelant. Tant que le nombre en cours de processus appartenant a l'identifiant de l'utilisateur reel du processus est superieur ou egal a cette limite, fork(2) echoue avec l'erreur EAGAIN. La limite RLIMIT_NPROC n'est pas geree pour les processus qui ont la capacite CAP_SYS_ADMIN ou CAP_SYS_RESOURCE, ou bien qui fonctionnent avec l'identifiant reel de l'utilisateur 0.. RLIMIT_RSS Indique la limite (en octets) 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). Pour plus de details sur les regles d'ordonnancement en temps reel, voir sched(7) 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 provoquer un appel systeme bloquant. Pour les besoins 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 stricte soit atteinte, ce qui provoque l'envoi d'un signal SIGKILL au processus. L'objectif de cette limite est d'empecher un processus temps reel fou de bloquer le systeme. Pour plus de details sur les regles d'ordonnancement en temps reel, voir sched(7) RLIMIT_SIGPENDING (depuis Linux 2.6.8) Specifie la limite du nombre de signaux pouvant etre mis en attente pour l'identifiant utilisateur 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(3) ; 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, l'appelant doit avoir la capacite CAP_SYS_RESOURCE dans l'espace de noms utilisateur du processus dont les limites de ressources vont etre modifiees ou bien les identifiants d'utilisateur reel, effectif et le set-UID sauve du processus cible doivent correspondre 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 doivent correspondre a l'identifiant de groupe reel de l'appelant. VALEUR RENVOYEE Ces appels systeme renvoient 0 en cas de succes ou -1 en cas d'echec, auquel cas errno est positionne pour indiquer l'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 autorisee ; 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 faire cela. EPERM L'appelant a essaye d'augmenter la limite stricte RLIMIT_NOFILE au-dela de celle maximale definie 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 indique par pid. ESRCH Impossible de trouver un processus dont l'identifiant est indique par pid. ATTRIBUTS Pour une explication des termes utilises dans cette section, consulter attributes(7). +---------------------------------+--------------------------+---------+ |Interface | Attribut | Valeur | +---------------------------------+--------------------------+---------+ |getrlimit(), setrlimit(), | Securite des threads | MT-Safe | |prlimit() | | | +---------------------------------+--------------------------+---------+ STANDARDS getrlimit() setrlimit() POSIX.1-2008. prlimit() Linux. RLIMIT_MEMLOCK et RLIMIT_NPROC proviennent de BSD et ne sont pas definis dans POSIX.1 ; 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 ; cependant, il est present sur la plupart des implementations. RLIMIT_MSGQUEUE, RLIMIT_NICE, RLIMIT_RTPRIO, RLIMIT_RTTIME et RLIMIT_SIGPENDING sont specifiques a Linux. HISTORIQUE getrlimit() setrlimit() POSIX.1-2001, SVr4, 4.3BSD. prlimit() Linux 2.6.36, glibc 2.13. NOTES Un processus enfant cree avec fork(2) herite des limites de ressource de son parent. Les limites de ressource sont preservees a travers un execve(2). Les limites de ressource sont des attributs par processus partages 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 empechera le processus d'augmenter ulterieurement sa consommation de cette ressource). On peut definir les limites de ressource de l'interpreteur de commandes en utilisant la commande interne ulimit (limit dans csh(1)). Les limites de ressource de l'interpreteur de commandes sont heritees par les processus qu'il cree pour executer les commandes. A partir de Linux 2.6.24, les limites de ressource de n'importe quel processus peuvent etre examinees en consultant /proc/pid/limits ; consultez proc(5). Les 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(). Differences entre la bibliotheque C et l'ABI du noyau A partir de la glibc 2.13, les fonctions d'enveloppe getrlimit() et setrlimit() de la glibc n'appellent plus les appels systemes correspondant, mais utilisent prlimit(), pour les raisons indiquees dans BUGS. Le nom de la fonction enveloppe dans la glibc est prlimit() ; l'appel systeme sous-jacent est prlimit64(). BOGUES Dans les noyaux Linux plus anciens, les signaux SIGXCPU et SIGKILL envoyes lorsqu'un processus depassait les limites souples et strictes pour RLIMIT_CPU etaient envoyes une seconde (CPU) plus tard qu'ils n'auraient du l'etre. Cela a ete corrige dans Linux 2.6.8. Dans les noyaux Linux de la serie 2.6 anterieurs a Linux 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, definir 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 Linux 2.6.12 ; le probleme a ete corrige dans Linux 2.6.13. Dans Linux 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. Cela est corrige depuis Linux 2.6.13. A partir de Linux 2.6.12, si un processus atteint sa limite souple RLIMIT_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 repete si le processus continue de consommer du temps processeur, jusqu'a ce que la limite stricte soit atteinte, auquel cas le processus est tue. D'autres implementations ne modifient pas la limite souple RLIMIT_CPU de cette facon, et le comportement de Linux n'est alors probablement pas conforme aux standards ; pour cette raison, les applications portables doivent eviter de tabler sur ce comportement. La limite propre a Linux RLIMIT_RTTIME se comporte de facon analogue lorsque la limite souple est atteinte. Les noyaux anterieurs a Linux 2.4.22 ne detectaient pas l'erreur EINVAL pour setrlimit() quand rlim->rlim_cur etait plus grand que rlim->rlim_max. Pour des raisons de compatibilite, Linux ne renvoie pas d'erreur quand une tentative de positionnement de RLIMIT_CPU a echoue. Representation des limites de ressources de grande taille sur les plate-formes 32 bits Les fonctions d'enrobage de la glibc getrlimit() et setrlimit() utilisent un type 64 bits rlim_t, et ce meme sur les plateformes 32 bits. Cependant, le type rlim_t utilise dans les appels systemes 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 systemes 32 bits au moyen du type unsigned long. Un type 32 bits n'est pourtant pas assez grand. Dans le cas present, la limite la plus pertinente est RLIMIT_FSIZE, qui indique la taille maximum que peut atteindre un fichier : pour etre utilisable, cette limite doit etre representee par un type de la meme taille que celui utilise pour representer les positions de curseur dans le fichier -- c'est a dire, de la taille d'un off_t 64 bits (en considerant que le programme a ete compile avec l'option _FILE_OFFSET_BITS=64). Pour contourner cette limitation du noyau, si un programme tente d'affecter a une limite de ressource une valeur trop grande pour etre representee 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 systeme getrlimit() et setrlimit() en implementant les fonctions setrlimit() et getrlimit() qui font appel a prlimit(). EXEMPLES Le programme ci-dessous demontre l'utilisation de prlimit(). #define _GNU_SOURCE #define _FILE_OFFSET_BITS 64 #include #include #include #include #include #include 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 [ " "]\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) err(EXIT_FAILURE, "prlimit-1"); printf("Limites precedentes : souple=%jd; stricte=%jd\n", (intmax_t) old.rlim_cur, (intmax_t) old.rlim_max); /* Recuperer 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), ulimit(3), core(5), capabilities(7), cgroups(7), credentials(7), signal(7) TRADUCTION La traduction francaise de cette page de manuel a ete creee par Christophe Blaess , Stephan Rafin , Thierry Vignaud , Francois Micaux, Alain Portal , Jean-Philippe Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas Francois , Florentin Duneau , Simon Paillard , Denis Barbier , David Prevot , Cedric Boutillier , Frederic Hantrais et Jean-Philippe MENGUAL Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . Pages du manuel de Linux 6.06 31 octobre 2023 getrlimit(2)