Veo un problema muy similar para eth0. Ubuntu 12.04 también.

Tengo que apagar y encender la máquina. Desde /var/log/kern.log :

May 22 19:26:08 box kernel: [596765.670275] device veth5070 entered promiscuous mode
May 22 19:26:08 box kernel: [596765.680630] IPv6: ADDRCONF(NETDEV_UP): veth5070: link is not ready
May 22 19:26:08 box kernel: [596765.700561] IPv6: ADDRCONF(NETDEV_CHANGE): veth5070: link becomes ready
May 22 19:26:08 box kernel: [596765.700628] docker0: port 7(veth5070) entered forwarding state
May 22 19:26:08 box kernel: [596765.700638] docker0: port 7(veth5070) entered forwarding state
May 22 19:26:19 box kernel: [596777.386084] [FW DBLOCK] IN=docker0 OUT= PHYSIN=veth5070 MAC=56:84:7a:fe:97:99:9e:df:a7:3f:23:42:08:00 SRC=172.17.0.8 DST=172.17.42.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=170 DF PROTO=TCP SPT=51615 DPT=13162 WINDOW=14600 RES=0x00 SYN URGP=0
May 22 19:26:21 box kernel: [596779.371993] [FW DBLOCK] IN=docker0 OUT= PHYSIN=veth5070 MAC=56:84:7a:fe:97:99:9e:df:a7:3f:23:42:08:00 SRC=172.17.0.8 DST=172.17.42.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=549 DF PROTO=TCP SPT=46878 DPT=12518 WINDOW=14600 RES=0x00 SYN URGP=0
May 22 19:26:23 box kernel: [596780.704031] docker0: port 7(veth5070) entered forwarding state
May 22 19:27:13 box kernel: [596831.359999] docker0: port 7(veth5070) entered disabled state
May 22 19:27:13 box kernel: [596831.361329] device veth5070 left promiscuous mode
May 22 19:27:13 box kernel: [596831.361333] docker0: port 7(veth5070) entered disabled state
May 22 19:27:24 box kernel: [596841.516039] unregister_netdevice: waiting for eth0 to become free. Usage count = 1
May 22 19:27:34 box kernel: [596851.756060] unregister_netdevice: waiting for eth0 to become free. Usage count = 1
May 22 19:27:44 box kernel: [596861.772101] unregister_netdevice: waiting for eth0 to become free. Usage count = 1

Oye, esto acaba de empezar a pasarme también.

Versión de Docker:

Client version: 0.11.1
Client API version: 1.11
Go version (client): go1.2.1
Git commit (client): fb99f99
Server version: 0.11.1
Server API version: 1.11
Git commit (server): fb99f99
Go version (server): go1.2.1
Last stable version: 0.11.1

Registro de kernel : http://pastebin.com/TubCy1tG

Detalles del sistema :
Ejecutando Ubuntu 14.04 LTS con kernel parcheado (3.14.3-rt4). Sin embargo, ver que suceda con el kernel linux-3.13.0-27-generic predeterminado. Sin embargo, lo gracioso es que cuando esto sucede, todas las ventanas de mi terminal se congelan, lo que me permite escribir algunos caracteres como máximo antes de eso. El mismo destino corre con todos los nuevos que abro también, y termino necesitando apagar y encender mi pobre computadora portátil como el buen doctor de arriba. Para que conste, estoy ejecutando fish shell en urxvt o xterm en xmonad. No he comprobado si afecta a bash simple.

Esto puede ser relevante:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065434#yui_3_10_3_1_1401948176063_2050

Copiar una cantidad bastante grande de datos a través de la red dentro de un contenedor
y luego salir del contenedor puede desencadenar un decremento faltante en el
recuento de referencias de CPU en un dispositivo de red.

Efectivamente, una de las veces que me sucedió esto fue justo después de apt-get ting un paquete con un montón de dependencias.

La actualización de Ubuntu 12.04.3 a 14.04 solucionó esto sin ningún otro cambio.

Experimento esto en RHEL7, 3.10.0-123.4.2.el7.x86_64

He notado que sucede lo mismo con mis interfaces de red virtual VirtualBox cuando estoy ejecutando 3.14-rt4. Se supone que está arreglado en vainilla 3.13 o algo así.

@egasimus Lo mismo aquí:

Actualicé al kernel de Debian 3.14 y el problema parece haber desaparecido. Parece que el problema existía en algunos kernels <3.5, se corrigió en 3.5, retrocedió en 3.6 y se parcheó en algo 3.12-3.14. https://bugzilla.redhat.com/show_bug.cgi?id=880394

@spiffytech ¿Tiene alguna idea de dónde puedo informar esto con respecto al sabor del kernel en tiempo real? Creo que solo están lanzando un parche RT para todas las demás versiones, y realmente odiaría ver que 3.16-rt salga con esto todavía roto. : /

EDITAR: Archivado en kernel.org .

Recibo esto en Ubuntu 14.10 con 3.18.1. Muestra el registro del kernel

Dec 21 22:49:31 inotmac kernel: [15225.866600] unregister_netdevice: waiting for lo to become free. Usage count = 2
Dec 21 22:49:40 inotmac kernel: [15235.179263] INFO: task docker:19599 blocked for more than 120 seconds.
Dec 21 22:49:40 inotmac kernel: [15235.179268]       Tainted: G           OE  3.18.1-031801-generic #201412170637
Dec 21 22:49:40 inotmac kernel: [15235.179269] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 21 22:49:40 inotmac kernel: [15235.179271] docker          D 0000000000000001     0 19599      1 0x00000000
Dec 21 22:49:40 inotmac kernel: [15235.179275]  ffff8802082abcc0 0000000000000086 ffff880235c3b700 00000000ffffffff
Dec 21 22:49:40 inotmac kernel: [15235.179277]  ffff8802082abfd8 0000000000013640 ffff8800288f2300 0000000000013640
Dec 21 22:49:40 inotmac kernel: [15235.179280]  ffff880232cf0000 ffff8801a467c600 ffffffff81f9d4b8 ffffffff81cd9c60
Dec 21 22:49:40 inotmac kernel: [15235.179282] Call Trace:
Dec 21 22:49:40 inotmac kernel: [15235.179289]  [<ffffffff817af549>] schedule+0x29/0x70
Dec 21 22:49:40 inotmac kernel: [15235.179292]  [<ffffffff817af88e>] schedule_preempt_disabled+0xe/0x10
Dec 21 22:49:40 inotmac kernel: [15235.179296]  [<ffffffff817b1545>] __mutex_lock_slowpath+0x95/0x100
Dec 21 22:49:40 inotmac kernel: [15235.179299]  [<ffffffff8168d5c9>] ? copy_net_ns+0x69/0x150
Dec 21 22:49:40 inotmac kernel: [15235.179302]  [<ffffffff817b15d3>] mutex_lock+0x23/0x37
Dec 21 22:49:40 inotmac kernel: [15235.179305]  [<ffffffff8168d5f8>] copy_net_ns+0x98/0x150
Dec 21 22:49:40 inotmac kernel: [15235.179308]  [<ffffffff810941f1>] create_new_namespaces+0x101/0x1b0
Dec 21 22:49:40 inotmac kernel: [15235.179311]  [<ffffffff8109432b>] copy_namespaces+0x8b/0xa0
Dec 21 22:49:40 inotmac kernel: [15235.179315]  [<ffffffff81073458>] copy_process.part.28+0x828/0xed0
Dec 21 22:49:40 inotmac kernel: [15235.179318]  [<ffffffff811f157f>] ? get_empty_filp+0xcf/0x1c0
Dec 21 22:49:40 inotmac kernel: [15235.179320]  [<ffffffff81073b80>] copy_process+0x80/0x90
Dec 21 22:49:40 inotmac kernel: [15235.179323]  [<ffffffff81073ca2>] do_fork+0x62/0x280
Dec 21 22:49:40 inotmac kernel: [15235.179326]  [<ffffffff8120cfc0>] ? get_unused_fd_flags+0x30/0x40
Dec 21 22:49:40 inotmac kernel: [15235.179329]  [<ffffffff8120d028>] ? __fd_install+0x58/0x70
Dec 21 22:49:40 inotmac kernel: [15235.179331]  [<ffffffff81073f46>] SyS_clone+0x16/0x20
Dec 21 22:49:40 inotmac kernel: [15235.179334]  [<ffffffff817b3ab9>] stub_clone+0x69/0x90
Dec 21 22:49:40 inotmac kernel: [15235.179336]  [<ffffffff817b376d>] ? system_call_fastpath+0x16/0x1b
Dec 21 22:49:41 inotmac kernel: [15235.950976] unregister_netdevice: waiting for lo to become free. Usage count = 2
Dec 21 22:49:51 inotmac kernel: [15246.059346] unregister_netdevice: waiting for lo to become free. Usage count = 2

Enviaré docker version/info una vez que el sistema ya no esté congelado :)

También estamos viendo este problema. Ubuntu 14.04, 3.13.0-37-genérico

En el servidor Ubuntu 14.04, mi equipo descubrió que la degradación de 3.13.0-40-generic a 3.13.0-32-generic "resuelve" el problema. Dada la observación de @sbward , eso colocaría la regresión después de 3.13.0-32-generic y antes (o incluyendo) 3.13.0-37-generic.

Agregaré que, en nuestro caso, a veces vemos un recuento de uso _negativo_.

