我看到 eth0 的一个非常相似的问题。 Ubuntu 12.04 也是。

我必须重新启动机器。 从/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

嘿，这对我来说也刚刚开始发生。

码头工人版本：

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

内核日志： http :

系统详情：
运行带有补丁内核 (3.14.3-rt4) 的 Ubuntu 14.04 LTS。 尚未看到它发生在默认的 linux-3.13.0-27-generic 内核中。 然而，有趣的是，当这种情况发生时，我所有的终端窗口都冻结了，在此之前我最多只能输入几个字符。 同样的命运也降临在我打开的任何新笔记本上 - 我最终需要像上面的好医生一样重启我可怜的笔记本电脑。 作为记录，我在 urxvt 中运行 fish shell 或在 xmonad 中运行 xterm。 还没有检查它是否影响普通 bash。

这可能是相关的：
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065434#yui_3_10_3_1_1401948176063_2050

在容器内通过网络复制相当大量的数据
然后退出容器可能会触发 per
网络设备上的 CPU 引用计数。

果然，对我来说发生这种情况的一次是在apt-get使用具有大量依赖项的包之后。

从 Ubuntu 12.04.3 升级到 14.04 为我解决了这个问题，没有任何其他更改。

我在 RHEL7, 3.10.0-123.4.2.el7.x86_64 上遇到过这个

当我运行 3.14-rt4 时，我注意到我的 VirtualBox 虚拟网络接口发生了同样的事情。 它应该在 vanilla 3.13 或其他版本中修复。

@egasimus在这里

我升级到 Debian 内核 3.14，问题似乎已经消失。 看起来这个问题存在于一些小于 3.5 的内核中，在 3.5 中得到修复，在 3.6 中回归，并在 3.12-3.14 中进行了修补。 https://bugzilla.redhat.com/show_bug.cgi?id=880394

@spiffytech你知道我可以在哪里报告关于实时内核风格的问题吗？ 我认为他们只是为每个其他版本发布了一个 RT 补丁，并且真的不希望看到 3.16-rt 出现这个仍然损坏的情况。 ：/

编辑：在kernel.org提交。

我在运行 3.18.1 的 Ubuntu 14.10 上得到了这个。 内核日志显示

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

一旦系统不再冻结，我将发送docker version/info :)

我们也看到了这个问题。 Ubuntu 14.04、3.13.0-37-通用

在 Ubuntu 14.04 服务器上，我的团队发现从 3.13.0-40-generic 降级到 3.13.0-32-generic 可以“解决”这个问题。 鉴于@sbward的观察，这会将回归置于 3.13.0-32-generic 之后和之前（或包括）3.13.0-37-generic。

我要补充一点，在我们的例子中，我们有时会看到 _negative_ 使用计数。

FWIW 我们在可信赖的内核（3.13.0-40-generic #69-Ubuntu）上运行 lxc 时遇到了这个错误，该消息出现在 dmesg 中，然后是此堆栈跟踪：

