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

39

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
cdauth
fuente
1
¿Recientemente actualizaste al kernel 4.3?
Roni Choudhury
Eso está muy bien posible. ¿Por qué?
cdauth
1
Asombroso, bajé al kernel 4.2.5-1 y ¡todo vuelve a funcionar! ¿Tienes alguna idea de qué está causando esto y cómo solucionarlo con 4.3?
cdauth
No tengo idea de qué lo está causando. Mi método para solucionarlo está esperando que los hilos del foro de Arch Linux sobre el tema se marquen "SOLUCIONADO" :-P.
Roni Choudhury
1
+1 Por ser una pregunta excelente e investigada, incluso si no tuviera el mismo problema
Roy Truelove

Respuestas:

47

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.

cdauth
fuente
1
FWIW, el archivo de servicio estaba /lib/systemd/system/docker.serviceen mi prueba de Debian.
El compilador
2
FWIW, diciendo systemctl set-property docker.service TasksMax=4096establecerá la propiedad para un servicio actualmente en ejecución y mantendrá la configuración para reinicios posteriores en el lugar correcto para la instalación de la ventana acoplable en cuestión.
Nakedible
Este es un enfoque común . Pero tenga en cuenta que el cambio de Docker que propuso fue revertido después de publicar esta respuesta, el 09/02/2016, esta reversión se lanzó al mundo en Docker versión 1.10.1.
JdeBP
hombre gracias gracias gracias! He estado buscando demasiado tiempo para esto
achabahe
Si realiza el cambio en el archivo de configuración (el mío estaba en /etc/systemd/system/docker.service.d/50-TasksMax.confUbuntu 16), debe ejecutar systemctl daemon-reload. Hacer un sudo service docker restartNO funcionará.
osman
4

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.

Ryan C. Underwood
fuente
Hice el cambio a /etc/systemd/system.conf y reinicié. Docker todavía enumera el límite de tareas como 512. El uso del comentario de @ Nakedible de arriba actualizó las tareas disponibles.
Ben Mathews
1
Gracias Ryan! @BenMathews tal vez esto se debía a que ambos son temas válidos en Ubuntu 16.04, es necesario fijarlos tanto para las cosas para que funcione correctamente. Este problema parece aplicarse a los contenedores iniciados por un demonio, no por un usuario en un shell. Entonces, todo parece estar bien, agrega @reboot lxc-autostarta su crontab para iniciarlos automáticamente en el arranque, y de repente obtiene contenedores paralizados después del reinicio.
qris
1

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...

Sebastiaan Pasterkamp
fuente