Estou vendo um problema muito semelhante para a eth0. Ubuntu 12.04 também.

Tenho que desligar e ligar a máquina. De /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

Ei, isso começou a acontecer para mim também.

Versão do 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

Log do kernel : http://pastebin.com/TubCy1tG

Detalhes do sistema :
Executando Ubuntu 14.04 LTS com kernel corrigido (3.14.3-rt4). Ainda para ver isso acontecer com o kernel genérico linux-3.13.0-27 padrão. O que é engraçado, porém, é que, quando isso acontece, todas as janelas do meu terminal congelam, permitindo-me digitar alguns caracteres no máximo antes disso. O mesmo destino acontecerá com todos os novos que eu abrir - e acabo precisando desligar e religar meu pobre laptop, assim como o bom médico acima. Só para constar, estou executando fish shell no urxvt ou xterm no xmonad. Não verifiquei se isso afeta o bash normal.

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

Copiar uma quantidade bastante grande de dados pela rede dentro de um contêiner
e, em seguida, sair do contêiner pode desencadear um decréscimo ausente no por
contagem de referência de CPU em um dispositivo de rede.

Com certeza, uma das vezes que isso aconteceu para mim foi logo depois de apt-get ting um pacote com uma tonelada de dependências.

Atualizar do Ubuntu 12.04.3 para 14.04 corrigiu isso para mim, sem quaisquer outras alterações.

Eu experimento isso no RHEL7, 3.10.0-123.4.2.el7.x86_64

Notei a mesma coisa acontecendo com minhas interfaces de rede virtual VirtualBox quando estou executando o 3.14-rt4. É suposto ser corrigido no vanilla 3.13 ou algo assim.

@egasimus O mesmo aqui -

Eu atualizei para o kernel Debian 3.14 e o problema parece ter desaparecido. Parece que o problema existia em alguns kernels <3.5, foi corrigido em 3.5, regrediu em 3.6 e foi corrigido em algo 3.12-3.14. https://bugzilla.redhat.com/show_bug.cgi?id=880394

@spiffytech Você tem alguma idéia de onde posso relatar isso com relação ao sabor do kernel em tempo real? Eu acho que eles estão apenas lançando um patch RT para todas as outras versões, e eu realmente odiaria ver o 3.16-rt sair com isso ainda quebrado. : /

EDIT: Arquivado em kernel.org .

Estou recebendo isso no Ubuntu 14.10 executando um 3.18.1. Mostra o log do 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

Vou enviar docker version/info assim que o sistema não estiver mais congelado :)

Também estamos vendo esse problema. Ubuntu 14.04, 3.13.0-37-genérico

No servidor Ubuntu 14.04, minha equipe descobriu que o downgrade de 3.13.0-40-generic para 3.13.0-32-generic "resolve" o problema. Dada a observação de @sbward , isso colocaria a regressão após 3.13.0-32-generic e antes (ou incluindo) 3.13.0-37-generic.

Acrescentarei que, em nosso caso, às vezes vemos uma contagem de uso _negativa_.