[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

在 Ubuntu 14.04 和带有内核 3.16.x 的 Debian jessie 上遇到了这个问题。

码头工人命令：

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

这似乎是一个非常糟糕的问题......

@jbalonso即使使用 3.13.0-32-generic 我只在几次成功运行后收到错误：sob：

@MrMMorris您可以使用公共可用图像共享复制脚本吗？

每个在他们的系统上看到这个错误的人都在他们的发行版上运行一个 Linux 内核包，这个包太旧了，缺乏针对这个特定问题的修复。

如果遇到此问题，请确保运行apt-get update && apt-get dist-upgrade -y并重新启动系统。 如果您使用的是 Digital Ocean，您还需要选择更新期间刚刚安装的内核版本，因为它们不会自动使用最新内核（请参阅 https://digitalocean.uservoice.com/forums/136585-digitalocean /suggestions/2814988-give-option-to-use-the-droplet-s-own-bootloader）。

CentOS/RHEL/Fedora/Scientific Linux 用户需要使用yum update保持系统更新，并在安装更新后重新启动。

报告此问题时，请确保您的系统已完全修补并使用发行版供应商提供的最新稳定更新（无需手动安装实验/测试/alpha/beta/rc 软件包）。

@unclejack

我跑了apt-get update && apt-get dist-upgrade -y

ubuntu 14.04 3.13.0-46-通用

只有一个docker run后仍然出现错误

如果需要，我可以创建一个用于复制的 AMI

@MrMMorris感谢您确认 Ubuntu 14.04 上的最新内核包仍然存在问题。

还有什么我能帮上忙的，请告诉我！ ：微笑：

@MrMMorris如果你能提供一个复制器，就会为 Ubuntu 打开一个错误，我们将不胜感激： https :

@rsampaio如果我今天有时间，我一定会为您准备的！

此问题也出现在 Debian 7 和 Debian 8 的 3.16(.7) 上： https :

在使用内核 2.6.32-504.8.1.el6.x86_64 的 RHEL 6.6 上启动某些 docker 容器（并非所有容器）时看到此问题
_ kernel:unregister_netdevice : 等待 lo 空闲。 使用次数 = -1_

再次，重新启动服务器似乎是此时唯一的解决方案

在内核为 3.19.3 的 CoreOS (647.0.0) 上也看到了这一点。

重新启动也是我找到的唯一解决方案。

使用 sid 的内核 (4.0.2) 测试了 Debian jessie - 问题仍然存在。

有人在运行非 ubuntu 容器时看到此问题吗？

是的。 Debian 的。
19 июня 2015 19:01 пользователь“popsikle”通知@github.com
написал：

有人在运行非 ubuntu 容器时看到此问题吗？

—
直接回复此邮件或在 GitHub 上查看
https://github.com/docker/docker/issues/5618#issuecomment -113556862。

这是内核问题，而不是图像相关问题。 为另一个图像切换不会改善或使这个问题变得更糟。

在运行 4.1.2-bone12 内核的 BeagleBone Black 上遇到 Debian Jessie 问题

从4.1.2切换到4.2-rc2后的体验（使用1.8.0的git build）。
删除 /var/lib/docker/* 并不能解决问题。
切换回 4.1.2 即可解决问题。

此外，VirtualBox 也有同样的问题，并且有 v5.0.0（移植到 v4）的补丁，据说它在内核驱动程序部分做了一些事情......值得了解这个问题。

这是 VirtualBox 中的修复： https :
他们实际上并没有修改内核，只是修改了他们的内核模块。

4.2-rc2 也有这个问题：

unregister_netdevice：等待 vethf1738d3 成为免费。 使用次数 = 1

刚编译4.2-RC3，好像又可以用了

@nazar-pc 感谢您提供信息。 刚用 4.1.3 打了它，很不高兴
@techniq在这里相同，非常糟糕的内核错误。 我想知道我们是否应该报告它被反向移植到 4.1 树。

Linux docker13 3.19.0-22-generic #22-Ubuntu SMP Tue Jun 16 17:15:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

来自 Ubuntu 15.04 的内核，同样的问题

我也在 4.2-rc3 中看到了它。 没有一个关于设备泄漏的错误 :) 我可以在高负载下在任何 >=4.1 的内核上重现。

我也刚遇到这个问题。 Ubuntu 3.13.0-57-generic，通过 tutum 配置。 不幸的是，它填满了 kern.log 和 syslog 并使机器崩溃。 它发生在数据库机器上（dockerized postgres），所以它会关闭整个系统......

加入“我也是”的合唱团，我在运行 RancherOS（最小操作系统）0.3.3 的 cloudstack VM 上看到这个问题，同时从本地私有 docker 存储库中提取 docker 镜像。 它每十秒发生一次，不确定这是否意味着什么。

4.2-rc7 也有这个问题

关于这方面的任何消息，我们应该使用哪个内核？ 即使使用完全最新的内核（Ubuntu 14.04 上的 3.19.0-26），它也会不断发生

我们也遇到了这个问题。 这发生在我们配置 userland-proxy=false 之后。 我们正在使用一些监视器脚本，这些脚本会产生新的 docker 容器，每 1 分钟执行一次 nagios 插件命令。 我在进程树上看到的是它卡在 docker rm 命令上并且在 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

这是我们的系统信息

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

更新：虽然https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152说它已经在 2015-08-17 修复了。 因此，我尝试使用构建于 2015 年 9 月 2 日的内核 v3.19.8-ckt6-vivid 甚至构建于 2015 年 9 月 21 日的 v4.2.1-unstable 内核，但仍然存在问题。

我刚刚使用3.19.0-28-generic再次遇到了这个问题，所以最新的 ubuntu 内核并不安全

是的，似乎--userland-proxy=false现在不是使用旧内核的最佳选择:(

不。我为所有 3.19、4.0、4.2 内核版本尝试了 --userland-proxy=false，但问题仍然存在。

我正在使用没有 iptables (--iptables=false) 的用户空间代理，并且每天至少看到一次。 遗憾的是，唯一的解决方法是使用 SysRq 技术硬重置服务器的看门狗。

我的系统运行一些容器，这些容器是大量 stdout/err 编写器，正如其他人报告的那样，它可能会触发错误。

``````
$码头信息
货柜：15
图片：148
存储驱动：aufs
根目录：/var/lib/docker/aufs
后备文件系统：extfs
目录：178
支持 Dirperm1：true
执行驱动程序：native-0.2
日志驱动：json-file
内核版本：3.19.0-26-generic
操作系统：Ubuntu 14.04.3 LTS
CPU：12
总内存：62.89 GiB
姓名： * *
ID: 2 ALJ:YTUH : QCNX:FPEO :YBG4:ZTL4:2 EYK:AV7D :FN7C: IVNU:UWBL :YYZ5

$ docker 版本
客户端版本：1.7.0
客户端 API 版本：1.19
Go 版本（客户端）：go1.4.2
Git 提交（客户端）：0baf609
操作系统/Arch（客户端）：linux/amd64
服务器版本：1.7.0
服务器 API 版本：1.19
Go 版本（服务器）：go1.4.2
Git 提交（服务器）：0baf609
操作系统/Arch（服务器）：linux/amd64```
``````

不幸的是，我处于同样的情况，今天生产服务器因此错误而失败了 3 次，唯一的处理方法是使用一些神奇的 SysRq 命令。

撞

我仍然在使用内核 4.2.0 的最新 debian jessie 上看到这个

同样的问题在这里。 突然之间，我的三个 aws 服务器出现故障，日志大喊“unregister_netdevice：等待 lo 成为免费。使用计数 = 1”

Ubuntu：14.04
内核版本：3.13.0-63-generic
码头工人：1.7.1

系统日志

是否有可安全使用的内核版本？

Ubuntu 15.10 的内核 4.2 也会出现问题

发生在coreos：

图片：1174
存储驱动：overlay
后备文件系统：extfs
执行驱动程序：native-0.2
日志驱动：json-file
内核版本：4.1.7-coreos
操作系统：CoreOS 766.4.0

@killme2008 上次说的内核bug

您可能应该尝试将此补丁应用于内核http://www.spinics.net/lists/netdev/msg351337.html
数据包：packet_bind 中的竞争条件

或者在-stable树中等待backport； 它迟早会到来。

:+1: 好消息！

大家好，好消息！

自从我上次在这里发表评论（在撰写本文时，17 天前）以来，我再也没有遇到这些错误。 我的服务器（大约有 30 个）运行 ubuntu 14.04 和一些过时的软件包。

在完整的系统升级包括 docker-engine（从 1.7.1 到 1.8.3）+内核升级到 ubuntu 存储库上的最新可能版本后，我的服务器正在运行，没有发生任何事情。

:8 球:

今天也发生在我们的 3 个 AWS 实例上：

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

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

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

我在 Ubuntu 14.04 上遇到了同样的问题，所有软件包都是最新的和最新的linux-generic-lts-vivid内核：

$ 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

我也有最新的linux-image-generic (3.13.0-67-generic)。

在rancherOS上也有同样的问题。

Fedora 22 上仍在发生（更新）...
如果我重新启动 docker，我可以摆脱这些消息

systemctl 重启 docker
... 该消息再次出现约 3-4 次，然后停止

coreos 遇到了同样的错误：

coreos 版本：

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

码头工人版本：

 core@core-1-94 ~ $ docker 版本
客户端版本：1.7.1
客户端 API 版本：1.19
 Go 版本（客户端）：go1.4.2
 Git 提交（客户端）：df2f73d-dirty
操作系统/Arch（客户端）：linux/amd64
服务器版本：1.7.1
服务器 API 版本：1.19
 Go 版本（服务器）：go1.4.2
 Git 提交（服务器）：df2f73d-dirty
操作系统/Arch（服务器）：linux/amd64

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

系统日志：

 12 月 7 日 16:26:54 core-1-94 内核：unregister_netdevice：等待 veth775ea53 释放。 使用次数 = 1
 12 月 7 日 16:26:54 core-1-94 内核：unregister_netdevice：等待 lo 空闲。 使用次数 = 2
 Dec 07 16:26:55 core-1-94 sdnotify-proxy[1203]: I1207 08:26:55.930559 00001 vxlan.go:340] 忽略不计：4e:5c:47:2f:9a:84, .97.10
 12 月 7 日 16:26:59 core-1-94 dockerd[1269]: time="2015-12-07T16:26:59.448438648+08:00" level=info msg="GET /version"
 Dec 07 16:27:01 core-1-94 sdnotify-proxy[1203]: I1207 08:27:01.050588 00001 vxlan.go:340] 忽略不计：5a:b1:f7:e9:7d.d24, .34.8
 12 月 7 日 16:27:02 core-1-94 dockerd[1269]: time="2015-12-07T16:27:02.398020120+08:00" level=info msg="GET /version"
 12 月 7 日 16:27:02 core-1-94 dockerd[1269]: time="2015-12-07T16:27:02.398316249+08:00" level=info msg="GET /version"
 12 月 7 日 16:27:04 core-1-94 dockerd[1269]: time="2015-12-07T16:27:04.449317389+08:00" level=info msg="GET /version"
 12 月 7 日 16:27:04 core-1-94 内核：unregister_netdevice：等待 veth775ea53 释放。 使用次数 = 1
 12 月 7 日 16:27:04 core-1-94 内核：unregister_netdevice：等待 lo 变得空闲。 使用次数 = 2
 Dec 07 16:27:06 core-1-94 sdnotify-proxy[1203]: I1207 08:27:06.106573 00001 vxlan.go:340] 忽略不计：a6:38:ac:79:93:f24, 10 .47.24
 12 月 7 日 16:27:09 core-1-94 dockerd[1269]: time="2015-12-07T16:27:09.449944048+08:00" level=info msg="GET /version"
 Dec 07 16:27:11 core-1-94 sdnotify-proxy[1203]: I1207 08:27:11.162578 00001 vxlan.go:340] 无视错过：0e:f0:6f:f4:69:54, .71.24
 12 月 7 日 16:27:12 core-1-94 dockerd[1269]: time="2015-12-07T16:27:12.502991197+08:00" level=info msg="GET /version"
 12 月 7 日 16:27:12 core-1-94 dockerd[1269]: time="2015-12-07T16:27:12.503411160+08:00" level=info msg="GET /version"
 12 月 7 日 16:27:14 core-1-94 dockerd[1269]: time="2015-12-07T16:27:14.450646841+08:00" level=info msg="GET /version"
 12 月 7 日 16:27:14 core-1-94 内核：unregister_netdevice：等待 veth775ea53 释放。 使用次数 = 1
 12 月 7 日 16:27:14 core-1-94 内核：unregister_netdevice：等待 lo 变为空闲。 使用次数 = 2
 Dec 07 16:27:16 core-1-94 sdnotify-proxy[1203]: I1207 08:27:16.282556 00001 vxlan.go:340] 忽略不计：a6:62:77:31:ef:624, 10 .13.6
 12 月 7 日 16:27:19 core-1-94 dockerd[1269]: time="2015-12-07T16:27:19.451486277+08:00" level=info msg="GET /version"
 Dec 07 16:27:21 core-1-94 sdnotify-proxy[1203]: I1207 08:27:21.402559 00001 vxlan.go:340] 无视错过：92:c4:66:52:cd:24, 100 .24.7
 12 月 7 日 16:27:22 core-1-94 dockerd[1269]: time="2015-12-07T16:27:22.575446889+08:00" level=info msg="GET /version"
 12 月 7 日 16:27:22 core-1-94 dockerd[1269]: time="2015-12-07T16:27:22.575838302+08:00" level=info msg="GET /version"
 12 月 7 日 16:27:24 core-1-94 dockerd[1269]: time="2015-12-07T16:27:24.452320364+08:00" level=info msg="GET /version"
 12 月 7 日 16:27:24 core-1-94 内核：unregister_netdevice：等待 veth775ea53 释放。 使用次数 = 1
 12 月 7 日 16:27:24 core-1-94 内核：unregister_netdevice：等待 lo 变得空闲。 使用次数 = 2
 Dec 07 16:27:26 core-1-94 sdnotify-proxy[1203]: I1207 08:27:26.394569 00001 vxlan.go:340] 忽略不计：6a:f7:bf:ec:03:54, 11 .87.8
 12 月 7 日 16:27:29 core-1-94 dockerd[1269]: time="2015-12-07T16:27:29.453171649+08:00" level=info msg="GET /version"
 12 月 7 日 16:27:29 core-1-94 systemd[1]：开始生成 /run/coreos/motd...
 12 月 7 日 16:27:29 core-1-94 systemd[1]：开始生成 /run/coreos/motd。
 12 月 7 日 16:27:32 core-1-94 dockerd[1269]: time="2015-12-07T16:27:32.671592437+08:00" level=info msg="GET /version"
 12 月 7 日 16:27:32 core-1-94 dockerd[1269]: time="2015-12-07T16:27:32.671841436+08:00" level=info msg="GET /version"
 Dec 07 16:27:33 core-1-94 sdnotify-proxy[1203]: I1207 08:27:33.562534 00001 vxlan.go:340] 无视错过：22:b4:62:d6:25.b24, .68.8
 12 月 7 日 16:27:34 core-1-94 dockerd[1269]: time="2015-12-07T16:27:34.453953162+08:00" level=info msg="GET /version"
 12 月 7 日 16:27:34 core-1-94 内核：unregister_netdevice：等待 veth775ea53 释放。 使用次数 = 1
 12 月 7 日 16:27:35 core-1-94 内核：unregister_netdevice：等待 lo 变得空闲。 使用次数 = 2

生日快乐，该死的问题 =)
2014 年 5 月 6 日

同样的事情在这里。 刚重启。 最新的码头工人版本。 Ubuntu 14.04。

@samvignoli这已被确定为内核问题，因此不幸的是无法在 docker 中修复

@thaJeztah你有内核问题的错误跟踪器的链接吗？
或者也许是指向哪些内核受到影响的指针？

渴望在我们的环境中解决这个问题。

@Rucknar抱歉，我没有（也许这个讨论中有一个，我没有读回所有评论）

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

@Rucknar如果你滚动到顶部 - 你会看到补丁的链接http://www.spinics.net/lists/netdev/msg351337.html。 它现在在 linux master 中，我想它会转到 Linux 4.4，也许有人已经将它反向移植到以前的版本，但不确定。

谢谢大家，会看看升级需要什么。

FWIW 我将这里提到的最后一个补丁向后移植到 ubuntu 3.19，我也在 4.2 内核上进行了测试，但都没有成功。 此时即使在 4.4-rc3 net-next 分支上问题仍然存在。

@rsampaio你是如何测试的？ 实际上，我无法在任何内核上使用 docker 可靠地触发此故障。 它只是偶尔发生。

@fxposter我们也无法在生产环境之外重现该问题，因此我不得不在生产环境中使用修补过的内核启动一些实例，这种情况发生得如此频繁，以至于我可以在生产负载的 24 小时内找出内核是否受到影响。

有时我们会用一个非常不寻常的资源修复它：我们将容器目录从 /var/lib/docker/aufs/mnt

有了那个......也许我们可以'service docker restart'并将目录移回。

否则……只能重新启动。

@rsampaio你现在在谈论 heroku 生产吗？ 您如何避免这个问题，因为您的所有业务都是围绕容器/等构建的？

@rsampaio你使用--userland-proxy=false还是只使用大量创建的容器？ 我可以用--userland-proxy=false很容易地重现它，并且没有一些负载:)

@LK4D4我相信这只是大量创建/销毁的容器，特别是执行大量出站流量的容器，我们也使用 LXC 而不是 docker 但该错误与此处描述的错误完全相同，我可以尝试重现如果您的方法易于描述和/或不涉及生产负载，则使用您的方法，其想法是获取故障转储并_可能_找到有关究竟是什么触发此错误的更多提示。

@rsampaio我可以通过长期使用https://github.com/crosbymichael/docker-stress 进行复制

是否有任何更新/建议解决此问题？

@joshrendek这是一个内核错误。 看起来即使是新发布的内核 4.4 也没有修复它，所以某处至少还有一个竞争条件:)

内核错误

=)

@samvignoli你能保持你的评论有建设性吗？ 如果您有解决此问题的方法，请随时打开 PR。

这个错误是否已经在上游报告（内核邮件列表）？

肯定有过。 第一条评论也引用了这个错误： https :

自 2014 年以来开放。没有任何人对此发表评论，但只能说这很可能是应用程序使用不当。

感谢您的链接，贾斯汀！ 我会控制 Linus =)

亲切的问候。 =* ：心：

@samvignoli请不要这样做，它对任何人都没有帮助。
有人可以在一个小的 VM 映像中重现这个吗？
也许我可以用 gdb 和大量的 kprintf 弄脏我的手。

错误仍然打开。

操作系统：CentOS 7.2
内核：4.4.2 elrepo 内核-ml
码头工人：1.10.2
fs：overlayfs 和 xfs

日志：

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

此日志在运行 sameersbn/docker-gitlab docker image 时显示：

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

我可能只是走运了 - 但是在应用这些 sysctl 设置后，这种情况的发生率已经下降了。

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这些设置背后的动机是什么？

@kmike这是为了解决我们遇到的其他一些 conntrack 问题（ip 表已满）-尽管作为副作用，它似乎对我的原始问题做了一些事情

您能否显示之前/之后，以便我们可以看到实际发生了什么变化？ 您是否愿意对这些设置进行二分搜索，看看是否有更小的设置？

我在 Compute Engine VM 中使用 CoreOS Stable (899.13.0)。 每次我使用以下标志启动服务器时都会发生此错误0 （默认值）。 我来回测试了几次，在禁用 IPv6 的情况下，我可以启动节点中的所有容器而不会出现任何错误：

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

我使用 gcloud 容器从 GCR 下载，所以问题可能是 IPv6 + 下载 MB 图像 + 快速关闭容器。

Docker 版本供参考：

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

我也在这个问题中测试了以前的 sysctl 标志； 但有些已经具有该值，其余的似乎没有改变与此错误相关的任何内容：

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

当我设置 net.ipv6.conf.all.disable_ipv6=1 时，我仍然看到这个问题。

docker 压力工具很容易产生这个问题。
https://github.com/crosbymichael/docker-stress

这是我为上述工具构建的二进制文件。
https://storage.googleapis.com/donny/main
https://storage.googleapis.com/donny/stress.json

一旦我们看到日志“unregister_netdevice: waiting for veth6c3b8b0 to be free. Usage count”，docker就挂了。 我认为这是由 docker 触发的内核问题。 这只会在 docker userland-proxy 关闭时发生（--userland-proxy=false）。

我在启用和不启用用户空间代理的情况下都发生过这种情况，所以我不会只在它关闭时说。

可能会使情况变得更糟； 我知道我们曾经尝试将--userland-proxy=false设为默认值，但由于存在副作用而恢复原状https://github.com/docker/docker/issues/14856

从昨天开始，我也看到过一次错误，显然禁用 IPv6 不是解决办法； 但是如果没有标志，我什至无法在不破坏 docker 的情况下启动服务器的所有容器。

使用 kubernetes 1.2.2 和 docker 1.10.3 在 CoreOS 1010.1.0 上运行

Kubernetes 为 kubelet 添加了一个标志（在移动设备上，因此无法查找）用于
发夹模式。 将其更改为“混杂的桥梁”或任何有效的
价值是。 自从进行更改后，我们还没有看到此错误。

@bprashanh

请确认还是反驳？
2016 年 4 月 13 日下午 12:43，“Aaron Crickenberger”通知@github.com
写道：

使用 kubernetes 1.2.2 和 docker 在 CoreOS 1010.1.0 上运行
1.10.3

—
您收到此消息是因为您发表了评论。
直接回复此邮件或在 GitHub 上查看
https://github.com/docker/docker/issues/5618#issuecomment -209617342

在运行 Linux 4.4.5-15.26.amzn1.x86_64 和 Docker 版本 1.9.1 的 AWS 上获得这个，构建 a34a1d5/1.9.1。

带有 Alpine 映像的 Ruby 2.3.0 正在容器内运行，导致出现此问题

内核：[58551.548114] unregister_netdevice：等待 lo 变得空闲。 使用次数 = 1

有什么解决办法吗？

第一次在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上看到这个

几次重新启动修复了它。

@MrMMorris 已修复，因为您确定问题已

很明显，这是内核中的一场竞赛，失去了引用计数
某处。 这是一个很难追踪的错误，但据我们所知
仍然存在。

2016 年 5 月 2 日星期一晚上 10:52，Sune Keller通知@ github.com
写道：

@MrMMorris https://github.com/MrMMorris 已修复，因为您确定
问题已经消失了，或者你不会再遇到它
刚刚？ 可能是竞争条件...

—
您收到此消息是因为您发表了评论。
直接回复此邮件或在 GitHub 上查看
https://github.com/docker/docker/issues/5618#issuecomment -216444133

是的。 我尝试了内核 4.5 的 CoreOS 1032.0.0，但问题仍然存在。

昨天我在内核为 4.5.0 的 CoreOS 1010.1.0 上再次遇到这个问题，这是在几个容器快速连续启动和终止之后。

我有这个错误。

Docker 版本：1.9.1
内核版本：4.4.8-20.46.amzn1.x86_64
操作系统：Amazon Linux AMI 2016.03

@sirlatrom未修复。 再次看到这个😭需要多次重启才能解决。

当前运行 3.19.0-18-generic。 将尝试升级到最新版本

同样在这里！ :cry:: :cry:: :cry: :cry:: :cry: :cry:: :cry: :cry:: :cry: :cry: :cry: :cry: :cry:: ：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：。。。。。。。。。。。。。。。。。。。。。。哭: :cry: :cry:: :cry: :cry: :cry: :cry: :cry: :cry: :cry: :cry: :cry:: :cry:: :cry:: :cry: :cry:: :cry: :cry:: :cry: :cry:: :cry: :cry: :cry: :cry: :cry:: ：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：。。。。。。。。。。。。。。。。。。。。。。哭: :cry: :cry:: :cry: :cry: :cry: :cry: :cry: :cry: :cry: :cry: :cry:: :cry:: :cry:: :cry: :cry:: :cry: :cry:: :cry: :cry:: :cry: :cry: :cry: :cry: :cry:: ：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：：。。。。。。。。。。。。。。。。。。。。。。哭: :cry: :cry:: :cry: :cry: :cry: :cry: :cry: :cry: :cry: :cry: :cry:: :cry:: :cry:: :cry: :cry:: :cry: :cry:: :cry: :cry:: :cry: :cry: :cry: :cry: :cry:: : :cry: :cry:: :cry: :cry: :cry: :cry: :cry: :cry::

@samvignoli你的评论没有建设性。 请停止发帖。

抱歉，忘了点赞功能。

转载于 Fedora Server 23 - 4.2.5-300.fc23.x86_64。 无法重新启动 Docker 服务 - 只能重新启动节点。

Fedora 24 内核上的相同问题：4.5.2-302.fc24.x86_64。 没有导致任何挂起，但垃圾邮件日志文件。

@hapylestat你能试试systemctl restart docker吗？ 这让我觉得这一切都悬而未决。

谢谢

这经常发生在我的（CoreOS，EC2）机器上。 如果它有帮助，以下是此错误的一个实例中与卡住的 veth 设备相关的所有日志。

$ 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

当我一次删除许多容器时（在我的情况下，当我删除 k8s pods 时），这似乎会发生。

对于那些说重新启动修复它的人 - 你是重新启动还是停止/启动机器？ 在物理机器上，我不得不使用远程电源重置来让机器重新启动。

@joshrendek ，我不得不使用 iLO 的冷启动（即物理电源循环）。

@joshrendek我现在有一个脚本，它运行监视这个并在它发生时执行reboot -f 😢。

可能已经发现了问题（或者只是很幸运）。 我已将 Docker 图形目录从 XFS 分区磁盘移动到 EXT4 分区磁盘，但我无法重现该问题（以及解决了我遇到的其他 XFS 错误的负载）。 我记得@vbatts说还不支持 XFS。

我试图通过在各种图像的无限循环中运行build 、 run 、 stop 、 delete来激发，每个循环创建大约 10 个容器，用于最后几个小时。

@joedborg你在使用什么图形驱动程序？ 设备映射器？ 覆盖？

@thaJeztah好点，我应该提到这一点。 我正在使用带有（现在）EXT4 支持 FS 的 Overlay 驱动程序。

我曾经使用 devicemapper（因为我使用的是 Fedora Server），但我有很多痛苦（我相信很多人都会这样做），尤其是在泄漏时，一旦容器被删除，映射器就不会将空间返回到池中。

如果有帮助，我在 Docker 1.11.1 和内核 4.2.5-300.fc23.x86_64 上。

@joedborg很有趣，因为 RHEL 文档提到 RHEL/CentOS 7.1 仅支持 EXT4，而 RHEL/CentOS 7.2 仅支持 XFS。 我本来希望 XFS 可以在更新的版本上工作

@thaJeztah啊，这很奇怪。 我正在尝试考虑其他可能的事情。 我从顶部重新阅读，似乎有些人正在运行相同的配置。 唯一不同的是 XFS 磁盘是主轴，EXT4 是 SSD。 同时我会继续浸泡测试。 我也将 prod 转移到使用相同的设置，所以无论哪种方式，我们都会很快得到答案。 然而，它之前几乎每一个stop在做，所以它肯定更好。

@joedborg好吧，这确实是有用的信息

同样的错误，从内核 4.2 到 4.5，相同的 docker 版本。

顺便说一句，我同时在同一个机器上运行多个虚拟机。

$ 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

我在使用overlay图形驱动程序时遇到此问题，目录位于ext4 FS 上。 所以我不认为xfs是问题😢

@obeattie是的，似乎人们也在devicemapper上得到它。 触摸木头，自从切换以来，我再也没有遇到过这个问题。 如前所述，我也交换了物理磁盘。 这将是一个有趣的！

这个问题与文件系统没有任何关系。 我在 zfs、overlayfs、devicemapper、btrfs 和 aufs 中看到了这个问题。 也有或没有交换。 它甚至不仅限于 docker，我也遇到了 lxc 的相同错误。 我目前看到的唯一解决方法是不要同时停止容器。

如果有帮助，我会在 AWS AMI 支持的最新 ec2 实例上收到相同的错误消息。 docker 版本显示-

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

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

只是跳上船。 我在最新的 Amazon ec2 实例上看到了相同的行为。 一段时间后，容器会翻倒并变得无响应。

$码头信息
容器：2
图片：31
服务器版本：1.9.1
存储驱动：devicemapper
池名称：docker-202:1-263705-pool
池块大小：65.54 kB
基本设备大小：107.4 GB
后备文件系统：
数据文件：/dev/loop0
元数据文件：/dev/loop1
已用数据空间：1.199 GB
数据空间总计：107.4 GB
可用数据空间：5.754 GB
使用的元数据空间：2.335 MB
元数据空间总计：2.147 GB
可用元数据空间：2.145 GB
支持 Udev 同步：true
延迟删除已启用：false
延迟删除已启用：false
延迟删除的设备计数：0
数据循环文件：/var/lib/docker/devicemapper/devicemapper/data
元数据循环文件：/var/lib/docker/devicemapper/devicemapper/metadata
库版本：1.02.93-RHEL7 (2015-01-28)
执行驱动程序：native-0.2
日志驱动：json-file
内核版本：4.4.10-22.54.amzn1.x86_64
操作系统：Amazon Linux AMI 2016.03
CPU：1
总内存：995.4 MiB
名称：[已编辑]
ID: OB7A:Q6RX: ZRMK:4R5H : ZUQY:BBNK : BJNN:OWKS :FNU4:7NI2: AKRT:5SEP

$ docker 版本
客户：
版本：1.9.1
API 版本：1.21
转版本：go1.4.2
Git 提交：a34a1d5/1.9.1
内置：
操作系统/架构：linux/amd64

服务器：
版本：1.9.1
API 版本：1.21
转版本：go1.4.2
Git 提交：a34a1d5/1.9.1
内置：
操作系统/架构：linux/amd64

与上述评论相同，也在 EC2 上运行恰好是通过使用64bit Amazon Linux 2016.03 v2.1.0 running Docker 1.9.1弹性豆茎

目前有点轶事，但我最近尝试在大约 18 台服务器上将内核从 4.2.0 升级到 4.5.5 作为测试，并且这个问题变得相当糟糕（从几天减少到两次问题之间的时间不超过 4 小时）。

这是在 Debian 8 上

与@jonpaul和@g0ddard完全相同的设置

看看我们如何能够减轻这个错误。
第一件事（可能会也可能不会成功，这是有风险的）是在发生这种情况时保持 API 可用：#23178

你好。 我也被这个虫子咬了。。。

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

我在 CoreOS Beta、Flannel 上使用 Kubernetes 1.2.4 并在 Azure 上运行。 有什么方法可以帮助调试这个问题吗？ 内核错误线程似乎已死。 有些人报告说在内核上禁用 IPv6、使用--userland-proxy=true或使用 aufs 代替覆盖存储有帮助，而其他人则没有……这有点令人困惑。

像@justin8一样，我在将 Fedora 23 系统升级到内核 4.5.5 后也注意到了这一点； 问题仍然存在于内核 4.5.6。

当容器达到其内存限制时，我们遇到了这个错误。 不确定它是否相关。

同样的问题在这里

# 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
码头工人 1.10.3
同样的问题

我有一个“one liner”，它最终会在运行 CoreOS 1068.3.0 和 4.6.3 内核的 EC2 (m4.large) 上为我重现这个问题（非常新）。 对我来说，它需要大约 300 次迭代，但 YMMV。

Linux ip-172-31-58-11.ec2.internal 4.6.3-coreos #2 SMP Sat Jun 25 00:59:14 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz GenuineIntel GNU/Linux
CoreOS 测试版 (1068.3.0)
Docker 版本 1.10.3，构建 3cd164c

此处循环的几百次迭代最终将挂起 dockerd，内核将发出错误消息，例如

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

复制器循环是

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

编辑

• 我只能在userland-proxy=false时使用它进行复制
• 我无法使用 VirtualBox（到目前为止只有 ec2）进行复制，所以也许它也与虚拟机管理程序有关

上面@btalbot的脚本在经过数千次迭代后并没有在 Fedora 23 上为我重现该问题。

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

这个问题在我的 Kubernetes 集群上经常发生，但是我无法用压力器或@btalbot的一个衬垫可靠地重现它。 我尝试在两个装有 CoreOS 1068.3.0 的 Azure VM 上运行它。

第一个 VM 是 Standard_D1_v2（3.5GB 内存，1 核）——脚本进行了 3000 次以上的迭代。
第二个 VM 是 Standard_DS15_v2（140GB 内存，20 个内核） - 脚本执行了 > 7600 次迭代。

我已经更新了我之前的评论 (https://github.com/docker/docker/issues/5618#issuecomment-229545933) 以包括我只能在 userland-proxy=false 时重现这一点。

它在 EC2 t2.micro（单核）VM 以及 m4.large（多核）上都使用 HVM 为我重现。 还没有看到它发生在我的笔记本电脑上使用 VirtualBox，尽管无论用户空间代理的设置如何。

我们在 kubernetes 集群（使用 iptables 代理）上使用带有 hairpin-veth 的 Flannel 时遇到了这个错误。 只有当我们运行停止太多容器时才会发生此错误。 我们切换到使用 cbr0 桥接网络和混杂桥接发夹模式，再也看不到它了。
实际上，如果您使用 hairpin-veth，很容易重现此错误，只需使用 100 个带有 kubernetes 的容器即可开始这项工作。

在 01/07/2016 08:01，manoj0077 写道：

@btalbot https://github.com/btalbot所以在 1.12 我们可以重新启动
dockerd 不影响正在运行的容器。 所以 dockerd 会重启
在这种情况下有帮助吗？

AFAICT，1.12 的事件，docker 容器进程仍然是孩子
docker 守护进程。

@sercand你是如何设置混杂桥发夹模式的？ 我看不到来自 docker 的任何文档，或者他们使用了不同的名称

Docker 🐳 是否有一些官方消息可以说明何时可以查看？ 这是第二个评论最多的未决问题； 非常严重（需要重启主机）； 是可复制的； 我没有看到在确定根本原因或修复它方面有任何真正的进展😞。

这似乎最有可能是内核问题，但Bugzilla 上的票数已经停滞了几个月。 在那里发布我们的测试用例会有帮助吗？

@justin8我认为这些是 Kubelet 标志： --configure-cbr0和--hairpin-mode

@sercand我也用法兰绒。 使用--hairpin-mode=promiscuous-bridge有什么缺点吗？

@obeattie我同意。 :(

FTR 我设法在我设置的测试 Kubernetes 集群上使用@sercand的压力器作业复制了这个问题，它还使用了法兰绒和发夹式。

@sercand您能否详细说明开始使用promiscuous-bridge ？ 我将标志--configure-cbr0=true到节点的 kubelet 中，但它抱怨：
ConfigureCBR0 requested, but PodCIDR not set. Will not configure CBR0 right now 。 我以为这个PodCIDR应该来自master？ 谢谢。

编辑：似乎我需要将--allocate-node-cidrs=true --cluster-cidr=10.2.0.0/16到控制器管理器配置中，但由于我没有云提供商（Azure），路由可能无法工作。

@justin8我已经关注了这个文档。
文档中的@edevil发夹模式是为了“如果他们应该尝试访问自己的服务，这允许服务的端点将负载平衡回自己”。 顺便说一下，我的集群在 Azure 上运行，这不是一项容易实现的任务。

@sercand根据文档，如果我们在控制器管理器上使用--allocate-node-cidrs=true ，我们应该使用云提供商来设置路由。 由于没有用于 Azure 的 Kubernetes 云提供商，所以您没有问题吗？ 您是否手动设置路线？ 谢谢。

@edevil我使用 terraform 创建路线。 你可以在这个 repo找到它。 我很快就创建了这个配置并且只测试了一次。 我希望它足以提供其背后的基本逻辑。

@morvans @btalbot你有机会尝试 1.12 ...？

我可以确认远离 hairpin-veth 并使用 cbr0 网桥我无法再重现该问题。

以防万一：有人在裸机上遇到过这个问题吗？ 我们在 VMWare 实验室测试 Rancher 集群时已经看到了这一点，但从未在真正的裸机部署中看到过。

是的，这个问题发生在任何内核 >= 4.3 的裸机上。 已经在许多不同的机器和硬件配置上看到了这一点。 我们唯一的解决方案是使用内核 4.2。

它肯定仍然发生在 4.2 上，但它在任何更新的东西上更频繁地发生，我一直在测试每个主要版本以查看它是否更好，但还没有

也发生在 CoreOS alpha 1097.0.0 上。

内核：4.6.3
码头工人：1.11.2

我得到同样的问题。

码头工人：1.11.2
内核：4.4.8-boot2docker。

主机：在 OS X 上带有 VMWare Fusion 驱动程序的 Docker 机器。

任何建议的解决方法？

如果你们中的那些能够在可能发生故障转储的环境（也不是 EC2）中可靠地重现问题的人实际上可以共享此故障转储文件，那将会非常有帮助，可以在此处找到有关如何在 ubuntu trusty 中启用 kdump 的更多信息和这些是当 kdump 准备好生成故障转储时您需要启用的故障选项：

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

我遇到了同样的问题。

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

同样的问题：

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

Docker version: 1.10.3

刚刚发生在终端屏幕上：

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

系统是

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

同样的问题

Os: Amazon Linux AMI release 2016.03
Docker: 1.9.1

这里也是：

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

我在 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

（发生这种情况时，在我所有的 pty + 蜂鸣器上）
“简单地”Debian Jessie + 向后移植：

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

你好，

当我尝试通过创建破坏性的新图像在受控环境中复制问题时，我无法重现它。

在运行 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

到目前为止，我在并发模式下同时午餐 17753 容器并提高互联网流量，没有泄漏任何 veth* 接口。 有人可以粘贴说明以一致地重现问题吗？

@pegerto如果您有--userland-proxy=false并同时启动一堆容器，应该很容易触发。 我这样做使用https://github.com/crosbymichael/docker-stress

谢谢@cpuguy83

将守护进程配置为--userland-proxy=false我可以轻松重现该问题，谢谢，我们可以看到此问题影响了不运行此配置的守护进程。

我在 >=4.3 处的 netns 隔离引入的 netfilter 钩子处看到内核转储，有没有想过为什么当路由发生在 127/8 时问题看起来更糟？

谢谢

看到这个问题也是。 CoreOS 1068.8.0、Docker 1.10.3、内核 4.6.3。 如果有人感兴趣，我提取了一些系统日志。

刚收到多...
unregistered_netdevice: waiting for lo to become free. Usage count = 1
...在 2 个虚拟机和我的裸机笔记本电脑上，都运行 Ubuntu 16.04 和最新的内核 (4.4.0-3[456])。

结果是一切都挂了，需要硬重启。
上周之前没有经历过这种情况，我认为其中一个虚拟机在 1.11.3 上，而其他虚拟机都在 1.12.0 上。

@RRAlex这并不特定于任何
如果您在守护进程选项上使用--userland-proxy=false ......或者（据我所知）您正在使用 kubernetes，您可能会遇到这个问题。

原因是--userland-proxy=false选项在桥接接口上启用了发夹式 NAT……这也是 kubernetes 在为其容器设置网络时设置的内容。

在使用 Docker Cloud（和 Docker Cloud 代理）的 BYO 节点上看到这一点。

今天看到这个，在当前的 Amazon ECS AMI 上（大约 25 次尝试），运行 vanilla debian:jessie并使用 apt-get 更新，安装 pbzip2，然后运行它的命令（简单的多线程 CPU 测试）。

@edevil
在座的大多数人都描述了在使用 Docker 启动/停止容器时遇到这种情况，但我在 Debian 上没有 Docker 时遇到了完全相同的情况：

• Debian "Jessie"（= Debian 8.5 版），在裸机上（没有虚拟机，没有云，但是普通硬件）
• 内核 3.16.0-4-amd64
• 启动了 4 个 LXC 容器
• 使用“lxc-stop -n $containerName”关闭一个 LXC 容器
• 当这个命令完成时，内核或接口可能还没有完全“清理”，因为当我在之前的“lxc-stop”之后立即启动一个新的“lxc-stop”时，我有内核问题

除了硬重置机器外，无法恢复。

因此，请在您查明/解决此问题的调查中，不要只关注 Docker。 很明显，容器的快速停止/启动是一个通用问题，无论是通过 Docker 还是通过简单的“lxc”命令。

我认为这是linux内核的问题。

当我有 3 个 chroot（实际上是 pbuilder）以非常重的负载运行时，我遇到了这个问题。
我的硬件是龙芯 3A（一台 3.16 内核的 mips64el 机器）。

当我尝试 ssh 进入它时，我遇到了这个问题。

所以这个问题可能不仅与 docker 或 lxc 有关，甚至与 chroot 有关。

Docker 版本 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

裸机。

我们最近在使用内核 4.6.x 和 docker 1.11.2 的裸机（专用于 ovh）上遇到了问题。
在阅读了这里的评论并尝试了多种解决方法后，我们将内核降级到 3.14 分支的最新版本（3.14.74）并将 docker 升级到 1.12.0 以避免https://github.com/docker/libnetwork/issues/1189现在一切似乎都很好。

我希望这会有所帮助。

所有，我认为你不需要再发布关于 Docker 或 chroot 的消息，这都是关于 Linux 内核的。
所以请有人站出来，以某种方式调试内核，在禁用容器的虚拟网络接口的部分？ 在请求容器的新停止之前，当容器的先前停止尚未完全禁用/清理其虚拟接口时，可能会发生一些竞争条件。

@rdelangh我认为这个问题不一定与内核有关。

在 Fedora 24 上，我无法从 Fedora 存储库中重现 Docker 1.10.3 的问题，只能使用来自 Docker 自己的存储库的 Docker 1.12.1。

两项测试均使用内核 4.6.7-300.fc24.x86_64 进行。

在 CoreOS 1068.10.0、Docker 1.10.3、内核 4.6.3 上也看到了这个问题。

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

在 EC2 上稳定的 CoreOS 1068.9.0 上使用 Kubernetes 1.3.4，docker 1.10.3 我看到了这个问题。

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

在 Ubuntu 16.04、Docker 1.12.1、内核 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

对于使用 Kubernetes <= 1.3.4 的用户，您可以利用此问题： https :

从那里你可以创建 2 个 ReplicationControllers，我称它们hello和hello1基于这个： http :

然后，根据以下内容创建 2 个与上述名称/标签匹配的部署： http :

_一旦创建部署，您就会得到大量垃圾邮件容器_。

如果你让它保持一段时间（几分钟），你会看到很多试图终止/创建的东西。 您可以删除部署并让事情稳定下来。 您应该会看到一些 Termination 和 ContainerCreating。 如果您通过 ssh 进入节点，请检查dmesg和docker ps以查看上述症状是否明显。

在我的例子中，我花了大约 5 分钟的时间才看到这个问题。 我计划进行@sercand和@edevil正在玩弄的更改，看看在这种情况下这是否适合我。

@edevil在查看您的链接提交后，我是否更正您在您的环境中完全禁用/删除 Flannel 以支持 Kubernetes 创建的cbro桥来解决此问题？

我看到我最后你不能同时使用它们，因为法兰绒想要使用docker0而你的内部网络将使用cbr0正确吗？

@alph486 没错，我不再使用法兰绒了。 我使用网桥并为 pod 网络设置路由。

@alph486法兰绒不想使用 docker0。 它只是 docker 的默认桥接器，您可以使用--bridge=cbr0 docker 选项覆盖它。
在 CoreOS 上，您必须覆盖 docker systemd 单元。

Kubelet 标志--experimental-flannel-overlay可以读取 flannel 配置，并使用 flannel CIDR 配置 docker 网桥cbr0 。

它还将启用promiscuous模式而不是veth-hairpin ，这似乎是问题所在。

感谢@dadux的输入。 如果 K8s 将选择已被覆盖单元引导的cbr0接口，则可以使用该解决方案； 我会试试看。

根据文档， promiscuous-bridge似乎是 kubelet v1.3.4+ 中--hairpin-mode的默认值。 我仍然看到这个问题，所以我不完全确定这就是整个解决方案。

使用kubenet网络插件（设置为替换--configure-cbr0 ）后，我无法再次重现该问题。 由于其未来的不确定性，我有点避免使用flannel-overlay选项（它似乎与--configure-cbr0 ）。

如果您的 docker 守护进程使用docker0网桥，则设置--hairpin-mode=promiscuous-bridge将无效，因为 kubelet 将尝试配置不存在的网桥cbr0 。

对于 CoreOS，我的解决方法是镜像 Kubernetes 行为但仍使用 flannel ：

• 为 docker.service 添加 systemd 插件以将桥docker0接口配置为混杂模式。 （当然有更优雅的想要这样做吗？）：

- 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

• 告诉 kubelet 不要在 docker 桥中设置 hairpin：
  kubelet --hairpin-mode=none

您可以检查是否为您的接口启用了发夹
brctl showstp docker0
或者
for f in /sys/devices/virtual/net/*/brport/hairpin_mode; do cat $f; done

我想我的同事最近已经修复了这个http://www.spinics.net/lists/netdev/msg393441.html ，我们在我们的环境中遇到了这个问题，然后我们发现了问题，有了这个修复，我们从来没有遇到过这个问题任何更多的。 遇到此问题的任何人都可以尝试此补丁，看看是否再次发生。 并且根据我们的分析，它与ipv6有关，因此您也可以尝试在启动docker daemon时使用--ipv6=false禁用docker的ipv6

@coolljt0725也许我错了，但是

@dadux感谢您的帮助。 在 Kubernetes 1.3.4 CoreOS 1068 Stable、Docker 10.3、Flannel 作为网络层上，我通过在我的 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

将以下内容添加到kubelet.service ：

        --hairpin-mode=none

Docker/Kubernetes 上的这些变化对 O/S 如何处理容器接口有什么影响？
我必须强调，这是 O/S 行为错误的问题，而不是 Docker 或 Kubernetes，因为我们（以及该线程中的其他一些人）根本没有运行 Docker 或 Kubernetes，但在停止 LXC 时仍然遇到完全相同的情况一个接一个的容器很快。

@rdelangh你是对的。 但是，这个问题是在 Docker 项目中创建的，用于跟踪与 Docker 相关的行为。 该线程中提到了其他问题，将其跟踪为操作系统问题、K8s 问题和 CoreOS 问题。 如果您在 LXC 或其他东西中发现了问题，强烈建议您在那里开始一个线程并在此处链接以提高对该问题的认识。

当那些使用 Docker google 解决这个错误时，他们很可能会在这里登陆。 因此，我们在这里发布此问题的解决方法是有道理的，以便在解决根本问题之前，人们可以继续前进。

Docker/Kubernetes 上的这些变化对 O/S 如何处理容器接口有什么影响？

1. 我帖子中的 docker 更改允许 Kubernetes 堆栈询问 docker 并确保在出现问题时平台是健康的。
2. hairpin-mode变化本质上是告诉 K8s 按原样使用docker0网桥，因此不会尝试使用“内核土地”网络和“发夹式网络”，这是 Docker 中问题开始的地方执行路径。

这是使用 K8s 和 Docker 解决此问题的方法。

coolljt0725 同事的补丁已经在排队等待稳定，所以希望它很快就会被移植到发行版中。 （大卫米勒的帖子：http://www.spinics.net/lists/netdev/msg393688.html）

不知道提交在哪里，我们是否应该将它发送到 Ubuntu、RH 等以帮助他们跟踪和向后移植它？

我想在某个时候会出现在这里：
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/ipv6/addrconf.c

编辑：似乎出现在这里： https :

感谢coolljt0725 和co（以及此线程中的每个人）。 由于许多人在一段时间内无法使用 ipv6 补丁更新内核，（目前每个人）在尝试了该线程中的许多建议后，我已经设法解决了这个错误。 我想发表一个完整的帖子来跟进那些有效和无效的事情，这样其他人就不必看到我看到的麻烦。

TL;DR 在 linux 启动参数中禁用 ipv6，重新启动。 在 coreos 上，这意味着/usr/share/oem/grub.cfg具有以下内容： set linux_append="ipv6.disable=1"然后重新启动。 可以在此处找到适用于 centos/ubuntu/debian/$linuxes 的更通用的建议

• 尝试过 ipvlan(l2,l3)/macvlan(bridge)：这些都没有在 aws 上工作，或者至少，我不拥有也找不到知识来让他们中的任何一个在 aws 上工作。 通过工作，我的意思是，使用 ipvlan 或 macvlan 启动连接到网络上的容器，无法 ping 网关/连接到互联网（是的，我测试了在非 aws 环境中工作的基本想法）。 这实际上似乎解决了手头的问题，但对于我们的用例，我们需要能够连接到互联网——对于没有连接到互联网的用例，这可能是一个可行的选择，并且与桥相比看起来非常性感.
• 尝试将以下标志单独传递给dockerd并使用某些组合（因为它们似乎都不起作用，我对尝试任何和所有组合都不太科学）：

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

有趣的是， --ipv6=false似乎并没有真正做任何事情——这很令人困惑，容器仍然收到带有这个标志的 inet6 地址。

--userland-proxy=false设置了发夹模式，预计不会真正起作用。 与此相结合，我有一些希望，但这也没有解决问题（将 docker0 设置为 promisc 模式）。 有一个修复程序的提--userland-proxy=false这里，这可能很快就会上行，值得一杆，这将是很好关闭这个功能，无论在这个问题上的表现指出错误的，但不幸的是它还有另一个这个时候的bug。

• 尝试通过此处记录的 sysctl 设置禁用 ipv6 并在应用 sysctl 设置后重新启动 systemd-networkd，以及尝试从此处记录的 dhcpcd 禁用 ipv6 并且这不足以禁用 ipv6，因为它仍然打开，即使没有接口使用它。
• 正如这里所建议的

太长; 确实读过：在您的 grub 设置中禁用 ipv6。 重启。 利润。

在 CentOS 7.2 (3.10.0-327.28.3.el7.x86_64) 和 Docker 1.12.1 (w/o k8s) 上遇到了这个问题。 当网络流量增加时就会出现问题。
在禁用 ipv6 的情况下引导内核（根据之前的建议）没有帮助。
但是将 docker0 接口变成 promisc 模式已经解决了这个问题。 @dadux使用的 systemd

@rdallman通过 grub 停用 ipv6 不会阻止我在 ubuntu 16.06（内核 4.4.0-36-generic）或 14.04（内核 3.13.0-95-generic）中使用unregister_netdevice 。 无论--userland-proxy设置如何（真或假）。

哦哦，那个补丁排队等待稳定很酷。
ping @aboch解决--ipv6=false什么都不做的问题。

@trifle抱歉 :( 感谢您发布信息，经过几天的测试，我们还没有遇到问题，但如果遇到任何问题，我们会更新。我们正在运行 coreos 1122.2（内核 4.7.0）。将 docker0 设置为 promisc 模式似乎为某些人解决了这个问题（我们不走运）。

@RRAlex你知道是否有人就向后移植的问题联系过 Ubuntu 内核团队吗？ 我们在受该错误影响的 Ubuntu 集群上部署了大型生产 Docker。

Ubuntu 内核团队邮件列表：
https://lists.ubuntu.com/archives/kernel-team/2016-September/thread.html

稳定内核的补丁：
https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d

Ubuntu内核提交日志：
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/?h=master-next
（补丁还没有）

@leonsp我尝试就似乎相关的问题与他们联系：
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1403152

如果您查看最后 (#79) 的回复，就会发现有人使用该补丁为 Xenial 构建了内核：
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1403152

不知道它什么时候进入主 Ubuntu 内核树，也不知道这个人与 Ubuntu 有什么关系，如果这会有所帮助......

我也无法在 Ubuntu 内核提交日志中找到该线程中提到的提交。

@RRAlex提到的提交是在 ddstreet 的分支 ~ddstreet/+git/ linux:lp1403152-xenial 上，这里是日志： https ://code.launchpad.net/~ddstreet/+git/linux/+ref/lp1403152-xenial
因此，任何在 Ubuntu 16.04 上遇到此问题的人都可以尝试一下。 https://launchpad.net/~ddstreet/+archive/ubuntu/lp1403152

可能@sforshee知道（对于 Ubuntu 内核）

我终于设法测试了“ipv6.disable=1”解决方案。 除此之外 - 我已经在我的 debian 8 上升级到 4.7.2 内核。
在内核升级并在内核参数中启用“ipv6.disable=1”后，即使没有 docker 守护程序的“--userland-proxy=false”标志，我也设法在实际工作负载中捕获“等待 lo”问题。 好消息是，在指定“--userland-proxy=false”并尝试使用“docker-stress”重现问题后，我无法再这样做了。 但我很确定无论“--userland-proxy”值如何，它都会再次出现。
所以从我看来 - ipv6 肯定涉及到这个问题，因为现在 docker-stress 不再能够捕捉到这个问题。 坏消息是问题实际上仍然存在（即：它只是部分修复）。

稍后会编译最新的 4.8rc7 进行更多测试。

@twang2218 @coolljt0725

嗯..所以我只是尝试了 Ubuntu xenial 4.4.0-36 内核和从ddstreet 的 ppa向后移植的补丁：

$ 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

不幸的是，这似乎并不能解决我的问题。 请注意，我也在使用“ipv6.disable=1”运行。 我们是否正在研究具有相同结果的多个不相关的原因？ 该线程中的许多评论似乎都表明了这一点。

我对这些不太了解，但我知道我们以前有过这样的错误。 据我了解，当清理网络命名空间时，对任何网络设备的引用计数最终都会转移到 lo，因此“等待 lo 变得可用”意味着某些网络设备存在引用计数泄漏，但不一定适用于 lo直接地。 这使得它们难以追踪，因为当您知道存在泄漏时，您不知道它与哪个设备相关联。

我还没有读完所有的评论，但如果有人可以在 Ubuntu 上给我一个可靠的复制器，我会看看它，看看我是否能想出什么。

@sforshee复制并不总是那么容易，但是创建了一个补丁（至少修复了这里报告的一些情况）； http://www.spinics.net/lists/netdev/msg393441.html。 上游接受了https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d

@thaJeztah啊，我明白你现在正在指导我的问题。

因此，该补丁位于上游 4.4 稳定队列中，对于 16.04，它可能不会包含在下一个内核 SRU（已经在进行中）中，而是包含在之后的内核 SRU 中，大约 5-6 周后。 如果 14.04 也需要它，请告诉我，以便它可以向后移植。

@sforshee基本上更早（在那个补丁之前），可以通过在内核中启用 ipv6（通常默认启用）来复制，将“--userland-proxy=false”添加到 docker 守护进程标志然后运行docker-stress -c 100 ，对于示例（docker-stress 来自这里：https://github.com/crosbymichael/docker-stress）

@fxposter谢谢。 如果有一个修复程序，尽管我真正需要担心的是将该修复程序添加到 Ubuntu 内核中。 我还可以帮助查看该补丁未修复的其他泄漏。

我也有这个问题。 我在 AWS 的 rancherOS 盒子内运行 docker。 实际上，它是在建立一个牧场主集群（3 台主机）并在其中运行一个小应用程序后随机发生的。

同样...... Fedora 24，随机发生，一周都可以，比我每 10 小时一次
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

在 CentOS 7 上运行内核 3.10.0-327.36.1.el7 和 docker 1.12.1 的体验

降级到内核 3.10.0-327.18.2.el7 而保留在 docker 1.12.1 上，似乎已经稳定了系统。

我也看到了这个：
Docker 版本 1.11.2
Ubuntu 16.04.1 4.4.0-38-通用

禁用 ipv6 (grub)

在带有内核 4.8.0-rc7 的服务器上没有--userland-proxy=false （原文如此！）的情况下遇到了这个问题，其中包括 ipv6 补丁（原文如此！！）。 所以也许它可以解决一些问题，但不是全部，当然。

有谁知道如何调试？

我们发现这只会在我们（几乎）耗尽可用内存时发生在我们的设置中。

@fxposter找到最小的复制案例会很有用，这有点困难：/然后我们可以使用 ftrace 至少找到代码路径。

发生在 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不幸的是，不再可能通过 docker-stress 重现它（至少我不能）。 我将尝试使用 webkits 模仿我们之前的设置（这比我想要的更频繁地触发这个问题）。

@fxposter那个补丁只解决了一些问题（但在我们的环境中，我们再也不会遇到那个补丁了），不是全部，我会让我的同事继续调查这个问题。 如果您有任何方法可以重现此内容，请告诉我，谢谢:)

修复在 4.4.22 稳定https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.22

我发布了一个要求 Redhat 将此补丁应用到 Fedora 24 的请求。

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

4.4.0-42 肯定还是坏了...
我在这里为 Ubuntu 提到了它，但也许有人有更好的主意：
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1403152

我也看到了这个，Docker 版本 1.11.2，构建 b9f10c9/1.11.2，64 位 Amazon Linux 2016.03 v2.1.6。

还是发生了。 docker 1.12.2，armbian linux 内核 4.8.4，引导参数中的 ipv6.disable=1

怎么修复bug，我天天遇到

@woshihaoren不要使用--userland-proxy=false

澄清一下 - 我们也遇到了禁用用户空间代理的情况

在 Amazon Linux AMI 2016.9 上获取此信息：

$ uname -a

Linux 4.4.23-31.54.amzn1.x86_64 #1 SMP

码头工人版本：

``` 客户端：
版本：1.11.2
API 版本：1.23
转版本：go1.5.3
Git 提交：b9f10c9/1.11.2
内置：
操作系统/架构：linux/amd64

服务器：
版本：1.11.2
API 版本：1.23
转版本：go1.5.3
Git 提交：b9f10c9/1.11.2
内置：
操作系统/架构：linux/amd64
``

centos7内核4.4.30又来了~~~~

CoreOS 1185.3.0、4.7.3-coreos-r2、Docker 1.11.2
只需运行 10..20 debian:jessie容器并使用“apt-get update”作为命令即可重现。

CoreOS 稳定版目前仍然受到打击。 4.7 系列的修复在 4.7.5： https :

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 - 这篇文章中没有解决方案，但我确实列出了迄今为止我所追求的内容以及我目前的工作理论。 我希望其他也在追求这个的人可能会在这里找到一些有用的信息，因为我们正在处理这个问题。

@koendc感谢您发布引入 4.7.5 的补丁。 我将 4e1b3aa898ea93ec10e48c06f0e511de37c35b2d（上游 751eb6b6042a596b0080967c1a529a9fe98dac1d）补丁移植到了我的 4.5.5

我根据测试确认的其他事情：

• 4.2 比任何后来的内核都稳定得多
• 4.5.x 是可重复的。 在我广泛测试的较新内核（4.8.2 和 4.8.6）中，问题仍然存在，尽管第一次出现的时间从 60 秒到 48 小时不等
• 该问题似乎与网络流量和容器与父资源 (virt cpu) 容量的比率有关。 正如其他人所逃避的那样，如果这确实是一种竞争条件，这可能是一个红鲱鱼

下一步：

• 使用适当的 printk 语句检测内核以尝试查找未释放已分配资源的情况
• 测试 4.7.5 或更高版本的内核有/没有上述补丁，看看是否出现问题
• 就在其中一次崩溃之前，我看到了一组非常有趣的IPv6: eth0: IPv6 duplicate address <blah> detected错误。 可能是另一个红鲱鱼，但我想尝试禁用 ipv6 以查看是否存在相关性

[1] 我的完整设置是运行基于4.5.5的稍微定制的 debian 内核的 GCE virt。 Docker version 1.8.3, build f4bf5c7正在运行
[2] 测试用例信息：我有 20 个并行进程，每个进程在 docker 容器内启动一个 Node.js hello world服务器。 Node.js 服务器不返回hello world ，而是返回 1 MB 的随机文本。 父进程处于一个紧密循环中，它启动容器，卷曲以检索 1MB 数据，然后停止容器。 使用此设置，我可以在 4-90 秒内始终如一地重现该问题。 在物理主机上或在 virtualbox 内部使用相同的设置不会重现问题，尽管不同的项目会改变 GCE box 上的平均重现时间。 我一直在玩的变量：并发测试进程的数量、传输的有效负载大小和 curl 调用的数量。 前两个变量肯定是相关的，尽管我认为它可能只是调整变量以找到合理的 virt 饱和点。

我也有这个错误。

部署容器后，我看到它重复了 3 次。

描述

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

重现问题的步骤：

1. ssh 进入 docker 主机
2. 运行一个容器

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

描述您收到的结果：

只需将错误重复 3 次即可。

描述您期望的结果：
没有错误

您认为重要的其他信息（例如问题仅偶尔发生）：
这个周末之后才开始发生。

docker version ：

 docker --version
Docker version 1.12.3, build 6b644ec

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

其他环境详细信息（AWS、VirtualBox、物理等）：

虚拟机：
软呢帽 24
ext3 上的 OverlayFS2

分配给 docker 的单独驱动器使用 24 个演出。
16 演出公羊。

码头工人

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

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

免费-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

对于任何感兴趣的人，我们 (Travis CI) 将在 Ubuntu 14.04 上升级到v4.8.7 。 我们的负载测试显示没有发生此处描述的错误。 以前，我们在 Ubuntu 14.04 上运行linux-image-generic-lts-xenial 。 我计划在不久的将来发表一篇博客文章，描述更多细节。

更新：我应该提到我们正在运行这个 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

更新：我们_仍然_在 Ubuntu Trusty + 内核 v4.8.7 的生产环境中看到这个错误。 我们还不知道为什么这些错误在之前重现错误的暂存负载测试中消失了，但生产中的错误率实际上是相同的。 步步高升。 鉴于实例周转率很高，我们基于此错误禁用了“自动内爆”。

也在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

在 Debian 测试中使用 DigitalOcean VPS 也发生了同样的事情：

# 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

系统

$ 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

在过去的 4 天里，我一直在一个紧密的循环中测试4.8.8 （参见我之前对测试用例的评论中的 [2]）。 到现在为止还挺好。

事实

• 补丁 751eb6b6显着减少了此问题的发生，但并未完全消除它。

假设
@meatballhat指出他们的生产服务器在运行 4.8.7 时遇到了问题。 这给我们留下了两种可能性：

• 我的测试用例有问题（可能性更大）
• 4.8.8 引入了一个修复。 查看4.8.8 更新日志，提交 5086cadf 和 6fff1319 都提到了已解决的 netdev 问题。 两者都没有明确指出这里的问题，但两者都足够接近以致令人怀疑。

我们可以让一些人尝试 4.8.8 看看他们是否能够重现这个问题吗？

@reshen我会让我们更新到 4.8.8 并报告：+1：非常感谢您的研究！

@reshen出色的研究。 到目前为止，我还无法在 Xubuntu 16.04 上使用 Linux 4.8.8 重现该问题。

我一直在使用Ubuntu 主线内核构建。 我没有明确定义的测试用例，但我可以通过启动和停止我使用的一组 docker 容器来一致地重现该问题。

测试 Linux 4.8.8 对我来说最简单的是从 aufs 切换到 overlay2 作为存储驱动程序，因为主线内核构建不包括 aufs。 我认为不会影响测试，但应该注意。

过去我用 Dan Streetman 向后移植的 751eb6b6 测试了 Linux 4.4.4，这似乎并没有减少我的问题。 看看是否也向后移植您提到的两个补丁（5086cadf 和 6fff1319）是否可以给出与 4.4.8 相同的结果会很有趣。

带有 4.4.0-47 的 Ubuntu 16.04 仍然受到影响……现在尝试 4.4.0-49，稍后会报告。

编辑：2016-11-28：-49 显示 dmesg 中的日志行。

在 Fedora 25（内核 4.8.8）和 Docker 1.12.3 上体验过这个

仅供参考：我们一直在单个生产主机上运行 Linux 4.8.8 和 Docker v1.12.3。 目前正常运行时间为 5.5 天，机器保持稳定。

我们偶尔会在 syslog 中看到一些unregister_netdevice: waiting for lo to become free. Usage count = 1消息，但与以前不同的是，内核不会崩溃并且消息消失。 我怀疑内核或 Docker 中引入的其他更改之一检测到这种情况，现在可以从中恢复。 对我们来说，这现在使这条消息很烦人，但不再是一个严重的错误。

我希望其他一些人可以在他们的生产车队上确认上述内容。

@gtirloni - 你能澄清一下你的 4.8.8/1.12.3 机器是崩溃还是刚刚看到消息？

提前感谢所有一直致力于复制/提供有用信息以对这件事进行三角测量的人。

我们在启动 docker 后删除 veth 接口（docker0）的对应部分，然后在我们使用 ansible 配置主机时重新启动 docker。 从那以后就没有出现问题。

我也在使用 Docker 运行 Raspbian 的 Raspberry Pi 2 上遇到同样的错误。

内核信息
Linux rpi2 4.4.32-v7+ #924 SMP Tue Nov 15 18:11:28 GMT 2016 armv7l GNU/Linux

码头工人信息

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

它发生在创建一个需要安装大约 50Mb 下载程序的容器之后。

只有重新启动才能让我再次使用机器

我实际上在 ECS 集群中的 Amazon Linux 上看到了这一点 - 消息偶尔会抛出，但并没有锁定，就像 rehen 现在看到的那样。 码头工人 1.11.2。 Uname 报告版本为“4.4.14-24.50.amzn1.x86_64”。

@reshen我将在本周末在我的笔记本电脑上构建 4.8.8，看看是否
帮我修好了！
ᐧ

2016 年 12 月 1 日星期四上午 10:29，Ernest Mueller通知@github.com
写道：

我实际上在 ECS 集群中的 Amazon Linux 上看到了这个消息 - 消息
偶尔会抛出但它不会锁定，就像现在rehen看到的那样。
码头工人 1.11.2。 Uname 报告版本为“4.4.14-24.50.amzn1.x86_64”。

—
您收到此消息是因为您订阅了此线程。
直接回复本邮件，在GitHub上查看
https://github.com/docker/docker/issues/5618#issuecomment-264220432或静音
线程
https://github.com/notifications/unsubscribe-auth/AKklVRqoBUZDu3HMhGv3b6knnA6j6C_Qks5rDvXRgaJpZM4B4L4Z
.

——
基弗·弗兹兰
http://kfrz.work

我还能够在运行 CoreOS Stable 1185.3.0 的 Kubernetes 工作节点上使用https://github.com/crosbymichael/docker-stress重现此问题。

运行docker_stress_linux_amd64 -k 3s -c 5 --containers 1000 ：5 个并发工作人员创建/删除容器，容器的最大生命周期 = 3 秒，在 AWS 上的 m4.large 实例上创建最多 1000 个容器将在大约三分钟后使 Docker 守护进程无响应。

升级到 CoreOS Beta 1235.1.0 并且我无法重现（无响应或内核日志中的unregister_netdevice消息）。 虽然运行 5 个并发 docker_stress 工作人员会在几分钟后杀死 CoreOS Stable，但我能够使用 10 和 15 个并发工作人员运行，直到使用 CoreOS Beta 完成测试。

CoreOS 在“通道”中发布，因此不可能单独升级内核。 以下是稳定版和测试版之间的主要区别：

CoreOS 稳定版 1185.3.0

内核：4.7.3

码头工人：1.11.2

CoreOS 测试版 1235.1.0

内核：4.8.6

码头工人：1.12.3

在运行 4.4.23-31.54.amzn1.x86_64 的 Amazon Elastic Beanstalk 上看到此问题

刚发生在 CoreOS Stable 1185.5.0, Docker 1.12.2
重启后一切正常

更新：在运行 CoreOS Beta 1235.1.0、Docker v1.12.3 和 Linux 内核 v4.8.6 的主机上，挂起的 Docker 守护进程问题再次出现。 😢

1.12.4 和 1.13 理论上应该不会在遇到此内核问题时冻结。
docker 守护进程发生冻结的原因是守护进程正在等待从内核返回的 netlink 消息（永远不会到来），同时持有容器对象的锁。

1.12.4 和 1.13 对此 netlink 请求设置了超时时间，以至少释放容器锁。
这确实__not__解决了问题，但至少（希望）不会冻结整个守护进程。
您可能无法启动新容器，同样可能无法拆除它们，因为一旦遇到此问题，与 netlink 的所有交互似乎都会停止。

@cpuguy83 FWIW，当守护进程挂起时，任何正在运行的容器都会继续运行而不会出现 AFAIK 问题。 事实上，容器的启动和停止是值得注意的（尤其是在 Kubernetes 上运行，就像我们一样）。

这并不能解决问题，但至少（希望）不会冻结整个守护进程。

整个守护进程被冻结的一个好处是很容易弄清楚。 Kubernetes 可以驱逐节点，甚至可以自动重启。 如果守护进程继续运行，是否仍然可以轻松找到内核问题的出现？

@seanknox我可以为您提供带有修补 Docker 的自定义 CoreOS 1248.1.0 AMI（CoreOS Docker 1.12.3 + Upstream 1.12.4-rc1 补丁）。 它每隔几个小时就会在我的 CoreOS/K8s 集群上修复一次挂断。 只需在 Deis Slack 上使用您的 AWS 账户 ID ping 我即可。

我们在 CoreOS 集群上遇到了这个问题。 谁能告诉它什么时候最终修复？ 我们梦想着晚上可以入睡的这一刻。

@DenisIzmaylov如果你没有设置--userland-proxy=false ，那么通常你不应该遇到这个问题。

但除此之外，这是内核中的一个错误，可能是多个内核错误，有人说在 4.8 中解决了，而其他人说没有。 对于某些人来说，禁用 ipv6 似乎可以解决它，而其他人则不能（因此这可能是多个问题……或者至少是多个原因）。

我已经在有和没有--userland-proxy=false高负载系统上几个小时内看到了这个问题

确认我们仍然在内核4.8.12上看到unregister_netdevice错误。 大约需要 5 天才能触发。 似乎只有重新启动系统才能从问题中恢复。 停止 Docker 似乎无限期地挂起。

尚未尝试禁用内核启动的 ipv6 技巧。

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

如果有人可以在 1.12.5 中尝试这个会很棒，它现在应该在卡住的 netlink 请求上超时，而不仅仅是挂起 Docker。

@cpuguy83但是，系统在该状态下仍然无法使用 :)

@LK4D4哦，完全，只是想看看那些超时;)

在 Cent OS 7 上遇到此问题：

kernel:unregister_netdevice : 等待 lo 空闲。 使用次数 = 1

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

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

这会影响我在 Docker 容器内运行的 CI 构建，并且在出现此控制台消息期间似乎突然死亡。 是否有修复或解决方法？ 谢谢！

@ cpuguy83发生此错误时，Docker 不会挂起，但容器被杀死，这在我的情况下破坏了我的 Jenkins/CI 作业。

所以我一直在 centos 7 机器上运行 docker 一段时间（11 个月？）没有问题。 今天我决定尝试一下 tcp 侦听守护程序（将 tcp 侦听地址添加到 /etc/sysconfig/docker ）并且刚刚收到此错误。

kernel:unregister_netdevice : 等待 lo 空闲。 使用次数 = 1

所以我的使用次数不是 3。

容器：4
跑步：3
暂停：0
停止：1
图片：67
服务器版本：1.10.3
存储驱动：btrfs
构建版本：Btrfs v4.4.1
库版本：101
执行驱动程序：native-0.2
日志驱动：json-file
插件：
体积：本地
网络：桥接空主机
内核版本：3.10.0-514.2.2.el7.x86_64
操作系统：CentOS Linux 7（核心）
操作系统类型：linux
架构：x86_64
Docker 钩子数量：2
CPU：24
总内存：39.12 GiB
名称：aimes-web-encoder
ID：QK5Q： JCMA：ATGR ：ND6W：YOT4：PZ7G：DBV5：PR26： YZQL：INRU ： HAUC：CQ6B
注册表：docker.io（安全）

3.10.0-514.2.2.el7.x86_64 #1 SMP Tue Dec 6 23:06:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

客户：
版本：1.10.3
API 版本：1.22
软件包版本：docker-common-1.10.3-59.el7.centos.x86_64
转版本：go1.6.3
Git 提交：3999ccb-不支持
内置：2016 年 12 月 15 日星期四 17:24:43
操作系统/架构：linux/amd64

服务器：
版本：1.10.3
API 版本：1.22
软件包版本：docker-common-1.10.3-59.el7.centos.x86_64
转版本：go1.6.3
Git 提交：3999ccb-不支持
内置：2016 年 12 月 15 日星期四 17:24:43
操作系统/架构：linux/amd64

我可以确认@aamerik。 我在同一个内核版本上看到了同样的问题。 最近系统没有重大变化，从今天开始看到这个问题。

我在运行 Jenkins docker 映像的 CentOS 7 机器上看到了相同的kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1消息。 截至 2016 年 12 月 20 日左右，我使用的 CentOS 7 机器安装了所有最新的 CentOS 7 补丁。

由于这里最近的参考资料似乎是基于 CentOS 的，我将我的执行主机切换到 Ubuntu 或 Debian 机器。

我在那台 CentOS 7 机器上运行Docker version 1.12.5, build 7392c3b 。 Docker 没有挂起，但是当该消息出现时，我在 Docker 中运行的 Jenkins 进程被终止了。

非常感谢 Docker！ 我一直在使用它，非常感谢您所做的工作！

在 Linux 4.8.15 机器上使用 Jenkins 和 Docker 时，我看到了同样的问题。

有没有人，达到了牧场主操作系统的修复程序？

AFAICT，这是 Linux 内核的网络命名空间子系统中的锁定问题。 一年多以前就已经报告了这个错误，但没有回复： https ://bugzilla.kernel.org/show_bug.cgi?id=97811 对此已经有一些工作（请参阅此处：http://www.spinics。 net/lists/netdev/msg351337.html）但它似乎不是一个完整的修复。

我试过直接 ping 网络子系统维护者，没有响应。 FWIW，我可以在几分钟内重现这个问题。

Smyte 将为解决此问题支付 5000 美元。 听起来我需要和从事内核工作的人谈谈吗？

@petehunt我相信有多个问题导致此错误。

我们按照@reshen 的建议部署了内核4.8.8 ，虽然正常运行时间似乎更好一些，但我们仍然继续在生产中看到这个问题。

尝试从引导节点部署 Mesosphere。 所有节点都是 CentOS 7.2 最小，并应用了所有更新。 bootstrap 节点显示了其他人在上面提到的错误：

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

码头工人-v：

Docker version 1.11.2, build b9f10c9

我可以确认重新启动会使消息静音，但是在我再次部署中间层的那一刻，消息不时开始。 Mesosphere 是一个相当大的部署。 也许那些试图重现错误的人可以使用安装程序重现错误。 使用第一个脚本开关（--genconf，这是第一步）后，在出现错误之前确实需要几分钟时间。

我们也遇到了这个问题。 但是，我们案例中的错误消息提到了设备eth0而不是lo 。 我的错误是这样的：

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

我假设提到eth0而不是lo的错误与此问题具有相同的根本原因。 如果没有，我们应该打开一个关于 eth0 错误的新票证。

• 操作系统：CentOS Linux 版本 7.3.1611
• 内核：3.10.0-514.2.2.el7.x86_64
• Docker 版本 1.12.6，构建 78d1802
• Docker 从选项开始： 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 使用 IPsec（因为 https://bugzilla.kernel.org/show_bug.cgi?id=97811 和其他错误提到 IPsec 才提到这一点）

我们也遇到了这个问题。
错误： unregister_netdevice：正在等待 lo 变为空闲。
操作系统：CentOS Linux 版本 7.3.1611（核心）
内核 3.10.0-514.2.2.el7.x86_64
Docker 版本：1.13.0-cs1-rc1
码头工人选项：
{
"disable-legacy-registry": 真,
“icc”：真，
“不安全的注册表”：[]，
“ipv6”：假，
“iptables”：真，
“存储驱动程序”：“设备映射器”，
“存储选择”：[
"dm.thinpooldev=/dev/mapper/docker_vg-thinpool",
"dm.use_deferred_removal=true",
“dm.use_deferred_deletion=true”
],
“用户空间代理”：假
}

我在两个 CentOS 系统上有这个，至少有一个是最新的更新。

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

嘿，对于在 RHEL 或 CentOS 上受此问题影响的每个人，我已将主线内核的提交（torvalds/linux@751eb6b6042a596b0080967c1a529a9fe98dac1d）向后移植，该提交修复了 IPV6 IFP 企业发行版内核中使用的 refcount.xs10 中的竞争条件。 这应该可以解决这个问题。

您可以在此处找到带有工作补丁的错误报告：
如果你有兴趣测试它并且有一个 RHEL 7 或 CentOS 7 系统，我已经编译了最新的 CentOS 7.3 3.10.0-514.6.1.el7.x86_64 内核和补丁。 回复 CentOS bugtracker 线程，我可以向您发送构建链接。

注意：可能还有另一个问题导致引用计数泄漏，但这应该可以解决许多人的错误消息。

@stefanlasiewski @henryiii @jsoler

我将尝试构建并添加此修复程序： http :

@iamthebot是否意味着如果禁用 IPv6，即使没有您刚刚向后移植的补丁，它也应该解决该问题？

@redbaron仅当这是您遇到的问题时。 我真的认为这里有多个内核问题。

@redbaron也许。 #20569 似乎表明完全禁用 IPV6 很困难。

因此，为了澄清生成此消息的幕后发生的事情，内核会在将设备从命名空间中删除、取消注册、停用它等之前维护一个设备是否正在使用的运行计数。 如果由于某种原因有一个悬空引用一个设备，那么您将看到该错误消息，因为当其他人正在使用它时无法取消注册。

到目前为止我看到的修复：

1. 修复了 IPV6 地址分配问题失败的问题（例如：重复地址），但我们在退出前不会释放对设备的引用。
2. 修复了以下问题：移动设备的命名空间会将对该设备的引用正确地移动到新的网络命名空间，但会在旧命名空间上留下悬空引用。 Docker 大量使用网络命名空间（另一个内核修复证明了我将 Red Hat 向后移植到 7.3 Z-Stream 并计划包含在 7.4 中，以防止 docker 的 macvlan 驱动程序在绑定或团队设备上工作）

我认为切换命名空间时还有另一个竞争条件（这似乎是在创建一堆新容器之后发生的），但我需要可靠地复制这个问题，以便找到它并编写补丁。

有没有人有一个最低限度的程序来始终如一地重现这个？ 似乎在我们的系统上随机发生。

@iamthebot这不是很简单，但我认为我们可以为您提供一个可以可靠地重现这一点的测试环境。 给我发电子邮件 ([email protected])，我们可以安排细节。

在 Docker 版本 1.12.6 的重负载下仍然会遇到这种情况，在 4.4.39-34.54.amzn1.x86_64 AWS Linux AMI 上构建 7392c3b/1.12.6。

我有 9 个几乎完全相同的 docker 主机，并且只在其中一些主机上遇到过这种情况。 这可能是巧合，但我注意到的一个共同点是，我似乎只有在运行不处理SIGINT容器时才会遇到这个问题。 当我docker stop这些容器时，它会挂起 10 秒，然后不雅地杀死容器。

问题出现之前需要几天时间，并且似乎是随机出现的，而不仅仅是在运行docker stop后立即出现。 这主要是轶事，但也许它会帮助某人。

正如@iamthebot提到的那样，我已将所有 docker 节点升级到 CentOS 7.3 上的内核 3.10.0-514.6.1.el7.x86_64，但我仍然遇到相同的错误：
Jan 26 13:52:49 XXX 内核：unregister_netdevice：等待 lo 成为免费。 使用次数 = 1
来自syslogd@XXX于 1 月 26 日 13:52:49 的消息...
kernel:unregister_netdevice : 等待 lo 空闲。 使用次数 = 1

@jsoler只是为了清楚这个（补丁应该适用于较旧的内核）。

给我发一封电子邮件 ([email protected])，我可以向您发送一个预构建内核的链接。 @vitherman不幸的是，我没有太多时间来研究这个问题（看起来需要编译一些工具来捕获这个错误）但是我已经通过 Red Hat 支持升级了这个问题，所以他们的内核团队将采取看。

@ckeeney我可以确认这种行为。 我们有一个 dockerized Node 应用程序，它在主机系统关闭时导致了上述错误。 在 Node.js 应用程序中实现一个函数后，它会捕获 SIGINT 和 SIGTERM 以正常关闭应用程序，错误没有再次发生。
哪一种有道理； Node 应用程序使用 Docker 创建的虚拟接口。 当 Node 没有正确关闭时，设备挂起并且主机系统无法注销它，即使 Docker 容器已成功停止。

这是一个示例代码片段：

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 是否有不同的信号在默认情况下由 Node 正确处理以实现干净关闭？ （您可以指定STOPSIGNAL图像中，或在docker run通过--stop-signal标志。

@thaJeztah对问题的很好解释和解决方法，请参阅nodejs/node-v0.x-archive#9131#issuecomment-72900581

@ckeeney我知道这一点（即，作为PID1运行的进程可能无法处理SIGINT或SIGTERM ）。 出于这个原因，我想知道即使以PID1运行，指定不同的停止信号是否会彻底关闭。

或者，docker 1.13 添加了一个--init选项（拉取请求：https://github.com/docker/docker/pull/26061），在容器中插入一个 init ； 在这种情况下，Node 不会作为PID1 ，这在您无法更新应用程序的情况下可能会有所帮助。

@iamthebot我已经构建了内核版本 3.10.0-514.el7 并集成了您的补丁，但我遇到了同样的错误。 好吧，我不确定我是否已经很好地构建了centos的内核包。 你能分享我你的内核包来测试它吗？

谢谢

我已经/已经处理这个错误将近一年了。 我将 CoreOS 与 PXE 引导一起使用，我在 pxeboot 配置中禁用了 ipv6，从那以后我再也没有遇到过这个问题。

好吧，我的环境已使用此 sysctl 配置禁用了 ipv6
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
但我仍然收到错误
kernel:unregister_netdevice : 等待 lo 空闲。 使用次数 = 1

@jsoler是的，我也这样做了，仍然发生了。 只有一次我做到了 pxe 级别才停止。

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

只是一个观察 - 似乎有不同的问题在起作用（之前已经说过）。

• 有些人注意到“等待...”
• 有些人注意到“等待 eth0”
• 有些人注意到“等待 veth ?????”
• 在RedHat bug tracking 上，有关于“等待 ppp0”的讨论

有些人注意到日志在上述任何一项之间交替，而其他人仅具有上述一项。

Ubuntu 上也

@etlweather我相信事实上，唯一的共同点是，一个网络设备不能像错误消息所说的那样被内核注销。 然而，_why_ 的原因有些不同。 对我们来说，这绝对是提到的 docker / node 问题（veth）。 对于 eth，原因很可能是完全不同的东西。

使用 docker 1.13.1 在 debian jessie 上使用 4.9.0-0.bpo.1-amd64 仍然会发生。 是否有任何稳定的内核 - os 组合？

这可能不是纯粹的 docker 问题 - 我在 Proxmox 服务器上得到它，我只运行 vanilla LXC 容器（ubuntu 16.04）。

@darth-veitcher 这是一个内核问题

@thaJeztah同意谢谢。 今晚打算尝试从主线安装 4.9.9，看看是否能解决问题。

我让它在内核为 4.9.9-040909 的 Debian 上运行 Docker 1.13.1。

是的，将 Proxmox 上的内核升级到最新的 4.9.9 并没有解决错误。 奇怪，因为它在一年后才出现，没有问题。

线程中的前一条语句中可能有一些内容关于它链接到挂载的 NFS 或 CIFS 共享。

从我的iPhone发送

2017 年 2 月 14 日 07:47，Alfonso da Silva [email protected]写道：

我让它在内核为 4.9.9-040909 的 Debian 上运行 Docker 1.13.1。

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看，或将线程静音。

我在 Redhat 上有一张关于这个的 bugzilla 票。

一些进展：
Red Hat 将来自主线的 IPV6 refcount 泄漏补丁放在 QA 上，看起来它们正在排队等待 RHEL 7.4，并且可能会向后移植到 7.3。 应该很快也会在 CentOS-plus 上。 注意：此补丁仅修复了某些情况下的问题。 如果你有一个 4.x 内核，这是一个有争议的问题，因为它们已经存在了。

据我所知，这绝对是内核中的竞争条件，这使得找到它真的很烦人。 我已经拍摄了当前主线内核的快照，并致力于检测从 IPV6 子系统开始的各种调用。 这个问题现在肯定可以重现：看起来你所要做的就是创建一堆容器，从它们推送大量网络流量，使容器内的程序崩溃，然后删除它们。 一遍又一遍地执行此操作会在几分钟内触发问题，在物理 4 核工作站上最严重。

不幸的是，我没有太多时间来处理这个问题：如果这里有内核开发人员愿意合作检测必要的部分，我认为我们可以建立一个分支并开始逐步寻找这个问题.

@iamthebot ，它可以在 qemu-kvm 设置上重现吗？

@iamthebot我试图用不同的内核多次重现这个。 在上面的某个地方提到使用docker-stress -c 100并将userland-proxy设置为 false 会触发它，但我没有运气。

如果你有更可靠的重现（即使需要很长时间才能触发）我可以尝试看看

我们在生产和登台环境中遇到了同样的困难。 我们将很快升级到 Docker 1.13 和 Linux 内核 4.9，但正如其他人已经提到的； 这些版本也受到影响。

$ 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

我在我的开发系统上经常遇到这个问题，总是在关闭容器时。

基本信息

→ 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

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 如果您尝试停止容器但它没有响应 SIGINT，docker 将等待 10 秒，然后不正常地终止容器。 我在 nodejs 容器中遇到了这种行为，直到我添加了信号处理。 如果您看到一个容器需要 10 秒才能停止，则它可能没有处理信号并且更有可能触发此问题。

确保您的容器可以正常停止。

虽然我不是解决这个问题的人，对 Linux 内核开发也不是很感兴趣，但我认为我说“我也是”的评论没有那么有帮助是正确的。 我的意思是，只是说“我也有这个问题，使用 Kernel vx.x 和 Docker 1.x”并没有给讨论带来任何新的东西。

但是，我建议“我也是”的评论更多地描述环境和繁殖方法将非常有价值。

在阅读所有评论时，很明显存在一些问题 - 正如我之前发布的那样，有些是 vethXYZ，有些是 eth0，有些是 lo0。 这表明它们可能是由不同的问题引起的。 所以只说“我也是”而不完整描述错误和环境可能会误导人们。

此外，在描述环境时，仅提供内核和 Docker 版本是不够的。 根据线程，似乎有一些因素，例如是否启用了 ipv6。 NodeJS 不响应 SIGINT（或其他容器，不在这里抨击 NodeJS）。

因此，描述环境上的工作负载是有用的。 此外，当容器正在关闭时会发生这种情况，因此我还建议遇到此问题的人注意当问题再次出现时正在停止的容器。

虽然问题似乎在于内核存在竞争条件 - 识别触发器将对解决问题的人有巨大帮助。 它甚至可以为受影响的用户提供即时解决方案，例如在 NodeJS 应用程序中实现信号处理程序（我自己不知道这会阻止问题触发，但根据其他人之前的评论似乎如此）。

FWIW kubernetes 已经将这完全与 veth“发夹模式”相关联，并且
已完全停止使用该功能。 我们没有经历过这个
数以万计的生产机器和大量
更多的测试运行，因为改变。

在这被修复之前，弃船。 寻找不同的解决方案:(

2017 年 2 月 15 日星期三上午 10:00，ETL [email protected]写道：

虽然我不是解决这个问题的人，但对 Linux 不太了解
内核开发人员，我认为我说“我也是”的评论是正确的
很有帮助。 我的意思是，只是说“我也有这个问题，与
Kernel vx.x 和 Docker 1.x”并没有给讨论带来任何新的东西。

但是，我建议使用“我也是”的评论来描述更多
繁殖的环境和方法将是非常有价值的。

看完所有评论，很明显有几个问题——
正如我之前发布的，有些使用 vethXYZ，有些使用 eth0，有些使用 lo0。
这表明它们可能是由不同的问题引起的。 所以就
在没有完整描述错误和环境的情况下说“我也是”可能
误导人们。

另外，在描述环境时，给出 Kernel 和 Docker
版本不够。 根据线程，似乎有几个因素
例如是否启用 ipv6。 NodeJS 不响应 SIGINT（或其他
容器，而不是在这里抨击 NodeJS）。

因此，描述环境上的工作负载是有用的。
此外，当容器正在关闭时会发生这种情况，因此我会
还建议遇到此问题的人注意什么
当问题再次出现时，容器正在停止。

虽然问题似乎在于内核存在竞争条件 -
确定触发器将对那些将要修复的人有很大帮助
问题。 它甚至可以为受影响的用户提供即时解决方案
例如在 NodeJS 应用程序中实现信号处理程序（我不知道
我自己认为这可以防止问题触发，但似乎如此
其他人之前的评论）。

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/docker/docker/issues/5618#issuecomment-280087293或静音
线程
https://github.com/notifications/unsubscribe-auth/AFVgVFmu1SiStZcLKtKuk1W-tjn6wOXlks5rcz0hgaJpZM4B4L4Z
.

是的，我们正在迁移到 gke 并且不再看到此问题（因此我们不再提供错误赏金:)）

刚才又报错了。 我试图修复一个使用套接字的 node.js 应用程序，因此经常扩展应用程序。 node.js 应用程序构建在https://github.com/deployd/deployd之上

编辑又发生了！ 在同一个 node.js 应用程序上工作。 过去 3 或 4 天我没有直接处理那个 node.js 应用程序，它从未发生过。

edit2将尝试向 nodejs 应用程序添加信号处理程序。 让我们看看这是否有帮助......

在使用 docker-py 将新实例发布到 EC 后，我刚刚遇到了这个错误。 但是，我能够使用 ctrl+C 退出，并且从那以后就再也没有看到过（现在大多数图像从缓存中构建得更快）

```{"status":"Pushed","progressDetail":{},"id":"c0962ea0b9bc"}
{“状态”：“阶段：摘要：sha256：f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8 大小：5737”}
{"progressDetail":{},"aux":{"Tag":"stage","Digest":"sha256:f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce687}5"85"

Docker 镜像发布成功

来自syslogd@ip-172-31-31-68 的消息于 2 月 16 日 19:49:16 ...
内核：[1611081.976079] unregister_netdevice：等待 lo 成为空闲。 使用次数 = 1

来自syslogd@ip-172-31-31-68 的消息，2 月 16 日 19:49:27 ...
内核：[1611092.220067] unregister_netdevice：等待 lo 变得空闲。 使用次数 = 1

[1]+ 停止 ./image-publish.py
[ root@ip-172-31-xx-xx镜像发布]# ^C
[ root@ip-172-31-xx-xx图像发布]#

@thockin是--hairpin-mode=none设置吗？

=none 会破坏通过 NAT 返回自身的容器。 我们用
默认情况下混杂桥接。

2017 年 2 月 16 日星期四晚上 7:26，Kanat Bekt通知@github.com
写道：

@thockin https://github.com/thockin是这个设置 --hairpin-mode=none
在 kubelets 上？

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/docker/docker/issues/5618#issuecomment-280539673或静音
线程
https://github.com/notifications/unsubscribe-auth/AFVgVLNwAH6NWVaIKhJfS147O9w_rtJEks5rdRN8gaJpZM4B4L4Z
.

@thockin哪些容器可能希望通过 Service ClusterIP 访问自己？

事实证明它比我想象的更常见，当我们打破它时，很多
的人抱怨。

2017 年 2 月 17 日上午 12:38，“Maxim Ivanov”通知@ github.com 写道：

@thockin https://github.com/thockin容器可能想要
通过 Service ClusterIP 访问自己？

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/docker/docker/issues/5618#issuecomment-280588366或静音
线程
https://github.com/notifications/unsubscribe-auth/AFVgVLn3uBvUW-dQ72qst5_eYiFUtfSVks5rdVyIgaJpZM4B4L4Z
.

我想我知道为什么一些 dockerized nodejs 应用程序会导致这个问题。 默认情况下，节点使用保持活动连接。 使用server.close() ，服务器不接受新连接。 但是当前的活动连接，如 websockets 或 HTTP 保持活动连接仍然保持。 当 dockerized 应用程序也被缩放到 n 时，这可能会导致waiting for lo to become free因为当它被迫终止时，新的被释放。 当 docker 将此应用程序重新分发到另一个节点或应用程序缩小时，docker 会向应用程序发送一个信号，要求它关闭。 该应用程序侦听此信号并可以做出反应。 当应用程序在几秒钟后没有关闭时，docker 会毫不犹豫地终止它。 我添加了信号处理程序，并发现使用server.close() ，服务器并未完全终止，但“仅”停止接受新连接（请参阅 https://github.com/nodejs/node/issues/2642）。 所以我们需要确保像 websockets 或 http keep-alive 这样的开放连接也被关闭。

如何处理网络套接字：
当收到关闭信号时，nodejs 应用程序向所有 websockets 发送closeSockets 。 客户端侦听此closeSockets事件并在sockets.connect()之后不久调用sockets.disconnect() sockets.connect() 。 请记住server.close()被调用，因此该实例不接受新请求。 当此 dockerized 应用程序的其他实例正在运行时，docker 内部的负载均衡器最终将选择一个未关闭并成功建立连接的实例。 应该关闭的实例不会打开 websockets-connections。

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

如何处理保持活动的 HTTP 连接：
目前我不知道如何才能完美地做到这一点。 最简单的方法是禁用保持活动。

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

另一种可能性是将保持活动超时设置为一个非常低的数字。 例如 0.5 秒。

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

希望这可以帮助其他人:)

我有同样的问题。 附件是所有由 ecs-logs-collector 脚本制作的日志。
非常感谢任何帮助:)

收藏.zip

我有同样的问题。
Docker 版本 1.13.1，构建 092cba3
Linux debian 4.8.6-x86_64-linode78

Linux 备份 4.6.0-040600-generic #201606100558 SMP Fri Jun 10 10:01:15 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
服务器版本：1.13.1

同样的问题。 我在特权容器中使用 mount。 运行 4-5 次后它会冻结。 我也对 16.04 的最新标准内核有同样的问题

每个人， @etlweather都

@rneugeba @redbaron不幸的是，我目前拥有的“

我们在 GCE 中经常得到这个。 Docker 冻结，机器在重新启动时挂起。

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

容器正在运行一个 go 应用程序，并配置了 hairpin nat。

码头工人：

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

有没有人对此有建议的解决方法？ 我尝试启用--userland-proxy=true并且一段时间后docker仍然挂起。 看起来 Kubernates 有一个来自@thockin上面写的解决方案，但不清楚--hairpin-mode=promiscuous-bridge到底做

在运行 Proxmox 和使用容器时，我可以可靠地做到这一点。 具体来说，如果我最近移动了大量数据或移动了任何数量的数据，关闭或硬停止容器将产生此错误。 当我使用将 NAS 安装在其中的容器时，我最常看到它，但这可能是巧合。

# 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

从 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

值得注意的是，Docker 没有安装在这个系统上，也从来没有安装过。 我很乐意提供社区解决此问题所需的任何数据，只需告诉我要运行哪些命令即可。

我能够在 Centos 7.3 上重现这个，作为一个 swarm 工作节点运行 dtr，并映射了一个已安装的 nfs 卷

如果你到达这里

此处讨论的问题是内核错误，尚未修复。 有许多选项可能对_某些_情况有所帮助，但并非对所有情况都有帮助（这很可能是触发相同错误的问题的组合）

不要留下“我也有这个”的评论

“我也有这个”无助于解决错误。 如果您有可能有助于解决问题的信息，请仅发表评论（在这种情况下；为上游内核提供补丁可能是最好的步骤）。

如果您想知道您也有此问题，请使用顶部描述中的“竖起大拇指”按钮：

如果您想随时了解更新，请使用_订阅按钮_。

这里的每条评论都会向超过 3000 人发送一封电子邮件/通知，我不想锁定关于此问题的对话，因为它尚未解决，但如果您忽略这一点，可能会被迫这样做。

谢谢！

这一切都很好，但有什么 _exactly_ 有帮助的选项？ 这个问题导致我们在生产中出现问题，所以我想做任何必要的解决方法来解决内核错误。

如果来自 Docker 的人有时间尝试 Kubernetes 解决方法，请
让我知道，我们可以指出你。 我无法提取更改
并立即将它们修补到 Docker 中。

2017 年 3 月 9 日星期四上午 7:46，Matthew Newhook通知@github.com
写道：

这一切都很好，但究竟有哪些选项有帮助？
这个问题导致我们在生产中出现问题，所以我想做什么
解决内核错误所必需的变通方法。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/docker/docker/issues/5618#issuecomment-285388243或静音
线程
https://github.com/notifications/unsubscribe-auth/AFVgVGdH5VX_oFWkImyo_TvlIuhmwMepks5rkB7MgaJpZM4B4L4Z
.

@thockin谢谢。 我正在使用发夹模式解决方法关注 Kubernetes 中的 PR/问题。 但是在多次来回的过程中，如果解决方法实际上摆脱了这个问题，我就迷失了方向？
（据我所知，有不同的情况会导致内核中的引用计数不一致）。

如果你能指出你认为解决 K8s 中的问题的 PR，我将努力在 docker 中修补这个问题，至少在默认情况下关闭 userland-proxy 的情况下。 （我们可以使用 docker-stress 复制步骤对其进行测试）。

我不确定我有一个 PR，但您可以查看当前状态。 开始
这里：

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

2017 年 3 月 11 日星期六晚上 10:49，Madhu Venugopal通知@ github.com
写道：

@thockin https://github.com/thockin谢谢。 我正在关注
Kubernetes 中的 PR/issue 使用发夹模式解决方法。 但期间
很多来回，如果解决方法实际上摆脱了这个，我就失去了方向
问题 ？
（据我所知，有不同的情况会导致引用计数
内核中的不一致）。

如果你能指出你认为解决 K8s 中问题的 PR，
我将努力在 docker 中至少在转弯的情况下修补它
userland-proxy 默认关闭。 （我们可以使用 docker-stress 测试它
复制步骤）。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/docker/docker/issues/5618#issuecomment-285926217或静音
线程
https://github.com/notifications/unsubscribe-auth/AFVgVIlGs_QccxS6YYQiLNybddDzB4yUks5rk5VogaJpZM4B4L4Z
.

大家好，需要说明的是，所有“kubernetes 解决方法”所做的就是在底层网桥上启用混杂模式。 您可以使用 iproute2 使用ip link set <bridgename> promisc on实现相同的目的。 它降低了遇到错误的可能性，但可能无法完全消除它。

现在，理论上这应该行不通……但由于某种原因，混杂模式似乎使设备拆卸速度足够慢，以至于您不会争先恐后地减少参考计数器。 如果 Kurbernetes 的一位贡献者在这个线程上，也许他们可以在这里发言。

我可以使用特定于环境的重现验证解决方法（NOT FIX）是否有效。 如果您使用 IPVLAN 或 MACVLAN 驱动程序（我们在 prod 中使用 macvlan），我无法真正验证它是否有帮助，因为让这些设置产生此错误似乎非常困难。 其他任何人都可以尝试验证解决方法吗？

大家好，我试图调试内核问题，在“netdev”邮件列表上有一个电子邮件链，所以只想在这里发布一些发现。

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

我们看到的问题是

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

在容器关闭期间。 当我检查容器网络命名空间时，似乎eth0设备已经被删除，但只有lo设备留在那里。 还有另一个结构保存该设备的引用。

经过一番挖掘，结果发现持有引用的“事物”是“路由缓存”之一（ struct dst_entry ）。 有些东西阻止了特定的dst_entry被 gc'ed（ dst_entry的引用计数大于 0）。 所以我记录了每个dst_hold() （将 dst_entry 引用计数增加 1）和dst_release() （将 dst_entry 引用计数减少 1），并且确实有更多的dst_hold()调用然后dst_release() 。

这是附加的日志： kern.log.zip

概括：

• lo接口被重命名为lodebug以便于 grep
• dst_entry的引用计数从 1 开始
• 最后dst_entry （保存 lo 的引用）的引用计数为 19
• 总共有 258041 次dst_hold()调用，总共 258023 次调用dst_release()
• 在 258041 dst_hold()调用中，有 88034 udp_sk_rx_dst_set() （然后调用dst_hold() ）、152536 inet_sk_rx_dst_set()和 17471 __sk_add_backlog()
• 在 258023 dst_release()调用中，有 240551 inet_sock_destruct()和 17472 refdst_drop()

总共有更多的udp_sk_rx_dst_set()和inet_sk_rx_dst_set()调用比inet_sock_destruct() ，所以怀疑有一些套接字处于“边缘”状态，并且阻止它们被破坏。

更新：
事实证明套接字（ struct sock ）被正确创建和销毁，但是对于某些 TCP 套接字inet_sk_rx_dst_set()在同一个dst上被多次调用，但只有一个对应inet_sock_destruct()以释放对dst的引用。

这是为我修复它的 CentOS 7.3 解决方法：

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

这是解决它的补丁：
https://bugs.centos.org/view.php?id=12711&nbn=1

更新：结果证明这并不能永久解决问题。 几个小时后它再次出现，并带有以下墙上消息：
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

@adrianotto - 澄清：CentOS 内核补丁是否解决了这个问题？ 只是好奇你的意思是你的解决方法和参考内核路径都没有成功永久解决这个问题吗？

@stayclassychicago @adrianotto该补丁仅解决了可能触发内核中“使用计数”问题的竞争条件之一。 这只是我已经从 4.x 内核中的某些内容向后移植的修复程序。 它可能会解决您的问题，因此值得一试。

@stayclassychicago在我尝试3.10.0-514.10.2.el7.centos.plus.x86_64内核之前，我经常得到kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1 ，几乎每次当容器退出时我用docker run --rm ...运行容器时。 内核升级重启后，完全停止了好几个小时，然后又回来了。 现在我删除容器的一半时间它都可以正常工作，但它曾经经常出错。 我不确定新内核是否有帮助，但它没有坏处。

机器上有LACP绑定接口的时候看起来很容易重现。 我们有一个 3 节点 swarm 集群，所有 3 个节点都配置了 LACP 绑定接口，这个问题基本上不允许我们使用集群。 我们必须每 15-20 分钟重新启动节点。

确认 - 一旦我从接口（那些用作主接口）中移除 LACP 绑定，一切正常运行超过 12 小时。 过去每约 30 分钟休息一次。

当我们打开 cifs 挂载时，这可以在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上重现，其中Docker version 17.04.0-ce, build 4845c56以特权模式运行。 当容器在挂载打开的情况下停止时，Docker 没有响应，我们得到kernel:[ 1129.675495] unregister_netdevice: waiting for lo to become free. Usage count = 1 -错误。

ubuntu 16.04(kernel 4.4.0-78-generic) 仍然有问题。 当它发生时，任何试图通过克隆系统调用创建新网络命名空间的应用程序都会卡住

[ 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

唯一的解决方案是硬重置机器。

在特权容器中安装 NFS 卷然后重新启动容器时，我遇到了这个问题。
在我看来，这个问题在 RHEL 7 上从未发生过，使用相同的程序。

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

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

Red Hat 声称从 kernel-3.10.0-514.21.1.el7 版本开始修复了这个错误的一个实例。 我想他们会尽快修复并重新调整到 4.12。 这个软件包也已经在 CentOS 7 上可用。

与修复相关的文档（需要 RHN 访问权限）：
https://access.redhat.com/articles/3034221
https://bugzilla.redhat.com/show_bug.cgi?id=1436588

从文章：
“如果 IPv6 地址重复或设置地址出现问题，则会发生竞争条件。这种竞争条件有时会导致地址引用计数泄漏。因此，尝试取消注册网络设备失败，并显示以下错误消息：“unregister_netdevice: waiting为了变得自由。 使用计数 = 1"。通过此更新，底层源代码已得到修复，网络设备现在可以在所描述的情况下按预期取消注册。"

我已经在我们 PaaS 池的所有系统中部署了此修复程序，并且已经有 2 天没有遇到错误。 早些时候，我们每天至少有一个系统被冻结。 如果我们再次遇到错误，我会在这里报告。

我的内核版本是 3.10.0-514.21.1.el7.x86_64，但还是有同样的症状。

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显然，有多种方法可以解决此问题。 你是如何重现这个错误的特定实例的？

@bcdonadio如果你查看https://git.centos.org/commitdiff/rpms!kernel.git/b777aca52781bc9b15328e8798726608933ceded - 你会看到https://bugzilla.redhat.com/show_bug.cgi?id=14365通过此更改“修复”：

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

我相信这是自 4.8 以来的上游内核（https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d）。 并且 4.9 和 4.10 存在此错误，因此 RedHat 只是从上游向后移植了一些修复程序，这可能修复了一些问题，但绝对不是全部。

@bcdonadio我可以通过从 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

这个脚本只是使用 Docker 注册表中的一个映像生成一个包列表，另一个使用本地构建的映像生成一个包列表，以便我可以比较它们。 Dockerfile 就是这样的：

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

2-4 分钟后 syslog 收到此消息：

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

最后一次发生在我手动运行脚本几分钟后。 我的猜测是，在尝试删除容器后经过一些超时后，会引发错误条件。

我确定错误情况是间歇性的，因为上面的脚本在每个错误过后 :00 作为 cron 作业运行。 以下是 syslog 记录的错误输出示例：

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

所以它发生在容器运行和退出后 2 到 4 分钟范围内的某个地方，并且由于 --rm 标志被 docker 删除。 还从上面的日志中注意到，运行/删除的每个容器都没有错误，但它非常一致。

有人可以看看这个补丁是否有所改善吗？

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

@hlrichardson这实际上看起来像！ 明天我将尝试将其向后移植到我们的 3.16 内核或升级特定服务器并使用此补丁编译内核 4.9，我们将看到它是如何进行的。

但是，在检查提交后，此补丁引用（https://github.com/torvalds/linux/commit/0c1d70af924b966cc71e9e48920b2b635441aa50）-它是在 4.6 内核中提交的，而问题甚至在 :(

啊，所以也许不相关，除非有多种原因（不幸的是，这种类型的错误可以通过多种方式触发，所以这是一种可能性）。

我们个人在这里至少遇到了多个问题 - 其中一些是
“unregister_netdevice”日志在一段时间后消失
docker 容器能够正常工作，而在其他容器中 - 所有容器
卡住了，需要重新启动服务器。

实际上 - 我们不会在出现这些问题的服务器上使用 vxlan - 我们使用
简单的网桥和端口转发（无论用户域代理如何都会发生）
设置）。

2017 年 5 月 30 日 22:54，“hlrichardson” [email protected]写道：

啊，所以也许不相关，除非有多种原因
（不幸的是，有很多方法可以触发这种类型的错误，所以
这是一种可能性）。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/moby/moby/issues/5618#issuecomment-304989068或静音
线程
https://github.com/notifications/unsubscribe-auth/AAGqoDHe1n3h9_eJ2kmeWcbhKRCX6rZoks5r_HPbgaJpZM4B4L4Z
.

好吧，如果您不使用 vxlan 隧道，那肯定无济于事。

顺便说一句，如果您在删除网络命名空间（容器退出）时看到“unregister_netdevice”消息的单个实例，则应将其视为正常情况，即在命名空间的同时或多或少地清理了引用 netdevice 的内容
正在被删除。

更严重的情况是此消息每 10 秒重复一次并且永不停止......
在这种情况下，一个全局锁将被永远持有，并且因为无论何时网络都必须获取此锁
命名空间被添加或删除，任何创建或删除网络命名空间的尝试也
永远挂起。

如果您有一种相当轻松的方式来重现第二类问题，我会对
看一看。

@hlrichardson我们在一堆服务器上看到您在上面提到的

在 Fedora 25 上使用 yum 测试和构建centos:7容器时看到这一点。 Yum 未能完成软件包数据库的下载并无限期挂起，因为网络以一种奇怪的方式停止工作。

嗨，大家好，

Linux net-dev 邮件列表中有一个针对内核错误（或至少其中一个错误）的潜在补丁：

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

它在网络树中合并，排队等待稳定树。

根据https://github.com/torvalds/linux/commit/d747a7a51b00984127a88113cdbbc26f91e9d815 - 它在 4.12（昨天发布）！

@fxposter @kevinxucs明天我将尝试将其移植到当前的 CentOS 内核。

我正在运行 4.12（来自 http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12/）并且我仍然遇到了这个问题，所以torvalds /

$ uname -r
4.12.0-041200-generic

瑞安，你有可靠的繁殖方式吗？

2017 年 7 月 6 日下午 4:29，“Ryan Campbell”通知@github.com写道：

我正在运行 4.12（来自 http://kernel.ubuntu.com/~
kernel-ppa/mainline/v4.12/) 并且我仍然点击了这个，所以 torvalds/linux@
d747a7a https://github.com/torvalds/linux/commit/d747a7a不得
完整的修复。

$ uname -r
4.12.0-041200-通用

—
您收到此消息是因为您订阅了此线程。
直接回复本邮件，在GitHub上查看
https://github.com/moby/moby/issues/5618#issuecomment-313413120或静音
线程
https://github.com/notifications/unsubscribe-auth/AAdcPCbVPDjPw6va-N5dM7CjYn2W4Bodks5sLO9ZgaJpZM4B4L4Z
.

@justincormack不幸的是，我没有可以分享的最小示例，但是我们有一个测试套件可以创建和销毁大量容器，我通常会遇到这个问题（挂起 docker 命令，很多waiting for lo to become free in syslog）只经过几次迭代。

@campbellr我现在已经尝试了三遍，并且在本周的大部分时间里都没有运气。 我设法多次收到waiting for lo to become free消息，但之后没有崩溃/挂起。 我试图通过创建网络命名空间和 veth 接口来减少测试用例。

在您的测试套件中：

• 你的容器有很多网络活动吗？ 如果是，哪个方向占主导地位？
• 您运行的是哪种机器（内核数，是否为 VM 等）
• 你是否同时创建了很多容器？
• 您的容器是正常退出还是崩溃？

即使对上述问题的部分答案也可能有助于缩小范围......
谢谢

@rn Docker 不会再挂起，因为它在通常会挂起的 netlink 请求上设置了超时。 但是您将无法启动新容器（或重新启动现有容器），停止时的容器清理可能也会很奇怪。

我还没有机会在 4.12 上进行测试，但是我可以在 vultr 的 kvm 实例上可靠地重现。 我正在运行 swarm 并且我的无头 chrome 工人在健康检查失败或定期崩溃时会导致问题。 当然，在这一点上，我已经追踪到所有崩溃者都干净利落地处理网络错误等，所以我看到waiting for lo to become free但通常不足以挂起几个星期。

所以看起来有助于复制的东西是更复杂的网络场景，结合大量进入容器的流量，不断的容器回收和 kvm。

@rn我设法将其缩小到我们测试套件中的特定容器，并且能够通过以下步骤进行重现：

1. 启动容器（一个基于龙卷风的内部 Web 服务——我试图提取一个仍然遇到这个问题的最小示例）
2. 向容器中运行的 Web 服务发出请求
3. 等待回应
4. 杀死容器

经过 3 或 4 次迭代后，我最终得到了waiting for lo to become free并且在下一次迭代中docker run失败了docker: Error response from daemon: containerd: container did not start before the specified timeout.

你的容器有很多网络活动吗？ 如果是，哪个方向占主导地位？

一个相当小的数量。 在上面提到的步骤中，http 请求是少量的 json，响应是一个大约 10MB 的二进制 blob。

您运行的是哪种机器（内核数，是否为 VM 等）

这是在 4 核台式机上（无 VM）

你是否同时创建了很多容器？

不，一切都是连续完成的。

您的容器是正常退出还是崩溃？

他们用docker stop停止

1. 启动容器（一个基于龙卷风的内部 Web 服务——我试图提取一个仍然遇到这个问题的最小示例）
2. 向容器中运行的 Web 服务发出请求
3. 等待回应
4. 杀死容器

我花了一些时间剥离容器，结果发现 Web 服务与错误无关。 在我的情况下，似乎触发此问题的是在容器内安装 NFS 共享（使用--privileged ）。

在我的桌面上，我可以可靠地重现简单地运行以下几次：

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

Kubernetes 用户，我向 _kops_ 提出了一个问题，以发布具有内核版本 4.12 的下一个 Kubernetes AMI。 欢迎查看： https :

我还在 centos 7.3 上使用主机内核 3.10.0-514.6.1.el7.x86_64 和 docker-ce-17.06.0.ce-1.el7.centos.x86_64 进行了此操作。

@FrankYu 那没有帮助。 要有效地参与此线程，请提供重现此问题的确切方法，并请在现代内核上进行测试。 3.10 是四年前发布的，我们正在讨论它是固定的还是部分是在四天前的版本上发布的。

@danielgusmao我们的 RancherOS 和 AWS ECS AMI linux 操作系统已经有了“修复”（可能是默认设置），但它并没有为我们解决问题。 我们仍然看到消息一直显示在日志中。 可能唯一的希望是内核补丁被广泛地向后移植。 尽管我四处搜索，但在 RedHat/Centos/AWS linux bugzillas 和论坛中还没有看到任何重大进展的证据。

需要明确的是，消息本身是良性的，它是 OP 报告的消息后内核崩溃，而不是。

代码中的注释，即这条消息的来源，解释了正在发生的事情。 基本上，网络设备的每个用户（例如 IP 堆栈）（例如容器内的veth对的末尾）在使用网络设备时都会增加网络设备结构中的引用计数。 当设备被移除时（例如，当容器被移除时），每个用户都会收到通知，以便他们可以在减少引用计数之前进行一些清理（例如关闭打开的套接字等）。 因为这种清理可能需要一些时间，尤其是在重负载（大量接口、大量连接等）的情况下，内核可能会偶尔在此处打印消息。

如果网络设备的用户从不减少引用计数，内核的其他部分将确定等待清理的任务卡住并崩溃。 只有这次崩溃表明存在内核错误（某些用户通过某些代码路径没有减少引用计数）。 有几个这样的错误，它们已在现代内核中得到修复（并且可能回移植到旧内核）。 我已经编写了相当多的压力测试（并继续编写它们）来触发此类崩溃，但无法在现代内核上重现（但是我会执行上述消息）。

如果您的内核确实崩溃，请仅报告此问题，然后我们将非常感兴趣：

• 内核版本（ uname -r ）
• Linux 发行版/版本
• 您使用的是 Linux 供应商的最新内核版本吗？
• 网络设置（桥接、覆盖、IPv4、IPv6 等）
• 工作负载描述（什么类型的容器，什么类型的网络负载等）
• 理想情况下是简单的复制

谢谢

[ @thaJeztah你能不能把标题改成kernel crash after "unregister_netdevice: waiting for lo to become free. Usage count = 3" ，让它更明确]

应该在内核 4.12 或更高版本中修复。 请检查。 https://access.redhat.com/solutions/3105941
并链接到补丁https://github.com/torvalds/linux/commit/d747a7a51b00984127a88113cdbbc26f91e9d815

@drweber您还将在即将发布的稳定版本中找到此补丁（目前为 4.11.12、4.9.39、4.4.78、3.18.62）

@rn

如果网络设备的用户从不减少引用计数，内核的其他部分将确定等待清理的任务卡住并崩溃。 只有这次崩溃表明存在内核错误（某些用户通过某些代码路径没有减少引用计数）。 有几个这样的错误，它们已在现代内核中得到修复（并且可能回移植到旧内核）。 我已经编写了相当多的压力测试（并继续编写它们）来触发此类崩溃，但无法在现代内核上重现（但是我会执行上述消息）。

请仅在您的内核实际崩溃时报告此问题...

我们在我们的环境中遇到了一个稍微不同的问题，我希望得到一些澄清（内核 3.16.0-77-generic，Ubuntu 14.04，docker 1.12.3-0~trusty。我们有数千台主机运行 docker，2每个主机 -3 个容器，我们在运行 docker 的主机总数的 < 1% 上看到了这一点）。

我们实际上从未看到内核崩溃，而是（据我所知，就像原来的记者一样） dockerd进程已经不存在了。 暴发户（使用上游包中的/etc/init/docker.conf作业）不会启动新的dockerd进程，因为它认为它已经在运行（ start: Job is already running: docker ），并试图停止暴发户作业也失败（ 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>

由于我们主要在dmesg使用桥接网络（在自定义桥接设备上）运行，因此我们看到一条与虚拟接口略有不同的消息：

[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

因为 upstart 似乎拒绝重启 dockerd 或者认为之前运行的进程是僵尸进程，所以我们找到的唯一解决方案就是重启主机。

虽然我们的结果看起来不同（内核没有崩溃），但根本原因听起来相同或相似。 那么这不是同一个问题吗？ 发生这种情况时，是否有任何已知的解决方法或方法可以让docker新贵工作再次运行？

@campbellr我可以用你在内核 4.12.2-1 上的方法重现这个问题。
顺便说一句，如果我在容器停止之前卸载 NFS 存储，则不会发生此问题。

同样的问题。

[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

你好，

我刚刚创建了 2 个 repos https://github.com/piec/docker-samba-loop和https://github.com/piec/docker-nfs-loop ，其中包含必要的设置以重现此错误

我的结果：

• 4.11.3-1-ARCH (Arch Linux) 内核：我在几次迭代 (<10) 中生成了docker-samba-loop的错误。 我无法用docker-nfs-loop重现它
• 4.11.9-1-ARCH 相同结果（版本）
• 4.12.3-1-ARCH (testing repo) 相同的结果
• 4.11.11-coreos: docker-samba-loop结果相同，没有尝试docker-nfs-loop

希望这可以帮助
干杯

一种解决方法是在我的情况下使用--net=host 。 但这并不总是可接受的解决方案

@piec ，非常感谢您提供的详细信息。 在这篇很长的评论的结尾，我还有几个问题要问你。

使用 SMB 设置，我能够使用不同的内核生成许多东西。 我也用 NFS 设置尝试过这个，但没有骰子。

所有测试都在 HyperKit 上使用 docker 17.06.1-ce 运行，虚拟机配置了 2 个 vCPU 和 2GB 内存（通过 Docker for Mac，但这应该无关紧要）。 我正在使用 LinuxKit 内核，因为我可以轻松地将它们换掉。

我修改您的Dockerfile在我加入通话date第一个命令执行，并且还添加了调用date之前andeafter的docker run为客户。

实验一（4.9.39内核）

使用 4.9.39（最新的 4.9.x 稳定内核）时出现内核崩溃：

# 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

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

有时我会看到 4.11.12 内核所做的多次迭代，包括unregister_netdevice消息（见下文），然后导致内核崩溃。 有时我会看到崩溃的细微变化，例如：

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

崩溃发生在 unix 域套接字代码中，与
报告here ，尽管有了这个新的测试用例，它更容易重现。

实验二（4.11.12内核）

使用 4.11.12（这是 4.11 系列中的最新稳定版本）我没有看到崩溃，但它真的很慢（注释与--->内联）：

# 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

我以相同的模式重复运行了一个小时左右，但没有内核崩溃。

我看到的内核日志有很多：

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

那是每十秒一条消息。

由于这不会导致挂起的任务检测在一个小时后启动，我怀疑在 4.11.12 中，引用计数最终会减少并且设备被释放，但是，根据我可以运行容器的时间间隔来判断，它可能需要长达4分钟！

实验三（4.11.12内核）

OP 中的内核崩溃表明内核崩溃是因为检测到挂起的任务。 我在测试中没有看到这种崩溃，所以我更改了与挂起任务检测相关的sysctl设置：

# 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

如果检测到挂起的任务，这会将超时减少到 60 秒并导致内核恐慌。 由于在dockerd抱怨containerd没有启动之前大约需要 2 分钟，如果单个任务被挂起，将挂起任务检测减少到 60 秒应该会触发内核恐慌。 唉，日志中没有崩溃

实验四（4.11.12内核）

接下来，我增加sleep后的各docker run 〜5分钟，看是否消息是连续的。 在这种情况下，所有docker run似乎都可以工作，这有点在意料之中，因为从之前的实验中， docker run将每 4 分钟左右工作一次

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

看起来我们几乎在每个docker run上都获得了大约 200 秒的unregister_netdevice docker run （除了第二个）。 我怀疑在那段时间我们不能启动新的容器（如实验 2 所示。奇怪的是，挂起的任务检测没有启动，大概是因为没有挂起任何任务。

实验 5（4.11.12/4.9.39 在内核中额外启用调试）

这是在docker run之间恢复到 1s 睡眠

我们有另一个内核，它启用了一堆额外的调试
选项，例如LOCKDEP 、 RCU_TRACE 、 LOCKUP_DETECTOR和一些
更多的。

在启用这些调试选项的情况下运行 repro 4.11.12 内核不会触发任何事情。

同样适用于 4.9.39 内核，其中正常内核会崩溃。 调试选项稍微改变了时间，所以这可能是 unix 域套接字代码中的崩溃是由于竞争引起的额外线索。

深入一点

strace上的各种containerd过程是没有帮助的（它
通常不是因为它是用 Go 编写的）。 很多长摊位
futex(...FUTEX_WAIT...)包含有关地点/原因的任何信息。

一些用sysrq闲逛：

增加冗长：

echo 9 > /proc/sysrq-trigger

来自所有 CPU 的堆栈跟踪：

echo l > /proc/sysrq-trigger
[ 1034.298202] sysrq: SysRq : Show backtrace of all active CPUs
[ 1034.298738] NMI backtrace for cpu 1
[ 1034.299073] CPU: 1 PID: 2235 Comm: sh Tainted: G    B           4.11.12-linuxkit #1
[ 1034.299818] Hardware name:   BHYVE, BIOS 1.00 03/14/2014
[ 1034.300286] Call Trace:
[ 1034.300517]  dump_stack+0x82/0xb8
[ 1034.300827]  nmi_cpu_backtrace+0x75/0x87
[ 1034.301200]  ? irq_force_complete_move+0xf1/0xf1
[ 1034.301633]  nmi_trigger_cpumask_backtrace+0x6e/0xfd
[ 1034.302097]  arch_trigger_cpumask_backtrace+0x19/0x1b
[ 1034.302560]  ? arch_trigger_cpumask_backtrace+0x19/0x1b
[ 1034.302989]  sysrq_handle_showallcpus+0x17/0x19
[ 1034.303438]  __handle_sysrq+0xe4/0x172
[ 1034.303826]  write_sysrq_trigger+0x47/0x4f
[ 1034.304210]  proc_reg_write+0x5d/0x76
[ 1034.304507]  __vfs_write+0x35/0xc8
[ 1034.304773]  ? rcu_sync_lockdep_assert+0x12/0x52
[ 1034.305132]  ? __sb_start_write+0x152/0x189
[ 1034.305458]  ? file_start_write+0x27/0x29
[ 1034.305770]  vfs_write+0xda/0x100
[ 1034.306029]  SyS_write+0x5f/0xa3
[ 1034.306283]  entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 1034.306638] RIP: 0033:0x7fa4810488a9
[ 1034.306976] RSP: 002b:00007fffd3a29828 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 1034.307567] RAX: ffffffffffffffda RBX: 000000c6b523a020 RCX: 00007fa4810488a9
[ 1034.308101] RDX: 0000000000000002 RSI: 000000c6b5239d00 RDI: 0000000000000001
[ 1034.308635] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 1034.309169] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[ 1034.309700] R13: 0000000000000000 R14: 00007fffd3a29988 R15: 00007fa481280ee0
[ 1034.310334] Sending NMI from CPU 1 to CPUs 0:
[ 1034.310710] NMI backtrace for cpu 0 skipped: idling at pc 0xffffffffa0922756

这里什么都没有，CPU1 空闲，CPU0 正在处理 sysrq。

显示被阻止的任务（两次）

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

这表明netns和cleanup_net工作队列都很忙。 很久以前我在这里发现了一个有点相关的问题，但是这次cleanup_net队列处于不同的状态。

概括

• 我认为 4.9.x 内核上的崩溃是无关的，但似乎在 4.11.x 中得到修复。 这需要更多的分类。
• 与之前的一些报告不同，没有报告挂起的任务，但很难说，因为关于这个问题的堆栈跟踪很少。
• 某物被阻塞了很长时间（2-4 分钟）。 它可能与工作队列状态有关
• 工作队列的转储需要更多的分析，特别是为什么工作队列在那个状态下停留那么久。
• unregister_netdev消息似乎与最近的修复（在 4.9.39 和 4.11.12 中）无关。 这可能是因为cleanup_net工作队列没有进行，因此打印了消息。
• 完全不清楚 SMB 如何/为什么触发这个。 我已经为网络命名空间和不同的工作负载编写了大约 60 个奇怪的压力测试，但无法触发任何问题。 测试基于runc ，也许我应该尝试containerd 。

我会再挖掘一点，然后将摘要发送到netdev 。

@piec您是否有控制台访问权限，可以查看是否有任何故障转储方面的问题，或者您是否也看到了我所看到的巨大延迟？ 如果你有一个崩溃转储，我会非常有兴趣看到它。 另外，您是在裸机上还是在虚拟机上运行？ 您在 CPU 和内存方面的配置是什么？

@rn感谢您的调查！

我在裸机台式 PC 上运行，因此我可以访问所有内容。 这是一个 i7-4790K + 32 GiB。
目前，我正在测试仓库 (4.12.3-1-ARCH) 中运行最新的 Arch Linux + 内核

就我而言，一切都如您在实验 2（4.11.12 内核）中描述的那样：

• 在 client-smb 容器存在后，运行新容器 4 分钟以上是不可能的。
• 我从来没有内核崩溃
• 如果我尝试在 client-smb 退出后 4 分钟以上的延迟内运行任何新容器，则会重复出现unregister_netdevice: waiting for lo to become free. Usage count = 1消息。 并且仅当您在 4 分钟的时间间隔内运行一个新容器时才会出现。 在这 4 分钟后运行一个新容器将是“正常的”

所以我想在与网络接口相关的 smb-client 容器的清理过程中某处存在问题

这个问题实际上有一个更简单的重现（顺便说一句，这不是原始问题）。

该脚本只是在主机上启动一个 SMB 服务器，然后使用veth对创建网络命名空间，在网络命名空间中执行mount; ls; unmount ，然后删除网络命名空间。

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

请注意，在卸载后添加一个简单的sleep 1 ，无论是在命名空间中执行时还是在删除网络命名空间之前，都可以在创建新命名空间时完全没有停顿。 删除旧命名空间后的睡眠不会减少停顿。

@piec我还在卸载后用你的sleep 1在 Dockerfile 中测试了这个，一切都按预期工作，没有停顿，没有unregister_netdev消息。

我现在把它写下来并发送给netdev@vger

优秀
我确认卸载后sleep修复了停滞和unregister_netdev消息在我的设置中

你不认为umount生成一个相对于它的 netns 的异步操作，如果在该操作完成之前删除 netns，它将阻塞并最终超时？ 挂载后的睡眠会让这些东西在 netns 被移除之前完成。
但这只是一个假设

我试过没有卸载，同样的区别。 这是网络命名空间的删除。 9 和删除挂载命名空间无论如何都会触发卸载。

喔好吧

顺便说一句，我再次错误地（在开发时）在另一台带有 smb 的机器上重现了这个问题。 这是一台 Ubuntu 16.04 PC，Linux 4.4.0-77-generic。 还有一个挂起的任务回溯可能很有趣。 没有崩溃和相同的约 4 分钟延迟。

[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

netdev@vger线程在这里https://www.mail-archive.com/[email protected]/msg179703.html如果有人想跟踪进展。

@piec是的，这是预期的。

我也遇到了这个错误，并且能够在 Ubuntu 内核映像上使用@piec 的 docker -samba-loop 方法重现 Oopses：

• 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

我将我的发现添加到 Ubuntu 错误报告中： https : https://github.com/fho/docker-samba-loop

@fho谢谢。 您实际上根本不需要 docker 来重现，只需在网络命名空间中运行 samba 客户端即可按照https://github.com/moby/moby/issues/5618#issuecomment -318681443 进行操作

@rn谢谢你的信息。 我还没有尝试过这种方式。

最近在这里和 netdev 邮件列表上的帖子似乎只是关于内核停顿。
我也有内核崩溃与内核 4.11 和 4.12。

我看到了一个与此非常相似的问题（详见 #35068）。 我们基本上运行一个双节点群，它使用分散放置策略运行具有 4 个副本的单个服务。

在每个服务容器中，我们将主机 docker.sock 挂载为一个卷，并从容器内执行docker run命令，每个容器的最大并发数为 4。 这导致最多同时创建 4 个容器，并在通过-rm后立即删除。

上面参考中显示的 ARMv7 上的其他内核日志和示例。

ip6_route_dev_notify panic 对我们来说是一个严重的问题。

我想再看看这个，这绝对不是与以下相同的错误：

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

我认为这是具有 ipv6 层的内核上游的一个问题。

这些信息可能是相关的。

我们可以通过 _unregister_netdevice 重现问题：等待 lo 成为免费。 使用计数 = 1_ 使用 4.14.0-rc3 内核，_CONFIG_PREEMPT_NONE=y_ 并且仅在具有以下引导内核选项的一个 CPU 上运行：

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

一旦我们达到这个状态，它就停留在这个状态并且需要重启。 不能产生更多的容器。 我们通过运行 ipsec/openvpn 连接的图像 + 在隧道内下载一个小文件来重现它。 然后实例存在（通常它们运行 < 10 秒）。 我们每分钟在一台机器上运行 10 个这样的容器。 使用上述设置（只有 1cpu），机器在大约 2 小时内命中。

另一个具有相同内核但不限制 CPU 数量的复制器是在容器内以 UDP 模式运行 iperf 3 秒（因此根本没有 TCP 通信）。 如果我们并行运行 10 个这样的容器，等待所有容器完成并再次运行，我们会在不到 10 分钟的时间内（在 40 核机器上）遇到问题。

在我们的两个复制器中，我们都添加了“ip route flush table all; ifconfig下; 在从容器存在之前休眠 10"。它似乎没有任何影响。

你好，

只是为了增加火力，我们也看到了这个问题，根据这里的要求，以下是......

内核版本： Linux exe-v3-worker 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64 GNU/Linux

Linux 发行版/版本： Debian 9.1（所有软件包都是最新的）

您使用的是 Linux 供应商的最新内核版本吗？ 是的

网络设置（桥接、覆盖、IPv4、IPv6 等）：仅限 IPv4，按照默认 Docker 设置进行 NAT

工作负载描述（什么类型的容器，什么类型的网络负载等）：非常短暂的容器（从几秒到几分钟）在退出之前运行脚本。

理想情况下是一个简单的复制：

**内核：[617624.412100] unregister_netdevice：等待 lo 成为空闲。 使用次数 = 1

无法在受影响的节点上终止旧容器或启动新容器，必须重新启动才能恢复功能。**

希望我们能尽快找到根本原因/补丁。

此致，

robputt796

@坎贝尔
同意它似乎与网络存储有关。 我在 kubernetes 中使用 ceph krbd 作为持久卷。
我可以在长时间运行容器崩溃后重现这种情况。

这个问题是在 10 天前分配的，它正在进行中，你可以在这里看到更多关于正在发生的事情的见解https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407

希望 Dan Streetman 找出解决方法

原来 Oops 是由内核错误引起的，该错误已由提交 76da0704507bbc51875013f6557877ab308cfd0a 修复：

ipv6：只为 NETDEV_UNREGISTER 调用一次 ip6_route_dev_notify()

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76da0704507bbc51875013f6557877ab308cfd0a
（它只是修复了内核恐慌，而不是“kernel:unregister_netdevice: waiting for lo to be free. Usage count = 2”问题。）

（在这里再次重复，因为 GitHub 隐藏了旧评论）

如果你到达这里

此处讨论的问题是内核错误，尚未完全修复。 内核中的一些补丁修复了此问题的_some_ 出现，但其他补丁尚未解决。

有许多选项可能对_某些_情况有帮助，但并非对所有情况都有帮助（同样；这很可能是触发相同错误的问题的组合）

不要留下“我也有这个”的评论

“我也有这个”无助于解决错误。 如果您有可能有助于解决问题的信息，请仅发表评论（在这种情况下；为上游内核提供补丁可能是最好的步骤）。

如果您想知道您也有此问题，请使用顶部描述中的“竖起大拇指”按钮：

如果您想随时了解更新，请使用_订阅按钮_。

这里的每条评论都会向超过 3000 人发送一封电子邮件/通知，我不想锁定关于此问题的对话，因为它尚未解决，但如果您忽略这一点，可能会被迫这样做。

我将删除不添加有用信息的评论，以（稍微）缩短线程

如果您想帮助解决此问题

• 阅读整个线程； 它很长，而且 github 隐藏了评论（因此您必须单击才能再次显示这些评论）。 如果此线程中已经提供了很多可能对您有所帮助的信息
• 阅读此评论https://github.com/moby/moby/issues/5618#issuecomment -316297818（以及当时的评论）以获取有用的信息。

谢谢！

我相信我已经解决了这个问题，至少是由内核 TCP 套接字连接引起的。 Ubuntu 的测试内核可用，如果他们为这里的任何人提供帮助/修复此问题，我会很乐意提供反馈。 补丁被上游提交； 更多细节在 LP 错误中：
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/comments/46

很抱歉破坏了庆祝活动，但我们能够重现该问题。 我们现在正在https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/上与@ddstreet合作。

没有解决方法吗？

使用主机网络（这会破坏容器的大部分价值，但你去了）。

@pumba-lt 我们在大约 1.5 年前遇到了这个问题，大约 1 年前我在内核级别（不是 sysctl）禁用了 ipv6，并且一次都没有遇到过这个问题。 运行 48 个刀片的集群。

通常在： /etc/default/grub
GRUB_CMDLINE_LINUX="xxxxx ipv6.disable=1"

但是，我使用 PXE 启动，所以我的 PXE 配置有：

      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

我向你保证，你不会再看到这个问题了。

请大家理解这是一个常见的症状，原因很多。 对您有效以避免这种情况的方法对其他人可能无效。

我可以确认在启动时禁用 IPv6 后我们的问题已经解决（从 grub 的配置文件）。 在 7 节点集群中出现了许多问题，现在运行顺利。

我不记得我在哪里找到了解决方案，还是我自己找到的，无论如何，感谢@qrpike向其他人提出这个建议:) !!

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

提交 edaafa805e0f9d09560a4892790b8e19cab8bf09
作者：Dan Streetman [email protected]
日期：2018 年 1 月 18 日星期四 16:14:26 -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]>

