getrlimit, setrlimit − Lire/écrire les limites des ressources.

#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. The maximum size of the process’s virtual memory (address space) in bytes. 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’est disponible avec 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() et sbrk(), 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(), truncate()) échoue avec l’erreur EFBIG.

RLIMIT_LOCKS (Dans les premiers Linux 2.4 seulement)

Une limite sur le nombre combiné de verrous flock() et fcntl() 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 par défaut au plus proche multiple de la taille de page système. Cette limite affecte les appels lock() et mlockall() 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 verrouillages SHM_LOCK de shmctl(2) sont comptabilisés de manière séparée des verrouillages 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 précédant 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)

Spécifie 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 :

    bytes = 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().

Le premier cumulateur dans la formule, qui inclut sizeof(struct msg_msg *) (4 octets sur Linux/x86), 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)

Spécifier 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 fichiers qu’un processus peut ouvrir simultanément. Les tentatives d’ouverture (open(), pipe(), dup(), etc) dépassant cette limite renverront l’erreur EMFILE.

RLIMIT_NPROC

Le nombre maximum de processus qui peuvent être créés pour l’UID réel du processus appelant. Une fois cette limite atteinte, fork() échoue avec l’erreur EAGAIN.

RLIMIT_RSS

Indiquer la limite (en pages) pour la taille de l’ensemble résident du processus (le nombre de page de mémoire virtuelle en RAM). Cette limite n’a d’effet que dans Linux 2.4.x, x < 30, et n’affecte que les appels madvise() indiquant MADV_WILLNEED.

RLIMIT_RTPRIO (depuis Linux 2.6.12, mais voir la section BOGUES)

Spécifier un plafond à la priorité temps réel qui peut être configurée pour le processus en utilisant sched_setscheduler(2) et sched_setparam(2).

RLIMIT_SIGPENDING (Depuis Linux 2.6.8)

Spécifier la limite du nombre de signaux qui peuvent être mis en file d’attente pour l’UID réel d’un processus appelant. Les signaux standard et temps réel sont additionnés en vue de vérifier cette limite. Toutefois, la limite est seulement appliquée pour sigqueue(2) ; il est toujours possible d’utiliser kill(2) pour mettre en file d’attente une instance de chacun des signaux qui ne sont 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.

Ces fonctions renvoient 0 si elles réussissent, ou −1 si elles échouent, auquel cas errno contient le code d’erreur.

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 logicielle ou matérielle au delà de l’actuelle limite matérielle ; la capacité CAP_SYS_RESOURCE est nécessaire pour pouvoir faire cela. Ou alors le super-utilisateur essaye d’augmenter les limites au-dessus des maxima du noyau (NR_OPEN).

Dans les anciens noyaux Linux, les signaux SIGXCPU et SIGKILL, envoyés lorsqu’un processus rencontrait les limites RLIMIT_CPU logicielle et matérielle, é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 précédant le 2.6.17, une limite RLIMIT_CPU de 0 était faussement interprété comme « pas de limite » (comme RLIM_INFINITY). Depuis le noyau 2.6.17, fixer une limite de 0 n’a aucun 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 diagnostiquaient pas l’erreur EINVAL pour setrlimit() lorsque rlim->rlim_cur était plus grand que rlim->rlim_max.

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).

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.

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)

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 14 août 2006.

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.