FWIW encontramos este bug executando lxc no kernel confiável (3.13.0-40-generic # 69-Ubuntu) a mensagem aparece em dmesg seguida por este rastreamento de pilha:

[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

Encontrei isso no Ubuntu 14.04 e no Debian jessie com kernel 3.16.x.

Comando Docker:

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

Este parece ser um problema muito ruim ...

@jbalonso mesmo com 3.13.0-32-generic recebo o erro depois de apenas algumas execuções bem-sucedidas: sob:

@MrMMorris você poderia compartilhar um script de reprodutor usando imagens disponíveis ao público?

Todo mundo que está vendo esse erro em seu sistema está executando um pacote do kernel do Linux em sua distribuição que é muito antigo e não possui as correções para este problema específico.

Se você se deparar com esse problema, certifique-se de executar apt-get update && apt-get dist-upgrade -y e reinicializar o sistema. Se você estiver no Digital Ocean, você também precisa selecionar a versão do kernel que acabou de ser instalada durante a atualização porque eles não usam o kernel mais recente automaticamente (veja https://digitalocean.uservoice.com/forums/136585-digitalocean / sugestões / 2814988-give-option-to-use-the-droplet-s-own-bootloader).

Os usuários do CentOS / RHEL / Fedora / Scientific Linux precisam manter seus sistemas atualizados usando yum update e reiniciar após instalar as atualizações.

Ao relatar este problema, certifique-se de que seu sistema está totalmente corrigido e atualizado com as últimas atualizações estáveis ​​(sem pacotes experimentais / testing / alpha / beta / rc instalados manualmente) fornecidos pelo fornecedor de sua distribuição.

@unclejack

Corri apt-get update && apt-get dist-upgrade -y

ubuntu 14.04 3.13.0-46-genérico

Ainda recebo o erro após apenas um docker run

Posso criar um AMI para reproduzir, se necessário

@MrMMorris Obrigado por confirmar que ainda é um problema com o pacote do kernel mais recente no Ubuntu 14.04.

Qualquer outra coisa que eu puder fazer para ajudar, me avise! :sorriso:

@MrMMorris se você puder fornecer um reprodutor, há um bug aberto para o Ubuntu e será muito apreciado: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152

@rsampaio se eu tiver tempo hoje, com certeza terei isso para você!

Este problema também aparece em 3.16 (.7) no Debian 7 e no Debian 8: https://github.com/docker/docker/issues/9605#issuecomment -85025729. Reinicializar o servidor é a única maneira de corrigir isso por enquanto.

Ver este problema no RHEL 6.6 com kernel 2.6.32-504.8.1.el6.x86_64 ao iniciar alguns contêineres docker (nem todos os contêineres)
_ kernel: unregister_netdevice : esperando que lo se torne livre. Contagem de uso = -1_

Novamente, reiniciar o servidor parece ser a única solução neste momento

Também vendo isso no CoreOS (647.0.0) com kernel 3.19.3.

Reinicializar também é a única solução que encontrei.

Debian jessie testado com kernel sid (4.0.2) - o problema permanece.

Alguém está vendo esse problema ao executar contêineres não ubuntu?

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

Alguém está vendo esse problema ao executar contêineres não ubuntu?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/5618#issuecomment -113556862.

Este é um problema do kernel, não um problema relacionado à imagem. Trocar uma imagem por outra não vai melhorar nem piorar o problema.

Enfrentando problema no Debian Jessie em um BeagleBone Black executando kernel 4.1.2-bone12

Experimentando após mudar de 4.1.2 para 4.2-rc2 (usando git build de 1.8.0).
Excluir / var / lib / docker / * não resolve o problema.
Voltar para 4.1.2 resolve o problema.

Além disso, o VirtualBox tem o mesmo problema e há patch para v5.0.0 (retro-portado para v4) que supostamente faz algo na parte do driver do kernel .. vale a pena tentar entender o problema.

Esta é a correção no VirtualBox: https://www.virtualbox.org/attachment/ticket/12264/diff_unregister_netdev
Na verdade, eles não modificam o kernel, apenas o módulo do kernel.

Também tendo este problema com 4.2-rc2:

unregister_netdevice: aguardando que vethf1738d3 se torne livre. Contagem de uso = 1

Acabei de compilar 4.2-RC3, parece funcionar novamente

@ nazar-pc Obrigado pela informação. Basta acertar o 4.1.3 e fiquei muito chateado
@techniq mesmo aqui, bug de kernel muito ruim. Eu me pergunto se deveríamos relatar que ele foi feito o backport para a árvore 4.1.

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

Kernel do Ubuntu 15.04, mesmo problema

Eu vi isso com 4.2-rc3 também. Não há um bug sobre vazamento de dispositivo :) Eu posso reproduzir em qualquer kernel> = 4.1 em alta carga.

Eu também tive esse problema. Ubuntu 3.13.0-57-generic, provisionado via tutum. Infelizmente, ele enche o kern.log e o syslog e trava a máquina. Acontece na máquina do banco de dados (postgres dockerized), então desativa todo o sistema ...

Juntando-me ao coro de "eu também", estou vendo este problema em uma VM cloudstack executando o RancherOS (um sistema operacional mínimo) 0.3.3 ao puxar imagens do docker de um repositório docker privado local. Está acontecendo a cada dez segundos, não tenho certeza se isso significa alguma coisa ou não.

Também tendo esse problema com 4.2-rc7

Alguma notícia sobre isso, qual kernel devemos usar? Isso continua acontecendo mesmo com um kernel totalmente atualizado (3.19.0-26 no Ubuntu 14.04)

Nós também temos esse problema. Isso acontece depois de configurarmos userland-proxy = false. Estamos usando alguns scripts de monitor que irão gerar um novo contêiner do docker para executar o comando nagios plugins a cada 1 minuto. O que estou vendo na árvore de processos é que ele está preso no comando docker rm e está vendo muitos erros no arquivo 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 é a informação do nosso 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

Atualização: Embora https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152 diga que já está corrigido em 17/08/2015. Então, tentei com o kernel v3.19.8-ckt6-vivid que foi compilado em 02-Set-2015 ou mesmo v4.2.1-unstable que foi compilado em 21-set-2015 e ainda tem um problema.

Acabei de encontrar o problema novamente usando 3.19.0-28-generic , então o kernel ubuntu mais recente não é seguro

Sim, parece que --userland-proxy=false não é a melhor opção agora com kernels mais antigos :(

Não. Eu tentei --userland-proxy = false para todas as versões de kernel 3.19, 4.0, 4.2 e o problema ainda acontece.

Estou usando o proxy userland sem iptables (--iptables = false) e vejo isso uma vez por dia, no mínimo. Infelizmente, a única solução alternativa era um watchdog que reinicializava o servidor usando a técnica SysRq.

Meus sistemas executam alguns contêineres que são gravadores de stdout / err pesados, pois outros relataram que isso pode acionar o bug.

`` `` ``
informação de $ docker
Recipientes: 15
Imagens: 148
Driver de armazenamento: aufs
Dir raiz: / var / lib / docker / aufs
Sistema de arquivos de backup: extfs
Dirs: 178
Compatível com Dirperm1: verdadeiro
Driver de execução: nativo-0.2
Driver de registro: arquivo json
Versão do kernel: 3.19.0-26-genérico
Sistema operacional: Ubuntu 14.04.3 LTS
CPUs: 12
Memória total: 62,89 GiB
Nome: * *
ID: 2 ALJ: YTUH : QCNX: FPEO : YBG4: ZTL4: 2 EYK: AV7D : FN7C: IVNU: UWBL : YYZ5

versão $ docker
Versão do cliente: 1.7.0
Versão da API do cliente: 1.19
Versão Go (cliente): go1.4.2
Git commit (cliente): 0baf609
OS / Arch (cliente): linux / amd64
Versão do servidor: 1.7.0
Versão da API do servidor: 1.19
Versão Go (servidor): go1.4.2
Git commit (servidor): 0baf609
OS / Arch (servidor): linux / amd64```
`` `` ``

Infelizmente, estou no mesmo caso, hoje um servidor de produção falhou 3 vezes com esse erro, e a única maneira de lidar com isso é usar alguns comandos SysRq mágicos.

ressalto

Ainda estou vendo isso no último debian jessie usando o kernel 4.2.0

Mesmo problema aqui. De repente, três dos meus servidores aws caíram e os logs gritavam "unregister_netdevice: esperando que lo se torne gratuito. Contagem de uso = 1"

Ubuntu: 14.04
Versão do kernel: 3.13.0-63-genérico
Docker: 1.7.1

Syslog

Existe uma versão de kernel segura para uso?

O problema também acontece com o kernel 4.2 do Ubuntu 15.10

aconteceu em coreos:

Imagens: 1174
Driver de armazenamento: overlay
Sistema de arquivos de backup: extfs
Driver de execução: nativo-0.2
Driver de registro: arquivo json
Versão do kernel: 4.1.7-coreos
Sistema operacional: CoreOS 766.4.0

O bug do kernel que @ killme2008 disse da última vez

Você provavelmente deve tentar com este patch aplicado no topo do seu kernel http://www.spinics.net/lists/netdev/msg351337.html
pacote: condição de corrida em packet_bind

ou espere pelo backport na árvore -stable; isso virá mais cedo ou mais tarde.

: +1: Boas notícias!

Olá a todos, boas notícias!

Desde meu último comentário aqui (no momento da redação, 17 dias atrás), não recebi esses erros novamente. Meus servidores (cerca de 30 deles) estavam executando o Ubuntu 14.04 com alguns pacotes desatualizados.

Após uma atualização completa do sistema incluindo docker-engine (de 1.7.1 para 1.8.3) + atualização do kernel para a versão mais recente possível no repositório do Ubuntu, meus servidores estão funcionando sem nenhuma ocorrência.

:bola 8:

Aconteceu em 3 de nossa instância AWS hoje também:

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

Estou tendo o mesmo problema com o Ubuntu 14.04, todos os pacotes atualizados e o kernel linux-generic-lts-vivid mais recente:

$ 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

Eu o tinha com o último linux-image-generic (3.13.0-67-generic) também.

Tendo os mesmos problemas aqui no rancherOS.

Ainda acontecendo no Fedora 22 (atualizado) ....
Posso me livrar das mensagens se reiniciar o docker

systemctl restart docker
... a mensagem aparece novamente por cerca de 3-4 vezes e depois para

O mesmo erro me encontro com coreos:

versão do coreos:

 core @ core-1-94 ~ $ cat / etc / os-release
 NAME = CoreOS
 ID = coreos
 VERSION = 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"

versão docker:

 core @ core-1-94 ~ $ docker version
 Versão do cliente: 1.7.1
 Versão da API do cliente: 1.19
 Versão Go (cliente): go1.4.2
 Git commit (cliente): df2f73d-dirty
 OS / Arch (cliente): linux / amd64
 Versão do servidor: 1.7.1
 Versão da API do servidor: 1.19
 Versão Go (servidor): go1.4.2
 Git commit (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 Qui. 5 de novembro 02:10:23 UTC 2015 x86_64 Intel (R) Xeon (R) CPU E5-2660 v3 @ 2,60 GHz GenuineIntel GNU / Linux

registro do sistema:

 07 de dezembro 16:26:54 núcleo-1-94 kernel: unregister_netdevice: aguardando que veth775ea53 se torne livre. Contagem de uso = 1
 07 de dezembro 16:26:54 kernel-1-94 núcleo: unregister_netdevice: esperando que lo se torne livre. Contagem de uso = 2
 07 de dezembro 16:26:55 core-1-94 sdnotify-proxy [1203]: I1207 08: 26: 55.930559 00001 vxlan.go: 340] Ignorando não é uma falha: 4e: 5c: 47: 2f: 9a: 85, 10,244 .97,10
 07 de dezembro 16:26:59 core-1-94 dockerd [1269]: time = "2015-12-07T16: 26: 59.448438648 + 08: 00" nível = info msg = "GET / versão"
 07 de dezembro 16:27:01 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 01.050588 00001 vxlan.go: 340] Ignorando não perder: 5a: b1: f7: e9: 7d: d0, 10,244 .34,8
 07 de dezembro 16:27:02 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 02.398020120 + 08: 00" nível = info msg = "GET / versão"
 07 de dezembro 16:27:02 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 02.398316249 + 08: 00" nível = info msg = "GET / versão"
 07 de dezembro 16:27:04 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 04.449317389 + 08: 00" nível = info msg = "GET / versão"
 07 de dezembro 16:27:04 kernel-1-94 núcleo: unregister_netdevice: aguardando que veth775ea53 se torne livre. Contagem de uso = 1
 07 de dezembro 16:27:04 kernel-1-94 núcleo: unregister_netdevice: esperando que lo se torne livre. Contagem de uso = 2
 07 de dezembro 16:27:06 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 06.106573 00001 vxlan.go: 340] Ignorando não perder: a6: 38: ac: 79: 93: f5, 10,244 .47,24
 07 de dezembro 16:27:09 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 09.449944048 + 08: 00" nível = info msg = "GET / versão"
 07 de dezembro 16:27:11 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 11.162578 00001 vxlan.go: 340] Ignorando não uma falha: 0e: f0: 6f: f4: 69: 57, 10,244 .71,24
 07 de dezembro 16:27:12 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 12.502991197 + 08: 00" nível = info msg = "GET / versão"
 07 de dezembro 16:27:12 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 12.503411160 + 08: 00" nível = info msg = "GET / versão"
 07 de dezembro 16:27:14 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 14.450646841 + 08: 00" nível = info msg = "GET / versão"
 07 de dezembro 16:27:14 núcleo-1-94 kernel: unregister_netdevice: aguardando que veth775ea53 se torne livre. Contagem de uso = 1
 07 de dezembro 16:27:14 kernel-1-94 kernel: unregister_netdevice: esperando que lo se torne livre. Contagem de uso = 2
 07 de dezembro 16:27:16 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 16.282556 00001 vxlan.go: 340] Ignorando não perder: a6: 62: 77: 31: ef: 68, 10,244 .13.6
 07 de dezembro 16:27:19 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 19.451486277 + 08: 00" nível = info msg = "GET / versão"
 07 de dezembro 16:27:21 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 21.402559 00001 vxlan.go: 340] Ignorando imperdível: 92: c4: 66: 52: cd: bb, 10,244 .24,7
 07 de dezembro 16:27:22 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 22.575446889 + 08: 00" nível = info msg = "GET / versão"
 07 de dezembro 16:27:22 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 22.575838302 + 08: 00" nível = info msg = "GET / versão"
 07 de dezembro 16:27:24 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 24.452320364 + 08: 00" nível = info msg = "GET / versão"
 07 de dezembro 16:27:24 núcleo-1-94 kernel: unregister_netdevice: aguardando que veth775ea53 se torne livre. Contagem de uso = 1
 07 de dezembro 16:27:24 kernel-1-94 núcleo: unregister_netdevice: esperando que lo se torne livre. Contagem de uso = 2
 07 de dezembro 16:27:26 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 26.394569 00001 vxlan.go: 340] Ignorando não perder: 6a: f7: bf: ec: 03: 50, 10,244 .87,8
 07 de dezembro 16:27:29 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 29.453171649 + 08: 00" nível = info msg = "GET / versão"
 07 de dezembro 16:27:29 core-1-94 systemd [1]: Iniciando Generate / run / coreos / motd ...
 07 de dezembro 16:27:29 core-1-94 systemd [1]: Iniciado Gerar / executar / coreos / motd.
 07 de dezembro 16:27:32 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 32.671592437 + 08: 00" nível = info msg = "GET / versão"
 07 de dezembro 16:27:32 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 32.671841436 + 08: 00" nível = info msg = "GET / versão"
 07 de dezembro 16:27:33 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 33.562534 00001 vxlan.go: 340] Ignorando não é um erro: 22: b4: 62: d6: 25: b9, 10,244 .68,8
 07 de dezembro 16:27:34 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 34.453953162 + 08: 00" nível = info msg = "GET / versão"
 07 de dezembro 16:27:34 kernel-1-94 núcleo: unregister_netdevice: aguardando que veth775ea53 se torne livre. Contagem de uso = 1
 07 de dezembro 16:27:35 núcleo-1-94 kernel: unregister_netdevice: esperando que lo se torne livre. Contagem de uso = 2

feliz aniversário, problema sangrento =)
6 de maio de 2014

mesma coisa aqui. Apenas reiniciando. Versão mais recente do docker. Ubuntu 14.04.

@samvignoli isso foi identificado como um problema de kernel, então, infelizmente, não é algo que pode ser corrigido no docker

@thaJeztah Você tem um link para o bug tracker para o problema do kernel?
Ou talvez um ponteiro para quais kernel são afetados?

Desejosos de resolver isso em nosso ambiente.

@Rucknar , desculpe, não (talvez haja um nesta discussão, não li todos os comentários)

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

@Rucknar se você rolar um pouco para o topo - você verá o link para o patch http://www.spinics.net/lists/netdev/msg351337.html. Agora está no linux master, acho que irá para o Linux 4.4, talvez alguém já tenha feito backport para versões anteriores, mas não tenho certeza.

Obrigado a todos, veremos o que é necessário para atualizar.

FWIW Eu fiz backport do último patch mencionado aqui para o ubuntu 3.19 e também testei no kernel 4.2, ambos sem sucesso. O problema ainda está presente até mesmo no ramal 4.4-rc3 net-next neste ponto.

@rsampaio Como você testou isso? Não consigo acionar de forma confiável essa falha usando docker, na verdade, em qualquer kernel. Simplesmente acontece às vezes.

@fxposter também não podemos reproduzir o problema fora da produção, então tive que inicializar algumas instâncias com o kernel corrigido na produção. Isso acontece com tanta frequência que posso descobrir se um kernel foi afetado em 24h após a carga de produção.

Às vezes, podemos consertá-lo com um recurso muito incomum: movemos os diretórios do contêiner para longe de / var / lib / docker / aufs / mnt

Com isso ... TALVEZ possamos 'reiniciar o docker de serviço' e mover os diretórios de volta.

Caso contrário ... apenas reiniciando.

@rsampaio você está falando da produção do heroku agora? como evitar esse problema, pois todo o seu negócio é construído em torno de contêineres / etc?

@rsampaio você usa --userland-proxy=false ou apenas uma grande quantidade de containers criados? Posso reproduzi-lo facilmente com --userland-proxy=false e com alguma carga sem :)

@ LK4D4 Acredito que seja apenas uma grande quantidade de contêineres criados / destruídos, especialmente contêineres que fazem muito tráfego de saída, também usamos LXC em vez de docker, mas o bug é exatamente o mesmo que o descrito aqui, posso tentar reproduzir usando seu método se for fácil de descrever e / ou não envolver carga de produção, a ideia é obter um crash dump e _talvez_ encontrar mais dicas sobre o que exatamente desencadeia esse bug.

@rsampaio posso reproduzir com uso prolongado de https://github.com/crosbymichael/docker-stress

Houve alguma atualização / proposta para que isso seja corrigido?

@joshrendek é um bug do kernel. Parece que mesmo o kernel 4.4 recém-lançado não corrige isso, então há pelo menos mais uma condição de corrida em algum lugar :)

bug do kernel

=)

@samvignoli você poderia manter seus comentários construtivos? Sinta-se à vontade para abrir um PR se tiver maneiras de corrigir esse problema.

Este bug já foi relatado pelo upstream (lista de discussão do kernel)?

Claro que foi. o primeiro comentário também faz referência a esse bug: https://bugzilla.kernel.org/show_bug.cgi?id=81211

Aberto desde 2014. Nenhum comentário de ninguém que trabalhe nele, exceto para dizer que é mais provável que um aplicativo o esteja usando incorretamente.

Obrigado pelo link, Justin! Vou rastrear Linus =)

Atenciosamente. = *: coração:

@samvignoli, por favor, não faça isso, não ajuda ninguém.
Alguém pode reproduzir isso em uma pequena imagem de VM?
Talvez eu consiga sujar as mãos com gdb e muito kprintf.

bug ainda aberto.

SO: CentOS 7.2
kernel: 4.4.2 elrepo kernel-ml
docker: 1.10.2
fs: overlayfs com xfs

registro:

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 mostra ao executar a imagem do docker sameersbn / docker-gitlab:

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

Posso estar apenas com sorte - mas depois de aplicar essas configurações de sysctl, a ocorrência desse acontecimento diminuiu bastante.

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 qual é a motivação por trás dessas configurações?

@kmike isso foi para corrigir alguns outros problemas de conntrack (tabelas de ip ficando cheias) que estávamos enfrentando - parece ter feito algo em relação ao meu problema original, embora como um efeito colateral

Você poderia mostrar o antes / depois para que possamos ver o que realmente mudou? você está disposto a fazer uma pesquisa binária nessas configurações e ver se há um conjunto menor?

Estou usando o CoreOS Stable (899.13.0) em uma VM do Compute Engine. Este erro ocorre sempre que eu inicio o servidor com o seguinte sinalizador para 0 (o padrão). Eu testei várias vezes e com o IPv6 desabilitado posso iniciar todos os contêineres no nó sem nenhum erro:

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

Eu uso o contêiner gcloud para baixar do GCR, então talvez o problema seja IPv6 + download de MBs de imagens + fechar os contêineres rapidamente.

Versão do Docker para referência:

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

Também testei os sinalizadores sysctl anteriores nesta edição; mas alguns já têm esse valor e o resto não parece mudar nada relacionado a este erro:

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

Ainda estou tendo o problema quando defino net.ipv6.conf.all.disable_ipv6 = 1.

A ferramenta docker stress pode produzir o problema com muita facilidade.
https://github.com/crosbymichael/docker-stress

Este é o binário que criei para a ferramenta acima.
https://storage.googleapis.com/donny/main
https://storage.googleapis.com/donny/stress.json

Assim que vermos o log "unregister_netdevice: esperando que veth6c3b8b0 se torne gratuito. Contagem de uso", o docker está pendurado. Acho que este é um problema de kernel acionado pelo docker. Isso acontecerá apenas quando docker userland-proxy estiver desativado (--userland-proxy = false).

Já fiz isso acontecer com e sem userland proxy habilitado, então eu não diria apenas quando ele está desligado.

Pode ser que isso piore a situação; Sei que uma vez tentamos tornar --userland-proxy=false o padrão, mas revertemos isso porque havia efeitos colaterais https://github.com/docker/docker/issues/14856

Eu também vi o erro uma vez desde ontem, desabilitar claramente o IPv6 não é uma correção; mas sem o sinalizador não consigo nem iniciar todos os contêineres do servidor sem destruir o docker.

Correndo para isso no CoreOS 1010.1.0 com kubernetes 1.2.2 e docker 1.10.3

O Kubernetes adicionou uma sinalização ao kubelet (no celular, portanto, não é possível procurá-la) para
modo hairpin. Altere-o para "ponte promíscua" ou qualquer que seja o válido
o valor é. Não vimos esse erro desde que fizemos essa alteração.

@bprashanh

Por favor, confirme ou refute?
Em 13 de abril de 2016, 12:43, "Aaron Crickenberger" [email protected]
escreveu:

Correndo para isso no CoreOS 1010.1.0 com kubernetes 1.2.2 e docker
1.10.3

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/5618#issuecomment -209617342

Obtendo isso na AWS executando Linux 4.4.5-15.26.amzn1.x86_64 com Docker versão 1.9.1, compilar a34a1d5 / 1.9.1.

Ruby 2.3.0 com imagem Alpine está sendo executado dentro do contêiner, causando este

kernel: [58551.548114] unregister_netdevice: esperando que lo se torne livre. Contagem de uso = 1

Alguma correção para isso?

vi isso pela primeira vez em 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

Algumas reinicializações corrigiram o problema.

@MrMMorris Corrigido porque você tem certeza de que o problema desapareceu para sempre ou porque ainda não o está tendo de novo? Pode ser uma condição de corrida ...

É muito claro que esta é uma corrida no kernel, perdendo um refcount
algum lugar. Este é um bug REALMENTE difícil de rastrear, mas pelo que podemos dizer
ainda existe.

Na segunda-feira, 2 de maio de 2016 às 22h52, Sune Keller [email protected]
escreveu:

@MrMMorris https://github.com/MrMMorris Corrigido porque você tem certeza de que
o problema desapareceu para sempre ou você não o está enfrentando novamente
agora mesmo? Pode ser uma condição de corrida ...

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/5618#issuecomment -216444133

Sim. Tentei CoreOS 1032.0.0 com kernel 4.5 e o problema ainda existe.

Eu encontrei isso novamente no CoreOS 1010.1.0 com kernel 4.5.0 ontem, foi depois que vários contêineres foram iniciados e eliminados em rápida sucessão.

Eu tenho esse erro.

Versão do Docker: 1.9.1
Versão do kernel: 4.4.8-20.46.amzn1.x86_64
Sistema operacional: Amazon Linux AMI 2016.03

@sirlatrom não corrigido. Vendo isso novamente 😭 Várias reinicializações necessárias para resolver.

Atualmente executando 3.19.0-18-generic. Tentaremos atualizar para o mais recente

mesmo aqui! : chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar :: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar: : chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar :: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar: : chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar :: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar: : chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar :: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:: chorar:

@samvignoli seus comentários não são construtivos. Pare de postar.

desculpe, esqueci a função de polegar para cima.

Reproduzido no Fedora Server 23 - 4.2.5-300.fc23.x86_64. Não é possível reiniciar o serviço Docker - reinicie apenas o nó.

Mesmo problema no Fedora 24 Kernel: 4.5.2-302.fc24.x86_64. não causou travamentos, mas spams um arquivo de log.

@hapylestat Você pode tentar systemctl restart docker ? Isso fez com que tudo parasse para mim.

Obrigado

Isso está acontecendo com as minhas máquinas (CoreOS, EC2) com bastante frequência. Caso seja útil, aqui estão todos os logs relacionados ao dispositivo veth travado em uma instância desse bug.

$ 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

Isso parece acontecer quando eu removo muitos contêineres de uma vez (no meu caso, quando eu excluo k8s pods em massa).

Para aqueles que disseram que uma reinicialização corrigiu o problema - você reinicializou ou parou / inicializou as máquinas? Em máquinas físicas, tive que usar uma reinicialização remota de energia para fazer a máquina voltar a funcionar.

@joshrendek , tive que usar a inicialização a frio do iLO (ou seja, um ciclo de alimentação física).

@joshrendek Eu tenho um script agora que executa observando isso e faz reboot -f quando isso acontece 😢.

Pode ter encontrado o problema (ou apenas teve sorte). Mudei o diretório gráfico do Docker de um disco particionado XFS para um disco particionado EXT4 e não consigo reproduzir o problema (além de resolver muitos outros bugs XFS que estava recebendo). Lembro-me de @vbatts dizendo que o XFS ainda não é compatível.

Tentei provocar executando build , run , stop , delete em um loop infinito em imagens variadas, criando cerca de 10 contêineres a cada ciclo, para nas últimas horas.

@joedborg, qual driver de gráfico você está usando? Devicemapper? Sobreposição?

@thaJeztah Bom argumento, eu deveria ter mencionado isso. Estou usando o driver Overlay com (agora) EXT4 backing FS.

Eu costumava usar o mapeador de dispositivos (porque estou usando o Fedora Server), mas tive muita dor (como acredito que muitos fazem), especialmente com vazamentos em que o mapeador não retornava espaço para o pool depois que um contêiner foi excluído.

Se ajudar, estou no Docker 1.11.1 e no Kernel 4.2.5-300.fc23.x86_64.

@joedborg interessante, porque os documentos do RHEL mencionaram que apenas EXT4 é suportado no RHEL / CentOS 7.1, e apenas XFS no RHEL / CentOS 7.2. Eu esperava que o XFS funcionasse em versões mais recentes

@thaJeztah ah isso é estranho. Estou tentando pensar em outras coisas que possa ser. Eu reli do início e parece que algumas pessoas estão executando a mesma configuração. A única outra coisa que é diferente é que o disco XFS é um eixo e o EXT4 é SSD. Vou continuar o teste de imersão nesse meio tempo. Também mudei o produto para usar a mesma configuração, então, de qualquer forma, teremos uma resposta em breve. No entanto, estava acontecendo em quase todos os stop antes, então é certamente melhor.

@joedborg bem, é uma informação útil de fato

mesmo erro aqui, do kernel 4.2 ao 4.5, mesma versão do docker.

BTW, estou executando várias máquinas de caixa virtual na mesma caixa ao mesmo tempo.

$ 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

Estou tendo esse problema ao usar o driver de gráfico overlay , com o diretório em um ext4 FS. Portanto, não acho que xfs seja o problema 😢

@obeattie Sim, parece que as pessoas estão conseguindo em devicemapper também. Toque na madeira, não tive o problema novamente desde a mudança. Como mencionei, também troquei o disco físico. Isso vai ser interessante!

Este problema não se correlaciona com o sistema de arquivos de forma alguma. Eu vi esse problema com zfs, overlayfs, devicemapper, btrfs e aufs. Também com ou sem troca. Não está nem limitado ao docker, eu encontrei o mesmo bug com o lxc também. A única solução alternativa, que vejo atualmente, é não interromper o contêiner simultaneamente.

se ajudar, estou recebendo a mesma mensagem de erro na instância ec2 mais recente apoiada pelo AWS AMI. docker version shows-

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

Apenas subindo a bordo. Estou vendo o mesmo comportamento na instância mais recente do Amazon ec2. Depois de algum tempo, o contêiner vira e não responde.

informação de $ docker
Recipientes: 2
Imagens: 31
Versão do servidor: 1.9.1
Driver de armazenamento: devicemapper
Nome da piscina: docker-202: 1-263705-piscina
Tamanho do bloco da piscina: 65,54 kB
Tamanho do dispositivo básico: 107,4 GB
Sistema de arquivos de backup:
Arquivo de dados: / dev / loop0
Arquivo de metadados: / dev / loop1
Espaço de dados usado: 1,199 GB
Total de espaço de dados: 107,4 GB
Espaço de dados disponível: 5,754 GB
Espaço de metadados usado: 2,335 MB
Total de espaço de metadados: 2,147 GB
Espaço de metadados disponível: 2,145 GB
Compatível com Udev Sync: true
Remoção adiada ativada: falso
Exclusão adiada ativada: falso
Contagem de dispositivos excluídos adiados: 0
Arquivo de loop de dados: / var / lib / docker / devicemapper / devicemapper / data
Arquivo de loop de metadados: / var / lib / docker / devicemapper / devicemapper / metadata
Versão da biblioteca: 1.02.93-RHEL7 (2015-01-28)
Driver de execução: nativo-0.2
Driver de registro: arquivo json
Versão do kernel: 4.4.10-22.54.amzn1.x86_64
Sistema operacional: Amazon Linux AMI 2016.03
CPUs: 1
Memória total: 995,4 MiB
Nome: [redigido]
ID: OB7A: Q6RX: ZRMK: 4R5H : ZUQY: BBNK : BJNN: OWKS : FNU4: 7NI2: AKRT: 5SEP

versão $ docker
Cliente:
Versão: 1.9.1
Versão API: 1.21
Versão Go: go1.4.2
Git commit: a34a1d5 / 1.9.1
Construído:
OS / Arch: linux / amd64

Servidor:
Versão: 1.9.1
Versão API: 1.21
Versão Go: go1.4.2
Git commit: a34a1d5 / 1.9.1
Construído:
OS / Arch: linux / amd64

Da mesma forma que os comentários acima, a execução no EC2 também acontece por meio de um beanstalk elástico usando 64bit Amazon Linux 2016.03 v2.1.0 running Docker 1.9.1

Um tanto anedótico neste momento, mas recentemente tentei atualizar do kernel 4.2.0 para 4.5.5 em cerca de 18 servidores como um teste, e esse problema piorou consideravelmente (de vários dias para não mais de 4 horas entre os problemas).

Isso estava no Debian 8

Exatamente a mesma configuração de @jonpaul e @ g0ddard

Procurando ver como podemos ser capazes de mitigar esse bug.
A primeira coisa (que pode ou não funcionar, é arriscado) é manter a API disponível nos casos em que isso ocorrer: # 23178

Olá. Eu também fui mordido por esse bug ...

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

Estou usando o Kubernetes 1.2.4 no CoreOS Beta, Flannel e executando no Azure. Existe alguma maneira de ajudar a depurar esse problema? O thread de bug do kernel parece morto. Algumas pessoas relatam que desabilitar o IPv6 no kernel, usando --userland-proxy=true ou usando aufs em vez de sobreposição de armazenamento ajuda, enquanto outros não ... É um pouco confuso.

Como @ justin8 , também notei isso depois de atualizar meu sistema Fedora 23 para o kernel 4.5.5; o problema permanece com o kernel 4.5.6.

Encontramos esse bug quando o contêiner estava atingindo seu limite de memória. Não tenho certeza se está relacionado ou não.

mesmo problema aqui

# 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
o mesmo problema

Eu tenho um "one liner" que irá eventualmente reproduzir este problema para mim em um EC2 (m4.large) executando CoreOS 1068.3.0 com o kernel 4.6.3 (muito recente). Para mim, leva cerca de 300 iterações, mas YMMV.

Linux ip-172-31-58-11.ec2.internal 4.6.3-coreos # 2 SMP Sáb 25 de junho 00:59:14 UTC 2016 x86_64 Intel (R) Xeon (R) CPU E5-2676 v3 @ 2,40 GHz GenuineIntel GNU / Linux
CoreOS beta (1068.3.0)
Docker versão 1.10.3, compilação 3cd164c

Algumas centenas de iterações do loop aqui eventualmente travarão o dockerd e o kernel emitirá mensagens de erro como

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

O loop reprodutor é

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

EDITAR% S

• Só consegui reproduzir com isso quando userland-proxy=false
• NÃO consegui reproduzir usando o VirtualBox (apenas ec2 até agora), então talvez esteja relacionado ao hipervisor também

O script de @btalbot , acima, não reproduz o problema para mim no Fedora 23 após vários milhares de iterações.

$ 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)

Esse problema acontece com bastante frequência em meu cluster Kubernetes, no entanto, não posso reproduzi-lo de maneira confiável com os estressores ou com o único liner do

A primeira VM foi uma Standard_D1_v2 (3,5 GB de RAM, 1 núcleo) - o script fez> 3000 iterações.
A segunda VM era Standard_DS15_v2 (140 GB de RAM, 20 núcleos) - o script fez> 7600 iterações.

Atualizei meu comentário anterior (https://github.com/docker/docker/issues/5618#issuecomment-229545933) para incluir que só posso reproduzir isso quando userland-proxy = false.

Ele reproduz para mim em VMs EC2 t2.micro (núcleo único), bem como m4.large (núcleo múltiplo), ambos usando HVM. Ainda não vi isso acontecer usando o VirtualBox no meu laptop, embora não importe a configuração de userland-proxy.

Encontramos esse bug ao usar Flannel com hairpin-veth habilitado no cluster kubernetes (usando o proxy iptables). Esse bug estava acontecendo apenas quando executamos e interrompemos muitos contêineres. Passamos a usar a rede de ponte cbr0 e o modo hairpin de ponte promíscua e nunca mais o vemos.
Na verdade, é fácil reproduzir esse bug se você estiver usando o hairpin-veth, basta iniciar este trabalho com 100 contêineres com kubernetes.

Em 01/07/2016 08:01, manoj0077 escreveu:

@btalbot https://github.com/btalbot então com 1.12 podemos reiniciar
dockerd sem afetar a execução de contêineres. Então, o dockerd reiniciaria
ajuda aqui neste caso?

AFAICT, evento com 1.12, processos de contêineres docker ainda são filhos
do daemon docker.

@sercand como você configurou o modo de grampo de ponte promíscua? Não consigo ver nenhuma documentação do docker sobre isso, ou talvez eles estejam usando um nome diferente

Há alguma palavra oficial do Docker 🐳 sobre quando isso pode ser analisado? Este é o segundo problema aberto mais comentado ; é muito grave (exigindo uma reinicialização do host); é reproduzível; e não vejo nenhum progresso real para identificar a causa raiz ou consertá-la 😞.

Este parece ser um problema de kernel, mas o tíquete no Bugzilla está estagnado há meses. Seria útil postar nossos casos de teste lá?

@ justin8 Acho que essas são bandeiras Kubelet: --configure-cbr0 e --hairpin-mode

@sercand Eu também uso flanela. Existe alguma desvantagem em usar --hairpin-mode=promiscuous-bridge ?

@obeattie eu concordo. :(

FTR Eu consegui replicar o problema usando o trabalho estressante do

@sercand Você poderia detalhar as etapas para começar a usar promiscuous-bridge ? Eu adicionei o sinalizador --configure-cbr0=true ao kubelet do nó, mas ele reclama:
ConfigureCBR0 requested, but PodCIDR not set. Will not configure CBR0 right now . Achei que esse PodCIDR deveria vir do mestre. Obrigado.

EDITAR: Parece que precisei adicionar --allocate-node-cidrs=true --cluster-cidr=10.2.0.0/16 à configuração do gerenciador de controlador, mas como não tenho um provedor de nuvem (Azure), as rotas provavelmente não funcionarão.

@ justin8 Tenho seguido este doc .
@edevil da documentação hairpin-mode é para "Isso permite que os endpoints de um serviço se equilibrem de volta para si mesmos se eles tentarem acessar seu próprio serviço". A propósito, meu cluster é executado no Azure e não foi uma tarefa fácil de alcançar.

@sercand De acordo com o doc, se usarmos --allocate-node-cidrs=true no gerenciador de controlador, devemos usar um provedor de nuvem para configurar as rotas. Como não há provedor de nuvem Kubernetes para Azure, você não teve problemas? Você configura as rotas manualmente? Obrigado.

@edevil Eu uso o terraform para criar rotas. Você pode encontrá-lo neste repositório . Eu criei rapidamente esta configuração e testei apenas uma vez. Espero que seja o suficiente para fornecer uma lógica básica por trás disso.

@morvans @btalbot você teve a chance de tentar com 1.12 ...?

Posso confirmar que me afastando do hairpin-veth e usando a ponte cbr0 não consigo mais reproduzir o problema.

Só para garantir: alguém está tendo esse problema no bare metal? Nós vimos isso quando testamos o cluster de rancheiros em nosso laboratório VMWare, mas nunca vimos em uma implantação real bare metal.

Sim, esse problema ocorre no bare metal para qualquer kernel> = 4.3. Já vi isso em várias máquinas e configurações de hardware diferentes. A única solução para nós foi usar o kernel 4.2.

Definitivamente, ainda acontece no 4.2, mas é uma ordem de magnitude com mais frequência em qualquer coisa mais recente, eu tenho testado cada versão principal para ver se está melhor, e nada ainda

Também acontece no CoreOS alpha 1097.0.0.

Kernel: 4.6.3
Docker: 1.11.2

Eu tenho o mesmo problema.

Docker: 1.11.2
Kernel: 4.4.8-boot2docker.

Host: Máquina Docker com driver VMWare Fusion no OS X.

Alguma solução alternativa sugerida?

Seria realmente útil se aqueles de vocês que podem reproduzir o problema de maneira confiável em um ambiente onde um crashdump é possível (também conhecido como não EC2) pudessem de fato compartilhar este arquivo crashdump, mais informações sobre como habilitar o kdump no ubuntu trusty podem ser encontradas aqui e estas são as opções de travamento que você precisa habilitar quando o kdump estiver pronto para gerar um despejo de travamento:

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

O crashdump pode realmente ajudar os desenvolvedores do kernel a encontrar mais sobre o que está causando o vazamento de referência, mas tenha em mente que um crashdump também inclui um despejo de memória de seu host e pode conter informações importantes.

... informação sensata.

: o

Estou tendo o mesmo 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

O mesmo problema:

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

Docker version: 1.10.3

Aconteceu diretamente na tela do 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

sistema é

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

Mesmo problema

Os: Amazon Linux AMI release 2016.03
Docker: 1.9.1

Aqui também:

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

Estou vendo o mesmo problema no 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

(em todos os meus pty + beeper quando isso acontecer)
Backports do Debian Jessie + "simplesmente":

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

Olá,

Quando tento replicar o problema em um ambiente controlado, criando novas imagens destrutivas, não consigo reproduzi-lo.

O problema foi levantado em um dos servidores que executam o 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

Simultaneamente almocei o container 17753 até agora no modo concorrente e aumentando o tráfego para a internet, sem vazar nada da interface veth *. Alguém pode colar instruções para reproduzir o problema de forma consistente?

@pegerto Deve ser muito fácil de acionar se você tiver --userland-proxy=false e girar vários contêineres simultaneamente. Eu faço isso usando https://github.com/crosbymichael/docker-stress

Obrigado @ cpuguy83

Configurando o daemon para --userland-proxy=false Posso reproduzir facilmente o problema, obrigado, podemos ver que esse problema está afetando os daemons que não executam esta configuração.

Vejo um dump do kernel no gancho netfilter introduzido pela segregação netns em> = 4.3, alguma ideia de por que o problema parece pior quando a rota ocorre em 127/8?

Obrigado

Vendo esse problema também. CoreOS 1068.8.0, Docker 1.10.3, kernel 4.6.3. Eu puxei alguns dos logs do sistema se alguém estiver interessado.

Acabei de obter vários ...
unregistered_netdevice: waiting for lo to become free. Usage count = 1
... em 2 VMs e no meu laptop baremetal, todos executando o Ubuntu 16.04 e os kernels mais recentes (4.4.0-3 [456]).

O resultado é que tudo trava e requer uma reinicialização forçada.
Não experimentei isso antes da semana passada e acho que um dos VM estava em 1.11.3, enquanto os outros estavam em 1.12.0.

@RRAlex Isso não é específico para nenhuma versão do docker.
Se você estiver usando --userland-proxy=false nas opções do daemon ... OU (pelo que entendi) você estiver usando kubernetes, provavelmente encontrará esse problema.

O motivo é que a opção --userland-proxy=false habilita o NAT em hairpin na interface da ponte ... isso é algo que o kubernetes também define ao configurar a rede para seus contêineres.

Vendo isso em um nó BYO usando Docker Cloud (e agente Docker Cloud).

Vi isso hoje, uma vez (em cerca de 25 tentativas) nas AMIs atuais do Amazon ECS, executando vanilla debian: jessie com um comando que apt-get updates, instala o pbzip2 e o executa (teste de CPU multithread simples).

@edevil
A maioria de vocês aqui descreve que encontra essa situação ao usar o Docker para iniciar / parar contêineres, mas eu tenho exatamente a mesma situação sem o Docker, no Debian:

• Debian "Jessie" (= Debian versão 8.5), em baremetal (sem VM, sem nuvem, mas hardware simples)
• kernel 3.16.0-4-amd64
• ter 4 contêineres LXC iniciados
• feche um contêiner LXC com "lxc-stop -n $ containerName"
• quando este comando é concluído, o kernel ou as interfaces provavelmente não estão totalmente 'limpos' ainda, porque quando eu imediatamente após o "lxc-stop" anterior iniciar um novo "lxc-stop", então eu tenho o problema do kernel

Nenhuma maneira de recuperar, exceto uma reinicialização forçada da máquina.

Portanto, em suas investigações para localizar / resolver esse problema, não se concentre apenas no Docker. É óbvio um problema genérico com início / parada rápida de contêineres, seja por meio do Docker ou por meio de comandos "lxc" simples.

Eu acho que este é um problema do kernel do Linux.

Eu encontrei este problema quando tenho 3 chroot (na verdade, pbuilder) rodando com uma carga muito pesada.
Meu hardware é Loongson 3A (uma máquina mips64el com kernel 3.16).

Quando estou tentando me aprofundar, encontrei esse problema.

Portanto, esse problema pode não ser apenas sobre o docker ou o lxc, mas também sobre o chroot.

Docker versão 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 puro.

Recentemente, tivemos o problema no bare metal (dedicado no ovh) com kernel 4.6.xe docker 1.11.2.
Depois de ler os comentários aqui e tentar várias soluções alternativas, fizemos o downgrade de nosso kernel para a versão mais recente do branch 3.14 (3.14.74) e atualizamos o docker para 1.12.0 para evitar https://github.com/docker/libnetwork/issues/1189 e tudo parece estar bem por enquanto.

Espero que isso possa ajudar.

Tudo, acho que você não precisa mais postar mensagens sobre Docker ou chroot, é tudo sobre o kernel do Linux.
Então, por favor, pode se levantar alguém que possa depurar de alguma forma o kernel, nas partes em que está desabilitando interfaces de rede virtual para containers? Talvez haja alguma condição de corrida acontecendo quando uma parada anterior de um contêiner ainda não desabilitou / limpou totalmente sua interface virtual, antes que uma nova parada de um contêiner seja solicitada.

@rdelangh Não acho que esse problema esteja necessariamente relacionado ao kernel.

No Fedora 24, não consigo reproduzir o problema com o Docker 1.10.3 dos repositórios do Fedora, apenas com o Docker 1.12.1 dos próprios repositórios do Docker.

Ambos os testes foram conduzidos com o kernel 4.6.7-300.fc24.x86_64.

Vendo esse problema também no 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 o Kubernetes 1.3.4 no CoreOS 1068.9.0 estável no EC2, docker 1.10.3, vejo esse 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

Também vejo esse problema no 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 aqueles que usam Kubernetes <= 1.3.4, você pode explorar esse problema: https://github.com/kubernetes/kubernetes/issues/30899 para reproduzir esse problema. Executei um pequeno cluster com 1 controlador (m4.large) e 2 Workers (m4.large) no CoreOS 1068.10.

A partir daí, você pode criar 2 ReplicationControllers, chamei-os de hello e hello1 base nisto: http://pastebin.com/mAtPTrXH . Certifique-se de alterar os nomes e rótulos para serem diferentes.

Em seguida, crie 2 implantações que correspondam aos mesmos nomes / rótulos acima com base nisto: http://pastebin.com/SAnwLnCw .

_Assim que você criar as implantações, você obterá uma quantidade absurda de contêineres de spam_.

Se você deixá-lo ligado por um tempo (vários minutos), verá muitas coisas tentando encerrar / criar. Você pode excluir as implantações e deixar as coisas se estabilizarem. Você deve ver um bom punhado de Terminating e ContainerCreating. Se você ssh nos nós, verifique dmesg e docker ps para ver se os sintomas acima são aparentes.

No meu caso, demorei cerca de 5 minutos para deixar esse maluco antes de ver o problema. Estou pensando em fazer as alterações com as quais @sercand e @edevil estavam brincando e ver se isso funciona para mim neste caso.

@edevil Depois de olhar seu commit vinculado, estou correto que você desativou / removeu a Flanela em seu ambiente em favor da ponte cbro criada pelo Kubernetes para superar esse problema?

Estou vendo que você não conseguiria usá-los em conjunto porque a flanela deseja usar docker0 e sua rede interna estaria funcionando em cbr0 correto?

@ alph486 correto, parei de usar flanela. Eu uso a ponte e configuro as rotas para a rede pod.

@ alph486 flannel não deseja usar docker0. É apenas a ponte padrão para docker, que você pode substituir com a opção --bridge=cbr0 docker.
No CoreOS, você teria que substituir a unidade docker systemd.

O sinalizador Kubelet --experimental-flannel-overlay pode ler a configuração da flanela e configurar a ponte docker cbr0 com o CIDR da flanela.

Ele também ativará o modo promiscuous vez de veth-hairpin que parece ser o problema.

Obrigado @dadux pela contribuição. Se K8s pegar a interface cbr0 que já foi inicializada pela unidade sobrescrita, poderia estar em negócios com essa solução; vou tentar.

De acordo com a documentação, promiscuous-bridge parece ser o valor padrão para --hairpin-mode no kubelet v1.3.4 +. Ainda estou vendo o problema com isso, então não tenho certeza se essa é a solução completa.

Não consegui reproduzir o problema novamente depois de usar o plug-in de rede kubenet (que foi configurado para substituir --configure-cbr0 ). Estou meio que evitando a opção flannel-overlay devido à incerteza de seu futuro (parece estar ligada a --configure-cbr0 ).

Se o seu daemon do docker usa a ponte docker0 , a configuração --hairpin-mode=promiscuous-bridge não terá efeito, pois o kubelet tentará configurar a ponte inexistente cbr0 .

Para CoreOS, minha solução alternativa para espelhar o comportamento do Kubernetes, mas ainda usando flanela:

• Adicione um drop-in systemd para docker.service para configurar a interface de ponte docker0 para o modo promíscuo. (Certamente há um desejo mais elegante de fazer isso?):

- 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

• Diga ao kubelet para não definir o grampo de cabelo na ponte do docker:
  kubelet --hairpin-mode=none

Você pode verificar se o hairpin está habilitado para suas interfaces com
brctl showstp docker0
ou
for f in /sys/devices/virtual/net/*/brport/hairpin_mode; do cat $f; done

Acho que meu colega corrigiu isso recentemente http://www.spinics.net/lists/netdev/msg393441.html , encontramos esse problema em nosso ambiente e depois encontramos o problema, com essa correção, nunca encontramos esse problema, mais. Qualquer pessoa que encontrou esse problema, pode tentar este patch e ver se isso acontece novamente. E de nossa análise, ele está relacionado ao ipv6, então você também pode tentar desabilitar o ipv6 do docker com --ipv6=false ao iniciar o daemon do docker

@ coolljt0725 Talvez eu esteja errado, mas ipv6 está desabilitado por padrão no docker e acabei de reproduzir o problema via docker-stress com a opção "--ipv6 = false" (que é o padrão de qualquer maneira). Ainda não tentei seu patch.

@dadux Obrigado por sua ajuda. No Kubernetes 1.3.4 CoreOS 1068 Stable, Docker 10.3, Flannel como camada de rede, resolvi o problema fazendo as seguintes alterações em minhas 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

Adicionado o seguinte a kubelet.service :

        --hairpin-mode=none

Que efeito essas mudanças no Docker / Kubernetes têm em relação a como o O / S lida com interfaces para contêineres?
Devo enfatizar que é um problema com o comportamento O / S errado, não Docker ou Kubernetes, porque nós (e algumas outras pessoas neste thread) não estamos executando Docker ou Kubernetes, mas ainda encontramos exatamente as mesmas situações ao parar o LXC recipientes muito rapidamente um após o outro.

@rdelangh Você está correto. No entanto, esse problema foi criado no projeto Docker para rastrear o comportamento relacionado ao Docker. Há outros problemas mencionados neste thread rastreando-o como um problema do sistema operacional, um problema do K8s e um problema do CoreOS. Se você encontrou o problema no LXC ou em qualquer outro lugar, recomendo que você inicie um tópico lá e faça o link aqui para aumentar a conscientização sobre o problema.

Quando aqueles que usam o Docker google para esse erro, provavelmente vão pousar aqui. Portanto, faz sentido publicarmos soluções alternativas para esse problema aqui, de modo que, até que os problemas subjacentes sejam corrigidos, as pessoas possam seguir em frente.

Que efeito essas mudanças no Docker / Kubernetes têm em relação a como o O / S lida com interfaces para contêineres?

1. A mudança do docker em minha postagem permite que o docker de interrogação da pilha do Kubernetes garanta que a plataforma esteja íntegra quando o problema ocorrer.
2. a mudança hairpin-mode essencialmente diz ao K8s para usar a ponte docker0 como está e, portanto, não tentará usar a rede "kernel land" e "hairpin veth", que é onde o problema começa no Docker caminho de execução.

É uma solução alternativa para esse problema usando K8s e Docker.

O patch de coolljt0725 colegas está na fila de espera para estável, então espero que ele seja transportado para as distros em breve. (Postagem de David Miller: http://www.spinics.net/lists/netdev/msg393688.html)

Não tem certeza de onde está esse commit e se devemos enviá-lo para o Ubuntu, RH, etc. para ajudá-los a rastreá-lo e transportá-lo?

Vai aparecer aqui em algum momento, eu acho:
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/ipv6/addrconf.c

EDIT: parece estar presente aqui: https://github.com/torvalds/linux/blob/master/net/ipv6/addrconf.c

Obrigado a coolljt0725 e co (e a todos neste tópico). Como muitas pessoas não conseguirão atualizar para um kernel com o patch ipv6 por algum tempo, (todos, atualmente), consegui eliminar esse bug depois de tentar muitas das sugestões deste tópico. Quero fazer um post completo para acompanhar coisas que funcionaram e não funcionaram para que ninguém mais veja os problemas que eu vi.

TL; DR desabilite o ipv6 nos parâmetros de inicialização do Linux, reinicie. em coreos, isso significa que /usr/share/oem/grub.cfg tem o conteúdo: set linux_append="ipv6.disable=1" e então uma reinicialização. uma sugestão de propósito mais geral que deve funcionar em centos / ubuntu / debian / $ linuxes pode ser encontrada aqui

• tentei ipvlan (l2, l3) / macvlan (bridge): nenhum desses funciona em aws, ou pelo menos, não possuo nem consegui encontrar o conhecimento para conseguir algum deles para funcionar em aws. por trabalho, quer dizer, iniciando um container conectado em uma rede com ipvlan ou macvlan, não consegui pingar o gateway / conectar a internet (sim, testei a ideia básica trabalhando em ambiente não aws). Isso de fato pareceu resolver o problema em questão, mas para nosso caso de uso, precisamos ser capazes de nos conectar à Internet - para casos de uso que não o fazem, esta pode ser uma opção viável e parece muito sexy em comparação com a ponte .
• tentei as seguintes sinalizações passadas para dockerd individualmente e com certas combinações (uma vez que nenhuma delas parecia funcionar, não fui muito científico sobre tentar todas e quaisquer combinações):

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

curiosamente, --ipv6=false realmente não parece fazer nada - isso era bastante desconcertante, os contêineres ainda recebiam endereços inet6 com este sinalizador.

--userland-proxy=false define o modo hairpin e não era esperado que funcionasse realmente. em conjunto com isso, eu tinha alguma esperança, mas isso também não resolveu o problema (definir docker0 para o modo promisc). Há uma menção de uma correção para --userland-proxy=false aqui e isso pode ser lançado em breve e valer a pena tentar novamente, seria bom desligar isso, independentemente do bug observado neste problema para desempenho, mas infelizmente tem outro bug neste momento.

• tentei desabilitar ipv6 através das configurações sysctl documentadas aqui e reiniciar systemd-networkd depois de aplicar as configurações sysctl, bem como tentar desabilitar ipv6 do dhcpcd conforme documentado aqui e isso não foi suficiente para desabilitar ipv6 porque ele ainda está ligado, mesmo se nenhuma interface estiver usando isso.
• como foi sugerido aqui , testamos essa solução, removendo apenas um contêiner por vez, e ainda encontramos esse bug.

demasiado longo; leu: desative o ipv6 nas configurações do grub. reinício. lucro.

Enfrentou esse problema no CentOS 7.2 (3.10.0-327.28.3.el7.x86_64) e Docker 1.12.1 (sem k8s). O problema surge quando o tráfego da rede aumenta.
A inicialização do kernel com ipv6 desabilitado (de acordo com o conselho anterior) não ajudou.
Mas transformar a interface docker0 no modo promisc corrigiu isso. O systemd usado por @dadux (obrigado!) - parece estar funcionando bem agora.

@rdallman Desativar ipv6 via grub não impede unregister_netdevice para mim no ubuntu 16.06 (kernel 4.4.0-36-genérico) ou 14.04 (kernel 3.13.0-95-genérico). Independentemente da configuração --userland-proxy (verdadeiro ou falso).

Ooooh, isso é legal que o patch estava na fila para estável.
ping @aboch para o problema de que --ipv6=false não faz nada.

@trifle desculpe :( obrigado por postar informações, ainda não temos problemas após alguns dias de teste, mas iremos atualizar novamente se encontrarmos quaisquer problemas. estamos executando o coreos 1122.2 (kernel 4.7.0). configurando docker0 para o modo promisc parece consertar isso para algumas pessoas (sem sorte para nós).

@RRAlex Você sabe se alguém entrou em

Lista de e-mails da equipe do kernel do Ubuntu:
https://lists.ubuntu.com/archives/kernel-team/2016-September/thread.html

Patch para o kernel estável:
https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d

Registro de confirmação do kernel do Ubuntu:
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/?h=master-next
(Patch ainda não está lá)

@leonsp , tentei entrar em contato com eles sobre o que parece ser o problema relacionado:
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1403152

Se você olhar a última (# 79) resposta, alguém construiu um kernel para o Xenial com aquele patch:
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1403152

Não tenho certeza quando está indo para a árvore principal do kernel do Ubuntu, nem qual é a relação dessa pessoa com o Ubuntu e se isso vai ajudar ...

Eu também não consigo encontrar os commits mencionados desse thread no log de commit do kernel do Ubuntu.

@RRAlex Os commits mencionados estão no branch do ddstreet ~ ddstreet / + git / linux: lp1403152-xenial , aqui está o log: https://code.launchpad.net/~ddstreet/+git/linux/+ref/lp1403152-xenial
Portanto, qualquer pessoa com esse problema no Ubuntu 16.04 pode tentar. https://launchpad.net/~ddstreet/+archive/ubuntu/lp1403152

Possivelmente @sforshee sabe (para o kernel do Ubuntu)

Finalmente consegui testar a solução "ipv6.disable = 1". Além disso - eu atualizei para o kernel 4.7.2 no meu debian 8.
Após a atualização do kernel e habilitando "ipv6.disable = 1" nos parâmetros do kernel, consegui detectar o problema de "esperando por lo" na carga de trabalho real, mesmo sem a sinalização "--userland-proxy = false" para docker daemon. A boa notícia é que depois de especificar "--userland-proxy = false" e tentar reproduzir o problema com "docker-stress" - não posso mais fazer isso. Mas tenho certeza de que surgirá novamente, independentemente do valor "--userland-proxy".
Portanto, pelo que vejo - o ipv6 está definitivamente envolvido neste problema, porque agora o docker-stress não é mais capaz de detectar o problema. A má notícia é que o problema ainda está lá (ou seja, foi corrigido apenas parcialmente).

Compilará o último 4.8rc7 mais tarde para testar mais.

@ twang2218 @ coolljt0725

Hmmm .. então eu tentei o kernel Ubuntu xenial 4.4.0-36 com o patch backport do ppa do 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

Infelizmente, isso não parece resolver o problema para mim. Observe que também estou executando com "ipv6.disable = 1". Estamos olhando para várias causas não relacionadas com o mesmo resultado? Muitos dos comentários neste tópico parecem sugerir isso.

Não sei muito sobre eles, mas sei que já tivemos insetos como esse antes. Pelo que entendi, as contagens de referência para qualquer dispositivo de rede acabam sendo transferidas para lo quando um namespace de rede está sendo limpo, então "esperar que lo se torne livre" significa que há um vazamento de contagem de referência para algum dispositivo de rede, mas não necessariamente para lo diretamente. Isso os torna difíceis de rastrear, porque quando você sabe que houve um vazamento, não sabe a que dispositivo ele estava associado.

Não li todos os comentários, mas se alguém puder me dar um reprodutor confiável no Ubuntu, vou dar uma olhada nele e ver se consigo descobrir alguma coisa.

@sforshee nem sempre é fácil de reproduzir, mas foi criado um patch (que pelo menos corrige alguns dos casos relatados aqui); http://www.spinics.net/lists/netdev/msg393441.html. Isso foi aceito upstream https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d

@thaJeztah ah, vejo a pergunta que você estava me dirigindo agora.

Portanto, o patch está na fila estável do upstream 4.4, para o 16.04 é provável que seja incluído não no próximo SRU do kernel (que já está em andamento), mas no seguinte, cerca de 5-6 semanas a partir de agora. Se for necessário no 14.04 também, por favor me avise para que possa ser feito o backport.

@sforshee basicamente antes (antes desse patch) que poderia ser reproduzido habilitando ipv6 no kernel (geralmente habilitado por padrão), adicionando "--userland-proxy = false" aos sinalizadores de daemon do docker e, em seguida, executando docker-stress -c 100 , para exemplo (docker-stress é daqui: https://github.com/crosbymichael/docker-stress)

Obrigado @fxposter . Se houver uma correção para isso, no entanto, tudo que eu realmente preciso me preocupar é em conseguir essa correção no kernel do Ubuntu. Também posso ajudar a verificar outros vazamentos que não foram corrigidos por aquele patch.

Também estou tendo esse problema. Estou executando o docker dentro de uma caixa rancherOS da AWS. Na verdade, isso acontece aleatoriamente após configurar um cluster de fazendeiros (3 hosts) e executar um pequeno aplicativo nele.

mesmo ... Fedora 24, acontece aleatoriamente, pode ficar bem por uma semana, então eu recebo um a cada 10 horas
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Experimentando em CentOS 7 executando kernel 3.10.0-327.36.1.el7 e docker 1.12.1

O downgrade para o kernel 3.10.0-327.18.2.el7 enquanto permanece no docker 1.12.1, parece ter estabilizado o sistema.

Eu também estou vendo isso:
Docker versão 1.11.2
Ubuntu 16.04.1 4.4.0-38-genérico

ipv6 desativado (grub)

Acabei de ter este problema sem --userland-proxy=false (sic!) No servidor com kernel 4.8.0-rc7, que inclui patch ipv6 (sic !!). Então, talvez isso resolva alguns dos problemas, mas não todos, definitivamente.

Alguém sabe como isso pode ser depurado?

Descobrimos que isso só ocorre em nossa configuração quando (quase) ficamos sem memória livre.

@fxposter Seria útil encontrar um caso de reprodução mínimo, o que é meio difícil: / Então poderíamos usar ftrace para pelo menos encontrar caminhos de código.

Acontecendo no 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 infelizmente não é mais possível reproduzi-lo via docker-stress (pelo menos não consegui). Vou tentar imitar nossa configuração anterior com webkits (que desencadeou esse problema com muito mais frequência do que eu gostaria).

@fxposter Esse patch corrige apenas alguns dos problemas (mas em nosso ambiente, nunca mais o encontramos com esse patch), não todos, vou deixar meu colega continuar investigando esse problema. Se você tiver alguma maneira de reproduzir isso, por favor me avise, obrigado :)

A correção está em 4.4.22 estável https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.22

Publiquei um pedido para o Redhat aplicar este patch ao Fedora 24.

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

4.4.0-42 ainda está quebrado com certeza ...
Mencionei isso aqui para o Ubuntu, mas talvez alguém tenha uma ideia melhor:
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1403152

Também estou vendo isso, Docker versão 1.11.2, compilação b9f10c9 / 1.11.2, Amazon Linux 2016.03 v2.1.6 de 64 bits.

ainda aconteceu. docker 1.12.2, kernel do linux armbian 4.8.4, ipv6.disable = 1 em bootargs

como consertar o bug, encontro-o todos os dias

@woshihaoren Não use --userland-proxy=false

Para esclarecer - nós também enfrentamos o problema do userland-proxy desabilitado

Obtendo isso no Amazon Linux AMI 2016.9:

$ uname -a

Linux 4.4.23-31.54.amzn1.x86_64 #1 SMP

Versão do Docker:

`` `Cliente:
Versão: 1.11.2
Versão API: 1.23
Versão Go: go1.5.3
Git commit: b9f10c9 / 1.11.2
Construído:
OS / Arch: linux / amd64

Servidor:
Versão: 1.11.2
Versão API: 1.23
Versão Go: go1.5.3
Git commit: b9f10c9 / 1.11.2
Construído:
OS / Arch: linux / amd64
`` `

kernel 4.4.30 do centos7 novamente ~~~~

CoreOS 1185.3.0, 4.7.3-coreos-r2, Docker 1.11.2
Reproduzível apenas executando 10..20 debian: jessie containers com "apt-get update" como comando.

CoreOS estável ainda está atingido. A correção para a série 4.7 está em 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 - Não há soluções neste post, mas eu listo o que tenho perseguido até agora e minhas teorias de trabalho atuais. Espero que outras pessoas que também estão perseguindo isso possam encontrar algumas informações úteis enquanto analisamos isso.

@koendc Obrigado por postar o patch que foi introduzido no 4.7.5. I volta portado o (751eb6b6042a596b0080967c1a529a9fe98dac1d upstream) 4e1b3aa898ea93ec10e48c06f0e511de37c35b2d remendo ao meu 4.5.5 setup [1] e foi capaz de reproduzir facilmente o problema unregister_netdevice. É possível que outras mudanças no kernel 4.7.x funcionem junto com o patch fornecido para resolver esse problema, mas eu ainda não confirmei isso, então não devemos perder todas as esperanças ainda. Estou testando com 4.5.5 porque tenho um caso de teste reproduzível para causar o problema, discutido em [2].

Outras coisas que confirmei com base em testes:

• 4.2 é muito mais estável do que qualquer kernel posterior
• 4.5.x é trivialmente reproduzível. Dos kernels mais novos que testei extensivamente (4.8.2 e 4.8.6), o problema ainda existe, embora o tempo para a primeira ocorrência variou de 60s a 48 horas
• O problema parece estar correlacionado ao tráfego de rede e à proporção de contêineres para capacidade de recurso pai (virt cpu). Como outros têm iludido, isso pode ser uma pista falsa se esta for realmente uma condição de corrida

Próximos passos:

• Instrumentar um kernel com as instruções printk apropriadas para tentar encontrar um caso em que os recursos alocados não sejam liberados
• Teste o kernel 4.7.5 ou posterior com / sem o patch mencionado para ver se o problema ocorre
• Pouco antes de uma das falhas, eu vi um conjunto muito interessante de IPv6: eth0: IPv6 duplicate address <blah> detected erros. Pode ser outra pista falsa, mas quero tentar exercitar a desativação do ipv6 para ver se há uma correlação

[1] Minha configuração completa é um GCE virt rodando um kernel debian ligeiramente customizado baseado em 4.5.5 . Docker version 1.8.3, build f4bf5c7 está sendo executado em cima disso
[2] Informações do caso de teste: tenho 20 processos paralelos, cada um inicia um servidor Node.js hello world dentro de um contêiner docker. Em vez de retornar hello world , o servidor Node.js retorna 1 MB de texto aleatório. O processo pai está em um loop apertado que inicia o contêiner, se curva para recuperar o 1 MB de dados e para o contêiner. Usando essa configuração, posso reproduzir consistentemente o problema nos anos 4-90. Usar esta mesma configuração em um host físico ou dentro de uma caixa virtual não reproduz o problema, apesar de vários itens que alteram o tempo médio de reprodução na caixa GCE. Variáveis ​​com as quais estou brincando: número de processos de teste simultâneos, tamanho da carga transferida e quantidade de chamadas curl. As duas primeiras variáveis ​​estão definitivamente correlacionadas, embora eu ache que é provável apenas ajustar as variáveis ​​para encontrar um ponto de saturação razoável para virt.

Eu também estou tendo esse erro.

Eu vejo isso repetido 3 vezes após a implantação de um contêiner.

Descrição

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

Etapas para reproduzir o problema:

1. ssh para o host docker
2. executar um contêiner

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

Descreva os resultados que você recebeu:

Basta repetir o erro 3 vezes.

Descreva os resultados que você esperava:
Sem erro

Informações adicionais que você considera importantes (por exemplo, o problema acontece apenas ocasionalmente):
Só comecei a acontecer depois deste fim de semana.

Resultado de docker version :

 docker --version
Docker version 1.12.3, build 6b644ec

Resultado 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

Detalhes adicionais do ambiente (AWS, VirtualBox, físico, etc.):

Máquina virtual:
Fedora 24
OverlayFS2 em ext3

Unidade separada alocada para docker usa 24 GB.
16 GB 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

Imagens 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

Docker Volume 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

Free -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 qualquer um dos interessados, nós (Travis CI) estamos lançando uma atualização para v4.8.7 no Ubuntu 14.04. Nossos testes de carga não mostraram ocorrências do erro descrito aqui. Anteriormente, estávamos executando linux-image-generic-lts-xenial no Ubuntu 14.04. Estou planejando publicar uma postagem no blog em um futuro próximo, descrevendo mais detalhes.

ATUALIZAÇÃO : Eu deveria ter mencionado que estamos executando esta pilha do 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

ATUALIZAÇÃO : _ainda_ estamos vendo este erro na produção do Ubuntu Trusty + kernel v4.8.7. Ainda não sabemos por que esses erros desapareceram nos testes de carga de preparação que anteriormente reproduziam o erro, mas a taxa de erro na produção é efetivamente a mesma. Para frente e para cima. Desativamos a "implosão automática" com base neste erro, devido à alta taxa de rotatividade de instâncias .

também encontrado em 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

A mesma coisa está acontecendo aqui com um DigitalOcean VPS no teste 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

Eu tenho testado 4.8.8 em um loop apertado (veja [2] do meu comentário anterior para o caso de teste) sem parar nos últimos 4 dias. Até agora tudo bem.

Fatos

• O patch 751eb6b6 reduz significativamente a ocorrência desse problema, mas não o elimina totalmente.

Suposições
@meatballhat apontou que seus servidores de produção tiveram o problema durante a execução do 4.8.7. Isso nos deixa com duas possibilidades:

• Meu caso de teste de teste está com defeito (a possibilidade mais provável)
• 4.8.8 introduziu uma correção. Olhando para o changelog 4.8.8 , os commits 5086cadf e 6fff1319 mencionam problemas do netdev que foram resolvidos. Nenhum deles chama explicitamente o problema aqui, mas ambos estão próximos o suficiente para suspeitar.

Podemos fazer com que algumas pessoas experimentem o 4.8.8 para ver se conseguem reproduzir esse problema?

@reshen Vou nos atualizar para 4.8.8 e relatar: +1: Muito obrigado por sua pesquisa!

@reshen Excelente pesquisa. Até agora, também não consegui reproduzir o problema usando o Linux 4.8.8 no Xubuntu 16.04.

Tenho usado as compilações do kernel principal do

Para testar o Linux 4.8.8, o mais fácil para mim foi mudar de aufs para overlay2 como driver de armazenamento, pois as compilações do kernel principal não incluíam aufs. Não acho que vá influenciar o teste, mas deve ser observado.

No passado eu testei o Linux 4.4.4 com o 751eb6b6 backport de Dan Streetman, isso não pareceu reduzir o problema para mim. Será interessante ver se também o backport dos dois patches observados por você (5086cadf e 6fff1319) pode dar o mesmo resultado que 4.4.8.

Ubuntu 16.04 com 4.4.0-47 ainda foi afetado ... tentando 4.4.0-49 agora, relatarei mais tarde.

editar: 2016-11-28: -49 está ainda mostrando essa linha de log no dmesg.

Experimentei isso no Fedora 25 (kernel 4.8.8) e Docker 1.12.3

Para sua informação: estamos executando o Linux 4.8.8 em conjunto com o Docker v1.12.3 em um único host de produção. O tempo de atividade atualmente é de 5,5 dias e a máquina permanece estável.

Ocasionalmente, vemos um punhado de unregister_netdevice: waiting for lo to become free. Usage count = 1 mensagens no syslog, mas ao contrário de antes, o kernel não trava e a mensagem vai embora. Suspeito que uma das outras alterações introduzidas no Kernel ou no Docker detecta essa condição e agora se recupera dela. Para nós, isso agora torna esta mensagem irritante, mas não é mais um bug crítico.

Espero que outras pessoas possam confirmar o acima em suas frotas de produção.

@gtirloni - você pode esclarecer se sua máquina 4.8.8 / 1.12.3 travou ou se você acabou de ver a mensagem?

Agradeço, antecipadamente, a todos que têm trabalhado na reprodução / fornecimento de informações úteis para triangular isso.

excluímos a contraparte da interface veth (docker0) após iniciar o docker e reiniciá-lo depois, quando provisionamos o host usando ansible. O problema não ocorreu desde então.

Também estou recebendo o mesmo erro em um Raspberry Pi 2 executando Raspbian com Docker.

Informação do kernel
Linux rpi2 4.4.32-v7+ #924 SMP Tue Nov 15 18:11:28 GMT 2016 armv7l GNU/Linux

Informações do 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

Aconteceu depois de criar um contêiner que precisava de cerca de ~ 50 MB de programas baixados instalados.

Apenas uma reinicialização me permitiria usar a máquina novamente

Na verdade, estou vendo isso no Amazon Linux em um cluster ECS - a mensagem ocasionalmente é lançada, mas não trava, como reshen está vendo agora. Docker 1.11.2. Uname relata "4.4.14-24.50.amzn1.x86_64" como a versão.

@reshen , vou construir 4.8.8 neste fim de semana no meu laptop e ver se isso
conserta para mim!
ᐧ

Na quinta-feira, 1º de dezembro de 2016 às 10:29, Ernest Mueller [email protected]
escreveu:

Na verdade, estou vendo isso no Amazon Linux em um cluster ECS - a mensagem
ocasionalmente joga, mas não trava, como Reshen está vendo agora.
Docker 1.11.2. Uname relata "4.4.14-24.50.amzn1.x86_64" como a versão.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/docker/issues/5618#issuecomment-264220432 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AKklVRqoBUZDu3HMhGv3b6knnA6j6C_Qks5rDvXRgaJpZM4B4L4Z
.

-
Keifer Furzland
http://kfrz.work

Também consegui reproduzir esse problema usando https://github.com/crosbymichael/docker-stress em um nó de trabalho do Kubernetes executando o CoreOS Stable 1185.3.0.

Executar docker_stress_linux_amd64 -k 3s -c 5 --containers 1000 : 5 workers simultâneos criando / excluindo contêineres, vida útil máxima de contêineres = 3s, criar até 1000 contêineres em uma instância m4.large na AWS deixaria o daemon Docker sem resposta após cerca de três minutos.

Fiz upgrade para CoreOS Beta 1235.1.0 e não consegui reproduzir (tanto a falta de resposta quanto a mensagem unregister_netdevice nos logs do kernel). Enquanto a execução de 5 workers docker_stress simultâneos eliminaria o CoreOS Stable após alguns minutos, consegui executar com 10 e 15 workers simultâneos até a conclusão do teste usando o CoreOS Beta.

O CoreOS é lançado em "canais", portanto não é possível atualizar o kernel isoladamente. Aqui estão as principais diferenças entre estável e beta:

CoreOS Stable 1185.3.0

kernel: 4.7.3

docker: 1.11.2

CoreOS Beta 1235.1.0

kernel: 4.8.6

docker: 1.12.3

Encontrando este problema no Amazon Elastic Beanstalk executando 4.4.23-31.54.amzn1.x86_64

Just Happen no CoreOS Stable 1185.5.0, Docker 1.12.2
Depois de reiniciar está tudo bem

Atualização: o problema do daemon do Docker travado ocorreu novamente em um host executando CoreOS Beta 1235.1.0 com Docker v1.12.3 e kernel Linux v4.8.6. 😢

1.12.4 e 1.13 deveriam, em teoria, não congelar quando este problema de kernel é atingido.
O motivo do congelamento no daemon do docker é porque o daemon está esperando por uma mensagem netlink de volta do kernel (que nunca virá) enquanto mantém o bloqueio no objeto contêiner.

1.12.4 e 1.13 definem um tempo limite nesta solicitação de netlink para pelo menos liberar o bloqueio do contêiner.
Isso __não__ corrige o problema, mas pelo menos (com sorte) não congela todo o daemon.
Você provavelmente não será capaz de girar novos contêineres e, da mesma forma, provavelmente não será capaz de derrubá-los, já que parece que todas as interações com o netlink param depois que esse problema é atingido.

@ cpuguy83 FWIW, todos os contêineres em execução continuam a funcionar sem problemas de AFAIK quando o daemon é interrompido. Na verdade, é o início e a parada de contêineres que é perceptível (especialmente em execução no Kubernetes, como nós).

Isso não corrige o problema, mas pelo menos (com sorte) não congela todo o daemon.

A única vantagem de todo o daemon estar congelado é que é fácil de descobrir. O Kubernetes pode remover o nó, talvez até mesmo reiniciá-lo automaticamente. Se o daemon continuar em execução, ainda será possível descobrir facilmente que o problema do kernel apareceu?

@seanknox Eu poderia fornecer a você um CoreOS 1248.1.0 AMI personalizado com Docker corrigido (CoreOS Docker 1.12.3 + Upstream 1.12.4-rc1 Patches). Ele corrigiu os bloqueios a cada duas horas em meus clusters CoreOS / K8s. Basta enviar um ping para mim com seu ID de conta da AWS no Deis Slack.

Temos uma grande dor com esse problema em nosso cluster CoreOS. Alguém poderia dizer quando será finalmente consertado? Sonhamos com este momento em que podemos dormir à noite.

@DenisIzmaylov Se você não definir --userland-proxy=false , geralmente não deve se deparar com esse problema.

Mas caso contrário, este é um bug no kernel, possivelmente vários bugs do kernel, que alguns dizem que foram resolvidos no 4.8 e outros dizem que não. Para alguns, desativar o ipv6 parece consertá-lo, outros não (portanto, provavelmente são vários problemas ... ou pelo menos várias causas).

Já vi esse problema em questão de horas em sistemas de alta carga com e sem --userland-proxy=false

Confirmado que ainda estamos vendo unregister_netdevice erros no kernel 4.8.12 . Demora cerca de 5 dias para ser acionado. Apenas uma reinicialização do sistema parece se recuperar do problema. Parar o Docker parece travar indefinidamente.

Ainda não tentei o truque de desabilitar ipv6 para inicialização do 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

Seria incrível se alguém pudesse tentar isso com 1.12.5, que deve atingir o tempo limite na solicitação de netlink travada agora, em vez de apenas travar o Docker.

@ cpuguy83 no entanto, o sistema ainda está inutilizável nesse estado :)

@ LK4D4 Oh, com

Obtendo este problema no Cent OS 7:

kernel: unregister_netdevice : esperando que lo se torne livre. Contagem de uso = 1

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

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

Isso está afetando meus builds de CI que estão sendo executados dentro de contêineres do Docker e parecem estar morrendo repentinamente durante o qual esta mensagem de console aparece. Existe uma correção ou solução alternativa? obrigado!

@ cpuguy83 O Docker não trava para mim quando esse erro ocorre, mas os contêineres são interrompidos, o que, em minha situação, está interrompendo meus jobs do Jenkins / CI.

Estou executando o docker em uma máquina centos 7 por um tempo (11 meses?) Sem problemas. Hoje eu decidi dar uma chance ao daemon de escuta tcp ( adicionei o endereço de escuta tcp a / etc / sysconfig / docker ) e acabei de receber este erro.

kernel: unregister_netdevice : esperando que lo se torne livre. Contagem de uso = 1

portanto, minha contagem de uso não é 3.

Recipientes: 4
Em execução: 3
Pausado: 0
Parado: 1
Imagens: 67
Versão do servidor: 1.10.3
Driver de armazenamento: btrfs
Versão de compilação: Btrfs v4.4.1
Versão da biblioteca: 101
Driver de execução: nativo-0.2
Driver de registro: arquivo json
Plugins:
Volume: local
Rede: host nulo de ponte
Versão do kernel: 3.10.0-514.2.2.el7.x86_64
Sistema operacional: CentOS Linux 7 (Core)
OSType: linux
Arquitetura: x86_64
Número de ganchos Docker: 2
CPUs: 24
Memória Total: 39,12 GiB
Nome: aimes-web-encoder
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 Ter 6 Dez 23:06:41 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux

Cliente:
Versão: 1.10.3
Versão API: 1.22
Versão do pacote: docker-common-1.10.3-59.el7.centos.x86_64
Versão Go: go1.6.3
Git commit: 3999ccb-sem suporte
Construído: Qui, 15 de dezembro, 17:24:43 2016
OS / Arch: linux / amd64

Servidor:
Versão: 1.10.3
Versão API: 1.22
Versão do pacote: docker-common-1.10.3-59.el7.centos.x86_64
Versão Go: go1.6.3
Git commit: 3999ccb-sem suporte
Construído: Qui, 15 de dezembro, 17:24:43 2016
OS / Arch: linux / amd64

Posso confirmar @aamerik. Estou vendo o mesmo problema na mesma versão do kernel. Nenhuma grande mudança recente no sistema, visto este problema desde hoje.

Eu vi a mesma mensagem kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1 em minha máquina CentOS 7 executando uma imagem docker do Jenkins. A máquina CentOS 7 que eu estava usando estava atualizada com todos os patches CentOS 7 mais recentes em aproximadamente 20 de dezembro de 2016.

Como as referências mais recentes aqui parecem ser baseadas em CentOS, vou mudar meu host de execução para uma máquina Ubuntu ou Debian.

Estou executando Docker version 1.12.5, build 7392c3b naquela máquina CentOS 7. O Docker não travou, mas o processo Jenkins que eu estava executando no Docker foi encerrado quando a mensagem apareceu.

Muito obrigado pelo Docker! Eu o uso o tempo todo e sou profundamente grato por seu trabalho nisso!

Estou tendo o mesmo problema ao usar Jenkins com Docker em uma máquina Linux 4.8.15.

Alguém chegou a um procedimento para consertar os rancheiros?

AFAICT, este é um problema de bloqueio no subsistema de namespaces de rede do kernel do Linux. Este bug foi relatado há mais de um ano, sem resposta: https://bugzilla.kernel.org/show_bug.cgi?id=97811 Houve algum trabalho sobre isso (veja aqui: http: //www.spinics. net / lists / netdev / msg351337.html), mas parece que não é uma correção completa.

Tentei pingar o mantenedor do subsistema de rede diretamente, sem resposta. FWIW, posso reproduzir o problema em questão de minutos.

A Smyte pagará $ 5000 USD pela resolução deste problema. Parece que preciso falar com alguém que trabalha no kernel?

@petehunt Acredito que vários problemas estejam causando esse erro.

Implementamos o kernel 4.8.8 como @reshen sugeriu e, embora o tempo de atividade pareça um pouco melhor, continuamos a ver esse problema na produção.

Tentando implantar o Mesosphere a partir de um nó de bootstrap. Todos os nós são CentOS 7.2 mínimos com todas as atualizações aplicadas. O nó de bootstrap está mostrando o erro conforme observado acima por outros:

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

Posso confirmar que uma reinicialização silencia as mensagens, mas no minuto em que implanto a mesosfera novamente, as mensagens começam de vez em quando. A Mesosfera é uma implantação bastante grande. Talvez aqueles que estão tentando recriar o erro possam usar o instalador para reproduzir o erro. Demora alguns minutos antes que o erro apareça após usar a primeira opção de script (--genconf que é o primeiro passo).

Nós também atingimos isso. No entanto, as mensagens de erro em nosso caso mencionam o dispositivo eth0 not lo . Meu erro é este:

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

Estou assumindo que erros como mencionar eth0 vez de lo têm a mesma causa raiz que este problema. Caso contrário, devemos abrir um novo tíquete sobre os erros de eth0.

• SO: CentOS Linux versão 7.3.1611
• Kernel: 3.10.0-514.2.2.el7.x86_64
• Docker versão 1.12.6, compilação 78d1802
• O Docker começou com as opções: 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 isso desde https://bugzilla.kernel.org/show_bug.cgi?id=97811 e outros bugs mencionam IPsec)

Nós também atingimos isso.
Erro: unregister_netdevice: esperando que lo seja liberado.
SO: CentOS Linux versão 7.3.1611 (Core)
Kernel 3.10.0-514.2.2.el7.x86_64
Versão do Docker: 1.13.0-cs1-rc1
Opções do Docker:
{
"disable-legacy-registry": verdadeiro,
"icc": verdadeiro,
"inseguros-registros": [],
"ipv6": falso,
"iptables": verdadeiro,
"driver de armazenamento": "devicemapper",
"opções de armazenamento": [
"dm.thinpooldev = / dev / mapper / docker_vg-thinpool",
"dm.use_deferred_removal = true",
"dm.use_deferred_deletion = true"
],
"userland-proxy": falso
}

Eu tenho isso em dois sistemas CentOS, atualizações mais recentes em pelo menos um deles.

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

Ei, para todos afetados por este problema no RHEL ou CentOS, eu fiz backport do commit dos kernels da linha principal (torvalds / linux @ 751eb6b6042a596b0080967c1a529a9fe98dac1d) que corrige a condição de corrida no IPV6 IFP refcount para os kernels 3.10.x usados ​​em distribuições corporativas. Isso deve resolver o problema.

Você pode encontrar o relatório de bug com patch funcional aqui :
Se você estiver interessado em testá-lo e tiver um sistema RHEL 7 ou CentOS 7, já compilei o kernel CentOS 7.3 3.10.0-514.6.1.el7.x86_64 mais recente com o patch. Responda ao tópico bugtracker do CentOS e posso enviar um link para a compilação.

Nota: pode haver outro problema causando um vazamento de refcount, mas isso deve corrigir a mensagem de erro para muitos de vocês.

@stefanlasiewski @henryiii @jsoler

Vou tentar uma construção adicionando também esta correção: http://www.spinics.net/lists/netdev/msg351337.html mais tarde esta noite.

@iamthebot significa que se alguém desabilitar o IPv6, o problema também deve ser corrigido, mesmo sem um patch que você acabou de fazer o backport?

@redbaron apenas se for esse o problema que você está enfrentando. Eu realmente acho que há vários problemas de kernel sendo atingidos aqui.

@redbaron talvez. # 20569 parece indicar que desativar totalmente o IPV6 é difícil.

Então, para esclarecer um pouco o que está acontecendo nos bastidores que está gerando essa mensagem, o kernel mantém uma contagem em execução de se um dispositivo está em uso antes de removê-lo de um namespace, cancelar o registro, desativá-lo etc. referência a um dispositivo, então você verá aquela mensagem de erro, uma vez que não pode ser cancelado quando outra coisa está usando.

As correções que vi até agora:

1. Corrija um problema em que um problema com uma alocação de endereço IPV6 falha (por exemplo, um endereço duplicado), mas não liberamos a referência ao dispositivo antes de sair.
2. Corrigir um problema em que mover o namespace de um dispositivo moverá corretamente as referências ao dispositivo para o novo namespace de rede, mas deixará uma referência pendente no namespace antigo. O Docker faz uso intensivo de namespaces de rede (conforme evidenciado por outra correção de kernel que eu tinha o backport do Red Hat para 7.3 Z-Stream e está programado para inclusão no 7.4 que impede que o driver macvlan do docker funcione em dispositivos de ligação ou de equipe)

Acho que ainda há outra condição de corrida ao alternar os namespaces (isso parece acontecer depois de criar um monte de novos contêineres), mas vou precisar replicar o problema de forma confiável a fim de localizá-lo e escrever um patch.

Alguém tem um procedimento mínimo para reproduzir isso de forma consistente? Pareceu acontecer aleatoriamente em nossos sistemas.

@iamthebot não é muito simples, mas acho que podemos fornecer a você um ambiente de teste que pode reproduzir isso de forma confiável. Envie-me um email ([email protected]) e podemos providenciar os detalhes.

Ainda experimente isso sob carga pesada no Docker versão 1.12.6, compilar 7392c3b / 1.12.6 no 4.4.39-34.54.amzn1.x86_64 AWS Linux AMI.

Eu tenho 9 hosts docker, todos quase idênticos, e só experimento isso em alguns deles. Pode ser coincidência, mas uma coisa em comum que percebi é que só pareço ter esse problema ao executar contêineres que não manipulam SIGINT . Quando eu docker stop esses contêineres, ele trava por 10s e depois mata o contêiner de forma desagradável.

Demora vários dias até que o problema se manifeste, e parece aparecer aleatoriamente, não apenas imediatamente após a execução de docker stop . Isso é principalmente anedótico, mas talvez ajude alguém.

Eu atualizei todos os meus nós do docker para kernel 3.10.0-514.6.1.el7.x86_64 no CentOS 7.3 como @iamthebot mencionou, mas ainda recebo os mesmos erros:
26 de janeiro 13:52:49 Kernel XXX: unregister_netdevice: esperando que lo se torne livre. Contagem de uso = 1
Mensagem de syslogd @ XXX em 26 de janeiro 13:52:49 ...
kernel: unregister_netdevice : esperando que lo se torne livre. Contagem de uso = 1

@jsoler só para ficar claro, você aplicou o patch no thread do bug tracker antes de compilar o kernel? Ou você está usando um kernel padrão? Também tente aplicar este (o patch deve funcionar em kernels mais antigos).

Envie-me um e-mail ([email protected]) e posso enviar-lhe um link para um kernel pré-compilado. @vitherman , infelizmente não tenho muito tempo para analisar isso (parece que alguma instrumentação precisará ser compilada para detectar esse bug), mas escalei o problema com o suporte da Red Hat, então sua equipe do kernel irá analisar olhar.

@ckeeney posso confirmar este comportamento. Temos um aplicativo Node dockerized que causou o referido erro no sistema host quando foi desligado. Depois de implementar uma função dentro do aplicativo Node.js, que captura SIGINT e SIGTERM para desligar normalmente o aplicativo, o erro não ocorreu novamente.
O que meio que faz sentido; o aplicativo Node usa a interface virtual que o Docker cria. Quando o Node não é desligado corretamente, o dispositivo trava e o sistema host não consegue cancelar o registro, embora o contêiner do Docker tenha sido interrompido com sucesso.

aqui está um exemplo de snippet de código:

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 há um sinal diferente que é gerenciado corretamente pelo Node por padrão para um desligamento limpo? (você pode especificar STOPSIGNAL na imagem, ou em docker run por meio da bandeira --stop-signal .

@thaJeztah para uma boa explicação do problema e solução alternativa, consulte nodejs / node-v0.x-archive # 9131 # issuecomment-72900581

@ckeeney Estou ciente disso (ou seja, processos rodando como PID1 podem não lidar com SIGINT ou SIGTERM ). Por esse motivo, gostaria de saber se a especificação de um sinal de parada diferente faria um desligamento limpo, mesmo se executando como PID1 .

Como alternativa, o docker 1.13 adiciona uma opção --init (solicitação pull: https://github.com/docker/docker/pull/26061), que insere um init no contêiner; nesse caso, o Node não está sendo executado como PID1 , o que pode ajudar nos casos em que você não pode atualizar o aplicativo.

@iamthebot Eu construí a versão 3.10.0-514.el7 do kernel com seu patch integrado, mas recebo o mesmo erro. Bem, não tenho certeza se construí bem o pacote do kernel do centos. Você poderia me compartilhar seu pacote de kernel para testá-lo?

Obrigado

Eu tenho / tenho lidado com esse bug há quase um ano. Eu uso o CoreOS com inicialização PXE, desativei o ipv6 na configuração do pxeboot e não vi esse problema nenhuma vez desde então.

Bem, meu ambiente desabilitou ipv6 com esta configuração sysctl
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
mas ainda recebo o erro
kernel: unregister_netdevice : esperando que lo se torne livre. Contagem de uso = 1

@jsoler certo, eu estava fazendo isso também, ainda aconteceu. Apenas uma vez que eu fiz isso no nível pxe, ele parou.

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

Apenas uma observação - parece haver diferentes problemas em jogo (isso foi dito antes).

• Algumas pessoas notam "esperando por ..."
• alguns notaram "esperando por eth0"
• alguns notaram "esperando por veth ?????"
• No rastreamento de bugs do RedHat , fala-se sobre "esperar pelo ppp0"

Alguns notaram logs alternando entre qualquer um dos acima e outros tendo apenas um dos acima.

Também existe um bug semelhante registrado no Ubuntu . Neste, eles parecem achar que o NFS é o problema.

@etlweather Eu acredito que na verdade o único denominador comum é, bem, um dispositivo de rede não pode ser cancelado pelo kernel como diz a mensagem de erro. No entanto, as razões _why_ são um pouco diferentes. Para nós, definitivamente foi o problema do docker / nó mencionado (veth). Para eth, lo a causa é provavelmente algo completamente diferente.

Ainda acontece com 4.9.0-0.bpo.1-amd64 no debian jessie com docker 1.13.1. Existe alguma combinação kernel-os que seja estável?

Isso pode não ser um problema puramente docker - estou obtendo em um servidor Proxmox onde estou executando apenas contêineres vanilla LXC (ubuntu 16.04).

@darth-veitcher é um problema de kernel

@thaJeztah concordou, obrigado. Ia tentar instalar o 4.9.9 hoje à noite a partir da linha principal e ver se isso faz a diferença.

Estou executando o Docker 1.13.1 em um Debian com kernel 4.9.9-040909.

Sim, atualizar o kernel no Proxmox para a última 4.9.9 não resolveu o erro. Por mais estranho que pareça, depois de um ano sem problemas.

Pode haver algo em uma declaração anterior mais adiante no encadeamento sobre ele estar vinculado a compartilhamentos NFS ou CIFS montados.

Enviado do meu iPhone

Em 14 de fevereiro de 2017, às 07:47, Alfonso da Silva [email protected] escreveu:

Estou executando o Docker 1.13.1 em um Debian com kernel 4.9.9-040909.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.

Eu tenho um tíquete do Bugzilla aberto com o Redhat sobre isso.

Alguns desenvolvimentos:
A Red Hat colocou os patches de vazamento de IPV6 refcount da linha principal no controle de qualidade, parece que eles estão na fila para o RHEL 7.4 e podem ter backported para 7.3. Deve estar no CentOS-plus em breve. Observação: este patch corrige problemas apenas em ALGUNS casos. Se você tem um kernel 4.x, é um ponto discutível, pois eles já estão lá.

Esta é definitivamente uma condição de corrida no kernel, pelo que posso dizer, o que a torna realmente irritante de se encontrar. Eu tirei um instantâneo do kernel da linha principal atual e estou trabalhando na instrumentação das várias chamadas começando com o subsistema IPV6. O problema é definitivamente reproduzível agora: parece que tudo que você precisa fazer é criar um monte de contêineres, enviar uma tonelada de tráfego de rede deles, travar o programa dentro dos contêineres e removê-los. Fazer isso repetidamente dispara o problema em minutos, no máximo em uma estação de trabalho física de 4 núcleos.

Infelizmente, não tenho muito tempo para trabalhar nisso: se houver desenvolvedores de kernel aqui dispostos a colaborar na instrumentação das peças necessárias, acho que podemos configurar um fork e começar a procurar isso passo a passo .

@iamthebot , é reproduzível em uma configuração qemu-kvm?

@iamthebot , tentei reproduzir isso várias vezes com diferentes kernels. Em algum lugar acima, foi mencionado que usar docker-stress -c 100 com userland-proxy definido como falso o acionaria, mas não tive sorte.

Se você tiver uma reprodução mais confiável (mesmo que leve muito tempo para ser acionada), posso tentar dar uma olhada

Encontramos a mesma dificuldade em nossos ambientes de produção e preparação. Faremos upgrade para Docker 1.13 e kernel do Linux 4.9 em breve, mas como outros já mencionados; essas versões também são afetadas.

$ 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

Estou tendo esse problema com bastante frequência no meu sistema de desenvolvimento, sempre ao encerrar os contêineres.

Informações gerais

→ 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 daemon do 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 se você tentar parar um contêiner, mas ele não responder ao SIGINT, o docker irá aguardar 10 segundos e então encerrar o contêiner de forma desagradável. Eu encontrei esse comportamento em meus contêineres nodejs até adicionar o tratamento de sinais. Se você vir um contêiner levando 10 segundos para parar, provavelmente ele não está processando os sinais e é mais provável que acione esse problema.

Certifique-se de que seus contêineres podem parar normalmente.

Embora não seja eu quem está corrigindo esse problema, não sendo muito dedicado ao Linux Kernel dev, acho que estou certo ao dizer que os comentários "eu também" não são tão úteis. Com isso, quero dizer, apenas dizer "Eu também tenho esse problema, com Kernel vx.x e Docker 1.x" não traz nada de novo para a discussão.

No entanto, gostaria de sugerir que comentários "eu também" que descrevam mais o ambiente e o método de reprodução seriam de grande valor.

Ao ler todos os comentários, fica claro que existem alguns problemas - como eu postei antes, alguns com vethXYZ, alguns com eth0 e outros com lo0. Isso sugere que eles podem ser causados ​​por diferentes problemas. Portanto, apenas dizer "eu também" sem uma descrição completa do erro e do ambiente pode enganar as pessoas.

Além disso, ao descrever o ambiente, fornecer a versão do Kernel e do Docker não é suficiente. De acordo com o tópico, parece haver alguns fatores, como ipv6 habilitado ou não. O NodeJS não está respondendo ao SIGINT (ou outros contêineres, não atacando o NodeJS aqui).

Portanto, descrever qual é a carga de trabalho no ambiente seria útil. Além disso, isso ocorre quando um contêiner está sendo encerrado, portanto, eu também sugeriria às pessoas que enfrentam esse problema que prestem atenção em qual contêiner está sendo interrompido quando o problema aparece.

Embora pareça que o problema esteja no kernel com uma condição de corrida, identificar o gatilho será de grande ajuda para aqueles que resolverem o problema. E pode até mesmo dar aos usuários afetados uma solução imediata, como implementar um manipulador de sinais em um aplicativo NodeJS (não sei se isso impede que o problema seja acionado, mas parece que sim por comentários anteriores de outras pessoas).

Kubernetes FWIW correlacionou isso completamente ao veth "modo hairpin" e
parou de usar esse recurso completamente. Nós não experimentamos isso
problema em tudo, em dezenas de milhares de máquinas de produção e vastamente
mais execuções de teste, desde a mudança.

Até que isso seja consertado, abandone o navio. Encontre uma solução diferente :(

Na quarta-feira, 15 de fevereiro de 2017 às 10:00, ETL [email protected] escreveu:

Embora não seja eu quem está corrigindo esse problema, não gosto muito de Linux
Dev Kernel, acho que estou certo em dizer que os comentários "eu também" não são
tão útil. Quero dizer, apenas dizendo "Eu também tenho esse problema, com
Kernel vx.x e Docker 1.x "não trazem nada de novo para a discussão.

No entanto, gostaria de sugerir que os comentários "eu também", que descrevem mais o
ambiente e método para reproduzir seriam de grande valor.

Ao ler todos os comentários, é claro que existem alguns problemas -
como postei anteriormente, alguns com vethXYZ, alguns com eth0 e outros com lo0.
Isso sugere que eles podem ser causados ​​por diferentes problemas. Então apenas
dizer "eu também" sem uma descrição completa do erro e do ambiente pode
enganar as pessoas.

Além disso, ao descrever o ambiente, dando o Kernel e o Docker
versão não é suficiente. De acordo com o tópico, parece haver alguns fatores
como ipv6 habilitado ou não. O NodeJS não está respondendo ao SIGINT (ou outro
contêineres, não atacando o NodeJS aqui).

Portanto, descrever qual é a carga de trabalho no ambiente seria útil.
Além disso, isso ocorre quando um contêiner está sendo encerrado, portanto, eu
também sugira às pessoas que estão enfrentando esse problema que prestem atenção em quais
contêiner está sendo interrompido quando o problema levanta sua cabeça feia.

Embora pareça que o problema está no kernel tendo uma condição de corrida -
identificar o gatilho será de grande ajuda para aqueles que irão consertar
o problema. E pode até dar aos usuários afetados uma solução imediata
como a implementação de um manipulador de sinal em um aplicativo NodeJS (não sei
eu mesmo que isso evita que o problema seja acionado, mas parece que sim
comentários anteriores de outros).

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/docker/issues/5618#issuecomment-280087293 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AFVgVFmu1SiStZcLKtKuk1W-tjn6wOXlks5rcz0hgaJpZM4B4L4Z
.

Sim, estamos mudando para o gke e não vemos mais esse problema (então não há mais recompensas por bugs da nossa parte :))

Acabei de ter o erro novamente. Eu estava tentando consertar um aplicativo node.js que usa soquetes e, portanto, dimensionava o aplicativo com frequência. O aplicativo node.js foi criado com base em https://github.com/deployd/deployd. Espero que isso forneça mais algumas informações. O que também foi interessante é que ambos os servidores dentro do meu swarm exibiram o erro unregister_netdevice simultaneamente depois que eu removi o serviço via docker service rm. O contêiner foi dimensionado para 4, de modo que dois contêineres estavam em execução em cada máquina.

editar Aconteceu de novo! Trabalhando no mesmo aplicativo node.js. Nos últimos 3 ou 4 dias, não trabalhei diretamente naquele aplicativo node.js e isso nunca ocorreu.

edit2 tentará adicionar o manipulador de sinal ao aplicativo nodejs. Vamos ver se isso ajuda ...

Acabei de encontrar este erro, depois de usar docker-py para publicar uma nova instância no EC. No entanto, consegui sair com ctrl + C e não o vi desde então (agora que a maioria das imagens estão construindo mais rapidamente a partir do cache)

`` `{" status ":" Pushed "," progressDetail ": {}," id ":" c0962ea0b9bc "}
{"status": "estágio: digest: sha256: f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8 tamanho: 5737"}
{"progressDetail": {}, "aux": {"Tag": "stage", "Digest": "sha256: f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8", "Size": 5737}}

Imagem Docker publicada com sucesso

Mensagem de syslogd @ ip-172-31-31-68 em 16 de fevereiro 19:49:16 ...
kernel: [1611081.976079] unregister_netdevice: esperando que lo se torne livre. Contagem de uso = 1

Mensagem de syslogd @ ip-172-31-31-68 em 16 de fevereiro 19:49:27 ...
kernel: [1611092.220067] unregister_netdevice: esperando que lo se torne livre. Contagem de uso = 1

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

@thockin é esta configuração --hairpin-mode=none nos kubelets?

= nenhum quebra os contêineres que recebem o NAT de volta para si mesmos. Nós usamos
ponte promíscua por padrão.

Na quinta-feira, 16 de fevereiro de 2017 às 19h26, Kanat Bekt [email protected]
escreveu:

@thockin https://github.com/thockin é esta configuração --hairpin-mode = none
nos kubelets?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/docker/issues/5618#issuecomment-280539673 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AFVgVLNwAH6NWVaIKhJfS147O9w_rtJEks5rdRN8gaJpZM4B4L4Z
.

@thockin quais contêineres podem querer acessar a si mesmos por meio do Service ClusterIP?

Acabou sendo mais comum do que eu pensava e, quando o quebramos, muitos
de pessoas reclamaram.

Em 17 de fevereiro de 2017, às 12h38, "Maxim Ivanov" [email protected] escreveu:

@thockin https://github.com/thockin quais contêineres podem querer
acessar a si próprios por meio do Service ClusterIP?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/docker/issues/5618#issuecomment-280588366 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AFVgVLn3uBvUW-dQ72qst5_eYiFUtfSVks5rdVyIgaJpZM4B4L4Z
.

Acho que sei por que algum aplicativo nodejs dockerized pode causar esse problema. O Node usa conexões keep-alive por padrão. Quando server.close() é usado, o servidor não aceita novas conexões. Mas as conexões ativas atuais, como websockets ou conexões HTTP keep-alive, ainda são mantidas. Quando o aplicativo encaixado também é dimensionado para n, isso pode resultar em waiting for lo to become free porque quando ele é forçado a encerrar, o mais novo foi liberado. Quando o docker redistribui este aplicativo para outro nó ou o aplicativo é reduzido, o docker envia um sinal para o aplicativo que deve ser encerrado. O aplicativo ouve esse sinal e pode reagir. Quando o aplicativo não é encerrado após alguns segundos, o docker o encerra sem hesitação. Eu adicionei manipuladores de sinal e descobri que ao usar server.close() o servidor não é encerrado perfeitamente, mas "apenas" para de aceitar novas conexões (consulte https://github.com/nodejs/node/issues/2642). Portanto, precisamos ter certeza de que conexões abertas como websockets ou http keep-alive também estão fechadas.

Como lidar com websockets:
O aplicativo nodejs emite para todos os websockets closeSockets quando um sinal de desligamento é recebido. O cliente escuta neste evento closeSockets e chama sockets.disconnect() e logo depois de sockets.connect() . Lembre-se de que server.close() foi chamado, portanto, esta instância não aceita novas solicitações. Quando outras instâncias deste aplicativo dockerized estão em execução, o balanceador de carga dentro do docker irá eventualmente escolher uma instância que não é desligada e uma conexão bem-sucedida é estabelecida. A instância que deve desligar não terá conexões de websockets abertas.

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();
});
...

Como lidar com conexões HTTP keep-alive:
Atualmente não sei como isso pode ser feito perfeitamente. A maneira mais fácil é desativar o keep-alive.

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

Outra possibilidade é definir o tempo limite de keep-alive para um número muito baixo. Por exemplo, 0,5 segundos.

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

Espero que isso possa ajudar outras pessoas :)

Eu tenho os mesmos problemas. Os anexos são todos os registros feitos a partir do script ecs-logs-collector.
Muito apreciado por qualquer ajuda :)