在 netns 中使用 SCTP 也可能触发此问题，在 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

尽管我已经将内核版本升级到 4.4.118 和 docker 版本 17.09.1-ce，但仍然发生“unregister_netdevice: waiting for eth0 to be free. Usage count = 1”，也许我应该尝试在内核级别禁用 ipv6。 希望它云工作。

@wuming5569请告诉我它是否适用于该版本的 linux

@wuming5569也许，升级内核 4.4.114 修复“unregister_netdevice：等待 lo 变为空闲。使用计数 = 1”，而不是“unregister_netdevice：等待 eth0 变为空闲。使用计数 = 1”。
我在生产中进行了测试。
@ddstreet这是一个反馈，有什么帮助吗？

@wuming5569如上所述，他们自己的消息是良性的，但最终可能会导致内核挂起。 您的内核是否挂起，如果是，您的网络模式是什么，即您的容器使用什么类型的网络？

在 CentOS 上遇到同样的问题。 我的内核是 3.10.0-693.17.1.el7.x86_64。 但是，我在 syslog 中没有得到类似的堆栈跟踪。

Centos7 内核 3.10.0-514.21.1.el7.x86_64 和 docker 18.03.0-ce 相同

@danielefranceschi我建议您升级到最新的 CentOS 内核（至少 3.10.0-693）。 它不会解决问题，但它似乎不那么频繁。 在内核 3.10.0-327 和 3.10.0-514 中，我们看到了堆栈跟踪，但根据我的记忆，我认为我们没有看到 3.10.0-693 中的任何一个。

