Administrer des serveurs Unix peut être un défi, surtout lorsque les systèmes que vous gérez sont fortement utilisés et que les problèmes de performance réduisent la disponibilité. Heureusement, vous pouvez mettre des limites sur certaines ressources pour aider à garantir que les processus les plus importants sur vos serveurs peuvent continuer à fonctionner et que les processus concurrents ne consomment pas beaucoup plus de ressources que ce qui est bon pour le système global. La commande ulimit peut tenir le désastre à distance, mais vous devez anticiper où les limites auront un sens et où elles causeront des problèmes.
Cela n’arrive peut-être pas si souvent, mais un seul utilisateur qui démarre trop de processus peut rendre un système inutilisable pour tous les autres. Une bombe à fourche — une attaque par déni de service dans laquelle un processus se réplique continuellement jusqu’à ce que les ressources disponibles soient épuisées — en est le pire cas. Cependant, même des utilisateurs sympathiques peuvent utiliser plus de ressources que ce qui est bon pour un système — souvent sans le vouloir. Dans le même temps, les processus légitimes peuvent parfois échouer lorsqu’ils sont exécutés dans des limites conçues pour des utilisateurs moyens. Dans ce cas, vous devez vous assurer que ces processus obtiennent des allocations renforcées de ressources système qui leur permettront de fonctionner correctement sans rendre les mêmes ressources disponibles pour tout le monde.
Pour voir les limites associées à votre login, utilisez la commande ulimit -a. Si vous utilisez un compte utilisateur ordinaire, vous verrez probablement quelque chose comme ceci :
$ ulimit -acore file size (blocks, -c) 0data seg size (kbytes, -d) unlimitedscheduling priority (-e) 0file size (blocks, -f) unlimitedpending signals (-i) 32767max locked memory (kbytes, -l) 32max memory size (kbytes, -m) unlimitedopen files (-n) 1024pipe size (512 bytes, -p) 8POSIX message queues (bytes, -q) 819200real-time priority (-r) 0stack size (kbytes, -s) 10240cpu time (seconds, -t) unlimitedmax user processes (-u) 50virtual memory (kbytes, -v) unlimitedfile locks (-x) unlimited
Une chose que vous pourriez remarquer dès le départ est que vous ne pouvez pas créer de core dumps — parce que votre taille maximale de fichier core est de 0. Oui, cela signifie rien, pas de données, pas de core dump. Si un processus que vous exécutez s’arrête, aucun fichier core ne sera déposé dans votre répertoire personnel. Tant que la taille du fichier core est fixée à zéro, les core dumps ne sont pas autorisés. Cela est logique pour la plupart des utilisateurs puisqu’ils ne feraient probablement rien de plus avec un core dump autre que de l’effacer, mais si vous avez besoin d’un core dump pour déboguer les problèmes que vous rencontrez avec une application, vous pourriez vouloir définir la taille de votre fichier core à un nombre illimité — et peut-être que vous pouvez.
$ ulimit -c ulimited$ ulimit -cunlimited
Si vous gérez un serveur et que vous voulez activer la possibilité de générer des core dumps pour tous vos utilisateurs — peut-être que ce sont des développeurs qui ont vraiment besoin de pouvoir analyser ces core dumps, vous devez passer de l’utilisateur à root et modifier votre /etc/security/limits.conf (Linux) ou faire des changements dans votre fichier /etc/system (Solaris).
Si, d’autre part, vous gérez un serveur et ne voulez pas qu’un de vos utilisateurs soit capable de générer des core dumps, peu importe combien ils aimeraient s’y enfoncer, vous pouvez définir une limite de 0 dans votre limits.conf.
Une autre limite qui est souvent appliquée est celle qui limite le nombre de processus qu’un individu peut exécuter. L’option ulimit utilisée pour cela est -u. Vous pouvez regarder votre limite comme nous l’avons fait ci-dessus avec la commande ulimit -a ou montrer seulement la limite « nproc » avec la commande ulimit -u.
$ ulimit -u50
Encore une fois, vos utilisateurs peuvent changer leurs limites avec une autre commande ulimit — ulimit -u 100 — à moins, bien sûr, qu’ils ne le puissent pas. Si vous les avez limités à 50 processus dans le fichier limits.conf ou le fichier système, ils obtiendront une erreur comme celle-ci lorsqu’ils essaieront d’augmenter leurs limites :
$ ulimit -u 100-bash: ulimit: max user processes: cannot modify limit: Operation not permitted
Les limites peuvent également être configurées par groupe afin que vous puissiez, par exemple, donner aux développeurs la possibilité d’exécuter plus de processus que les gestionnaires. Des lignes comme celles-ci dans votre fichier limits.conf feraient cela:
@managers hard nproc 50@developers hard nproc 200
Si vous voulez limiter le nombre de fichiers ouverts, vous utilisez simplement un paramètre différent.
@managers hard nofile 2048@developers hard nofile 8192sbob hard nofile 8192
Ici, nous avons donné à deux groupes et à un individu des augmentations de leurs limites de fichiers ouverts. Ceux-ci ont tous fixé des limites dures. Si vous définissez également des limites souples, les utilisateurs recevront des avertissements lorsqu’ils atteindront la limite inférieure.
@developers soft nofile 2048@developers hard nofile 8192
Pour voir une liste des options de ulimit, regardez la page de manuel (man ulimit). Vous remarquerez que ulimit est un intégré bash — au moins sous Linux — et que les options suivantes sont disponibles:
-a All current limits are reported-c The maximum size of core files created-d The maximum size of a process's data segment-e The maximum scheduling priority ("nice")-f The maximum size of files written by the shell and its children-i The maximum number of pending signals-l The maximum size that may be locked into memory-m The maximum resident set size (has no effect on Linux)-n The maximum number of open file descriptors (most systems do not allow this value to be set)-p The pipe size in 512-byte blocks (this may not be set)-q The maximum number of bytes in POSIX message queues-r The maximum real-time scheduling priority-s The maximum stack size-t The maximum amount of cpu time in seconds-u The maximum number of processes available to a single user-v The maximum amount of virtual memory available to the shell
Si votre fichier limits.conf le permet, vous pourriez voir des limites comme celles-ci mises en place pour des applications particulières qui ont vraiment besoin de la capacité supplémentaire. Dans cet exemple, l’utilisateur oracle a la possibilité d’exécuter jusqu’à 16 384 processus et d’ouvrir 65 536 fichiers. Ces lignes seraient configurées dans le .bash_profile de l’utilisateur oracle.
if ; then if ; then ulimit -p 16384 ulimit -n 65536 else ulimit -u 16384 -n 65536 fifi