collect.zip

Eu tenho os mesmos problemas.
Docker versão 1.13.1, compilação 092cba3
Linux debian 4.8.6-x86_64-linode78

Backup do Linux 4.6.0-040600-genérico # 201606100558 SMP Sex. Jun 10 10:01:15 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux
Versão do servidor: 1.13.1

O mesmo problema. Estou usando a montagem em um contêiner privilegiado. Após 4-5 execuções, ele congela. Também tenho o mesmo problema com o kernel padrão mais recente para 16.04

Pessoal, @etlweather está

@rneugeba @redbaron Infelizmente, o "repro" atual que tenho é muito específico para o hardware (quase prova que é uma condição de corrida). Eu não tentei obter uma reprodução do QEMU, mas essa é definitivamente a próxima etapa, então várias pessoas podem realmente trabalhar nisso e obter o resultado esperado (de preferência em uma configuração de núcleo de CPU). Se alguém já tiver um, envie-me um e-mail (está no meu perfil). Vou testá-lo completamente e postá-lo aqui.

Estamos recebendo isso no GCE com bastante frequência. O Docker congela e a máquina trava na reinicialização.

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

O contêiner está executando um aplicativo go e tem o hairpin nat configurado.

Docker:

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

Alguém tem uma sugestão de solução para isso? Tentei ativar --userland-proxy=true e o docker ainda trava depois de um tempo. Parece que o Kubernates tem uma solução do que @thockin escreveu acima, mas não está claro o que --hairpin-mode=promiscuous-bridge exatamente faz e como configurar isso em uma instalação simples do docker do jane ubuntu 16.x