@alexhexabeam 3.10.0-693 似乎完美无缺，tnx :)

在 CentOS7 内核 4.16.0-1.el7.elrepo.x86_64 和 docker 18.03.0-ce 上相同

它在崩溃前工作了数周，什么时候尝试起来，它完全卡住了。

内核 3.10.0-693.21.1.el7 也出现了这个问题

我可以确认它也发生在：

Linux 3.10.0-693.17.1.el7.x86_64
红帽企业 Linux 服务器 7.4 版 (Maipo)

我可以通过在有一定负载量的情况下执行“service docker restart”来重现它。

@wuming5569你解决这个问题了吗？你的网络类型是什么？ 数周以来，我们一直对这个问题感到困惑。
你有微信账号吗？

4admin2root，鉴于你提到的修复， https: //cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.114，

如果安装了正确的最新内核，禁用 docker 守护进程的用户空间代理是否安全？ 不是很清楚是不是来自

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

由于两者都比内核修复程序旧

谢谢

数周以来，我们一直对这个问题感到困惑。
Linux 3.10.0-693.17.1.el7.x86_64
CentOS Linux 版本 7.4.1708（核心）

谁能确认最新的 4.14 内核是否有这个问题？ 好像没有。 互联网上没有人遇到过 4.14 内核的这个问题。

