nproc était le problème :
[[email protected] ~]# ps -eLf | grep pascal | wc -l
4068
[[email protected] ~]# cat /etc/security/limits.d/20-nproc.conf
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz #432903 for reasoning.
* soft nproc 4096
root soft nproc unlimited
[[email protected] ~]#
man limits.conf indique :
Also, please note that all limit settings are set per login. They are
not global, nor are they permanent; existing only for the duration of
the session. One exception is the maxlogin option, this one is system
wide. But there is a race, concurrent logins at the same time will not
always be detected as such but only counted as one.
Il me semble que nproc n'est appliqué que par connexion mais compte globalement. Ainsi, une connexion avec les threads nproc 8192 et 5000 n'aurait aucun problème, mais une connexion simultanée du même UID avec les threads nproc 4096 et 50 ne pourrait pas en créer plus car le nombre global (5050) est supérieur à son paramètre nproc.
[[email protected] ~]# ps -eLf | grep pascal | grep google/chrome | wc -l
3792
Si vous ne pouvez pas du tout accéder au compte, vous aurez du mal à déterminer quel est le problème. Mais vérifiez les journaux du système ou des applications, j'espère qu'un programme y aura laissé un indice (en particulier pour une tentative de connexion infructueuse).
Si vous pouvez exécuter des programmes pour expérimenter, vous pouvez savoir quelle limite a été atteinte en essayant d'augmenter chaque valeur limitée et en voyant quand cela fonctionne et quand la tentative échoue avec EAGAIN . Il est également possible de lister les ressources utilisées pour chaque valeur; Je ne peux pas penser à un utilitaire qui collecte les données pour toutes les limites, mais il pourrait bien y en avoir un.
En supposant que le problème est une limite du noyau, ceux-ci sont répertoriés dans le setrlimit page de manuel. Ceux qui s'appliquent par ID utilisateur sont :
RLIMIT_MEMLOCK— taille de la mémoire non échangeable. Ne devrait pas empêcher la connexion, très peu de programmes demandent de la mémoire non échangeable.RLIMIT_MSGQUEUE— taille des files d'attente de messages. Ne devrait pas empêcher la connexion, très peu de programmes utilisent des files d'attente de messages.RLIMIT_NPROC— nombre maximal de processus. Celui-ci absolument va empêcher les connexions s'il est atteint. Augmentation de la limite en/etc/security/limits.confn'affectera pas les sessions existantes, mais cela affectera les nouveaux processus, donc si l'administrateur système augmente la valeur là-bas, l'utilisateur pourra se connecter.RLIMIT_SIGPENDING— nombre maximal de signaux en attente. Ne devrait pas empêcher la connexion, très peu de programmes utilisentsigqueuepour mettre les signaux en file d'attente.
La limite des processus est donc la plus probable. Si vous avez accès à un shell en cours d'exécution, vous pouvez confirmer en essayant d'exécuter un programme ; l'erreur devrait être assez distincte :
$ ls
bash: fork: retry: No child processes
bash: fork: retry: No child processes
bash: fork: retry: No child processes
bash: fork: retry: No child processes
bash: fork: Resource temporarily unavailable
Vous pouvez imprimer cette limite avec ulimit -u . Si vous avez accès à un shell exécuté en tant qu'utilisateur problématique et que l'utilisateur n'a exécuté aucun programme setuid, vous pouvez répertorier les processus qui comptent dans cette limite avec set /proc/*/task/*/cwd/.; echo $# (répertorie les threads du noyau pour lesquels l'utilisateur peut lire le cwd lien, ce qui signifie que l'utilisateur a un contrôle total sur le processus).