Posso fazer isso acontecer de maneira confiável ao executar o Proxmox e usar contêineres. Especificamente, se eu movi uma quantidade considerável de dados ou movi realmente qualquer quantidade de dados muito recentemente, desligar ou parar o contêiner produzirá esse erro. Já vi isso com mais frequência quando estou usando contêineres que montam meu NAS, mas pode ser uma coincidência.

# 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

E de dentro do 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

É importante notar que o Docker não está instalado neste sistema e nunca foi. Tenho o prazer de fornecer todos os dados de que a comunidade precisa para solucionar esse problema, apenas me diga quais comandos executar.

Consigo reproduzir isso no centos 7.3 rodando como um nó de trabalho swarm rodando dtr com um volume nfs montado mapeado

Se você está chegando aqui

O problema discutido aqui é um bug do kernel e ainda não foi corrigido. Existem várias opções que podem ajudar em _algumas_ situações, mas não em todas (provavelmente é uma combinação de problemas que desencadeiam o mesmo erro)

Não deixe comentários do tipo "Eu também tenho isso"

"Eu também tenho isso" não ajuda a resolver o bug. apenas deixe um comentário se você tiver informações que possam ajudar a resolver o problema (nesse caso; fornecer um patch para o kernel upstream pode ser o melhor passo).