我在 4.15.15-1 内核中看到了这个，Centos7

查看更改日志， https: //cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.15.8 修复了 SCTP，但没有修复 TCP。 所以你可能想尝试最新的 4.14。

• 即使 4.15.18 也无助于解决此错误
• 禁用 ipv6 也无济于事

我们现在已经升级到 4.16.13。 观察。 这个错误每周只在一个节点上攻击我们一次。

您是否在 grub 引导参数或 sysctl 中禁用了 ipv6？ 只有引导参数会起作用。 Sysctl 不会修复它。

2018 年 6 月 4 日下午 12:09:53，Sergey Pronin ( [email protected] (mailto:[email protected])) 写道：

即使 4.15.18 也无助于解决此错误
禁用 ipv6 也无济于事

我们现在已经升级到 4.16.13。 观察。 这个错误每周只在一个节点上攻击我们一次。

—
你收到这个是因为你被提到了。
直接回复本邮件，在 GitHub 上查看（https://github.com/moby/moby/issues/5618#issuecomment-394410321），或者将线程静音（https://github.com/notifications/unsubscribe-auth /AAo3HLYI_jnwjgtQ0ce-E4mc6Em5yeISks5t5VvRgaJpZM4B4L4Z）。

对我来说，大多数情况下，再次重新部署相同的项目/网络后会出现错误

