La creación de subprocesos falla con "Recurso no disponible temporalmente" con el kernel 4.3

Estoy ejecutando un servidor Docker en Arch Linux (kernel 4.3.3-2) con varios contenedores. Desde mi último reinicio, tanto el servidor Docker como los programas aleatorios dentro de los contenedores se bloquean con un mensaje sobre no poder crear un hilo o (con menos frecuencia) para bifurcar. El mensaje de error específico es diferente según el programa, pero la mayoría de ellos parecen mencionar el error específico Resource temporarily unavailable. Consulte al final de esta publicación algunos ejemplos de mensajes de error.

Ahora hay muchas personas que han recibido este mensaje de error y muchas respuestas a ellas. Lo que es realmente frustrante es que todo el mundo parece estar especulando sobre cómo se podría resolver el problema, pero nadie parece indicar cómo identificar cuál de las muchas causas posibles del problema está presente.

He recopilado estas 5 posibles causas del error y cómo verificar que no estén presentes en mi sistema:

1. Existe un límite para todo el sistema en la cantidad de subprocesos configurados en /proc/sys/kernel/threads-max( fuente ). En mi caso, esto está configurado en 60613.
2. Cada hilo ocupa algo de espacio en la pila. El límite de tamaño de la pila se configura usando ulimit -s( fuente ). El límite de mi concha solía ser 8192, pero han aumentado por poner * soft stack 32768en /etc/security/limits.conf, por lo que ulimit -sahora vuelve 32768. También lo he aumentado para el proceso de acoplador al ponerlo LimitSTACK=33554432en /etc/systemd/system/docker.service( fuente , y verifiqué que el límite se aplica al examinar /proc/<pid of docker>/limitsy ejecutar ulimit -sdentro de un contenedor de acoplador.
3. Cada hilo lleva algo de memoria. Se configura un límite de memoria virtual mediante ulimit -v. En mi sistema está configurado como unlimited, y el 80% de mis 3 GB de memoria están libres.
4. Hay un límite en la cantidad de procesos que se usan ulimit -u. Los hilos cuentan como procesos en este caso ( fuente ). En mi sistema, el límite se establece en 30306, y para el dacker de Docker y dentro de los contenedores de Docker, el límite es 1048576. El número de subprocesos actualmente en ejecución se puede encontrar ejecutando ls -1d /proc/*/task/* | wc -lo ejecutando ps -elfT | wc -l( fuente ). En mi sistema están entre 700y 800.
5. Existe un límite en la cantidad de archivos abiertos, que según algunas fuentes también es relevante al crear hilos. El límite se configura mediante ulimit -n. En mi sistema y en la ventana acoplable, el límite está establecido en 1048576. La cantidad de archivos abiertos se puede encontrar usando lsof | wc -l( fuente ), en mi sistema se trata 30000.

Parece que antes del último reinicio estaba ejecutando el kernel 4.2.5-1, ahora estoy ejecutando 4.3.3-2. La degradación a 4.2.5-1 soluciona todos los problemas. Otras publicaciones que mencionan el problema son esto y esto . He abierto un informe de error para Arch Linux .

¿Qué ha cambiado en el núcleo que podría estar causando esto?

Aquí hay algunos mensajes de error de ejemplo:

Crash dump was written to: erl_crash.dump
Failed to create aux thread

Jan 07 14:37:25 edeltraud docker[30625]: runtime/cgo: pthread_create failed: Resource temporarily unavailable

dpkg: unrecoverable fatal error, aborting:
 fork failed: Resource temporarily unavailable
E: Sub-process /usr/bin/dpkg returned an error code (2)

test -z "/usr/include" || /usr/sbin/mkdir -p "/tmp/lib32-popt/pkg/lib32-popt/usr/include"
/bin/sh: fork: retry: Resource temporarily unavailable
 /usr/bin/install -c -m 644 popt.h '/tmp/lib32-popt/pkg/lib32-popt/usr/include'
test -z "/usr/share/man/man3" || /usr/sbin/mkdir -p "/tmp/lib32-popt/pkg/lib32-popt/usr/share/man/man3"
/bin/sh: fork: retry: Resource temporarily unavailable
/bin/sh: fork: retry: No child processes
/bin/sh: fork: retry: Resource temporarily unavailable
/bin/sh: fork: retry: No child processes
/bin/sh: fork: retry: No child processes
/bin/sh: fork: retry: Resource temporarily unavailable
/bin/sh: fork: retry: Resource temporarily unavailable
/bin/sh: fork: retry: No child processes
/bin/sh: fork: Resource temporarily unavailable
/bin/sh: fork: Resource temporarily unavailable
make[3]: *** [install-man3] Error 254

Jan 07 11:04:39 edeltraud docker[780]: time="2016-01-07T11:04:39.986684617+01:00" level=error msg="Error running container: [8] System error: fork/exec /proc/self/exe: resource temporarily unavailable"

[Wed Jan 06 23:20:33.701287 2016] [mpm_event:alert] [pid 217:tid 140325422335744] (11)Resource temporarily unavailable: apr_thread_create: unable to create worker thread

El problema es causado por el TasksMaxatributo systemd. Se introdujo en systemd 228 y utiliza el subsistema pid cgroups, que se introdujo en el kernel 4.3 de Linux. 512Por lo tanto, se habilita un límite de tareas en systemd si se está ejecutando el kernel 4.3 o posterior. La característica se anuncia aquí y se introdujo en esta solicitud de extracción y los valores predeterminados se establecieron en esta solicitud de extracción . Después de actualizar mi kernel a 4.3, systemctl status dockermuestra una Taskslínea:

# systemctl status docker
● docker.service - Docker Application Container Engine
   Loaded: loaded (/etc/systemd/system/docker.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2016-01-15 19:58:00 CET; 1min 52s ago
     Docs: https://docs.docker.com
 Main PID: 2770 (docker)
    Tasks: 502 (limit: 512)
   CGroup: /system.slice/docker.service

Ajuste TasksMax=infinity en la [Service]sección de docker.servicesoluciona el problema. docker.servicegeneralmente está dentro /usr/share/systemd/system, pero también se puede colocar / copiar /etc/systemd/systempara evitar que el administrador de paquetes lo anule.

Una solicitud de extracción está aumentando TasksMaxpara los archivos systemd de ejemplo de Docker, y un informe de error de Arch Linux está tratando de lograr lo mismo para el paquete. Hay una discusión adicional en el Foro Arch Linux y en un informe de error de Arch Linux con respecto a lxc .

DefaultTasksMax puede ser usado en [Manager] sección en /etc/systemd/system.conf(o /etc/systemd/user.confpara servicios ejecutados por el usuario) para controlar el valor predeterminado de TasksMax.

Systemd también aplica un límite para los programas que se ejecutan desde un shell de inicio de sesión. Estos valores predeterminados son 4096por usuario (se incrementarán a12288 ) y se configuran como UserTasksMaxen la [Login]sección de /etc/systemd/logind.conf.

La respuesta de cdauth es correcta, pero hay otro detalle que agregar.

En mi sistema Ubuntu 16.04 con systemd 229 y un kernel 4.3, se impuso un límite de 512 pid en los ámbitos de sesión de forma predeterminada, incluso cuando UserTasksMax se estableció en el nuevo valor predeterminado, mayor de 12288. Por lo tanto, el alcance de cualquier sesión de usuario se limitó a 512 hilos.

La única manera que encontré para eliminar el límite fue establecido DefaultTasksMax=unlimiteden /etc/systemd/system.confysystemctl daemon-reexec (o reiniciar).

Puede verificar si esto está sucediendo emitiendo systemctl status, seleccionando un alcance de sesión y cat /sys/fs/cgroup/pids/user.slice/user-${UID}.slice/session-FOO.scope/pids.max.

Después de leer este hilo.

Esta solución funcionó para mí: docker -d --exec-opt native.cgroupdriver=cgroupfs. De hecho, lo agregué a la OPTIONSen /etc/sysconfig/docker...