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:
- 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 en60613
. - 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 ser8192
, pero han aumentado por poner* soft stack 32768
en/etc/security/limits.conf
, por lo queulimit -s
ahora vuelve32768
. También lo he aumentado para el proceso de acoplador al ponerloLimitSTACK=33554432
en/etc/systemd/system/docker.service
( fuente , y verifiqué que el límite se aplica al examinar/proc/<pid of docker>/limits
y ejecutarulimit -s
dentro de un contenedor de acoplador. - Cada hilo lleva algo de memoria. Se configura un límite de memoria virtual mediante
ulimit -v
. En mi sistema está configurado comounlimited
, y el 80% de mis 3 GB de memoria están libres. - 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 en30306
, y para el dacker de Docker y dentro de los contenedores de Docker, el límite es1048576
. El número de subprocesos actualmente en ejecución se puede encontrar ejecutandols -1d /proc/*/task/* | wc -l
o ejecutandops -elfT | wc -l
( fuente ). En mi sistema están entre700
y800
. - 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 en1048576
. La cantidad de archivos abiertos se puede encontrar usandolsof | wc -l
( fuente ), en mi sistema se trata30000
.
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
Respuestas:
El problema es causado por el
TasksMax
atributo systemd. Se introdujo en systemd 228 y utiliza el subsistema pid cgroups, que se introdujo en el kernel 4.3 de Linux.512
Por 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 docker
muestra unaTasks
línea:Ajuste
TasksMax=infinity
en la[Service]
sección dedocker.service
soluciona el problema.docker.service
generalmente está dentro/usr/share/systemd/system
, pero también se puede colocar / copiar/etc/systemd/system
para evitar que el administrador de paquetes lo anule.Una solicitud de extracción está aumentando
TasksMax
para 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.conf
para servicios ejecutados por el usuario) para controlar el valor predeterminado deTasksMax
.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
4096
por usuario (se incrementarán a12288
) y se configuran comoUserTasksMax
en la[Login]
sección de/etc/systemd/logind.conf
.fuente
/lib/systemd/system/docker.service
en mi prueba de Debian.systemctl set-property docker.service TasksMax=4096
establecerá 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./etc/systemd/system/docker.service.d/50-TasksMax.conf
Ubuntu 16), debe ejecutarsystemctl daemon-reload
. Hacer unsudo service docker restart
NO funcionará.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=unlimited
en/etc/systemd/system.conf
ysystemctl daemon-reexec
(o reiniciar).Puede verificar si esto está sucediendo emitiendo
systemctl status
, seleccionando un alcance de sesión ycat /sys/fs/cgroup/pids/user.slice/user-${UID}.slice/session-FOO.scope/pids.max
.fuente
@reboot lxc-autostart
a su crontab para iniciarlos automáticamente en el arranque, y de repente obtiene contenedores paralizados después del reinicio.Después de leer este hilo.
Esta solución funcionó para mí:
docker -d --exec-opt native.cgroupdriver=cgroupfs
. De hecho, lo agregué a laOPTIONS
en/etc/sysconfig/docker
...fuente