@qrpike你是对的，我们只试过 sysctl。 让我用 grub 试试。 谢谢！

4.9.88 Debian 内核。 可重现。

@qrpike你是对的，我们只试过 sysctl。 让我用 grub 试试。 谢谢！

在我的情况下，禁用 ipv6 没有任何区别。

@spronin-aurea 在引导加载程序中禁用 ipv6 有帮助吗？

@qrpike如果禁用 ipv6 对您有帮助，您能告诉我们您正在使用的节点吗？ 内核版本、k8s 版本、CNI、docker 版本等。

@komljen在过去的 2 年

在我这边，我也在使用 CoreOS，使用 grub 禁用了 ipv6 并且仍然遇到问题

@deimosfr我目前正在为我的所有节点使用 PXE 启动：

      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

但是，我的主节点即 PXE 主机也是 CoreOS 并从磁盘启动，也没有问题。

你们正在运行什么内核版本？

我遇到的问题是在 4.14.32-coreos 和之前。 我在 4.14.42-coreos 上还没有遇到这个问题

Centos 7.5 与 4.17.3-1 内核，仍然有问题。

环境：
Kubernetes 1.10.4
码头工人 13.1
带有法兰绒网络插件。

日志 ：
[89.790907]IPv6：ADDRCONF（NETDEV_UP）：eth0：链接未准备好
[89.798523]IPv6：ADDRCONF（NETDEV_CHANGE）：eth0：链接准备就绪
[89.799623] cni0：端口 8（vethb8a93c6f）进入阻塞状态
[89.800547] cni0：端口 8（vethb8a93c6f）进入禁用状态
[89.801471] 设备 vethb8a93c6f 进入混杂模式
[89.802323] cni0：端口 8（vethb8a93c6f）进入阻塞状态
[89.803200] cni0：端口 8（vethb8a93c6f）进入转发状态