FWIW, encontramos este error al ejecutar lxc en un kernel confiable (3.13.0-40-generic # 69-Ubuntu), el mensaje aparece en dmesg seguido de este stacktrace:

[27211131.602869] INFO: task lxc-start:26342 blocked for more than 120 seconds.
[27211131.602874]       Not tainted 3.13.0-40-generic #69-Ubuntu
[27211131.602877] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[27211131.602881] lxc-start       D 0000000000000001     0 26342      1 0x00000080
[27211131.602883]  ffff88000d001d40 0000000000000282 ffff88001aa21800 ffff88000d001fd8
[27211131.602886]  0000000000014480 0000000000014480 ffff88001aa21800 ffffffff81cdb760
[27211131.602888]  ffffffff81cdb764 ffff88001aa21800 00000000ffffffff ffffffff81cdb768
[27211131.602891] Call Trace:
[27211131.602894]  [<ffffffff81723b69>] schedule_preempt_disabled+0x29/0x70
[27211131.602897]  [<ffffffff817259d5>] __mutex_lock_slowpath+0x135/0x1b0
[27211131.602900]  [<ffffffff811a2679>] ? __kmalloc+0x1e9/0x230
[27211131.602903]  [<ffffffff81725a6f>] mutex_lock+0x1f/0x2f
[27211131.602905]  [<ffffffff8161c2c1>] copy_net_ns+0x71/0x130
[27211131.602908]  [<ffffffff8108f889>] create_new_namespaces+0xf9/0x180
[27211131.602910]  [<ffffffff8108f983>] copy_namespaces+0x73/0xa0
[27211131.602912]  [<ffffffff81065b16>] copy_process.part.26+0x9a6/0x16b0
[27211131.602915]  [<ffffffff810669f5>] do_fork+0xd5/0x340
[27211131.602917]  [<ffffffff810c8e8d>] ? call_rcu_sched+0x1d/0x20
[27211131.602919]  [<ffffffff81066ce6>] SyS_clone+0x16/0x20
[27211131.602921]  [<ffffffff81730089>] stub_clone+0x69/0x90
[27211131.602923]  [<ffffffff8172fd2d>] ? system_call_fastpath+0x1a/0x1f

Me encontré con esto en Ubuntu 14.04 y Debian jessie con kernel 3.16.x.

Comando de Docker:

docker run -t -i -v /data/sitespeed.io:/sitespeed.io/results company/dockerfiles:sitespeed.io-latest --name "Superbrowse"

Esto parece un problema bastante malo ...

@jbalonso incluso con 3.13.0-32-generic obtengo el error después de solo unas pocas ejecuciones exitosas: sollozo:

@MrMMorris ¿ podrías compartir un script de reproducción usando imágenes públicas disponibles?

Todos los que ven este error en su sistema están ejecutando un paquete del kernel de Linux en su distribución que es demasiado antiguo y carece de las correcciones para este problema en particular.

Si se encuentra con este problema, asegúrese de ejecutar apt-get update && apt-get dist-upgrade -y y reiniciar su sistema. Si está en Digital Ocean, también debe seleccionar la versión del kernel que se acaba de instalar durante la actualización porque no usan el último kernel automáticamente (consulte https://digitalocean.uservoice.com/forums/136585-digitalocean / sugerencias / 2814988-dar-opción-de-usar-el-cargador-de-arranque-propio-droplet-s).

Los usuarios de CentOS / RHEL / Fedora / Scientific Linux necesitan mantener sus sistemas actualizados usando yum update y reiniciar después de instalar las actualizaciones.

Al informar de este problema, asegúrese de que su sistema esté completamente parcheado y actualizado con las últimas actualizaciones estables (sin paquetes experimentales / de prueba / alpha / beta / rc instalados manualmente) proporcionados por el proveedor de su distribución.

@unclejack

Corrí apt-get update && apt-get dist-upgrade -y

ubuntu 14.04 3.13.0-46-genérico

Sigue apareciendo el error después de solo una docker run

Puedo crear una AMI para reproducirla si es necesario

@MrMMorris Gracias por confirmar que sigue siendo un problema con el último paquete del kernel en Ubuntu 14.04.

Cualquier otra cosa que pueda hacer para ayudar, ¡hágamelo saber! :sonrisa:

@MrMMorris si puede proporcionar un reproductor, hay un error abierto para Ubuntu y será muy apreciado: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152

@rsampaio, si tengo tiempo hoy, ¡definitivamente lo conseguiré para ti!

Este problema también aparece en 3.16 (.7) tanto en Debian 7 como en Debian 8: https://github.com/docker/docker/issues/9605#issuecomment -85025729. Reiniciar el servidor es la única forma de solucionar este problema por ahora.

Ver este problema en RHEL 6.6 con kernel 2.6.32-504.8.1.el6.x86_64 al iniciar algunos contenedores Docker (no todos los contenedores)
_ kernel: unregister_netdevice : esperando que lo sea libre. Recuento de uso = -1_

Nuevamente, reiniciar el servidor parece ser la única solución en este momento.

También viendo esto en CoreOS (647.0.0) con kernel 3.19.3.

El reinicio también es la única solución que he encontrado.

Debian jessie probado con el kernel de sid (4.0.2); el problema persiste.

¿Alguien ve este problema al ejecutar contenedores que no son de ubuntu?

Si. Debian.
19 de июня 2015 г. 19:01 пользователь "popsikle" [email protected]
написал:

¿Alguien ve este problema al ejecutar contenedores que no son de ubuntu?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/5618#issuecomment -113556862.

Este es un problema del kernel, no un problema relacionado con la imagen. Cambiar una imagen por otra no mejorará ni empeorará este problema.

Experimentando un problema en Debian Jessie en un BeagleBone Black que ejecuta el kernel 4.1.2-bone12

Experimentar después de cambiar de 4.1.2 a 4.2-rc2 (usando git build de 1.8.0).
Eliminar / var / lib / docker / * no resuelve el problema.
Volver a 4.1.2 resuelve el problema.

Además, VirtualBox tiene el mismo problema y hay un parche para v5.0.0 (retroportado a v4) que supuestamente hace algo en la parte del controlador del kernel ... vale la pena mirar para comprender el problema.

Esta es la solución en VirtualBox: https://www.virtualbox.org/attachment/ticket/12264/diff_unregister_netdev
En realidad, no modifican el kernel, solo su módulo del kernel.

También teniendo este problema con 4.2-rc2:

unregister_netdevice: esperando que vethf1738d3 se vuelva libre. Recuento de uso = 1

Recién compilado 4.2-RC3, parece funcionar de nuevo

@ nazar-pc Gracias por la información. Solo lo golpeo con 4.1.3, estaba bastante molesto
@techniq lo mismo aquí, error del kernel bastante malo. Me pregunto si deberíamos informarlo para que se vuelva a exportar al árbol 4.1.

Linux docker13 3.19.0-22-generic # 22-Ubuntu SMP Mar 16 de junio 17:15:15 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

Kernel de Ubuntu 15.04, mismo problema

También lo vi con 4.2-rc3. No hay ningún error sobre la fuga del dispositivo :) Puedo reproducir en cualquier kernel> = 4.1 bajo carga alta.

Yo también tuve este problema. Ubuntu 3.13.0-57-generic, aprovisionado a través de tutum. Desafortunadamente, llena kern.log y syslog y bloquea la máquina. Sucede en la máquina de la base de datos (postgres acoplado), por lo que derriba todo el sistema ...

Uniéndome al coro de "yo también", estoy viendo este problema en una VM cloudstack que ejecuta RancherOS (un SO mínimo) 0.3.3 mientras extrae imágenes de la ventana acoplable de un repositorio de ventana acoplable privado local. Sucede cada diez segundos, no estoy seguro de si eso significa algo o no.

También tengo este problema con 4.2-rc7

Alguna novedad sobre esto, ¿qué kernel deberíamos usar? Sigue sucediendo incluso con un kernel completamente actualizado (3.19.0-26 en Ubuntu 14.04)

También tenemos este problema. Esto sucede después de que configuramos userland-proxy = false. Estamos usando algunos scripts de monitor que generarán un nuevo contenedor de ventana acoplable para ejecutar el comando de complementos de nagios cada 1 minuto. Lo que veo en el árbol de procesos es que está atascado en el comando docker rm y veo muchos errores en el archivo kern.log

Sep 24 03:53:13 prod-service-05 kernel: [ 1920.544106] unregister_netdevice: waiting for lo to become free. Usage count = 2
Sep 24 03:53:13 prod-service-05 kernel: [ 1921.008076] unregister_netdevice: waiting for vethb6bf4db to become free. Usage count = 1
Sep 24 03:53:23 prod-service-05 kernel: [ 1930.676078] unregister_netdevice: waiting for lo to become free. Usage count = 2
Sep 24 03:53:23 prod-service-05 kernel: [ 1931.140074] unregister_netdevice: waiting for vethb6bf4db to become free. Usage count = 1
Sep 24 03:53:33 prod-service-05 kernel: [ 1940.820078] unregister_netdevice: waiting for lo to become free. Usage count = 2

Esta es la información de nuestro sistema

ubuntu@prod-service-02:~$ docker version
Client:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Thu Sep 10 19:19:00 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Thu Sep 10 19:19:00 UTC 2015
 OS/Arch:      linux/amd64
ubuntu@prod-service-02:~$ docker info
Containers: 2
Images: 52
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: gelf
Kernel Version: 4.0.9-040009-generic
Operating System: Ubuntu 14.04.3 LTS
CPUs: 4
Total Memory: 7.304 GiB
Name: prod-service-02
ID: NOIK:LVBV:HFB4:GZ2Y:Q74F:Q4WW:ZE22:MDE7:7EBW:XS42:ZK4G:XNTB
WARNING: No swap limit support
Labels:
 provider=generic

Actualización: aunque https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152 dijo que ya está arreglado en 2015-08-17. Así que probé con el kernel v3.19.8-ckt6-vivid que se construyó el 02-Sep-2015 o incluso v4.2.1-inestable que se construyó el 21-Sep-2015 y todavía tengo un problema.

Acabo de encontrar el problema nuevamente usando 3.19.0-28-generic , por lo que el último kernel de ubuntu no es seguro

Sí, parece que --userland-proxy=false no es la mejor opción ahora con kernels más antiguos :(

No. Intenté --userland-proxy = false para todas las versiones del kernel 3.19, 4.0, 4.2 y el problema sigue ocurriendo.

Estoy usando un proxy de usuario sin iptables (--iptables = false) y veo esto una vez al día como mínimo. Lamentablemente, la única solución fue un perro guardián que reinició el servidor mediante la técnica SysRq.

Mis sistemas ejecutan algunos contenedores que son escritores de stdout / err pesados, ya que otros informaron que pueden desencadenar el error.

`` `` ``
$ docker info
Contenedores: 15
Imágenes: 148
Controlador de almacenamiento: aufs
Directorio raíz: / var / lib / docker / aufs
Sistema de archivos de respaldo: extfs
Dirs: 178
Dirperm1 admitido: verdadero
Controlador de ejecución: native-0.2
Controlador de registro: archivo json
Versión de Kernel: 3.19.0-26-generic
Sistema operativo: Ubuntu 14.04.3 LTS
CPU: 12
Memoria total: 62,89 GiB
Nombre: * *
ID: 2 ALJ: YTUH : QCNX: FPEO : YBG4: ZTL4: 2 EYK: AV7D : FN7C: IVNU: UWBL : YYZ5

$ versión docker
Versión del cliente: 1.7.0
Versión de la API del cliente: 1.19
Go versión (cliente): go1.4.2
Confirmación de Git (cliente): 0baf609
OS / Arch (cliente): linux / amd64
Versión del servidor: 1.7.0
Versión de la API del servidor: 1.19
Go versión (servidor): go1.4.2
Confirmación de Git (servidor): 0baf609
OS / Arch (servidor): linux / amd64```
`` `` ``

Desafortunadamente, estoy en el mismo caso, hoy un servidor de producción falló 3 veces en este error, y la única forma de manejarlo es usar algunos comandos mágicos SysRq.

protuberancia

Sigo viendo esto en la última versión de Debian jessie usando el kernel 4.2.0

El mismo problema aqui. De repente, tres de mis servidores de aws dejaron de funcionar y los registros gritaban "unregister_netdevice: esperando que lo se liberara. Usage count = 1"

Ubuntu: 14.04
Versión de Kernel: 3.13.0-63-generic
Docker: 1.7.1

Syslog

¿Existe una versión de kernel segura de usar?

El problema también ocurre con el kernel 4.2 de Ubuntu 15.10

sucedió en coreos:

Imágenes: 1174
Controlador de almacenamiento: superposición
Sistema de archivos de respaldo: extfs
Controlador de ejecución: native-0.2
Controlador de registro: archivo json
Versión de Kernel: 4.1.7-coreos
Sistema operativo: CoreOS 766.4.0

El error del kernel que @ killme2008 dijo la última vez

Probablemente debería intentarlo con este parche aplicado sobre su kernel http://www.spinics.net/lists/netdev/msg351337.html
paquete: condición de carrera en packet_bind

o esperar el backport in -stable tree; vendrá tarde o temprano.

: +1: ¡Buenas noticias!

Hola a todos, ¡buenas noticias!

Desde mi último comentario aquí (en el momento de escribir este artículo, hace 17 días) no he vuelto a tener estos errores. Mis servidores (unos 30 de ellos) ejecutaban ubuntu 14.04 con algunos paquetes desactualizados.

Después de una actualización completa del sistema que incluye docker-engine (de 1.7.1 a 1.8.3) + actualización del kernel a la última versión posible en el repositorio de ubuntu, mis servidores se están ejecutando sin incidencias.

:bola 8:

También sucedió hoy en 3 de nuestras instancias de AWS:

Client:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Thu Sep 10 19:19:00 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Thu Sep 10 19:19:00 UTC 2015
 OS/Arch:      linux/amd64

Containers: 45
Images: 423
Storage Driver: devicemapper
 Pool Name: docker-202:1-527948-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 22.79 GB
 Data Space Total: 107.4 GB
 Data Space Available: 84.58 GB
 Metadata Space Used: 35.58 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.112 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.77 (2012-10-15)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-49-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 8
Total Memory: 60 GiB
Name: ip-10-0-1-36
ID: HEZG:TBTM:V4LN:IU7U:P55N:HNVH:XXOP:RMUX:JNWH:DSJP:3OA4:MGO5
WARNING: No swap limit support

Tengo el mismo problema con Ubuntu 14.04, todos los paquetes actualizados y el último linux-generic-lts-vivid kernel:

$ docker version
Client:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 17:43:42 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 17:43:42 UTC 2015
 OS/Arch:      linux/amd64

$ docker info
Containers: 14
Images: 123
Server Version: 1.9.0
Storage Driver: aufs
 Root Dir: /mnt/docker-images/aufs
 Backing Filesystem: extfs
 Dirs: 151
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.19.0-32-generic
Operating System: Ubuntu 14.04.3 LTS
CPUs: 8
Total Memory: 29.45 GiB
Name: ip-172-31-35-202
ID: 3B7E:5DJL:S4IB:KUCL:6UKN:64OF:WCLO:JKGK:4OI2:I2R6:63EY:WATN
WARNING: No swap limit support

También lo tuve con el último linux-image-generic (3.13.0-67-generic).

Tener los mismos problemas aquí en rancherOS.

Sigue sucediendo en Fedora 22 (actualizado) ...
Puedo deshacerme de los mensajes si reinicio la ventana acoplable

systemctl reiniciar ventana acoplable
... el mensaje vuelve a aparecer unas 3-4 veces y luego se detiene

El mismo error me encuentro con coreos:

versión de coreos:

 core @ core-1-94 ~ $ cat / etc / os-release
 NOMBRE = CoreOS
 ID = coreos
 VERSIÓN = 766.5.0
 VERSION_ID = 766.5.0
 BUILD_ID =
 PRETTY_NAME = "CoreOS 766.5.0"
 ANSI_COLOR = "1; 32"
 HOME_URL = "https://coreos.com/"
 BUG_REPORT_URL = "https://github.com/coreos/bugs/issues"

versión de Docker:

 core @ core-1-94 ~ $ versión de la ventana acoplable
 Versión del cliente: 1.7.1
 Versión de la API del cliente: 1.19
 Go versión (cliente): go1.4.2
 Git commit (cliente): df2f73d-dirty
 OS / Arch (cliente): linux / amd64
 Versión del servidor: 1.7.1
 Versión de la API del servidor: 1.19
 Go versión (servidor): go1.4.2
 Confirmación de Git (servidor): df2f73d-dirty
 OS / Arch (servidor): linux / amd64

 core @ core-1-94 ~ $ uname -a
 Linux core-1-94 4.1.7-coreos-r1 # 2 SMP Jue 5 Nov 02:10:23 UTC 2015 x86_64 Intel (R) Xeon (R) CPU E5-2660 v3 @ 2.60GHz GenuineIntel GNU / Linux

registro del sistema:

 07 de diciembre 16:26:54 núcleo-1-94 kernel: unregister_netdevice: esperando que veth775ea53 se vuelva libre. Recuento de uso = 1
 07 de diciembre 16:26:54 core-1-94 kernel: unregister_netdevice: esperando que lo sea libre. Recuento de uso = 2
 07 de diciembre 16:26:55 core-1-94 sdnotify-proxy [1203]: I1207 08: 26: 55.930559 00001 vxlan.go: 340] Ignorando no fallar: 4e: 5c: 47: 2f: 9a: 85, 10.244 .97.10
 07 de diciembre 16:26:59 core-1-94 dockerd [1269]: time = "2015-12-07T16: 26: 59.448438648 + 08: 00" level = info msg = "GET / version"
 07 de diciembre 16:27:01 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 01.050588 00001 vxlan.go: 340] Ignorando no fallar: 5a: b1: f7: e9: 7d: d0, 10.244 .34.8
 07 de diciembre 16:27:02 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 02.398020120 + 08: 00" level = info msg = "GET / version"
 07 de diciembre 16:27:02 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 02.398316249 + 08: 00" level = info msg = "GET / version"
 07 de diciembre 16:27:04 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 04.449317389 + 08: 00" level = info msg = "GET / version"
 07 de diciembre 16:27:04 núcleo-1-94 kernel: unregister_netdevice: esperando que veth775ea53 se vuelva libre. Recuento de uso = 1
 07 de diciembre 16:27:04 core-1-94 kernel: unregister_netdevice: esperando que lo sea libre. Recuento de uso = 2
 07 de diciembre 16:27:06 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 06.106573 00001 vxlan.go: 340] Ignorando no fallar: a6: 38: ac: 79: 93: f5, 10.244 .47.24
 07 de diciembre 16:27:09 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 09.449944048 + 08: 00" level = info msg = "GET / version"
 07 de diciembre 16:27:11 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 11.162578 00001 vxlan.go: 340] Ignorando no fallar: 0e: f0: 6f: f4: 69: 57, 10.244 .71.24
 07 de diciembre 16:27:12 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 12.502991197 + 08: 00" level = info msg = "GET / version"
 07 de diciembre 16:27:12 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 12.503411160 + 08: 00" level = info msg = "GET / version"
 07 de diciembre 16:27:14 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 14.450646841 + 08: 00" level = info msg = "GET / version"
 07 de diciembre 16:27:14 core-1-94 kernel: unregister_netdevice: esperando que veth775ea53 se vuelva libre. Recuento de uso = 1
 07 de diciembre 16:27:14 core-1-94 kernel: unregister_netdevice: esperando que lo sea libre. Recuento de uso = 2
 07 de diciembre 16:27:16 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 16.282556 00001 vxlan.go: 340] Ignorando no fallar: a6: 62: 77: 31: ef: 68, 10.244 .13.6
 07 de diciembre 16:27:19 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 19.451486277 + 08: 00" level = info msg = "GET / version"
 07 de diciembre 16:27:21 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 21.402559 00001 vxlan.go: 340] Ignorando no fallar: 92: c4: 66: 52: cd: bb, 10.244 .24.7
 07 de diciembre 16:27:22 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 22.575446889 + 08: 00" level = info msg = "GET / version"
 07 de diciembre 16:27:22 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 22.575838302 + 08: 00" level = info msg = "GET / version"
 07 de diciembre 16:27:24 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 24.452320364 + 08: 00" level = info msg = "GET / version"
 07 de diciembre 16:27:24 núcleo-1-94 kernel: unregister_netdevice: esperando que veth775ea53 se vuelva libre. Recuento de uso = 1
 07 de diciembre 16:27:24 core-1-94 kernel: unregister_netdevice: esperando que lo sea libre. Recuento de uso = 2
 07 de diciembre 16:27:26 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 26.394569 00001 vxlan.go: 340] Ignorando no fallar: 6a: f7: bf: ec: 03: 50, 10.244 .87.8
 07 de diciembre 16:27:29 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 29.453171649 + 08: 00" level = info msg = "GET / version"
 07 de diciembre 16:27:29 core-1-94 systemd [1]: Iniciando Generate / run / coreos / motd ...
 07 de diciembre 16:27:29 core-1-94 systemd [1]: Se inició Generate / run / coreos / motd.
 07 de diciembre 16:27:32 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 32.671592437 + 08: 00" level = info msg = "GET / version"
 07 de diciembre 16:27:32 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 32.671841436 + 08: 00" level = info msg = "GET / version"
 07 de diciembre 16:27:33 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 33.562534 00001 vxlan.go: 340] Ignorando no fallar: 22: b4: 62: d6: 25: b9, 10.244 .68.8
 07 de diciembre 16:27:34 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 34.453953162 + 08: 00" level = info msg = "GET / version"
 07 de diciembre 16:27:34 core-1-94 kernel: unregister_netdevice: esperando que veth775ea53 se vuelva libre. Recuento de uso = 1
 07 de diciembre 16:27:35 core-1-94 kernel: unregister_netdevice: esperando que lo se libere. Recuento de uso = 2

feliz cumpleaños, problema sangriento =)
6 de mayo de 2014

lo mismo aqui. Solo reiniciando. Última versión de Docker. Ubuntu 14.04.

@samvignoli, esto se ha identificado como un problema del kernel, por lo que, desafortunadamente, no es algo que se pueda solucionar en la ventana acoplable

@thaJeztah ¿Tiene un enlace al rastreador de errores para el problema del kernel?
¿O quizás un puntero al que se ve afectado el kernel?

Deseoso de que esto se resuelva en nuestro entorno.

@Rucknar lo siento, no lo hago (tal vez haya uno en esta discusión, no he leído todos los comentarios)

Linux atlas2 3.19.0-33-generic # 38 ~ 14.04.1-Ubuntu SMP Vie 6 de noviembre 18:17:28 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

@Rucknar, si se desplaza un poco hacia la parte superior, verá el enlace al parche http://www.spinics.net/lists/netdev/msg351337.html. Ahora está en linux master, supongo que irá a Linux 4.4, tal vez alguien ya lo haya exportado a versiones anteriores, pero no estoy seguro.

Gracias a todos, veremos qué se requiere en la actualización.

FWIW Retroporté el último parche mencionado aquí a ubuntu 3.19 y también probé en el kernel 4.2, ambos sin éxito. El problema todavía está presente incluso en la rama 4.4-rc3 net-next en este punto.

@rsampaio ¿Cómo

@fxposter tampoco podemos reproducir el problema fuera de la producción, así que tuve que arrancar algunas instancias con el kernel parcheado en producción, sucede con tanta frecuencia que puedo averiguar si un kernel se ve afectado dentro de las 24 horas posteriores a la carga de producción.

A veces lo solucionamos con un recurso muy inusual: alejamos los directorios del contenedor de / var / lib / docker / aufs / mnt

Con eso ... TAL VEZ podamos 'reiniciar el docker de servicio' y mover los directorios hacia atrás.

De lo contrario ... solo reiniciando.

@rsampaio, ¿estás hablando de la producción de heroku ahora? ¿Cómo puede evitar este problema, ya que todo su negocio se basa en contenedores, etc.?

@rsampaio , ¿usas --userland-proxy=false o solo una gran cantidad de contenedores creados? Puedo reproducirlo bastante fácil con --userland-proxy=false y con algo de carga sin :)

@ LK4D4 Creo que es solo una gran cantidad de contenedores creados / destruidos, especialmente contenedores que hacen mucho tráfico saliente, también usamos LXC en lugar de Docker pero el error es exactamente el mismo que el que se describe aquí, puedo intentar reproducir usando su método si es fácil de describir y / o no involucra carga de producción, la idea es obtener un crashdump y _quizá_ encontrar más pistas sobre qué es exactamente lo que desencadena este error.

@rsampaio Puedo reproducir con el uso prolongado de https://github.com/crosbymichael/docker-stress

¿Ha habido alguna actualización / propuesta para solucionar este problema?

@joshrendek es un error del kernel. Parece que incluso el kernel 4.4 recién lanzado no lo soluciona, por lo que hay al menos una condición de carrera más en alguna parte :)

error del kernel

=)

@samvignoli, ¿ podría mantener sus comentarios constructivos? No dude en abrir un PR si tiene formas de solucionar este problema.

¿Este error ya se informó en sentido ascendente (lista de correo del kernel)?

Seguro que lo ha sido. El primer comentario también hace referencia a este error: https://bugzilla.kernel.org/show_bug.cgi?id=81211

Abierto desde 2014. No hay comentarios de nadie que trabaje en él, salvo para decir que lo más probable es que sea una aplicación que lo usa incorrectamente.

¡Gracias por el enlace, Justin! Troll Linus =)

Saludos cordiales. = *: corazón:

@samvignoli, por favor, no hagas esto, no ayuda a nadie.
¿Alguien puede reproducir esto en una pequeña imagen de VM?
Tal vez pueda ensuciarme las manos con gdb y mucho kprintf.

error aún abierto.

SO: CentOS 7.2
núcleo: 4.4.2 elrepo kernel-ml
acoplador: 1.10.2
fs: overlayfs con xfs

Iniciar sesión:

Message from syslogd<strong i="11">@host118</strong> at Feb 29 14:52:47 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

[root<strong i="14">@host118</strong> ~]# uname -a
Linux host118 4.4.2-1.el7.elrepo.x86_64 #1 SMP Thu Feb 18 10:20:19 EST 2016 x86_64 x86_64 x86_64 GNU/Linux
[root<strong i="15">@host118</strong> ~]# cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)
[root<strong i="16">@host118</strong> ~]# lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch
Distributor ID: CentOS
Description:    CentOS Linux release 7.2.1511 (Core)
Release:    7.2.1511
Codename:   Core
[root<strong i="17">@host118</strong> ~]# docker info
Containers: 5
 Running: 2
 Paused: 0
 Stopped: 3
Images: 154
Server Version: 1.10.2
Storage Driver: overlay
 Backing Filesystem: xfs
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 4.4.2-1.el7.elrepo.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.858 GiB
Name: host118
ID: 2NW7:Y54E:AHTO:AVDR:S2XZ:BGMC:ZO4I:BCAG:6RKW:KITO:KRM2:DQIZ
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

este registro se muestra al ejecutar la imagen de la ventana acoplable sameersbn / docker-gitlab:

wget https://raw.githubusercontent.com/sameersbn/docker-gitlab/master/docker-compose.yml
docker-compose up

Puede que tenga suerte, pero después de aplicar esta configuración de sysctl, la ocurrencia de esto ha disminuido.

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 600
net.ipv4.tcp_tw_reuse = 1
net.netfilter.nf_conntrack_generic_timeout = 120
net.netfilter.nf_conntrack_max = 1555600000
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 300
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300

@joshrendek ¿cuál es la motivación detrás de estas configuraciones?

@kmike, esto fue para solucionar algunos otros problemas de conntrack (las tablas ip se están

¿Podrías mostrar el antes / después para que podamos ver qué cambió realmente? ¿Está dispuesto a realizar una búsqueda binaria en estas configuraciones y ver si hay un conjunto más pequeño?

Estoy usando CoreOS Stable (899.13.0) en una VM de Compute Engine. Este error ocurre cada vez que inicio el servidor con la siguiente bandera a 0 (el valor predeterminado). He probado varias veces de ida y vuelta y con IPv6 desactivado puedo iniciar todos los contenedores en el nodo sin ningún error:

$ cat /etc/sysctl.d/10-disable-ipv6.conf 
net.ipv6.conf.all.disable_ipv6 = 1

Utilizo el contenedor de gcloud para descargar desde GCR, por lo que tal vez el problema sea IPv6 + descarga de MB de imágenes + cierre los contenedores rápidamente.

Versión de Docker para referencia:

Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   9894698
 Built:        
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   9894698
 Built:        
 OS/Arch:      linux/amd64

También probé los indicadores sysctl anteriores en este tema; pero algunos ya tienen ese valor y el resto no pareció cambiar nada relacionado con este error:

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 600
  -----> not found in CoreOS
net.ipv4.tcp_tw_reuse = 1
  -----> default: 0
net.netfilter.nf_conntrack_generic_timeout = 120
  -----> default: 600
net.netfilter.nf_conntrack_max = 1555600000
  -----> default: 65536
net.netfilter.nf_conntrack_tcp_timeout_close = 10
  -> already: 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
  -> already: 60
net.netfilter.nf_conntrack_tcp_timeout_established = 300
  -----> default: 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
  -> already: 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
  -> already: 30
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
  -> already: 300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
  -> already: 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
  -> already: 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
  -> already: 120
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
  -> already: 300

Sigo viendo el problema cuando configuro net.ipv6.conf.all.disable_ipv6 = 1.

La herramienta de estrés de la ventana acoplable puede producir el problema con mucha facilidad.
https://github.com/crosbymichael/docker-stress

Este es el binario que construí para la herramienta anterior.
https://storage.googleapis.com/donny/main
https://storage.googleapis.com/donny/stress.json

Una vez que vemos el registro "unregister_netdevice: esperando que veth6c3b8b0 se vuelva libre. Recuento de uso", la ventana acoplable se bloquea. Creo que este es un problema del kernel provocado por Docker. Esto sucederá solo cuando la ventana acoplable userland-proxy esté desactivada (--userland-proxy = false).

He tenido esto sucediendo con y sin el proxy de usuario habilitado, por lo que no diría solo cuando está apagado.

Puede ser que empeore la situación; Sé que una vez intentamos que --userland-proxy=false el valor predeterminado, pero lo revertimos porque había efectos secundarios https://github.com/docker/docker/issues/14856

También he visto el error una vez desde ayer, claramente deshabilitar IPv6 no es una solución; pero sin la bandera ni siquiera puedo iniciar todos los contenedores del servidor sin destruir la ventana acoplable.

Ejecutando esto en CoreOS 1010.1.0 con kubernetes 1.2.2 y docker 1.10.3

Kubernetes agregó una bandera a kubelet (en dispositivos móviles, por lo que no se puede buscar) para
modo horquilla. Cámbielo a "puente promiscuo" o lo que sea válido
el valor es. No hemos visto este error desde que hicimos ese cambio.

@bprashanh

¿Confirmar o refutar?
El 13 de abril de 2016 a las 12:43 p. M., "Aaron Crickenberger" [email protected]
escribió:

Corriendo con esto en CoreOS 1010.1.0 con kubernetes 1.2.2 y docker
1.10.3

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/5618#issuecomment -209617342

Obtener esto en AWS con Linux 4.4.5-15.26.amzn1.x86_64 con Docker versión 1.9.1, compilación a34a1d5 / 1.9.1.

Ruby 2.3.0 con imagen de Alpine se está ejecutando dentro del contenedor, lo que causa esto

kernel: [58551.548114] unregister_netdevice: esperando que lo sea libre. Recuento de uso = 1

¿Alguna solución para esto?

vi esto por primera vez en Linux 3.19.0-18-generic #18~14.04.1-Ubuntu SMP Wed May 20 09:38:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Un par de reinicios lo arreglaron.

@MrMMorris Solucionado porque está seguro de que el problema ha desaparecido para siempre, o porque todavía no lo está experimentando de nuevo. Podría ser una condición de carrera ...

Está bastante claro que esta es una carrera en el kernel, perdiendo un refcount
algun lado. Este es un error REALMENTE difícil de rastrear, pero por lo que sabemos
todavía existe.

El lunes 2 de mayo de 2016 a las 10:52 p.m., Sune Keller [email protected]
escribió:

@MrMMorris https://github.com/MrMMorris Corregido porque estás seguro de que
el problema ha desaparecido para siempre, o porque no lo está experimentando de nuevo
¿todavía? Podría ser una condición de carrera ...

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/5618#issuecomment -216444133

Sí. Probé CoreOS 1032.0.0 con kernel 4.5 y el problema persiste.

Me encontré con esto nuevamente en CoreOS 1010.1.0 con kernel 4.5.0 ayer, había sido después de que se iniciaran y mataran varios contenedores en rápida sucesión.

Tengo este error.

Versión de Docker: 1.9.1
Versión de Kernel: 4.4.8-20.46.amzn1.x86_64
Sistema operativo: Amazon Linux AMI 2016.03

@sirlatrom no arreglado. Al ver esto de nuevo 😭 Se requirieron varios reinicios para resolverlo.

Actualmente se ejecuta 3.19.0-18-generic. Intentará actualizar a la última

¡aquí igual! : llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar :: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar: : llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar :: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar: : llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar :: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar: : llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar :: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:: llorar:

@samvignoli, sus comentarios no son constructivos. Deja de publicar.

lo siento, olvidé la función de pulgar hacia arriba.

Reproducido en Fedora Server 23 - 4.2.5-300.fc23.x86_64. No se puede reiniciar el servicio Docker, solo reinicie el nodo.

El mismo problema en el Kernel de Fedora 24: 4.5.2-302.fc24.x86_64. no causó ningún bloqueo, pero envía spam a un archivo de registro.

@hapylestat ¿Puedes probar systemctl restart docker ? Esto hizo que todo se me colgara.

Gracias

Esto le sucede a mis máquinas (CoreOS, EC2) con bastante frecuencia. En caso de que sea útil, aquí están todos los registros relacionados con el dispositivo veth atascado en una instancia de este error.

$ journalctl | grep veth96110d9
May 14 16:40:27 ip-10-100-37-14.eu-west-1.compute.internal systemd-udevd[4189]: Could not generate persistent MAC address for veth96110d9: No such file or directory
May 14 16:40:27 ip-10-100-37-14.eu-west-1.compute.internal kernel: IPv6: ADDRCONF(NETDEV_UP): veth96110d9: link is not ready
May 14 16:40:27 ip-10-100-37-14.eu-west-1.compute.internal systemd-networkd[665]: veth96110d9: Configured
May 14 16:40:27 ip-10-100-37-14.eu-west-1.compute.internal kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth96110d9: link becomes ready
May 14 16:40:27 ip-10-100-37-14.eu-west-1.compute.internal systemd-networkd[665]: veth96110d9: Gained carrier
May 14 16:40:27 ip-10-100-37-14.eu-west-1.compute.internal systemd-networkd[665]: veth96110d9: Lost carrier
May 14 16:40:27 ip-10-100-37-14.eu-west-1.compute.internal systemd-networkd[665]: veth96110d9: Removing non-existent address: fe80::98f4:98ff:fea2:d83b/64 (valid for ever)
May 14 16:40:32 ip-10-100-37-14.eu-west-1.compute.internal kernel: eth0: renamed from veth96110d9
May 14 16:53:45 ip-10-100-37-14.eu-west-1.compute.internal kernel: veth96110d9: renamed from eth0
May 14 16:53:45 ip-10-100-37-14.eu-west-1.compute.internal systemd-networkd[665]: veth96110d9: Configured
May 14 16:53:45 ip-10-100-37-14.eu-west-1.compute.internal systemd-networkd[665]: veth96110d9: Gained carrier
May 14 16:53:45 ip-10-100-37-14.eu-west-1.compute.internal kernel: IPv6: veth96110d9: IPv6 duplicate address fe80::42:aff:fee0:571a detected!
May 14 16:53:45 ip-10-100-37-14.eu-west-1.compute.internal systemd-networkd[665]: veth96110d9: Lost carrier
May 14 16:53:45 ip-10-100-37-14.eu-west-1.compute.internal systemd-networkd[665]: veth96110d9: Removing non-existent address: fe80::42:aff:fee0:571a/64 (valid for ever)
May 14 16:53:55 ip-10-100-37-14.eu-west-1.compute.internal kernel: unregister_netdevice: waiting for veth96110d9 to become free. Usage count = 1
May 14 16:54:05 ip-10-100-37-14.eu-west-1.compute.internal kernel: unregister_netdevice: waiting for veth96110d9 to become free. Usage count = 1
May 14 16:54:15 ip-10-100-37-14.eu-west-1.compute.internal kernel: unregister_netdevice: waiting for veth96110d9 to become free. Usage count = 1
May 14 16:54:25 ip-10-100-37-14.eu-west-1.compute.internal kernel: unregister_netdevice: waiting for veth96110d9 to become free. Usage count = 1
May 14 16:54:35 ip-10-100-37-14.eu-west-1.compute.internal kernel: unregister_netdevice: waiting for veth96110d9 to become free. Usage count = 1

Esto parece suceder cuando elimino muchos contenedores a la vez (en mi caso, cuando elimino los pods de k8s en masa).

Para aquellos que dicen que un reinicio lo solucionó, ¿reiniciaron o detuvieron / encendieron las máquinas? En las máquinas físicas, tuve que usar un reinicio de energía remoto para que la máquina volviera a funcionar.

@joshrendek , tuve que usar el arranque en frío de iLO (es decir, un ciclo de energía físico).

@joshrendek Ahora tengo un script que se ejecuta en busca de esto y hace reboot -f cuando sucede 😢.

Podría haber encontrado el problema (o simplemente haber tenido suerte). He movido el directorio gráfico de Docker de un disco particionado XFS a un disco particionado EXT4 y no puedo reproducir el problema (además de resolver una carga de otros errores XFS que estaba obteniendo). Recuerdo que @vbatts dijo que XFS aún no es compatible.

He intentado provocar ejecutando build , run , stop , delete en un ciclo infinito en imágenes variadas, creando alrededor de 10 contenedores cada ciclo, por las últimas horas.

@joedborg ¿qué controlador gráfico estás usando? Devicemapper? ¿Cubrir?

@thaJeztah Buen punto, debería haberlo mencionado. Estoy usando el controlador de superposición con (ahora) EXT4 respaldando FS.

Solía ​​usar devicemapper (porque estoy usando Fedora Server), pero tenía toneladas de dolor (como creo que muchos lo hacen), especialmente con fugas en las que el asignador no devuelve espacio al grupo una vez que se ha eliminado un contenedor.

Si ayuda, estoy en Docker 1.11.1 y Kernel 4.2.5-300.fc23.x86_64.

@joedborg es interesante, porque los documentos de RHEL mencionaron que solo EXT4 es compatible con RHEL / CentOS 7.1, y solo XFS en RHEL / CentOS 7.2. Entonces habría esperado que XFS funcionara en versiones más nuevas

@thaJeztah ah eso es extraño. Estoy tratando de pensar en otras cosas que podrían ser. He vuelto a leer desde arriba y parece que algunas personas están ejecutando la misma configuración. La única otra cosa que es diferente es que el disco XFS es un eje y el EXT4 es SSD. Seguiré empapando las pruebas mientras tanto. También cambié prod para usar la misma configuración, por lo que de cualquier manera tendremos una respuesta en poco tiempo. Sin embargo, lo estaba haciendo en casi todos los stop antes, por lo que ciertamente es mejor.

@joedborg bueno, es información realmente útil

mismo error aquí, del kernel 4.2 a 4.5, misma versión de la ventana acoplable.

Por cierto, estoy ejecutando varias máquinas virtuales en la misma caja al mismo tiempo.

$ docker version
Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:        Mon Oct 12 05:27:08 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:        Mon Oct 12 05:27:08 UTC 2015
 OS/Arch:      linux/amd64

$ docker info
Containers: 3
Images: 461
Storage Driver: devicemapper
 Pool Name: docker-253:7-1310721-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 18.08 GB
 Data Space Total: 107.4 GB
 Data Space Available: 18.37 GB
 Metadata Space Used: 26.8 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.121 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.90 (2014-09-01)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.5.0-0.bpo.1-amd64
Operating System: Debian GNU/Linux 8 (jessie)
CPUs: 4
Total Memory: 15.56 GiB
Name: tungsten
ID: HJX5:TKIH:TF4G:JCQA:MHQB:YYUD:DHBL:53M7:ZRY2:OCIE:FHY7:NLP6

Estoy experimentando este problema al usar el controlador gráfico overlay , con el directorio en un ext4 FS. Entonces no creo que xfs sea ​​el problema 😢

@obeattie Sí, parece que la gente también lo está consiguiendo en devicemapper . Toque madera, no he vuelto a tener el problema desde que me cambié. Como se mencionó, también cambié el disco físico. ¡Este va a ser interesante!

Este problema no se correlaciona con el sistema de archivos de ninguna manera. He visto este problema con zfs, overlayfs, devicemapper, btrfs y aufs. También con o sin permuta. Ni siquiera se limita a la ventana acoplable, también encontré el mismo error con lxc. La única solución que veo actualmente es no detener el contenedor al mismo tiempo.

si ayuda, recibo el mismo mensaje de error en la última instancia ec2 respaldada por AWS AMI. muestra la versión de Docker

Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   a34a1d5/1.9.1
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   a34a1d5/1.9.1
 Built:
 OS/Arch:      linux/amd64

Solo subiendo a bordo. Veo el mismo comportamiento en la última instancia de Amazon ec2. Después de un período de tiempo, el contenedor simplemente se vuelca y deja de responder.

$ docker info
Contenedores: 2
Imágenes: 31
Versión del servidor: 1.9.1
Controlador de almacenamiento: devicemapper
Nombre del grupo: docker-202: 1-263705-pool
Tamaño del bloque de la piscina: 65.54 kB
Tamaño del dispositivo base: 107,4 GB
Sistema de archivos de respaldo:
Archivo de datos: / dev / loop0
Archivo de metadatos: / dev / loop1
Espacio de datos utilizado: 1.199 GB
Espacio de datos total: 107,4 GB
Espacio de datos disponible: 5.754 GB
Espacio de metadatos utilizado: 2.335 MB
Espacio total de metadatos: 2.147 GB
Espacio de metadatos disponible: 2.145 GB
Sincronización Udev compatible: verdadero
Eliminación diferida habilitada: falso
Eliminación diferida habilitada: falso
Recuento de dispositivos eliminados diferidos: 0
Archivo de bucle de datos: / var / lib / docker / devicemapper / devicemapper / data
Archivo de bucle de metadatos: / var / lib / docker / devicemapper / devicemapper / metadata
Versión de la biblioteca: 1.02.93-RHEL7 (28/01/2015)
Controlador de ejecución: native-0.2
Controlador de registro: archivo json
Versión de Kernel: 4.4.10-22.54.amzn1.x86_64
Sistema operativo: Amazon Linux AMI 2016.03
CPU: 1
Memoria total: 995,4 MiB
Nombre: [redactado]
ID: OB7A: Q6RX: ZRMK: 4R5H : ZUQY: BBNK : BJNN: OWKS : FNU4: 7NI2: AKRT: 5SEP

$ versión docker
Cliente:
Versión: 1.9.1
Versión de API: 1.21
Go versión: go1.4.2
Confirmación de Git: a34a1d5 / 1.9.1
Construido:
SO / Arch: linux / amd64

Servidor:
Versión: 1.9.1
Versión de API: 1.21
Go versión: go1.4.2
Confirmación de Git: a34a1d5 / 1.9.1
Construido:
SO / Arch: linux / amd64

Igual que los comentarios anteriores, también se ejecuta en EC2 a través de elástico beanstalk usando 64bit Amazon Linux 2016.03 v2.1.0 running Docker 1.9.1

Algo anecdótico en este momento, pero recientemente intenté actualizar del kernel 4.2.0 al 4.5.5 en alrededor de 18 servidores como prueba, y este problema empeoró considerablemente (de varios días a no más de 4 horas entre problemas).

Esto fue en Debian 8

Exactamente la misma configuración que @jonpaul y @ g0ddard

Buscando ver cómo podríamos mitigar este error.
Lo primero (que puede funcionar o no, es arriesgado) es mantener la API disponible en los casos en que esto ocurra: # 23178

Hola. También me ha picado este error ...

Jun 08 17:30:40 node-0-vm kernel: unregister_netdevice: waiting for veth846b1dc to become free. Usage count = 1

Estoy usando Kubernetes 1.2.4 en CoreOS Beta, Flannel y ejecutándome en Azure. ¿Hay alguna forma de ayudar a depurar este problema? El hilo de error del kernel parece muerto. Algunas personas informan que deshabilitar IPv6 en el kernel, usar --userland-proxy=true o usar aufs en lugar de la ayuda de almacenamiento superpuesto, mientras que otras no ... Es un poco confuso.

Como @ justin8 , también noté esto después de actualizar mi sistema Fedora 23 al kernel 4.5.5; el problema persiste con el kernel 4.5.6.

Encontramos este error cuando el contenedor alcanzaba su límite de memoria. No estoy seguro de si está relacionado o no.

mismo problema aquí

# docker version
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      linux/amd64

 # docker info
Containers: 213
Images: 1232
Server Version: 1.9.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 1667
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.19.0-5-exton
Operating System: Debian GNU/Linux 7 (wheezy)
CPUs: 4
Total Memory: 21.58 GiB
Name: [redacted]

Message from syslogd@[redacted] at Jun 24 10:07:54 ...
 kernel:[1716405.486669] unregister_netdevice: waiting for lo to become free. Usage count = 2

Message from syslogd@[redacted] at Jun 24 10:07:56 ...
 kernel:[1716407.146691] unregister_netdevice: waiting for veth06216c2 to become free. Usage count = 1

centos7.2
Docker 1.10.3
el mismo problema

Tengo "una línea" que eventualmente reproducirá este problema para mí en un EC2 (m4.large) que ejecuta CoreOS 1068.3.0 con el kernel 4.6.3 (muy reciente). Para mí, se necesitan alrededor de 300 iteraciones, pero YMMV.

Linux ip-172-31-58-11.ec2.internal 4.6.3-coreos # 2 SMP Sáb 25 de junio 00:59:14 UTC 2016 x86_64 CPU Intel (R) Xeon (R) E5-2676 v3 @ 2.40GHz GenuineIntel GNU / Linux
CoreOS beta (1068.3.0)
Docker versión 1.10.3, compilación 3cd164c

Unos cientos de iteraciones del bucle aquí eventualmente colgarán dockerd y el kernel emitirá mensajes de error como

kernel: unregister_netdevice: waiting for veth8c7d525 to become free. Usage count = 1

El bucle reproductor es

i=0; while echo $i && docker run --rm -p 8080 busybox /bin/true && docker ps; do sleep 0.05; ((i+=1)); done

EDICIONES

• Solo pude reproducir esto cuando userland-proxy=false
• NO he podido reproducir usando VirtualBox (solo ec2 hasta ahora), así que tal vez también esté relacionado con el hipervisor

El script de @btalbot , arriba, no reproduce el problema para mí en Fedora 23 después de varios miles de iteraciones.

$ docker --version
Docker version 1.10.3, build f476348/1.10.3
$ docker info
Containers: 3
 Running: 0
 Paused: 0
 Stopped: 3
Images: 42
Server Version: 1.10.3
Storage Driver: devicemapper
 Pool Name: docker_vg-docker--pool
 Pool Blocksize: 524.3 kB
 Base Device Size: 107.4 GB
 Backing Filesystem: xfs
 Data file: 
 Metadata file: 
 Data Space Used: 17.69 GB
 Data Space Total: 73.67 GB
 Data Space Available: 55.99 GB
 Metadata Space Used: 5.329 MB
 Metadata Space Total: 130 MB
 Metadata Space Available: 124.7 MB
 Udev Sync Supported: true
 Deferred Removal Enabled: true
 Deferred Deletion Enabled: true
 Deferred Deleted Device Count: 0
 Library Version: 1.02.109 (2015-09-22)
Execution Driver: native-0.2
Logging Driver: journald
Plugins: 
 Volume: local
 Network: bridge null host
Kernel Version: 4.5.7-200.fc23.x86_64
Operating System: Fedora 23 (Workstation Edition)
OSType: linux
Architecture: x86_64
Number of Docker Hooks: 0
CPUs: 4
Total Memory: 15.56 GiB
Name: <hostname>
ID: TOKW:AWJF:3VZU:55QA:V3KD:ZCA6:4XWW:JBY2:2Q5C:3S65:3ZXV:XRXG
Registries: docker.io (secure)

Este problema ocurre con bastante frecuencia en mi clúster de Kubernetes, sin embargo, no puedo reproducirlo de manera confiable con los factores estresantes o la línea única de @btalbot . Intenté ejecutarlo en dos máquinas virtuales de Azure con CoreOS 1068.3.0.

La primera VM fue una Standard_D1_v2 (3.5GB Ram, 1 core) - el script hizo> 3000 iteraciones.
La segunda máquina virtual era Standard_DS15_v2 (140 GB de RAM, 20 núcleos); el script tenía> 7600 iteraciones.

Actualicé mi comentario anterior (https://github.com/docker/docker/issues/5618#issuecomment-229545933) para incluir que solo puedo reproducirlo cuando userland-proxy = false.

Se reproduce para mí en EC2 t2.micro (un solo núcleo) VM, así como en m4.large (multi core), ambos usando HVM. Aún no lo he visto usar VirtualBox en mi computadora portátil, sin importar la configuración de userland-proxy.

Hemos encontrado este error al usar Flannel con hairpin-veth habilitado en el clúster de kubernetes (usando el proxy iptables). Este error estaba sucediendo solo cuando ejecutamos y detenemos demasiados contenedores. Pasamos a usar la red de puente cbr0 y el modo de horquilla de puente promiscuo y nunca lo volvemos a ver.
En realidad, es fácil reproducir este error si está usando hairpin-veth, simplemente comience este trabajo con 100 contenedores con kubernetes.

El 01/07/2016 08:01, manoj0077 escribió:

@btalbot https://github.com/btalbot así que con 1.12 podemos reiniciar
dockerd sin afectar a los contenedores en ejecución. Entonces dockerd reiniciaría
ayuda aquí en este caso?

AFAICT, evento con 1.12, los procesos de contenedores docker todavía son secundarios
del demonio docker.

@sercand ¿cómo estableciste el modo horquilla de puente promiscuo? No puedo ver ninguna documentación de Docker sobre eso, o tal vez estén usando un nombre diferente

¿Hay alguna noticia oficial de Docker 🐳 sobre cuándo se podría analizar esto? Este es el segundo tema abierto más comentado ; es muy grave (necesita un reinicio del host); es reproducible; y no veo ningún progreso real para determinar la causa raíz o solucionarlo 😞.

Esto parece más probable que sea un problema del kernel, pero el ticket en Bugzilla ha estado estancado durante meses. ¿Sería útil publicar nuestros casos de prueba allí?

@ justin8 Creo que esas son las banderas de Kubelet: --configure-cbr0 y --hairpin-mode

@sercand Yo también uso Flannel. ¿Existe alguna desventaja en el uso de --hairpin-mode=promiscuous-bridge ?

@obeattie estoy de acuerdo. :(

FTR Me las arreglé para replicar el problema usando el trabajo estresante de @sercand en un clúster de prueba de Kubernetes que configuré, también usa franela y horquilla-veth.

@sercand ¿Podría detallar los pasos para comenzar a usar promiscuous-bridge ? Agregué la bandera --configure-cbr0=true al kubelet del nodo pero se queja:
ConfigureCBR0 requested, but PodCIDR not set. Will not configure CBR0 right now . Pensé que se suponía que este PodCIDR venía del maestro. Gracias.

EDITAR: Parece que necesitaba agregar --allocate-node-cidrs=true --cluster-cidr=10.2.0.0/16 a la configuración del administrador del controlador, pero como no tengo un proveedor en la nube (Azure), las rutas probablemente no funcionarán.

@ justin8 He seguido este documento .
@edevil del modo de horquilla de la documentación es para "Esto permite que los puntos finales de un Servicio se equilibren a sí mismos si intentan acceder a su propio Servicio". Por cierto, mi clúster se ejecuta en Azure y no fue una tarea fácil de lograr.

@sercand De acuerdo con el documento, si usamos --allocate-node-cidrs=true en el administrador del controlador, se supone que debemos usar un proveedor en la nube para que configure las rutas. Dado que no existe un proveedor de nube de Kubernetes para Azure, ¿no ha tenido problemas? ¿Configura las rutas manualmente? Gracias.

@edevil Yo uso terraform para crear rutas. Puede encontrarlo en este repositorio . He creado rápidamente esta configuración y la he probado solo una vez. Espero que sea suficiente para proporcionar la lógica básica detrás de esto.

@morvans @btalbot, ¿tuviste la oportunidad de probar con 1.12 ...?

Puedo confirmar que alejándome de horquilla-veth y usando el puente cbr0 ya no puedo reproducir el problema.

Por si acaso: ¿alguien tiene este problema con el metal desnudo? Hemos visto esto cuando probamos el clúster de rancheros en nuestro laboratorio de VMWare, pero nunca lo vimos en una implementación real de bare metal.

Sí, este problema ocurre en bare metal para cualquier kernel> = 4.3. He visto esto en muchas máquinas y configuraciones de hardware diferentes. La única solución para nosotros fue usar el kernel 4.2.

Definitivamente todavía sucede en 4.2, pero es un orden de magnitud más a menudo en cualquier versión más nueva, he estado probando cada versión importante para ver si es mejor, y aún no hay nada.

También ocurre en CoreOS alpha 1097.0.0.

Núcleo: 4.6.3
Docker: 1.11.2

Tengo el mismo problema.

Docker: 1.11.2
Kernel: 4.4.8-boot2docker.

Host: máquina Docker con controlador VMWare Fusion en OS X.

¿Alguna solución alternativa sugerida?

Sería realmente útil si aquellos de ustedes que pueden reproducir el problema de manera confiable en un entorno donde es posible un crashdump (también conocido como EC2) pudieran de hecho compartir este archivo crashdump, se puede encontrar más información sobre cómo habilitar kdump en ubuntu trusty aquí y estas son las opciones de bloqueo que necesita habilitar cuando kdump esté listo para generar un crashdump:

echo 1 > /proc/sys/kernel/hung_task_panic          # panic when hung task is detected
echo 1 > /proc/sys/kernel/panic_on_io_nmi          # panic on NMIs from I/O
echo 1 > /proc/sys/kernel/panic_on_oops            # panic on oops or kernel bug detection
echo 1 > /proc/sys/kernel/panic_on_unrecovered_nmi # panic on NMIs from memory or unknown
echo 1 > /proc/sys/kernel/softlockup_panic         # panic when soft lockups are detected
echo 1 > /proc/sys/vm/panic_on_oom                 # panic when out-of-memory happens

El crashdump realmente puede ayudar a los desarrolladores del kernel a encontrar más información sobre la causa de la fuga de referencia, pero tenga en cuenta que un crashdump también incluye un volcado de memoria de su host y puede contener información sensible.

... información sensible.

: o

Me encuentro con el mismo problema.

Jul 13 10:48:34 kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1

Linux 4.6.3-1.el7.elrepo.x86_64
Docker: 1.11.2

Mismo problema:

Ubuntu 14.04.4 LTS (GNU/Linux 3.19.0-25-generic x86_64)

Docker version: 1.10.3

Simplemente sucedió directamente en la pantalla del terminal:

Message from syslogd<strong i="6">@svn</strong> at Jul 26 21:47:38 ...
 kernel:[492821.492101] unregister_netdevice: waiting for lo to become free. Usage count = 2

Message from syslogd<strong i="7">@svn</strong> at Jul 26 21:47:48 ...
 kernel:[492831.736107] unregister_netdevice: waiting for lo to become free. Usage count = 2

Message from syslogd<strong i="8">@svn</strong> at Jul 26 21:47:58 ...
 kernel:[492841.984110] unregister_netdevice: waiting for lo to become free. Usage count = 2

el sistema es

Linux svn.da.com.ar 4.4.14-24.50.amzn1.x86_64 #1 SMP Fri Jun 24 19:56:04 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

El mismo problema

Os: Amazon Linux AMI release 2016.03
Docker: 1.9.1

Aqui tambien:

Linux 4.4.14-24.50.amzn1.x86_64 x86_64
Docker version 1.11.2, build b9f10c9/1.11.2

Veo el mismo problema en EC2:

Docker version 1.11.2, build b9f10c9/1.11.2
NAME="Amazon Linux AMI"
VERSION="2016.03"
ID="amzn"
ID_LIKE="rhel fedora"
VERSION_ID="2016.03"
PRETTY_NAME="Amazon Linux AMI 2016.03"
CPE_NAME="cpe:/o:amazon:linux:2016.03:ga"
HOME_URL="http://aws.amazon.com/amazon-linux-ami/"

 kernel:[154350.108043] unregister_netdevice: waiting for lo to become free. Usage count = 1

(en todos mis pty + beeper cuando esto sucede)
Backports "simplemente" de Debian Jessie +:

Linux 4.6.0-0.bpo.1-amd64 #1 SMP Debian 4.6.1-1~bpo8+1 (2016-06-14) x86_64 GNU/Linux
Docker version 1.12.0, build 8eab29e

Hola,

Cuando trato de replicar el problema en un entorno controlado mediante la creación de nuevas imágenes que destruyen, no puedo reproducirlo.

El problema se ha planteado en uno de los servidores que ejecutan Docker 1.9.1.

 docker info | egrep "Version|Driver"
Server Version: 1.9.1
Storage Driver: devicemapper
 Library Version: 1.02.93 (2015-01-30)
Execution Driver: native-0.2
Logging Driver: gelf
Kernel Version: 4.5.0-coreos-r1

Al mismo tiempo almorcé el contenedor 17753 hasta ahora en modo concurrente y aumentando el tráfico a Internet, sin filtrar nada de la interfaz veth *. ¿Alguien puede pegar instrucciones para reproducir el problema de forma coherente?

@pegerto Debería ser bastante fácil de activar si tiene --userland-proxy=false y activa un montón de contenedores al mismo tiempo. Hago esto usando https://github.com/crosbymichael/docker-stress

Gracias @ cpuguy83

Configurando el demonio para que tenga --userland-proxy=false Puedo reproducir fácilmente el problema, gracias, podemos ver que este problema afecta a los demonios que no ejecutan esta configuración.

Veo un volcado de kernel en el gancho de netfilter introducido por la segregación de netns en> = 4.3, ¿alguna idea de por qué el problema parece peor cuando la ruta ocurre en 127/8?

Gracias

Viendo este problema también. CoreOS 1068.8.0, Docker 1.10.3, kernel 4.6.3. Saqué algunos de los registros del sistema si alguien estaba interesado.

Acabo de tener múltiples ...
unregistered_netdevice: waiting for lo to become free. Usage count = 1
... en 2 VM y en mi portátil baremetal, todos ejecutando Ubuntu 16.04 y los últimos kernels (4.4.0-3 [456]).

El resultado es que todo se cuelga y requiere un reinicio completo.
No había experimentado esto antes de la semana pasada y creo que una de las VM estaba en 1.11.3 mientras que las otras estaban todas en 1.12.0.

@RRAlex Esto no es específico de ninguna versión de Docker.
Si está usando --userland-proxy=false en las opciones del demonio ... O (por lo que tengo entendido) está usando kubernetes, probablemente encontrará este problema.

La razón es que la opción --userland-proxy=false habilita NAT de horquilla en la interfaz del puente ... esto es algo que kubernetes también establece cuando configura la red para sus contenedores.

Ver esto en un nodo BYO usando Docker Cloud (y el agente de Docker Cloud).

Vi esto hoy, una vez (de aproximadamente 25 intentos) en las AMI actuales de Amazon ECS, ejecutando vanilla debian: jessie con un comando que apt-get actualiza, instala pbzip2 y luego lo ejecuta (prueba de CPU multiproceso simple).

@ diablo
La mayoría de ustedes aquí describen que se encuentran con esta situación mientras usan Docker para iniciar / detener contenedores, pero yo obtuve exactamente la misma situación sin Docker, en Debian:

• Debian "Jessie" (= Debian versión 8.5), en baremetal (sin VM, sin nube, pero con hardware simple)
• kernel 3.16.0-4-amd64
• tener 4 contenedores LXC en marcha
• cierre un contenedor LXC con "lxc-stop -n $ containerName"
• cuando este comando se completa, el kernel o las interfaces probablemente no estén completamente 'limpiadas' todavía, porque cuando inmediatamente después del "lxc-stop" anterior lanzo un nuevo "lxc-stop", entonces tengo el problema del kernel

No hay forma de recuperarse excepto un restablecimiento completo de la máquina.

Por lo tanto, en sus investigaciones para identificar / resolver este problema, no se centre solo en Docker. Es obvio un problema genérico con paradas / inicios rápidos de contenedores, ya sea a través de Docker o mediante comandos "lxc" simples.

Creo que este es un problema del kernel de Linux.

Encontré este problema cuando tengo 3 chroot (de hecho, pbuilder) ejecutándose con una carga muy pesada.
Mi hardware es Loongson 3A (una máquina mips64el con kernel 3.16).

Cuando estoy tratando de entrar en él, encontré este problema.

Por lo tanto, este problema puede no solo sobre docker o lxc, sino incluso sobre chroot.

Docker versión 1.11.2.

kernel:[3406028.998789] unregister_netdevice: waiting for lo to become free. Usage count = 1

cat /etc/os-release 
NAME=openSUSE
VERSION="Tumbleweed"
VERSION_ID="20160417"
PRETTY_NAME="openSUSE Tumbleweed (20160417) (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:20160417"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
ID_LIKE="suse"

uname -a
Linux centre 4.5.0-3-default #1 SMP PREEMPT Mon Mar 28 07:27:57 UTC 2016 (8cf0ce6) x86_64 x86_64 x86_64 GNU/Linux

Metal básico.

Últimamente tuvimos el problema en bare metal (dedicado en ovh) con kernel 4.6.xy docker 1.11.2.
Después de leer los comentarios aquí y probar varias soluciones alternativas, degradamos nuestro kernel a la última versión de la rama 3.14 (3.14.74) y actualizamos la ventana acoplable a 1.12.0 para evitar https://github.com/docker/libnetwork/issues/1189 y todo parece estar bien por ahora.

Espero que esto pueda ayudar.

Todo, creo que ya no es necesario publicar mensajes sobre Docker o chroot, se trata del kernel de Linux.
Entonces, por favor, ¿alguien puede ponerse de pie que pueda depurar de alguna manera el kernel, en las partes donde está deshabilitando las interfaces de red virtual para los contenedores? Tal vez se produzcan algunas condiciones de carrera cuando una parada anterior de un contenedor aún no desactivó / limpió por completo su interfaz virtual, antes de que se solicite una nueva parada de un contenedor.

@rdelangh No creo que ese problema esté necesariamente relacionado con el kernel.

En Fedora 24, no puedo reproducir el problema con Docker 1.10.3 desde los repositorios de Fedora, solo con Docker 1.12.1 desde los repositorios propios de Docker.

Ambas pruebas se realizaron con el kernel 4.6.7-300.fc24.x86_64.

Al ver este problema también en CoreOS 1068.10.0, Docker 1.10.3, kernel 4.6.3.

kernel: unregister_netdevice: waiting for veth09b49a3 to become free. Usage count = 1

Usando Kubernetes 1.3.4 en CoreOS 1068.9.0 estable en EC2, Docker 1.10.3 Veo este problema.

unregister_netdevice: waiting for veth5ce9806 to become free. Usage count = 1
unregister_netdevice: waiting for veth5ce9806 to become free. Usage count = 1
unregister_netdevice: waiting for veth5ce9806 to become free. Usage count = 1
...
uname -a
Linux <redacted> 4.6.3-coreos #2 SMP Fri Aug 5 04:51:16 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz GenuineIntel GNU/Linux

Al ver este problema también en Ubuntu 16.04, Docker 1.12.1, kernel 4.4.0-34-generic
waiting for lo to become free. Usage count = 1

$ time docker ps
CONTAINER ID        IMAGE                                                                       COMMAND                  CREATED             STATUS                             PORTS                                                                          NAMES

...

real    4m40.943s
user    0m0.012s
sys     0m0.004s

Para aquellos que usan Kubernetes <= 1.3.4, pueden aprovechar este problema: https://github.com/kubernetes/kubernetes/issues/30899 para reproducir este problema. Ejecuté un pequeño clúster con 1 controlador (m4.large) y 2 trabajadores (m4.large) en CoreOS 1068.10.

Desde allí, puede crear 2 ReplicationControllers, los llamé hello y hello1 función de esto: http://pastebin.com/mAtPTrXH . Asegúrese de cambiar los nombres y las etiquetas para que sean diferentes.

Luego, cree 2 implementaciones que coincidan con los mismos nombres / etiquetas que las anteriores basándose en esto: http://pastebin.com/SAnwLnCw .

_Tan pronto como cree las implementaciones, obtendrá una gran cantidad de contenedores de spam_.

Si lo deja encendido por un tiempo (varios minutos), verá muchas cosas tratando de terminar / crear. Puede eliminar las implementaciones y dejar que las cosas se estabilicen. Debería ver un buen puñado de Terminating y ContainerCreating. Si ingresa a los nodos, verifique dmesg y docker ps para ver si los síntomas anteriores son evidentes.

En mi caso, me tomó unos 5 minutos dejar que esto se asuste antes de ver el problema. Planeo hacer los cambios con los que @sercand y @edevil estaban jugando y ver si esto funciona para mí en este caso.

@edevil Después de ver su compromiso vinculado, ¿tengo razón en que deshabilitó / eliminó Flannel en su entorno por completo a favor del puente cbro creado por Kubernetes para superar este problema?

Por mi parte, veo que no podría usarlos en conjunto porque Flannel quiere usar docker0 y su red interna funcionaría en cbr0 ¿correcto?

@ alph486 eso es correcto, dejé de usar franela. Utilizo el puente y configuro las rutas para la red de pod.

@ alph486 flannel no quiere usar docker0. Es solo el puente predeterminado para la ventana acoplable, que puede anular con la opción de ventana acoplable --bridge=cbr0 .
En CoreOS, tendría que anular la unidad docker systemd.

La bandera de Kubelet --experimental-flannel-overlay puede leer la configuración de franela y configurar el puente docker cbr0 con el CIDR de franela.

También habilitará el modo promiscuous lugar de veth-hairpin que parece ser el problema.

Gracias @dadux por la entrada. Si K8s recogerá la interfaz cbr0 que ya ha sido iniciada por la unidad anulada, podría estar en el negocio con esa solución; Lo intentaré.

Según los documentos, promiscuous-bridge parece ser el valor predeterminado para --hairpin-mode en kubelet v1.3.4 +. Sigo viendo el problema con esto, así que no estoy del todo seguro de que esa sea la solución completa.

No he podido reproducir el problema nuevamente después de usar el complemento de red kubenet (que está configurado para reemplazar --configure-cbr0 ). Estoy evitando la opción flannel-overlay debido a la incertidumbre de su futuro (parece estar ligada a --configure-cbr0 ).

Si su demonio docker usa el puente docker0 , la configuración de --hairpin-mode=promiscuous-bridge no tendrá ningún efecto ya que el kubelet intentará configurar el puente no existente cbr0 .

Para CoreOS, mi solución para reflejar el comportamiento de Kubernetes pero aún usando franela:

• Agregue un drop-in systemd para docker.service para configurar el puente docker0 interfaz en modo promiscuo. (¿Seguro que hay alguien más elegante que quiera hacer esto?):

- name: docker.service
  command: start
  drop-ins:
   - name: 30-Set-Promiscuous-Mode.conf
     content: |
       [Service]
       ExecStartPost=/usr/bin/sleep 5
       ExecStartPost=/usr/bin/ip link set docker0 promisc on

• Dígale al kubelet que no coloque una horquilla en el puente de la ventana acoplable:
  kubelet --hairpin-mode=none

Puede comprobar si la horquilla está habilitada para sus interfaces con
brctl showstp docker0
o
for f in /sys/devices/virtual/net/*/brport/hairpin_mode; do cat $f; done

Creo que mi colega ha solucionado esto recientemente http://www.spinics.net/lists/netdev/msg393441.html , encontramos este problema en nuestro entorno y luego encontramos el problema, con esta solución, nunca encontramos este problema. más. Cualquiera que haya encontrado este problema, podría probar este parche y ver si vuelve a suceder. Y a partir de nuestro análisis, se relaciona con ipv6, por lo que también puede intentar deshabilitar ipv6 de la ventana acoplable con --ipv6=false al iniciar el demonio de la ventana acoplable.

@ coolljt0725 Tal vez me equivoque, pero ipv6 está deshabilitado de forma predeterminada en la ventana acoplable y acabo de reproducir el problema a través de docker-stress con la opción "--ipv6 = false" (que es la predeterminada de todos modos). Aún no probé el parche.

@dadux Gracias por su ayuda. En Kubernetes 1.3.4 CoreOS 1068 Stable, Docker 10.3, Flannel como capa de red, solucioné el problema realizando los siguientes cambios en mis unidades CoreOS:

    - name: docker.service
      drop-ins:
        - name: 30-Set-Promiscuous-Mode.conf
          content: |
            [Service]
            ExecStartPost=/usr/bin/sleep 5
            ExecStartPost=/usr/bin/ip link set docker0 promisc on

Se agregó lo siguiente a kubelet.service :

        --hairpin-mode=none

¿Qué efecto tienen estos cambios en Docker / Kubernetes con respecto a cómo el O / S maneja las interfaces para contenedores?
Debo enfatizar que es un problema con el comportamiento incorrecto de O / S, no Docker o Kubernetes, porque nosotros (y algunas otras personas en este hilo) no estamos ejecutando Docker o Kubernetes, pero aún nos encontramos exactamente con las mismas situaciones al detener LXC contenedores con bastante rapidez uno tras otro.

@rdelangh Tienes razón. Sin embargo, este problema se creó en el proyecto de Docker para realizar un seguimiento del comportamiento en lo que respecta a Docker. Hay otros problemas mencionados en este hilo que lo rastrean como un problema del sistema operativo, un problema de K8s y un problema de CoreOS. Si ha encontrado el problema en LXC o en algo más, le recomiendo encarecidamente que inicie un hilo allí y enlace aquí para crear conciencia sobre el problema.

Cuando aquellos que usan Docker google para este error, probablemente aterrizarán aquí. Por lo tanto, tiene sentido que publiquemos soluciones a este problema aquí para que, hasta que se solucionen los problemas subyacentes, la gente pueda seguir adelante.

¿Qué efecto tienen estos cambios en Docker / Kubernetes con respecto a cómo el O / S maneja las interfaces para contenedores?

1. El cambio de la ventana acoplable en mi publicación permite que la pila de Kubernetes interrogue a la ventana acoplable y se asegure de que la plataforma esté en buen estado cuando se produzca el problema.
2. el cambio hairpin-mode esencialmente le dice a K8s que use el puente docker0 tal cual, y por lo tanto no intentará usar la red "kernel land" y "hairpin veth" que es donde comienza el problema en el Docker ruta de ejecución.

Es una solución para este problema con K8s y Docker.

El parche de coolljt0725 colegas se ha puesto en cola para que sea estable, por lo que es de esperar que se vuelva a exportar a las distribuciones lo suficientemente pronto. (Publicación de David Miller: http://www.spinics.net/lists/netdev/msg393688.html)

Sin embargo, ¿no estás seguro de dónde está esa confirmación y si deberíamos enviarla a Ubuntu, RH, etc. para ayudarlos a rastrearla y exportarla?

Voy a aparecer aquí en algún momento, supongo:
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/ipv6/addrconf.c

EDITAR: parece estar presente aquí: https://github.com/torvalds/linux/blob/master/net/ipv6/addrconf.c

Gracias a coolljt0725 y compañía (y a todos en este hilo). Dado que muchas personas no podrán actualizar a un kernel con el parche ipv6 durante algún tiempo, (todos, actualmente) he logrado eliminar este error después de probar muchas de las sugerencias de este hilo. Quiero hacer una publicación completa para hacer un seguimiento de las cosas que funcionaron y no funcionaron para que nadie más tenga que ver el problema que vi.

TL; DR deshabilita ipv6 en linux boot params, reinicia. en coreos esto significa que /usr/share/oem/grub.cfg tiene el contenido: set linux_append="ipv6.disable=1" y luego un reinicio. una sugerencia de propósito más general que debería funcionar en centos / ubuntu / debian / $ linuxes se puede encontrar aquí

• probé ipvlan (l2, l3) / macvlan (bridge): ninguno de estos funciona en aws, o al menos, no poseo ni pude encontrar el conocimiento para hacer que ninguno de ellos trabaje en aws. por trabajo, quiero decir, al iniciar un contenedor adjunto en una red con ipvlan o macvlan, no pude hacer ping a la puerta de enlace / conectarse a Internet (sí, probé la idea básica trabajando en un entorno que no es aws). De hecho, esto pareció resolver el problema en cuestión, pero para nuestro caso de uso, necesitamos poder conectarnos a Internet; para los casos de uso que no lo hacen, esta puede ser una opción viable y parece bastante sexy en comparación con el puente. .
• probé las siguientes banderas pasadas a dockerd individualmente, y con ciertas combinaciones (dado que ninguna de ellas parecía funcionar, no era demasiado científico para probar todas y cada una de las combinaciones):

--ipv6=false
—iptables=false
—ip-forward=false
—icc=false
—ip-masq=false
—userland-proxy=false

Curiosamente, --ipv6=false realmente no parece hacer nada ; esto fue bastante desconcertante, los contenedores aún recibían direcciones inet6 con esta bandera.

--userland-proxy=false establece el modo horquilla y no se esperaba que funcionara realmente. junto con esto , tenía algo de esperanza, pero esto tampoco resolvió el problema (configurando docker0 en modo promisc). Hay una mención de una solución a --userland-proxy=false aquí y esto puede ser upstream pronto y vale la pena intentarlo de nuevo, sería bueno desactivarlo independientemente del error observado en este problema para el rendimiento, pero desafortunadamente tiene otro error en este momento.

• intenté deshabilitar ipv6 a través de la configuración de sysctl como se documenta aquí y reiniciar systemd-networkd después de aplicar la configuración de sysctl, así como intentar deshabilitar ipv6 de dhcpcd como se documenta aquí y esto no fue suficiente para deshabilitar ipv6 ya que todavía está encendido, incluso si no hay interfaces usándolo.
• como se sugirió aquí, probamos esta solución, solo eliminando un contenedor a la vez, y todavía nos encontramos con este error.

demasiado largo; leyó: deshabilite ipv6 en la configuración de grub. reiniciar. lucro.

Enfrenté este problema en CentOS 7.2 (3.10.0-327.28.3.el7.x86_64) y Docker 1.12.1 (sin k8s). El problema surge cuando aumenta el tráfico de la red.
Arrancar el kernel con ipv6 deshabilitado (según el consejo anterior) no ayudó.
Pero convertir la interfaz docker0 en modo promisc ha solucionado esto. Systemd drop-in usado por

@rdallman Desactivar ipv6 a través de grub no me impide unregister_netdevice en ubuntu 16.06 (kernel 4.4.0-36-generic) o 14.04 (kernel 3.13.0-95-generic). Independientemente de la configuración --userland-proxy (verdadero o falso).

Ooooh, es genial que el parche esté en la cola de espera.
ping @aboch por el problema de que --ipv6=false no hace nada.

@trifle sorry :( gracias por publicar información, todavía tenemos problemas después de unos días de prueba, pero actualizaremos si tenemos algún problema. Estamos ejecutando coreos 1122.2 (kernel 4.7.0). configurando docker0 en modo promisc parece solucionar este problema para algunas personas (sin suerte para nosotros).

@RRAlex ¿Sabe si alguien se ha comunicado con el equipo del kernel de Ubuntu con respecto a un backport? Tenemos una gran implementación de Docker de producción en un clúster de Ubuntu que se ve afectado por el error.

Lista de correo del equipo del kernel de Ubuntu:
https://lists.ubuntu.com/archives/kernel-team/2016-September/thread.html

Parche para el kernel estable:
https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d

Registro de confirmación del kernel de Ubuntu:
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/?h=master-next
(El parche aún no está allí)

@leonsp Intenté ponerme en contacto con ellos sobre lo que parece ser el problema relacionado:
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1403152

Si miras la última respuesta (# 79), alguien construyó un kernel para Xenial con ese parche:
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1403152

Sin embargo, no estoy seguro de cuándo se incluirá en el árbol principal del kernel de Ubuntu ni cuál es la relación de esta persona con Ubuntu y si eso ayudará ...

Tampoco puedo encontrar las confirmaciones mencionadas de ese hilo en el registro de confirmación del kernel de Ubuntu.

@RRAlex Las confirmaciones mencionadas están en la rama de ddstreet ~ ddstreet / + git / linux: lp1403152-xenial , aquí está el registro: https://code.launchpad.net/~ddstreet/+git/linux/+ref/lp1403152-xenial
Entonces, cualquier persona con este problema en Ubuntu 16.04 puede intentarlo. https://launchpad.net/~ddstreet/+archive/ubuntu/lp1403152

Posiblemente @sforshee lo sabe (para el kernel de Ubuntu)

Finalmente logré probar la solución "ipv6.disable = 1". Además de eso, he actualizado al kernel 4.7.2 en mi debian 8.
Después de actualizar el kernel y habilitar "ipv6.disable = 1" en los parámetros del kernel, me las arreglé para detectar el problema "esperando lo" en la carga de trabajo real incluso sin el indicador "--userland-proxy = false" para el demonio de la ventana acoplable. La buena noticia es que después de especificar "--userland-proxy = false" e intentar reproducir el problema con "docker-stress", ya no puedo hacer eso. Pero estoy bastante seguro de que volverá a surgir independientemente del valor "--userland-proxy".
Entonces, por lo que veo, el ipv6 definitivamente está involucrado en este problema, porque ahora docker-stress ya no puede detectar el problema. La mala noticia es que el problema sigue ahí (es decir, se ha solucionado solo parcialmente).

Compilará el último 4.8rc7 más tarde para probar más.

@ twang2218 @ coolljt0725

Hmmm ... así que acabo de probar el kernel Ubuntu xenial 4.4.0-36 con el parche exportado desde ddstreet :

$ uname -a
Linux paul-laptop 4.4.0-36-generic #55hf1403152v20160916b1-Ubuntu SMP Fri Sep 16 19:13:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Desafortunadamente, esto no parece resolver el problema para mí. Tenga en cuenta que también estoy ejecutando "ipv6.disable = 1". ¿Estamos analizando múltiples causas no relacionadas con el mismo resultado? Muchos de los comentarios en este hilo parecen sugerirlo.

No sé mucho sobre estos, pero sé que hemos tenido errores como este antes. Según tengo entendido, los recuentos de referencias a cualquier dispositivo de red terminan siendo transferidos a lo cuando se está limpiando un espacio de nombres de red, por lo que "esperar a que lo se libere" significa que hay una fuga de recuento de referencias para algún dispositivo de red, pero no necesariamente para lo directamente. Eso hace que sea difícil rastrearlos, porque cuando sabes que hubo una fuga, no sabes con qué dispositivo estaba asociado.

No he leído todos los comentarios, pero si alguien me puede dar un reproductor confiable en Ubuntu, lo echaré un vistazo y veré si puedo resolver algo.

@sforshee no siempre es fácil de reproducir, pero se creó un parche (que al menos corrige algunos de los casos reportados aquí); http://www.spinics.net/lists/netdev/msg393441.html. Eso fue aceptado en sentido ascendente https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d

@thaJeztah ah, veo la pregunta a la que me

Entonces, el parche está en la cola estable de la versión 4.4, para 16.04 es probable que no se incluya en la próxima SRU del kernel (que ya está en progreso) sino en la siguiente, dentro de unas 5-6 semanas a partir de ahora. Si también es necesario en la versión 14.04, hágamelo saber para que pueda ser transferido.

@sforshee básicamente antes (antes de ese parche) que podría reproducirse habilitando ipv6 en el kernel (generalmente habilitado de forma predeterminada), agregando "--userland-proxy = false" a las banderas del demonio de la ventana acoplable y luego ejecutando docker-stress -c 100 , para ejemplo (docker-stress es de aquí: https://github.com/crosbymichael/docker-stress)

@fxposter gracias. Si hay una solución para eso, todo lo que realmente debo preocuparme es obtener esa solución en el kernel de Ubuntu. También puedo ayudar a buscar otras fugas que no hayan sido reparadas por ese parche.

Yo también tengo este problema. Estoy ejecutando Docker dentro de una caja rancherOS de AWS. En realidad, sucede de forma aleatoria después de configurar un grupo de ganaderos (3 hosts) y ejecutar una pequeña aplicación en él.

Lo mismo ... Fedora 24, sucede al azar, puede estar bien durante una semana, de lo que obtengo uno cada 10 horas
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Experimentar en CentOS 7 con kernel 3.10.0-327.36.1.el7 y Docker 1.12.1

La degradación al kernel 3.10.0-327.18.2.el7 mientras permanece en la ventana acoplable 1.12.1, parece haber estabilizado el sistema.

También veo esto:
Docker versión 1.11.2
Ubuntu 16.04.1 4.4.0-38-genérico

ipv6 deshabilitado (grub)

Acabo de tener este problema sin --userland-proxy=false (sic!) En el servidor con kernel 4.8.0-rc7, que incluye el parche ipv6 (sic !!). Entonces, tal vez solucione algunos de los problemas, pero no todos, definitivamente.

¿Alguien sabe cómo se puede depurar esto?

Descubrimos que esto solo ocurre en nuestra configuración cuando (casi) nos quedamos sin memoria libre.

@fxposter Sería útil encontrar un caso de reproducción mínima, lo cual es un poco difícil: / Entonces podríamos usar ftrace para al menos encontrar rutas de código.

Sucediendo en CoreOS 1081.5.0 (4.6.3-coreos)

Linux blade08 4.6.3-coreos #2 SMP Sat Jul 16 22:51:51 UTC 2016 x86_64 Intel(R) Xeon(R) CPU X5650 @ 2.67GHz GenuineIntel GNU/Linux

@ LK4D4 desafortunadamente ya no es posible reproducirlo a través de docker-stress (al menos no pude). Intentaré imitar nuestra configuración anterior con webkits (que desencadenó este problema con más frecuencia de lo que me gustaría).

@fxposter Ese parche solo soluciona algunos de los problemas (pero en nuestro entorno, nunca más lo encontramos con ese parche), no todos, dejaré que mi colega siga investigando este problema. Si tiene alguna forma de reproducir esto, hágamelo saber, gracias :)

La solución está en 4.4.22 estable https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.22

Publiqué una solicitud para que Redhat aplique este parche a Fedora 24.

https://bugzilla.redhat.com/show_bug.cgi?id=1379767#c1

4.4.0-42 todavía está roto con seguridad ...
Lo mencioné aquí para Ubuntu, pero tal vez alguien tenga una mejor idea:
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1403152

También estoy viendo esto, Docker versión 1.11.2, compilación b9f10c9 / 1.11.2, 64bit Amazon Linux 2016.03 v2.1.6.

todavía sucedió. docker 1.12.2, armbian linux kernel 4.8.4, ipv6.disable = 1 en bootargs

cómo arreglar el error, lo encuentro todos los días

@woshihaoren No uses --userland-proxy=false

Para aclarar, lo enfrentamos con userland-proxy deshabilitado también

Obteniendo esto en Amazon Linux AMI 2016.9:

$ uname -a

Linux 4.4.23-31.54.amzn1.x86_64 #1 SMP

Versión de Docker:

`` `Cliente:
Versión: 1.11.2
Versión de API: 1.23
Go versión: go1.5.3
Confirmación de Git: b9f10c9 / 1.11.2
Construido:
SO / Arch: linux / amd64

Servidor:
Versión: 1.11.2
Versión de API: 1.23
Go versión: go1.5.3
Confirmación de Git: b9f10c9 / 1.11.2
Construido:
SO / Arch: linux / amd64
''

centos7 kernel 4.4.30 de nuevo ~~~~

CoreOS 1185.3.0, 4.7.3-coreos-r2, Docker 1.11.2
Reproducible con solo ejecutar 10..20 contenedores debian: jessie con "apt-get update" como comando.

El estable de CoreOS todavía está afectado. La solución para la serie 4.7 está en 4.7.5: https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.7.5

commit 4e1b3aa898ea93ec10e48c06f0e511de37c35b2d
Author: Wei Yongjun <[email protected]>
Date:   Mon Sep 5 16:06:31 2016 +0800

    ipv6: addrconf: fix dev refcont leak when DAD failed

TL; DR : no hay soluciones en esta publicación, pero sí enumero lo que he perseguido hasta ahora y mis teorías de trabajo actuales. Espero que otras personas que también están persiguiendo esto encuentren útil alguna información aquí mientras analizamos esto.

@koendc Gracias por publicar el parche que se introdujo en 4.7.5. Me volver portado el 4e1b3aa898ea93ec10e48c06f0e511de37c35b2d (751eb6b6042a596b0080967c1a529a9fe98dac1d aguas arriba) de parches a mi configuración 4.5.5 [1] y fue capaz de reproducir fácilmente el problema unregister_netdevice. Es posible que otros cambios en el kernel 4.7.x funcionen junto con el parche proporcionado para resolver este problema, pero aún no lo he confirmado, por lo que no deberíamos perder toda la esperanza todavía. Estoy probando con 4.5.5 porque tengo un caso de prueba reproducible para causar el problema, discutido en [2].

Otras cosas que he confirmado según las pruebas:

• 4.2 es mucho más estable que cualquier kernel posterior
• 4.5.x es trivialmente reproducible. De los kernels más nuevos que he probado ampliamente (4.8.2 y 4.8.6), el problema aún existe, aunque el tiempo hasta la primera aparición osciló entre 60 y 48 horas.
• El problema parece correlacionarse tanto con el tráfico de red como con la relación entre contenedores y capacidad de recursos principales (virt cpu). Como otros han eludido, esto podría ser una pista falsa si se trata de una condición de carrera.

Próximos pasos:

• Instrumentar un kernel con las instrucciones de printk adecuadas para intentar encontrar un caso en el que los recursos asignados no se liberen
• Pruebe el kernel 4.7.5 o posterior con / sin el parche mencionado anteriormente para ver si ocurre el problema
• Justo antes de uno de los bloqueos, vi un conjunto muy interesante de errores IPv6: eth0: IPv6 duplicate address <blah> detected . Podría ser otra pista falsa, pero quiero intentar ejercitar la desactivación de ipv6 para ver si hay una correlación

[1] Mi configuración completa es una virtud de GCE que ejecuta un kernel de Debian ligeramente personalizado basado en 4.5.5 . Docker version 1.8.3, build f4bf5c7 está ejecutando además de eso
[2] Información del caso de prueba: tengo 20 procesos paralelos, cada uno inicia un servidor hello world de Node.js dentro de un contenedor docker. En lugar de devolver hello world , el servidor Node.js devuelve 1 MB de texto aleatorio. El proceso principal está en un ciclo cerrado que inicia el contenedor, se riza para recuperar el 1 MB de datos y detiene el contenedor. Con esta configuración, puedo reproducir el problema de forma coherente en 4-90 s. El uso de esta misma configuración en un host físico o dentro de la caja virtual no reproduce el problema, a pesar de los elementos variables que alteran el tiempo medio de reproducción en la caja GCE. Variables con las que he estado jugando: número de procesos de prueba simultáneos, tamaño de la carga útil transferida y cantidad de llamadas curl. Las dos primeras variables están definitivamente correlacionadas, aunque creo que es probable que solo se ajusten las variables para encontrar un punto de saturación razonable para la virtud.

Yo también tengo este error.

Lo veo repetido 3 veces después de desplegar un contenedor.

Descripción

kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Pasos para reproducir el problema:

1. ssh en el host de la ventana acoplable
2. ejecutar un contenedor

docker run -d --network=anetwork --name aname -p 9999:80 aimagename

Describe los resultados que recibiste:

Simplemente repita el error 3 veces.

Describe los resultados que esperabas:
No hay error

Información adicional que considere importante (por ejemplo, el problema ocurre solo ocasionalmente):
Comenzó a suceder después de este fin de semana.

Salida de docker version :

 docker --version
Docker version 1.12.3, build 6b644ec

Salida de docker info :

docker info
Containers: 10
 Running: 9
 Paused: 0
 Stopped: 1
Images: 16
Server Version: 1.12.3
Storage Driver: overlay2
 Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay null host bridge
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.8.4-200.fc24.x86_64
Operating System: Fedora 24 (Server Edition)
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 15.67 GiB
Name: docker-overlayfs
ID: AHY3:COIU:QQDG:KZ7S:AUBY:SJO7:AHNB:3JLM:A7RN:57CQ:G56Y:YEVU
Docker Root Dir: /docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Insecure Registries:
 127.0.0.0/8

Detalles adicionales del entorno (AWS, VirtualBox, físico, etc.):

Máquina virtual:
Fedora 24
OverlayFS2 en ext3

Unidad separada asignada para el uso de la ventana acoplable 24 gigas.
16 gigas de ram.

Docker PS

docker ps -a
CONTAINER ID        IMAGE                COMMAND                  CREATED             STATUS                      PORTS                                            NAMES
5664a10de50b        7f01d324a3cb         "/bin/sh -c 'apk --no"   11 minutes ago      Exited (1) 10 minutes ago                                                    pensive_brattain
3727b3e57e2f        paa-api              "/bin/sh -c /run.sh"     10 days ago         Up 10 days                  0.0.0.0:8080->80/tcp                             paa-api
43cfe7eae9cf        paa-ui               "nginx -g 'daemon off"   10 days ago         Up 10 days                  0.0.0.0:80->80/tcp, 443/tcp                      paa-ui
345eaab3b289        sentry               "/entrypoint.sh run w"   11 days ago         Up 11 days                  0.0.0.0:8282->9000/tcp                           my-sentry
32e555609cd2        sentry               "/entrypoint.sh run w"   11 days ago         Up 11 days                  9000/tcp                                         sentry-worker-1
a411d09d7f98        sentry               "/entrypoint.sh run c"   11 days ago         Up 11 days                  9000/tcp                                         sentry-cron
7ea48b27eb85        postgres             "/docker-entrypoint.s"   11 days ago         Up 11 days                  5432/tcp                                         sentry-postgres
116ad8850bb1        redis                "docker-entrypoint.sh"   11 days ago         Up 11 days                  6379/tcp                                         sentry-redis
35ee0c906a03        uifd/ui-for-docker   "/ui-for-docker"         11 days ago         Up 11 days                  0.0.0.0:9000->9000/tcp                           docker-ui
111ad12b877f        elasticsearch        "/docker-entrypoint.s"   11 days ago         Up 11 days                  0.0.0.0:9200->9200/tcp, 0.0.0.0:9300->9300/tcp   paa-elastic

Imágenes de docker

 docker images -a
REPOSITORY           TAG                 IMAGE ID            CREATED             SIZE
<none>               <none>              7f01d324a3cb        12 minutes ago      88.51 MB
<none>               <none>              1a6a12354032        12 minutes ago      88.51 MB
debian               jessie              73e72bf822ca        6 days ago          123 MB
paa-api              latest              6da68e510175        10 days ago         116.9 MB
<none>               <none>              4c56476ba36d        10 days ago         116.9 MB
<none>               <none>              3ea3bff63c7b        10 days ago         116.8 MB
<none>               <none>              05d6d5078f8a        10 days ago         88.51 MB
<none>               <none>              30f0e6001f1e        10 days ago         88.51 MB
paa-ui               latest              af8ff5acc85a        10 days ago         188.1 MB
elasticsearch        latest              5a62a28797b3        12 days ago         350.1 MB
sentry               latest              9ebeda6520cd        13 days ago         493.7 MB
redis                latest              74b99a81add5        13 days ago         182.9 MB
python               alpine              8dd7712cca84        13 days ago         88.51 MB
postgres             latest              0267f82ab721        13 days ago         264.8 MB
nginx                latest              e43d811ce2f4        3 weeks ago         181.5 MB
uifd/ui-for-docker   latest              965940f98fa5        9 weeks ago         8.096 MB

Volumen de Docker Ls

DRIVER              VOLUME NAME
local               3bc848cdd4325c7422284f6898a7d10edf8f0554d6ba8244c75e876ced567261
local               6575dad920ec453ca61bd5052cae1b7e80197475b14955115ba69e8c1752cf18
local               bf73a21a2f42ea47ce472e55ab474041d4aeaa7bdb564049858d31b538bad47b
local               c1bf0761e8d819075e8e2427c29fec657c9ce26bc9c849548e10d64eec69e76d
local               e056bce5ae34f4066d05870365dcf22e84cbde8d5bd49217e3476439d909fe44

* DF -H *

df -h
Filesystem               Size  Used Avail Use% Mounted on
devtmpfs                 7.9G     0  7.9G   0% /dev
tmpfs                    7.9G     0  7.9G   0% /dev/shm
tmpfs                    7.9G  1.3M  7.9G   1% /run
tmpfs                    7.9G     0  7.9G   0% /sys/fs/cgroup
/dev/mapper/fedora-root   11G  1.6G  8.7G  16% /
tmpfs                    7.9G  8.0K  7.9G   1% /tmp
/dev/sda1                477M  130M  319M  29% /boot
/dev/sdb1                 24G  1.6G   21G   7% /docker
overlay                   24G  1.6G   21G   7% /docker/overlay2/5591cfec27842815f5278112edb3197e9d7d5ab508a97c3070fb1a149d28f9f0/merged
shm                       64M     0   64M   0% /docker/containers/35ee0c906a03422e1b015c967548582eb5ca3195b3ffdd040bb80df9bb77cd32/shm
overlay                   24G  1.6G   21G   7% /docker/overlay2/73e795866566e845f09042d9f7e491e8c3ac59ebd7f5bc0ee4715d0f08a12b7b/merged
shm                       64M  4.0K   64M   1% /docker/containers/7ea48b27eb854e769886f3b662c2031cf74f3c6f77320a570d2bfa237aef9d2b/shm
overlay                   24G  1.6G   21G   7% /docker/overlay2/fad7f3b483bc48b83c3a729368124aaaf5fdd7751fe0a383171b8966959ac966/merged
shm                       64M     0   64M   0% /docker/containers/116ad8850bb1c74d1a33b6416e1b99775ef40aa13fc098790b7e4ea07e3e6075/shm
overlay                   24G  1.6G   21G   7% /docker/overlay2/456c40bc86852c9f9c9ac737741b57d30f2167882f15b32ac25f42048648d945/merged
shm                       64M     0   64M   0% /docker/containers/a411d09d7f98e1456a454a399fb68472f5129df6c3bd0b73f59236e6f1e55e74/shm
overlay                   24G  1.6G   21G   7% /docker/overlay2/3ee2b1b978b048f4d80302eec129e7163a025c7bb8e832a29567b64f5d15baa0/merged
shm                       64M     0   64M   0% /docker/containers/32e555609cd2c77a1a8efc45298d55224f15988197ef47411a90904cf3e13910/shm
overlay                   24G  1.6G   21G   7% /docker/overlay2/3e1cdabc2ae422a84b1d4106af1dde0cd670392bbe8a9d8f338909a926026b73/merged
shm                       64M     0   64M   0% /docker/containers/345eaab3b289794154af864e1d14b774cb8b8beac8864761ac84051416c7761b/shm
overlay                   24G  1.6G   21G   7% /docker/overlay2/6bfc33084abe688af9c1a704a0daba496bee7746052103ef975c76d2c74d6455/merged
shm                       64M     0   64M   0% /docker/containers/111ad12b877f4d4d8b3ab4b44b06f645acf89b983580e93d441305dcc7926671/shm
overlay                   24G  1.6G   21G   7% /docker/overlay2/0b454336447a39d06966adedf4dc4abed6405212107a2f8f326072ae5fb58b3d/merged
shm                       64M     0   64M   0% /docker/containers/43cfe7eae9cf310d64c6fe0f133152067d88f8d9242e48289148daebd9cb713d/shm
overlay                   24G  1.6G   21G   7% /docker/overlay2/0d8bba910f1f5e928a8c1e5d02cc55b6fe7bd7cd5c4d23d4abc6f361ff5043ac/merged
shm                       64M     0   64M   0% /docker/containers/3727b3e57e2f5c3b7879f

DF -i

 df -i
Filesystem               Inodes IUsed   IFree IUse% Mounted on
devtmpfs                2051100   411 2050689    1% /dev
tmpfs                   2054171     1 2054170    1% /dev/shm
tmpfs                   2054171   735 2053436    1% /run
tmpfs                   2054171    16 2054155    1% /sys/fs/cgroup
/dev/mapper/fedora-root 5402624 53183 5349441    1% /
tmpfs                   2054171     8 2054163    1% /tmp
/dev/sda1                128016   350  127666    1% /boot
/dev/sdb1               1572864 72477 1500387    5% /docker
overlay                 1572864 72477 1500387    5% /docker/overlay2/5591cfec27842815f5278112edb3197e9d7d5ab508a97c3070fb1a149d28f9f0/merged
shm                     2054171     1 2054170    1% /docker/containers/35ee0c906a03422e1b015c967548582eb5ca3195b3ffdd040bb80df9bb77cd32/shm
overlay                 1572864 72477 1500387    5% /docker/overlay2/73e795866566e845f09042d9f7e491e8c3ac59ebd7f5bc0ee4715d0f08a12b7b/merged
shm                     2054171     2 2054169    1% /docker/containers/7ea48b27eb854e769886f3b662c2031cf74f3c6f77320a570d2bfa237aef9d2b/shm
overlay                 1572864 72477 1500387    5% /docker/overlay2/fad7f3b483bc48b83c3a729368124aaaf5fdd7751fe0a383171b8966959ac966/merged
shm                     2054171     1 2054170    1% /docker/containers/116ad8850bb1c74d1a33b6416e1b99775ef40aa13fc098790b7e4ea07e3e6075/shm
overlay                 1572864 72477 1500387    5% /docker/overlay2/456c40bc86852c9f9c9ac737741b57d30f2167882f15b32ac25f42048648d945/merged
shm                     2054171     1 2054170    1% /docker/containers/a411d09d7f98e1456a454a399fb68472f5129df6c3bd0b73f59236e6f1e55e74/shm
overlay                 1572864 72477 1500387    5% /docker/overlay2/3ee2b1b978b048f4d80302eec129e7163a025c7bb8e832a29567b64f5d15baa0/merged
shm                     2054171     1 2054170    1% /docker/containers/32e555609cd2c77a1a8efc45298d55224f15988197ef47411a90904cf3e13910/shm
overlay                 1572864 72477 1500387    5% /docker/overlay2/3e1cdabc2ae422a84b1d4106af1dde0cd670392bbe8a9d8f338909a926026b73/merged
shm                     2054171     1 2054170    1% /docker/containers/345eaab3b289794154af864e1d14b774cb8b8beac8864761ac84051416c7761b/shm
overlay                 1572864 72477 1500387    5% /docker/overlay2/6bfc33084abe688af9c1a704a0daba496bee7746052103ef975c76d2c74d6455/merged
shm                     2054171     1 2054170    1% /docker/containers/111ad12b877f4d4d8b3ab4b44b06f645acf89b983580e93d441305dcc7926671/shm
overlay                 1572864 72477 1500387    5% /docker/overlay2/0b454336447a39d06966adedf4dc4abed6405212107a2f8f326072ae5fb58b3d/merged
shm                     2054171     1 2054170    1% /docker/containers/43cfe7eae9cf310d64c6fe0f133152067d88f8d9242e48289148daebd9cb713d/shm
overlay                 1572864 72477 1500387    5% /docker/overlay2/0d8bba910f1f5e928a8c1e5d02cc55b6fe7bd7cd5c4d23d4abc6f361ff5043ac/merged
shm                     2054171     1 2054170    1% /docker/containers/3727b3e57e2f5c3b7879f23deb3b023d10c0b766fe83e21dd389c71021af371f/shm
tmpfs                   2054171     5 2054166    1% /run/user/0

Libre -lmh

free -lmh
              total        used        free      shared  buff/cache   available
Mem:            15G        3.0G         10G         19M        2.7G         12G
Low:            15G        5.6G         10G
High:            0B          0B          0B
Swap:          1.2G          0B        1.2G

Para cualquiera de los interesados, nosotros (Travis CI) estamos implementando una actualización a v4.8.7 en Ubuntu 14.04. Nuestras pruebas de carga no mostraron ocurrencias del error descrito aquí. Anteriormente, estábamos ejecutando linux-image-generic-lts-xenial en Ubuntu 14.04. Estoy planeando publicar una publicación de blog en un futuro cercano que describa más detalles.

ACTUALIZACIÓN : Debería haber mencionado que estamos ejecutando esta pila de Docker:

Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 21:44:32 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 21:44:32 2016
 OS/Arch:      linux/amd64

ACTUALIZACIÓN : Estamos _todavía_ viendo este error en producción en Ubuntu Trusty + kernel v4.8.7. Todavía no sabemos por qué estos errores desaparecieron en las pruebas de carga por etapas que reproducían previamente el error, sin embargo, la tasa de error en la producción es efectivamente la misma. Adelante y hacia arriba. Hemos desactivado la "implosión automática" en función de este error dada la alta tasa de rotación de instancias .

también encontrado en centos 7

Message from syslogd@c31392666b98e49f6ace8ed65be337210-node1 at Nov 17 17:28:07 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Message from syslogd@c31392666b98e49f6ace8ed65be337210-node1 at Nov 17 17:32:47 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Message from syslogd@c31392666b98e49f6ace8ed65be337210-node1 at Nov 17 17:37:32 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Message from syslogd@c31392666b98e49f6ace8ed65be337210-node1 at Nov 17 17:37:42 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

[root@c31392666b98e49f6ace8ed65be337210-node1 ~]# docker info
Containers: 19
 Running: 15
 Paused: 0
 Stopped: 4
Images: 23
Server Version: 1.11.2.1
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local nas acd ossfs
 Network: vpc bridge null host
Kernel Version: 4.4.6-1.el7.elrepo.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.795 GiB
Name: c31392666b98e49f6ace8ed65be337210-node1
ID: WUWS:FDP5:TNR6:EE5B:I2KI:O4IT:TQWF:4U42:5327:7I5K:ATGT:73KM
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/
WARNING: bridge-nf-call-ip6tables is disabled
Cluster store: etcd://test.com:2379
Cluster advertise: 192.168.0.2:2376

Lo mismo sucede aquí con un VPS de DigitalOcean en las pruebas de Debian:

# journalctl -p0 | tail -15

Nov 19 12:02:55 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 12:03:05 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 12:17:44 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 12:48:15 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 13:33:08 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 14:03:04 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 14:03:14 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 14:17:59 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 15:03:02 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 15:18:13 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 15:32:44 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 16:03:13 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 16:47:43 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 17:17:46 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 17:17:56 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1

Sistema

$ apt list --installed 'linux-image*'
Listing... Done
linux-image-3.16.0-4-amd64/now 3.16.36-1+deb8u2 amd64 [installed,local]
linux-image-4.8.0-1-amd64/testing,now 4.8.5-1 amd64 [installed,automatic]
linux-image-amd64/testing,now 4.8+76 amd64 [installed]

$ apt list --installed 'docker*'
Listing... Done
docker-engine/debian-stretch,now 1.12.3-0~stretch amd64 [installed]
N: There are 22 additional versions. Please use the '-a' switch to see them.

$ uname -a
Linux hostname 4.8.0-1-amd64 #1 SMP Debian 4.8.5-1 (2016-10-28) x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux testing (stretch)
Release:    testing
Codename:   stretch

$ docker info

Containers: 1
 Running: 1
 Paused: 0
 Stopped: 0
Images: 42
Server Version: 1.12.3
Storage Driver: devicemapper
 Pool Name: docker-254:1-132765-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: ext4
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 435 MB
 Data Space Total: 107.4 GB
 Data Space Available: 16.96 GB
 Metadata Space Used: 1.356 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.146 GB
 Thin Pool Minimum Free Space: 10.74 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.136 (2016-11-05)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.8.0-1-amd64
Operating System: Debian GNU/Linux stretch/sid
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 996.4 MiB
Name: hostname
ID: <redacted>
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 127.0.0.0/8

$ docker ps -a

CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS                              NAMES
0b54ed86ba70        squid/production    "/usr/sbin/squid -N"   29 hours ago        Up 29 hours         0.0.0.0:8080-8081->8080-8081/tcp   squid

$ ip link show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether de:ad:be:ff:ff:ff brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether de:ad:be:ff:ff:ff brd ff:ff:ff:ff:ff:ff
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether de:ad:be:ff:ff:ff brd ff:ff:ff:ff:ff:ff
234: veth64d2a77<strong i="12">@if233</strong>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default 
    link/ether de:ad:be:ff:ff:ff brd ff:ff:ff:ff:ff:ff link-netnsid 1

# ifconfig

docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 0.0.0.0
        inet6 dead::beef:dead:beef:ffff  prefixlen 64  scopeid 0x20<link>
        ether de:ad:be:ef:ff:ff  txqueuelen 0  (Ethernet)
        RX packets 3095526  bytes 1811946213 (1.6 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2642391  bytes 1886180372 (1.7 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 123.45.67.89  netmask 255.255.240.0  broadcast 123.45.67.89
        inet6 dead::beef:dead:beef:ffff  prefixlen 64  scopeid 0x0<global>
        inet6 dead::beef:dead:beef:ffff  prefixlen 64  scopeid 0x20<link>
        ether dead::beef:dead:beef:ffff  txqueuelen 1000  (Ethernet)
        RX packets 3014258  bytes 2087556505 (1.9 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3453430  bytes 1992544469 (1.8 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 178  bytes 15081 (14.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 178  bytes 15081 (14.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth64d2a77: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 dead::beef:dead:beef:ffff  prefixlen 64  scopeid 0x20<link>
        ether d2:00:ac:07:c8:45  txqueuelen 0  (Ethernet)
        RX packets 1259405  bytes 818486790 (780.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1103375  bytes 817423202 (779.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

He estado probando 4.8.8 en un circuito cerrado (ver [2] de mi comentario anterior para el caso de prueba) sin parar durante los últimos 4 días. Hasta aquí todo bien.

Hechos

• El parche 751eb6b6 reduce significativamente la aparición de este problema, pero no lo elimina por completo.

Suposiciones
@meatballhat señaló que sus servidores de producción experimentaron el problema mientras ejecutaban 4.8.7. Esto nos deja dos posibilidades:

• Mi caso de prueba de prueba es defectuoso (la posibilidad más probable)
• 4.8.8 introdujo una solución. Al observar el registro de cambios 4.8.8 , las confirmaciones 5086cadf y 6fff1319 mencionan problemas de netdev que se resolvieron. Ninguno de los dos menciona explícitamente el problema aquí, pero ambos están lo suficientemente cerca como para sospechar.

¿Podemos hacer que algunas personas prueben 4.8.8 para ver si pueden reproducir este problema?

@reshen Nos actualizaré a 4.8.8 e informaré: +1: ¡Muchas gracias por su investigación!

@reshen Excelente investigación. Hasta ahora tampoco he podido reproducir el problema usando Linux 4.8.8 en Xubuntu 16.04.

He estado usando las compilaciones del kernel de la línea principal de Ubuntu . No tengo un caso de prueba bien definido, pero podría reproducir el problema de manera consistente antes iniciando y deteniendo el conjunto de contenedores docker con los que trabajo.

Para probar Linux 4.8.8, lo más fácil para mí fue cambiar de aufs a overlay2 como controlador de almacenamiento, ya que las compilaciones del núcleo principal no incluían aufs. No creo que influya en la prueba, pero debe tenerse en cuenta.

En el pasado probé Linux 4.4.4 con el 751eb6b6 backportado por Dan Streetman, esto no pareció reducir el problema para mí. Será interesante ver si la copia de respaldo de los dos parches anotados por usted (5086cadf y 6fff1319) puede dar el mismo resultado que 4.4.8.

Ubuntu 16.04 con 4.4.0-47 todavía se vio afectado ... probando 4.4.0-49 ahora, informará más tarde.

edit: 2016-11-28: -49 es sitll mostrando esa línea de registro en dmesg.

Experimenté esto en Fedora 25 (kernel 4.8.8) y Docker 1.12.3

Para su información: hemos estado ejecutando Linux 4.8.8 junto con Docker v1.12.3 en un solo host de producción. Actualmente, el tiempo de actividad es de 5,5 días y la máquina permanece estable.

Ocasionalmente vemos un puñado de mensajes unregister_netdevice: waiting for lo to become free. Usage count = 1 en syslog, pero a diferencia de antes, el kernel no falla y el mensaje desaparece. Sospecho que uno de los otros cambios introducidos en el Kernel o en Docker detecta esta condición y ahora se recupera de ella. Para nosotros, esto ahora hace que este mensaje sea molesto pero ya no sea un error crítico.

Espero que otras personas puedan confirmar lo anterior en sus flotas de producción.

@gtirloni : ¿puede aclarar si su máquina 4.8.8 / 1.12.3 se bloqueó o si acaba de ver el mensaje?

Gracias, de antemano, a todos los que han estado trabajando en reproducir / proporcionar información útil para triangular esto.

eliminamos la contraparte de la interfaz veth (docker0) después de iniciar la ventana acoplable y reiniciamos la ventana acoplable cuando aprovisionamos el host usando ansible. El problema no ocurrió desde entonces.

También recibo este mismo error en una Raspberry Pi 2 que ejecuta Raspbian con Docker.

Información del kernel
Linux rpi2 4.4.32-v7+ #924 SMP Tue Nov 15 18:11:28 GMT 2016 armv7l GNU/Linux

Información de Docker

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 9
Server Version: 1.12.3
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options:
Kernel Version: 4.4.32-v7+
Operating System: Raspbian GNU/Linux 8 (jessie)
OSType: linux
Architecture: armv7l
CPUs: 4
Total Memory: 925.5 MiB
Name: rpi2
ID: 24DC:RFX7:D3GZ:YZXF:GYVY:NXX3:MXD3:EMLC:JPLN:7I6I:QVQ7:M3NX
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
WARNING: No cpuset support
Insecure Registries:
 127.0.0.0/8

Ocurrió después de crear un contenedor que necesitaba alrededor de ~ 50Mb de programas descargados instalados.

Solo un reinicio me permitiría usar la máquina nuevamente

De hecho, estoy viendo esto en Amazon Linux en un clúster de ECS: el mensaje se lanza ocasionalmente pero no se bloquea, como lo ve reshen ahora. Docker 1.11.2. Uname informa "4.4.14-24.50.amzn1.x86_64" como la versión.

@reshen Voy a compilar 4.8.8 este fin de semana en mi computadora portátil y veré si eso
me lo arregla!
ᐧ

El jueves 1 de diciembre de 2016 a las 10:29 a.m., Ernest Mueller [email protected]
escribió:

De hecho, estoy viendo esto en Amazon Linux en un clúster de ECS: el mensaje
ocasionalmente lanza pero no se bloquea, como reshen está viendo ahora.
Docker 1.11.2. Uname informa "4.4.14-24.50.amzn1.x86_64" como la versión.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/docker/issues/5618#issuecomment-264220432 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AKklVRqoBUZDu3HMhGv3b6knnA6j6C_Qks5rDvXRgaJpZM4B4L4Z
.

-
Keifer Furzland
http://kfrz.work

También pude reproducir este problema usando https://github.com/crosbymichael/docker-stress en un nodo de trabajo de Kubernetes que ejecuta CoreOS Stable 1185.3.0.

Ejecutar docker_stress_linux_amd64 -k 3s -c 5 --containers 1000 : 5 trabajadores simultáneos creando / eliminando contenedores, vida útil máxima de los contenedores = 3 s, crear hasta 1000 contenedores en una instancia m4.large en AWS dejaría el demonio de Docker sin responder después de aproximadamente tres minutos.

Se actualizó a CoreOS Beta 1235.1.0 y no he podido reproducir (tanto la falta de respuesta como el mensaje unregister_netdevice en los registros del kernel). Mientras que ejecutar 5 trabajadores de docker_stress simultáneos mataría a CoreOS Stable después de unos minutos, pude ejecutar con 10 y 15 trabajadores simultáneos hasta completar la prueba con CoreOS Beta.

Lanzamientos de CoreOS en "canales", por lo que no es posible actualizar el kernel de forma aislada. Estas son las principales diferencias entre estable y beta:

CoreOS estable 1185.3.0

núcleo: 4.7.3

acoplador: 1.11.2

CoreOS Beta 1235.1.0

núcleo: 4.8.6

acoplador: 1.12.3

Ver este problema en Amazon Elastic Beanstalk con 4.4.23-31.54.amzn1.x86_64

Simplemente sucede en CoreOS Stable 1185.5.0, Docker 1.12.2
Después de reiniciar todo está bien

Actualización: el problema del demonio de Docker colgado ha vuelto a aparecer en un host que ejecuta CoreOS Beta 1235.1.0 con Docker v1.12.3 y el kernel de Linux v4.8.6. 😢

1.12.4 y 1.13, en teoría, no deberían congelarse cuando se golpea este problema del kernel.
La razón por la que ocurre la congelación en el demonio de la ventana acoplable es porque el demonio está esperando un mensaje de enlace de red desde el kernel (que nunca vendrá) mientras mantiene el bloqueo en el objeto contenedor.

1.12.4 y 1.13 establecen un tiempo de espera en esta solicitud de enlace de red para al menos liberar el bloqueo del contenedor.
Esto __no__ soluciona el problema, pero al menos (con suerte) no congela todo el demonio.
Es probable que no pueda hacer girar nuevos contenedores y, de manera similar, probablemente no podrá derribarlos, ya que parece que todas las interacciones con netlink se estancan una vez que se detecta este problema.

@ cpuguy83 FWIW, cualquier contenedor en ejecución continúa ejecutándose sin problemas AFAIK cuando el demonio está bloqueado. De hecho, lo que se nota es el inicio y la detención de contenedores (especialmente cuando se ejecutan en Kubernetes, como nosotros).

Esto no soluciona el problema, pero al menos (con suerte) no congela todo el demonio.

La única ventaja de que todo el demonio se congele es que es fácil de entender. Kubernetes puede desalojar el nodo, tal vez incluso reiniciarse automáticamente. Si el demonio simplemente siguiera ejecutándose, ¿sería posible encontrar fácilmente el problema del kernel que apareció?

@seanknox Podría proporcionarle una AMI CoreOS 1248.1.0 personalizada con Docker parcheado (CoreOS Docker 1.12.3 + Upstream 1.12.4-rc1 Patches). Tiene bloqueos fijos cada dos horas en mis clústeres de CoreOS / K8s. Simplemente envíeme un ping con su ID de cuenta de AWS en Deis Slack.

Tenemos un gran dolor con este problema en nuestro clúster de CoreOS. ¿Alguien podría decir cuándo finalmente se arreglará? Soñamos con este momento en el que podemos dormir por la noche.

@DenisIzmaylov Si no configura --userland-proxy=false , generalmente no debería encontrarse con este problema.

Pero de lo contrario, esto es un error en el kernel, posiblemente varios errores del kernel, que algunos dicen que se resuelve en 4.8 y otros dicen que no. Para algunos, deshabilitar ipv6 parece solucionarlo, para otros no (por lo tanto, es probable que haya varios problemas ... o al menos múltiples causas).

He visto este problema en unas horas en sistemas de alta carga con y sin --userland-proxy=false

Confirmado que todavía estamos viendo errores unregister_netdevice en el kernel 4.8.12 . Tarda unos 5 días en activarse. Solo un reinicio del sistema parece recuperarse del problema. Detener Docker parece colgarse indefinidamente.

Todavía no he probado el truco de deshabilitar ipv6 para el arranque del kernel.

Containers: 17
 Running: 14
 Paused: 0
 Stopped: 3
Images: 121
Server Version: 1.10.3
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 4.8.12-1.el7.elrepo.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 24
Total Memory: 62.86 GiB
Name: **REDACTED***
ID: **REDACTED***
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

Sería increíble si alguien pudiera probar esto con 1.12.5, que debería agotar el tiempo de espera en la solicitud de enlace de red bloqueada ahora en lugar de simplemente colgar Docker.

@ cpuguy83 sin embargo, el sistema aún no se puede utilizar en ese estado :)

@ LK4D4 Oh, totalmente, solo quiero ver esos tiempos de espera;)

Obteniendo este problema en Cent OS 7:

kernel: unregister_netdevice : esperando que lo sea libre. Recuento de uso = 1

Linux foo 3.10.0-514.2.2.el7.x86_64 # 1 SMP Mar 6 de diciembre 23:06:41 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux

docker-engine-1.12.5-1.el7.centos.x86_64

Esto está afectando mis compilaciones de CI que se ejecutan dentro de los contenedores de Docker y parecen estar muriendo repentinamente durante el cual aparece este mensaje de consola. ¿Existe una solución o una solución alternativa? ¡Gracias!

@ cpuguy83 Docker no se cuelga cuando se produce este error, pero los contenedores se eliminan, lo que en mi situación está rompiendo mis trabajos de Jenkins / CI.

Así que he estado ejecutando Docker en una máquina centos 7 durante un tiempo (¿11 meses?) Sin problemas. Hoy decidí probar el demonio de escucha tcp ( agregué la dirección de escucha tcp a / etc / sysconfig / docker ) y acabo de recibir este error.

kernel: unregister_netdevice : esperando que lo sea libre. Recuento de uso = 1

entonces mi recuento de uso no es 3.

Contenedores: 4
Corriendo: 3
En pausa: 0
Detenido: 1
Imágenes: 67
Versión del servidor: 1.10.3
Controlador de almacenamiento: btrfs
Versión de compilación: Btrfs v4.4.1
Versión de la biblioteca: 101
Controlador de ejecución: native-0.2
Controlador de registro: archivo json
Complementos:
Volumen: local
Red: puente de host nulo
Versión de Kernel: 3.10.0-514.2.2.el7.x86_64
Sistema operativo: CentOS Linux 7 (Core)
OSType: linux
Arquitectura: x86_64
Número de ganchos Docker: 2
CPU: 24
Memoria total: 39,12 GiB
Nombre: codificador-web-aimes
ID: QK5Q: JCMA: ATGR : ND6W: YOT4: PZ7G: DBV5: PR26: YZQL: INRU : HAUC: CQ6B
Registros: docker.io (seguro)

3.10.0-514.2.2.el7.x86_64 # 1 SMP Mar 6 de diciembre 23:06:41 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux

Cliente:
Versión: 1.10.3
Versión de API: 1.22
Versión del paquete: docker-common-1.10.3-59.el7.centos.x86_64
Go versión: go1.6.3
Confirmación de Git: 3999ccb-unsupported
Construido: Thu Dec 15 17:24:43 2016
SO / Arch: linux / amd64

Servidor:
Versión: 1.10.3
Versión de API: 1.22
Versión del paquete: docker-common-1.10.3-59.el7.centos.x86_64
Go versión: go1.6.3
Confirmación de Git: 3999ccb-unsupported
Construido: Thu Dec 15 17:24:43 2016
SO / Arch: linux / amd64

Puedo confirmar @aamerik. Veo el mismo problema en la misma versión del kernel. No hay cambios importantes recientes en el sistema, viendo este problema desde hoy.

Vi el mismo mensaje kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1 en mi máquina CentOS 7 ejecutando una imagen acoplable de Jenkins. La máquina CentOS 7 que estaba usando estaba actualizada con todos los últimos parches de CentOS 7 aproximadamente el 20 de diciembre de 2016.

Dado que las referencias más recientes aquí parecen estar basadas en CentOS, cambiaré mi host de ejecución a una máquina Ubuntu o Debian.

Estoy ejecutando Docker version 1.12.5, build 7392c3b en esa máquina CentOS 7. Docker no se bloqueó, pero el proceso de Jenkins que estaba ejecutando en Docker se eliminó cuando apareció ese mensaje.

¡Muchas gracias por Docker! ¡Lo uso todo el tiempo y estoy profundamente agradecido por su trabajo en él!

Veo el mismo problema cuando uso Jenkins con Docker en una máquina Linux 4.8.15.

¿Alguien llegó a un procedimiento de solución para el sistema operativo ranchero?

AFAICT, este es un problema de bloqueo en el subsistema de espacios de nombres de red del kernel de Linux. Este error se informó hace más de un año, sin respuesta: https://bugzilla.kernel.org/show_bug.cgi?id=97811 Se ha trabajado en esto (ver aquí: http: //www.spinics. net / lists / netdev / msg351337.html) pero parece que no es una solución completa.

He intentado hacer ping directamente al responsable del mantenimiento del subsistema de red, sin respuesta. FWIW, puedo reproducir el problema en cuestión de minutos.

Smyte pagará $ 5000 USD por la resolución de este problema. ¿Parece que necesito hablar con alguien que trabaje en el kernel?

@petehunt Creo que hay varios problemas en juego que causan este error.

Implementamos el kernel 4.8.8 como sugirió @reshen y aunque el tiempo de actividad parece un poco mejor, seguimos viendo este problema en producción.

Intentando implementar Mesosphere desde un nodo bootstrap. Todos los nodos tienen un mínimo de CentOS 7.2 con todas las actualizaciones aplicadas. El nodo de arranque muestra el error como lo señalaron otros anteriormente:

Message from syslogd<strong i="6">@command01</strong> at Jan 16 02:30:24 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Message from syslogd<strong i="7">@command01</strong> at Jan 16 02:30:34 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Message from syslogd<strong i="8">@command01</strong> at Jan 16 02:30:44 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

uname -r:

3.10.0-514.2.2.el7.x86_64

docker -v:

Docker version 1.11.2, build b9f10c9

Puedo confirmar que un reinicio silencia los mensajes, pero en el momento en que implemento mesosfera nuevamente, los mensajes comienzan de vez en cuando. Mesosphere es un despliegue bastante grande. Quizás aquellos que intentan recrear el error pueden usar el instalador para reproducir el error. Se necesitan unos minutos antes de que aparezca el error después de usar el primer cambio de secuencia de comandos (--genconf, que es el primer paso).

También hemos llegado a esto. Sin embargo, los mensajes de error en nuestro caso mencionan el dispositivo eth0 no lo . Mi error es este:

kernel:unregister_netdevice: waiting for eth0 to become free. Usage count = 1

Supongo que errores como mencionar eth0 lugar de lo tienen la misma causa raíz que este problema. Si no es así, deberíamos abrir un nuevo ticket con respecto a los errores eth0.

• SO: CentOS Linux versión 7.3.1611
• Kernel: 3.10.0-514.2.2.el7.x86_64
• Docker versión 1.12.6, compilación 78d1802
• Docker comenzó con opciones: OPTIONS=" -H unix:///var/run/docker.sock --ip-forward=true --iptables=true --ip-masq=true --log-driver json-file --log-opt max-size=25m --log-opt max-file=2"
• Rancher 1.2.2 usando IPsec (mencionando esto desde https://bugzilla.kernel.org/show_bug.cgi?id=97811 y otros errores mencionan IPsec)

También hemos llegado a esto.
Error: unregister_netdevice: esperando que lo se libere.
SO: CentOS Linux versión 7.3.1611 (Core)
Kernel 3.10.0-514.2.2.el7.x86_64
Versión de Docker: 1.13.0-cs1-rc1
Opciones de Docker:
{
"deshabilitar-registro-heredado": verdadero,
"icc": cierto,
"registros-inseguros": [],
"ipv6": falso,
"iptables": verdadero,
"controlador de almacenamiento": "mapeador de dispositivos",
"opciones de almacenamiento": [
"dm.thinpooldev = / dev / mapper / docker_vg-thinpool",
"dm.use_deferred_removal = true",
"dm.use_deferred_deletion = true"
],
"userland-proxy": falso
}

Tengo esto en dos sistemas CentOS, las últimas actualizaciones en al menos uno de ellos.

$ uname -r
3.10.0-514.2.2.el7.x86_64
$ docker -v
Docker version 1.12.6, build 78d1802

Hola, para todos los afectados por este problema en RHEL o CentOS, he respaldado la confirmación de los kernels de la línea principal (torvalds / linux @ 751eb6b6042a596b0080967c1a529a9fe98dac1d) que corrige la condición de carrera en el recuento de referencia IFP IPV6 a los kernels 3.10.x utilizados en las distribuciones empresariales. Esto debería solucionar este problema.

Puede encontrar el informe de error con el parche de trabajo aquí :
Si está interesado en probarlo y tiene un sistema RHEL 7 o CentOS 7, ya compilé el último kernel de CentOS 7.3 3.10.0-514.6.1.el7.x86_64 con el parche. Responda al hilo del seguimiento de errores de CentOS y puedo enviarle un enlace a la compilación.

Nota: puede haber otro problema que cause una fuga de recuento, pero esto debería solucionar el mensaje de error para muchos de ustedes.

@stefanlasiewski @henryiii @jsoler

Estaré probando una compilación también agregando esta solución: http://www.spinics.net/lists/netdev/msg351337.html más tarde esta noche.

@iamthebot, ¿significa que si uno deshabilita IPv6 también debería solucionar el problema, incluso sin un parche que acaba de exportar?

@redbaron solo si ese es el problema al que te

@redbaron tal vez. # 20569 parece indicar que es difícil deshabilitar completamente IPV6.

Entonces, para aclarar un poco lo que está sucediendo debajo del capó que está generando este mensaje, el kernel mantiene un recuento continuo de si un dispositivo está en uso antes de eliminarlo de un espacio de nombres, anular el registro, desactivarlo, etc. referencia a un dispositivo, entonces verá ese mensaje de error, ya que no se puede anular el registro cuando otra persona lo está usando.

Las correcciones que he visto hasta ahora:

1. Solucione un problema en el que un problema con la asignación de una dirección IPV6 falla (por ejemplo, una dirección duplicada) pero no publicamos la referencia al dispositivo antes de salir.
2. Solucione un problema por el cual mover el espacio de nombres de un dispositivo moverá correctamente las referencias al dispositivo al nuevo espacio de nombres de red, pero dejará una referencia pendiente en el espacio de nombres antiguo. Docker hace un uso intensivo de los espacios de nombres de red (como lo demuestra otra corrección del kernel de que tenía el backport de Red Hat a 7.3 Z-Stream y está programado para su inclusión en 7.4 que evita que el controlador macvlan de Docker funcione en dispositivos de enlace o de equipo)

Creo que todavía hay otra condición de carrera al cambiar los espacios de nombres (esto parece suceder después de crear un montón de contenedores nuevos) pero tendré que replicar el problema de manera confiable para buscarlo y escribir un parche.

¿Alguien tiene un procedimiento mínimo para reproducir esto de manera consistente? Parecía suceder al azar en nuestros sistemas.

@iamthebot no es realmente sencillo, pero creo que podemos proporcionarle un entorno de prueba que pueda reproducir esto de manera confiable. Envíeme un correo electrónico ([email protected]) y podemos organizar los detalles.

Aún experimente esto bajo una gran carga en la versión 1.12.6 de Docker, compilación 7392c3b / 1.12.6 en 4.4.39-34.54.amzn1.x86_64 AWS Linux AMI.

Tengo 9 hosts de Docker, todos casi idénticos, y solo experimento esto en algunos de ellos. Puede ser una coincidencia, pero una cosa en común que he notado es que parece que solo tengo este problema cuando ejecuto contenedores que no manejan SIGINT . Cuando docker stop estos contenedores, se cuelga durante 10 segundos y luego mata el contenedor sin gracia.

Pasan varios días antes de que se presente el problema, y ​​parece aparecer al azar, no solo inmediatamente después de ejecutar docker stop . Esto es principalmente anecdótico, pero quizás ayude a alguien.

He actualizado todos mis nodos de Docker al kernel 3.10.0-514.6.1.el7.x86_64 en CentOS 7.3 como mencionó @iamthebot, pero sigo recibiendo los mismos errores:
26 de enero 13:52:49 kernel XXX: unregister_netdevice: esperando que lo sea libre. Recuento de uso = 1
Mensaje de syslogd @ XXX el 26 de enero 13:52:49 ...
kernel: unregister_netdevice : esperando que lo sea libre. Recuento de uso = 1

@jsoler solo para ser claros, ¿aplicó el parche en el hilo del rastreador de errores antes de construir el kernel? ¿O está utilizando un núcleo de stock? También intente aplicar este (el parche debería funcionar en núcleos más antiguos).

Envíeme un correo electrónico ([email protected]) y puedo enviarle un enlace a un kernel prediseñado. @vitherman Desafortunadamente, no tengo mucho tiempo para investigar esto (parece que será necesario compilar alguna instrumentación para detectar este error) pero he escalado el problema con el soporte de Red Hat, por lo que su equipo de kernel tomará un Mira.

@ckeeney Puedo confirmar este comportamiento. Tenemos una aplicación de nodo acoplada que causó dicho error en el sistema host cuando se cerró. Después de implementar una función dentro de la aplicación Node.js, que detecta a SIGINT y SIGTERM para cerrar correctamente la aplicación, el error no ha vuelto a ocurrir.
Lo cual tiene sentido; la aplicación Node utiliza la interfaz virtual que crea Docker. Cuando el nodo no se apaga correctamente, el dispositivo se cuelga y el sistema host no puede anular el registro, aunque el contenedor de Docker se haya detenido con éxito.

aquí hay un fragmento de código de ejemplo:

function shutdown() {
    logger.log('info', 'Graceful shutdown.');

    httpServer.close();
    if (httpsServer) {
        httpsServer.close();
    }

    process.exit();
}

process.on('SIGINT', shutdown);
process.on('SIGTERM', shutdown);

@ michael-niemand, ¿hay alguna señal diferente que Node maneje correctamente de forma predeterminada para un apagado limpio? (puede especificar STOPSIGNAL en la imagen, o en docker run través de la bandera --stop-signal .

@thaJeztah para obtener una buena explicación del problema y una solución alternativa, consulte nodejs / node-v0.x-archive # 9131 # issuecomment-72900581

@ckeeney Soy consciente de eso (es decir, los procesos que se ejecutan como PID1 pueden no manejar SIGINT o SIGTERM ). Por esa razón, me preguntaba si especificar una señal de parada diferente haría un apagado limpio incluso si se ejecuta como PID1 .

Alternativamente, docker 1.13 agrega una opción --init (solicitud de extracción: https://github.com/docker/docker/pull/26061), que inserta un init en el contenedor; en ese caso, Node no se está ejecutando como PID1 , lo que puede ayudar en los casos en que no pueda actualizar la aplicación.

@iamthebot He construido la versión del kernel 3.10.0-514.el7 con su parche integrado pero obtengo el mismo error. Bueno, no estoy seguro de haber construido bien el paquete del kernel de centos. ¿Podrías compartirme tu paquete de kernel para probarlo?

Gracias

He estado lidiando con este error durante casi un año. Utilizo CoreOS con arranque PXE, desactivé ipv6 en la configuración de pxeboot y no he visto este problema una vez desde entonces.

Bueno, mi entorno ha desactivado ipv6 con esta configuración sysctl
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
pero sigo recibiendo el error
kernel: unregister_netdevice : esperando que lo sea libre. Recuento de uso = 1

@jsoler cierto, yo también estaba haciendo eso, todavía sucedió. Solo una vez que lo hice, el nivel de pxe se detuvo.

label coreos
        menu label CoreOS
        kernel coreos/coreos_production_pxe.vmlinuz
        append initrd=coreos/coreos_production_pxe_image.cpio.gz ipv6.disable=1 cloud-config-url=http://...

Solo una observación: parece que hay diferentes problemas en juego (eso se ha dicho antes).

• Algunas personas notan "esperando lo ..."
• algunos han notado "esperando eth0"
• algunos han notado "esperando veth ?????"
• En el seguimiento de errores de RedHat , se habla de "esperar ppp0"

Algunos han notado que los registros alternan entre cualquiera de los anteriores y otros solo tienen uno de los anteriores.

También hay un error similar registrado en Ubuntu . En este, parecen encontrar que NFS es el problema.

@etlweather Creo que, de hecho, el único denominador común es, bueno, que el kernel no pueda anular el registro de un dispositivo de red como dice el mensaje de error. Sin embargo, las razones _por qué_ son algo diferentes. Para nosotros, definitivamente fue el problema de docker / nodo mencionado (veth). Para eth, lo más probable es que la causa sea algo completamente diferente.

Todavía sucede con 4.9.0-0.bpo.1-amd64 en debian jessie con docker 1.13.1. ¿Existe alguna combinación de kernel - os que sea estable?

Es posible que esto no sea un problema puramente de Docker: lo obtengo en un servidor Proxmox donde solo estoy ejecutando contenedores vanilla LXC (ubuntu 16.04).

@ darth-veitcher es un problema del kernel

@thaJeztah estuvo de acuerdo, gracias. Iba a intentar instalar 4.9.9 esta noche desde la línea principal y ver si eso soluciona las cosas.

Lo hago ejecutando Docker 1.13.1 en Debian con kernel 4.9.9-040909.

Sí, la actualización del kernel en Proxmox a la última versión 4.9.9 no resolvió el error. Extraño como acaba de aparecer después de un año sin problemas.

Puede haber algo en una declaración anterior más arriba en el hilo acerca de que está vinculado a los recursos compartidos NFS o CIFS montados.

Enviado desde mi iPhone

El 14 de febrero de 2017, a las 07:47, Alfonso da Silva [email protected] escribió:

Lo hago ejecutando Docker 1.13.1 en Debian con kernel 4.9.9-040909.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o silencie el hilo.

Tengo un ticket de bugzilla abierto con Redhat sobre esto.

Algunas novedades:
Red Hat colocó los parches de fugas de recuento de referencias IPV6 de la línea principal en QA, parece que están en cola para RHEL 7.4 y pueden ser retroportados a 7.3. También debería estar en CentOS-plus pronto. Nota: este parche solo corrige problemas en ALGUNOS casos. Si tiene un kernel 4.x, es un punto discutible ya que ya están allí.

Esta es definitivamente una condición de carrera en el kernel por lo que puedo decir, lo que hace que sea realmente molesto de encontrar. Tomé una instantánea del kernel de la línea principal actual y estoy trabajando en la instrumentación de las diversas llamadas comenzando con el subsistema IPV6. El problema es definitivamente reproducible ahora: parece que todo lo que tiene que hacer es crear un montón de contenedores, empujar una tonelada de tráfico de red desde ellos, bloquear el programa dentro de los contenedores y eliminarlos. Hacer esto una y otra vez desencadena el problema en minutos, como máximo en una estación de trabajo física de 4 núcleos.

Desafortunadamente, no tengo mucho tiempo para trabajar en esto: si hay desarrolladores de kernel aquí que estén dispuestos a colaborar en la instrumentación de las piezas necesarias, creo que podemos configurar una bifurcación y comenzar a trabajar en la búsqueda de esto paso a paso. .

@iamthebot , ¿es reproducible en una configuración qemu-kvm?

@iamthebot He intentado reproducir esto varias veces con diferentes núcleos. En algún lugar arriba se mencionó que usar docker-stress -c 100 con userland-proxy establecido en falso lo activaría, pero no tuve suerte.

Si tiene una reproducción más confiable (incluso si tarda mucho en activarse) puedo probar y echar un vistazo

Encontramos la misma dificultad en nuestros entornos de producción y puesta en escena. Pronto actualizaremos a Docker 1.13 y al kernel de Linux 4.9, pero como ya se ha mencionado anteriormente; estas versiones también se ven afectadas.

$ docker -v
Docker version 1.12.3, build 6b644ec

$ uname -a
Linux 4.7.0-0.bpo.1-amd64 #1 SMP Debian 4.7.8-1~bpo8+1 (2016-10-19) x86_64 GNU/Linux

Estoy experimentando este problema con bastante regularidad en mi sistema de desarrollo, siempre mientras cierro los contenedores.

Información general

→ uname -a
Linux miriam 3.10.0-514.6.1.el7.x86_64 #1 SMP Sat Dec 10 11:15:38 EST 2016 x86_64 x86_64 x86_64 GNU/Linux

→ cat /etc/redhat-release
Red Hat Enterprise Linux Workstation release 7.3 (Maipo)

→ docker -v 
Docker version 1.13.0, build 49bf474

→ docker-compose -v 
docker-compose version 1.10.0, build 4bd6f1a

→ docker info 
Containers: 11
 Running: 0
 Paused: 0
 Stopped: 11
Images: 143
Server Version: 1.13.0
Storage Driver: overlay
 Backing Filesystem: xfs
 Supports d_type: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 03e5862ec0d8d3b3f750e19fca3ee367e13c090e
runc version: 2f7393a47307a16f8cee44a37b262e8b81021e3e
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 3.10.0-514.6.1.el7.x86_64
Operating System: Red Hat Enterprise Linux
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 31.19 GiB
Name: miriam
ID: QU56:66KP:C37M:LHXT:4ZMX:3DOB:2RUD:F2RR:JMNV:QCGZ:ZLWQ:6UO5
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 16
 Goroutines: 25
 System Time: 2017-02-15T10:47:09.010477057-06:00
 EventsListeners: 0
Http Proxy: http://xxxxxxxxxxxxxxxxxxxx:80
Https Proxy: http://xxxxxxxxxxxxxxxxxxxx:80
No Proxy: xxxxxxxxxxxxxxxxxxxx
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Registro del demonio de Docker

DEBU[70855] Calling DELETE /v1.22/containers/9b3d01076f3b6a1373729e770a9b1b4e878c2e4be5e27376d24f21ffead6792f?force=False&link=False&v=False 
DEBU[70855] Calling DELETE /v1.22/containers/38446ddb58bc1148ea2fd394c5c14618198bcfca114dae5998a5026152da7848?force=False&link=False&v=False 
DEBU[70855] Calling DELETE /v1.22/containers/e0d31b24ea4d4649aec766c7ceb5270e79f5a74d60976e5894d767c0fb2af47a?force=False&link=False&v=False 
DEBU[70855] Calling DELETE /v1.22/networks/test_default  
DEBU[70855] Firewalld passthrough: ipv4, [-t nat -C POSTROUTING -s 172.19.0.0/16 ! -o br-ee4e6fb1c772 -j MASQUERADE] 
DEBU[70855] Firewalld passthrough: ipv4, [-t nat -D POSTROUTING -s 172.19.0.0/16 ! -o br-ee4e6fb1c772 -j MASQUERADE] 
DEBU[70855] Firewalld passthrough: ipv4, [-t nat -C DOCKER -i br-ee4e6fb1c772 -j RETURN] 
DEBU[70855] Firewalld passthrough: ipv4, [-t nat -D DOCKER -i br-ee4e6fb1c772 -j RETURN] 
DEBU[70855] Firewalld passthrough: ipv4, [-t filter -C FORWARD -i br-ee4e6fb1c772 -o br-ee4e6fb1c772 -j ACCEPT] 
DEBU[70855] Firewalld passthrough: ipv4, [-D FORWARD -i br-ee4e6fb1c772 -o br-ee4e6fb1c772 -j ACCEPT] 
DEBU[70855] Firewalld passthrough: ipv4, [-t filter -C FORWARD -i br-ee4e6fb1c772 ! -o br-ee4e6fb1c772 -j ACCEPT] 
DEBU[70855] Firewalld passthrough: ipv4, [-D FORWARD -i br-ee4e6fb1c772 ! -o br-ee4e6fb1c772 -j ACCEPT] 
DEBU[70855] Firewalld passthrough: ipv4, [-t filter -C FORWARD -o br-ee4e6fb1c772 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT] 
DEBU[70855] Firewalld passthrough: ipv4, [-D FORWARD -o br-ee4e6fb1c772 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT] 
DEBU[70856] Firewalld passthrough: ipv4, [-t filter -C FORWARD -o br-ee4e6fb1c772 -j DOCKER] 
DEBU[70856] Firewalld passthrough: ipv4, [-t filter -C FORWARD -o br-ee4e6fb1c772 -j DOCKER] 
DEBU[70856] Firewalld passthrough: ipv4, [-D FORWARD -o br-ee4e6fb1c772 -j DOCKER] 
DEBU[70856] Firewalld passthrough: ipv4, [-t filter -C DOCKER-ISOLATION -i br-ee4e6fb1c772 -o docker0 -j DROP] 
DEBU[70856] Firewalld passthrough: ipv4, [-D DOCKER-ISOLATION -i br-ee4e6fb1c772 -o docker0 -j DROP] 
DEBU[70856] Firewalld passthrough: ipv4, [-t filter -C DOCKER-ISOLATION -i docker0 -o br-ee4e6fb1c772 -j DROP] 
DEBU[70856] Firewalld passthrough: ipv4, [-D DOCKER-ISOLATION -i docker0 -o br-ee4e6fb1c772 -j DROP] 
DEBU[70856] Firewalld passthrough: ipv4, [-t filter -C DOCKER-ISOLATION -i br-ee4e6fb1c772 -o br-b2210b5a8b9e -j DROP] 
DEBU[70856] Firewalld passthrough: ipv4, [-D DOCKER-ISOLATION -i br-ee4e6fb1c772 -o br-b2210b5a8b9e -j DROP] 
DEBU[70856] Firewalld passthrough: ipv4, [-t filter -C DOCKER-ISOLATION -i br-b2210b5a8b9e -o br-ee4e6fb1c772 -j DROP] 
DEBU[70856] Firewalld passthrough: ipv4, [-D DOCKER-ISOLATION -i br-b2210b5a8b9e -o br-ee4e6fb1c772 -j DROP] 
DEBU[70856] releasing IPv4 pools from network test_default (ee4e6fb1c772154fa35ad8d2c032299375bc2d7756b595200f089c2fbcc39834) 
DEBU[70856] ReleaseAddress(LocalDefault/172.19.0.0/16, 172.19.0.1) 
DEBU[70856] ReleasePool(LocalDefault/172.19.0.0/16)      

Message from syslogd<strong i="10">@miriam</strong> at Feb 15 10:20:52 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

@ r-BenDoan si intenta detener un contenedor pero no responde a SIGINT, la ventana acoplable esperará 10 segundos y luego matará el contenedor sin gracia. Encontré ese comportamiento en mis contenedores de nodejs hasta que agregué el manejo de señales. Si ve que un contenedor tarda 10 segundos en detenerse, es probable que no esté manejando señales y es más probable que desencadene este problema.

Asegúrese de que sus contenedores puedan detenerse con gracia.

Si bien no soy yo quien está solucionando este problema, no estoy muy interesado en el desarrollo del kernel de Linux, creo que tengo razón al decir que los comentarios "yo también" no son tan útiles. Con esto quiero decir, simplemente decir "Yo también tengo este problema, con Kernel vx.xy Docker 1.x" no aporta nada nuevo a la discusión.

Sin embargo, sugeriría que los comentarios "yo también" que describan más el entorno y el método de reproducción serían de gran valor.

Al leer todos los comentarios, está claro que hay algunos problemas, como publiqué anteriormente, algunos con vethXYZ, algunos con eth0 y otros con lo0. Esto sugiere que podrían deberse a diferentes problemas. Por lo tanto, decir "yo también" sin una descripción completa del error y el entorno puede inducir a error a las personas.

Además, al describir el entorno, dar la versión de Kernel y Docker no es suficiente. Según el hilo, parece haber algunos factores, como ipv6 habilitado o no. NodeJS no responde a SIGINT (u otros contenedores, no ataca a NodeJS aquí).

Por tanto, sería útil describir cuál es la carga de trabajo en el entorno. Además, esto ocurre cuando se cierra un contenedor, por lo que también sugeriría a las personas que experimentan este problema que presten atención a qué contenedor se está deteniendo cuando el problema asoma su fea cabeza.

Si bien parece que el problema está en que el kernel tiene una condición de carrera, identificar el desencadenante será de gran ayuda para quienes solucionarán el problema. E incluso puede brindar a los usuarios afectados una solución inmediata, como implementar un controlador de señales en una aplicación NodeJS (no sé si esto evita que se active el problema, pero parece que sí, según los comentarios anteriores de otros).

FWIW kubernetes ha correlacionado esto completamente con el "modo horquilla" y
ha dejado de utilizar esa función por completo. No hemos experimentado esto
problema en absoluto, en decenas de miles de máquinas de producción y en gran medida
más ejecuciones de prueba, desde el cambio.

Hasta que esto se arregle, abandone el barco. Encuentra una solución diferente :(

El miércoles 15 de febrero de 2017 a las 10:00 a. M., ETL [email protected] escribió:

Si bien no soy yo quien está solucionando este problema, no estoy muy interesado en Linux
Desarrollador de kernel, creo que tengo razón al decir que los comentarios "yo también" no
que útil. Con esto quiero decir, simplemente decir "Yo también tengo este problema, con
Kernel vx.xy Docker 1.x "no aporta nada nuevo a la discusión.

Sin embargo, sugeriría que los comentarios "yo también" que describan más el
el medio ambiente y el método de reproducción serían de gran valor.

Al leer todos los comentarios, queda claro que hay algunos problemas:
como publiqué anteriormente, algunos con vethXYZ, algunos con eth0 y otros con lo0.
Esto sugiere que podrían deberse a diferentes problemas. Por lo que sólo
decir "yo también" sin una descripción completa del error y el entorno puede
engañar a la gente.

Además, al describir el entorno, dando al Kernel y Docker
la versión no es suficiente. Según el hilo, parece haber algunos factores
como ipv6 habilitado o no. NodeJS no responde a SIGINT (u otro
contenedores, no atacando a NodeJS aquí).

Por tanto, sería útil describir cuál es la carga de trabajo en el entorno.
Además, esto ocurre cuando se cierra un contenedor, por lo que
También sugiera a las personas que experimentan este problema que presten atención a lo que
contenedor se detiene cuando el problema asoma su fea cabeza.

Si bien parece que el problema está en que el kernel tiene una condición de carrera:
identificar el desencadenante será de gran ayuda para aquellos que solucionarán
la cuestión. E incluso puede dar a los usuarios afectados una solución inmediata.
como implementar un controlador de señales en una aplicación NodeJS (no sé
Yo mismo que esto evita que el problema se active, pero parece que así es.
comentarios anteriores de otros).

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/docker/issues/5618#issuecomment-280087293 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AFVgVFmu1SiStZcLKtKuk1W-tjn6wOXlks5rcz0hgaJpZM4B4L4Z
.

Sí, nos estamos mudando a gke y ya no vemos este problema (así que no más recompensas por errores de nuestra parte :))

Acabo de tener el error de nuevo. Estaba tratando de arreglar una aplicación node.js que usa sockets y, por lo tanto, escalaba la aplicación con frecuencia. La aplicación node.js se creó sobre https://github.com/deployd/deployd. Espero que esto proporcione más información. Lo que también fue interesante es que ambos servidores dentro de mi enjambre mostraron el error unregister_netdevice simultáneamente después de que eliminé el servicio a través del servicio docker rm. El contenedor se escaló a 4, por lo que dos contenedores estaban funcionando en cada máquina.

editar ¡ Ocurrió de nuevo! Trabajando en la misma aplicación node.js. Los últimos 3 o 4 días no he trabajado directamente en esa aplicación node.js y nunca ocurrió.

edit2 intentará agregar un controlador de señal a la aplicación nodejs. Veamos si eso ayuda ...

Me encontré con este error, después de usar docker-py para publicar una nueva instancia en EC. Sin embargo, pude salir con ctrl + C y no lo he visto desde entonces (ahora que la mayoría de las imágenes se están construyendo más rápidamente desde el caché)

`` `{" status ":" Push "," progressDetail ": {}," id ":" c0962ea0b9bc "}
{"status": "stage: digest: sha256: f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8 size: 5737"}
{"progressDetail": {}, "aux": {"Tag": "stage", "Digest": "sha256: f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8", "Tamaño": 5737}}

Imagen de Docker publicada correctamente

Mensaje de syslogd @ ip-172-31-31-68 el 16 de febrero 19:49:16 ...
kernel: [1611081.976079] unregister_netdevice: esperando que lo sea libre. Recuento de uso = 1

Mensaje de syslogd @ ip-172-31-31-68 el 16 de febrero 19:49:27 ...
kernel: [1611092.220067] unregister_netdevice: esperando que lo se libere. Recuento de uso = 1

[1] + Detenido ./image-publish.py
[ root @ ip-172-31-xx-xx image-publish] # ^ C
[ root @ ip-172-31-xx-xx image-publish] #

@thockin, ¿esta configuración es --hairpin-mode=none en los kubelets?

= none rompe los contenedores que se vuelven NAT a sí mismos. Usamos
promiscuous-bridge por defecto.

El jueves 16 de febrero de 2017 a las 7:26 p.m., Kanat Bekt [email protected]
escribió:

@thockin https://github.com/thockin es esta configuración --hairpin-mode = none
en los kubelets?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/docker/issues/5618#issuecomment-280539673 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AFVgVLNwAH6NWVaIKhJfS147O9w_rtJEks5rdRN8gaJpZM4B4L4Z
.

@thockin ¿ qué contenedores podrían querer acceder a sí mismos a través de Service ClusterIP?

Resulta ser más común de lo que pensaba, y cuando lo rompimos, muchos
de la gente se quejó.

El 17 de febrero de 2017 a las 12:38 a. M., "Maxim Ivanov" [email protected] escribió:

@thockin https://github.com/thockin qué contenedores pueden querer
acceder a sí mismos a través de Service ClusterIP?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/docker/issues/5618#issuecomment-280588366 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AFVgVLn3uBvUW-dQ72qst5_eYiFUtfSVks5rdVyIgaJpZM4B4L4Z
.

Creo que sé por qué alguna aplicación de nodejs acoplada podría causar este problema. El nodo utiliza conexiones de mantenimiento de vida de forma predeterminada. Cuando se usa server.close() , el servidor no acepta nuevas conexiones. Pero las conexiones activas actuales como websockets o conexiones HTTP Keep-Alive aún se mantienen. Cuando la aplicación acoplada también se escala an, esto podría resultar en waiting for lo to become free porque cuando se fuerza a la terminación, se libera una versión más nueva. Cuando la ventana acoplable redistribuye esta aplicación a otro nodo o la aplicación se reduce, la ventana acoplable envía una señal a la aplicación para que se cierre. La aplicación escucha esta señal y puede reaccionar. Cuando la aplicación no se apaga después de algunos segundos, Docker la cierra sin dudarlo. Agregué controladores de señal y descubrí que cuando se usa server.close() el servidor no está perfectamente terminado, pero "solo" deja de aceptar nuevas conexiones (consulte https://github.com/nodejs/node/issues/2642). Por lo tanto, debemos asegurarnos de que las conexiones abiertas como websockets o http keep-alive también estén cerradas.

Cómo manejar websockets:
La aplicación nodejs emite a todos los websockets closeSockets cuando se recibe una señal de apagado. El cliente escucha este evento closeSockets y llama a sockets.disconnect() y poco después sockets.connect() . Recuerde que se llamó server.close() por lo que esta instancia no acepta nuevas solicitudes. Cuando se están ejecutando otras instancias de esta aplicación acoplada, el equilibrador de carga dentro de la ventana acoplable eventualmente seleccionará una instancia que no se apaga y se establece una conexión exitosa. La instancia que debería cerrarse no tendrá conexiones websockets abiertas.

var gracefulTermination = function(){
    //we don't want to kill everything without telling the clients that this instance stops
    //server.close() sets the server to a state on which he doesn't allow new connections
    //but the old connections (websockets) are still open and can be used
    server.close(function(){
        // this method is called when the server terminates
        console.log('close bknd');
            process.exit();
        });

        //iterate through all open websockets and emit 'closeSockets' to the clients.
    //Clients will then call disconnect() and connect() on their site to establish new connections
    //to other instances of this scaled app
    Object.keys(server.socketIoObj.sockets.sockets).forEach(function(id) {
        console.log("WebSocket ID:",id, " will be closed from the client.") 
        server.socketIoObj.to(id).emit('closeSockets');
    });

};
process.on( "SIGINT", function() {
    console.log('CLOSING [SIGINT]');
    gracefulTermination();
});
...

Cómo manejar conexiones HTTP Keep-Alive:
Actualmente no sé cómo se puede hacer esto perfectamente. La forma más sencilla es desactivar Keep-Alive.

app.use(function (req, res, next) {
    res.setHeader('Connection', 'close');
    next();
}

Otra posibilidad es establecer el tiempo de espera de Keep-Alive en un número muy bajo. Por ejemplo 0,5 segundos.

app.use(function (req, res, next) {
    res.setTimeout(500);
    next();
}

Espero que esto pueda ayudar a otros :)

Tengo los mismos problemas. Los archivos adjuntos son todos los registros creados con el script ecs-logs-collector.
Muy apreciado por cualquier ayuda :)

Collect.zip

Tengo los mismos problemas.
Docker versión 1.13.1, compilación 092cba3
Linux debian 4.8.6-x86_64-linode78

Copia de seguridad de Linux 4.6.0-040600-generic # 201606100558 SMP Vie 10 de junio 10:01:15 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux
Versión del servidor: 1.13.1

Mismo problema. Estoy usando el montaje en un contenedor privilegiado. Después de 4-5 ejecuciones, se congela. También tengo el mismo problema con el último kernel estándar para 16.04

Todos, @etlweather es

@rneugeba @redbaron Desafortunadamente, el "repro" actual que tengo es muy específico de hardware (todo menos demostrando que esto es una condición de carrera). No he intentado obtener una reproducción QEMU, pero ese es definitivamente el siguiente paso para que varias personas puedan trabajar en esto y obtener el resultado esperado (idealmente en una configuración de núcleo de CPU). Si alguien ya tiene uno, envíeme un correo electrónico (está en mi perfil). Lo probaré a fondo y lo publicaré aquí.

Recibimos esto en GCE con bastante frecuencia. Docker se congela y la máquina se cuelga al reiniciar.

[782935.982038] unregister_netdevice: waiting for vethecf4912 to become free. Usage count = 17

El contenedor está ejecutando una aplicación go y tiene configurada una horquilla nat.

Estibador:

matthew@worker-1:~$ docker version
Client:
 Version:      1.12.6
 API version:  1.24
 Go version:   go1.6.4
 Git commit:   78d1802
 Built:        Tue Jan 10 20:38:45 2017
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.6
 API version:  1.24
 Go version:   go1.6.4
 Git commit:   78d1802
 Built:        Tue Jan 10 20:38:45 2017
 OS/Arch:      linux/amd64

Ubuntu 16.04 LTS,

matthew@worker-1:~$ uname -a
Linux worker-1 4.4.0-64-generic #85-Ubuntu SMP Mon Feb 20 11:50:30 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

¿Alguien tiene una solución sugerida para esto? Intenté habilitar --userland-proxy=true y la ventana acoplable aún se cuelga después de un tiempo. Parece que Kubernates tiene una solución de lo que @thockin escribió anteriormente, pero no está claro qué es exactamente lo que hace --hairpin-mode=promiscuous-bridge y cómo configurarlo en una instalación sencilla de jane ubuntu 16.x docker.

Puedo hacer que esto suceda de manera confiable al ejecutar Proxmox y usar contenedores. Específicamente, si moví una cantidad considerable de datos o moví realmente cualquier cantidad de datos muy recientemente, apagar o detener el contenedor producirá este error. Lo he visto con más frecuencia cuando uso contenedores que montan mi NAS dentro, pero eso podría ser una coincidencia.

# uname -a
Linux proxmox01 4.4.40-1-pve #1 SMP PVE 4.4.40-82 (Thu, 23 Feb 2017 15:14:06 +0100) x86_64 GNU/Linux

# cat /etc/debian_version
8.7

Y desde dentro de Proxmox:

proxmox-ve: 4.4-82 (running kernel: 4.4.40-1-pve)
pve-manager: 4.4-12 (running version: 4.4-12/e71b7a74)
pve-kernel-4.4.35-1-pve: 4.4.35-77
pve-kernel-4.4.40-1-pve: 4.4.40-82
lvm2: 2.02.116-pve3
corosync-pve: 2.4.2-1
libqb0: 1.0-1
pve-cluster: 4.0-48
qemu-server: 4.0-109
pve-firmware: 1.1-10
libpve-common-perl: 4.0-92
libpve-access-control: 4.0-23
libpve-storage-perl: 4.0-76
pve-libspice-server1: 0.12.8-2
vncterm: 1.3-1
pve-docs: 4.4-3
pve-qemu-kvm: 2.7.1-4
pve-container: 1.0-94
pve-firewall: 2.0-33
pve-ha-manager: 1.0-40
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u3
lxc-pve: 2.0.7-3
lxcfs: 2.0.6-pve1
criu: 1.6.0-1
novnc-pve: 0.5-8
smartmontools: 6.5+svn4324-1~pve80
zfsutils: 0.6.5.9-pve15~bpo80

Vale la pena señalar que Docker no está instalado en este sistema y nunca lo ha estado. Me complace proporcionar cualquier información que la comunidad necesite para solucionar este problema, solo dígame qué comandos ejecutar.

Puedo reproducir esto en centos 7.3 ejecutándose como un nodo trabajador de enjambre que ejecuta dtr con un volumen nfs montado mapeado

Si vienes aquí

El problema que se discute aquí es un error del kernel y aún no se ha solucionado. Hay una serie de opciones que pueden ayudar en _algunas_ situaciones, pero no en todas (lo más probable es que sea una combinación de problemas que desencadenan el mismo error)

No dejes comentarios de "Yo también tengo esto"

"Yo también tengo esto" no ayuda a resolver el error. solo deje un comentario si tiene información que pueda ayudar a resolver el problema (en cuyo caso, proporcionar un parche para el núcleo en sentido ascendente puede ser el mejor paso).

Si desea informarle que también tiene este problema, use el botón "Me gusta" en la descripción superior:

Si desea mantenerse informado sobre las actualizaciones, utilice el _botón de suscripción_.

Cada comentario aquí envía un correo electrónico / notificación a más de 3000 personas . No quiero bloquear la conversación sobre este tema, porque aún no se ha resuelto, pero podría verse obligado a hacerlo si lo ignora.

¡Gracias!

Eso está muy bien, pero ¿cuáles son exactamente las opciones que ayudan? Este problema nos está causando problemas en producción, por lo que me gustaría hacer cualquier solución que sea necesaria para solucionar el error del kernel.

Si alguien de Docker tiene tiempo para probar la solución alternativa de Kubernetes,
avísame y te lo indicaremos. No puedo extraer los cambios
y parchearlos yo mismo en Docker, ahora mismo.

El jueves 9 de marzo de 2017 a las 7:46 a. M., Matthew Newhook [email protected]
escribió:

Eso está muy bien, pero ¿cuáles son exactamente las opciones que ayudan?
Este problema nos está causando problemas en producción, así que me gustaría hacer lo que sea
soluciones que son necesarias para solucionar el error del kernel.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/docker/issues/5618#issuecomment-285388243 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AFVgVGdH5VX_oFWkImyo_TvlIuhmwMepks5rkB7MgaJpZM4B4L4Z
.

@thockin gracias. Estaba siguiendo el problema de relaciones públicas / en Kubernetes con la solución alternativa del modo de horquilla. Pero durante los muchos idas y venidas, perdí la pista si la solución de hecho elimina este problema.
(Según tengo entendido, hay diferentes escenarios que causan la inconsistencia del recuento de referencias en el kernel).

Si puede señalarme el PR que cree que soluciona el problema en K8s, trabajaré para que esto se repare en la ventana acoplable al menos para el caso de desactivar el proxy de área de usuario de forma predeterminada. (Y podemos probarlo usando los pasos de reproducción del estrés de la ventana acoplable).

No estoy seguro de tener un solo PR, pero puedes ver el estado actual. Comienzo
aquí:

https://github.com/kubernetes/kubernetes/blob/9a1f0574a4ad5813410b445330d7240cf266b322/pkg/kubelet/network/kubenet/kubenet_linux.go#L345

El sábado 11 de marzo de 2017 a las 10:49 p.m., Madhu Venugopal [email protected]
escribió:

@thockin https://github.com/thockin gracias. Estaba siguiendo el
PR / problema en Kubernetes con la solución alternativa del modo de horquilla. Pero durante el
muchos de ida y vuelta, perdí la pista si la solución de hecho se deshace de este
asunto ?
(Según tengo entendido, hay diferentes escenarios que hacen que el recuento de referencias
inconsistencia en el kernel).

Si puede indicarme el PR que cree que aborda el problema en K8,
Trabajaré para obtener este parche en la ventana acoplable al menos para el caso de girar
userland-proxy desactivado de forma predeterminada. (Y podemos probarlo usando el docker-stress
pasos de reproducción).

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/docker/issues/5618#issuecomment-285926217 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AFVgVIlGs_QccxS6YYQiLNybddDzB4yUks5rk5VogaJpZM4B4L4Z
.

Hola a todos, para que quede claro, todo lo que hace la "solución alternativa de Kubernetes" es habilitar el modo promiscuo en el puente subyacente. Puede lograr lo mismo con ip link set <bridgename> promisc on usando iproute2. Disminuye la probabilidad de encontrar el error, pero es posible que no lo elimine por completo.

Ahora, en teoría, esto no debería funcionar ... pero por alguna razón, el modo promiscuo parece hacer que el dispositivo se desmonte lo suficientemente lento como para que no tengas una carrera para disminuir el contador de referencias. Quizás uno de los colaboradores de Kurbernetes pueda intervenir aquí si está en este hilo.

Puedo verificar que la solución alternativa (NO FIX) funciona usando mi reproducción específica del entorno. Realmente no puedo verificar que ayude si está usando los controladores IPVLAN o MACVLAN (usamos macvlan en prod) porque parece muy difícil lograr que esas configuraciones produzcan este error. ¿Alguien más con una reproducción puede intentar verificar la solución?

Hola a todos, intenté depurar el problema del kernel, tenía una cadena de correo electrónico en la lista de correo "netdev", así que solo quería publicar algunos hallazgos aquí.

https://www.spinics.net/lists/netdev/msg416310.html

El problema que estamos viendo es que

unregister_netdevice: waiting for lo to become free. Usage count = 1

durante el cierre del contenedor. Cuando inspecciono el espacio de nombres de la red del contenedor, parece que el dispositivo eth0 ya se ha eliminado, pero solo queda allí el dispositivo lo . Y hay otra estructura que contiene la referencia para ese dispositivo.

Después de investigar un poco, resulta que la "cosa" que contiene la referencia es una de las "caché de enrutamiento" ( struct dst_entry ). Y algo está impidiendo que se gc'ed ese dst_entry en particular (el recuento de referencias para dst_entry es mayor que 0). Así que registré cada dst_hold() (incremento del recuento de referencias dst_entry en 1) y dst_release() (decremento del recuento de referencias dst_entry en 1), y de hecho hay más llamadas dst_hold() dst_release() .

Aquí están los registros adjuntos: kern.log.zip

Resumen:

• la interfaz lo se renombró a lodebug para facilitar el greping
• el recuento de referencia para dst_entry comienza con 1
• el recuento de referencia para dst_entry (que contiene la referencia para lo) al final es 19
• hay un total de 258041 dst_hold() llamadas y 258023 un total de dst_release() llamadas
• en las llamadas 258041 dst_hold() , hay 88034 udp_sk_rx_dst_set() (que luego son llamadas dst_hold() ), 152536 inet_sk_rx_dst_set() y 17471 __sk_add_backlog()
• en las llamadas 258023 dst_release() , hay 240551 inet_sock_destruct() y 17472 refdst_drop()

Hay más llamadas udp_sk_rx_dst_set() y inet_sk_rx_dst_set() en total que inet_sock_destruct() , por lo que sospechar que hay algunos sockets están en un estado de "limbo" y algo impide que se destruyan.

ACTUALIZAR:
Resulta que los sockets ( struct sock ) se crean y destruyen correctamente, pero para algunos de los sockets TCP inet_sk_rx_dst_set() se llaman varias veces en el mismo dst , pero solo hay uno correspondiente inet_sock_destruct() para liberar la referencia al dst .

Aquí está la solución alternativa de CentOS 7.3 que me solucionó:

yum --enablerepo=centosplus install kernel-plus
egrep ^menuentry /etc/grub2.cfg | cut -f 2 -d \’
grub2-set-default 0
reboot

Aquí está el parche que lo resuelve:
https://bugs.centos.org/view.php?id=12711&nbn=1

ACTUALIZACIÓN: Esto resultó no resolver el problema de forma permanente. Apareció de nuevo varias horas después con el siguiente mensaje en la pared:
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

@adrianotto - para aclarar: ¿El parche del kernel de CentOS resuelve esto? ¿Solo tiene curiosidad por saber si tanto su solución alternativa como la ruta del kernel de referencia no resolvieron esto de forma permanente?

@stayclassychicago @adrianotto Ese parche solo aborda una de las condiciones de carrera que pueden desencadenar el problema del "recuento de uso" en el kernel. Es solo mi solución retroactiva de algo en los kernels 4.x ya. Puede resolver sus problemas, por lo que vale la pena intentarlo.

@stayclassychicago antes de probar el kernel 3.10.0-514.10.2.el7.centos.plus.x86_64 obtenía el kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1 mucha regularidad, casi cada vez que ejecutaba un contenedor con docker run --rm ... cuando salía del contenedor. Después de la actualización y reinicio del kernel, se detuvo por completo durante muchas horas y luego regresó. Ahora, la mitad de las veces que elimino contenedores, funciona correctamente, donde solía equivocarse mucho tiempo. No sé con certeza si el nuevo kernel está ayudando, pero no hace daño.

Parece que es muy fácil de reproducir cuando hay una interfaz de enlace LACP en la máquina. Tenemos un clúster de enjambre de 3 nodos, los 3 con una interfaz de enlace LACP configurada, y este problema básicamente no nos permite trabajar con el clúster. Tenemos que reiniciar los nodos cada 15-20 minutos.

Confirmado: tan pronto como eliminé la vinculación LACP de las interfaces (que se usaron como interfaces principales), todo funciona bien durante más de 12 horas. Se usa para romper cada ~ 30 minutos.

Esto es reproducible en Linux containerhost1 4.9.0-0.bpo.2-amd64 #1 SMP Debian 4.9.18-1~bpo8+1 (2017-04-10) x86_64 GNU/Linux con Docker version 17.04.0-ce, build 4845c56 ejecutándose en modo privilegiado cuando tenemos montajes cifs abiertos. Cuando el contenedor se detiene con los montajes abiertos, Docker deja de responder y obtenemos el kernel:[ 1129.675495] unregister_netdevice: waiting for lo to become free. Usage count = 1 -error.

ubuntu 16.04 (kernel 4.4.0-78-generic) todavía tiene el problema. Y cuando suceda, cualquier aplicación que intente crear un nuevo espacio de nombres de red a través de clone syscall se atascará

[ 3720.752954]  [<ffffffff8183c8f5>] schedule+0x35/0x80
[ 3720.752957]  [<ffffffff8183cb9e>] schedule_preempt_disabled+0xe/0x10
[ 3720.752961]  [<ffffffff8183e7d9>] __mutex_lock_slowpath+0xb9/0x130
[ 3720.752964]  [<ffffffff8183e86f>] mutex_lock+0x1f/0x30
[ 3720.752968]  [<ffffffff8172ba2e>] copy_net_ns+0x6e/0x120
[ 3720.752972]  [<ffffffff810a169b>] create_new_namespaces+0x11b/0x1d0
[ 3720.752975]  [<ffffffff810a17bd>] copy_namespaces+0x6d/0xa0
[ 3720.752980]  [<ffffffff8107f1d5>] copy_process+0x905/0x1b70
[ 3720.752984]  [<ffffffff810805d0>] _do_fork+0x80/0x360
[ 3720.752988]  [<ffffffff81080959>] SyS_clone+0x19/0x20
[ 3720.752992]  [<ffffffff81840a32>] entry_SYSCALL_64_fastpath+0x16/0x71

La única solución es reiniciar la máquina.

Encontré este problema al montar el volumen NFS en un contenedor privilegiado y luego reiniciar el contenedor.
Me parece que este problema nunca ocurrió en RHEL 7 con el mismo procedimiento.

$ docker version
Client:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-common-1.12.6-6.gitae7d637.fc25.x86_64
 Go version:      go1.7.4
 Git commit:      ae7d637/1.12.6
 Built:           Mon Jan 30 16:15:28 2017
 OS/Arch:         linux/amd64

Server:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-common-1.12.6-6.gitae7d637.fc25.x86_64
 Go version:      go1.7.4
 Git commit:      ae7d637/1.12.6
 Built:           Mon Jan 30 16:15:28 2017
 OS/Arch:         linux/amd64

Red Hat afirma tener una instancia de este error corregida a partir del lanzamiento de kernel-3.10.0-514.21.1.el7. Supongo que actualizarán la solución lo antes posible y volverán a basarse en 4.12. Este paquete también está disponible en CentOS 7.

Documentación relacionada con la solución (se necesita acceso a RHN):
https://access.redhat.com/articles/3034221
https://bugzilla.redhat.com/show_bug.cgi?id=1436588

Del artículo:
"En caso de una dirección IPv6 duplicada o un problema con la configuración de una dirección, se produjo una condición de carrera. Esta condición de carrera a veces provocó una fuga de recuento de referencias de dirección. En consecuencia, los intentos de anular el registro de un dispositivo de red fallaron con el siguiente mensaje de error:" unregister_netdevice: esperando para ser libre. Recuento de uso = 1 ". Con esta actualización, el código fuente subyacente se ha corregido y los dispositivos de red ahora se anulan del registro como se esperaba en la situación descrita".

Ya implementé esta solución en todos los sistemas de nuestro grupo de PaaS, y ya han pasado 2 días sin que se produjera el error. Anteriormente, teníamos al menos un sistema congelado por día. Informaré aquí si volvemos a encontrar el error.

Tengo la versión de kernel 3.10.0-514.21.1.el7.x86_64 y todavía tengo el mismo síntoma.

Message from syslogd<strong i="6">@docker</strong> at May 26 22:02:26 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1
# uname -a
Linux docker 3.10.0-514.21.1.el7.x86_64 #1 SMP Thu May 25 17:04:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
# uptime
 22:03:10 up 35 min,  3 users,  load average: 0.16, 0.07, 0.06

@adrianotto Aparentemente, hay varias formas de

@bcdonadio Si miras https://git.centos.org/commitdiff/rpms!kernel.git/b777aca52781bc9b15328e8798726608933ceded , verás que el error https://bugzilla.redhat.com/show_bug.cgi?id=1436588 es "arreglado" por este cambio:

+- [net] ipv6: addrconf: fix dev refcont leak when DAD failed (Hangbin Liu) [1436588 1416105]

Que está en el kernel ascendente desde 4.8, creo (https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d). Y 4.9 y 4.10 tienen este error presente, por lo que RedHat acaba de actualizar algunas de las correcciones desde el principio, que probablemente solucionen algunos problemas, pero definitivamente no todos.

@bcdonadio Puedo reproducir el error en mi sistema ejecutando este script de prueba una vez por hora desde cron:

#!/bin/sh

TAG=`date +%F_%H_%M_%S_UTC`
docker pull centos:centos6
docker run --rm adrianotto/centos6 yum check-update -q > package_updates.txt
LINES=`wc -l < package_updates.txt`

if [ $LINES -eq 0 ] ; then
        rm -f package_updates.txt
        echo "No packages need to be updated"
        exit 0
fi

docker run --rm adrianotto/centos6 rpm -a -q > old_packages.txt
docker build -t temp:$TAG .
docker run --rm temp:$TAG rpm -a -q > new_packages.txt
docker rmi temp:$TAG

Este script solo está produciendo una lista de paquetes usando una imagen en el registro de Docker, y otra usando una construida localmente para poder compararlos. El Dockerfile es solo esto:

FROM centos:centos6
MAINTAINER Adrian Otto
RUN yum clean all && yum update -y && yum clean all

2-4 minutos después, syslog recibe este mensaje:

Message from syslogd<strong i="13">@docker</strong> at May 27 16:51:55 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 0

En la última ocurrencia sucedió unos minutos después de que ejecuté el script manualmente. Supongo que después de que transcurre un tiempo de espera después de que se intenta la eliminación del contenedor, se genera la condición de error.

Estoy seguro de que la condición de error es intermitente, porque el script anterior se ejecuta como un trabajo cron en: 00 después de cada error. Aquí hay una muestra de la salida de error que registró syslog:

May 26 01:02:44 docker kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
May 26 02:02:22 docker kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
May 26 02:02:32 docker kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
May 26 03:02:18 docker kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
May 26 03:02:28 docker kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
May 26 03:02:38 docker kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
May 26 04:03:14 docker kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
May 26 05:02:25 docker kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
May 26 05:02:35 docker kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
May 26 06:03:31 docker kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
May 26 06:03:41 docker kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
May 26 06:03:51 docker kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
May 26 06:04:02 docker kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
May 26 09:03:04 docker kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1

Por lo tanto, sucede en algún lugar en el rango de 2 a 4 minutos después de que los contenedores se ejecutan y salen y Docker los elimina debido a la marca --rm. También observe en el registro anterior que no hay un error para cada contenedor que se ejecuta / elimina, pero es bastante consistente.

¿Sería posible que alguien viera si este parche mejora las cosas?

https://patchwork.ozlabs.org/patch/768291/

@hlrichardson ¡ Esto realmente lo parece! Intentaré volver a exportarlo a nuestro kernel 3.16 o actualizar servidores específicos y compilar el kernel 4.9 con este parche mañana, veremos cómo va.

Sin embargo, después de verificar las referencias de este parche de confirmación (https://github.com/torvalds/linux/commit/0c1d70af924b966cc71e9e48920b2b635441aa50), se comprometió en el kernel 4.6, mientras que el problema estaba allí incluso antes :(

Ah, tal vez no esté relacionado, a menos que haya múltiples causas (desafortunadamente, hay muchas formas en las que este tipo de error puede desencadenarse, por lo que es una posibilidad).

Personalmente, abordamos al menos varios problemas aquí; en algunos de ellos, estos
Los registros "unregister_netdevice" simplemente desaparecen después de un período de tiempo y
Los contenedores Docker pueden funcionar bien, mientras que en otros, todos los contenedores.
se atasca y es necesario reiniciar el servidor.

En realidad, no usamos vxlan en servidores que tienen estos problemas, usamos
Puentes simples y reenvío de puertos (ocurre independientemente del proxy de usuario
ajustes).

El 30 de mayo de 2017 22:54, "hlrichardson" [email protected] escribió:

Ah, tal vez no esté relacionado, a menos que haya múltiples causas.
(Desafortunadamente, hay muchas formas en que se puede activar este tipo de error, por lo que
esa es una posibilidad).

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/moby/moby/issues/5618#issuecomment-304989068 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAGqoDHe1n3h9_eJ2kmeWcbhKRCX6rZoks5r_HPbgaJpZM4B4L4Z
.

De acuerdo, si no está utilizando túneles vxlan, definitivamente no ayudará.

Por cierto, si ve una sola instancia del mensaje "unregister_netdevice" cuando se elimina un espacio de nombres de red (salida del contenedor), debe considerarse una situación normal en la que algo que hace referencia a un dispositivo de red se limpió más o menos al mismo tiempo que el espacio de nombres
estaba siendo eliminado.

El caso más grave es cuando este mensaje se repite cada 10 segundos y nunca cesa ...
en este caso, un bloqueo global se mantiene para siempre, y dado que este bloqueo debe adquirirse siempre que la red
se agrega o elimina un espacio de nombres, cualquier intento de crear o eliminar un espacio de nombres de red también
cuelga para siempre.

Si tiene una forma bastante sencilla de reproducir el segundo tipo de problema, me interesaría
echando un vistazo.

@hlrichardson Estamos viendo el segundo caso que mencionaste anteriormente en un grupo de nuestros servidores, es decir, el mensaje se repite cada 10 segundos. ¿Qué información quieres que comparta?

Ver esto en Fedora 25 mientras probaba y construía contenedores centos: 7 mientras usaba yum. Yum no pudo terminar de descargar la base de datos del paquete y se colgó indefinidamente porque la red dejó de funcionar de una manera extraña.

Hola tios,

Existe un parche potencial para el error del kernel (o al menos uno de los errores) en la lista de correo de net-dev de Linux:

https://www.spinics.net/lists/netdev/msg442211.html

Se fusionó en árbol de red, en cola para árbol estable.

Según https://github.com/torvalds/linux/commit/d747a7a51b00984127a88113cdbbc26f91e9d815 , ¡está en 4.12 (que se lanzó ayer)!

@fxposter @kevinxucs Intentaré hacer una copia de seguridad de esto al kernel de CentOS actual mañana.

Estoy ejecutando 4.12 (de http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12/) y todavía presiono esto, por lo que torvalds / linux @ d747a7a no debe ser la solución completa.

$ uname -r
4.12.0-041200-generic

Ryan, ¿tienes una forma confiable de reproducirse?

El 6 de julio de 2017 a las 4:29 pm, "Ryan Campbell" [email protected] escribió:

Estoy ejecutando 4.12 (de http://kernel.ubuntu.com/~
kernel-ppa / mainline / v4.12 /) y sigo presionando esto, entonces torvalds / linux @
d747a7a https://github.com/torvalds/linux/commit/d747a7a no debe ser
la solución completa.

$ uname -r
4.12.0-041200-genérico

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/moby/moby/issues/5618#issuecomment-313413120 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAdcPCbVPDjPw6va-N5dM7CjYn2W4Bodks5sLO9ZgaJpZM4B4L4Z
.

@justincormack Lamentablemente, no tengo un ejemplo mínimo que pueda compartir, pero tenemos un conjunto de pruebas que crea y destruye muchos contenedores y, por lo general, me encuentro con este problema (comandos de docker colgantes, una gran cantidad de waiting for lo to become free en syslog) después de solo unas pocas iteraciones.

@campbellr He intentado reproducir esto ahora tres veces y pasé una buena parte de esta semana con poca suerte. Me las arreglé para recibir los mensajes waiting for lo to become free un par de veces, pero sin fallas / bloqueos después. Estoy tratando de reducir el caso de prueba simplemente creando un espacio de nombres de red y veth interfaces.

En su suite de pruebas:

• ¿Sus contenedores tienen mucha actividad en la red? Si es así, ¿qué dirección es predominante?
• ¿Qué tipo de máquina está ejecutando? (Número de núcleos, es una máquina virtual, etc.)
• ¿Creas muchos contenedores al mismo tiempo?
• ¿Sus contenedores salen normalmente o se estrellan?

Incluso las respuestas parciales a lo anterior pueden ayudar a reducirlo ...
Gracias

@rn Docker ya no se bloqueará, ya que establece un tiempo de espera en la solicitud de

Todavía no he tenido la oportunidad de probar en 4.12, pero pude reproducir de manera confiable en las instancias de kvm en vultr. Estoy corriendo enjambre y mis trabajadores de Chrome sin cabeza causan los problemas cuando fallan los controles de salud o fallan con regularidad. Por supuesto, en este punto, he rastreado a todos los bloqueadores que manejan los errores de red de manera limpia, etc., por lo que veo waiting for lo to become free pero no lo suficiente como para colgar cosas durante un par de semanas.

Entonces, parece que las cosas que ayudan a reproducir son escenarios de redes más complejos combinados con grandes cantidades de tráfico hacia los contenedores, reciclaje constante de contenedores y kvm.

@rn Me las arreglé para reducir esto a un contenedor específico en nuestro conjunto de pruebas y pude reproducir con los siguientes pasos:

1. start container (un servicio web interno basado en tornado; estoy tratando de extraer un ejemplo mínimo que todavía golpea esto)
2. realizar una solicitud al servicio web que se ejecuta en el contenedor
3. esperar respuesta
4. matar contenedor

Después de 3 o 4 iteraciones de esto, termino obteniendo waiting for lo to become free y en la siguiente iteración docker run falla con docker: Error response from daemon: containerd: container did not start before the specified timeout.

¿Sus contenedores tienen mucha actividad en la red? Si es así, ¿qué dirección es predominante?

Una cantidad bastante pequeña. En los pasos mencionados anteriormente, la solicitud http es una pequeña cantidad de json y la respuesta es un blob binario que ronda los 10 MB.

¿Qué tipo de máquina está ejecutando? (Número de núcleos, es una máquina virtual, etc.)

Esto está en una máquina de escritorio de 4 núcleos (sin VM)

¿Creas muchos contenedores al mismo tiempo?

No, todo se hace en serie.

¿Sus contenedores salen normalmente o se estrellan?

Se detienen con docker stop

1. start container (un servicio web interno basado en tornado; estoy tratando de extraer un ejemplo mínimo que todavía golpea esto)
2. realizar una solicitud al servicio web que se ejecuta en el contenedor
3. esperar respuesta
4. matar contenedor

Pasé un tiempo desmontando el contenedor y resultó que el servicio web no tenía nada que ver con el error. Lo que parece desencadenar esto en mi caso es montar un recurso compartido NFS dentro de un contenedor (que se ejecuta con --privileged ).

En mi escritorio, puedo reproducir de manera confiable simplemente ejecutando lo siguiente unas cuantas veces:

$ docker run -it --rm --privileged alpine:latest /bin/mount -o nolock -o async -o vers=3 <my-nfs-server>:/export/foo /mnt

Usuarios de Kubernetes, abrí un problema a _kops_ para lanzar la próxima AMI de Kubernetes con la versión 4.12 del Kernel. Bienvenido a comprobarlo: https://github.com/kubernetes/kops/issues/2901

También encontré esto en centos 7.3 con el kernel de host 3.10.0-514.6.1.el7.x86_64 y docker-ce-17.06.0.ce-1.el7.centos.x86_64.

@FrankYu eso no es útil. Para participar de manera útil en este hilo, proporcione una forma exacta de reproducir este problema y pruébelo en un kernel moderno. 3.10 fue lanzado hace cuatro años, estamos discutiendo si está arreglado o parcialmente en un lanzamiento de hace cuatro días.

@danielgusmao nuestro RancherOS y AWS ECS AMI linux OS ya tienen esa 'solución' en su lugar (probablemente era la predeterminada) y no nos resuelve el problema. Seguimos viendo que el mensaje aparece en los registros todo el tiempo. Probablemente, la única esperanza es que el parche del kernel se publique ampliamente. Aunque busqué alrededor y no puedo ver ninguna evidencia de un progreso serio hacia eso todavía en RedHat / Centos / AWS linux bugzillas y foros.

Para ser claros, el mensaje en sí es benigno , es el bloqueo del kernel después de los mensajes informados por el OP que no lo es.

El comentario en el código, de donde proviene este mensaje, explica lo que está sucediendo. Básicamente, cada usuario, como la pila de IP) de un dispositivo de red (como el final de veth par dentro de un contenedor) incrementa un recuento de referencia en la estructura del dispositivo de red cuando está usando el dispositivo de red. Cuando se quita el dispositivo (p. Ej., Cuando se quita el contenedor), se notifica a cada usuario para que pueda realizar alguna limpieza (p. Ej., Cerrar tomas abiertas, etc.) antes de disminuir el recuento de referencias. Debido a que esta limpieza puede llevar algún tiempo, especialmente bajo una carga pesada (mucha interfaz, muchas conexiones, etc.), el kernel puede imprimir el mensaje aquí de vez en cuando .

Si un usuario de un dispositivo de red nunca reduce el recuento de referencias, alguna otra parte del kernel determinará que la tarea que espera la limpieza está bloqueada y se bloqueará. Es solo este bloqueo lo que indica un error del kernel (algún usuario, a través de alguna ruta de código, no disminuyó el recuento de referencias). Ha habido varios errores de este tipo y se han corregido en el kernel moderno (y posiblemente se han adaptado a los más antiguos). He escrito bastantes pruebas de estrés (y continúo escribiéndolas) para desencadenar tales bloqueos, pero no he podido reproducir en núcleos modernos (sin embargo, hago el mensaje anterior).

Por favor, solo informe sobre este problema si su kernel realmente falla, y entonces estaríamos muy interesados ​​en:

• versión del kernel (salida de uname -r )
• Distribución / versión de Linux
• ¿Tiene la última versión del kernel de su proveedor de Linux?
• Configuración de red (puente, superposición, IPv4, IPv6, etc.)
• Descripción de la carga de trabajo (qué tipo de contenedores, qué tipo de carga de red, etc.)
• E idealmente una reproducción simple

Gracias

[ @thaJeztah ¿ podrías cambiar el título a algo como kernel crash after "unregister_netdevice: waiting for lo to become free. Usage count = 3" para hacerlo más explícito?]

Debería arreglarse en el kernel 4.12 o más tarde. Por favor, compruebe. https://access.redhat.com/solutions/3105941
y enlace al parche https://github.com/torvalds/linux/commit/d747a7a51b00984127a88113cdbbc26f91e9d815

@drweber también encontrará este parche en las próximas versiones estables (por ahora 4.11.12, 4.9.39, 4.4.78, 3.18.62)

@rn

Si un usuario de un dispositivo de red nunca reduce el recuento de referencias, alguna otra parte del kernel determinará que la tarea que espera la limpieza está bloqueada y se bloqueará. Es solo este bloqueo lo que indica un error del kernel (algún usuario, a través de alguna ruta de código, no disminuyó el recuento de referencias). Ha habido varios errores de este tipo y se han corregido en el kernel moderno (y posiblemente se han adaptado a los más antiguos). He escrito bastantes pruebas de estrés (y continúo escribiéndolas) para desencadenar tales bloqueos, pero no he podido reproducir en núcleos modernos (sin embargo, hago el mensaje anterior).

Solo informe sobre este problema si su kernel realmente falla ...

Tenemos un problema ligeramente diferente en nuestro entorno sobre el que espero obtener alguna aclaración (kernel 3.16.0-77-generic, Ubuntu 14.04, docker 1.12.3-0 ~ trusty. Tenemos miles de hosts que ejecutan docker, 2 -3 contenedores por host, y estamos viendo esto en <1% del total de hosts que ejecutan Docker).

En realidad, nunca vemos que el kernel se bloquee, sino que (como los reporteros originales, por lo que puedo decir) el proceso dockerd ha desaparecido. Upstart (usando el trabajo /etc/init/docker.conf del paquete upstream) no iniciará un nuevo proceso dockerd porque cree que ya se está ejecutando ( start: Job is already running: docker ) y está intentando detener el upstart el trabajo también falla ( docker start/killed, process <pid of defunct process> ).

$ ps -ely
S   UID   PID  PPID  C PRI  NI   RSS    SZ WCHAN  TTY          TIME CMD
...
Z     0 28107     1  0  80   0     0     0 -      ?        00:18:05 dockerd <defunct>

Dado que la mayoría de las veces corremos con redes de puente (en un dispositivo de puente personalizado) en dmesg , vemos un mensaje ligeramente diferente que se refiere a la interfaz virtual:

[7895942.484851] unregister_netdevice: waiting for vethb40dfbc to become free. Usage count = 1
[7895952.564852] unregister_netdevice: waiting for vethb40dfbc to become free. Usage count = 1
[7895962.656984] unregister_netdevice: waiting for vethb40dfbc to become free. Usage count = 1

Debido a que el advenedizo parece negarse a reiniciar dockerd o reconocer que el proceso que se estaba ejecutando anteriormente es un zombi, la única solución que hemos encontrado es reiniciar el host.

Si bien nuestro resultado parece diferente (el kernel no falla), la causa raíz suena igual o similar. Entonces, ¿no es este el mismo problema? ¿Existe alguna solución alternativa o forma de hacer que el trabajo docker advenedizo se vuelva a ejecutar cuando esto ocurra?

@campbellr Puedo reproducir este problema con su enfoque en el kernel 4.12.2-1.
Por cierto, si desmonto el almacenamiento NFS antes de que se detenga el contenedor, este problema no sucederá.

el mismo problema.

[root<strong i="6">@docker1</strong> ~]# cat /etc/redhat-release 
CentOS Linux release 7.3.1611 (Core) 
[root<strong i="7">@docker1</strong> ~]# uname  -r
3.10.0-514.26.2.el7.x86_64
[root<strong i="8">@docker1</strong> ~]# docker version
Client:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-1.12.6-32.git88a4867.el7.centos.x86_64
 Go version:      go1.7.4
 Git commit:      88a4867/1.12.6
 Built:           Mon Jul  3 16:02:02 2017
 OS/Arch:         linux/amd64

Server:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-1.12.6-32.git88a4867.el7.centos.x86_64
 Go version:      go1.7.4
 Git commit:      88a4867/1.12.6
 Built:           Mon Jul  3 16:02:02 2017
 OS/Arch:         linux/amd64

Hola,

Acabo de crear 2 repositorios https://github.com/piec/docker-samba-loop y https://github.com/piec/docker-nfs-loop que contienen la configuración necesaria para reproducir este error

Mis resultados:

• 4.11.3-1-Kernel ARCH (Arch Linux): Genero el error con docker-samba-loop en algunas iteraciones (<10). No puedo reproducirlo con docker-nfs-loop
• 4.11.9-1-ARCH mismos resultados ( versiones )
• 4.12.3-1-ARCH (repositorio de prueba) mismos resultados
• 4.11.11-coreos: mismos resultados para docker-samba-loop , no probé docker-nfs-loop

Espero que esto ayude
Salud

Una solución alternativa es usar --net=host en mi caso. Pero no siempre es una solución aceptable.

@piec , muchas gracias por los detalles. Tengo algunas preguntas más para ti al final de este largo comentario.

Usando la configuración de SMB pude producir una serie de cosas con diferentes núcleos. También intenté esto con la configuración de NFS, pero sin dados.

Todas las pruebas se ejecutan con Docker 17.06.1-ce en HyperKit con una VM configurada con 2 CPU virtuales y 2 GB de memoria (a través de Docker para Mac, pero eso no debería importar). Estoy usando kernels de LinuxKit, porque puedo intercambiarlos fácilmente.

Modifiqué su Dockerfile porque agregué una llamada a date como el primer comando ejecutado y también agregué una llamada a date antes y después de docker run para el cliente.

Experimento 1 (núcleo 4.9.39)

Con 4.9.39 (el último kernel estable 4.9.x) obtengo un bloqueo del kernel:

# while true; do  date;    docker run -it --rm --name client-smb --cap-add=SYS_ADMIN --cap-add DAC_READ_SEARCH --link samba:samba client-smb:1;  date;   sleep 1; done
Thu 27 Jul 2017 14:12:51 BST
+ date
Thu Jul 27 13:12:52 UTC 2017
+ mount.cifs //172.17.0.2/public /mnt/ -o vers=3.0,user=nobody,password=
+ date
Thu Jul 27 13:12:52 UTC 2017
+ ls -la /mnt
total 1028
drwxr-xr-x    2 root     root             0 Jul 27 10:11 .
drwxr-xr-x    1 root     root          4096 Jul 27 13:12 ..
-rwxr-xr-x    1 root     root             3 Jul 27 10:11 bla
+ umount /mnt
+ echo umount ok
umount ok
Thu 27 Jul 2017 14:12:52 BST
Thu 27 Jul 2017 14:12:53 BST

---> First iteration suceeds and then hangs on the docker run

y en dmesg :

[  268.347598] BUG: unable to handle kernel paging request at 0000000100000015
[  268.348072] IP: [<ffffffff8c64ea95>] sk_filter_uncharge+0x5/0x31
[  268.348411] PGD 0 [  268.348517]
[  268.348614] Oops: 0000 [#1] SMP
[  268.348789] Modules linked in:
[  268.348971] CPU: 1 PID: 2221 Comm: vsudd Not tainted 4.9.39-linuxkit #1
[  268.349330] Hardware name:   BHYVE, BIOS 1.00 03/14/2014
[  268.349620] task: ffff8b6ab8eb5100 task.stack: ffffa015c113c000
[  268.349995] RIP: 0010:[<ffffffff8c64ea95>]  [<ffffffff8c64ea95>] sk_filter_uncharge+0x5/0x31
[  268.350509] RSP: 0018:ffffa015c113fe10  EFLAGS: 00010202
[  268.350818] RAX: 0000000000000000 RBX: ffff8b6ab7eee6a8 RCX: 0000000000000006
[  268.351231] RDX: 00000000ffffffff RSI: 00000000fffffffd RDI: ffff8b6ab7eee400
[  268.351636] RBP: ffff8b6ab7eee400 R08: 0000000000000000 R09: 0000000000000000
[  268.352022] R10: ffffa015c101fcb0 R11: 0000000000000000 R12: 0000000000000000
[  268.352409] R13: ffff8b6ab7eee4a8 R14: ffff8b6ab7f8e340 R15: 0000000000000000
[  268.352796] FS:  00007f03f62e3eb0(0000) GS:ffff8b6abc700000(0000) knlGS:0000000000000000
[  268.353234] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  268.353546] CR2: 0000000100000015 CR3: 00000000782d2000 CR4: 00000000000406a0
[  268.353961] Stack:
[  268.354106]  ffffffff8c625054 ffff8b6ab7eee400 ffffa015c113fe88 0000000000000000
[  268.354526]  ffffffff8c74ed96 01000008bc718980 0000000000000000 0000000000000000
[  268.354965]  de66927a28223151 ffff8b6ab4443a40 ffffa015c101fcb0 ffff8b6ab4443a70
[  268.355384] Call Trace:
[  268.355523]  [<ffffffff8c625054>] ? __sk_destruct+0x35/0x133
[  268.355822]  [<ffffffff8c74ed96>] ? unix_release_sock+0x1df/0x212
[  268.356164]  [<ffffffff8c74ede2>] ? unix_release+0x19/0x25
[  268.356454]  [<ffffffff8c62034c>] ? sock_release+0x1a/0x6c
[  268.356742]  [<ffffffff8c6203ac>] ? sock_close+0xe/0x11
[  268.357019]  [<ffffffff8c1f8710>] ? __fput+0xdd/0x17b
[  268.357288]  [<ffffffff8c0f604d>] ? task_work_run+0x64/0x7a
[  268.357583]  [<ffffffff8c003285>] ? prepare_exit_to_usermode+0x7d/0xa4
[  268.357925]  [<ffffffff8c7d2884>] ? entry_SYSCALL_64_fastpath+0xa7/0xa9
[  268.358268] Code: 08 4c 89 e7 e8 fb f8 ff ff 48 3d 00 f0 ff ff 77 06 48 89 45 00 31 c0 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 1f 44 00 00 <48> 8b 46 18 8b 40 04 48 8d 04 c5 28 00 00 00 f0 29 87 24 01 00
[  268.359776] RIP  [<ffffffff8c64ea95>] sk_filter_uncharge+0x5/0x31
[  268.360118]  RSP <ffffa015c113fe10>
[  268.360311] CR2: 0000000100000015
[  268.360550] ---[ end trace 4a7830b42d5acfb3 ]---
[  268.360861] Kernel panic - not syncing: Fatal exception
[  268.361217] Kernel Offset: 0xb000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[  268.361789] Rebooting in 120 seconds..

Algunas veces veo varias iteraciones de lo que hace el kernel 4.11.12, incluidos los mensajes unregister_netdevice (ver más abajo) y luego aparece el fallo del kernel arriba. A veces veo ligeras variaciones del accidente, como:

[  715.926694] BUG: unable to handle kernel paging request at 00000000fffffdc9
[  715.927380] IP: [<ffffffff8664ea95>] sk_filter_uncharge+0x5/0x31
[  715.927868] PGD 0 [  715.928022]
[  715.928174] Oops: 0000 [#1] SMP
[  715.928424] Modules linked in:
[  715.928703] CPU: 0 PID: 2665 Comm: runc:[0:PARENT] Not tainted 4.9.39-linuxkit #1
[  715.929321] Hardware name:   BHYVE, BIOS 1.00 03/14/2014
[  715.929765] task: ffff931538ef4140 task.stack: ffffbcbbc0214000
[  715.930279] RIP: 0010:[<ffffffff8664ea95>]  [<ffffffff8664ea95>] sk_filter_uncharge+0x5/0x31
[  715.931043] RSP: 0018:ffffbcbbc0217be0  EFLAGS: 00010206
[  715.931487] RAX: 0000000000000000 RBX: ffff931532a662a8 RCX: 0000000000000006
[  715.932043] RDX: 00000000ffffffff RSI: 00000000fffffdb1 RDI: ffff931532a66000
[  715.932612] RBP: ffff931532a66000 R08: 0000000000000000 R09: 0000000000000000
[  715.933181] R10: ffff9315394f2990 R11: 000000000001bb68 R12: ffff931532a66000
[  715.933725] R13: ffff9315328060a8 R14: ffff931532a66340 R15: 0000000000000000
[  715.934258] FS:  0000000000000000(0000) GS:ffff93153c600000(0000) knlGS:0000000000000000
[  715.934857] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  715.935286] CR2: 00000000fffffdc9 CR3: 0000000052c09000 CR4: 00000000000406b0
[  715.935822] Stack:
[  715.935974]  ffffffff86625054 ffff931532806000 ffffbcbbc0217c58 ffff931532a66000
[  715.936560]  ffffffff8674ed37 0100000800000282 0000000000000000 0000000000000000
[  715.937173]  5de0b9a3a313c00b ffff9315346f5080 ffff9315394f2990 ffff9315346f50b0
[  715.937751] Call Trace:
[  715.937982]  [<ffffffff86625054>] ? __sk_destruct+0x35/0x133
[  715.938608]  [<ffffffff8674ed37>] ? unix_release_sock+0x180/0x212
[  715.939130]  [<ffffffff8674ede2>] ? unix_release+0x19/0x25
[  715.939517]  [<ffffffff8662034c>] ? sock_release+0x1a/0x6c
[  715.939907]  [<ffffffff866203ac>] ? sock_close+0xe/0x11
[  715.940277]  [<ffffffff861f8710>] ? __fput+0xdd/0x17b
[  715.940635]  [<ffffffff860f604d>] ? task_work_run+0x64/0x7a
[  715.941072]  [<ffffffff860e148a>] ? do_exit+0x42a/0x8e0
[  715.941472]  [<ffffffff8674edfa>] ? scm_destroy+0xc/0x25
[  715.941880]  [<ffffffff867504e0>] ? unix_stream_sendmsg+0x2dd/0x30b
[  715.942357]  [<ffffffff860e19aa>] ? do_group_exit+0x3c/0x9d
[  715.942780]  [<ffffffff860eac41>] ? get_signal+0x45d/0x4e2
[  715.943210]  [<ffffffff86621640>] ? sock_sendmsg+0x2d/0x3c
[  715.943618]  [<ffffffff8602055a>] ? do_signal+0x36/0x4c9
[  715.944017]  [<ffffffff861f64c7>] ? __vfs_write+0x8f/0xcc
[  715.944416]  [<ffffffff861f7100>] ? vfs_write+0xbb/0xc7
[  715.944809]  [<ffffffff8600326c>] ? prepare_exit_to_usermode+0x64/0xa4
[  715.945295]  [<ffffffff867d2884>] ? entry_SYSCALL_64_fastpath+0xa7/0xa9
[  715.945789] Code: 08 4c 89 e7 e8 fb f8 ff ff 48 3d 00 f0 ff ff 77 06 48 89 45 00 31 c0 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 1f 44 00 00 <48> 8b 46 18 8b 40 04 48 8d 04 c5 28 00 00 00 f0 29 87 24 01 00
[  715.947701] RIP  [<ffffffff8664ea95>] sk_filter_uncharge+0x5/0x31
[  715.948112]  RSP <ffffbcbbc0217be0>
[  715.948292] CR2: 00000000fffffdc9
[  715.948467] ---[ end trace 2d69bea56725fd5f ]---
[  715.948722] Kernel panic - not syncing: Fatal exception
[  715.949059] Kernel Offset: 0x5000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[  715.949595] Rebooting in 120 seconds..

Los bloqueos están en el código de socket de dominio de Unix y son similares / idénticos a lo que es
informado aquí , aunque con este nuevo caso de prueba es mucho más fácil de reproducir.

Experimento 2 (kernel 4.11.12)

Con 4.11.12 (que es el último estable de la serie 4.11) no veo fallas, pero es realmente lento (anotaciones en línea con ---> ):

# while true; do  date;    docker run -it --rm --name client-smb --cap-add=SYS_ADMIN --cap-add DAC_READ_SEARCH --link samba:samba client-smb:1;  date;   sleep 1; done
Thu 27 Jul 2017 13:48:04 BST
+ date
Thu Jul 27 12:48:05 UTC 2017
+ mount.cifs //172.17.0.2/public /mnt/ -o vers=3.0,user=nobody,password=
+ date
Thu Jul 27 12:48:05 UTC 2017
+ ls -la /mnt
total 1028
drwxr-xr-x    2 root     root             0 Jul 27 10:11 .
drwxr-xr-x    1 root     root          4096 Jul 27 12:48 ..
-rwxr-xr-x    1 root     root             3 Jul 27 10:11 bla
+ umount /mnt
+ echo umount ok
umount ok
Thu 27 Jul 2017 13:48:05 BST

---> First iteration takes one second

Thu 27 Jul 2017 13:48:06 BST
docker: Error response from daemon: containerd: container did not start before the specified timeout.
Thu 27 Jul 2017 13:50:07 BST

---> Second iteration fails after 2 minutes with dockerd unable to start the container

Thu 27 Jul 2017 13:50:08 BST
+ date
Thu Jul 27 12:51:52 UTC 2017
+ mount.cifs //172.17.0.2/public /mnt/ -o vers=3.0,user=nobody,password=
+ date
Thu Jul 27 12:51:53 UTC 2017
+ ls -la /mnt
total 1028
drwxr-xr-x    2 root     root             0 Jul 27 10:11 .
drwxr-xr-x    1 root     root          4096 Jul 27 12:50 ..
-rwxr-xr-x    1 root     root             3 Jul 27 10:11 bla
+ umount /mnt
+ echo umount ok
umount ok
Thu 27 Jul 2017 13:51:53 BST

---> Third iterations succeeds, BUT it takes almost 2 minutes between docker run and the container running

Thu 27 Jul 2017 13:51:54 BST
docker: Error response from daemon: containerd: container did not start before the specified timeout.
Thu 27 Jul 2017 13:53:55 BST

---> Fourth iteration fails after two minutes

Thu 27 Jul 2017 13:53:56 BST
+ date
Thu Jul 27 12:55:37 UTC 2017
+ mount.cifs //172.17.0.2/public /mnt/ -o vers=3.0,user=nobody,password=
+ date
Thu Jul 27 12:55:37 UTC 2017
+ ls -la /mnt
total 1028
drwxr-xr-x    2 root     root             0 Jul 27 10:11 .
drwxr-xr-x    1 root     root          4096 Jul 27 12:53 ..
-rwxr-xr-x    1 root     root             3 Jul 27 10:11 bla
+ umount /mnt
+ echo umount ok
umount ok
Thu 27 Jul 2017 13:55:38 BST

---> Fifth iteration succeeds, but almost 2 minutes between docker run and the container executing

Tuve esto funcionando durante una hora más o menos con el mismo patrón repitiéndose, pero sin falla del kernel.

Veo los registros del kernel, muchos:

[   84.940380] unregister_netdevice: waiting for lo to become free. Usage count = 1
[   95.082151] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  105.253289] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  115.477095] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  125.627059] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  135.789298] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  145.969455] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  156.101126] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  166.303333] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  176.445791] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  186.675958] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  196.870265] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  206.998238] unregister_netdevice: waiting for lo to become free. Usage count = 1
[...]

Ese es un mensaje cada diez segundos.

Dado que esto no hace que la detección de tareas colgadas se active incluso después de una hora, sospecho que con 4.11.12 el recuento de referencias finalmente se reduce y el dispositivo se libera, pero, a juzgar por los intervalos en los que puedo ejecutar contenedores, podría tomar hasta 4 minutos!

Experimento 3 (kernel 4.11.12)

El bloqueo del kernel en el OP indicó que el kernel se bloqueó porque se detectó una tarea bloqueada. No he visto este bloqueo en mis pruebas, así que cambié la configuración sysctl relacionada con la detección de tareas colgadas:

# sysctl -a | grep kernel.hung_task
kernel.hung_task_check_count = 4194304
kernel.hung_task_panic = 0
kernel.hung_task_timeout_secs = 120
kernel.hung_task_warnings = 10
# sysctl -w kernel.hung_task_timeout_secs = 60
# sysctl -w kernel.hung_task_panic=1

Esto reduce el tiempo de espera a 60 segundos y genera un pánico en el kernel si se detecta una tarea colgada. Dado que se demoran alrededor de 2 minutos antes de que dockerd queje de que containerd no se inició, reducir la detección de tareas colgadas a 60 segundos debería provocar un pánico en el kernel si se colgaba una sola tarea. Por desgracia, no hubo choque en los troncos

Experimento 4 (kernel 4.11.12)

A continuación, aumento sleep después de cada docker run a 5 minutos para ver si los mensajes son continuos. En este caso, todos los docker run s parecen funcionar, lo cual es algo esperado ya que de los experimentos anteriores un docker run funcionaría cada 4 minutos aproximadamente.

---> This is after the first run
[  281.406660] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  291.455945] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  301.721340] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  311.988572] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  322.258805] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  332.527383] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  342.796511] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  353.059499] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  363.327472] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  373.365562] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  383.635923] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  393.684949] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  403.950186] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  414.221779] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  424.490110] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  434.754925] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  445.022243] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  455.292106] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  465.557462] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  475.826946] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  486.097833] unregister_netdevice: waiting for lo to become free. Usage count = 1

---> 200+ seconds of messages and then nothing for almost 400 seconds

[  883.924399] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  893.975810] unregister_netdevice: waiting for lo to become free. Usage count = 1
...
[ 1088.624065] unregister_netdevice: waiting for lo to become free. Usage count = 1
[ 1098.891297] unregister_netdevice: waiting for lo to become free. Usage count = 1

---> 200+ seconds of messages and then a gap of 90 seconds

[ 1185.119327] unregister_netdevice: waiting for lo to become free. Usage count = 1
[ 1195.387962] unregister_netdevice: waiting for lo to become free. Usage count = 1
...
[ 1390.040035] unregister_netdevice: waiting for lo to become free. Usage count = 1
[ 1400.307359] unregister_netdevice: waiting for lo to become free. Usage count = 1

---> 200+ seconds of messages and then a gap of 80+ seconds

[ 1486.325724] unregister_netdevice: waiting for lo to become free. Usage count = 1
[ 1496.591715] unregister_netdevice: waiting for lo to become free. Usage count = 1
...
[ 1680.987216] unregister_netdevice: waiting for lo to become free. Usage count = 1
[ 1691.255068] unregister_netdevice: waiting for lo to become free. Usage count = 1

---> 200+ seconds of messages and then a gap of 90+ seconds

[ 1787.547334] unregister_netdevice: waiting for lo to become free. Usage count = 1
[ 1797.819703] unregister_netdevice: waiting for lo to become free. Usage count = 1

Parece que estamos obteniendo alrededor de 200 segundos de unregister_netdevice en casi cada docker run (excepto en el segundo). Sospecho que durante ese tiempo no podemos iniciar nuevos contenedores (como lo indica el Experimento 2. Es curioso que la detección de tareas colgadas no se esté activando, presumiblemente porque no hay ninguna tarea colgada.

Experimento 5 (4.11.12 / 4.9.39 con una habilitación de depuración adicional en el kernel)

Esto está volviendo a 1 s de sueño entre docker run

Tenemos otro kernel que habilitó un montón de depuración adicional
opciones, como LOCKDEP , RCU_TRACE , LOCKUP_DETECTOR y algunas
más.

La ejecución de los núcleos repro 4.11.12 con estas opciones de depuración habilitadas no desencadenó nada.

Lo mismo ocurre con el kernel 4.9.39, donde el kernel normal falla. Las opciones de depuración cambian ligeramente el tiempo, por lo que esta puede ser una pista adicional de que la falla en el código del socket del dominio Unix muestra que se debe a una carrera.

Cavando un poco más profundo

strace en los diversos procesos containerd no es útil (
generalmente no lo es porque está escrito en Go). Muchos puestos largos en
futex(...FUTEX_WAIT...) con cualquier información sobre dónde / por qué.

Algunos hurgando con sysrq :

Aumentar la verbosidad:

echo 9 > /proc/sysrq-trigger

Seguimiento de pila de todas las CPU:

echo l > /proc/sysrq-trigger
[ 1034.298202] sysrq: SysRq : Show backtrace of all active CPUs
[ 1034.298738] NMI backtrace for cpu 1
[ 1034.299073] CPU: 1 PID: 2235 Comm: sh Tainted: G    B           4.11.12-linuxkit #1
[ 1034.299818] Hardware name:   BHYVE, BIOS 1.00 03/14/2014
[ 1034.300286] Call Trace:
[ 1034.300517]  dump_stack+0x82/0xb8
[ 1034.300827]  nmi_cpu_backtrace+0x75/0x87
[ 1034.301200]  ? irq_force_complete_move+0xf1/0xf1
[ 1034.301633]  nmi_trigger_cpumask_backtrace+0x6e/0xfd
[ 1034.302097]  arch_trigger_cpumask_backtrace+0x19/0x1b
[ 1034.302560]  ? arch_trigger_cpumask_backtrace+0x19/0x1b
[ 1034.302989]  sysrq_handle_showallcpus+0x17/0x19
[ 1034.303438]  __handle_sysrq+0xe4/0x172
[ 1034.303826]  write_sysrq_trigger+0x47/0x4f
[ 1034.304210]  proc_reg_write+0x5d/0x76
[ 1034.304507]  __vfs_write+0x35/0xc8
[ 1034.304773]  ? rcu_sync_lockdep_assert+0x12/0x52
[ 1034.305132]  ? __sb_start_write+0x152/0x189
[ 1034.305458]  ? file_start_write+0x27/0x29
[ 1034.305770]  vfs_write+0xda/0x100
[ 1034.306029]  SyS_write+0x5f/0xa3
[ 1034.306283]  entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 1034.306638] RIP: 0033:0x7fa4810488a9
[ 1034.306976] RSP: 002b:00007fffd3a29828 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 1034.307567] RAX: ffffffffffffffda RBX: 000000c6b523a020 RCX: 00007fa4810488a9
[ 1034.308101] RDX: 0000000000000002 RSI: 000000c6b5239d00 RDI: 0000000000000001
[ 1034.308635] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 1034.309169] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[ 1034.309700] R13: 0000000000000000 R14: 00007fffd3a29988 R15: 00007fa481280ee0
[ 1034.310334] Sending NMI from CPU 1 to CPUs 0:
[ 1034.310710] NMI backtrace for cpu 0 skipped: idling at pc 0xffffffffa0922756

Nada aquí, CPU1 está inactivo, CPU0 está manejando el sysrq.

Mostrar tareas bloqueadas (dos veces)

echo w > /proc/sysrq-trigger
[  467.167062] sysrq: SysRq : Show Blocked State
[  467.167731]   task                        PC stack   pid father
[  467.168580] kworker/u4:6    D    0   293      2 0x00000000
[  467.169096] Workqueue: netns cleanup_net
[  467.169487] Call Trace:
[  467.169732]  __schedule+0x582/0x701
[  467.170073]  schedule+0x89/0x9a
[  467.170338]  schedule_timeout+0xbf/0xff
[  467.170666]  ? del_timer_sync+0xc1/0xc1
[  467.171011]  schedule_timeout_uninterruptible+0x2a/0x2c
[  467.171422]  ? schedule_timeout_uninterruptible+0x2a/0x2c
[  467.171866]  msleep+0x1e/0x22
[  467.172155]  netdev_run_todo+0x173/0x2c4
[  467.172499]  rtnl_unlock+0xe/0x10
[  467.172770]  default_device_exit_batch+0x13c/0x15f
[  467.173226]  ? __wake_up_sync+0x12/0x12
[  467.173550]  ops_exit_list+0x29/0x53
[  467.173850]  cleanup_net+0x1a8/0x261
[  467.174153]  process_one_work+0x276/0x4fb
[  467.174487]  worker_thread+0x1eb/0x2ca
[  467.174800]  ? rescuer_thread+0x2d9/0x2d9
[  467.175136]  kthread+0x106/0x10e
[  467.175406]  ? __list_del_entry+0x22/0x22
[  467.175737]  ret_from_fork+0x2a/0x40
[  467.176167] runc:[1:CHILD]  D    0  2609   2606 0x00000000
[  467.176636] Call Trace:
[  467.176849]  __schedule+0x582/0x701
[  467.177152]  schedule+0x89/0x9a
[  467.177451]  schedule_preempt_disabled+0x15/0x1e
[  467.177827]  __mutex_lock+0x2a0/0x3ef
[  467.178133]  ? copy_net_ns+0xbb/0x17c
[  467.178456]  mutex_lock_killable_nested+0x1b/0x1d
[  467.179068]  ? mutex_lock_killable_nested+0x1b/0x1d
[  467.179489]  copy_net_ns+0xbb/0x17c
[  467.179798]  create_new_namespaces+0x12b/0x19b
[  467.180151]  unshare_nsproxy_namespaces+0x8f/0xaf
[  467.180569]  SyS_unshare+0x17b/0x302
[  467.180925]  entry_SYSCALL_64_fastpath+0x1f/0xc2
[  467.181303] RIP: 0033:0x737b97
[  467.181559] RSP: 002b:00007fff1965ab18 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
[  467.182182] RAX: ffffffffffffffda RBX: 0000000002277bd8 RCX: 0000000000737b97
[  467.182805] RDX: 0000000000000000 RSI: 0000000000867a0f RDI: 000000006c020000
[  467.183368] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[  467.184014] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[  467.184639] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[  477.286653] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  487.457828] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  497.659654] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  507.831614] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  518.030241] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  528.232963] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  538.412263] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  548.583610] unregister_netdevice: waiting for lo to become free. Usage count = 1
echo w > /proc/sysrq-trigger
[  553.969592] sysrq: SysRq : Show Blocked State
[  553.970411]   task                        PC stack   pid father
[  553.971208] kworker/u4:6    D    0   293      2 0x00000000
[  553.971686] Workqueue: netns cleanup_net
[  553.972058] Call Trace:
[  553.972305]  __schedule+0x582/0x701
[  553.972690]  schedule+0x89/0x9a
[  553.973039]  schedule_timeout+0xbf/0xff
[  553.973462]  ? del_timer_sync+0xc1/0xc1
[  553.973890]  schedule_timeout_uninterruptible+0x2a/0x2c
[  553.974706]  ? schedule_timeout_uninterruptible+0x2a/0x2c
[  553.975244]  msleep+0x1e/0x22
[  553.975539]  netdev_run_todo+0x173/0x2c4
[  553.975950]  rtnl_unlock+0xe/0x10
[  553.976303]  default_device_exit_batch+0x13c/0x15f
[  553.976725]  ? __wake_up_sync+0x12/0x12
[  553.977121]  ops_exit_list+0x29/0x53
[  553.977501]  cleanup_net+0x1a8/0x261
[  553.977869]  process_one_work+0x276/0x4fb
[  553.978245]  worker_thread+0x1eb/0x2ca
[  553.978578]  ? rescuer_thread+0x2d9/0x2d9
[  553.978933]  kthread+0x106/0x10e
[  553.979283]  ? __list_del_entry+0x22/0x22
[  553.979774]  ret_from_fork+0x2a/0x40
[  553.980244] runc:[1:CHILD]  D    0  2609   2606 0x00000000
[  553.980728] Call Trace:
[  553.980949]  __schedule+0x582/0x701
[  553.981254]  schedule+0x89/0x9a
[  553.981533]  schedule_preempt_disabled+0x15/0x1e
[  553.981917]  __mutex_lock+0x2a0/0x3ef
[  553.982220]  ? copy_net_ns+0xbb/0x17c
[  553.982524]  mutex_lock_killable_nested+0x1b/0x1d
[  553.982909]  ? mutex_lock_killable_nested+0x1b/0x1d
[  553.983311]  copy_net_ns+0xbb/0x17c
[  553.983606]  create_new_namespaces+0x12b/0x19b
[  553.983977]  unshare_nsproxy_namespaces+0x8f/0xaf
[  553.984363]  SyS_unshare+0x17b/0x302
[  553.984663]  entry_SYSCALL_64_fastpath+0x1f/0xc2
[  553.985080] RIP: 0033:0x737b97
[  553.985306] RSP: 002b:00007fff1965ab18 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
[  553.985861] RAX: ffffffffffffffda RBX: 0000000002277bd8 RCX: 0000000000737b97
[  553.986383] RDX: 0000000000000000 RSI: 0000000000867a0f RDI: 000000006c020000
[  553.986811] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[  553.987182] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[  553.987551] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
/ # [  558.844761] unregister_netdevice: waiting for lo to become free. Usage count = 1

Esto muestra que las colas de trabajo netns y cleanup_net están ocupadas. Encontré un problema algo relacionado hace bastante tiempo aquí , pero esta vez la cola de trabajo cleanup_net está en un estado diferente.

Resumen

• Creo que el bloqueo en los núcleos 4.9.x no está relacionado, pero parece estar solucionado en 4.11.x. Esto necesita un poco más de clasificación.
• A diferencia de algunos informes anteriores, no se informa de tareas bloqueadas, pero es difícil saberlo porque hay muy pocos seguimientos de pila sobre este problema.
• Algo está bloqueado durante mucho tiempo (2-4 minutos). Es probable que esté relacionado con el estado de la cola de trabajo.
• El volcado de la cola de trabajo necesita más análisis, en particular, por qué la cola de trabajo permanece en ese estado tanto tiempo.
• Los mensajes unregister_netdev parecen no estar relacionados con la solución reciente (que se encuentra tanto en 4.9.39 como en 4.11.12). Esto puede deberse a que la cola de trabajo cleanup_net no avanza y, por lo tanto, se imprime el mensaje.
• No está del todo claro cómo / por qué SMB está provocando esto. Escribí unas 60 pruebas de estrés extrañas para espacios de nombres de red y diferentes cargas de trabajo y no pude desencadenar ningún problema. Las pruebas se basaron en runc , tal vez debería probar containerd .

Profundizaré un poco más y luego enviaré un resumen a netdev .

@piec , ¿tienes acceso a la consola y puedes ver si hay algo en términos de volcado por caída o también ves grandes retrasos como yo veo? Si tiene un volcado de emergencia, me interesaría mucho verlo. Además, ¿se está ejecutando en bare metal o en una máquina virtual? ¿Cuál es su configuración en términos de CPU y memoria?

@rn gracias por las investigaciones!

Estoy funcionando en una PC de escritorio baremetal, por lo que tengo acceso a todo. Es un i7-4790K + 32 GiB.
Actualmente estoy ejecutando un kernel de Arch Linux + actualizado desde el repositorio de prueba (4.12.3-1-ARCH)

En mi caso, todo se comporta como lo describe en su Experimento 2 (kernel 4.11.12):

• Una vez que existe el contenedor client-smb, es imposible ejecutar nuevos contenedores durante más de 4 minutos.
• Nunca tengo fallos del kernel
• El mensaje unregister_netdevice: waiting for lo to become free. Usage count = 1 aparece repetidamente si intento ejecutar cualquier contenedor nuevo en el retraso de más de 4 minutos después de que el cliente-smb haya salido. Y solo aparece si ejecuta un nuevo contenedor en ese lapso de tiempo de 4 minutos. Ejecutar un nuevo contenedor después de estos 4 minutos será "normal"

Así que supongo que hay un problema en algún lugar del proceso de limpieza del contenedor smb-client relacionado con las interfaces de red.

En realidad, hay una reproducción mucho más simple de este problema (que, por cierto, no es el problema original).

Este script simplemente inicia un servidor SMB en el host y luego crea un espacio de nombres de red con un par veth , ejecuta mount; ls; unmount en el espacio de nombres de red y luego elimina el espacio de nombres de red.

apk add --no-cache iproute2 samba samba-common-tools cifs-utils

# SMB server setup
cat <<EOF > /etc/samba/smb.conf
[global]
    workgroup = WORKGROUP
    netbios name = FOO
    passdb backend = tdbsam
    security = user
    guest account = nobody
    strict locking = no
    min protocol = SMB2
[public]
    path = /share
    browsable = yes
    read only = no
    guest ok = yes
    browseable = yes
    create mask = 777
EOF
adduser -D -G nobody nobody && smbpasswd -a -n nobody
mkdir /share && chmod ugo+rwx /share && touch /share/foo
chown -R nobody.nobody /share

# Bring up a veth pair
ip link add hdev type veth peer name nsdev
ip addr add 10.0.0.1/24 dev hdev
ip link set hdev up

# Start SMB server and sleep for it to serve
smbd -D; sleep 5

# Client setup
ip netns add client-ns
ip link set nsdev netns client-ns
ip netns exec client-ns ip addr add 10.0.0.2/24 dev nsdev
ip netns exec client-ns ip link set lo up
ip netns exec client-ns ip link set nsdev up
sleep 1 # wait for the devices to come up

# Execute (mount, ls, unmount) in the network namespace and a new mount namespace
ip netns exec client-ns unshare --mount \
    /bin/sh -c 'mount.cifs //10.0.0.1/public /mnt -o vers=3.0,guest; ls /mnt; umount /mnt'

# Delete the client network namespace.
ip netns del client-ns

# Create a new network namespace
# This will stall for up to 200s
ip netns add new-netns

Tenga en cuenta que agregar un sleep 1 simple después del desmontaje, ya sea al ejecutar en el espacio de nombres o antes de eliminar el espacio de nombres de red, funciona sin detenerse en absoluto al crear el nuevo espacio de nombres. Una suspensión después de eliminar el antiguo espacio de nombres no reduce el estancamiento.

@piec También probé esto con su repro y un sleep 1 en el Dockerfile después del desmontaje y todo funciona como se esperaba, sin paradas, sin mensajes unregister_netdev .

Escribiré esto ahora y lo enviaré a netdev@vger

Excelente
Confirmo que un sleep después de desmontar corrige el estancamiento y los mensajes unregister_netdev en mi configuración también

¿No crees que umount genera una acción asincrónica relativa a sus netns que bloqueará y, eventualmente, agotará el tiempo de espera si se eliminan los netns antes de que finalice esa acción? Un sueño después de la montura dejaría que esto terminara antes de que se quiten las redes.
Pero eso es solo una hipótesis

Lo intenté sin desmontar, la misma diferencia. Es la eliminación del espacio de nombres de la red. Ese 9 y la eliminación del espacio de nombres de montaje desencadenarán el desmontaje de todos modos.

Ah ok

Por cierto, reproduje el problema por error (durante el desarrollo) en otra máquina con smb nuevamente. Es una PC con Ubuntu 16.04, Linux 4.4.0-77 genérico. Y hay una tarea pendiente que podría ser interesante. Sin accidentes y con el mismo retraso de ~ 4 minutos.

[6409720.564230] device vethff6396b entered promiscuous mode
[6409720.564415] IPv6: ADDRCONF(NETDEV_UP): vethff6396b: link is not ready
[6409723.844595] unregister_netdevice: waiting for lo to become free. Usage count = 1
[6409726.812872] INFO: task exe:17732 blocked for more than 120 seconds.
[6409726.812918]       Tainted: P           O    4.4.0-77-generic #98-Ubuntu
[6409726.812959] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[6409726.813007] exe             D ffff8809952bbcb8     0 17732      1 0x00000000
[6409726.813013]  ffff8809952bbcb8 ffffffff821d9a20 ffff88103856c600 ffff880ffae2d400
[6409726.813018]  ffff8809952bc000 ffffffff81ef7724 ffff880ffae2d400 00000000ffffffff
[6409726.813021]  ffffffff81ef7728 ffff8809952bbcd0 ffffffff81837845 ffffffff81ef7720
[6409726.813025] Call Trace:
[6409726.813036]  [<ffffffff81837845>] schedule+0x35/0x80
[6409726.813040]  [<ffffffff81837aee>] schedule_preempt_disabled+0xe/0x10
[6409726.813044]  [<ffffffff81839729>] __mutex_lock_slowpath+0xb9/0x130
[6409726.813048]  [<ffffffff818397bf>] mutex_lock+0x1f/0x30
[6409726.813053]  [<ffffffff81726a2e>] copy_net_ns+0x6e/0x120
[6409726.813059]  [<ffffffff810a168b>] create_new_namespaces+0x11b/0x1d0
[6409726.813062]  [<ffffffff810a17ad>] copy_namespaces+0x6d/0xa0
[6409726.813068]  [<ffffffff8107f1d5>] copy_process+0x905/0x1b70
[6409726.813073]  [<ffffffff810805d0>] _do_fork+0x80/0x360
[6409726.813077]  [<ffffffff81080959>] SyS_clone+0x19/0x20
[6409726.813081]  [<ffffffff8183b972>] entry_SYSCALL_64_fastpath+0x16/0x71
[6409733.941041] unregister_netdevice: waiting for lo to become free. Usage count = 1
[6409744.021494] unregister_netdevice: waiting for lo to become free. Usage count = 1

El hilo netdev @ vger está aquí https://www.mail-archive.com/[email protected]/msg179703.html si alguien quiere seguir el progreso.

@piec sí, eso es lo esperado.

También me encontré con este error y pude reproducir Oopses con el método docker-samba-loop de @piec en las imágenes del kernel de Ubuntu:

• linux-image-4.4.0-93-genérico
• linux-image-4.10.0-1004-gcp
• linux-image-4.10.0-32-genérico
• linux-image-4.11.0-14-genérico
• linux-image-4.12.10-041210-generic = 4.12.10-041210.20170830

Agregué mis hallazgos al informe de errores de Ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407 y https://github.com/fho/docker-samba-loop

@fho gracias. En realidad, no necesita docker para reproducir, solo ejecutar el cliente samba en un espacio de nombres de red hará el truco según https://github.com/moby/moby/issues/5618#issuecomment -318681443

@rn gracias por la información. No lo he probado todavía.

Las publicaciones recientes aquí y en la lista de correo de netdev parecen ser solo sobre paradas del kernel.
También tengo bloqueos del kernel con el kernel 4.11 y 4.12.

Veo un problema muy similar a este (como se detalla en el n. ° 35068). Básicamente, ejecutamos un enjambre de dos nodos, que ejecuta un solo servicio con 4 réplicas utilizando una estrategia de ubicación extendida.

En cada uno de estos contenedores de servicios montamos el host docker.sock como un volumen, y desde dentro del contenedor ejecutamos los comandos docker run , con una concurrencia máxima de 4 por contenedor. Esto da como resultado que se creen hasta 4 contenedores al mismo tiempo, y que se eliminen inmediatamente después a través de -rm .

Registros de kernel adicionales y ejemplos en ARMv7 que se muestran en la referencia anterior.

ip6_route_dev_notify pánico es un problema grave para nosotros.

Creo que mirando esto un poco más, este definitivamente NO es el mismo error que:

• https://github.com/hardkernel/linux/issues/312
• https://ubuntuforums.org/showthread.php?t=2367854

Creo que este es un problema aguas arriba en el kernel con la capa ipv6.

Esta información puede ser relevante.

Podemos reproducir el problema con _unregister_netdevice: esperando que lo sea libre. Recuento de uso = 1_ con kernel 4.14.0-rc3 con _CONFIG_PREEMPT_NONE = y_ y ejecutándose solo en una CPU con las siguientes opciones de kernel de arranque:

BOOT_IMAGE = / boot / vmlinuz-4.14.0-rc3 root = / dev / mapper / vg0-root ro quiet vsyscall = emular nosmp

Una vez que llegamos a este estado, permanece en este estado y es necesario reiniciar. No se pueden generar más contenedores. Lo reproducimos ejecutando imágenes haciendo conexiones ipsec / openvpn + descargando un pequeño archivo dentro de los túneles. Entonces existen las instancias (normalmente se ejecutan <10 s). Ejecutamos 10 de estos contenedores por minuto en una máquina. Con la configuración mencionada anteriormente (solo 1cpu), la máquina funciona en ~ 2 horas.

Otro reproductor con el mismo kernel, pero sin limitar el número de CPU, es simplemente ejecutar iperf en modo UDP durante 3 segundos dentro del contenedor (por lo que no hay comunicación TCP en absoluto). Si ejecutamos 10 de estos contenedores en paralelo, esperamos a que todos terminen y lo volvemos a hacer, solucionamos el problema en menos de 10 minutos (en una máquina de 40 núcleos).

En nuestros dos reproductores, agregamos "ip route flush table all; ifconfigabajo; duerme 10 "antes de existir de los contenedores. No parece tener ningún efecto.

Hola,

Solo para agregar al fuego, también estamos viendo este problema, como se solicita aquí son los siguientes ...

Versión de kernel: Linux exe-v3-worker 4.9.0-3-amd64 # 1 SMP Debian 4.9.30-2 + ​​deb9u5 (2017-09-19) x86_64 GNU / Linux

Distribución / versión de Linux: Debian 9.1 (con todos los paquetes actualizados)

¿Tiene la última versión del kernel de su proveedor de Linux? sí

Configuración de red (puente, superposición, IPv4, IPv6, etc.): solo IPv4, NAT según la configuración predeterminada de Docker

Descripción de la carga de trabajo (qué tipo de contenedores, qué tipo de carga de red, etc.): Contenedores de muy corta duración (de unos segundos a unos minutos) que ejecutan scripts antes de salir.

E idealmente una reproducción simple:

** kernel: [617624.412100] unregister_netdevice: esperando que lo sea libre. Recuento de uso = 1

No se pudo eliminar el contenedor antiguo o iniciar uno nuevo en los nodos afectados, tuve que reiniciar para restaurar la funcionalidad. **

Con suerte, pronto encontraremos una causa raíz / parche.

Atentamente,

robputt796

@campbellr
Estuvo de acuerdo en que parece tener algo que ver con el almacenamiento en red. Estoy usando ceph krbd como volumen persistente en kubernetes.
Y puedo reproducir la situación después de un largo tiempo ejecutando el bloqueo del contenedor.

El problema se asignó hace 10 días y está en progreso, puede ver más información sobre lo que está sucediendo aquí https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407

Con suerte, Dan Streetman descubre cómo solucionarlo.

Resulta que el error es causado por un error del kernel que ha sido corregido por la confirmación 76da0704507bbc51875013f6557877ab308cfd0a:

ipv6: solo llame a ip6_route_dev_notify () una vez para NETDEV_UNREGISTER

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76da0704507bbc51875013f6557877ab308cfd0a
(Simplemente corrige el pánico del kernel, no el "kernel: unregister_netdevice: esperando que lo sea libre. Usage count = 2" problema).

(repitiendo esto aquí nuevamente, porque GitHub está ocultando comentarios antiguos)

Si vienes aquí

El problema que se discute aquí es un error del kernel y aún no se ha solucionado por completo. Se incluyeron algunos parches en el kernel que corrigen _algunas_ apariciones de este problema, pero otras aún no se han resuelto.

Hay una serie de opciones que pueden ayudar en _algunas_ situaciones, pero no en todas (de nuevo, lo más probable es que sea una combinación de problemas que desencadenan el mismo error).

No dejes comentarios de "Yo también tengo esto"

"Yo también tengo esto" no ayuda a resolver el error. solo deje un comentario si tiene información que pueda ayudar a resolver el problema (en cuyo caso, proporcionar un parche para el núcleo en sentido ascendente puede ser el mejor paso).

Si desea informarle que también tiene este problema, use el botón "Me gusta" en la descripción superior:

Si desea mantenerse informado sobre las actualizaciones, utilice el _botón de suscripción_.

Cada comentario aquí envía un correo electrónico / notificación a más de 3000 personas . No quiero bloquear la conversación sobre este tema, porque aún no se ha resuelto, pero podría verse obligado a hacerlo si lo ignora.

Eliminaré los comentarios que no agreguen información útil para acortar (ligeramente) el hilo

Si desea ayudar a resolver este problema

• Lea todo el hilo; es largo y github oculta los comentarios (por lo que tendrá que hacer clic para hacerlos visibles nuevamente). Hay mucha información presente en este hilo que posiblemente podría ayudarlo
• Lea este comentario https://github.com/moby/moby/issues/5618#issuecomment -316297818 (y comentarios en ese momento) para obtener información que puede ser útil.

¡Gracias!

Creo que solucioné este problema, al menos cuando fue causado por una conexión de socket TCP del kernel. Los núcleos de prueba para Ubuntu están disponibles y me encantaría recibir comentarios si ayudan / solucionan esto para cualquiera aquí. El parche se envía en sentido ascendente; más detalles están en LP bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/comments/46

Lamento estropear la celebración, pero pudimos reproducir el problema. Ahora estamos trabajando con @ddstreet en https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/ .

¿No existen soluciones alternativas?

Utilice redes de host (que destruyen gran parte del valor de los contenedores, pero ya está).

@ pumba-lt Tuvimos este problema hace aproximadamente 1,5 años, hace aproximadamente 1 año desactivé ipv6 en el nivel del kernel (no sysctl) y no he tenido el problema una vez. Ejecutando un grupo de 48 blades.

Normalmente en: /etc/default/grub
GRUB_CMDLINE_LINUX="xxxxx ipv6.disable=1"

Sin embargo, uso el arranque PXE, por lo que mi configuración PXE tiene:

      DEFAULT menu.c32
      prompt 0
      timeout 50
      MENU TITLE PXE Boot
      label coreos
              menu label CoreOS
              kernel mykernel
              append initrd=myimage ipv6.disable=1 elevator=deadline cloud-config-url=myurl

Te aseguro que no volverás a ver este problema.

Todos, por favor, comprendan que este es un SÍNTOMA común que tiene muchas causas. Lo que le ha funcionado a usted para evitarlo puede que no le funcione a otra persona.

Puedo confirmar que nuestros problemas se resolvieron después de deshabilitar IPv6 en el arranque (archivo de configuración de fron grub). Tuvo numerosos problemas en un clúster de 7 nodos, ahora funciona sin problemas.

No recuerdo dónde encontré la solución, o la encontré yo mismo, de todos modos, ¡¡gracias @qrpike por sugerir esto a otros :) !!

https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.114

cometer edaafa805e0f9d09560a4892790b8e19cab8bf09
Autor: Dan Streetman [email protected]
Fecha: Thu Jan 18 16:14:26 2018-0500

net: tcp: close sock if net namespace is exiting


[ Upstream commit 4ee806d51176ba7b8ff1efd81f271d7252e03a1d ]

When a tcp socket is closed, if it detects that its net namespace is
exiting, close immediately and do not wait for FIN sequence.

For normal sockets, a reference is taken to their net namespace, so it will
never exit while the socket is open.  However, kernel sockets do not take a
reference to their net namespace, so it may begin exiting while the kernel
socket is still open.  In this case if the kernel socket is a tcp socket,
it will stay open trying to complete its close sequence.  The sock's dst(s)
hold a reference to their interface, which are all transferred to the
namespace's loopback interface when the real interfaces are taken down.
When the namespace tries to take down its loopback interface, it hangs
waiting for all references to the loopback interface to release, which
results in messages like:

unregister_netdevice: waiting for lo to become free. Usage count = 1

These messages continue until the socket finally times out and closes.
Since the net namespace cleanup holds the net_mutex while calling its
registered pernet callbacks, any new net namespace initialization is
blocked until the current net namespace finishes exiting.

After this change, the tcp socket notices the exiting net namespace, and
closes immediately, releasing its dst(s) and their reference to the
loopback interface, which lets the net namespace continue exiting.

Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=97811
Signed-off-by: Dan Streetman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

El uso de SCTP en redes también podría desencadenar esto, correcciones en 4.16-rc1:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a31a6b19f9ddf498c81f5c9b089742b7472a6f8
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=957d761cf91cdbb175ad7d8f5472336a4d54dbf2

todavía sucedió "unregister_netdevice: esperando que eth0 se vuelva libre. Usage count = 1" aunque he actualizado la versión del kernel a 4.4.118 y la versión de la ventana acoplable 17.09.1-ce, tal vez debería intentar deshabilitar ipv6 a nivel del kernel. Espero que funcione en la nube.

@ wuming5569 por favor avíseme si funcionó para usted con esa versión de linux

@ wuming5569 tal vez, actualice el kernel 4.4.114 y corrija "unregister_netdevice: esperando que lo sea libre. Usage count = 1", no para "unregister_netdevice: esperando que eth0 se vuelva libre. Usage count = 1".
Probé en producción.
@ddstreet esto es un comentario, ¿alguna ayuda?

@ wuming5569 como se mencionó anteriormente, los mensajes en sí mismos son benignos pero eventualmente pueden hacer que el kernel se cuelgue. ¿Se bloquea su kernel y, de ser así, cuál es su patrón de red, es decir, qué tipo de red hacen sus contenedores?

Experimentó el mismo problema en CentOS. Mi kernel es 3.10.0-693.17.1.el7.x86_64. Pero no obtuve un seguimiento de pila similar en syslog.

Lo mismo en Centos7 kernel 3.10.0-514.21.1.el7.x86_64 y docker 18.03.0-ce

@danielefranceschi Te recomiendo que actualices al último kernel de CentOS (al menos 3.10.0-693). No resolverá el problema, pero parece ser mucho menos frecuente. En los núcleos 3.10.0-327 y 3.10.0-514, estábamos viendo el seguimiento de la pila, pero según mi memoria, no creo que hayamos visto ninguno de esos en 3.10.0-693.

@alexhexabeam 3.10.0-693 parece funcionar perfectamente, tnx :)

Lo mismo en CentOS7 kernel 4.16.0-1.el7.elrepo.x86_64 y docker 18.03.0-ce

Funcionó durante semanas antes del accidente y, cuando se intentó, se atascó por completo.

El problema también ocurrió con el kernel 3.10.0-693.21.1.el7

Puedo confirmar que también sucede en:

Linux 3.10.0-693.17.1.el7.x86_64
Red Hat Enterprise Linux Server versión 7.4 (Maipo)

Puedo reproducirlo haciendo "service docker restart" mientras tengo una cierta cantidad de carga.

@ wuming5569 ¿ ha solucionado este problema? ¿
¿Tienes una cuenta de wechat?

4admin2root, dada la solución que mencionaste, https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.114 ,

¿Es seguro deshabilitar el proxy de área de usuario para el demonio de la ventana acoplable, si está instalado el kernel reciente adecuado? No está muy claro si es de

https://github.com/moby/moby/issues/8356
https://github.com/moby/moby/issues/11185

Dado que ambos son más antiguos que la corrección del kernel

Gracias

este problema nos ha confundido durante semanas.
Linux 3.10.0-693.17.1.el7.x86_64
Versión de CentOS Linux 7.4.1708 (Core)

¿Alguien puede confirmar si el último kernel 4.14 tiene este problema? Parece que no es así. Nadie en Internet se enfrentó a este problema con el kernel 4.14.

Veo esto en el kernel 4.15.15-1, Centos7

En cuanto a los registros de cambios, https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.15.8 tiene una solución para SCTP, pero no para TCP. Por lo tanto, es posible que desee probar la última versión 4.14.

• incluso 4.15.18 no ayuda con este error
• deshabilitar ipv6 tampoco ayuda

ahora hemos actualizado a 4.16.13. Observando. Este error nos afectaba en un nodo solo aproximadamente una vez por semana.

¿Desactivó ipv6 en los parámetros de arranque de grub o sysctl? Solo funcionarán los parámetros de arranque. Sysctl no lo solucionará.

El 4 de junio de 2018 a las 12:09:53 p.m., Sergey Pronin ( [email protected] (mailto: [email protected])) escribió:

incluso 4.15.18 no ayuda con este error
deshabilitar ipv6 tampoco ayuda

ahora hemos actualizado a 4.16.13. Observando. Este error nos afectaba en un nodo solo aproximadamente una vez por semana.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub (https://github.com/moby/moby/issues/5618#issuecomment-394410321), o silencie el hilo (https://github.com/notifications/unsubscribe-auth / AAo3HLYI_jnwjgtQ0ce-E4mc6Em5yeISks5t5VvRgaJpZM4B4L4Z).

Para mí, la mayoría de las veces el error aparece después de volver a implementar el mismo proyecto / red.

@qrpike tienes razón, solo probamos sysctl. Déjame intentarlo con grub. ¡Gracias!

4.9.88 Kernel de Debian. Reproducible.

@qrpike tienes razón, solo probamos sysctl. Déjame intentarlo con grub. ¡Gracias!

En mi caso, la desactivación de ipv6 no supuso ninguna diferencia.

@ spronin-aurea ¿Le ayudó la desactivación de ipv6 en el cargador de arranque?

@qrpike, ¿ puede decirnos sobre los nodos que está utilizando si deshabilitar ipv6 ayudó en su caso? Versión de kernel, versión de k8s, CNI, versión de docker, etc.

@komljen He estado usando CoreOS durante los últimos 2 años sin un solo incidente. Desde ~ ver 1000. No lo he probado recientemente, pero si no desactivo ipv6, el error ocurre.

Por mi parte, también estoy usando CoreOS, ipv6 deshabilitado con grub y sigo teniendo el problema

@deimosfr Actualmente estoy usando el arranque PXE para todos mis nodos:

      DEFAULT menu.c32
      prompt 0
      timeout 50
      MENU TITLE PXE Boot Blade 1
      label coreos
              menu label CoreOS ( blade 1 )
              kernel coreos/coreos_production_pxe.vmlinuz
              append initrd=coreos/coreos_production_pxe_image.cpio.gz ipv6.disable=1 net.ifnames=1 biosdevname=0 elevator=deadline cloud-config-url=http://HOST_PRIV_IP:8888/coreos-cloud-config.yml?host=1 root=LABEL=ROOT rootflags=noatime,discard,rw,seclabel,nodiratime

Sin embargo, mi nodo principal que es el host PXE también es CoreOS y arranca desde el disco, y tampoco tiene el problema.

¿Qué versiones de kernel están ejecutando?

Los que obtuve el problema fueron en 4.14.32-coreos y antes. Todavía no encuentro este problema en 4.14.42-coreos

Centos 7.5 con el kernel 4.17.3-1, todavía tiene el problema.

Env:
kubernetes 1.10.4
Docker 13.1
con el complemento de red Flannel.

Tronco :
[89.790907] IPv6: ADDRCONF (NETDEV_UP): eth0: el enlace no está listo
[89.798523] IPv6: ADDRCONF (NETDEV_CHANGE): eth0: el enlace está listo
[89.799623] cni0: el puerto 8 (vethb8a93c6f) entró en estado de bloqueo
[89.800547] cni0: el puerto 8 (vethb8a93c6f) entró en estado deshabilitado
[89.801471] dispositivo vethb8a93c6f entró en modo promiscuo
[89.802323] cni0: el puerto 8 (vethb8a93c6f) entró en estado de bloqueo
[89.803200] cni0: el puerto 8 (vethb8a93c6f) entró en estado de reenvío

kernel: unregister_netdevice : esperando que lo sea libre. Recuento de uso = 1。

Ahora :
La IP del nodo puede alcanzar, pero no puede utilizar ningún servicio de red, como ssh ...

Los síntomas aquí son similares a muchos informes en varios otros lugares. Todo lo que tiene que ver con los espacios de nombres de la red. ¿Podrían las personas que se encuentren con esto, por favor, ver si unshare -n cuelga, y si es así, desde otra terminal, hacer cat /proc/$pid/stack del proceso de no compartir para ver si se cuelga en copy_net_ns() ? Este parece ser un denominador común para muchos de los problemas, incluidos algunos rastros que se encuentran aquí. Entre 4.16 y 4.18 ha habido una serie de parches de Kirill Tkhai que refactorizaron mucho el bloqueo involucrado. Los mantenedores de paquetes de distribución / kernel afectados probablemente deberían considerar aplicarlos / exportarlos a kernels estables y ver si eso ayuda.
Ver también: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779678

@Lloriquear

sudo cat /proc/122355/stack
[<ffffffff8157f6e2>] copy_net_ns+0xa2/0x180
[<ffffffff810b7519>] create_new_namespaces+0xf9/0x180
[<ffffffff810b775a>] unshare_nsproxy_namespaces+0x5a/0xc0
[<ffffffff81088983>] SyS_unshare+0x193/0x300
[<ffffffff816b8c6b>] tracesys+0x97/0xbd
[<ffffffffffffffff>] 0xffffffffffffffff

Dados los cambios de bloqueo en 4.18, sería bueno probar el 4.18rc actual, especialmente si puede activarlo de manera más o menos confiable, ya que por lo que he visto, hay muchas personas en las que cambiar las versiones del kernel también cambió la probabilidad de que esto suceda. mucho.

Tuve estos problemas con Kubernetes y, después de cambiar a la última versión estable de CoreOS, 1745.7.0, el problema desapareció:

• núcleo: 4.14.48
• estibador: 18.03.1

mismo problema en CentOS 7

• núcleo: 4.11.1-1.el7.elrepo.x86_64
• acoplador: 17.12.0-ce

@Blub Viendo lo mismo en CoreOS 1688.5.3, kernel 4.14.32

ip-10-72-101-86 core # cat /proc/59515/stack
[<ffffffff9a4df14e>] copy_net_ns+0xae/0x200
[<ffffffff9a09519c>] create_new_namespaces+0x11c/0x1b0
[<ffffffff9a0953a9>] unshare_nsproxy_namespaces+0x59/0xb0
[<ffffffff9a07418d>] SyS_unshare+0x1ed/0x3b0
[<ffffffff9a003977>] do_syscall_64+0x67/0x120
[<ffffffff9a800081>] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[<ffffffffffffffff>] 0xffffffffffffffff

En teoría, puede haber uno o más rastros en algún lugar que contengan una de las funciones de net_namespace.c bloqueando el net_mutex ( cleanup_net , net_ns_barrier , net_ns_init , {,un}register_pernet_{subsys,device} ). Para los kernels estables, por supuesto, sería mucho más fácil si hubiera una cosa en particular que se interbloqueara de una manera que pudiera arreglarse, que volver a exportar todos los cambios de bloqueo de 4.18. Pero hasta ahora no he visto ningún rastro que conduzca a la causa raíz. No sé si ayudará, pero tal vez otros /proc/*/stack s con las funciones anteriores sean visibles cuando aparezca el problema.

mismo problema! y mi env es debian 8

RHEL, SWARM, 18.03.0-ce

1. Conexión al nodo administrador a través de ssh

2. Iniciar manualmente un contenedor en un nodo administrador:

   sudo docker run -it -v / import: / temp / eximport -v / home / myUser: / temp / exhome docker.repo.myHost / fedora: 23 / bin / bash

3. Después de un tiempo sin hacer nada:

   [ root @ 8a9857c25919 myDir] #
   Mensaje de syslogd @ se1-shub-t002 el 19 de julio 11:56:03 ...
   kernel: unregister_netdevice : esperando que lo sea libre. Recuento de uso = 1

Después de unos minutos, estoy de vuelta en la consola del nodo administrador y el contenedor iniciado ya no se está ejecutando.

¿Describe esto el mismo problema o se trata de otro "conjunto de problemas"?

¡THX de antemano!

ACTUALIZAR
Esto también sucede directamente en la consola ssh (en el bash del administrador de enjambres).

ACTUALIZAR
Máquina host (un nodo administrador en el enjambre):
Linux [MACHINENNAME] 3.10.0-514.2.2.el7.x86_64 # 1 SMP Mié 16 de noviembre 13:15:13 EST 2016 x86_64 x86_64 x86_64 GNU / Linux

Si esto no se soluciona después de un tiempo, entonces este es un problema diferente.

Lo mismo en CentOS7.5 kernel 3.10.0-693.el7.x86_64 y docker 1.13.1

El mismo problema OEL 7.5
uname -a
4.1.12-124.16.1.el7uek.x86_64 # 2 SMP Lunes 11 de junio 20:09:51 PDT 2018 x86_64 x86_64 x86_64 GNU / Linux
información de la ventana acoplable
Contenedores: 9
Corriendo: 5
En pausa: 0
Detenido: 4
Imágenes: 6
Versión del servidor: 17.06.2-ol

dmesg
[2238374.718889] unregister_netdevice: esperando que lo se libere. Recuento de uso = 1
[2238384.762813] unregister_netdevice: esperando que lo se libere. Recuento de uso = 1
[2238392.792585] eth0: renombrado de vethbed6d59

(repitiendo esto https://github.com/moby/moby/issues/5618#issuecomment-351942943 aquí nuevamente, porque GitHub está ocultando comentarios antiguos)

Si vienes aquí

El problema que se discute aquí es un error del kernel y aún no se ha solucionado por completo. Se incluyeron algunos parches en el kernel que corrigen _algunas_ apariciones de este problema, pero otras aún no se han resuelto.

Hay una serie de opciones que pueden ayudar en _algunas_ situaciones, pero no en todas (de nuevo, lo más probable es que sea una combinación de problemas que desencadenan el mismo error).

El error "unregister_netdevice: esperando que lo se libere" en sí mismo no es el error

Si es el fallo del kernel _ después_ eso es un error (ver más abajo)

No dejes comentarios de "Yo también tengo esto"

"Yo también tengo esto" no ayuda a resolver el error. solo deje un comentario si tiene información que pueda ayudar a resolver el problema (en cuyo caso, proporcionar un parche para el núcleo en sentido ascendente puede ser el mejor paso).

Si desea informarle que también tiene este problema, use el botón "Me gusta" en la descripción superior:

Si desea mantenerse informado sobre las actualizaciones, utilice el _botón de suscripción_.

Cada comentario aquí envía un correo electrónico / notificación a más de 3000 personas . No quiero bloquear la conversación sobre este tema, porque aún no se ha resuelto, pero podría verse obligado a hacerlo si lo ignora.

Eliminaré los comentarios que no agreguen información útil para acortar (ligeramente) el hilo

Si desea ayudar a resolver este problema

• Leer todo el hilo, incluidos los comentarios que están ocultos ; es largo y github oculta los comentarios (por lo que tendrá que hacer clic para hacerlos visibles nuevamente). Hay mucha información presente en este hilo que posiblemente podría ayudarlo

• Lea este comentario https://github.com/moby/moby/issues/5618#issuecomment -316297818 (y comentarios en ese momento) para obtener información que puede ser útil:

Para ser claros, el mensaje en sí es benigno , es el bloqueo del kernel después de los mensajes informados por el OP que no lo es.

El comentario en el código, de donde proviene este mensaje, explica lo que está sucediendo. Básicamente, cada usuario, como la pila de IP) de un dispositivo de red (como el final de veth par dentro de un contenedor) incrementa un recuento de referencia en la estructura del dispositivo de red cuando está usando el dispositivo de red. Cuando se quita el dispositivo (p. Ej., Cuando se quita el contenedor), se notifica a cada usuario para que pueda realizar alguna limpieza (p. Ej., Cerrar tomas abiertas, etc.) antes de disminuir el recuento de referencias. Debido a que esta limpieza puede llevar algún tiempo, especialmente bajo una carga pesada (mucha interfaz, muchas conexiones, etc.), el kernel puede imprimir el mensaje aquí de vez en cuando .

Si un usuario de un dispositivo de red nunca reduce el recuento de referencias, alguna otra parte del kernel determinará que la tarea que espera la limpieza está bloqueada y se bloqueará. Es solo este bloqueo lo que indica un error del kernel (algún usuario, a través de alguna ruta de código, no disminuyó el recuento de referencias). Ha habido varios errores de este tipo y se han corregido en el kernel moderno (y posiblemente se han adaptado a los más antiguos). He escrito bastantes pruebas de estrés (y continúo escribiéndolas) para desencadenar tales bloqueos, pero no he podido reproducir en núcleos modernos (sin embargo, hago el mensaje anterior).

* Por favor, solo informe sobre este problema si su kernel realmente falla *, y entonces estaríamos muy interesados ​​en:

• versión del kernel (salida de uname -r )
• Distribución / versión de Linux
• ¿Tiene la última versión del kernel de su proveedor de Linux?
• Configuración de red (puente, superposición, IPv4, IPv6, etc.)
• Descripción de la carga de trabajo (qué tipo de contenedores, qué tipo de carga de red, etc.)
• E idealmente una reproducción simple

¡Gracias!

¿Están ejecutando Docker bajo algún límite? Como ulimits, cgroups, etc.

systemd más nuevo tiene un límite predeterminado incluso si no lo configuró. Configuré las cosas en ilimitado y el problema no ha ocurrido desde entonces (viendo desde hace 31 días).

Tuve el mismo problema en muchos entornos y mi solución fue detener el firewall. No ha vuelto a pasar, por ahora

Rhel 7.5 - 3.10.0-862.3.2.el7.x86_64
Docker 1.13

@dElogics ¿Qué versión de systemd se considera "más nueva"? ¿Este límite predeterminado está habilitado en CentOS 7.5 systemd?

Además, cuando pregunta si estamos ejecutando Docker bajo algún límite, ¿se refiere al demonio de Docker oa los contenedores individuales?

El demonio de Docker. El systemd como en Debian 9 (232-25).

No estoy seguro acerca de RHEL, pero personalmente también he visto este problema en RHEL. Establecería LimitNOFILE = 1048576, LimitNPROC = infinito, LimitCORE = infinito, TasksMax = infinito

kernel: unregister_netdevice: esperando que eth0 se vuelva libre. Recuento de uso = 3
kernel 4.4.146-1.el7.elrepo.x86_64
Linux versión CentOS Linux versión 7.4.1708 (Core)
Modo Puente

Tuve el mismo problema, ¿qué puedo hacer?

Mismo problema:

Versión de CentOS Linux 7.5.1804 (Core)
Docker versión 18.06.1-ce, compilación e68fc7a
Versión de Kernel: 3.10.0-693.el7.x86_64

El problema similar que he conocido aquí ...
¿Hay algún movimiento que pueda realizar ahora mismo? Por favor, ayúdame...

CentOS 7.0.1406
[ root @ zjsm-slavexx etc] # uname -a
Linux zjsm-slave08 3.10.0-123.el7.x86_64 # 1 SMP Lun 30 de junio 12:09:22 UTC 2014 x86_64 x86_64 x86_64 GNU / Linux
[ root @ zjsm-slavexx etc] # cat / etc / centos-release
Versión de CentOS Linux 7.0.1406 (Core)

Información de Docker:
[ root @ zjsm-slavexx ~] # versión de la
Cliente:
Versión: 17.04.0-ce
Versión de API: 1.28
Go versión: go1.7.5
Confirmación de Git: 4845c56
Construido: lun 3 de abril 18:01:50 2017
SO / Arch: linux / amd64

Servidor:
Versión: 17.04.0-ce
Versión de API: 1.28 (versión mínima 1.12)
Go versión: go1.7.5
Confirmación de Git: 4845c56
Construido: lun 3 de abril 18:01:50 2017
SO / Arch: linux / amd64
Experimental: falso

Kernel de CentOS Linux versión 7.2.1511: 3.10.0-327.el7.x86_64
el mismo problema

He experimentado este problema.

Ubuntu 16.04.3 LTS
Kernel 4.4.0-87-generic #110-Ubuntu SMP Tue Jul 18 12:55:35 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Docker version:
Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:42:18 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:56 2017
 OS/Arch:      linux/amd64
 Experimental: false

@thaJeztah , tal vez debería agregar su comentario en la parte superior de la publicación original, ya que la gente aún lo ignora.

$ docker network ls
NETWORK ID          NAME                     DRIVER              SCOPE
b3fc47abfff2        bridge                   bridge              local
f9474559ede8        dockerfile_cluster_net   bridge              local
ef999de68a96        host                     host                local
e7b41d23674c        none                     null                local
$ docker network rm f9474559ede8 

arreglado.

@hzbd ¿ Te refieres a eliminar la red puente definida por el usuario? ¿Ha intentado investigar más para averiguar por qué? Por favor, avíseme si hizo eso. Realmente aprecio eso.

Esperando ser arreglado

¿Están ejecutando Docker bajo algún límite? Como ulimits, cgroups, etc.

systemd más nuevo tiene un límite predeterminado incluso si no lo configuró. Configuré las cosas en ilimitado y el problema no ha ocurrido desde entonces (viendo desde hace 31 días).

Ok, este error todavía ocurre, pero la probabilidad se ha reducido.

Creo que si los contenedores se detienen con gracia (PID 1 existe () s), entonces este error no nos molestará.

@dElogics gracias por

@dElogics gracias por

Tienes que modificar la unidad systemd de docker. La unidad systemd que uso (solo partes relevantes) -

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target docker.socket firewalld.service flannel.service
Wants=network-online.target
Requires=docker.socket

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker

ExecReload=/bin/kill -s HUP $MAINPID
LimitNOFILE=1048576
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNPROC=infinity
LimitCORE=infinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this version.
TasksMax=infinity
TimeoutStartSec=0
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
# kill only the docker process, not all processes in the cgroup
KillMode=process
# restart the docker process if it exits prematurely
Restart=on-failure
StartLimitBurst=3
StartLimitInterval=60s

[Install]
WantedBy=multi-user.target

¿Alguien tuvo este problema en un kernel 4.15 o más reciente?

Esta corrección de Dan Streetman (https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d) se incluye por primera vez en la versión del kernel 4.15 y parece que al menos para alguien ya no está sucediendo desde que actualizaron a 4.16 (https: / /github.com/kubernetes/kubernetes/issues/64743#issuecomment-436839647)

¿Alguien lo probó?

@victorgp Seguimos experimentando el problema con el kernel 4.15. Informaremos aquí cuando hayamos probado con el kernel 4.16 (con suerte en unas pocas semanas).

Usamos la versión del kernel

Para agregar a mis resoluciones anteriores, una detención elegante de los contenedores (que responden a SIGTERM) nunca desencadena esto.

También intente ejecutar los contenedores en el espacio de nombres de host (si es aceptable para usted) que resuelve completamente el problema.

@dElogics ¿Qué quiere decir con "espacio de nombres de host"? ¿Es simplemente --privileged ?

@dElogics ¿Qué quiere decir con "espacio de nombres de host"? ¿Es simplemente --privileged ?

No, significa --network = host

Desde la actualización del kernel 4.4.0 a 4.15.0 y la ventana acoplable 1.11.2 a 18.09, el problema desapareció.

En una flota considerable de máquinas virtuales que actúan como hosts de Docker, este problema aparecía varias veces al día (con nuestro caso de uso de Docker).
45 días y ya no vemos esto.

Para la posteridad, un seguimiento de pila de un Docker 1.11.2 colgado con printk que muestra unregister_netdevice: waiting for vethXXXXX (similar a lo que siempre veíamos en nuestra flota, en cientos de VM) se puede encontrar en http: // paste .ubuntu.com / p / 6RgkpX352J / (la referencia de contenedor interesante es 0xc820001980 )

goroutine 8809 [syscall, 542 minutes, locked to thread]:
syscall.Syscall6(0x2c, 0xd, 0xc822f3d200, 0x20, 0x0, 0xc822f3d1d4, 0xc, 0x20, 0xc82435fda0, 0x10)
    /usr/local/go/src/syscall/asm_linux_amd64.s:44 +0x5
syscall.sendto(0xd, 0xc822f3d200, 0x20, 0x20, 0x0, 0xc822f3d1d4, 0xc80000000c, 0x0, 0x0)
    /usr/local/go/src/syscall/zsyscall_linux_amd64.go:1729 +0x8c
syscall.Sendto(0xd, 0xc822f3d200, 0x20, 0x20, 0x0, 0x7faba31bded8, 0xc822f3d1c8, 0x0, 0x0)
    /usr/local/go/src/syscall/syscall_unix.go:258 +0xaf
github.com/vishvananda/netlink/nl.(*NetlinkSocket).Send(0xc822f3d1c0, 0xc82435fda0, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go:333 +0xd4
github.com/vishvananda/netlink/nl.(*NetlinkRequest).Execute(0xc82435fda0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go:215 +0x111
github.com/vishvananda/netlink.LinkDel(0x7fab9c2b15d8, 0xc825ef2240, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/vishvananda/netlink/link_linux.go:615 +0x16b
github.com/docker/libnetwork/drivers/bridge.(*driver).DeleteEndpoint(0xc8204aac30, 0xc8203ae780, 0x40, 0xc826e7b800, 0x40, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go:1060 +0x5cf
github.com/docker/libnetwork.(*endpoint).deleteEndpoint(0xc822945b00, 0xc82001ac00, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/endpoint.go:760 +0x261
github.com/docker/libnetwork.(*endpoint).Delete(0xc822945b00, 0x7fab9c2b0a00, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/endpoint.go:735 +0xbcb
github.com/docker/libnetwork.(*sandbox).delete(0xc8226bc780, 0xc8229f0600, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/sandbox.go:217 +0xd3f
github.com/docker/libnetwork.(*sandbox).Delete(0xc8226bc780, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/sandbox.go:175 +0x32
github.com/docker/docker/daemon.(*Daemon).releaseNetwork(0xc820001980, 0xc820e23a40)
    /usr/src/docker/.gopath/src/github.com/docker/docker/daemon/container_operations.go:732 +0x4f1
github.com/docker/docker/daemon.(*Daemon).Cleanup(0xc820001980, 0xc820e23a40)
    /usr/src/docker/.gopath/src/github.com/docker/docker/daemon/start.go:163 +0x62
github.com/docker/docker/daemon.(*Daemon).StateChanged(0xc820001980, 0xc825f9fac0, 0x40, 0xc824155b50, 0x4, 0x8900000000, 0x0, 0x0, 0x0, 0x0, ...)
    /usr/src/docker/.gopath/src/github.com/docker/docker/daemon/monitor.go:39 +0x60a
github.com/docker/docker/libcontainerd.(*container).handleEvent.func2()
    /usr/src/docker/.gopath/src/github.com/docker/docker/libcontainerd/container_linux.go:177 +0xa5
github.com/docker/docker/libcontainerd.(*queue).append.func1(0xc820073c01, 0xc820f9a2a0, 0xc821f3de20, 0xc822ddf9e0)
    /usr/src/docker/.gopath/src/github.com/docker/docker/libcontainerd/queue_linux.go:26 +0x47
created by github.com/docker/docker/libcontainerd.(*queue).append
    /usr/src/docker/.gopath/src/github.com/docker/docker/libcontainerd/queue_linux.go:28 +0x1da

De eso podemos observar que colgó en https://github.com/moby/moby/blob/v1.11.2/daemon/container_operations.go#L732

que nos lleva a

Y
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/endpoint.go#L760

Que entra en el controlador de puente libnetwork (verifique la descripción impresionante)
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go#L1057 -L1061

Pasando a netlink
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go#L601 -L617
https://github.com/moby/moby/blob/v1.11.2//vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go#L215

Y, en última instancia, en ese conector netlink, llamadas https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go#L333

Creemos que el error en general ocurre cuando se detiene un contenedor y debido a que los SKB todavía están referenciados en las redes, el veth no se libera, entonces Docker emite un Kill a ese contenedor después de 15 segundos. El demonio de Docker no maneja esta situación con elegancia, pero en última instancia, el error está en el kernel. Creemos que https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d (aceptado en 4.15 en sentido ascendente) y los compromisos vinculados a él (hay varios) actúan como una mitigación.

En general, esa parte del kernel no es un lugar bonito.

Por lo que vale ... actualizamos el kernel de RHEL Linux de 3.10.0 a 4.17.11. (Ejecutando el clúster de Kubernetes en). Antes de actualizar, este error se producía a diario varias veces en diferentes servidores. Ejecutando con la actualización desde hace tres semanas. El error ocurrió solo una vez. Así, aproximadamente, se reduce en un 99%.

@marckamerbeek ¿Actualizó RHEL Kernel a un Kernel comunitario? Entonces ya no es compatible.

El usuario de

centos 7.2 todavía tiene este problema: kernel: unregister_netdevice : esperando que lo sea libre. Recuento de uso = 1

@Beatlor RHEL no nos ayudó en absoluto. Un entorno de producción estable es más importante que un contrato de soporte sin valor. Seguimos funcionando muy estable ahora en 4.17.11. Ya no hay grandes problemas.

@Beatlor RHEL no nos ayudó en absoluto. Un entorno de producción estable es más importante que un contrato de soporte sin valor. Seguimos funcionando muy estable ahora en 4.17.11. Ya no hay grandes problemas.

Sí, tampoco tuve este problema después de actualizar el kernel a 4.17.0-1.el7.elrepo.x86_64. Intenté esto antes (4.4.x, 4.8, 4.14 ..) y ha fallado. Parece que el problema no volverá a ocurrir en el kernel 4.17+.

centos 7.2 todavía tiene este problema: kernel: unregister_netdevice : esperando que lo sea libre. Recuento de uso = 1

Puede intentar actualizar al último kernel 4.19+.

Espere unos meses y aparecerá alguien quejándose también del kernel 4.19. Solo la historia se repite.

Hola a todos, ¡buenas noticias!

Desde mi último comentario aquí (en el momento de escribir este artículo, hace 17 días) no he vuelto a tener estos errores. Mis servidores (unos 30 de ellos) ejecutaban ubuntu 14.04 con algunos paquetes desactualizados.

Después de una actualización completa del sistema que incluye docker-engine (de 1.7.1 a 1.8.3) + actualización del kernel a la última versión posible en el repositorio de ubuntu, mis servidores se están ejecutando sin incidencias.

🎱

¿Qué versión del kernel está actualizando?

tal vez relacionado con esto https://github.com/torvalds/linux/commit/f186ce61bb8235d80068c390dc2aad7ca427a4c2

Aquí hay un intento de resumir este problema, a partir de los comentarios de este problema, https://github.com/kubernetes/kubernetes/issues/70427 , https://github.com/kubernetes/kubernetes/issues/64743 y https: //access.redhat.com/solutions/3659011

Versiones de kernel observadas con este problema

• RHEL7 3.10.0-862
• 4.15.0
• 4.20.0

Las versiones del kernel afirman que no desencadenan este problema

• RHEL7 3.10.0-957.10.1
• 4.19.12
• 4.17.0
• 4.17.11

Confirmaciones de kernel relacionadas

• https://github.com/torvalds/linux/commit/f186ce61bb8235d80068c390dc2aad7ca427a4c2 - desde 4.12
• https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d - desde 4.15
• https://github.com/torvalds/linux/commit/ee60ad219f5c7c4fb2f047f88037770063ef785f - desde 5.1

Desafío https://github.com/kubernetes/kubernetes/issues/70427#issuecomment -470681000 ya que no hemos visto esto con miles de VM en 4.15.0 mientras lo veíamos docenas de veces al día en 4.4. 0, ¿hay más informes al respecto en 4.15.0?

Veo este problema con una de mis máquinas que ejecuta Docker en Debian 9 Stretch ( 4.9.0-8-amd64 ). Experimento este problema con un túnel creado dentro del contenedor de Docker a través de Docker Gen y genera un pánico en el kernel:

Message from syslogd<strong i="7">@xxxx</strong> at Apr 29 15:55:41 ...
 kernel:[719739.507961] unregister_netdevice: waiting for tf-xxxxxxxx to become free. Usage count = 1

Aquí está nuestra información de Docker:

Client:
 Version:           18.09.3
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        774a1f4
 Built:             Thu Feb 28 06:34:04 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.3
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.8
  Git commit:       774a1f4
  Built:            Thu Feb 28 05:59:55 2019
  OS/Arch:          linux/amd64
  Experimental:     false

¿Alguien sabe si hay una solución temporal para esto sin reiniciar toda la máquina? Realmente preferiríamos no tener que reiniciar toda la máquina cuando experimentamos este problema.

Algo fuera de tema, no podemos suprimir los mensajes de pánico del kernel dentro de la terminal también. He probado dmesg -D y dmesg -n 1 . Sin embargo, no hubo suerte. ¿Hay alguna forma de suprimir este tipo de mensajes de pánico del kernel desde la terminal? Es molesto intentar escribir comandos y que aparezca ese mensaje cada 10 segundos aproximadamente.

Gracias.

¿Son estos núcleos de vainilla o están muy parcheados por distribuciones con correcciones retroportadas?

@pmoust Veo esto en ubuntu 4.15.0-32 una vez a la semana más o menos. definitivamente mucho mejor desde 4.4.0

@iavael intentaré enumerar la información de distribución en el resumen si la referencia lo proporciona.

¿Alguien vio este error con 4.19?

¿Alguien vio este error con 4.19?

https://github.com/kubernetes/kubernetes/issues/64743#issuecomment -451351435
https://github.com/kubernetes/kubernetes/issues/64743#issuecomment -461772385

Esta información puede resultarle útil.

@tankywoo @drpancake @egasimus @csabahenk @spiffytech @ibuildthecloud @sbward @jbalonso @rsampaio @MrMMorris @rsampaio @unclejack @chrisjstevenson @popsikle @fxposter @ scher200 @victorgp @jstangroome @ Xuexiang825 @dElogics @Nowaker @pmoust @marckamerbeek @Beatlor @warmchang @Jovons @ 247687009 @jwongz @ tao12345666333 @clkao Por favor, mire esto https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs- while- testing- tidb- operator- in- k8s/

@tankywoo @drpancake @egasimus @csabahenk @spiffytech @ibuildthecloud @sbward @jbalonso @rsampaio @MrMMorris @rsampaio @unclejack @chrisjstevenson @popsikle @fxposter @ scher200 @victorgp @jstangroome @ Xuexiang825 @dElogics @Nowaker @pmoust @marckamerbeek @Beatlor @warmchang @Jovons @ 247687009 @jwongz @ tao12345666333 @clkao Por favor, mire esto https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs- while- testing- tidb- operator- in- k8s/

Seguí la documentación, pero sigo recibiendo un error.

[root<strong i="39">@node1</strong> ~]# kpatch list
Loaded patch modules:
livepatch_route [enabled]

Installed patch modules:
[root<strong i="40">@node1</strong> ~]#
Message from syslogd<strong i="41">@node1</strong> at May  7 15:59:11 ...
 kernel:unregister_netdevice: waiting for eth0 to become free. Usage count = 1

Ese mensaje en sí no es el error; es el kernel fallando después; https://github.com/moby/moby/issues/5618#issuecomment -407751991

@tankywoo @drpancake @egasimus @csabahenk @spiffytech @ibuildthecloud @sbward @jbalonso @rsampaio @MrMMorris @rsampaio @unclejack @chrisjstevenson @popsikle @fxposter @ scher200 @victorgp @jstangroome @ Xuexiang825 @dElogics @Nowaker @pmoust @marckamerbeek @Beatlor @warmchang @Jovons @ 247687009 @jwongz @ tao12345666333 @clkao Por favor, mire esto https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs- while- testing- tidb- operator- in- k8s/

Seguí la documentación, pero sigo recibiendo un error.

[root<strong i="40">@node1</strong> ~]# kpatch list
Loaded patch modules:
livepatch_route [enabled]

Installed patch modules:
[root<strong i="41">@node1</strong> ~]#
Message from syslogd<strong i="42">@node1</strong> at May  7 15:59:11 ...
 kernel:unregister_netdevice: waiting for eth0 to become free. Usage count = 1

Después de reiniciar, ok ···

@ vincent927 Por cierto, debe poner livepatch_route.ko en / var / lib / kpatch / $ (uname -r), cuando habilite kpatch.service, el ko se puede cargar automáticamente después del reinicio.

Obtuvimos esto en nuestra empresa de repente hoy en varios clústeres de kubernetes.

• uname -a :
  Linux ip-10-47-17-58 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux

• docker version :

  Client:
   Version:           18.09.5
   API version:       1.39
   Go version:        go1.10.8
   Git commit:        e8ff056dbc
   Built:             Thu Apr 11 04:44:28 2019
   OS/Arch:           linux/amd64
   Experimental:      false
  
  Server: Docker Engine - Community
   Engine:
    Version:          18.09.2
    API version:      1.39 (minimum version 1.12)
    Go version:       go1.10.6
    Git commit:       6247962
    Built:            Sun Feb 10 03:42:13 2019
    OS/Arch:          linux/amd64
    Experimental:     false
  

• kubectl version (servidor):
  Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.2", GitCommit:"cff46ab41ff0bb44d8584413b598ad8360ec1def", GitTreeState:"clean", BuildDate:"2019-01-10T23:28:14Z", GoVersion:"go1.11.4", Compiler:"gc", Platform:"linux/amd64"}

Aún no conocemos la causa; hemos estado ejecutando estas versiones del software anterior durante varios meses sin problemas. Solo estoy comentando para agregar a la lista de "versiones de software que experimentan este error" por ahora.

@ 2rs2ts ¿Ha https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs- while-testing-tidb-operator-in-k8s/ ?

@ethercflow He leído eso, pero desde que ejecutamos Debian en mi empresa, no es sencillo para nosotros implementar la solución en esa publicación.

@ethercflow @ 2rs2ts también estamos ejecutando debian. Me he encontrado con muchos problemas al intentar que kpatch-build funcione. Si logro encontrar una solución alternativa, los mantendré informados. En cualquier caso, ¿alguien tiene alguna otra solución? ¿Es la versión del kernel 4.15 o 4.19 la que mitiga el problema? He estado tratando de encontrar la respuesta durante la semana pasada y todavía no lo he logrado.

@commixon, nuestra experiencia sigue siendo la misma que se informó en https://github.com/moby/moby/issues/5618#issuecomment -455800975, en una flota de miles de máquinas virtuales sin que se repita el problema con 4.15.0 en Sabores de kernels genéricos, optimizados para AWS y GCP proporcionados por Canonical. La prueba limitada en vainilla 4.15.0 tampoco mostró ninguno de esos problemas, pero no se probó a escala.

Muchas gracias @pmoust . Los probaré. En cualquier caso, también intentaré parchear kpatch para que funcione con Debian (como un proyecto paralelo) y publicar actualizaciones aquí para cualquiera que esté interesado.

@ethercflow @ 2rs2ts también estamos ejecutando debian. Me he encontrado con muchos problemas al intentar que kpatch-build funcione. Si logro encontrar una solución alternativa, los mantendré informados. En cualquier caso, ¿alguien tiene alguna otra solución? ¿Es la versión del kernel 4.15 o 4.19 la que mitiga el problema? He estado tratando de encontrar la respuesta durante la semana pasada y todavía no lo he logrado.

Puede actualizar a 4.19. Está en los puertos traseros.

Por cierto, ha sido un año para nosotros aquí. ;)

De hecho, probamos el 4.19 en los backports, pero tuvo algunas regresiones importantes en otras áreas (las instancias EC2 se reiniciarían aleatoriamente y luego la red se interrumpiría al inicio). Supongo que tendremos que lidiar con esto hasta el próximo establo.

@ 2rs2ts Durante los últimos 4 días, usamos 4.19 de backports (en EC2) y no hemos visto ningún problema. El problema de la caída del kernel no ha aparecido en absoluto y todo lo demás parece estar bien también. No creo que haga ninguna diferencia, pero basamos nuestra imagen de Debian en la proporcionada por kops (https://github.com/kubernetes/kops/blob/master/docs/images.md#debian). Actualizamos el kernel en esta imagen y no el archivo debian.

Amigos, he estado usando el kernel 4.19 para un funcionamiento estable durante medio año. Espero que también puedas disfrutar de la estabilidad.

Tengo un contenedor abierto puerto 80 y 443, cada 2 semanas, desde otro contenedor de acceso a computadora 80 y
443 es negar

La versión del kernel centos7.3 es:
Navegador Linux1 3.10.0-514.el7.x86_64 # 1 SMP Mar 22 de noviembre 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux

root @ browser1 ~] # versión de la
Cliente:
Versión: 18.06.3-ce
Versión de API: 1.38
Go versión: go1.10.4
Confirmación de Git: d7080c1
Construido: mié 20 feb 02:24:22 2019
SO / Arch: linux / amd64
Experimental: falso

Servidor:
Motor:
Versión: 18.06.3-ce
Versión API: 1.38 (versión mínima 1.12)
Go versión: go1.10.3
Confirmación de Git: d7080c1
Construido: mié 20 feb 02:25:33 2019
SO / Arch: linux / amd64
Experimental: falso
[ root @ browser1 ~] #

dmesg:

[1063959.636785] unregister_netdevice: esperando que lo se libere. Recuento de uso = 1
[1071340.887512] br-af29e1edc1b8: el puerto 5 (vethc2ac4f8) entró en estado inhabilitado
[1071340.891753] br-af29e1edc1b8: el puerto 5 (vethc2ac4f8) entró en estado inhabilitado
[1071340.895118] dispositivo vethc2ac4f8 dejó el modo promiscuo
[1071340.895138] br-af29e1edc1b8: el puerto 5 (vethc2ac4f8) entró en estado inhabilitado
[1071340.990505] dispositivo veth5e4f161 entró en modo promiscuo
[1071340.990897] IPv6: ADDRCONF (NETDEV_UP): veth5e4f161: el enlace no está listo
[1071340.990904] br-af29e1edc1b8: el puerto 5 (veth5e4f161) entró en estado de reenvío
[1071340.990924] br-af29e1edc1b8: el puerto 5 (veth5e4f161) entró en estado de reenvío
[1071341.231405] IPv6: ADDRCONF (NETDEV_CHANGE): veth5e4f161: el enlace está listo
[1071355.991701] br-af29e1edc1b8: el puerto 5 (veth5e4f161) entró en estado de reenvío
[1071551.533907] br-af29e1edc1b8: el puerto 5 (veth5e4f161) entró en estado inhabilitado
[1071551.537564] br-af29e1edc1b8: el puerto 5 (veth5e4f161) entró en estado inhabilitado
[1071551.540295] dispositivo veth5e4f161 dejó el modo promiscuo
[1071551.540313] br-af29e1edc1b8: el puerto 5 (veth5e4f161) entró en estado inhabilitado
[1071551.570924] dispositivo veth8fd3a0a entró en modo promiscuo
[1071551.571550] IPv6: ADDRCONF (NETDEV_UP): veth8fd3a0a: el enlace no está listo
[1071551.571556] br-af29e1edc1b8: el puerto 5 (veth8fd3a0a) entró en estado de reenvío
[1071551.571582] br-af29e1edc1b8: el puerto 5 (veth8fd3a0a) entró en estado de reenvío
[1071551.841656] IPv6: ADDRCONF (NETDEV_CHANGE): veth8fd3a0a: el enlace está listo
[1071566.613998] br-af29e1edc1b8: el puerto 5 (veth8fd3a0a) entró en el estado de reenvío
[1071923.465082] br-af29e1edc1b8: el puerto 5 (veth8fd3a0a) entró en estado inhabilitado
[1071923.470215] br-af29e1edc1b8: el puerto 5 (veth8fd3a0a) entró en estado inhabilitado
[1071923.472888] dispositivo veth8fd3a0a dejó el modo promiscuo
[1071923.472904] br-af29e1edc1b8: el puerto 5 (veth8fd3a0a) entró en estado inhabilitado
[1071923.505580] dispositivo veth9e693ae entró en modo promiscuo
[1071923.505919] IPv6: ADDRCONF (NETDEV_UP): veth9e693ae: el enlace no está listo
[1071923.505925] br-af29e1edc1b8: el puerto 5 (veth9e693ae) entró en estado de reenvío
[1071923.505944] br-af29e1edc1b8: el puerto 5 (veth9e693ae) entró en el estado de reenvío
[1071923.781658] IPv6: ADDRCONF (NETDEV_CHANGE): veth9e693ae: el enlace está listo
[1071938.515044] br-af29e1edc1b8: el puerto 5 (veth9e693ae) entró en estado de reenvío

¿Alguien vio este error con 4.19?

Si. Tengo el problema en el kernel 4.19.4-1.e17.elrep.x86_64

Hola,

También veo este error. ¿Tenemos alguna solución para este problema? Núcleo 3.10.0-514.26.2.el7.x86_64

[username@ip-10-1-4-64 ~]$
Message from syslogd@ip-10-1-4-64 at Jul 19 10:50:01 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Message from syslogd@ip-10-1-4-64 at Jul 19 10:50:48 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Este problema sigue sucediendo :( no hay actualizaciones / ideas sobre cómo solucionarlo.

Sucediendo en Debian Stretch. Estaba intentando actualizar mi contenedor Jenkins a través de Ansible cuando esto sucedió.

Este problema ha sido resuelto por este compromiso:
https://github.com/torvalds/linux/commit/ee60ad219f5c7c4fb2f047f88037770063ef785f
Usando kpatch

curl -SOL https://raw.githubusercontent.com/Aleishus/kdt/master/kpatchs/route.patch
kpatch-build -t vmlinux route.patch 
mkdir -p /var/lib/kpatch/${UNAME} 
cp -a livepatch-route.ko /var/lib/kpatch/${UNAME}
systemctl restart kpatch
kpatch list

Este problema ha sido resuelto por este compromiso:
torvalds / linux @ ee60ad2
Usando kpatch

curl -SOL https://raw.githubusercontent.com/Aleishus/kdt/master/kpatchs/route.patch
kpatch-build -t vmlinux route.patch 
mkdir -p /var/lib/kpatch/${UNAME} 
cp -a livepatch-route.ko /var/lib/kpatch/${UNAME}
systemctl restart kpatch
kpatch list