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.
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
Lignes liées à pam_limits.so
n'ont pas été commentés dans tous les fichiers pertinents dans /etc/pam.d/ et fs.file-max
a été correctement défini 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é.
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 /etc/ssh/sshd_config
file, 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_config
et a rebondi le service SSH, puis le fichier limits.conf a été respecté avec les connexions SSH.
Je soupçonne que 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.
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
Je sais de cette façon 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 Shell comme @etherfish l'a dit
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 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 ma faute de 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.
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 utilisateurs non root:
* soft nproc 1024
root soft nproc unlimited