kernel:unregister_netdevice : 等待 lo 空闲。 使用次数 = 1。

现在 ：
节点IP可以到达，但不能使用任何网络服务，如ssh...

这里的症状和其他地方的很多报道很相似。 所有这些都与网络命名空间有关。 遇到此问题的人能否查看unshare -n挂起，如果是，则从另一个终端执行取消共享过程的cat /proc/$pid/stack以查看它是否挂在copy_net_ns() ？ 这似乎是许多问题的共同点，包括此处发现的一些回溯。 在 4.16 和 4.18 之间，Kirill Tkhai 发布了许多补丁，对涉及的锁定进行了大量重构。 受影响的发行版/内核包维护者可能应该考虑将它们应用/反向移植到稳定的内核中，看看是否有帮助。
另见： https :

@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

鉴于 4.18 中的锁定更改，最好测试当前的 4.18rc，特别是如果您可以或多或少地可靠地触发它，因为据我所知，有很多人更改内核版本也会改变这种情况发生的可能性很多。

我在 Kubernetes 上遇到了这个问题，在切换到最新的 CoreOS 稳定版本 - 1745.7.0 后，问题消失了：

• 内核：4.14.48
• 码头工人：18.03.1

CentOS 7 上的相同问题

• 内核：4.11.1-1.el7.elrepo.x86_64
• 码头工人：17.12.0-ce

@Blub在 CoreOS 1688.5.3、内核 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

