Come posso sapere in quale limite di utenti mi sto imbattendo?

nproc era il problema:

[[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 dichiara:

   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.

Mi sembra che nproc sia applicato solo per accesso ma conta a livello globale. Quindi un accesso con nproc 8192 e 5000 thread non avrebbe problemi, ma un accesso simultaneo dello stesso UID con nproc 4096 e 50 thread non sarebbe in grado di crearne altri perché il conteggio globale (5050) è superiore alla sua impostazione nproc.

[[email protected] ~]# ps -eLf | grep pascal | grep google/chrome | wc -l
3792

Se non riesci ad accedere all'account, avrai difficoltà a scoprire qual è il problema. Ma controlla i log di sistema o dell'applicazione, si spera che qualche programma abbia lasciato un indizio lì (soprattutto per un tentativo di accesso fallito).

Se puoi eseguire programmi per sperimentare, puoi stabilire quale limite è stato raggiunto tentando di aumentare ciascun valore limitato e vedere quando funziona e quando il tentativo fallisce con EAGAIN . E' anche possibile elencare le risorse utilizzate per ogni valore; Non riesco a pensare a un'utilità che raccolga i dati per tutti i limiti, ma potrebbe essercene uno.

Supponendo che il problema sia un limite del kernel, questi sono elencati in setrlimit pagina man. Quelli che si applicano per ID utente sono:

• RLIMIT_MEMLOCK — dimensione della memoria non scambiabile. Non dovrebbe impedire l'accesso, pochissimi programmi richiedono memoria non scambiabile.
• RLIMIT_MSGQUEUE — dimensione delle code di messaggi. Non dovrebbe impedire l'accesso, pochissimi programmi utilizzano le code dei messaggi.
• RLIMIT_NPROC — numero massimo di processi. Questo lo farà assolutamente impedire gli accessi se viene raggiunto. Aumentando il limite in /etc/security/limits.conf non influenzerà le sessioni esistenti, ma influenzerà i nuovi processi, quindi se l'amministratore di sistema aumenta il valore lì, l'utente sarà in grado di accedere.
• RLIMIT_SIGPENDING — numero massimo di segnalazioni pendenti. Non dovrebbe impedire l'accesso, pochissimi programmi usano sigqueue per accodare i segnali.

Quindi il limite sui processi è quello più probabile. Se hai accesso a una shell in esecuzione, puoi confermare provando a eseguire un programma; l'errore dovrebbe essere piuttosto caratteristico:

$ 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

Puoi stampare questo limite con ulimit -u . Se hai accesso a una shell in esecuzione come utente problematico e l'utente non ha eseguito alcun programma setuid, puoi elencare i processi che contano rispetto a questo limite con set /proc/*/task/*/cwd/.; echo $# (elenca i thread del kernel per i quali l'utente può leggere il cwd link, il che significa che l'utente ha il pieno controllo del processo).