ulimit -n ne change pas - les valeurs limites.conf n'ont aucun effet

13

J'essaie d'augmenter le maximum de descripteurs de fichiers ouverts pour tous les utilisateurs sur une machine Ubuntu.

Cette question fait en quelque sorte suite à cette question.

descripteur de fichier ouvert Le paramètre limits.conf n'est pas lu par ulimit même lorsque pam_limits.so est requis

sauf que j'ai ajouté les entrées "root" requises dans limits.conf

Voici les entrées

*               soft    nofile           100000
*               hard    nofile           100000
root            soft    nofile           100000
root            hard    nofile           100000

Les lignes liées à pam_limits.son'ont pas été commentées dans tous les fichiers pertinents dans /etc/pam.d/ et fs.file-maxont été définies correctement dans /etc/sysctl.conf

Cependant, je vois toujours

abc@machine-2:/etc/pam.d$ ulimit -n
1024

après le redémarrage.

Quel pourrait être le problème?

Mon shell par défaut est / bin / sh et je ne peux pas utiliser chsh pour changer mon shell par défaut car mon utilisateur sur la machine est authentifié via un schéma d'authentification distribué.

— Nerrve
source

strace -o loglimit su - abc et après cela egrep "(limit | open)" loglimit, peut-être que la configuration de votre pam est incorrecte

— c4f4t0r

@ c4f4t0r, l'option - à su ne provoque une nouvelle connexion que lorsque c'est le dernier argument. Je ne le sais que parce que je lisais juste cette page de manuel. En outre, comme détail, un utilisateur régulier ne peut pas étirer un binaire racine suid.

— etherfish

en tant que root, vous devez utiliser la commande strace -o loglimit su - abc

— c4f4t0r

désolé pour le spam mais j'ai ce genre de problème unix.stackexchange.com/questions/200310/…

— vladeli

5

J'ai eu un problème similaire, mais avec les connexions SSH uniquement. Les connexions locales (via la console) respectaient les /etc/security/limits.conf.

Il s'est avéré que lorsque vous définissez:

UsePrivilegeSeparation yes

dans le /etc/ssh/sshd_configfichier, puis sshd envoie un enfant non privilégié pour configurer l'env du compte. Étant donné que cet enfant n'est pas privilégié, la définition des limites supérieures par pam_limits.so n'a eu aucun effet.

Dès que je mets

UsePrivilegeSeparation no

dans /etc/ssh/sshd_configet renvoyé le service SSH, puis le fichier limits.conf a été respecté avec les connexions SSH.

— user418149
source

2

Dans mon cas, j'ai changé sshd-config en UsePAM yes. (+1 pour m'avoir dirigé vers sshd-config)

— Randall Whitman

4

Je soupçonne que l'ulimit est appliqué par un profil / etc / ou un ~ / .bashrc. Le fait que votre système ait un pam compliqué, je confirmerais que quelque chose ne va pas mal.

Je confirmerais également qu'il n'y a pas de fichier errant dans /etc/security/limits.d/ en cours d'analyse comme mentionné dans pam_limits (8).

Je voudrais ajouter le paramètre de débogage à la ligne pam_limits.conf requise pour la session, puis regarder /var/log/auth.log pendant que vous vous connectez.

Si votre limite logicielle est 1024, quelle est votre limite matérielle?

su devrait vous obtenir une nouvelle connexion avec su en utilisant l'argument -l.

su -l -s / bin / bash

Bonne chance.

— etherfish
source

ma limite est de 4096, c'estulimit -Hn

— Nerrve

4

Sur le serveur Redhat connecté en tant que root

/etc/security/limits.conf

user01  -       nofile  2048

commande strace enregistrée en tant que root

strace -o loglimit su - user01

avec un autre shell open loglimit

grep "limit" loglimit
open("/lib64/security/pam_limits.so", O_RDONLY) = 6
 ..........
 ..........
 open("/etc/security/limits.conf", O_RDONLY) = 3
 read(3, "# /etc/security/limits.conf\n#\n#E"..., 4096) = 1823
 open("/etc/security/limits.d", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 3
 setrlimit(RLIMIT_NOFILE, {rlim_cur=2*1024, rlim_max=2*1024}) = 0

De cette façon, je sais que pam_limits a été chargé et limits.conf a été lu, si votre pam_limits a été chargé mais que vous voyez toujours d'autres valeurs en utilisant ulimit -n, vérifiez votre profil de shell comme @etherfish l'a dit

— c4f4t0r
source

3

J'étais avec un problème comme celui-ci, voici ce que j'ai fait.

La commande strace affichera toutes les interactions que le processus fait avec les bibliothèques externes, donc avec elle, nous pouvons voir si notre configuration est chargée ou non.

Donc, je le fais, comme suggéré ci-dessus:

root:/etc/pam.d$ strace -o ~/loglimit su - glaudiston
glaudiston:~$ exit
logout
root:/etc/pam.d$ cat ~/loglimit | grep limits.conf

Dans mon problème, le journal de strace (strace -o log su - nom d'utilisateur) n'a pas d'instance de texte de limites, donc le fichier limits.conf n'a PAS été chargé.

Je m'assure d'abord que pam_limits.so recherche /etc/security/limits.conf

root:/etc/pam.d$ strings /lib/security/pam_limits.so | grep limits.conf
/etc/security/limits.conf

Donc, je m'assure que le module pam_limits.so est chargé en opération d'authentification dans des fichiers situés dans /etc/pam.d ... par exemple, dans /etc/pam.d/su, j'ai ajouté:

session   required    pam_limits.so

Maintenant, je peux faire un "su" à mon utilisateur et les limites seront chargées. Vous pouvez refaire l'étape strace pour vous en assurer.

Mon linux est un LFS, donc c'est de ma faute l'absence de pam_limits.so dans les fichiers /etc/pam.d. Dans d'autres distributions, je ne pense pas que ce soit exactement ce problème.

Mais j'espère que cela vous aidera.

— tonne
source

1

Dans mon cas (Centos 6.10), Strace a montré qu'après que la limite a été définie à partir de /etc/security/limits.conf plus tard dans le processus de connexion, elle a été réinitialisée à partir de /etc/security/limits.d/90-nproc.conf pour tous les non - utilisateurs root:

*          soft    nproc     1024
root       soft    nproc     unlimited

— brouiller
source