理论上，某处可能存在一个或多个其他跟踪，其中包含来自 net_namespace.c 的函数之一，锁定net_mutex ( cleanup_net , net_ns_barrier , net_ns_init , {,un}register_pernet_{subsys,device} ）。 对于稳定的内核，如果有一个特定的事情以一种可以修复的方式死锁，当然比从 4.18 向后移植所有锁定更改要容易得多。 但到目前为止，我还没有看到导致根本原因的痕迹。 我不知道它是否会有所帮助，但是当问题出现时，也许可以看到具有上述功能的其他/proc/*/stack ？

同样的问题！ 我的环境是 debian 8

RHEL，群，18.03.0-ce

1. 通过 ssh 连接到管理节点

2. 在管理节点上手动启动容器：

   sudo docker run -it -v /import:/temp/eximport -v /home/myUser:/temp/exhome docker.repo.myHost/ fedora:23 /bin/bash

3. 一段时间后什么都不做：

   [ root@8a9857c25919 myDir]#
   7 月 19 日 11:56:03 来自syslogd@se1-shub-t002 的消息...
   kernel:unregister_netdevice : 等待 lo 空闲。 使用次数 = 1

几分钟后，我回到管理器节点的控制台，启动的容器不再运行。

这是描述相同的问题还是另一个“问题套件”？

提前谢谢！

更新
这也直接发生在 ssh 控制台上（在 swarm manager bash 上）。

更新
主机（集群中的一个管理节点）：
Linux [MACHINENNAME] 3.10.0-514.2.2.el7.x86_64 #1 SMP Wed 16 13:15:13 EST 2016 x86_64 x86_64 x86_64 GNU/Linux

如果这在一段时间后没有解决，那么这是一个不同的问题。

在 CentOS7.5 内核 3.10.0-693.el7.x86_64 和 docker 1.13.1 上相同

同样的问题 OEL 7.5
uname -a
4.1.12-124.16.1.el7uek.x86_64 #2 SMP Mon Jun 11 20:09:51 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
码头工人信息
容器：9
跑步：5
暂停：0
停止：4
图片：6
服务器版本：17.06.2-ol

消息
[2238374.718889] unregister_netdevice：等待 lo 变为空闲。 使用次数 = 1
[2238384.762813] unregister_netdevice：等待 lo 变为空闲。 使用次数 = 1
[2238392.792585] eth0：从 vethbed6d59 重命名

（在这里再次重复这个 https://github.com/moby/moby/issues/5618#issuecomment-351942943，因为 GitHub 隐藏了旧评论）

如果你到达这里

此处讨论的问题是内核错误，尚未完全修复。 内核中的一些补丁修复了此问题的_some_ 出现，但其他补丁尚未解决。

有许多选项可能对_某些_情况有帮助，但并非对所有情况都有帮助（同样；这很可能是触发相同错误的问题的组合）

“unregister_netdevice: waiting for lo to become free”错误本身不是错误

如果内核崩溃_after_那是一个错误（见下文）

不要留下“我也有这个”的评论

“我也有这个”无助于解决错误。 如果您有可能有助于解决问题的信息，请仅发表评论（在这种情况下；为上游内核提供补丁可能是最好的步骤）。

如果您想知道您也有此问题，请使用顶部描述中的“竖起大拇指”按钮：

如果您想随时了解更新，请使用_订阅按钮_。

这里的每条评论都会向超过 3000 人发送一封电子邮件/通知，我不想锁定关于此问题的对话，因为它尚未解决，但如果您忽略这一点，可能会被迫这样做。

我将删除不添加有用信息的评论，以（稍微）缩短线程

如果您想帮助解决此问题

• 阅读整个线程，包括那些隐藏的评论； 它很长，而且 github 隐藏了评论（因此您必须单击才能再次显示这些评论）。 如果此线程中已经提供了很多可能对您有所帮助的信息

• 阅读此评论https://github.com/moby/moby/issues/5618#issuecomment -316297818（以及当时的评论）以获取有用的信息：

需要明确的是，消息本身是良性的，它是 OP 报告的消息后内核崩溃，而不是。

代码中的注释，即这条消息的来源，解释了正在发生的事情。 基本上，网络设备的每个用户（例如 IP 堆栈）（例如容器内的veth对的末尾）在使用网络设备时都会增加网络设备结构中的引用计数。 当设备被移除时（例如，当容器被移除时），每个用户都会收到通知，以便他们可以在减少引用计数之前进行一些清理（例如关闭打开的套接字等）。 因为这种清理可能需要一些时间，尤其是在重负载（大量接口、大量连接等）的情况下，内核可能会偶尔在此处打印消息。

如果网络设备的用户从不减少引用计数，内核的其他部分将确定等待清理的任务卡住并崩溃。 只有这次崩溃表明存在内核错误（某些用户通过某些代码路径没有减少引用计数）。 有几个这样的错误，它们已在现代内核中得到修复（并且可能回移植到旧内核）。 我已经编写了相当多的压力测试（并继续编写它们）来触发此类崩溃，但无法在现代内核上重现（但是我会执行上述消息）。

* 请仅在您的内核确实崩溃时报告此问题*，然后我们将非常感兴趣：

• 内核版本（ uname -r ）
• Linux 发行版/版本
• 您使用的是 Linux 供应商的最新内核版本吗？
• 网络设置（桥接、覆盖、IPv4、IPv6 等）
• 工作负载描述（什么类型的容器，什么类型的网络负载等）
• 理想情况下是简单的复制

谢谢！

你们在任何限制下运行 docker 吗？ 像ulimits，cgroups等...

即使您没有设置，较新的 systemd 也有默认限制。 我将事情设置为无限制，从那以后就没有发生过这个问题（从 31 天开始观看）。

我在许多环境中都遇到了同样的问题，我的解决方案是停止防火墙。 暂时没有再发生

Rhel 7.5 - 3.10.0-862.3.2.el7.x86_64
码头工人 1.13

@dElogics哪个版本的 systemd 被认为是“较新的”？ CentOS 7.5 systemd 中是否启用了此默认限制？

另外，当您问我们是否在任何限制下运行 docker 时，您是指 docker 守护进程还是单个容器？

docker 守护进程。 Debian 9 (232-25) 中的 systemd。

不确定 RHEL，但我个人也在 RHEL 上看到过这个问题。 我会设置 LimitNOFILE=1048576, LimitNPROC=infinity, LimitCORE=infinity, TasksMax=infinity

内核：unregister_netdevice：等待 eth0 空闲。 使用次数 = 3
内核 4.4.146-1.el7.elrepo.x86_64
linux 版本 CentOS Linux release 7.4.1708 (Core)
桥接模式

我有同样的问题，我该怎么办？

同样的问题：

CentOS Linux 版本 7.5.1804（核心）
Docker 版本 18.06.1-ce，构建 e68fc7a
内核版本：3.10.0-693.el7.x86_64

我在这里遇到的类似问题...
我现在有什么动作可以表演吗？ 请帮帮我...

CentOS 7.0.1406
[ root@zjsm-slavexx等]# uname -a
Linux zjsm-slave08 3.10.0-123.el7.x86_64 #1 SMP Mon Jun 30 12:09:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[ root@zjsm-slavexx etc]# cat /etc/centos-release
CentOS Linux 7.0.1406 版（核心）

码头工人信息：
[ root@zjsm-slavexx ~]#
客户：
版本：17.04.0-ce
API 版本：1.28
Go 版本：go1.7.5
Git 提交：4845c56
内置：2017 年 4 月 3 日星期一 18:01:50
操作系统/架构：linux/amd64

服务器：
版本：17.04.0-ce
API 版本：1.28（最低版本 1.12）
转版本：go1.7.5
Git 提交：4845c56
内置：2017 年 4 月 3 日星期一 18:01:50
操作系统/架构：linux/amd64
实验：假

CentOS Linux 7.2.1511 版本内核：3.10.0-327.el7.x86_64
同样的问题

我已经试验过这个问题。

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 ，也许您应该将您的评论添加到原始帖子的顶部，因为人们仍然忽略它。

$ 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 

修复。

@hzbd你的意思是删除用户定义的桥接网络？ 您是否尝试进一步挖掘以找出原因？ 如果你这样做了，请告诉我。 我真的很感激。

等待修复

你们在任何限制下运行 docker 吗？ 像ulimits，cgroups等...

即使您没有设置，较新的 systemd 也有默认限制。 我将事情设置为无限制，从那以后就没有发生过这个问题（从 31 天开始观看）。

好吧，这个bug还是出现了，但是概率降低了。

我认为如果容器正常停止（PID 1存在（）s），那么这个错误不会打扰我们。

@dElogics感谢您让我们知道，您能否告诉我们您运行了哪些命令来将此 systemd 限制设置为无限制。 我也喜欢尝试。

@dElogics感谢您让我们知道，您能否告诉我们您运行了哪些命令来将此 systemd 限制设置为无限制。 我也喜欢尝试。

您必须修改 docker 的 systemd 单元。 我使用的 systemd 单元（仅相关部分）-

[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

有人在内核 4.15 或更新版本中遇到过这个问题吗？

这个 Dan Streetman 修复（https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d）首先包含在 4.15 内核版本中，似乎至少对于某些人来说，自从他们升级到 4.16 后就不再发生这种情况了（https：/ /github.com/kubernetes/kubernetes/issues/64743#issuecomment-436839647)

有人试过吗？

@victorgp我们仍然遇到 4.15 内核的问题。 当我们使用 4.16 内核进行测试时（希望在几周内），我们将在此处报告。

我们使用内核版本：4.14.62几个月了，这个问题消失了。

添加到我以前的决议 - 一个优雅停止的容器（响应 SIGTERM）永远不会触发这个。

还尝试在主机命名空间中运行容器（如果您可以接受的话），这完全解决了问题。

@dElogics “主机命名空间”是什么意思？ 它只是--privileged吗？

@dElogics “主机命名空间”是什么意思？ 它只是--privileged吗？

不，这意味着 --network=host

由于从内核 4.4.0 升级到 4.15.0 和 docker 1.11.2 到 18.09，问题消失了。

在充当 Docker 主机的大量 VM 中，我们每天都会多次遇到此问题（使用我们的 Docker 用例）。
45 天后，我们再也看不到这种情况了。

对于后代，可以在http://paste找到挂起的 Docker 1.11.2 的堆栈跟踪，带有 printk 的显示unregister_netdevice: waiting for vethXXXXX （类似于我们一直在我们的车队中看到的数百个 VM） .ubuntu.com/p/6RgkpX352J/ （有趣的容器引用是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

从中我们可以观察到它挂在https://github.com/moby/moby/blob/v1.11.2/daemon/container_operations.go#L732

这将我们指向https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/sandbox.go#L175

和
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/endpoint.go#L760

哪个进入 libnetwork 网桥驱动程序（检查真棒描述）
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go#L1057 -L1061

搬到网联
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

最终在那个 netlink 套接字中，调用https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go#L333

我们认为该错误通常发生在停止容器时，并且由于在 netns 中仍然引用了 SKB，因此 veth 没有被释放，然后 Docker 在 15 秒后向该容器发出 Kill。 Docker 守护进程并不能很好地处理这种情况，但最终问题出在内核中。 我们认为https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d （上游 4.15 接受）和与之相关的提交（有几个）可以作为缓解措施。

一般来说，内核的那部分不是一个漂亮的地方。

就其价值而言……我们将 RHEL Linux 内核从 3.10.0 升级到 4.17.11。 （运行 Kubernetes 集群）。 在升级之前，这个错误每天都会在不同的服务器上发生几次。 现在运行升级三周。 错误只发生一次。 所以粗略地说是减少了99%。

@marckamerbeek您是否将 RHEL 内核更新为社区内核？ 然后就不再支持了。

@Beatlor CentOS 用户可以这样做。

centos 7.2 还是有这个问题： kernel:unregister_netdevice : 等待 lo 成为 free。 使用次数 = 1

@Beatlor RHEL 根本没有帮助我们。 一个稳定的生产环境比一些毫无价值的支持合同更重要。 我们现在仍然在 4.17.11 上运行非常稳定。 没有大问题了。

@Beatlor RHEL 根本没有帮助我们。 一个稳定的生产环境比一些毫无价值的支持合同更重要。 我们现在仍然在 4.17.11 上运行非常稳定。 没有大问题了。

是的，我升级内核到4.17.0-1.el7.elrepo.x86_64后也没有这个问题。 我之前尝试过（4.4.x、4.8、4.14..）但它失败了。 看来这个问题在4.17+内核中不会再出现了。

centos 7.2 还是有这个问题： kernel:unregister_netdevice : 等待 lo 成为 free。 使用次数 = 1

您可以尝试升级到最新的 4.19+ 内核。

只需等待几个月，就会有人抱怨 4.19 内核。 只是历史重演。

大家好，好消息！

自从我上次在这里发表评论（在撰写本文时，17 天前）以来，我再也没有遇到这些错误。 我的服务器（大约有 30 个）运行 ubuntu 14.04 和一些过时的软件包。

在完整的系统升级包括 docker-engine（从 1.7.1 到 1.8.3）+内核升级到 ubuntu 存储库上的最新可能版本后，我的服务器正在运行，没有发生任何事情。

🎱

你升级哪个内核版本？

可能与此有关https://github.com/torvalds/linux/commit/f186ce61bb8235d80068c390dc2aad7ca427a4c2

下面是一个试图总结这个问题，从这个问题，提出的意见https://github.com/kubernetes/kubernetes/issues/70427 ， https://github.com/kubernetes/kubernetes/issues/64743和HTTPS： //access.redhat.com/solutions/3659011

观察到有此问题的内核版本

• RHEL7 3.10.0-862
• 4.15.0
• 4.20.0

内核版本声称不会触发此问题

• RHEL7 3.10.0-957.10.1
• 4.19.12
• 4.17.0
• 4.17.11

相关内核提交

• https://github.com/torvalds/linux/commit/f186ce61bb8235d80068c390dc2aad7ca427a4c2 - 从 4.12 开始
• https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d - 从 4.15 开始
• https://github.com/torvalds/linux/commit/ee60ad219f5c7c4fb2f047f880377770063ef785f - 从 5.1 开始

我挑战https://github.com/kubernetes/kubernetes/issues/70427#issuecomment -470681000，因为我们在 4.15.0 中没有看到这种带有数千个 VM 的情况，而我们在 4.4 上每天看到它几十次。 0，4.15.0有更多的报道吗？

我在我的一台在 Debian 9 Stretch ( 4.9.0-8-amd64 ) 上运行 Docker 的机器上看到了这个问题。 我通过 Docker Gen 在 Docker 容器中创建的隧道遇到了这个问题，它会产生内核恐慌：

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

这是我们的 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

有人知道在不重新启动整个机器的情况下是否可以临时解决此问题吗？ 当我们遇到这个问题时，我们真的不想重启整个机器。

有点跑题，我们也不能抑制终端内的内核恐慌消息。 我试过dmesg -D和dmesg -n 1 。 然而，没有运气。 有没有办法从终端内抑制这些类型的内核恐慌消息？ 尝试键入命令并每隔 10 秒左右弹出该消息是很烦人的。

谢谢。

这些是香草内核还是被发行版大量修补并带有向后移植的修复程序？

@pmoust我每周都会在 ubuntu 4.15.0-32 上看到这个。 自 4.4.0 以来肯定好多了

@iavael如果参考提供了它，我将尝试在摘要中列出发行版信息。

有人在 4.19 中看到过这个错误吗？

有人在 4.19 中看到过这个错误吗？

https://github.com/kubernetes/kubernetes/issues/64743#issuecomment -451351435
https://github.com/kubernetes/kubernetes/issues/64743#issuecomment -461772385

这些信息可能对您有所帮助。

@tankywoo @drpancake @egasimus @csabahenk @spiffytech @ibuildthecloud @sbward @jbalonso @rsampaio @MrMMorris @rsampaio @unclejack @chrisjstevenson @popsikle @fxposter @ scher200 @victorgp @jstangroome @ Xuexiang825 @dElogics @Nowaker @pmoust @marckamerbeek @Beatlor @warmchang @Jovons @ 247687009 @jwongz @ tao12345666333 @clkao请看这个https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs-while-testing-tidb-operator-in-k8s/

@tankywoo @drpancake @egasimus @csabahenk @spiffytech @ibuildthecloud @sbward @jbalonso @rsampaio @MrMMorris @rsampaio @unclejack @chrisjstevenson @popsikle @fxposter @ scher200 @victorgp @jstangroome @ Xuexiang825 @dElogics @Nowaker @pmoust @marckamerbeek @Beatlor @warmchang @Jovons @247687009 @jwongz @tao12345666333 @clkao请看这个https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs-while-testing-tidb-operator-in-k8s/

我遵循了文档，但仍然出现错误。

[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

该消息本身不是错误； 之后内核崩溃了； https://github.com/moby/moby/issues/5618#issuecomment -407751991

@tankywoo @drpancake @egasimus @csabahenk @spiffytech @ibuildthecloud @sbward @jbalonso @rsampaio @MrMMorris @rsampaio @unclejack @chrisjstevenson @popsikle @fxposter @ scher200 @victorgp @jstangroome @ Xuexiang825 @dElogics @Nowaker @pmoust @marckamerbeek @Beatlor @warmchang @Jovons @247687009 @jwongz @tao12345666333 @clkao请看这个https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs-while-testing-tidb-operator-in-k8s/

我遵循了文档，但仍然出现错误。

[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

重启后，ok...

@vincent927顺便说一句，你应该把 livepatch_route.ko 放到 /var/lib/kpatch/$(uname -r)，当启用 kpatch.service 时，ko 可以在重启后自动加载。

我们今天突然在公司的几个 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 （服务器）：
  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"}

我们还不知道原因； 我们已经运行上述软件的这些版本几个月了，没有出现任何问题。 我现在只是评论添加到“遇到此错误的软件版本”列表中。

@2rs2ts您是否尝试过https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs-while-testing-tidb-operator-in-k8s/？

@ethercflow我已经读过，但是由于我们在我的公司运行 Debian，因此我们在该帖子中实施修复程序并不简单。

@ethercflow @2rs2ts我们也在运行 debian。 我在尝试让 kpatch-build 工作时遇到了很多问题。 如果我设法找到解决方法，我会及时通知您。 无论如何，有人有其他解决方案吗？ 是内核版本 4.15 还是 4.19 缓解了这个问题？ 过去一周我一直在努力寻找答案，但仍然没有找到。

@commixon我们的经验仍然与https://github.com/moby/moby/issues/5618#issuecomment -455800975 中报告的相同，在数千个 VM 的队列中没有再次出现问题 w/ 4.15.0 Canonical 提供的内核的通用、AWS 优化和 GCP 优化风格。 对 vanilla 4.15.0 的有限测试也没有显示任何这些问题，但没有进行大规模测试。

非常感谢@pmoust 。 将尝试他们。 无论如何，我也会尝试修补 kpatch 以与 Debian 一起工作（作为一个辅助项目），并在此处为感兴趣的任何人发布更新。

@ethercflow @2rs2ts我们也在运行 debian。 我在尝试让 kpatch-build 工作时遇到了很多问题。 如果我设法找到解决方法，我会及时通知您。 无论如何，有人有其他解决方案吗？ 是内核版本 4.15 还是 4.19 缓解了这个问题？ 过去一周我一直在努力寻找答案，但仍然没有找到。

您可以升级到 4.19。 它在后台。

顺便说一句，我们在这里已经一年了。 ;)

我们实际上在 backports 中尝试了 4.19，但它在其他方面有一些重大的回归（EC2 实例只是随机重启，然后在启动时网络会中断。）我猜我们将不得不处理这个直到下一个稳定。

@2rs2ts在过去的 4 天里，我们从 backports（在 EC2 中）使用 4.19，我们根本没有发现任何问题。 内核崩溃问题根本没有出现，其他一切似乎也很好。 我认为这没有任何区别，但我们将 Debian 映像基于 kops (https://github.com/kubernetes/kops/blob/master/docs/images.md#debian) 提供的映像。 我们更新了此映像中的内核，而不是原始 debian。

朋友们，我用4.19内核稳定运行半年了。 我希望你也能享受稳定。

我有一个容器每两周打开 80 和 443 端口，从另一个计算机访问容器 80 和
443是拒绝

centos7.3内核版本为：
Linux 浏览器 1 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

root@browser1 ~]#
客户：
版本：18.06.3-ce
API 版本：1.38
转版本：go1.10.4
Git 提交：d7080c1
内置：2019 年 2 月 20 日星期三 02:24:22
操作系统/架构：linux/amd64
实验：假

服务器：
引擎：
版本：18.06.3-ce
API 版本：1.38（最低版本 1.12）
转版本：go1.10.3
Git 提交：d7080c1
内置：2019 年 2 月 20 日星期三 02:25:33
操作系统/架构：linux/amd64
实验：假
[ root@browser1 ~]#

留言：

[1063959.636785] unregister_netdevice：等待 lo 变为空闲。 使用次数 = 1
[1071340.887512] br-af29e1edc1b8：端口5（vethc2ac4f8）进入禁用状态
[1071340.891753] br-af29e1edc1b8：端口5（vethc2ac4f8）进入禁用状态
[1071340.895118] 设备 vethc2ac4f8 左混杂模式
[1071340.895138] br-af29e1edc1b8：端口5（vethc2ac4f8）进入禁用状态
[1071340.990505] 设备 veth5e4f161 进入混杂模式
[1071340.990897] IPv6：ADDRCONF(NETDEV_UP)：veth5e4f161：链接未准备好
[1071340.990904] br-af29e1edc1b8：端口5（veth5e4f161）进入转发状态
[1071340.990924] br-af29e1edc1b8：端口5（veth5e4f161）进入转发状态
[1071341.231405] IPv6：ADDRCONF(NETDEV_CHANGE)：veth5e4f161：链接准备好
[1071355.991701] br-af29e1edc1b8：端口5（veth5e4f161）进入转发状态
[1071551.533907] br-af29e1edc1b8：端口5（veth5e4f161）进入禁用状态
[1071551.537564] br-af29e1edc1b8：端口5（veth5e4f161）进入禁用状态
[1071551.540295] 设备 veth5e4f161 左混杂模式
[1071551.540313] br-af29e1edc1b8：端口5（veth5e4f161）进入禁用状态
[1071551.570924] 设备 veth8fd3a0a 进入混杂模式
[1071551.571550] IPv6：ADDRCONF(NETDEV_UP)：veth8fd3a0a：链接未准备好
[1071551.571556] br-af29e1edc1b8：端口5（veth8fd3a0a）进入转发状态
[1071551.571582] br-af29e1edc1b8：端口5（veth8fd3a0a）进入转发状态
[1071551.841656] IPv6：ADDRCONF(NETDEV_CHANGE)：veth8fd3a0a：链接准备就绪
[1071566.613998] br-af29e1edc1b8：端口5（veth8fd3a0a）进入转发状态
[1071923.465082] br-af29e1edc1b8：端口5（veth8fd3a0a）进入禁用状态
[1071923.470215] br-af29e1edc1b8：端口5（veth8fd3a0a）进入禁用状态
[1071923.472888] 设备 veth8fd3a0a 左混杂模式
[1071923.472904] br-af29e1edc1b8：端口5（veth8fd3a0a）进入禁用状态
[1071923.505580] 设备 veth9e693ae 进入混杂模式
[1071923.505919] IPv6：ADDRCONF(NETDEV_UP)：veth9e693ae：链接未准备好
[1071923.505925] br-af29e1edc1b8：端口5（veth9e693ae）进入转发状态
[1071923.505944] br-af29e1edc1b8：端口5（veth9e693ae）进入转发状态
[1071923.781658] IPv6：ADDRCONF(NETDEV_CHANGE)：veth9e693ae：链接准备就绪
[1071938.515044] br-af29e1edc1b8：端口5（veth9e693ae）进入转发状态

有人在 4.19 中看到过这个错误吗？

是的。 我在内核 4.19.4-1.e17.elrep.x86_64 上有问题

你好，

我也看到了这个错误。 对于这个问题，我们有什么解决方案吗？ 内核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

这个问题仍然发生:(没有关于如何解决的更新/想法？

发生在 Debian Stretch 上。 发生这种情况时，我试图通过 Ansible 更新我的 Jenkins 容器。

此提交已解决此问题：
https://github.com/torvalds/linux/commit/ee60ad219f5c7c4fb2f047f880377770063ef785f
使用 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

此提交已解决此问题：
Torvalds/ linux@ee60ad2
使用 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

这必须在 4.19.30 之后。

我不确定torvalds / https://github.com/torvalds/linux/commit/deed49df7390d5239024199e249190328f1651e45中只添加了 0。

我们使用诊断内核重现了相同的错误，该内核具有人为插入的延迟以使 PMTU 发现异常路由命中此窗口。

1. 调试内核补丁：