Se você quiser informar que também tem esse problema, use o botão "Gostei" na descrição superior:

Se você quiser se manter informado sobre as atualizações, use o _botão de inscrição_.

Todos os comentários aqui enviam um e-mail / notificação para mais de 3000 pessoas . Não quero bloquear a conversa sobre esse problema, pois ainda não foi resolvido, mas posso ser forçado se você ignorar.

Obrigado!

Tudo bem, mas quais _exatamente_ são as opções que ajudam? Este problema está nos causando problemas na produção, então eu gostaria de fazer qualquer solução que seja necessária para contornar o bug do kernel.

Se alguém do Docker tiver tempo para tentar a solução alternativa do Kubernetes, por favor
deixe-me saber e podemos apontar isso. Eu não consigo extrair as mudanças
e corrigi-los no Docker eu mesmo, agora.

Em quinta-feira, 9 de março de 2017 às 7h46, Matthew Newhook [email protected]
escreveu:

Tudo bem, mas quais são exatamente as opções que ajudam?
Este problema está nos causando problemas na produção, então eu gostaria de fazer o que for
soluções alternativas que são necessárias para contornar o bug do kernel.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/docker/issues/5618#issuecomment-285388243 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AFVgVGdH5VX_oFWkImyo_TvlIuhmwMepks5rkB7MgaJpZM4B4L4Z
.

@thockin obrigado. Eu estava acompanhando o problema de relações públicas / no Kubernetes com a solução alternativa do modo hairpin. Mas durante as muitas idas e vindas, eu perdi a noção se a solução alternativa resolveria esse problema?
(Pelo que entendi, existem diferentes cenários que causam a inconsistência ref-count no kernel).

Se você puder me indicar o PR que você acredita que aborda o problema no K8s, vou trabalhar para obter esse patch no docker, pelo menos, para o caso de desligar o userland-proxy por padrão. (E podemos testá-lo usando as etapas de reprodução docker-stress).

Não tenho certeza se tenho um único PR, mas você pode olhar para o estado atual. Começar
aqui:

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

No sábado, 11 de março de 2017 às 22h49, Madhu Venugopal [email protected]
escreveu:

@thockin https://github.com/thockin obrigado. Eu estava seguindo o
Problema de RP / no Kubernetes com a solução alternativa do modo hairpin. Mas durante o
muitos para trás e para frente, eu perdi a noção se a solução alternativa realmente livrar-me deste
edição ?
(Pelo que entendi, existem diferentes cenários que causam o ref-count
inconsistência no kernel).

Se você puder me indicar o PR que você acredita que aborda o problema nos K8s,
Vou trabalhar para conseguir isso corrigido no docker, pelo menos para o caso de torneamento
userland-proxy desativado por padrão. (E podemos testá-lo usando o docker-stress
etapas de reprodução).

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/docker/issues/5618#issuecomment-285926217 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AFVgVIlGs_QccxS6YYQiLNybddDzB4yUks5rk5VogaJpZM4B4L4Z
.

Ei pessoal, só para ficar claro, tudo o que a "solução alternativa do kubernetes" faz é habilitar o modo promíscuo na ponte subjacente. Você pode conseguir a mesma coisa com ip link set <bridgename> promisc on usando iproute2. Isso diminui a probabilidade de encontrar o bug, mas pode não eliminá-lo completamente.

Agora, em teoria isso não deveria funcionar ... mas por alguma razão o modo promíscuo parece fazer o desmontagem do dispositivo lento o suficiente para que você não tenha uma corrida para diminuir o contador de referência. Talvez um dos contribuidores do Kurbernetes possa intervir aqui se estiver neste tópico.

Posso verificar se a solução alternativa (NOT FIX) funciona usando meu repro específico do ambiente. Eu realmente não posso verificar se você está usando os drivers IPVLAN ou MACVLAN (usamos macvlan no prod) porque parece muito difícil fazer com que essas configurações produzam esse bug. Qualquer outra pessoa com uma reprodução pode tentar verificar a solução alternativa?

Olá a todos, Eu tentei depurar o problema do kernel, estava tendo uma cadeia de e-mail na lista de discussão "netdev", então só queria postar algumas descobertas aqui.

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

O problema que estamos vendo é que

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

durante o encerramento do contêiner. Quando eu inspecionar o namespace da rede do contêiner, parece que o dispositivo eth0 já foi excluído, mas apenas o dispositivo lo foi deixado lá. E há outra estrutura que contém a referência para esse dispositivo.

Depois de algumas pesquisas, descobriu-se que a "coisa" que contém a referência é um dos "cache de roteamento" ( struct dst_entry ). E algo está impedindo que determinado dst_entry seja gc'ed (a contagem de referência para dst_entry é maior que 0). Então eu registrei cada dst_hold() (incrementar a contagem de referência dst_entry em 1) e dst_release() (diminuir a contagem de referência dst_entry em 1), e realmente há mais dst_hold() chamadas do que dst_release() .

Aqui estão os registros em anexo: kern.log.zip

Resumo:

• a interface lo foi renomeada para lodebug para facilitar o greping
• a contagem de referência para dst_entry começa com 1
• a contagem de referência para dst_entry (que contém a referência para lo) no final é 19
• há 258041 no total de dst_hold() chamadas e 258023 no total de dst_release() chamadas
• nas 258041 dst_hold() chamadas, há 88034 udp_sk_rx_dst_set() (que é então chamadas dst_hold() ), 152536 inet_sk_rx_dst_set() e 17471 __sk_add_backlog()
• nas 258023 dst_release() chamadas, há 240551 inet_sock_destruct() e 17472 refdst_drop()

Existem mais udp_sk_rx_dst_set() e inet_sk_rx_dst_set() chamadas no total do que inet_sock_destruct() , portanto, suspeito que alguns sockets estão em um estado de "limbo" e algo os impedindo de serem destruídos.

ATUALIZAR:
Acontece que os sockets ( struct sock ) são criados e destruídos corretamente, mas para alguns dos sockets TCP inet_sk_rx_dst_set() estão sendo chamados várias vezes no mesmo dst , mas há apenas um correspondente a inet_sock_destruct() para liberar a referência ao dst .

Aqui está a solução alternativa do CentOS 7.3 que corrigiu isso para mim:

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

Aqui está o patch que resolve isso:
https://bugs.centos.org/view.php?id=12711&nbn=1

ATUALIZAÇÃO: Isso acabou não resolvendo o problema permanentemente. Ele apareceu novamente várias horas depois com a seguinte mensagem de parede:
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

@adrianotto - para esclarecer: O patch do kernel CentOS resolve isso? Só estou curioso para saber se você quis dizer que a solução alternativa e o caminho do kernel de referência não resolveram isso permanentemente?

@stayclassychicago @adrianotto Esse patch aborda apenas uma das condições de corrida que podem acionar o problema de "contagem de uso" no kernel. É apenas minha correção de backport de algo nos kernels 4.x. Pode resolver seus problemas, então vale a pena tentar.

@stayclassychicago antes de tentar o kernel 3.10.0-514.10.2.el7.centos.plus.x86_64 eu recebia o kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1 muito regularmente, quase todas as vezes que executava um contêiner com docker run --rm ... quando o contêiner saía. Após a atualização e reinicialização do kernel, ele parou completamente por muitas horas e voltou novamente. Agora, na metade das vezes que excluo os containers, ele funciona corretamente, onde costumava ocorrer erros muito tempo. Não sei ao certo se o novo kernel está ajudando, mas não faz mal.

