¿Cómo puedo saber con qué límite de usuarios me estoy encontrando?

nproc fue el 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 estados:

   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.

Me parece que nproc solo se aplica por inicio de sesión, pero cuenta globalmente. Por lo tanto, un inicio de sesión con nproc 8192 y 5000 subprocesos no tendría problemas, pero un inicio de sesión simultáneo del mismo UID con nproc 4096 y 50 subprocesos no podría crear más porque el recuento global (5050) está por encima de su configuración de nproc.

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

Si no puede acceder a la cuenta en absoluto, tendrá dificultades para descubrir cuál es el problema. Pero verifique los registros del sistema o de la aplicación, es de esperar que algún programa haya dejado una pista allí (especialmente para un intento fallido de inicio de sesión).

Si puede ejecutar programas para experimentar, puede saber qué límite se ha alcanzado al intentar aumentar cada valor limitado y ver cuándo funciona y cuándo falla el intento con EAGAIN . También es posible enumerar los recursos utilizados para cada valor; No se me ocurre una utilidad que recopile los datos de todos los límites, pero es posible que haya una.

Suponiendo que el problema es un límite del núcleo, se enumeran en el setrlimit página de manual Los que aplican por ID de usuario son:

• RLIMIT_MEMLOCK — tamaño de la memoria no intercambiable. No debería impedir el inicio de sesión, muy pocos programas solicitan memoria no intercambiable.
• RLIMIT_MSGQUEUE — tamaño de las colas de mensajes. No debería impedir el inicio de sesión, muy pocos programas usan colas de mensajes.
• RLIMIT_NPROC — número máximo de procesos. Este absolutamente lo hará evitar inicios de sesión si se alcanza. Aumentando el límite en /etc/security/limits.conf no afectará las sesiones existentes, pero afectará los nuevos procesos, por lo que si el administrador del sistema aumenta el valor allí, el usuario podrá iniciar sesión.
• RLIMIT_SIGPENDING — número máximo de señales pendientes. No debería impedir el inicio de sesión, muy pocos programas usan sigqueue para poner en cola las señales.

Entonces, el límite en los procesos es el más probable. Si tiene acceso a un shell en ejecución, puede confirmarlo intentando ejecutar un programa; el error debería ser bastante distintivo:

$ 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

Puede imprimir este límite con ulimit -u . Si tiene acceso a un shell que se ejecuta como el usuario problemático y el usuario no ha ejecutado ningún programa setuid, puede enumerar los procesos que cuentan para este límite con set /proc/*/task/*/cwd/.; echo $# (enumera los subprocesos del núcleo para los que el usuario puede leer el cwd enlace, lo que significa que el usuario tiene control total sobre el proceso).