Parece que é muito fácil reproduzir quando há uma interface de ligação LACP na máquina. Temos um cluster de enxame de 3 nós, todos os 3 com uma interface de ligação LACP configurada, e esse problema basicamente não nos permite trabalhar com o cluster. Precisamos reiniciar os nós a cada 15-20 minutos.

Confirmado - assim que retirei a ligação LACP das interfaces (aquelas usadas como interfaces principais), tudo está funcionando bem por mais de 12 horas. Costumava fazer uma pausa a cada 30 minutos.

Isso é reproduzível em 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 com Docker version 17.04.0-ce, build 4845c56 rodando em modo privilegiado quando temos montagens cifs abertas. Quando o contêiner para com as montagens abertas, o Docker não responde e obtemos o kernel:[ 1129.675495] unregister_netdevice: waiting for lo to become free. Usage count = 1 -error.

ubuntu 16.04 (kernel 4.4.0-78-genérico) ainda tem o problema. E quando isso acontecer, qualquer aplicativo que tentar criar um novo namespace de rede por meio do clone syscall ficará travado

[ 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

A única solução é reinicializar o hardware da máquina.

Encontrei esse problema ao montar o volume NFS em um contêiner privilegiado e, em seguida, reiniciar o contêiner.
Parece-me que esse problema nunca aconteceu no RHEL 7 com o mesmo procedimento.

$ 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

A Red Hat afirma ter uma instância desse bug corrigida na versão kernel-3.10.0-514.21.1.el7. Suponho que eles farão o upstream da correção o mais rápido possível e farão o rebase para 4.12. Este pacote já está disponível no CentOS 7 também.

Documentação relacionada à correção (acesso RHN necessário):
https://access.redhat.com/articles/3034221
https://bugzilla.redhat.com/show_bug.cgi?id=1436588

Do artigo:
"No caso de um endereço IPv6 duplicado ou um problema com a configuração de um endereço, ocorreu uma condição de corrida. Essa condição de corrida às vezes causava vazamento de contagem de referência de endereço. Consequentemente, as tentativas de cancelar o registro de um dispositivo de rede falharam com a seguinte mensagem de erro:" unregister_netdevice: em espera para se tornar livre. Contagem de uso = 1 ". Com esta atualização, o código-fonte subjacente foi corrigido e os dispositivos de rede agora cancelam o registro conforme esperado na situação descrita."

Já implantei essa correção em todos os sistemas do nosso pool PaaS, e já faz 2 dias sem que o bug tenha sido atingido. Anteriormente, tivemos pelo menos um sistema sendo congelado por dia. Vou relatar aqui se encontrarmos o bug novamente.

Tenho a versão do kernel 3.10.0-514.21.1.el7.x86_64 e ainda tenho o mesmo sintoma.

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, existem várias maneiras de resolver esse problema. Como você reproduziu sua instância específica desse bug?

@bcdonadio Se você olhar em https://git.centos.org/commitdiff/rpms!kernel.git/b777aca52781bc9b15328e8798726608933ceded - você verá que o bug https://bugzilla.redhat.com/show_bug.cgi?id=1436588 é "corrigido" por esta mudança:

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

Que está no kernel upstream desde 4.8, eu acredito (https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d). E 4.9 e 4.10 tem este bug presente, então RedHat apenas fez backport de algumas das correções do upstream, o que provavelmente corrigiu alguns problemas, mas definitivamente não todos eles.

@bcdonadio Posso reproduzir o bug em meu sistema executando este script de teste uma vez por hora no 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 está apenas produzindo uma lista de pacotes usando uma imagem no registro do Docker e outra usando uma construída localmente para que eu possa compará-los. O Dockerfile é apenas isto:

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

2-4 minutos depois, o syslog recebe esta mensagem:

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

Na última ocorrência aconteceu poucos minutos depois que executei o script manualmente. Meu palpite é que, depois de decorrido algum tempo limite após a tentativa de exclusão do contêiner, a condição de erro é levantada.

Tenho certeza de que a condição de erro é intermitente, porque o script acima é executado como um cron job às: 00 após cada erro. Aqui está um exemplo da saída de erro que o syslog registrou:

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

Portanto, isso acontece em algum lugar no intervalo de 2 a 4 minutos depois que os contêineres são executados e saem e são excluídos pelo docker por causa do sinalizador --rm. Observe também no log acima que não há um erro para cada contêiner executado / excluído, mas é bastante consistente.

Seria possível alguém ver se esse patch melhora as coisas?

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

@hlrichardson Isso realmente se parece com isso! Vou tentar fazer o backport para nosso kernel 3.16 ou atualizar servidores específicos e compilar o kernel 4.9 com este patch amanhã, veremos como vai.

Porém, após verificar as referências deste patch (https://github.com/torvalds/linux/commit/0c1d70af924b966cc71e9e48920b2b635441aa50) - ele foi confirmado no kernel 4.6, enquanto o problema já existia antes :(

Ah, talvez não esteja relacionado, a menos que haja várias causas (infelizmente, há muitas maneiras de esse tipo de bug ser acionado, então essa é uma possibilidade).

Nós pessoalmente encontramos pelo menos vários problemas aqui - em alguns deles,
Os logs de "unregister_netdevice" simplesmente desaparecem após algum tempo e
os contêineres docker podem funcionar bem, enquanto em outros - todos os contêineres
travar e o servidor precisar ser reinicializado.

Na verdade - não usamos vxlan em servidores que apresentam esses problemas - usamos
pontes simples e encaminhamento de porta (isso acontece independentemente do userland-proxy
definições).

Em 30 de maio de 2017 22:54, "hlrichardson" [email protected] escreveu:

Ah, talvez não esteja relacionado, a menos que haja várias causas
(infelizmente, existem muitas maneiras de este tipo de bug ser acionado, então
essa é uma possibilidade).

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/moby/moby/issues/5618#issuecomment-304989068 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAGqoDHe1n3h9_eJ2kmeWcbhKRCX6rZoks5r_HPbgaJpZM4B4L4Z
.

OK, se você não estiver usando túneis vxlan, definitivamente não ajudará.

BTW, se você vir uma única instância da mensagem "unregister_netdevice" quando um namespace de rede é excluído (saída do contêiner), deve ser considerada uma situação normal em que algo referenciando um netdevice foi limpo mais ou menos ao mesmo tempo que o namespace
estava sendo excluído.

O caso mais sério é quando esta mensagem é repetida a cada 10 segundos e nunca para ...
neste caso, um bloqueio global é mantido para sempre, e uma vez que este bloqueio deve ser adquirido sempre que a rede
namespace é adicionado ou excluído, qualquer tentativa de criar ou excluir um namespace de rede também
trava para sempre.

Se você tiver uma maneira bastante indolor de reproduzir o segundo tipo de problema, estou interessado em
Dando uma olhada.

@hlrichardson Estamos vendo o segundo caso que você mencionou acima em

Vendo isso no Fedora 25 ao testar e construir centos: 7 contêineres ao usar o yum. O Yum não conseguiu terminar o download do banco de dados de pacotes e travou indefinidamente porque a rede parou de funcionar de uma maneira estranha.

Oi, pessoal,

Há um patch potencial para o bug do kernel (ou pelo menos um dos bugs) na lista de e-mails net-dev do Linux:

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

Ele é mesclado na árvore da rede, enfileirado para a árvore estável.

De acordo com https://github.com/torvalds/linux/commit/d747a7a51b00984127a88113cdbbc26f91e9d815 - está em 4.12 (que foi lançado ontem)!

@fxposter @kevinxucs Vou tentar fazer o backport para o kernel CentOS atual amanhã.

Estou executando o 4.12 (de http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12/) e ainda acerto isso, então torvalds / linux @ d747a7a não deve ser a solução completa.

$ uname -r
4.12.0-041200-generic

Ryan, você tem uma maneira confiável de reproduzir?

Em 6 de julho de 2017, 4:29 pm, "Ryan Campbell" [email protected] escreveu:

Estou executando o 4.12 (de http://kernel.ubuntu.com/~
kernel-ppa / mainline / v4.12 /) e eu ainda acerto isso, então torvalds / linux @
d747a7a https://github.com/torvalds/linux/commit/d747a7a não deve ser
a correção completa.

$ uname -r
4.12.0-041200-genérico

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/moby/moby/issues/5618#issuecomment-313413120 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAdcPCbVPDjPw6va-N5dM7CjYn2W4Bodks5sLO9ZgaJpZM4B4L4Z
.

@justincormack Infelizmente não tenho um exemplo mínimo para compartilhar, mas temos um conjunto de testes que cria e destrói muitos contêineres e geralmente encontro esse problema (comandos do docker pendurados, muitos waiting for lo to become free no syslog) após apenas algumas iterações.

@campbellr Tenho tentado reproduzir isso agora três vezes e passei uma boa parte desta semana nisso com pouca sorte. Consegui receber as waiting for lo to become free mensagens algumas vezes, mas sem travar / travar depois. Estou tentando reduzir o caso de teste apenas criando namespace de rede e interfaces veth.

Em seu pacote de testes:

• seus contêineres têm muita atividade de rede? Em caso afirmativo, qual direção é predominante?
• Que tipo de máquina você está executando este (número de núcleos, é uma VM, etc)
• Você cria muitos contêineres simultaneamente?
• Seus contêineres saem normalmente ou travam?

Mesmo as respostas parciais ao acima podem ajudar a restringi-lo ...
obrigado

@rn Docker não

Ainda não tive a chance de testar no 4.12, mas pude reproduzir de forma confiável nas instâncias kvm em vultr. Estou executando o swarm e meus funcionários cromados sem cabeça causam problemas quando falham nas verificações de saúde ou travam regularmente. É claro que neste ponto eu rastreei todos os crashers que lidam com erros de rede de forma limpa, etc, então estou vendo waiting for lo to become free mas não com frequência suficiente para travar as coisas por algumas semanas.

Portanto, parece que as coisas que ajudam a reproduzir são cenários de rede mais complexos combinados com grandes quantidades de tráfego nos contêineres, reciclagem constante de contêineres e kvm.

@rn Consegui restringir isso a um contêiner específico em nosso conjunto de testes e reproduzi com as seguintes etapas:

1. iniciar o contêiner (um serviço da web baseado em tornado interno - estou tentando extrair um exemplo mínimo que ainda acerta isso)
2. fazer uma solicitação ao serviço da web em execução no contêiner
3. espere pela resposta
4. matar container

Após 3 ou 4 iterações disso eu acabo obtendo waiting for lo to become free e na próxima iteração docker run falha com docker: Error response from daemon: containerd: container did not start before the specified timeout.

seus contêineres têm muita atividade de rede? Em caso afirmativo, qual direção é predominante?

Uma quantia bem pequena. Nas etapas mencionadas acima, a solicitação http é uma pequena quantidade de json e a resposta é um blob binário com cerca de 10 MB.

Que tipo de máquina você está executando este (número de núcleos, é uma VM, etc)

Isso está em uma máquina de desktop de 4 núcleos (sem VM)

Você cria muitos contêineres simultaneamente?

Não, tudo é feito em série.

Seus contêineres saem normalmente ou travam?

Eles pararam com docker stop

1. iniciar o contêiner (um serviço da web baseado em tornado interno - estou tentando extrair um exemplo mínimo que ainda acerta isso)
2. fazer uma solicitação ao serviço da web em execução no contêiner
3. espere pela resposta
4. matar container

Passei algum tempo removendo o contêiner e descobri que o serviço da web não tinha nada a ver com o bug. O que parece desencadear isso no meu caso é montar um compartilhamento NFS dentro de um contêiner (rodando com --privileged ).

No meu desktop, posso reproduzir de forma confiável simplesmente executando o seguinte algumas vezes:

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

Usuários do Kubernetes, abri um problema para _kops_ para lançar a próxima AMI do Kubernetes com a versão 4.12 do Kernel. Bem-vindo para conferir: https://github.com/kubernetes/kops/issues/2901

Eu também achei isso no centos 7.3 com kernel do host 3.10.0-514.6.1.el7.x86_64 e docker-ce-17.06.0.ce-1.el7.centos.x86_64.

@FrankYu isso não ajuda. Para participar de maneira útil neste tópico, forneça uma maneira exata de reproduzir este problema e teste em um kernel moderno. 3.10 foi lançado há quatro anos, estamos discutindo se ele foi corrigido ou parcialmente em um lançamento de quatro dias atrás.

@danielgusmao nossos sistemas operacionais de linux RancherOS e AWS ECS AMI já têm essa 'correção' em vigor (provavelmente era o padrão) e isso não resolve o problema para nós. Ainda vemos a mensagem nos logs o tempo todo. Provavelmente, a única esperança é que o patch do kernel seja amplamente divulgado. Embora eu tenha pesquisado e não consiga ver nenhuma evidência de progresso sério em relação a isso ainda nos bugzillas e fóruns RedHat / Centos / AWS linux.

Para ficar claro, a mensagem em si é benigna , é o travamento do kernel após as mensagens relatadas pelo OP que não é.

O comentário no código, de onde esta mensagem está vindo, explica o que está acontecendo. Basicamente, cada usuário, como a pilha de IP) de um dispositivo de rede (como o final do par veth dentro de um contêiner) incrementa uma contagem de referência na estrutura do dispositivo de rede quando está usando o dispositivo de rede. Quando o dispositivo é removido (por exemplo, quando o contêiner é removido), cada usuário é notificado para que possa fazer alguma limpeza (por exemplo, fechar soquetes abertos, etc.) antes de diminuir a contagem de referência. Como essa limpeza pode levar algum tempo, especialmente sob carga pesada (muitas interfaces, muitas conexões, etc.), o kernel pode imprimir a mensagem aqui de vez em quando .

Se um usuário de dispositivo de rede nunca diminuir a contagem de referência, alguma outra parte do kernel determinará que a tarefa que está aguardando a limpeza está travada e irá travar. É apenas esse travamento que indica um bug do kernel (algum usuário, por meio de algum caminho de código, não diminuiu a contagem de referência). Houve vários desses bugs e eles foram corrigidos no kernel moderno (e possivelmente retransportados para os mais antigos). Eu escrevi alguns testes de estresse (e continuo a escrevê-los) para acionar tais travamentos, mas não fui capaz de reproduzir em kernels modernos (eu, no entanto, faço a mensagem acima).

Por favor, relate este problema apenas se o seu kernel realmente travar, e então estaríamos muito interessados ​​em:

• versão do kernel (saída de uname -r )
• Distribuição / versão Linux
• Você está usando a versão mais recente do kernel do seu fornecedor Linux?
• Configuração de rede (ponte, sobreposição, IPv4, IPv6, etc)
• Descrição da carga de trabalho (que tipo de contêineres, que tipo de carga de rede, etc)
• E, idealmente, uma reprodução simples

Obrigado

[ @thaJeztah você poderia mudar o título para algo como kernel crash after "unregister_netdevice: waiting for lo to become free. Usage count = 3" para torná-lo mais explícito]

Deve ser corrigido no kernel 4.12 ou posterior. Por favor, verifique. https://access.redhat.com/solutions/3105941
e link para patch https://github.com/torvalds/linux/commit/d747a7a51b00984127a88113cdbbc26f91e9d815

@drweber você também encontrará este patch nas próximas versões estáveis ​​(por agora 4.11.12, 4.9.39, 4.4.78, 3.18.62)

@rn

Se um usuário de dispositivo de rede nunca diminuir a contagem de referência, alguma outra parte do kernel determinará que a tarefa que está aguardando a limpeza está travada e irá travar. É apenas esse travamento que indica um bug do kernel (algum usuário, por meio de algum caminho de código, não diminuiu a contagem de referência). Houve vários desses bugs e eles foram corrigidos no kernel moderno (e possivelmente retransportados para os mais antigos). Eu escrevi alguns testes de estresse (e continuo a escrevê-los) para acionar tais travamentos, mas não fui capaz de reproduzir em kernels modernos (eu, no entanto, faço a mensagem acima).

Por favor, apenas relate este problema se o seu kernel realmente travar ...

Estamos tendo um problema um pouco diferente em nosso ambiente sobre o qual espero obter alguns esclarecimentos (kernel 3.16.0-77-generic, Ubuntu 14.04, docker 1.12.3-0 ~ trusty. Temos milhares de hosts executando o docker, 2 -3 contêineres por host, e estamos vendo isso em <1% do total de hosts executando o docker).

Na verdade, nunca vimos o kernel travar, mas em vez disso (como os repórteres originais, pelo que eu posso dizer) o processo dockerd está extinto. O upstart (usando o trabalho /etc/init/docker.conf do pacote upstream) não iniciará um novo processo dockerd porque pensa que já está em execução ( start: Job is already running: docker ) e tentando interromper o upstart o trabalho também falha ( 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>

Uma vez que operamos principalmente com rede de ponte (em um dispositivo de ponte personalizado) em dmesg , vemos uma mensagem um pouco diferente referente à interface 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

Como o upstart parece se recusar a reiniciar o dockerd ou reconhecer que o processo em execução anterior é um zumbi, a única solução que encontramos é reiniciar o host.

Embora nosso resultado pareça diferente (o kernel não trava), a causa raiz soa igual ou semelhante. Este não é o mesmo problema então? Existe alguma solução alternativa conhecida ou maneira de fazer com que o trabalho inicial de docker se torne executável novamente quando isso ocorrer?

@campbellr Posso reproduzir esse problema com sua abordagem no kernel 4.12.2-1.
A propósito, se eu desmontar o armazenamento NFS antes que o contêiner seja interrompido, esse problema não acontecerá.

mesmo 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

Oi,

Acabei de criar 2 repos https://github.com/piec/docker-samba-loop e https://github.com/piec/docker-nfs-loop que contêm a configuração necessária para reproduzir este bug

Meus resultados:

• Kernel 4.11.3-1-ARCH (Arch Linux): Eu gerei o bug com docker-samba-loop em algumas iterações (<10). Não consigo reproduzi-lo com docker-nfs-loop
• 4.11.9-1-ARCH mesmos resultados ( versões )
• 4.12.3-1-ARCH (testando repo) mesmos resultados
• 4.11.11-coreos: mesmos resultados para docker-samba-loop , não tentei docker-nfs-loop

Espero que isto ajude
Saúde

Uma solução alternativa é usar --net=host no meu caso. Mas nem sempre é uma solução aceitável

@piec , muito obrigado pelos detalhes. Tenho mais algumas perguntas para você no final deste longo comentário.

Usando a configuração SMB, consegui produzir várias coisas com diferentes kernels. Eu tentei isso com a configuração NFS também, mas sem dados.

Todos os testes são executados com docker 17.06.1-ce no HyperKit com uma VM configurada com 2 vCPUs e 2 GB de memória (via Docker para Mac, mas isso não deve importar). Estou usando kernels LinuxKit, porque posso trocá-los facilmente.

Eu modifiquei seu Dockerfile em que adicionei uma chamada para date como o primeiro comando executado e também adicionei uma chamada para date antes e depois de docker run para o cliente.

Experimento 1 (kernel 4.9.39)

Com 4.9.39 (kernel estável 4.9.x mais recente), recebo uma falha de 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

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

Algumas vezes eu vejo várias iterações do que o kernel 4.11.12 faz, incluindo as mensagens unregister_netdevice (veja abaixo) e, em seguida, obtenho o travamento do kernel acima. Às vezes, vejo pequenas variações para a falha, 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..

As falhas estão no código do soquete do domínio unix e semelhantes / idênticos ao que é
relatado aqui , embora com este novo caso de teste seja muito mais fácil de reproduzir.

Experimento 2 (kernel 4.11.12)

Com 4.11.12 (que é o último estável na série 4.11) não vejo travamentos, mas é muito lento (anotações em linha com ---> ):

# 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

Fiquei funcionando por uma hora ou mais com o mesmo padrão se repetindo, mas sem travamento do kernel.

Eu vejo os logs do kernel, muitos:

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

Essa é uma mensagem a cada dez segundos.

Como isso não faz com que a detecção de tarefa travada seja ativada mesmo depois de uma hora, suspeito que com 4.11.12 a contagem de referência eventualmente diminui e o dispositivo é liberado, mas, a julgar pelos intervalos em que posso executar contêineres, pode demorar até 4 minutos!

Experimento 3 (kernel 4.11.12)

O travamento do kernel no OP indicou que o kernel travou porque uma tarefa travada foi detectada. Não vi essa falha em meus testes, então alterei a configuração sysctl relacionada à detecção de tarefa travada:

# 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

Isso reduz o tempo limite para 60 segundos e coloca o kernel em pânico se uma tarefa travada for detectada. Uma vez que leva cerca de 2 minutos antes de dockerd reclamar que containerd não foi iniciado, reduzir a detecção de tarefa travada para 60s deve disparar um kernel panics se uma única tarefa for travada. Infelizmente, não houve falha nos registros

Experimento 4 (kernel 4.11.12)

Em seguida, aumento sleep após cada docker run para 5 minutos para ver se as mensagens são contínuas. Neste caso, todos os docker run s parecem funcionar, o que é meio que esperado, pois dos experimentos anteriores um docker run funcionaria a cada 4 minutos ou mais

---> 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 obtendo cerca de 200 segundos no valor de unregister_netdevice em quase todos os docker run (exceto no segundo). Suspeito que durante esse tempo não podemos iniciar novos contêineres (conforme indicado pelo Experimento 2. É curioso que a detecção de tarefa travada não esteja funcionando, provavelmente porque nenhuma tarefa foi travada.

Experimento 5 (4.11.12 / 4.9.39 com uma habilitação de depuração extra no kernel)

Isso está voltando a dormir 1s entre docker run

Nós temos outro kernel que permite um monte de depuração adicional
opções, como LOCKDEP , RCU_TRACE , LOCKUP_DETECTOR e alguns
mais.

Executar os kernels repro 4.11.12 com essas opções de depuração ativadas não acionou nada.

Idem para o kernel 4.9.39, onde o kernel normal trava. As opções de depuração mudam um pouco o tempo, então esta pode ser uma pista adicional de que a falha no código de soquete de domínio unix mostra que é devido a uma corrida.

Indo um pouco mais fundo

strace nos vários containerd processos não é útil (
geralmente não é porque está escrito em Go). Muitas barracas compridas em
futex(...FUTEX_WAIT...) com qualquer informação sobre onde / por quê.

Alguns mexendo com sysrq :

Aumentar a verbosidade:

echo 9 > /proc/sysrq-trigger

Rastreamento de pilha de todas as CPUs:

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 aqui, CPU1 está ocioso, CPU0 está lidando com o sysrq.

Mostrar tarefas bloqueadas (duas vezes)

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

Isso mostra que as filas de trabalho netns e cleanup_net estão ocupadas. Eu encontrei um problema um tanto relacionado há um bom tempo aqui , mas desta vez a fila de trabalho cleanup_net está em um estado diferente.

Resumo

• Acho que o travamento nos kernels 4.9.x não está relacionado, mas parece ter sido corrigido no 4.11.x. Isso precisa de um pouco mais de triagem.
• Ao contrário de alguns relatórios anteriores, nenhuma tarefa travada é relatada, mas é difícil dizer porque há muito poucos rastreamentos de pilha sobre esse problema.
• Algo está bloqueado por muito tempo (2-4 minutos). Provavelmente está relacionado ao estado da fila de trabalho
• O despejo da fila de trabalho precisa de mais análise, em particular por que a fila de trabalho permanece nesse estado por tanto tempo.
• As mensagens unregister_netdev parecem não ter relação com a correção recente (que está em 4.9.39 e 4.11.12). Isso pode ser porque a fila de trabalho cleanup_net não está progredindo e, portanto, a mensagem é impressa.
• Não está totalmente claro como / por que o SMB está provocando isso. Eu escrevi cerca de 60 testes de estresse ímpares para namespaces de rede e diferentes cargas de trabalho e não consegui acionar nenhum problema. Os testes foram baseados em runc , talvez eu deva tentar containerd .

Vou cavar um pouco mais e enviar um resumo para netdev .

@piec , você tem acesso ao console e pode ver se há algo em termos de despejo de

@rn obrigado pelas investigações!

Estou executando um PC desktop baremetal, então tenho acesso a tudo. É um i7-4790K + 32 GiB.
Atualmente estou executando um Arch Linux + kernel atualizado do repositório de teste (4.12.3-1-ARCH)

No meu caso, tudo se comporta como você descreve em seu Experimento 2 (kernel 4.11.12):

• Depois que o contêiner smb do cliente existe, a execução de novos contêineres é impossível por mais de 4 minutos.
• Eu nunca tive travamentos de kernel
• A mensagem unregister_netdevice: waiting for lo to become free. Usage count = 1 aparecerá repetidamente se eu tentar executar qualquer novo contêiner no intervalo de 4+ minutos após a saída do client-smb. E só aparece se você executar um novo contêiner nesse lapso de tempo de 4 minutos. Executar um novo contêiner após esses 4 minutos será "normal"

Então, suponho que haja um problema em algum lugar no processo de limpeza do contêiner smb-client relacionado às interfaces de rede

Na verdade, há uma reprodução muito mais simples desse problema (que, aliás, não é o problema original).

Este script apenas inicia um servidor SMB no host e cria um namespace de rede com um par veth , executa mount; ls; unmount no namespace de rede e remove o namespace de rede.

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

Observe que adicionar um sleep 1 simples após a desmontagem, seja ao executar no namespace ou antes de excluir o namespace da rede, funciona sem paralisar ao criar o novo namespace. Uma suspensão após o namespace antigo ser excluído não reduz a demora.

@piec Eu também testei isso com seu repro e um sleep 1 no Dockerfile após a desmontagem e tudo funciona como esperado, sem paralisação, sem unregister_netdev mensagens.

Vou escrever isso agora e enviar para netdev@vger

Excelente
Confirmo que sleep depois de desmontar correções travando e unregister_netdev mensagens em minha configuração também

Você não acha que umount gera uma ação assíncrona em relação aos seus netns que irá bloquear e, eventualmente, expirar se o netns for removido antes que a ação termine? Um sono após a montaria permitiria que essas coisas terminassem antes que as redes fossem removidas.
Mas isso é apenas uma hipótese

Tentei sem desmontar, mesma diferença. É a exclusão do namespace da rede. Esse 9 e a remoção do namespace de montagem desencadearão a desmontagem de qualquer maneira.

Ah ok

A propósito, reproduzi o problema por engano (durante o desenvolvimento) em outra máquina com smb novamente. É um Ubuntu 16.04 PC, Linux 4.4.0-77-genérico. E há um backtrace de tarefa travado que pode ser interessante. Sem travamento e mesmo retardo de cerca 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

O tópico netdev @ vger está aqui https://www.mail-archive.com/[email protected]/msg179703.html se alguém quiser acompanhar o progresso.

@piec sim, isso é esperado.

Também encontrei esse bug e consegui reproduzir Oopses com o método docker-samba-loop de @piec nas imagens do kernel do Ubuntu:

• linux-image-4.4.0-93-generic
• linux-image-4.10.0-1004-gcp
• linux-image-4.10.0-32-generic
• linux-image-4.11.0-14-generic
• linux-image-4.12.10-041210-generic = 4.12.10-041210.20170830

Adicionei minhas descobertas ao relatório de bug do Ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407 e https://github.com/fho/docker-samba-loop

@fho obrigado. Na verdade, você não precisa do docker para reproduzir, apenas executar o cliente samba em um namespace de rede resolverá o problema de acordo com https://github.com/moby/moby/issues/5618#issuecomment -318681443

@rn obrigado pela informação. Ainda não tentei assim.

As postagens recentes aqui e na lista de discussão netdev parecem ser apenas sobre travamentos do kernel.
Estou tendo travamentos de kernel também com kernel 4.11 e 4.12.

Estou vendo um problema muito semelhante a este (conforme detalhado em # 35068). Basicamente, executamos um enxame de dois nós, que executa um único serviço com 4 réplicas usando uma estratégia de distribuição de distribuição.

Em cada um desses contêineres de serviço, montamos o host docker.sock como um volume e, de dentro do contêiner, executamos comandos docker run , com simultaneidade máxima de 4 por contêiner. Isso resulta em até 4 contêineres sendo criados simultaneamente e imediatamente removidos por meio de -rm .

Logs de kernel adicionais e exemplos em ARMv7 mostrados na referência acima.

pânico ip6_route_dev_notify é um problema sério para nós.

Acho que olhando um pouco mais, definitivamente NÃO é o mesmo bug que:

• https://github.com/hardkernel/linux/issues/312
• https://ubuntuforums.org/showthread.php?t=2367854

Acho que esse é um problema do upstream no kernel com a camada ipv6.

Esta informação pode ser relevante.

Podemos reproduzir o problema com _unregister_netdevice: esperando que lo seja liberado. Contagem de uso = 1_ com kernel 4.14.0-rc3 com _CONFIG_PREEMPT_NONE = y_ e executando apenas em uma CPU com as seguintes opções de kernel de inicialização:

BOOT_IMAGE = / boot / vmlinuz-4.14.0-rc3 root = / dev / mapper / vg0-root ro quiet vsyscall = emular nosmp

Assim que atingirmos esse estado, ele permanecerá nesse estado e será necessário reinicializar. Nenhum outro container pode ser gerado. Nós o reproduzimos rodando imagens fazendo conexões ipsec / openvpn + baixando um pequeno arquivo dentro dos túneis. Então, as instâncias existem (geralmente são executadas <10s). Executamos 10s desses contêineres por minuto em uma máquina. Com as configurações mencionadas acima (apenas 1cpu), a máquina acerta em cerca de 2 horas.

Outro reprodutor com o mesmo kernel, mas sem limitar o número de CPUs, é apenas executar iperf em modo UDP por 3 segundos dentro do contêiner (para que não haja comunicação TCP). Se rodarmos 10 desses contêineres em paralelo, esperamos que todos eles terminem e façamos novamente, encontramos o problema em menos de 10 minutos (em uma máquina de 40 núcleos).

Em ambos os reprodutores, adicionamos "ip route flush table all; ifconfigbaixa; sleep 10 "antes de existir de contêineres. Não parece ter nenhum efeito.

Oi,

Só para aumentar o fogo também estamos vendo esse problema, conforme solicitado aqui estão os seguintes ...

Versão do 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

Distribuição / versão do Linux: Debian 9.1 (com todos os pacotes atualizados)

Você está usando a versão mais recente do kernel do seu fornecedor Linux? sim

Configuração de rede (ponte, sobreposição, IPv4, IPv6, etc): somente IPv4, NAT de acordo com a configuração padrão do Docker

Descrição da carga de trabalho (que tipo de contêiner, que tipo de carga de rede, etc): Contêineres de vida muito curta (de alguns segundos a alguns minutos) executando scripts antes de sair.

E, idealmente, uma reprodução simples:

** kernel: [617624.412100] unregister_netdevice: esperando que lo se torne livre. Contagem de uso = 1

Não foi possível eliminar o contêiner antigo ou iniciar novos nos nós afetados, tive que reiniciar para restaurar a funcionalidade. **

Esperamos encontrar uma causa / patch em breve.

Cumprimentos,

robputt796

@campbellr
concordou que parece ter algo a ver com o armazenamento de rede. Estou usando ceph krbd como volume persistente no kubernetes.
E posso reproduzir a situação depois de muito tempo executando a falha do contêiner.

O problema foi atribuído há 10 dias e está em andamento. Você pode ver mais informações sobre o que está acontecendo aqui https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407

Espero que Dan Streetman descubra como consertar

Acontece que o Oops é causado por um bug do kernel que foi corrigido pelo commit 76da0704507bbc51875013f6557877ab308cfd0a:

ipv6: apenas chame ip6_route_dev_notify () uma vez para NETDEV_UNREGISTER

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76da0704507bbc51875013f6557877ab308cfd0a
(Ele simplesmente corrige o kernel panic, não o "kernel: unregister_netdevice: esperando que lo se torne livre. Contagem de uso = 2" problema.)

(repetindo aqui novamente, porque o GitHub está ocultando comentários antigos)

Se você está chegando aqui

O problema que está sendo discutido aqui é um bug do kernel e ainda não foi totalmente corrigido. Alguns patches foram no kernel que corrigem _algumas_ ocorrências deste problema, mas outros ainda não foram resolvidos.

Existem várias opções que podem ajudar em _algumas_ situações, mas não em todas (mais uma vez; é mais provável que seja uma combinação de problemas que desencadeiam o mesmo erro)

Não deixe comentários do tipo "Eu também tenho isso"

"Eu também tenho isso" não ajuda a resolver o bug. apenas deixe um comentário se você tiver informações que possam ajudar a resolver o problema (nesse caso; fornecer um patch para o kernel upstream pode ser o melhor passo).

Se você quiser informar que também tem esse problema, use o botão "Gostei" na descrição superior:

Se você quiser se manter informado sobre as atualizações, use o _botão de inscrição_.

Todos os comentários aqui enviam um e-mail / notificação para mais de 3000 pessoas . Não quero bloquear a conversa sobre esse problema, pois ainda não foi resolvido, mas posso ser forçado se você ignorar.

Vou remover comentários que não adicionam informações úteis para encurtar (ligeiramente) o tópico

Se você quiser ajudar a resolver este problema

• Leia todo o tópico; é longo e o github oculta os comentários (então você terá que clicar para torná-los visíveis novamente). Existem muitas informações neste tópico que podem ajudá-lo
• Leia este comentário https://github.com/moby/moby/issues/5618#issuecomment -316297818 (e comentários na época) para obter informações que podem ser úteis.

Obrigado!

Acredito ter corrigido esse problema, pelo menos quando causado por uma conexão de soquete TCP do kernel. Kernels de teste para Ubuntu estão disponíveis e eu adoraria um feedback se eles ajudassem / corrigissem isso para alguém aqui. O patch é enviado pelo upstream; mais detalhes estão no bug LP:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/comments/46

Desculpe estragar a comemoração, mas conseguimos reproduzir o problema. Agora estamos trabalhando com @ddstreet nele em https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/ .

Não há soluções alternativas?

Use a rede de host (que destrói muito do valor dos contêineres, mas pronto).

@ pumba-lt Tivemos esse problema cerca de 1,5 anos atrás, cerca de 1 ano atrás, desativei o ipv6 no nível do kernel (não sysctl) e não tive o problema nenhuma vez. Executando um cluster de 48 lâminas.

Normalmente em: /etc/default/grub
GRUB_CMDLINE_LINUX="xxxxx ipv6.disable=1"

No entanto, eu uso a inicialização PXE, então minha configuração PXE tem:

      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

Garanto que você não verá esse problema novamente.

Todos, por favor, entendam que este é um SINTOMA comum que tem muitas causas. O que funcionou para você para evitar isso pode não funcionar para outra pessoa.

Posso confirmar que nossos problemas foram resolvidos após desabilitar o IPv6 na inicialização (arquivo de configuração do fron grub). Teve vários problemas em um cluster de 7 nós, agora funciona sem problemas.

Não me lembro onde encontrei a solução, ou pelo menos encontrei, obrigado @qrpike por sugerir isso a outras pessoas :) !!

https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.114

commit edaafa805e0f9d09560a4892790b8e19cab8bf09
Autor: Dan Streetman [email protected]
Data: Qui, 18 de janeiro 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]>

Usar SCTP em netns também pode desencadear isso, correções em 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

ainda aconteceu "unregister_netdevice: aguardando que o eth0 se tornasse livre. Usage count = 1" embora eu tenha atualizado a versão do kernel para 4.4.118 e docker versão 17.09.1-ce, talvez eu deva tentar desabilitar ipv6 no nível do kernel. Espero que funcione na nuvem.

@ wuming5569 por favor me diga se funcionou para você com essa versão do linux

@ wuming5569 talvez, atualize o kernel 4.4.114 correção "unregister_netdevice: esperando que lo se torne livre. Contagem de uso = 1", não para "unregister_netdevice: esperando que o eth0 se torne livre. Contagem de uso = 1".
Eu testei em produção.
@ddstreet isso é um feedback, alguma ajuda?

@ wuming5569 como mencionado acima, as próprias mensagens são benignas, mas podem eventualmente levar ao travamento do kernel. Seu kernel travou e, em caso afirmativo, qual é o seu padrão de rede, ou seja, que tipo de rede seus containers fazem?

Experimentou o mesmo problema no CentOS. Meu kernel é 3.10.0-693.17.1.el7.x86_64. Mas, eu não obtive rastreamento de pilha semelhante no syslog.

Mesmo no kernel Centos7 3.10.0-514.21.1.el7.x86_64 e docker 18.03.0-ce

@danielefranceschi Eu recomendo que você atualize para o kernel CentOS mais recente (pelo menos 3.10.0-693). Não vai resolver o problema, mas parece ser muito menos frequente. Nos kernels 3.10.0-327 e 3.10.0-514, víamos o rastreamento da pilha, mas, pela minha memória, não acho que vimos nenhum deles no 3.10.0-693.

@alexhexabeam 3.10.0-693 parece funcionar perfeitamente, tnx :)

Mesmo no kernel CentOS7 4.16.0-1.el7.elrepo.x86_64 e docker 18.03.0-ce

Funcionou semanas antes da queda e, quando tentei subir, travou completamente.

O problema também aconteceu com o kernel 3.10.0-693.21.1.el7

Posso confirmar que também acontece em:

Linux 3.10.0-693.17.1.el7.x86_64
Servidor Red Hat Enterprise Linux versão 7.4 (Maipo)

Posso reproduzi-lo fazendo "reinicialização do docker de serviço" com uma certa quantidade de carga.

@ wuming5569 você corrigiu esse problema? qual é o seu tipo de rede? estamos confusos com esse problema há semanas.
Você tem nossa conta?

4admin2root, dada a correção que você mencionou, https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.114 ,

é seguro desabilitar o proxy do ambiente do usuário para o daemon do docker, se o kernel recente apropriado estiver instalado? Não está muito claro se é de

https://github.com/moby/moby/issues/8356
https://github.com/moby/moby/issues/11185

Uma vez que ambos são mais antigos do que a correção do kernel

Obrigado

estamos confusos com esse problema há semanas.
Linux 3.10.0-693.17.1.el7.x86_64
CentOS Linux versão 7.4.1708 (Core)

Alguém pode confirmar se o kernel 4.14 mais recente tem esse problema? Parece que não. Ninguém na Internet enfrentou esse problema com o kernel 4.14.

Eu vejo isso no kernel 4.15.15-1, Centos7

Olhando os logs de mudança, https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.15.8 tem uma correção para SCTP, mas não para TCP. Portanto, você pode querer experimentar o 4.14 mais recente.

• mesmo 4.15.18 não ajuda com esse bug
• desabilitar o ipv6 também não ajuda

agora atualizamos para 4.16.13. Observando. Este bug estava nos atingindo em um nó apenas cerca de uma vez por semana.

Você desabilitou o ipv6 nos parâmetros de inicialização do grub ou sysctl? Apenas os parâmetros de inicialização funcionarão. Sysctl não vai consertar.

Em 4 de junho de 2018 às 12h09:53, Sergey Pronin ( [email protected] (mailto: [email protected])) escreveu:

mesmo 4.15.18 não ajuda com esse bug
desabilitar o ipv6 também não ajuda

agora atualizamos para 4.16.13. Observando. Este bug estava nos atingindo em um nó apenas cerca de uma vez por semana.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub (https://github.com/moby/moby/issues/5618#issuecomment-394410321) ou ignore o tópico (https://github.com/notifications/unsubscribe-auth / AAo3HLYI_jnwjgtQ0ce-E4mc6Em5yeISks5t5VvRgaJpZM4B4L4Z).

para mim, na maioria das vezes o bug aparece depois de reimplantar o mesmo projeto / rede novamente

@qrpike você está certo, tentamos apenas sysctl. Deixe-me tentar com o grub. Obrigado!

4.9.88 Kernel do Debian. Reproduzível.

@qrpike você está certo, tentamos apenas sysctl. Deixe-me tentar com o grub. Obrigado!

No meu caso, desabilitar o ipv6 não fez diferença.

@ spronin-aurea Desativar o ipv6 no carregador de inicialização ajudou?

@qrpike você pode nos contar sobre os nós que está usando se desabilitar o ipv6 ajudou no seu caso? Versão do kernel, versão k8s, CNI, versão do docker etc.

@komljen Tenho usado CoreOS nos últimos 2 anos sem um único incidente. Desde ~ ver 1000. Eu não tentei recentemente, mas se eu não desabilitar o ipv6, o bug acontece.

Do meu lado, estou usando CoreOS também, ipv6 desabilitado com grub e ainda estou tendo o problema

@deimosfr No momento, estou usando a inicialização PXE para todos os meus nós:

      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

No entanto, meu nó principal que é o host PXE também é CoreOS e inicializa a partir do disco e também não tem o problema.

Quais versões de kernel vocês estão executando?

Os que eu encontrei com o problema estavam em 4.14.32-coreos e antes. Não encontrei esse problema ainda em 4.14.42-coreos

Centos 7.5 com kernel 4.17.3-1, ainda tem o problema.

Env:
kubernetes 1.10.4
Docker 13.1
com o plugin de rede Flannel.

Registro :
[89.790907] IPv6: ADDRCONF (NETDEV_UP): eth0: o link não está pronto
[89.798523] IPv6: ADDRCONF (NETDEV_CHANGE): eth0: o link fica pronto
[89.799623] cni0: a porta 8 (vethb8a93c6f) entrou no estado de bloqueio
[89.800547] cni0: a porta 8 (vethb8a93c6f) entrou no estado desativado
[89.801471] dispositivo vethb8a93c6f entrou no modo promíscuo
[89.802323] cni0: a porta 8 (vethb8a93c6f) entrou no estado de bloqueio
[89.803200] cni0: a porta 8 (vethb8a93c6f) entrou no estado de encaminhamento

kernel: unregister_netdevice : esperando que lo se torne livre. Contagem de uso = 1。

Agora :
O IP do nó pode alcançar, mas não pode usar nenhum serviço de rede, como ssh ...

Os sintomas aqui são semelhantes a muitos relatórios em vários outros lugares. Tudo relacionado a namespaces de rede. As pessoas que se deparam com isso podem ver se unshare -n trava e, em caso afirmativo, em outro terminal, faça cat /proc/$pid/stack do processo de cancelamento de compartilhamento para ver se ele trava em copy_net_ns() ? Este parece ser um denominador comum para muitos dos problemas, incluindo alguns rastros encontrados aqui. Entre 4.16 e 4.18 houve uma série de patches de Kirill Tkhai refatorando muito o bloqueio envolvido. Os mantenedores dos pacotes distro / kernel afetados devem provavelmente dar uma olhada em aplicá-los / portá-los para kernels estáveis ​​e ver se isso ajuda.
Veja também: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779678

@Blub

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

Dadas as alterações de bloqueio no 4.18, seria bom testar o 4.18rc atual, especialmente se você pode ativá-lo de forma mais ou menos confiável, pois pelo que tenho visto, há muitas pessoas onde alterar as versões do kernel também mudou a probabilidade de isso acontecer bastante.

Eu tive esses problemas com o Kubernetes e depois de mudar para a última versão estável do CoreOS - 1745.7.0, o problema desapareceu:

• kernel: 4.14.48
• docker: 18.03.1

mesmo problema no CentOS 7

• kernel: 4.11.1-1.el7.elrepo.x86_64
• docker: 17.12.0-ce

@Blub Vendo o mesmo no 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

Em teoria, pode haver um ou mais outros rastros em algum lugar contendo uma das funções de net_namespace.c bloqueando o net_mutex ( cleanup_net , net_ns_barrier , net_ns_init , {,un}register_pernet_{subsys,device} ). Para kernels estáveis, é claro que seria muito mais fácil se houvesse algo em particular bloqueando de uma forma que pudesse ser corrigida, do que portar todas as alterações de bloqueio do 4.18. Mas até agora não vi nenhum traço que levasse à causa raiz. Não sei se isso vai ajudar, mas talvez outros /proc/*/stack s com as funções acima estejam visíveis quando o problema aparecer?

o mesmo problema ! e meu env é debian 8

RHEL, SWARM, 18.03.0-ce

1. Conectando ao nó gerenciador via ssh

2. Iniciando manualmente um contêiner em um nó gerenciador:

   sudo docker run -it -v / import: / temp / eximport -v / home / myUser: / temp / exhome docker.repo.myHost / fedora: 23 / bin / bash

3. Depois de algum tempo sem fazer nada:

   [ root @ 8a9857c25919 myDir] #
   Mensagem de syslogd @ se1-shub-t002 em 19 de julho 11h56:03 ...
   kernel: unregister_netdevice : esperando que lo se torne livre. Contagem de uso = 1

Depois de minutos, estou de volta ao console do nó do gerenciador e o contêiner iniciado não está mais em execução.

Isso descreve o mesmo problema ou é outro "conjunto de problemas"?

THX com antecedência!

ATUALIZAR
Isso também acontece diretamente no console ssh (no bash do gerenciador de enxame).

ATUALIZAR
Máquina host (um nó gerenciador no enxame):
Linux [MACHINENNAME] 3.10.0-514.2.2.el7.x86_64 # 1 SMP Quarta-feira, 16 de novembro 13:15:13 EST 2016 x86_64 x86_64 x86_64 GNU / Linux

Se isso não resolver depois de algum tempo, o problema é diferente.

Mesmo no kernel CentOS7.5 3.10.0-693.el7.x86_64 e docker 1.13.1

O mesmo problema OEL 7.5
uname -a
4.1.12-124.16.1.el7uek.x86_64 # 2 SMP Seg 11 de junho 20:09:51 PDT 2018 x86_64 x86_64 x86_64 GNU / Linux
informação do docker
Recipientes: 9
Em execução: 5
Pausado: 0
Parado: 4
Imagens: 6
Versão do servidor: 17.06.2-ol

dmesg
[2238374.718889] unregister_netdevice: aguardando que lo se torne livre. Contagem de uso = 1
[2238384.762813] unregister_netdevice: aguardando que lo se torne livre. Contagem de uso = 1
[2238392.792585] eth0: renomeado de vethbed6d59

(repetindo https://github.com/moby/moby/issues/5618#issuecomment-351942943 aqui novamente, porque o GitHub está ocultando comentários antigos)

Se você está chegando aqui

O problema que está sendo discutido aqui é um bug do kernel e ainda não foi totalmente corrigido. Alguns patches foram no kernel que corrigem _algumas_ ocorrências deste problema, mas outros ainda não foram resolvidos.

Existem várias opções que podem ajudar em _algumas_ situações, mas não em todas (mais uma vez; é mais provável que seja uma combinação de problemas que desencadeiam o mesmo erro)

O erro "unregister_netdevice: esperando que lo se torne livre" em si não é o bug

Se o kernel travar _após_ isso é um bug (veja abaixo)

Não deixe comentários do tipo "Eu também tenho isso"

"Eu também tenho isso" não ajuda a resolver o bug. apenas deixe um comentário se você tiver informações que possam ajudar a resolver o problema (nesse caso; fornecer um patch para o kernel upstream pode ser o melhor passo).

Se você quiser informar que também tem esse problema, use o botão "Gostei" na descrição superior:

Se você quiser se manter informado sobre as atualizações, use o _botão de inscrição_.

Todos os comentários aqui enviam um e-mail / notificação para mais de 3000 pessoas . Não quero bloquear a conversa sobre esse problema, pois ainda não foi resolvido, mas posso ser forçado se você ignorar.

Vou remover comentários que não adicionam informações úteis para encurtar (ligeiramente) o tópico

Se você quiser ajudar a resolver este problema

• Leia todo o tópico, incluindo os comentários que estão ocultos ; é longo e o github oculta os comentários (então você terá que clicar para torná-los visíveis novamente). Existem muitas informações neste tópico que podem ajudá-lo

• Leia este comentário https://github.com/moby/moby/issues/5618#issuecomment -316297818 (e comentários na época) para obter informações que podem ser úteis:

Para ficar claro, a mensagem em si é benigna , é o travamento do kernel após as mensagens relatadas pelo OP que não é.

O comentário no código, de onde esta mensagem está vindo, explica o que está acontecendo. Basicamente, cada usuário, como a pilha de IP) de um dispositivo de rede (como o final do par veth dentro de um contêiner) incrementa uma contagem de referência na estrutura do dispositivo de rede quando está usando o dispositivo de rede. Quando o dispositivo é removido (por exemplo, quando o contêiner é removido), cada usuário é notificado para que possa fazer alguma limpeza (por exemplo, fechar soquetes abertos, etc.) antes de diminuir a contagem de referência. Como essa limpeza pode levar algum tempo, especialmente sob carga pesada (muitas interfaces, muitas conexões, etc.), o kernel pode imprimir a mensagem aqui de vez em quando .

Se um usuário de dispositivo de rede nunca diminuir a contagem de referência, alguma outra parte do kernel determinará que a tarefa que está aguardando a limpeza está travada e irá travar. É apenas esse travamento que indica um bug do kernel (algum usuário, por meio de algum caminho de código, não diminuiu a contagem de referência). Houve vários desses bugs e eles foram corrigidos no kernel moderno (e possivelmente retransportados para os mais antigos). Eu escrevi alguns testes de estresse (e continuo a escrevê-los) para acionar tais travamentos, mas não fui capaz de reproduzir em kernels modernos (eu, no entanto, faço a mensagem acima).

* Por favor, relate este problema apenas se o seu kernel realmente travar *, e então estaríamos muito interessados ​​em:

• versão do kernel (saída de uname -r )
• Distribuição / versão Linux
• Você está usando a versão mais recente do kernel do seu fornecedor Linux?
• Configuração de rede (ponte, sobreposição, IPv4, IPv6, etc)
• Descrição da carga de trabalho (que tipo de contêineres, que tipo de carga de rede, etc)
• E, idealmente, uma reprodução simples

Obrigado!

Vocês estão executando o docker sob algum limite? Como ulimits, cgroups etc ...

O systemd mais recente possui um limite padrão, mesmo que você não o tenha definido. Eu defini as coisas como ilimitadas e o problema não ocorreu desde então (assistindo desde 31 dias).

Eu tive o mesmo problema em muitos ambientes e minha solução foi parar o firewall. Não aconteceu de novo, por enquanto

Rhel 7.5 - 3.10.0-862.3.2.el7.x86_64
Docker 1.13

@dElogics Qual versão do systemd é considerada "mais recente"? Este limite padrão está habilitado no systemd CentOS 7.5?

Além disso, quando você pergunta se estamos executando o docker sob algum limite, você se refere ao daemon do docker ou aos contêineres individuais?

O daemon do docker. O systemd como no Debian 9 (232-25).

Não tenho certeza sobre o RHEL, mas também vi esse problema pessoalmente no RHEL. Eu definiria LimitNOFILE = 1048576, LimitNPROC = infinito, LimitCORE = infinito, TasksMax = infinito

kernel: unregister_netdevice: aguardando que o eth0 se torne livre. Contagem de uso = 3
kernel 4.4.146-1.el7.elrepo.x86_64
versão linux CentOS Linux release 7.4.1708 (Core)
Modo Ponte

Eu tive o mesmo problema, o que posso fazer?

O mesmo problema:

CentOS Linux versão 7.5.1804 (Core)
Docker versão 18.06.1-ce, compilação e68fc7a
Versão do kernel: 3.10.0-693.el7.x86_64

O problema semelhante que encontrei aqui ...
Há algum movimento que eu possa fazer agora? Por favor, me ajude...

CentOS 7.0.1406
[ root @ zjsm-slavexx etc] # uname -a
Linux zjsm-slave08 3.10.0-123.el7.x86_64 # 1 SMP Seg 30 de junho 12:09:22 UTC 2014 x86_64 x86_64 x86_64 GNU / Linux
[ root @ zjsm-slavexx etc] # cat / etc / centos-release
CentOS Linux versão 7.0.1406 (Core)

Informações do Docker:
[ root @ zjsm-slavexx ~] # versão do docker
Cliente:
Versão: 17.04.0-ce
Versão API: 1.28
Versão Go: go1.7.5
Git commit: 4845c56
Construído: Seg, 3 de abril, 18:01:50 de 2017
OS / Arch: linux / amd64

Servidor:
Versão: 17.04.0-ce
Versão da API: 1.28 (versão mínima 1.12)
Versão Go: go1.7.5
Git commit: 4845c56
Construído: Seg, 3 de abril, 18:01:50 de 2017
OS / Arch: linux / amd64
Experimental: falso

Kernel do CentOS Linux versão 7.2.1511: 3.10.0-327.el7.x86_64
mesmo problema

Eu experimentei esse 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 , talvez você deva adicionar seu comentário no início da postagem original, já que as pessoas ainda o estão ignorando.

$ 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 

consertou.

@hzbd Você quer dizer excluir a rede de ponte definida pelo usuário? Você já tentou cavar mais para descobrir por quê? Por favor, deixe-me saber se você fez isso. Eu realmente aprecio isso.

Esperando ser consertado

Vocês estão executando o docker sob algum limite? Como ulimits, cgroups etc ...

O systemd mais recente possui um limite padrão, mesmo que você não o tenha definido. Eu defini as coisas como ilimitadas e o problema não ocorreu desde então (assistindo desde 31 dias).

Ok, esse bug ainda ocorre, mas a probabilidade foi reduzida.

Eu acho que se os contêineres forem normalmente parados (PID 1 exist () s), então esse bug não vai nos incomodar.

@dElogics obrigado por nos informar, você poderia nos mostrar quais comandos você executou para definir os limites deste systemd como ilimitados. Eu gosto de tentar isso também.

@dElogics obrigado por nos informar, você poderia nos mostrar quais comandos você executou para definir os limites deste systemd como ilimitados. Eu gosto de tentar isso também.

Você tem que modificar a unidade systemd do docker. A unidade systemd que eu uso (apenas 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

Alguém teve esse problema em um kernel 4.15 ou mais recente?

Esta correção Dan Streetman (https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d) foi incluída pela primeira vez na versão do kernel 4.15 e parece que pelo menos para alguém isso não está acontecendo mais desde que eles atualizaram para 4.16 (https: / /github.com/kubernetes/kubernetes/issues/64743#issuecomment-436839647)

Alguém experimentou?

@victorgp Ainda temos o problema com o kernel 4.15. Nós relataremos aqui quando tivermos testado com o kernel 4.16 (esperançosamente em algumas semanas).

Usamos a versão do kernel

Para adicionar às minhas resoluções anteriores - uma parada graciosa de contêineres (que respondem ao SIGTERM) nunca aciona isso.

Além disso, tente executar os contêineres no namespace do host (se for aceitável para você), o que resolve totalmente o problema.

@dElogics O que você quer dizer com "namespace de host"? É simplesmente --privileged ?

@dElogics O que você quer dizer com "namespace de host"? É simplesmente --privileged ?

Não, isso significa --network = host

Desde a atualização do kernel 4.4.0 para 4.15.0 e docker 1.11.2 para 18.09, o problema desapareceu.

Em uma frota considerável de VMs atuando como hosts docker, tivemos esse problema que aparecia várias vezes ao dia (com nosso caso de uso Docker).
45 dias e não estamos mais vendo isso.

Para a posteridade, um rastreamento de pilha de um Docker 1.11.2 pendurado com printk mostrando unregister_netdevice: waiting for vethXXXXX (semelhante ao que sempre víamos em nossa frota, em centenas de VMs) pode ser encontrado em http: // paste .ubuntu.com / p / 6RgkpX352J / (a referência de contêiner interessante é 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

A partir disso, podemos observar que ele está suspenso em https://github.com/moby/moby/blob/v1.11.2/daemon/container_operations.go#L732

que nos aponta para https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/sandbox.go#L175

E
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/endpoint.go#L760

Que vai para o driver de ponte libnetwork (verifique a descrição incrível)
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go#L1057 -L1061

Movendo para 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

E, finalmente, nesse soquete netlink, chama https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go#L333

Sentimos que o bug em geral acontece ao parar um contêiner e devido aos SKBs ainda serem referenciados no netns, o veth não é liberado, então o Docker emite um Kill para aquele contêiner após 15s. O daemon do Docker não lida com essa situação normalmente, mas no final das contas o bug está no kernel. Acreditamos que https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d (aceito em 4.15 upstream) e commits vinculados a ele (há vários) atuam como uma mitigação.

Em geral, essa parte do kernel não é um lugar bonito.

Por que vale a pena ... atualizamos o kernel RHEL Linux de 3.10.0 para 4.17.11. (Executando o cluster do Kubernetes). Antes de atualizar, esse bug ocorria diariamente várias vezes em diferentes servidores. Executando a atualização há três semanas. Bug ocorreu apenas uma vez. Então, grosso modo, é reduzido em 99%.

@marckamerbeek Você atualizou o RHEL Kernel para um Kernel da comunidade? Então não é mais suportado.

O usuário do

centos 7.2 ainda tem este problema: kernel: unregister_netdevice : esperando que lo se torne livre. Contagem de uso = 1

@Beatlor RHEL não nos ajudou em nada. Um ambiente de produção estável é mais importante do que algum contrato de suporte inútil. Ainda estamos muito estáveis ​​agora em 4.17.11. Não há mais grandes problemas.

@Beatlor RHEL não nos ajudou em nada. Um ambiente de produção estável é mais importante do que algum contrato de suporte inútil. Ainda estamos muito estáveis ​​agora em 4.17.11. Não há mais grandes problemas.

Sim, eu também não tive esse problema depois de atualizar o kernel para 4.17.0-1.el7.elrepo.x86_64. Eu tentei isso antes (4.4.x, 4.8, 4.14 ..) e falhou. Parece que o problema não ocorrerá novamente no kernel 4.17+.

centos 7.2 ainda tem este problema: kernel: unregister_netdevice : esperando que lo se torne livre. Contagem de uso = 1

Você pode tentar atualizar para o kernel 4.19+ mais recente.

Espere alguns meses e alguém irá reclamar do kernel 4.19 também. Apenas a história se repetindo.

Olá a todos, boas notícias!

Desde meu último comentário aqui (no momento da redação, 17 dias atrás), não recebi esses erros novamente. Meus servidores (cerca de 30 deles) estavam executando o Ubuntu 14.04 com alguns pacotes desatualizados.

Após uma atualização completa do sistema incluindo docker-engine (de 1.7.1 para 1.8.3) + atualização do kernel para a versão mais recente possível no repositório do Ubuntu, meus servidores estão funcionando sem nenhuma ocorrência.

🎱

qual versão do kernel você está atualizando?

talvez relacionado a este https://github.com/torvalds/linux/commit/f186ce61bb8235d80068c390dc2aad7ca427a4c2

Aqui está uma tentativa de resumir esse problema, a partir dos comentários sobre ele, https://github.com/kubernetes/kubernetes/issues/70427 , https://github.com/kubernetes/kubernetes/issues/64743 e https: //access.redhat.com/solutions/3659011

Versões de kernel observadas com este problema

• RHEL7 3.10.0-862
• 4.15.0
• 4,20,0

As versões do kernel afirmam não ter causado esse problema

• RHEL7 3.10.0-957.10.1
• 4.19,12
• 4.17.0
• 4.17.11

Commits de kernel relacionados

• 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

Desafio https://github.com/kubernetes/kubernetes/issues/70427#issuecomment -470681000, pois não vimos isso com milhares de VMs no 4.15.0, embora o víssemos dezenas de vezes por dia no 4.4. 0, há mais relatos disso no 4.15.0?

Estou tendo esse problema com uma das minhas máquinas executando Docker no Debian 9 Stretch ( 4.9.0-8-amd64 ). Eu experimento esse problema com um túnel criado dentro do contêiner do Docker via Docker Gen e ele gera um kernel panic:

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

Estas são nossas informações do 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

Alguém sabe se há uma solução temporária para isso sem reiniciar a máquina inteira? Nós realmente preferiríamos não ter que reiniciar a máquina inteira quando tivermos esse problema.

Um tanto fora do assunto, não podemos suprimir as mensagens de kernel panic no terminal também. Tentei dmesg -D e dmesg -n 1 . No entanto, sem sorte. Existe uma maneira de suprimir esse tipo de mensagens de kernel panic de dentro do terminal? É irritante tentar digitar comandos e ter essa mensagem aparecendo a cada 10 segundos ou mais.

Obrigado.

Esses kernels vanilla ou fortemente corrigidos por distros com correções backported?

@pmoust Eu vejo isso no ubuntu 4.15.0-32 uma vez por semana ou assim. definitivamente muito melhor desde 4.4.0

@iavael, tentarei listar as informações da distro no resumo, se a referência as fornecer.

Alguém viu esse bug com 4.19?

Alguém viu esse bug com 4.19?

https://github.com/kubernetes/kubernetes/issues/64743#issuecomment -451351435
https://github.com/kubernetes/kubernetes/issues/64743#issuecomment -461772385

Esta informação pode ser útil para você.

@tankywoo @drpancake @egasimus @csabahenk @spiffytech @ibuildthecloud @sbward @jbalonso @rsampaio @MrMMorris @rsampaio @unclejack @chrisjstevenson @popsikle @fxposhang @ scheriang @ scher200 @victorgp @jeatBlogstangstangome @victorgp @jeatBogstangstangstang @ scher200 @victorgp @jeatBogstangstangome @ scher200 @victorgp @jeatBogstangstangome @ scher200 @victorgp @jeatBlogstangstangome @Jovons @ 247687009 @jwongz @ tao12345666333 @clkao Por favor, olhe este 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 @fxposhang @ scheriang @ scher200 @victorgp @jeatBlogstangstangome @victorgp @jeatBogstangstangstang @ scher200 @victorgp @jeatBogstangstangome @ scher200 @victorgp @jeatBogstangstangome @ scher200 @victorgp @jeatBlogstangstangome @Jovons @ 247687009 @jwongz @ tao12345666333 @clkao Por favor, olhe este https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs-while-testing-tidb-operator-in-k8s/

Eu segui a documentação, mas ainda recebo um erro.

[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

Essa mensagem em si não é o bug; é o kernel travando depois; https://github.com/moby/moby/issues/5618#issuecomment -407751991

@tankywoo @drpancake @egasimus @csabahenk @spiffytech @ibuildthecloud @sbward @jbalonso @rsampaio @MrMMorris @rsampaio @unclejack @chrisjstevenson @popsikle @fxposhang @ scheriang @ scher200 @victorgp @jeatBlogstangstangome @victorgp @jeatBogstangstangstang @ scher200 @victorgp @jeatBogstangstangome @ scher200 @victorgp @jeatBogstangstangome @ scher200 @victorgp @jeatBlogstangstangome @Jovons @ 247687009 @jwongz @ tao12345666333 @clkao Por favor, olhe este https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs-while-testing-tidb-operator-in-k8s/

Eu segui a documentação, mas ainda recebo um erro.

[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

Após reiniciar, ok ···

@ vincent927 BTW ， Você deve colocar livepatch_route.ko em / var / lib / kpatch / $ (uname -r), ao habilitar kpatch.service, o ko pode ser carregado automaticamente após a reinicialização.

Conseguimos isso em nossa empresa de repente hoje em vários clusters 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"}

Ainda não sabemos a causa; estamos executando essas versões do software acima há vários meses sem problemas. Estou apenas comentando o acréscimo à lista de "versões de software que apresentam esse bug" por enquanto.

@ 2rs2ts Você tentou https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs-while-testing-tidb-operator-in-k8s/?

@ethercflow Eu li isso, mas como executamos o Debian em minha empresa, não é fácil implementar a correção naquele post.

@ethercflow @ 2rs2ts também estamos executando o debian. Eu encontrei muitos problemas ao tentar fazer o kpatch-build funcionar. Se eu conseguir encontrar uma solução alternativa, vou mantê-lo informado. Em qualquer caso, alguém tem outra solução? É a versão 4.15 ou 4.19 do kernel que atenua o problema? Tenho tentado encontrar a resposta na semana passada e ainda não consegui.

@commixon, nossa experiência ainda é a mesma relatada em https://github.com/moby/moby/issues/5618#issuecomment -455800975, em uma frota de mil VMs sem recorrência do problema com 4.15.0 em sabores genéricos, otimizados para AWS e otimizados para GCP de kernels fornecidos pela Canonical. O teste limitado no vanilla 4.15.0 também não mostrou nenhum desses problemas, mas não foi testado em escala.

Muito obrigado @pmoust . Vou experimentá-los. Em qualquer caso, também tentarei corrigir o kpatch para funcionar com o Debian (como um projeto paralelo) e postar atualizações aqui para todos os interessados.

@ethercflow @ 2rs2ts também estamos executando o debian. Eu encontrei muitos problemas ao tentar fazer o kpatch-build funcionar. Se eu conseguir encontrar uma solução alternativa, vou mantê-lo informado. Em qualquer caso, alguém tem outra solução? É a versão 4.15 ou 4.19 do kernel que atenua o problema? Tenho tentado encontrar a resposta na semana passada e ainda não consegui.

Você pode atualizar para 4.19. Está nas portas traseiras.

Aliás, já faz um ano para nós aqui. ;)

Na verdade, tentamos o 4.19 nos backports, mas ele teve algumas regressões importantes em outras áreas (as instâncias do EC2 seriam reiniciadas aleatoriamente e a rede seria interrompida na inicialização). Acho que teremos que lidar com isso até a próxima fase estável.

@ 2rs2ts Nos últimos 4 dias, estamos usando o 4.19 dos backports (no EC2) e não vimos nenhum problema. O problema de travamento do kernel não apareceu e todo o resto parece bem também. Não acredito que faça diferença, mas baseamos nossa imagem Debian na imagem fornecida por kops (https://github.com/kubernetes/kops/blob/master/docs/images.md#debian). Atualizamos o kernel nesta imagem e não o debian de estoque.

Amigos, tenho usado o kernel 4.19 para operação estável por meio ano. Espero que você também goste de estabilidade.

Eu tenho um contêiner aberto 80 e 443 portas, a cada 2 semanas, de outro contêiner de acesso ao computador 80 e
443 é negar

A versão do kernel centos7.3 é:
Navegador Linux1 3.10.0-514.el7.x86_64 # 1 SMP Ter 22 de novembro 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux

root @ browser1 ~] # versão do docker
Cliente:
Versão: 18.06.3-ce
Versão API: 1.38
Versão Go: go1.10.4
Git commit: d7080c1
Construído: Quarta, 20 de fevereiro, 02:24:22 2019
OS / Arch: linux / amd64
Experimental: falso

Servidor:
Motor:
Versão: 18.06.3-ce
Versão da API: 1.38 (versão mínima 1.12)
Versão Go: go1.10.3
Git commit: d7080c1
Construído: Quarta, 20 de fevereiro 02:25:33 2019
OS / Arch: linux / amd64
Experimental: falso
[ root @ browser1 ~] #

dmesg:

[1063959.636785] unregister_netdevice: aguardando que lo se torne livre. Contagem de uso = 1
[1071340.887512] br-af29e1edc1b8: a porta 5 (vethc2ac4f8) entrou no estado desativado
[1071340.891753] br-af29e1edc1b8: a porta 5 (vethc2ac4f8) entrou no estado desativado
[1071340.895118] dispositivo vethc2ac4f8 deixou o modo promíscuo
[1071340.895138] br-af29e1edc1b8: a porta 5 (vethc2ac4f8) entrou no estado desativado
[1071340.990505] dispositivo veth5e4f161 entrou no modo promíscuo
[1071340.990897] IPv6: ADDRCONF (NETDEV_UP): veth5e4f161: o link não está pronto
[1071340.990904] br-af29e1edc1b8: a porta 5 (veth5e4f161) entrou no estado de encaminhamento
[1071340.990924] br-af29e1edc1b8: a porta 5 (veth5e4f161) entrou no estado de encaminhamento
[1071341.231405] IPv6: ADDRCONF (NETDEV_CHANGE): veth5e4f161: o link fica pronto
[1071355.991701] br-af29e1edc1b8: a porta 5 (veth5e4f161) entrou no estado de encaminhamento
[1071551.533907] br-af29e1edc1b8: a porta 5 (veth5e4f161) entrou no estado desativado
[1071551.537564] br-af29e1edc1b8: a porta 5 (veth5e4f161) entrou no estado desativado
[1071551.540295] dispositivo veth5e4f161 saiu do modo promíscuo
[1071551.540313] br-af29e1edc1b8: a porta 5 (veth5e4f161) entrou no estado desativado
[1071551.570924] dispositivo veth8fd3a0a entrou no modo promíscuo
[1071551.571550] IPv6: ADDRCONF (NETDEV_UP): veth8fd3a0a: o link não está pronto
[1071551.571556] br-af29e1edc1b8: a porta 5 (veth8fd3a0a) entrou no estado de encaminhamento
[1071551.571582] br-af29e1edc1b8: a porta 5 (veth8fd3a0a) entrou no estado de encaminhamento
[1071551.841656] IPv6: ADDRCONF (NETDEV_CHANGE): veth8fd3a0a: o link fica pronto
[1071566.613998] br-af29e1edc1b8: a porta 5 (veth8fd3a0a) entrou no estado de encaminhamento
[1071923.465082] br-af29e1edc1b8: a porta 5 (veth8fd3a0a) entrou no estado desativado
[1071923.470215] br-af29e1edc1b8: a porta 5 (veth8fd3a0a) entrou no estado desativado
[1071923.472888] dispositivo veth8fd3a0a deixou o modo promíscuo
[1071923.472904] br-af29e1edc1b8: a porta 5 (veth8fd3a0a) entrou no estado desativado
[1071923.505580] dispositivo veth9e693ae entrou no modo promíscuo
[1071923.505919] IPv6: ADDRCONF (NETDEV_UP): veth9e693ae: o link não está pronto
[1071923.505925] br-af29e1edc1b8: a porta 5 (veth9e693ae) entrou no estado de encaminhamento
[1071923.505944] br-af29e1edc1b8: a porta 5 (veth9e693ae) entrou no estado de encaminhamento
[1071923.781658] IPv6: ADDRCONF (NETDEV_CHANGE): veth9e693ae: o link fica pronto
[1071938.515044] br-af29e1edc1b8: a porta 5 (veth9e693ae) entrou no estado de encaminhamento

Alguém viu esse bug com 4.19?

sim. Tenho o problema no kernel 4.19.4-1.e17.elrep.x86_64

Olá,

Também estou vendo esse erro. Temos alguma solução para este problema? Kernel 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 ainda está acontecendo :( nenhuma atualização / ideias sobre como corrigir?

Acontecendo no Debian Stretch. Eu estava tentando atualizar meu contêiner Jenkins via Ansible quando isso aconteceu.

Este problema foi resolvido por este compromisso:
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 foi resolvido por este compromisso:
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

Isso deve ser em 4.19.30 em diante.