eth0についても非常によく似た問題が発生しています。 Ubuntu12.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

ねえ、これは私にも起こり始めたばかりです。

Dockerバージョン：

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

カーネルログ： http ：

システムの詳細：
パッチが適用されたカーネル（3.14.3-rt4）でUbuntu 14.04LTSを実行します。 しかし、それがデフォルトのlinux-3.13.0-27-genericカーネルで発生することを確認します。 ただし、面白いのは、これが発生すると、すべてのターミナルウィンドウがフリーズし、その前にせいぜい数文字を入力できるようになることです。 同じ運命は私が開いた新しいものにも当てはまります-そして私は上記の良い医者のように私の貧しいラップトップの電源を入れ直す必要があります。 記録のために、私はurxvtでfish shellを実行しているか、xmonadでxtermを実行しています。 プレーンバッシュに影響するかどうかはチェックしていません。

これは関連している可能性があります：
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065434#yui_3_10_3_1_1401948176063_2050

コンテナ内のネットワークを介してかなり大量のデータをコピーする
その後、コンテナを終了すると、あたりのデクリメントが失われる可能性があります
ネットワークデバイスのCPU参照カウント。

案の定、これが私に起こったのは、 apt-get大量の依存関係を持つパッケージを作成した直後

Ubuntu 12.04.3から14.04にアップグレードすると、他の変更なしでこれが修正されました。

私はこれをRHEL7、3.10.0-123.4.2.el7.x86_64で経験します

3.14-rt4を実行しているときに、VirtualBox仮想ネットワークインターフェイスで同じことが起こっていることに気づきました。 バニラ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を実行しているUbuntu14.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-generic

Ubuntu 14.04サーバーで、私のチームは3.13.0-40-genericから3.13.0-32-genericにダウングレードすると問題が「解決」することを発見しました。 @sbwardの観察を考えると、回帰は3.13.0-32-genericの後、3.13.0-37-genericの前（またはそれを含む）になります。

私たちの場合、時々_負の_使用数が表示されることを付け加えておきます。

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

Ubuntu14.04とDebianjessie w / kernel3.16.xでこれに遭遇しました。

Dockerコマンド：

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

これはかなり悪い問題のようです...

@jbalonso 3.13.0-32-genericを

@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を使用してシステムを最新の状態に保ち、更新をインストールした後に再起動する必要があります。

この問題を報告するときは、システムに完全にパッチが適用され、ディストリビューションのベンダーが提供する最新の安定したアップデート（手動でインストールされたexperimental / tests / alpha / beta / rcパッケージがない）で最新であることを確認してください。

@unclejack

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

ubuntu 14.043.13.0-46-ジェネリック

docker runつだけ実行しても、エラーが発生します

必要に応じて複製用のAMIを作成できます

@MrMMorris Ubuntu14.04の最新のカーネルパッケージでまだ問題があることを確認していただきありがとうございます。

私が助けるために他にできることは何でも、私に知らせてください！ ：笑顔：

@MrMMorris再現機能を提供できる場合は、Ubuntuで開かれているバグがあり、非常に高く評価されます： https ：

@rsampaio今日時間があれば、間違いなくあなたのためにそれを手に入れます！

この問題は、Debian7とDebian8の両方の3.16（.7）でも発生します： https ：//github.com/docker/docker/issues/9605#issuecomment-85025729。 今のところ、サーバーを再起動することがこれを修正する唯一の方法です。

一部のDockerコンテナー（すべてのコンテナーではない）を起動すると、カーネル2.6.32-504.8.1.el6.x86_64を使用するRHEL6.6でこの問題が発生します。
_ kernel：unregister_netdevice ：loが解放されるのを待っています。 使用回数= -1_

繰り返しになりますが、現時点ではサーバーの再起動が唯一の解決策のようです

カーネル3.19.3を搭載したCoreOS（647.0.0）でもこれが見られます。

再起動も私が見つけた唯一の解決策です。

sidのカーネル（4.0.2）でDebianjessieをテストしました-問題は残っています。

Ubuntu以外のコンテナを実行しているときにこの問題が発生するのを見た人はいますか？

はい。 Debianのもの。
2015年6月19日 19：01пользователь "popsikle" [email protected]
написал：

Ubuntu以外のコンテナを実行しているときにこの問題が発生するのを見た人はいますか？

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/5618#issuecomment-113556862 。

これはカーネルの問題であり、イメージ関連の問題ではありません。 別の画像に切り替えても、この問題は改善または悪化しません。

4.1.2-bone12カーネルを実行しているBeagleBoneBlackでDebianJessieの問題が発生しています

4.1.2から4.2-rc2に切り替えた後の経験（1.8.0のgitビルドを使用）。
/ 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でも見ました。 デバイスのリークに関するバグは1つではありません:)高負荷で4.1以上のカーネルで再現できます。

私もこの問題を抱えていました。 Ubuntu 3.13.0-57-汎用、tutum経由でプロビジョニング。 残念ながら、kern.logとsyslogがいっぱいになり、マシンがクラッシュします。 これはデータベースマシン（dockerized postgres）で発生するため、システム全体がダウンします...

「私も」の合唱に加わって、ローカルのプライベートDockerリポジトリからDockerイメージをプルしているときに、RancherOS（最小OS）0.3.3を実行しているクラウドスタックVMでこの問題が発生しています。 それは10秒ごとに起こっていますが、それが何かを意味するかどうかはわかりません。

4.2-rc7でもこの問題が発生しています

これに関するニュースはありますか？どのカーネルを使用する必要がありますか？ 完全に最新のカーネル（Ubuntu 14.04では3.19.0-26）でも発生し続けます

私たちもこの問題を抱えています。 これは、userland-proxy = falseを構成した後に発生します。 1分ごとにnagiosプラグインコマンドを実行するために新しいDockerコンテナを生成するいくつかのモニタースクリプトを使用しています。 プロセスツリーに表示されているのは、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 ： ます。 そこで、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なしでuserlandプロキシを使用しており（--iptables = false）、これを最低でも1日1回見ています。 残念ながら、唯一の回避策は、SysRq手法を使用してサーバーをハードリセットするウォッチドッグでした。

私のシステムは、重いstdout / errライターであるいくつかのコンテナーを実行します。他の人は、それがバグを引き起こす可能性があると報告しました。

`` `` `` ``
$ docker情報
コンテナ：15
画像：148
ストレージドライバー：aufs
ルートディレクトリ：/ var / lib / docker / aufs
バッキングファイルシステム：extfs
Dirs：178
サポートされているDirperm1：true
実行ドライバー：ネイティブ-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
OS / Arch（クライアント）：linux / amd64
サーバーバージョン：1.7.0
サーバーAPIバージョン：1.19
Goバージョン（サーバー）：go1.4.2
Gitコミット（サーバー）：0baf609
OS / Arch（サーバー）：linux / amd64```
`` `` `` ``

残念ながら、私も同じケースです。今日、本番サーバーはこのエラーで3回失敗しました。これを処理する唯一の方法は、いくつかのマジックSysRqコマンドを使用することです。

バンプ

私はまだカーネル4.2.0を使用している最新のdebianjessieでこれを見ています

ここでも同じ問題があります。 突然、3つのawsサーバーがダウンし、ログに「unregister_netdevice：loが解放されるのを待っています。使用回数= 1」と叫んでいました。

Ubuntu：14.04
カーネルバージョン：3.13.0-63-generic
Docker：1.7.1

Syslog

安全に使用できるカーネルバージョンはありますか？

この問題は、Ubuntu15.10のカーネル4.2でも発生します

coreosで発生しました：

画像：1174
ストレージドライバー：オーバーレイ
バッキングファイルシステム：extfs
実行ドライバー：ネイティブ-0.2
ロギングドライバー：json-file
カーネルバージョン：4.1.7-coreos
オペレーティングシステム：CoreOS 766.4.0

@ killme2008が前回言ったカーネルのバグ

おそらく、カーネルの上にこのパッチを適用して試してみる必要がありますhttp://www.spinics.net/lists/netdev/msg351337.html
パケット：packet_bindの競合状態

または、-stableツリーでバックポートを待ちます。 それは遅かれ早かれ来るでしょう。

：+1：素晴らしいニュースです！

みなさん、朗報です！

ここでの最後のコメント（執筆時点、17日前）以来、これらのエラーは二度と発生していません。 私のサーバー（そのうちの約30台）は、いくつかの古いパッケージでubuntu14.04を実行していました。

docker-engine（1.7.1から1.8.3）を含む完全なシステムアップグレード+ ubuntuのリポジトリで可能な最新バージョンへのカーネルアップグレードの後、サーバーは問題なく実行されています。

：8ball：

今日のAWSインスタンスの3つでも発生しました：

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でも同じ問題が発生しています。

まだFedora22で起こっています（更新されました）...
dockerを再起動すると、メッセージを取り除くことができます

systemctl restart docker
...メッセージが約3〜4回再び表示され、その後停止します

同じエラーがcoreosで私に会います：

coreosのバージョン：

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

Dockerバージョン：

 core @ core-1-94〜 $ dockerバージョン
クライアントバージョン：1.7.1
クライアントAPIバージョン：1.19
 Goバージョン（クライアント）：go1.4.2
 Gitコミット（クライアント）：df2f73d-dirty
 OS / Arch（クライアント）：linux / amd64
サーバーバージョン：1.7.1
サーバーAPIバージョン：1.19
 Goバージョン（サーバー）：go1.4.2
 Gitコミット（サーバー）：df2f73d-dirty
 OS / Arch（サーバー）：linux / amd64

 core @ core-1-94〜 $ uname -a
 Linuxコア-1-944.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

システムログ：

 Dec 07 16:26:54 core-1-94カーネル：unregister_netdevice：veth775ea53が解放されるのを待っています。 使用回数= 1
 Dec 07 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：85、10.244 .97.10
 Dec 07 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：d0、10.244 .34.8
 Dec 07 16:27:02 core-1-94 dockerd [1269]：time = "2015-12-07T16：27：02.398020120 + 08：00" level = info msg = "GET / version"
 Dec 07 16:27:02 core-1-94 dockerd [1269]：time = "2015-12-07T16：27：02.398316249 + 08：00" level = info msg = "GET / version"
 Dec 07 16:27:04 core-1-94 dockerd [1269]：time = "2015-12-07T16：27：04.449317389 + 08：00" level = info msg = "GET / version"
 Dec 07 16:27:04 core-1-94カーネル：unregister_netdevice：veth775ea53が解放されるのを待っています。 使用回数= 1
 Dec 07 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：f5、10.244 .47.24
 Dec 07 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：57、10.244 .71.24
 Dec 07 16:27:12 core-1-94 dockerd [1269]：time = "2015-12-07T16：27：12.502991197 + 08：00" level = info msg = "GET / version"
 Dec 07 16:27:12 core-1-94 dockerd [1269]：time = "2015-12-07T16：27：12.503411160 + 08：00" level = info msg = "GET / version"
 Dec 07 16:27:14 core-1-94 dockerd [1269]：time = "2015-12-07T16：27：14.450646841 + 08：00" level = info msg = "GET / version"
 Dec 07 16:27:14 core-1-94カーネル：unregister_netdevice：veth775ea53が解放されるのを待っています。 使用回数= 1
 Dec 07 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：68、10.244 .13.6
 Dec 07 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：bb、10.244 .24.7
 Dec 07 16:27:22 core-1-94 dockerd [1269]：time = "2015-12-07T16：27：22.575446889 + 08：00" level = info msg = "GET / version"
 Dec 07 16:27:22 core-1-94 dockerd [1269]：time = "2015-12-07T16：27：22.575838302 + 08：00" level = info msg = "GET / version"
 Dec 07 16:27:24 core-1-94 dockerd [1269]：time = "2015-12-07T16：27：24.452320364 + 08：00" level = info msg = "GET / version"
 Dec 07 16:27:24 core-1-94カーネル：unregister_netdevice：veth775ea53が解放されるのを待っています。 使用回数= 1
 Dec 07 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：50、10.244 .87.8
 Dec 07 16:27:29 core-1-94 dockerd [1269]：time = "2015-12-07T16：27：29.453171649 + 08：00" level = info msg = "GET / version"
 Dec 07 16:27:29 core-1-94 systemd [1]：Generate / run / coreos / motdを開始しています...
 Dec 07 16:27:29 core-1-94 systemd [1]：/ run / coreos / motdの生成を開始しました。
 Dec 07 16:27:32 core-1-94 dockerd [1269]：time = "2015-12-07T16：27：32.671592437 + 08：00" level = info msg = "GET / version"
 Dec 07 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：b9、10.244 .68.8
 Dec 07 16:27:34 core-1-94 dockerd [1269]：time = "2015-12-07T16：27：34.453953162 + 08：00" level = info msg = "GET / version"
 Dec 07 16:27:34 core-1-94カーネル：unregister_netdevice：veth775ea53が解放されるのを待っています。 使用回数= 1
 Dec 07 16:27:35 core-1-94カーネル：unregister_netdevice：loが解放されるのを待っています。 使用回数= 2

お誕生日おめでとう、血まみれの問題=）
2014年5月6日

ここでも同じです。 再起動するだけです。 最新のDockerバージョン。 Ubuntu14.04。

@samvignoliこれはカーネルの問題として識別されているため、残念ながら

@thaJeztahカーネル問題のバグトラッカーへのリンクはありますか？
それとも、影響を受けるカーネルへのポインタですか？

私たちの環境でこれを解決することに熱心です。

@Rucknar申し訳ありませんが、私はしません（おそらく、このディスカッションに1つありますが、すべてのコメントを読み返していません）

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へのリンクが表示され

おかげさまで、アップグレードに必要なものを見ていきます。

FWIWここで説明した最後のパッチをubuntu3.19にバックポートし、4.2カーネルでもテストしましたが失敗しました。 この時点では、4.4-rc3net-nextブランチでも問題が発生しています。

@rsampaioどのようにそれをテストしましたか？ 実際、どのカーネルでも、dockerを使用してこの障害を確実にトリガーすることはできません。 それはたまに起こります。

@fxposter本番環境以外でも問題を再現できないため、パッチを適用したカーネルを本番環境の負荷から24時間以内にカーネルが影響を受けるかどうかを確認できます。

非常に珍しいリソースで修正することがあります。コンテナディレクトリを/ var / lib / docker / aufs / mntから移動します。

これで...「サービスドッカーの再起動」を実行して、ディレクトリを元に戻すことができる場合があります。

それ以外の場合は...再起動するだけです。

@rsampaio今、herokuの制作について話しているのですか？ この問題をどのように回避しますか？すべてのビジネスがコンテナなどを中心に構築されているためですか？

@rsampaio --userland-proxy=falseを使用しますか、それとも大量の作成済みコンテナーを使用しますか？ --userland-proxy=falseを使用し、負荷をかけなくてもかなり簡単に再現できます:)

@ LK4D4大量の作成/破棄されたコンテナ、特に大量のアウトバウンドトラフィックを実行するコンテナだと思います

@rsampaiohttps：//github.com/crosbymichael/docker-stressを長時間使用しても再現できます

これを修正するための更新/提案はありますか？

@joshrendekこれはカーネルのバグです。 新しくリリースされたカーネル4.4でも修正されていないようです。そのため、どこかに少なくとももう1つの競合状態があります:)

カーネルのバグ

=）

@samvignoliコメントを建設的に保つことができますか？ この問題を解決する方法がある場合は、PRを開いてください。

このバグはすでにアップストリーム（カーネルメーリングリスト）で報告されていますか？

確かにそうです。 最初のコメントもこのバグを参照しています： https ：

2014年からオープンしています。アプリケーションが誤って使用している可能性が高いと言う以外は、それに取り組んでいる人からのコメントはありません。

リンクをありがとう、ジャスティン！ Linusをトロールします=）

敬具。 = *：heart：

@samvignoliこれをしないでください、それは誰にも役立ちません。
誰かがこれを小さなVMイメージで再現できますか？
たぶん、gdbとたくさんのkprintfで手を汚すことができます。

バグはまだ開いています。

OS：CentOS 7.2
カーネル：4.4.2 elrepo kernel-ml
docker：1.10.2
fs：xfsを使用したoverlayfs

ログ：

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 EngineVMでCoreOSStable（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：veth6c3b8b0が解放されるのを待っています。使用回数」というログが表示されると、dockerがハングしています。 これはdockerによって引き起こされたカーネルの問題だと思います。 これは、docker userland-proxyがオフ（--userland-proxy = false）の場合にのみ発生します。

これは、ユーザーランドプロキシが有効になっている場合と有効になっていない場合で発生したため、オフの場合だけは言いません。

それは状況を悪化させる可能性があります。 --userland-proxy=falseデフォルトにしようとしたことがありますが、副作用があったため、元に戻しましたhttps://github.com/docker/docker/issues/14856

昨日から一度もエラーが発生しました。明らかにIPv6を無効にすることは修正ではありません。 しかし、フラグがないと、Dockerを破棄せずにサーバーのすべてのコンテナーを起動することさえできません。

kubernetes1.2.2およびdocker1.10.3を使用するCoreOS1010.1.0でこれに遭遇する

Kubernetesはkubeletにフラグを追加しました（モバイルでは、検索できません）。
ヘアピンモード。 それを「無差別橋」または有効なものに変更します
値はです。 その変更を行って以来、このエラーは発生していません。

@bprashanh

確認または反論してください。
2016年4月13日12:43 PM、「AaronCrickenberger」 [email protected]
書きました：

kubernetes1.2.2とdockerを搭載したCoreOS1010.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イメージを含むRuby2.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問題が

これがカーネルの競争であり、refcountを失うことはかなり明らかです
どこか。 これはバグを追跡するのは本当に難しいですが、私たちが知る限りでは
まだ存在しています。

22:52時月、2016年5月2日には、Suneケラー[email protected]
書きました：

@MrMMorris https://github.com/MrMMorris確かに、
問題は永久に消えた、またはあなたがそれを再び経験していないという点で
まだ？ 競合状態である可能性があります...

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/5618#issuecomment -216444133

うん。 カーネル4.5でCoreOS1032.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 ：： 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サーバー23-4.2.5-300.fc23.x86_64で再現。 Dockerサービスを再起動できません-ノードを再起動するだけです。

Fedora 24カーネルで同じ問題：4.5.2-302.fc24.x86_64。 ハングは発生しませんでしたが、ログファイルをスパムします。

@hapylestat systemctl restart dockerを試すことができますか？ これは私のためにそれをすべてぶら下げさせました。

ありがとう

これは私の（CoreOS、EC2）マシンで非常に頻繁に発生しています。 それがまったく役立つ場合のために、このバグの1つのインスタンスでスタックした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ポッドをまとめて削除した場合）に発生するようです。

再起動で修正されたと言っている人のために-マシンを再起動または停止/起動しましたか？ 物理マシンでは、リモート電源リセットを使用してマシンを復旧させる必要がありました。

@ joshrendek 、iLOのコールドブート（

@joshrendekこれを監視して実行し、発生したときにreboot -fを実行するスクリプトがあります😢。

問題を見つけた可能性があります（または運が良かっただけです）。 DockerグラフディレクトリをXFSパーティションディスクからEXT4パーティションディスクに移動しましたが、問題を再現できません（また、発生していた他のXFSバグの負荷を解決できません）。 @vbattsがXFSはまだサポートされていないと言ったことを覚えています。

build 、 run 、 stop 、 deleteをさまざまな画像の無限ループで実行し、サイクルごとに約10個のコンテナを作成して、挑発しようとしました。過去数時間。

@joedborgどのグラフドライバーを使用していますか？ デバイスマッパー？ かぶせる？

@thaJeztah良い点、私はそれについて言及すべきだった。 私は（現在）EXT4バッキングFSでオーバーレイドライバーを使用しています。

以前はdevicemapperを使用していましたが（Fedora Serverを使用しているため）、特にコンテナーが削除された後、マッパーがプールにスペースを戻さないリークで、（多くの人がそう信じているように）多くの苦痛がありました。

それが役に立ったら、私はDocker1.11.1とカーネル4.2.5-300.fc23.x86_64を使用しています。

@joedborgは興味深いです。なぜなら、RHELのドキュメントには、RHEL / CentOS 7.1ではEXT4のみがサポートされ、RHEL / CentOS7.2ではXFSのみがサポートされると記載されているためです。 XFSが新しいバージョンで動作することを期待していました

@thaJeztahああそれは奇妙だ。 私はそれがそうであるかもしれない他のことを考えようとしています。 上から読み直しましたが、同じ設定を実行している人がいるようです。 他に異なるのは、XFSディスクがスピンドルであり、EXT4がSSDであるということだけです。 その間、ソークテストを続けます。 また、同じセットアップを使用するように製品を移動したので、どちらの方法でも、まもなく答えが得られます。 ただし、以前はほぼすべてのstopで実行されていたため、確かに優れています。

@joedborgまあ、それは確かに有用な情報です

ここでも同じエラー、カーネル4.2から4.5、同じDockerバージョン。

ところで、私は同じボックスで同時に複数のvirtualboxマシンを実行しています。

$ 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

ext4 FS上のディレクトリで、 overlayグラフドライバを使用してこの問題が発生しています。 だから私はxfsが問題だとは思わない😢

@obeattieええ、人々もdevicemapperそれを手に入れているようです。 木に触れてください、私は切り替えてから再び問題を抱えていません。 前述のように、物理ディスクも交換しました。 これは興味深いものになるでしょう！

この問題は、ファイルシステムとはまったく関係がありません。 zfs、overlayfs、devicemapper、btrfs、aufsでこの問題が発生しました。 また、スワップの有無にかかわらず。 Dockerに限定されるものではなく、lxcでも同じバグが発生しました。 私が現在見ている唯一の回避策は、コンテナを同時に停止しないことです。

それが役立つ場合は、AWSAMIがサポートする最新の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

ただ乗り込んでください。 最新のAmazonec2インスタンスでも同じ動作が見られます。 しばらくすると、コンテナが転倒して応答しなくなります。

$ docker情報
コンテナ：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）
実行ドライバー：ネイティブ-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
Goバージョン：go1.4.2
Gitコミット：a34a1d5 / 1.9.1
構築：
OS / Arch：linux / amd64

サーバ：
バージョン：1.9.1
APIバージョン：1.21
Goバージョン：go1.4.2
Gitコミット：a34a1d5 / 1.9.1
構築：
OS / Arch：linux / amd64

上記のコメントと同じように、EC2でも実行されるのは、 64bit Amazon Linux 2016.03 v2.1.0 running Docker 1.9.1を使用するElasticBeanstalkを介したものです。

現時点では多少の逸話ですが、最近、テストとして約18台のサーバーで4.2.0から4.5.5カーネルにアップグレードしようとしましたが、この問題はかなり悪化しました（数日から問題の間隔は4時間以内）。

これはDebian8にありました

@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のように、

コンテナがメモリ制限に達したときにこのバグが発生しました。 関連するかどうかわからない。

ここに同じ問題

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

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

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

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

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

centos7.2
docker 1.10.3
同じ問題

4.6.3カーネル（非常に最近）でCoreOS 1068.3.0を実行しているEC2（m4.large）で、最終的にこの問題を再現する「1つのライナー」があります。 私の場合、約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のスクリプトは、数千回の反復の後、

$ 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の1つのライナーでは確実に再現できません。 CoreOS1068.3.0を搭載した2つのAzureVMで実行してみました。

最初のVMはStandard_D1_v2（3.5GB RAM、1コア）でした-スクリプトは3000回以上の反復を行いました。
2番目のVMはStandard_DS15_v2（140GB Ram、20コア）でした-スクリプトは7600回以上の反復を行いました。

以前のコメント（https://github.com/docker/docker/issues/5618#issuecomment-229545933）を更新して、userland-proxy = falseの場合にのみこれを再現できるようにしました。

EC2 t2.micro（シングルコア）VMとm4.large（マルチコア）の両方でHVMを使用して再現します。 userland-proxyの設定に関係なく、ラップトップでVirtualBoxを使用してそれが発生するのはまだ見ていません。

kubernetesクラスターでヘアピン-vethを有効にしてFlannelを使用しているときにこのバグが発生しました（iptablesプロキシを使用）。 このバグは、実行時にのみ発生していました。コンテナが多すぎます。 cbr0ブリッジネットワークと無差別ブリッジヘアピンモードの使用に切り替え、二度と表示されません。
実際、ヘアピンvethを使用している場合は、このバグを簡単に再現できます。このジョブは、kubernetesを含む100個のコンテナーで開始するだけです。

2016年1月7日08:01に、manoj0077は次のように書いています。

@btalbot https://github.com/btalbotなので、1.12で再起動できます
実行中のコンテナに影響を与えずにdockerd。 したがって、dockerdは再起動します
この場合ここで助けますか？

AFAICT、1.12のイベント、Dockerコンテナプロセスはまだ子です
dockerデーモンの。

@sercandどのようにして無差別ブリッジヘアピンモードを設定しましたか？ Dockerからのドキュメントが表示されないか、別の名前を使用している可能性があります

これがいつ見られるかについて、Docker🐳からの公式の言葉はありますか？ これは2番目にコメントの多い未解決の問題です。 非常に深刻です（ホストの再起動が必要です）。 再現性があります。 根本的な原因を特定したり、修正したりするための実際の進展は見られません😞。

これはカーネルの問題である可能性が最も高いようですが、 Bugzillaの

@ justin8これらはKubeletフラグだと思います： --configure-cbr0と--hairpin-mode

@sercand私もフランネルを使用しています。 --hairpin-mode=promiscuous-bridgeを使用することに不利な点はありますか？

@obeattie同意します。 :(

FTRセットアップしたテストKubernetesクラスターでヘアピンベスも使用しています。

@sercand promiscuous-bridge使用を開始する手順を詳しく教えてください。 ノードのkubeletにフラグ--configure-cbr0=trueを追加しましたが、次のように文句を言います。
ConfigureCBR0 requested, but PodCIDR not set. Will not configure CBR0 right now 。 このPodCIDRはマスターから来るはずだと思いましたか？ ありがとう。

編集：コントローラーマネージャーの構成に--allocate-node-cidrs=true --cluster-cidr=10.2.0.0/16を追加する必要があるようですが、クラウドプロバイダー（Azure）がないため、ルートが機能しない可能性があります。

@ justin8私はこのドキュメントをフォローし
ドキュメントhairpin-modeの@edevilは、「これにより、サービスのエンドポイントが、独自のサービスにアクセスしようとした場合に、サービスのエンドポイントがロードバランスを取り戻すことができます」という

@sercandドキュメントによると、コントローラーマネージャーで--allocate-node-cidrs=trueを使用する場合、ルートを設定するためにクラウドプロバイダーを使用することになっています。 Azure用のKubernetesクラウドプロバイダーがないので、問題はありませんでしたか？ ルートを手動で設定しますか？ ありがとう。

@edevil私はこのリポジトリでそれを見つけることができます。 私はすぐにこの構成を作成し、一度だけテストしました。 その背後にある基本的なロジックを提供するだけで十分だと思います。

@morvans @btalbot 1.12で試す機会がありましたか...？

ヘアピンベスから離れてcbr0ブリッジを使用すると、問題を再現できないことが確認できます。

念のため：ベアメタルでこの問題を抱えている人はいますか？ これは、VMWareラボでランチャークラスターをテストしたときに見られましたが、実際のベアメタル展開では見られませんでした。

はい、この問題は、4.3以上のカーネルのベアメタルで発生します。 これは、さまざまなマシンやハードウェア構成で見られます。 私たちにとっての唯一の解決策は、カーネル4.2を使用することでした。

それは間違いなく4.2でも発生しますが、新しいものでは桁違いに頻繁に発生します。各メジャーリリースをテストして、それが優れているかどうかを確認していますが、まだ何もありません。

CoreOS alpha1097.0.0でも発生します。

カーネル：4.6.3
Docker：1.11.2

同じ問題が発生します。

Docker：1.11.2
カーネル：4.4.8-boot2docker。

ホスト：OSX上のVMWareFusionドライバーを備えたDockerマシン。

提案された回避策はありますか？

クラッシュダンプが可能な環境（別名ではないEC2）で確実に問題を再現することができますあなたの人々の場合は、事実を共有し、このクラッシュダンプファイルに本当に便利でしたでしょうUbuntuの中で信頼できるのkdumpを有効にする方法の詳細については見つけることができるこことkdumpがcrashdumpを生成する準備ができたときに有効にする必要があるクラッシュオプションは次のとおりです。

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

クラッシュダンプは、カーネル開発者が参照リークの原因について詳しく知るのに役立ちますが、クラッシュダンプにはホストのメモリダンプも含まれており、適切な情報が含まれている可能性があることに注意してください。

...賢明な情報。

：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 +ブザーで）
「単に」DebianJessie +バックポート：

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

こんにちは、

破壊的な新しいイメージを作成して、制御された環境で問題を再現しようとすると、再現できません。

この問題は、docker1.9.1を実行しているサーバーの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つのVMとベアメタルラップトップで、すべてUbuntu 16.04と最新のカーネル（4.4.0-3 [456]）を実行しています。

その結果、すべてがハングし、ハードリブートが必要になります。
先週までこれを経験したことがなく、VMの1つは1.11.3にあり、他のVMはすべて1.12.0にあったと思います。

@RRAlexこれはどの
デーモンオプションで--userland-proxy=falseしている場合...または（私が理解していることから）kubernetesを使用している場合は、この問題が発生する可能性があります。

その理由は、 --userland-proxy=falseオプションがブリッジインターフェイスでヘアピンNATを有効にするためです...これは、kubernetesがコンテナのネットワークを設定するときにも設定するものです。

Docker Cloud（およびDocker Cloudエージェント）を使用するBYOノードでこれを確認します。

今日、これを現在のAmazon ECS AMIで1回（約25回の試行のうち）見ました。apt-getupdates、pbzip2をインストールし、それを実行するコマンドでvanilla debian：jessieを実行します（単純なマルチスレッドCPUテスト）。

@edevil
ここにいるほとんどの人は、コンテナの起動/停止にDockerを使用しているときにこの状況に遭遇すると説明していますが、DebianでDockerを使用しなくてもまったく同じ状況になりました。

• Debian "Jessie"（= Debianバージョン8.5）、ベアメタル（VMなし、クラウドなし、ただしプレーンハードウェア）
• カーネル3.16.0-4-amd64
• 4つのLXCコンテナを開始しました
• 「lxc-stop-n $ containerName」で1つのLXCコンテナをシャットダウンします
• このコマンドが完了しても、カーネルまたはインターフェイスはまだ完全に「クリーンアップ」されていない可能性があります。前の「lxc-stop」の直後に新しい「lxc-stop」を起動すると、カーネルの問題が発生するためです。

マシンをハードリセットする以外に回復する方法はありません。

したがって、この問題を特定/解決するための調査では、Dockerだけに焦点を当てないでください。 Dockerを介した場合でも、単純な「lxc」コマンドを使用した場合でも、コンテナーの高速停止/開始に関する一般的な問題は明らかです。

これはLinuxカーネルの問題だと思います。

非常に重い負荷で3つのchroot（実際にはpbuilder）を実行しているときに、この問題が発生しました。
私のハードウェアはLoongson3A（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）にダウングレードし、 https： //github.com/docker/libnetwork/issues/1189を回避するためにdockerを1.12.0にアップグレードしました

これがお役に立てば幸いです。

すべて、Dockerやchrootについてのメッセージを投稿する必要はもうないと思います。それはすべてLinuxカーネルに関するものです。
それで、コンテナの仮想ネットワークインターフェイスを無効にしている部分で、カーネルを何らかの方法でデバッグできる誰かが立ち上がることができますか？ コンテナの新しい停止が要求される前に、コンテナの以前の停止がまだその仮想インターフェイスを完全に無効化/クリーンアップしていなかった場合に、いくつかの競合状態が発生する可能性があります。

@rdelanghこの問題は必ずしもカーネルに関連しているとは思いません。

Fedora 24では、FedoraリポジトリからのDocker 1.10.3の問題を再現できず、Docker自身のリポジトリからのDocker1.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で安定したCoreOS1068.9.0でKubernetes1.3.4を使用すると、docker1.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つのReplicationControllerを作成できます。これに基づいてhelloとhello1と呼びました： http ：

次に、これに基づいて、上記と同じ名前/ラベルに一致する2つのデプロイメントを作成します： http ：

_デプロイメントを作成するとすぐに、膨大な量のスパムコンテナが届きます_。

しばらく（数分）オンのままにすると、多くのものが終了/作成しようとしているのがわかります。 デプロイメントを削除して、状況を安定させることができます。 あなたは良い一握りの終了とContainerCreatingを見るはずです。 ノードにSSHで接続する場合は、 dmesgとdocker psをチェックして、上記の症状が明らかかどうかを確認してください。

私の場合、問題が発生する前に、このフリークを解放するのに約5分かかりました。 @sercandと@edevilがいじっていた変更を予定です。

@edevilリンクされたコミットを確認した後、この問題を回避するためにKubernetesによって作成されたcbroブリッジを優先して、環境内のFlannelを完全に無効化/削除したことは正しいですか？

フランネルがdocker0を使用したいと考えており、内部ネットワークがcbr0しているため、これらをタンデムで使用することはできません。

@ alph486正解です、フランネルの使用をやめました。 ブリッジを使用して、ポッドネットワークのルートを設定します。

@ alph486フランネルは--bridge=cbr0 dockerオプションでオーバーライドできます。
CoreOSでは、dockersystemdユニットをオーバーライドする必要があります。

Kubeletフラグ--experimental-flannel-overlayは、フランネル構成を読み取り、フランネルCIDRを使用してDockerブリッジcbr0を構成できます。

また、問題のように思われるveth-hairpin代わりにpromiscuousモードが有効になります。

入力してくれた@daduxに感謝します。 K8sが、オーバーライドされたユニットによってすでにブートストラップされているcbr0インターフェースを取得する場合、そのソリューションと連携している可能性があります。 私はそれを試してみます。

ドキュメントによると、 promiscuous-bridge --hairpin-modeはkubelet v1.3.4 +の

kubenetネットワークプラグイン（ --configure-cbr0を置き換えるように設定されています）を使用した後、問題を再現できませんでした。 将来の不確実性のために、私はflannel-overlayオプションを避けています（ --configure-cbr0関連付けられているようです）。

Dockerデーモンがdocker0ブリッジを使用している場合、kubeletは存在しないブリッジcbr0を構成しようとするため、 --hairpin-mode=promiscuous-bridgeを設定しても効果はありません。

CoreOSの場合、Kubernetesの動作をミラーリングするための回避策ですが、フランネルを使用しています。

• 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

• Dockerブリッジにヘアピンをセットしないようにkubeletに伝えます。
  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デーモンを起動するときに--ipv6=falseでdockerのipv6を無効にすることもできます

@ coolljt0725間違っているかもしれませんが、

@daduxご

    - 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

O / Sがコンテナーのインターフェースを処理する方法に関して、Docker / Kubernetesに対するこれらの変更はどのような影響を及ぼしますか？
DockerやKubernetesではなく、間違ったO / S動作の問題であることを強調する必要があります。これは、私たち（およびこのスレッドの他の一部の人々）がDockerまたはKubernetesをまったく実行していないためですが、LXCを停止したときにまったく同じ状況が発生するためです。コンテナは次々と非常に速くなります。

@rdelanghその通りです。 ただし、この問題は、Dockerに関連する動作を追跡するためにDockerプロジェクトで作成されました。 このスレッドでは、OSの問題、K8sの問題、CoreOSの問題として追跡している他の問題があります。 LXCなどで問題を見つけた場合は、そこでスレッドを開始し、ここにリンクして問題に関する認識を高めることを強くお勧めします。

このエラーのためにDockergoogleを使用している場合、おそらくここに到達します。 したがって、根本的な問題が修正されるまで人々が前進できるように、この問題の回避策をここに投稿することは理にかなっています。

O / Sがコンテナーのインターフェースを処理する方法に関して、Docker / Kubernetesに対するこれらの変更はどのような影響を及ぼしますか？

1. 私の投稿でのDockerの変更により、KubernetesスタックがDockerに問い合わせることができ、問題が発生したときにプラットフォームが正常であることを確認できます。
2. hairpin-mode変更は、基本的にK8にdocker0ブリッジをそのまま使用するように指示するため、Dockerで問題が発生する「カーネルランド」ネットワークと「ヘアピンベス」を使用しようとはしません。実行パス。

K8sとDockerを使用したこの問題の回避策。

coolljt0725の同僚のパッチは安定するためにキューに入れられているので、すぐにディストリビューションにバックポートされることを願っています。 （David Millerの投稿：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はヘアピンモードを設定し、実際に機能することは期待されていませんでした。 これに関連して--userland-proxy=falseここでは、これはすぐ上流であってもよいし、価値がある別のショット、それはパフォーマンスのために、この問題に言及バグにかかわらず、これをオフにするにはいいだろうが、残念ながら、それはまた別の持っています現時点でのバグ。

• ここに記載さました。また、
• ここで提案されて

長すぎる; 読みました：grub設定でipv6を無効にします。 リブート。 利益。

CentOS 7.2（3.10.0-327.28.3.el7.x86_64）およびDocker 1.12.1（k8sなし）でこの問題に直面しました。 この問題は、ネットワークトラフィックが増加すると発生します。
（以前のアドバイスに従って）ipv6を無効にしてカーネルを起動しても役に立ちませんでした。
しかし、docker0インターフェースをpromiscモードに変えることで、これは修正されました。 @daduxによる中古のsystemdドロップイン（ありがとう！）-現在はうまく機能しているようです。

@rdallman grubを介してipv6をunregister_netdevice妨げられることはありません。 --userland-proxy設定に関係なく（trueまたはfalseのいずれか）。

ああ、パッチが安定するためにキューに入れられたのは素晴らしいことです。
--ipv6=falseが何もしないという問題について@abochにpingを

@trifle申し訳ありません:(情報を投稿していただきありがとうございます。数日間のテスト後もまだ問題は発生していませんが、問題が発生した場合は更新されます。coreos1122.2（カーネル4.7.0）を実行しています。docker0をpromiscモードに設定しています。一部の人にとってはこれを修正しているようです（私たちにとっては運が悪いです）。

@RRAlex誰かがバックポートに関してUbuntuカーネルチームに

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」ソリューションをテストすることに成功しました。 それに加えて-私は私のdebian8で4.7.2カーネルにアップグレードしました。
カーネルをアップグレードし、カーネルパラメーターで「ipv6.disable = 1」を有効にした後、Dockerデーモンの「--userland-proxy = false」フラグがなくても、実際のワークロードで「待機中」の問題をキャッチできました。 幸いなことに、「-userland-proxy = false」を指定し、「docker-stress」の問題を再現しようとすると、それができなくなります。 しかし、「-userland-proxy」の値に関係なく、再び発生すると確信しています。
つまり、私が見たところ、ipv6は間違いなくこの問題に関与しています。これは、docker-stressが問題をキャッチできなくなったためです。 悪いニュースは、問題が実際にはまだ存在していることです（つまり、部分的にしか修正されていません）。

さらにテストするために、後で最新の4.8rc7をコンパイルします。

@ twang2218 @ coolljt0725

うーん..だから私はちょうどddstreetのppaからバックポートされたパッチでUbuntuxenial 4.4.0-36カーネルを試しました：

$ 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（すでに進行中）ではなく、その後の約5〜6週間に含まれる可能性があります。 14.04でも必要な場合は、バックポートできるようにお知らせください。

@sforsheeは基本的に以前（そのパッチの前）で、カーネルでipv6を有効にし（通常はデフォルトで有効）、dockerデーモンフラグに「--userland-proxy = false」を追加してからdocker-stress -c 100実行することで再現できました。例（docker-stressはここからです：https：//github.com/crosbymichael/docker-stress）

@fxposterありがとう。 その修正がある場合、私が本当に心配する必要があるのは、その修正をUbuntuカーネルに取り込むことだけです。 また、そのパッチで修正されていない他のリークを調べるのを手伝うこともできます。

私もこの問題を抱えています。 AWSのrancherOSボックス内でdockerを実行しています。 実際には、ランチャークラスター（3つのホスト）をセットアップし、その中で小さなアプリケーションを実行した後、ランダムに発生します。

同じ... Fedora 24はランダムに発生し、10時間ごとに1つ取得するよりも、1週間は問題ない可能性があります
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

カーネル3.10.0-327.36.1.el7およびdocker1.12.1を実行しているCentOS7での体験

Docker 1.12.1のままでカーネル3.10.0-327.18.2.el7にダウングレードすると、システムが安定したようです。

私もこれを見ています：
Dockerバージョン1.11.2
Ubuntu 16.04.14.4.0-38-generic

ipv6が無効（grub）

ipv6パッチ（sic !!）を含むカーネル4.8.0-rc7を搭載したサーバーで、 --userland-proxy=false （sic！）なしでこの問題が発生しました。 したがって、問題の一部は修正されるかもしれませんが、すべてではありません。

これをデバッグする方法を知っている人はいますか？

これは、（ほぼ）空きメモリが不足した場合にのみセットアップで発生することがわかりました。

@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残念ながら、

@fxposterそのパッチは問題の一部を修正するだけです（しかし、私たちの環境では、そのパッチでこれ以上遭遇することはありません）、すべてではありません。同僚にこの問題を調査し続けさせます。 これを再現する方法があれば、私に知らせてください、ありがとう:)

修正は4.4.22安定版https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.22にあります

このパッチをFedora24に適用するようにRedhatにリクエストを投稿しました。

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.03v2.1.6も表示されます。

まだ起こった。 docker 1.12.2、armbian linux kernel 4.8.4、bootargsのipv6.disable = 1

バグを修正する方法、私は毎日それに会います

@woshihaoren --userland-proxy=falseは使用しないでください

明確にするために、userland-proxyも無効にして直面しました

Amazon Linux AMI 2016.9でこれを取得する：

$ uname -a

Linux 4.4.23-31.54.amzn1.x86_64 #1 SMP

Dockerバージョン：

`` `クライアント：
バージョン：1.11.2
APIバージョン：1.23
Goバージョン：go1.5.3
Gitコミット：b9f10c9 / 1.11.2
構築：
OS / Arch：linux / amd64

サーバ：
バージョン：1.11.2
APIバージョン：1.23
Goバージョン：go1.5.3
Gitコミット：b9f10c9 / 1.11.2
構築：
OS / Arch：linux / amd64
`` `

centos7カーネル4.4.30再び~~~~

CoreOS 1185.3.0、4.7.3-coreos-r2、Docker 1.11.2
コマンドとして「apt-getupdate」を使用して10..20debian ：jessieコンテナを実行するだけで再現可能。

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-この投稿には解決策はありませんが、これまでに追跡したことと現在の作業理論をリストします。 これを追いかけている他の人々が、私たちがこのことを実行するときに、ここでいくつかの情報が役立つことを願っています。

@ koendc4.7.5に導入されたパッチを投稿していただきありがとうございます。 4e1b3aa898ea93ec10e48c06f0e511de37c35b2d（アップストリーム751eb6b6042a596b0080967c1a529a9fe98dac1d）パッチを4.5.5セットアップ[1]にバックポートし、unregister_netdeviceの問題を簡単に再現できました。 4.7.xカーネルの他の変更が、提供されたパッチと連携してこの問題を解決する可能性がありますが、私はまだそれを確認していないので、まだすべての希望を失うことはありません。 [2]で説明されているように、問題を引き起こす再現可能なテストケースがあるため、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カーネルを実行するGCEvirtです。 Docker version 1.8.3, build f4bf5c7はその上で実行されています
[2]テストケースの情報：私は、それぞれのNode.js開始、20の並列処理を有するハローワールドドッカー容器のサーバ内を。 hello worldを返す代わりに、Node.jsサーバーは1MBのランダムテキストを返します。 親プロセスは、コンテナーを開始し、カールして1MBのデータを取得し、コンテナーを停止するタイトなループにあります。 この設定を使用すると、4〜90年代の問題を一貫して再現できます。 物理ホストまたはvirtualbox内でこれと同じセットアップを使用しても、GCEボックスでの再生までの平均時間を変更するさまざまな項目があるにもかかわらず、問題は再現されません。 私が遊んでいる変数：同時テストプロセスの数、転送されたペイロードのサイズ、curl呼び出しの量。 最初の2つの変数は確実に相関していますが、virtの妥当な飽和点を見つけるために変数を調整するだけである可能性が高いと思います。

私もこのエラーが発生しています。

コンテナをデプロイした後、3回繰り返されているのがわかります。

説明

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

問題を再現する手順：

1. DockerホストにSSHで接続
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、物理など）：

仮想マシン：
Fedora 24
ext3のOverlayFS2

Dockerに割り当てられた個別のドライブは24ギガを使用します。
ラムの16ギガ。

Docker PS

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

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へのアップグレードをUbuntu14.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の本番環境でこのエラーがまだ発生しています。 以前にエラーを再現したステージング負荷テストでこれらのエラーが消えた理由はまだわかりませんが、本番環境でのエラー率は実質的に同じです。 前方および上方。 インスタンスの回転率が高いため、このエラーに基づいて「自動爆縮」を無効にしました。

CentOS7にもあります

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テストでのDigitalOceanVP​​Sでも同じことが起こります。

# 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の実行中に本番サーバーで問題が発生したことを指摘しました。 これにより、2つの可能性が残ります。

• 私のテストテストケースに欠陥があります（可能性が高い）
• 4.8.8で修正が導入されました。 4.8.8の変更ログを見ると、コミット5086cadfと6fff1319はどちらも、解決されたnetdevの問題に言及しています。 どちらもここで問題を明示的に指摘していませんが、どちらも疑わしいほど近くにあります。

何人かの人々に4.8.8を試してもらい、この問題を再現できるかどうかを確認することはできますか？

@reshen 4.8.8に更新し、報告します：+1：調査していただきありがとうございます。

@reshen優れた研究。 これまでのところ、Xubuntu16.04でLinux4.8.8を使用して問題を再現することもできませんでした。

私はUbuntuメインラインカーネルビルドを使用してい

Linux 4.8.8をテストするために私にとって最も簡単なのは、メインラインのカーネルビルドにaufsが含まれていなかったため、ストレージドライバーとしてaufsからoverlay2に切り替えることでした。 テストに影響はないと思いますが、注意が必要です。

過去に、DanStreetmanによってバックポートされた751eb6b6を使用してLinux4.4.4をテストしましたが、これによって問題が軽減されたようには見えませんでした。 あなたが指摘した2つのパッチ（5086cadfと6fff1319）をバックポートしても、4.4.8と同じ結果が得られるかどうかを確認するのは興味深いことです。

4.4.0-47を搭載したUbuntu16.04は引き続き影響を受けました...今すぐ4.4.0-49を試してみると、後で報告されます。

編集：2016-11-28：-49はdmesgでそのログ行を示すsitllです。

Fedora 25（カーネル4.8.8）とDocker1.12.3でこれを体験しました

参考：単一の本番ホストでLinux4.8.8をDockerv1.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を実行しているRaspberryPi2でも同じエラーが発生します。

カーネル情報
Linux rpi2 4.4.32-v7+ #924 SMP Tue Nov 15 18:11:28 GMT 2016 armv7l GNU/Linux

Docker情報

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

これは、ダウンロードしたプログラムを約50Mbインストールする必要があるコンテナーを作成した後に発生しました。

再起動するだけで、マシンを再び使用できるようになります

私は実際にこれをECSクラスターのAmazonLinuxで見ています-メッセージは時々スローされますが、reshenが今見ているようにロックされません。 Docker1.11.2。 Unameは、バージョンとして「4.4.14-24.50.amzn1.x86_64」を報告します。

@reshen今週末、ラップトップで4.8.8をビルドして、それがどうかを確認します。
私のためにそれを修正します！
ᐧ

10:29の木、2016年12月1日には、アーネスト・ミューラー[email protected]
書きました：

私は実際にこれをECSクラスターのAmazonLinuxで見ています-メッセージ
時々スローしますが、reshenが今見ているように、ロックされません。
Docker1.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個のコンテナを作成すると、約3分後にDockerデーモンが応答しなくなります。

CoreOS Beta 1235.1.0にアップグレードしましたが、再現できませんでした（応答がないか、カーネルログのunregister_netdeviceメッセージの両方）。 5つの同時docker_stressワーカーを実行すると、数分後にCoreOS Stableが強制終了されますが、CoreOS Betaを使用してテストが完了するまで、10と15の同時ワーカーで実行できました。

CoreOSは「チャネル」でリリースされるため、カーネルを個別にアップグレードすることはできません。 安定版とベータ版の主な違いは次のとおりです。

CoreOS Stable 1185.3.0

カーネル：4.7.3

docker：1.11.2

CoreOS Beta 1235.1.0

カーネル：4.8.6

docker：1.12.3

4.4.23-31.54.amzn1.x86_64を実行しているAmazonElasticBeanstalkでこの問題が発生する

CoreOS Stable 1185.5.0、Docker1.12.2で発生します
再起動後、すべてが正常です

更新：Dockerv1.12.3およびLinuxカーネルv4.8.6を搭載したCoreOSBeta 1235.1.0を実行しているホストで、ハングしたDockerデーモンの問題が再び発生しました。 😢

1.12.4および1.13は、理論的には、このカーネルの問題が発生したときにフリーズしないようにする必要があります。
dockerデーモンでフリーズが発生する理由は、デーモンがコンテナーオブジェクトのロックを保持している間、カーネルからのネットリンクメッセージ（これは決して来ない）を待機しているためです。

1.12.4および1.13は、このnetlink要求にタイムアウトを設定して、少なくともコンテナーロックを解放します。
これは問題を修正しませんが、少なくとも（うまくいけば）デーモン全体をフリーズしません。
この問題が発生すると、netlinkとのすべての相互作用が停止するように見えるため、新しいコンテナをスピンアップできず、同様にそれらを破棄できない可能性があります。

@ cpuguy83 FWIW、デーモンがハングしている場合、実行中のコンテナーは問題なくAFAIKで実行を継続します。 実際、目立つのはコンテナーの開始と停止です（特に、私たちのようにKubernetesで実行されています）。

これで問題が解決するわけではありませんが、少なくとも（うまくいけば）デーモン全体がフリーズすることはありません。

デーモン全体がフリーズすることの1つの利点は、簡単に理解できることです。 Kubernetesはノードを削除でき、場合によっては自動的に再起動することもできます。 デーモンを実行し続ける必要がありますが、カーネルの問題が発生したことを簡単に見つけることは可能ですか？

@seanknoxパッチを適用したDocker（CoreOS Docker 1.12.3 +アップストリーム1.12.4-rc1パッチ）を使用したカスタムCoreOS 1248.1.0AMIを提供できます。 CoreOS / K8sクラスターで数時間ごとにハングアップが修正されました。 DeisSlackの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でこれを試すことができれば素晴らしいでしょう。これは、Dockerをハングさせるだけでなく、スタックしたnetlinkリクエストでタイムアウトするはずです。

@ 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はハングしませんが、コンテナーが中断されます。

だから私は問題なくしばらくの間（11ヶ月？）centos7マシンでdockerを実行しています。 今日、私は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
実行ドライバー：ネイティブ-0.2
ロギングドライバー：json-file
プラグイン：
ボリューム：ローカル
ネットワーク：ブリッジヌルホスト
カーネルバージョン：3.10.0-514.2.2.el7.x86_64
オペレーティングシステム：CentOS Linux 7（コア）
OSType：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
Goバージョン：go1.6.3
Gitコミット：3999ccb-サポートされていません
構築日：2016年12月15日木曜日17:24:43
OS / Arch：linux / amd64

サーバ：
バージョン：1.10.3
APIバージョン：1.22
パッケージバージョン：docker-common-1.10.3-59.el7.centos.x86_64
Goバージョン：go1.6.3
Gitコミット：3999ccb-サポートされていません
構築日：2016年12月15日木曜日17:24:43
OS / Arch：linux / amd64

@aamerikを確認できます。 同じカーネルバージョンで同じ問題が発生しています。 システムに最近の大きな変更はなく、今日からこの問題が発生しています。

JenkinsのDockerイメージを実行しているCentOS7マシンで同じkernel:unregister_netdevice: waiting for lo to become free. Usage count = 1メッセージが表示されました。 私が使用していたCentOS7マシンは、2016年12月20日頃の時点ですべての最新のCentOS7パッチを備えた最新のものでした。

ここでの最新の参照はCentOSベースのようですので、実行ホストをUbuntuまたはDebianマシンに切り替えます。

そのCentOS7マシンでDocker version 1.12.5, build 7392c3bしています。 Dockerはハングしませんでしたが、Dockerで実行していたJenkinsプロセスは、そのメッセージが表示されたときに強制終了されました。

Dockerをどうもありがとう！ いつも使っておりますので、よろしくお願いします！

Linux 4.8.15マシンでDockerを使用してJenkinsを使用すると、同じ問題が発生します。

誰か、ランチャーOSの修正手順に到達しましたか？

AFAICT、これはLinuxカーネルのネットワーク名前空間サブシステムのロックの問題です。 このバグは1年以上前に報告されており、返信はありません： https ：//bugzilla.kernel.org/show_bug.cgi？id = 97811これについてはいくつかの作業が行われてい

ネットワークサブシステムメンテナに直接pingを実行しようとしましたが、応答がありません。 FWIW、私はほんの数分で問題を再現することができます。

Smyteは、この問題の解決に5000米ドルを支払います。 カーネルで作業している人と話す必要があるように聞こえますか？

@petehuntこのエラーの原因となる問題は複数あると思います。

@reshenが提案したように、カーネル4.8.8をデプロイしました。稼働時間は少し良くなっているように見えますが、

ブートストラップノードからMesosphereをデプロイしようとしています。 すべてのノードはCentOS7.2最小であり、すべての更新が適用されています。 ブートストラップノードは、他の人が上記のようにエラーを表示しています。

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

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

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

uname -r：

3.10.0-514.2.2.el7.x86_64

docker -v：

Docker version 1.11.2, build b9f10c9

再起動するとメッセージが無音になることを確認できますが、mesosphereを再度デプロイすると、メッセージが時々開始されます。 Mesosphereは非常に大規模な展開です。 エラーを再現しようとしている人は、インストーラーを使用してエラーを再現できるかもしれません。 最初のスクリプトスイッチ（最初のステップである--genconf）を使用した後、エラーが表示されるまでに数分かかります。

これもヒットしました。 しかし、私たちの場合のエラーメッセージは、デバイスに言及eth0ませんlo 。 私のエラーはこれです：

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

eth0代わりにlo eth0に言及するなどのエラーには、この問題と同じ根本的な原因があると思います。 そうでない場合は、eth0エラーに関する新しいチケットを開く必要があります。

• OS：CentOSLinuxリリース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"
• ランチャー1.2.2はIPsecを使用しています（https://bugzilla.kernel.org/show_bug.cgi?id=97811およびその他のバグがIPsecに言及しているため、これについて言及しています）

これもヒットしました。
エラー： unregister_netdevice：loが解放されるのを待っています。
OS：CentOS Linuxリリース7.3.1611（コア）
カーネル3.10.0-514.2.2.el7.x86_64
Dockerバージョン：1.13.0-cs1-rc1
Dockerオプション：
{{
「disable-legacy-registry」：true、
"icc"：true、
「安全でないレジストリ」：[]、
"ipv6"：false、
"iptables"：true、
"storage-driver"： "devicemapper"、
"storage-opts"：[
"dm.thinpooldev = / dev / mapper / docker_vg-thinpool"、
"dm.use_deferred_removal = true"、
"dm.use_deferred_deletion = true"
]、
「userland-proxy」：false
}

私はこれを2つのCentOSシステムに持っており、そのうちの少なくとも1つに最新のアップデートがあります。

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

ねえ、RHELまたはCentOSでこの問題の影響を受けるすべての人のために、IPV6 IFP refcountの競合状態をエンタープライズディストリビューションで使用される3.10.xカーネルに修正するメインラインカーネル（torvalds / linux @ 751eb6b6042a596b0080967c1a529a9fe98dac1d）からのコミットをバックポートしました。 これでこの問題はずです。

動作中のパッチを含むバグレポートはここにあります：
テストに興味があり、RHEL7またはCentOS7システムを使用している場合は、最新のCentOS 7.33.10.0-514.6.1.el7.x86_64カーネルをパッチでコンパイル済みです。 CentOSバグトラッカースレッドに返信してください。ビルドへのリンクを送信できます。

注：refcountリークを引き起こす別の問題がある可能性がありますが、これで多くの人のエラーメッセージが修正されるはずです。

@stefanlasiewski @henryiii @jsoler

私はこの修正を追加してビルドを試します： http ：

@iamthebotは、IPv6を無効にすると、バックポートしたパッチがなくても問題が修正されることを意味しますか？

@redbaronは、それが問題になっている場合にのみ発生します。 ここでは、カーネルの問題が複数発生していると思います。

@redbaron多分。 ＃20569は、IPV6を完全に無効にすることが難しいことを示しているようです。

したがって、このメッセージを生成している内部で何が起こっているのかを少し明確にするために、カーネルは、デバイスが名前空間から削除、登録解除、非アクティブ化などする前に、デバイスが使用されているかどうかの実行カウントを維持します。何らかの理由でぶら下がっている場合デバイスを参照すると、他の何かがデバイスを使用しているときに登録を解除できないため、そのエラーメッセージが表示されます。

私がこれまでに見た修正：

1. IPV6アドレス割り当ての問題（アドレスの重複など）が失敗したが、終了する前にデバイスへの参照を解放しない問題を修正します。
2. デバイスの名前空間を移動すると、デバイスへの参照が新しいネットワーク名前空間に正しく移動するが、古い名前空間にぶら下がっている参照が残る問題を修正します。 Dockerはネットワーク名前空間を多用します（RedHatを7.3Z-Streamにバックポートし、Dockerのmacvlanドライバーがボンドまたはチームデバイスで動作しないようにする7.4に含める予定であるという別のカーネル修正によって証明されています）

名前空間を切り替えるときはまだ別の競合状態があると思いますが（これは新しいコンテナの束を作成した後に発生するようです）、問題を探してパッチを作成するには、問題を確実に複製する必要があります。

誰かがこれを一貫して再現するための最小限の手順を持っていますか？ 私たちのシステムではランダムに発生しているようです。

@iamthebotはそれほど単純ではありませんが、これを確実に再現できるテスト環境を提供できると思います。 私にメール（[email protected]）してください。詳細を手配できます。

Dockerバージョン1.12.6の高負荷でもこれを経験し、4.4.39-34.54.amzn1.x86_64 AWS LinuxAMIで7392c3b / 1.12.6をビルドします。

私は9つのDockerホストをすべてほぼ同じにしていますが、これは一部のホストでのみ発生します。 偶然かもしれませんが、私が気付いた共通点の1つは、 SIGINT処理しないコンテナーを実行しているときにのみこの問題が発生するように見えることです。 これらのコンテナをdocker stopすると、10秒間ハングし、その後コンテナを不正に強制終了します。

問題が発生するまでに数日かかり、 docker stop実行した直後だけでなく、ランダムに表示されるようです。 これはほとんど逸話的ですが、多分それは誰かを助けるでしょう。

@iamthebotが述べたように、CentOS7.3ですべてのDockerノードをカーネル3.10.0-514.6.1.el7.x86_64にアップグレードしましたが、それでも同じエラーが発生します。
Jan 26 13:52:49 XXXカーネル：unregister_netdevice：loが解放されるのを待っています。 使用回数= 1
1月26日13:52:49のsyslogd @ XXXからのメッセージ..。
kernel：unregister_netdevice ：loが解放されるのを待っています。 使用回数= 1

@jsoler明確にするために、カーネルを構築する前にバグトラッカースレッドにパッチを適用しましたか？ または、ストックカーネルを使用していますか？ また、これを適用し

私にメール（[email protected]）を送ってください。構築済みのカーネルへのリンクを送信できます。 @vitherman残念ながら、これを調べる時間があまりありません（このバグをキャッチするには、いくつかのインストルメンテーションをコンパイルする必要があるようです）が、Red Hatサポートの問題をエスカレーションしたので、カーネルチームは見る。

@ckeeneyこの動作を確認できます。 シャットダウン時にホストシステムで上記のエラーを引き起こしたドッキングされたノードアプリケーションがあります。 Node.jsアプリケーション内に関数を実装した後、SIGINTとSIGTERMをキャッチして、アプリケーションを正常にシャットダウンします。エラーは再発していません。
どちらが理にかなっています。 Nodeアプリケーションは、Dockerが作成する仮想インターフェースを使用します。 ノードが適切にシャットダウンされない場合、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クリーンシャットダウンのためにデフォルトでノードによって適切に処理される別のシグナルはありますか？ （画像内、またはdocker runで--stop-signalフラグを使用してSTOPSIGNALを指定できます。

良い問題の説明、および回避策について@thaJeztah、参照nodejs /ノード-v0.x-アーカイブ＃9131＃issuecomment-72900581

@ckeeney私はそれを知っています（つまり、 PID1として実行されているプロセスはSIGINTまたはSIGTERM処理しない可能性があります）。 そのため、 PID1として実行している場合でも、別の停止信号を指定するとクリーンシャットダウンが実行されるのではないかと考えていました。

または、docker1.13は--initオプション（プルリクエスト：https：//github.com/docker/docker/pull/26061）をPID1として実行されていません。これは、アプリケーションを更新できない場合に役立つ可能性があります。

@iamthebotパッチを統合してカーネルバージョン3.10.0-514.el7をビルドしましたが、同じエラーが発生します。 CentOSのカーネルパッケージをうまく構築したかどうかはわかりません。 カーネルパッケージを共有してテストしてもらえますか？

ありがとう

私はこのバグにほぼ1年前から取り組んできました。 PXEブートでCoreOSを使用し、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のバグ追跡では、「ppp0を待っている」という話があります。

上記のいずれかと上記のいずれかのみを持つログが交互に現れることに気付いた人もいます。

Ubuntuにも同様のバグが

@etlweather実際、唯一の一般的な分母は、エラーメッセージに示されているように、カーネルがネットデバイスの登録を解除できないことだと思います。 ただし、理由は多少異なります。 私たちにとって、それは間違いなく言及されたdocker / nodeの問題（veth）でした。 イーサリアムの場合、原因はおそらく完全に異なるものです。

docker1.13.1を使用したdebianjessieの4.9.0-0.bpo.1-amd64でも引き続き発生します。 安定したカーネルとOSの組み合わせはありますか？

これは純粋にDockerの問題ではない可能性があります-バニラLXCコンテナー（ubuntu 16.04）のみを実行しているProxmoxサーバーで発生しています。

@ darth-veitcherこれはカーネルの問題です

@thaJeztahは感謝に同意しました。 今夜メインラインから4.9.9をインストールして、それが問題になるかどうかを確認しようとしていました。

カーネル4.9.9-040909を搭載したDebianでDocker1.13.1を実行しています。

はい、Proxmoxのカーネルを最新の4.9.9にアップグレードしてもエラーは解決しませんでした。 1年経っても問題なく登場したばかりなので不思議です。

マウントされたNFSまたはCIFS共有のいずれかにリンクされていることについて、スレッドのさらに上の前のステートメントに何かがある可能性があります。

私のiPhoneから送信された

2017年2月14日には、午前7時47分で、アルフォンソ・ダ・シルバの[email protected]は書きました：

カーネル4.9.9-040909を搭載したDebianでDocker1.13.1を実行しています。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

これについてRedhatでバグジラチケットを開いています。

いくつかの開発：
Red Hatは、メインラインからのIPV6 refcountリークパッチをQAに配置しました。これらは、RHEL 7.4のキューに入れられているようで、7.3にバックポートされる可能性があります。 CentOS-plusもすぐに利用できるようになるはずです。 注：このパッチは、一部のケースでのみ問題を修正します。 4.xカーネルを使用している場合は、すでに存在しているため、これは重要なポイントです。

これは間違いなくカーネルの競合状態であり、見つけるのが非常に面倒です。 現在のメインラインカーネルのスナップショットを撮り、IPV6サブシステムから始まるさまざまな呼び出しのインストルメント化に取り組んでいます。 この問題は間違いなく再現可能です。あなたがしなければならないのは、たくさんのコンテナを作成し、それらから大量のネットワークトラフィックをプッシュし、コンテナ内のプログラムをクラッシュさせ、それらを削除することだけのようです。 これを何度も繰り返すと、数分で問題が発生し、物理的な4コアワークステーションでトップになります。

残念ながら、これに取り組む時間はあまりありません。必要な部分をインストルメント化するために協力してくれるカーネル開発者がここにいる場合は、フォークをセットアップして、これを段階的に探し出す作業を開始できると思います。 。

@ iamthebot 、qemu-kvmセットアップで再現可能ですか？

@iamthebot私はこれをさまざまなカーネルで数回再現しようとしました。 上記のどこかで、 userland-proxyをfalseに設定してdocker-stress -c 100を使用するとトリガーされると述べられていましたが、運がありませんでした。

より信頼性の高い再現がある場合（トリガーに時間がかかる場合でも）、試してみることができます

本番環境とステージング環境でも同じ問題が発生します。 間もなくDocker1.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カーネル開発にはあまり興味がありませんが、「私も」というコメントはそれほど役に立たないと言っているのは正しいと思います。 つまり、「カーネルvx.xとDocker 1.xでもこの問題が発生している」と言っても、議論に新しいことは何ももたらされません。

しかし、私は、再現するための環境と方法をより詳しく説明する「私も」コメントが非常に価値があることを提案します。

すべてのコメントを読むと、いくつかの問題があることは明らかです-以前に投稿したように、vethXYZにあるもの、eth0にあるもの、lo0にあるものがあります。 これは、さまざまな問題が原因である可能性があることを示しています。 したがって、エラーと環境の完全な説明なしに「私も」と言うだけで、人々を誤解させる可能性があります。

また、環境を説明する場合、カーネルとDockerのバージョンを指定するだけでは不十分です。 スレッドごとに、ipv6が有効になっているかどうかなどのいくつかの要因があるようです。 NodeJSがSIGINT（または他のコンテナー、ここではNodeJSをバッシングしていない）に応答していません。

したがって、環境のワークロードが何であるかを説明することは役に立ちます。 また、これはコンテナがシャットダウンされているときに発生するため、この問題が発生した場合は、問題が醜い頭を抱えているときにどのコンテナが停止されているかに注意することをお勧めします。

問題はカーネルに競合状態があるように見えますが、トリガーを特定することは、問題を修正する人にとって非常に役立ちます。 また、影響を受けるユーザーに、NodeJSアプリケーションにシグナルハンドラーを実装するなどの即時の解決策を提供することもできます（これにより問題がトリガーされないことはわかりませんが、他の人の以前のコメントによるとそうです）。

FWIW kubernetesは、これをvethの「ヘアピンモード」と完全に関連付けています。
その機能の使用を完全に停止しました。 私たちはこれを経験していません
何万台もの生産機械にまたがって、そして非常に大きな問題
変更してから、より多くのテストを実行します。

これが修正されるまで、船を放棄します。 別の解決策を見つける:(

2017年2月15日水曜日の午前10時、ETLnotifications @ github.comは次のように書いています。

この問題を修正しているのは私ではありませんが、Linuxにはあまり詳しくありません。
カーネル開発者、私は「私も」コメントはそうではないと言っているのは正しいと思います
役に立ちました。 つまり、「私にもこの問題があります。
Kernelvx.xとDocker1.x "は、議論に新しいことを何ももたらしません。

ただし、「私も」というコメントで、
再現するための環境と方法は非常に価値があります。

すべてのコメントを読むと、いくつかの問題があることは明らかです-
以前に投稿したように、vethXYZを使用するもの、eth0を使用するもの、lo0を使用するものがあります。
これは、さまざまな問題が原因である可能性があることを示しています。 これだけ
エラーと環境の完全な説明なしに「私も」と言うと、
人々を誤解させる。

また、環境を説明するときは、カーネルと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：f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8"、 "Size"：5737}}

Dockerイメージが正常に公開されました

2月16日19:49:16のsyslogd @ ip-172-31-31-68からのメッセージ..。
カーネル：[1611081.976079] unregister_netdevice：loが解放されるのを待っています。 使用回数= 1

2月16日19:49:27のsyslogd @ ip-172-31-31-68からのメッセージ..。
カーネル：[1611092.220067] unregister_netdevice：loが解放されるのを待っています。 使用回数= 1

[1] +停止しました./image-publish.py
[ root @ ip-172-31-xx-xx image-publish]＃^ C
[ root @ ip-172-31-xx-xx image-publish]＃

@thockinは、この設定が--hairpin-mode=noneですか？

= noneは、NATされたコンテナを壊します。 を使用しております
promiscuous-デフォルトでブリッジ。

19:26の木、2017年2月16日には、カナトBekt [email protected]
書きました：

@thockinhttps ：//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どのコンテナが

それは私が思っていたよりも一般的であることが判明しました、そして私たちがそれを壊したとき、たくさん
不平を言った人々の。

2017年2月17日午前0時38分、「MaximIvanov」 [email protected]は次のように書いています。

@thockinhttps ：//github.com/thockinどのコンテナが
Service ClusterIPを介して自分自身にアクセスしますか？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/docker/issues/5618#issuecomment-280588366 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AFVgVLn3uBvUW-dQ72qst5_eYiFUtfSVks5rdVyIgaJpZM4B4L4Z
。

一部のドッキングされたnodejsアプリがこの問題を引き起こす可能性がある理由を私は知っていると思います。 ノードはデフォルトでキープアライブ接続を使用します。 server.close()が使用されている場合、サーバーは新しい接続を受け入れません。 ただし、WebSocketやHTTPキープアライブ接続などの現在アクティブな接続は引き続き維持されます。 ドッキングされたアプリもnにスケーリングされると、強制終了時に新しいアプリが解放されたため、 waiting for lo to become freeになる可能性があります。 dockerがこのアプリを別のノードに再配布するか、アプリが縮小されると、dockerはアプリにシャットダウンする必要があるというシグナルを送信します。 アプリはこの信号をリッスンし、反応することができます。 数秒経ってもアプリがシャットダウンされない場合、dockerはためらうことなくアプリを終了します。 シグナルハンドラーを追加したところ、 server.close()するとサーバーが完全に終了するわけではなく、「のみ」が新しい接続の受け入れを停止することがわかりました（https://github.com/nodejs/node/issues/2642を参照）。 したがって、WebSocketやhttpキープアライブなどの開いている接続も閉じていることを確認する必要があります。

WebSocketの処理方法：
nodejsアプリは、シャットダウン信号を受信すると、すべてのWebSocketにcloseSocketsを発行します。 この上のクライアントリッスンcloseSocketsイベントと呼び出し、 sockets.disconnect()と直後にsockets.connect() 。 server.close()が呼び出されたため、このインスタンスは新しいリクエストを受け入れないことに注意してください。 このDocker化されたアプリの他のインスタンスが実行されている場合、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();
}

もう1つの可能性は、キープアライブタイムアウトを非常に低い数値に設定することです。 たとえば、0.5秒。

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

これが他の人を助けることができることを願っています:)

同じ問題があります。 添付ファイルは、ecs-logs-collectorスクリプトから作成されたすべてのログです。
助けてくれてありがとう:)

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

同じ問題。 特権コンテナでマウントを使用しています。 4〜5回実行すると、フリーズします。 また、16.04の最新の標準カーネルでも同じ問題が発生します

みなさん、 @ etlweatherは的を

@rneugeba @redbaron残念ながら、私が持っている現在の「再現」は非常にハードウェア固有です（これを証明する以外はすべて競合状態です）。 QEMUの再現を試したことはありませんが、これは間違いなく次のステップなので、複数の人が実際にこれに取り組み、期待される結果を得ることができます（理想的には1 CPUコアのセットアップで）。 誰かがすでに持っている場合は、私にメールを送ってください（それは私のプロフィールにあります）。 徹底的にテストして、ここに投稿します。

これはGCEでかなり頻繁に取得されています。 Dockerがフリーズし、再起動時にマシンがハングします。

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

コンテナーはgoアプリケーションを実行しており、ヘアピンNATが構成されています。

Docker：

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

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

Ubuntu 16.04 LTS、

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

誰かがこれに対する提案された回避策を持っていますか？ --userland-proxy=trueを有効にしようとしましたが、しばらくするとdockerがハングします。 Kubernatesには@thockinが上で書いたものからの解決策があるようですが、 --hairpin-mode=promiscuous-bridge正確に何をするのか、そしてプレーンなジェーンubuntu 16.xdockerインストールでそれを構成する方法は明確ではありません。

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がこのシステムにインストールされておらず、インストールされたことがないことは注目に値します。 コミュニティがこの問題のトラブルシューティングに必要なデータを提供できれば幸いです。実行するコマンドを教えてください。

マウントされたnfsボリュームがマップされたdtrを実行しているスウォームワーカーノードとして実行されているcentos7.3でこれを再現できます

ここに到着する場合

ここで説明している問題はカーネルのバグであり、まだ修正されていません。 _いくつかの_状況に役立つ可能性のあるオプションがいくつかありますが、すべてではありません（同じエラーを引き起こす問題の組み合わせである可能性が高いです）

「私もこれもあります」というコメントを残さないでください

「私もこれを持っています」はバグの解決に役立ちません。 問題の解決に役立つ可能性のある情報がある場合にのみコメントを残してください（その場合、アップストリームのカーネルにパッチを提供することが最善のステップである可能性があります）。

この問題があることを知らせたい場合は、上部の説明にある[

更新に関する最新情報を入手したい場合は、_サブスクライブボタン_を使用してください。

ここにあるすべてのコメントは、3000人を電子メール/通知を送信します。この問題に関する会話はまだ解決されていないため、ロックしたくありませんが、これを無視すると強制される可能性があります。

ありがとう！

それはすべてうまくいっていますが、役立つオプションは何ですか？ この問題は本番環境で問題を引き起こしているので、カーネルのバグを回避するために必要なあらゆる回避策を実行したいと思います。

Dockerの誰かがKubernetesの回避策を試す時間があれば、どうぞ
私に知らせてください、そして、私たちはあなたにそれを指摘することができます。 変更を抽出できません
今すぐDockerにパッチを適用します。

7:46の木、2017年3月9日には、マシューNewhook [email protected]
書きました：

それはすべてうまくいっていますが、役立つオプションは正確には何ですか？
この問題は私たちに本番環境で問題を引き起こしているので、私は何でもしたいです
カーネルのバグを回避するために必要な回避策。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/docker/issues/5618#issuecomment-285388243 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AFVgVGdH5VX_oFWkImyo_TvlIuhmwMepks5rkB7MgaJpZM4B4L4Z
。

@thockinありがとう。 私はヘアピンモードの回避策でKubernetesのPR /問題をフォローしていました。 しかし、何度も行ったり来たりしながら、回避策の事実がこの問題を取り除くかどうか私は道に迷いましたか？
（私が理解しているように、カーネルでref-countの不整合を引き起こすさまざまなシナリオがあります）。

K8sの問題に対処していると思われるPRを教えていただければ、デフォルトでuserland-proxyをオフにする場合に備えて、少なくともDockerでパッチを適用するように努めます。 （そして、docker-stressの再現手順を使用してテストできます）。

PRが1つあるかどうかはわかりませんが、現在の状態を確認できます。 始める
ここ：

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

22:49時土、2017年3月11日には、マドゥVenugopal [email protected]
書きました：

@thockinhttps ：//github.com/thockinありがとう。 私はフォローしていました
ヘアピンモードの回避策を使用したKubernetesでのPR /問題。 しかし、
多くの場合、回避策の事実がこれを取り除くと、私は道に迷いました
問題 ？
（私が理解しているように、ref-countを引き起こすさまざまなシナリオがあります
カーネルの不整合）。

K8sの問題に対処していると思われるPRを教えていただければ、
少なくとも回転する場合に備えて、これをdockerにパッチするように努めます。
userland-プロキシはデフォルトでオフになっています。 （そして、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でも同じことができます。 バグに遭遇する可能性は低くなります

さて、理論的にはこれは機能しないはずです...しかし、何らかの理由で、無差別モードではデバイスの分解が十分に遅くなり、refカウンターをデクリメントする競争が発生しないようです。 おそらく、Kurbernetesの寄稿者の1人が、このスレッドに参加している場合は、ここでチャイムを鳴らすことができます。

環境固有の再現を使用して、回避策（修正ではない）が機能することを確認できます。 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 ）の1つであることがわかりました。 そして、何かがその特定のdst_entryがgcされるのを妨げています（ dst_entryの参照カウントが0より大きい）。 私はすべて記録されてdst_hold() 、および（1によってインクリメントdst_entryの参照カウントを） dst_release() （1でデクリメントdst_entry参照カウント）、および実際よりありdst_hold() 、その後の呼び出しdst_release() 。

添付されているログは次のとおりです：

概要：

• loインターフェースは、grepを簡単にするためにlodebugに名前が変更されました
• dst_entryの参照カウントは1から始まります
• 最後のdst_entry （loの参照を保持している）の参照カウントは19です。
• 合計dst_hold()呼び出しが258041あり、合計dst_release()呼び出しが258023あります。
• 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で複数回呼び出されていますが、1つしかありませんdstへの参照を解放するための対応するinet_sock_destruct() dst 。

これが私のためにそれを修正したCentOS7.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このパッチは、カーネルで「使用回数」の問題を引き起こす可能性のある競合状態の1つにのみ対処します。 これは、すでに4.xカーネルにあるものからのバックポートされた修正です。 それはあなたの問題を解決するかもしれないので、それは一撃の価値があります。

@stayclassychicago 3.10.0-514.10.2.el7.centos.plus.x86_64カーネルを試す前は、コンテナが終了したときにdocker run --rm ...コンテナを実行するたびに、非常に定期的にkernel:unregister_netdevice: waiting for lo to become free. Usage count = 1を取得していました。 カーネルをアップグレードして再起動した後、カーネルは何時間も完全に停止し、その後再び戻ってきました。 コンテナを削除する時間の半分は正しく機能しますが、以前はエラーが発生していました。 新しいカーネルが役立っているかどうかはわかりませんが、問題はありません。

マシンにLACPボンディングインターフェイスがあると、非常に簡単に再現できるように見えます。 3ノードのスウォームクラスターがあり、3つすべてにLACPボンディングインターフェイスが構成されていますが、この問題では基本的にクラスターを操作できません。 15〜20分ごとにノードを再起動する必要があります。

確認済み-インターフェイスからLACPボンディングを削除すると（メインインターフェイスとして使用されていました）、すべてが12時間以上正常に機能しています。 30分ごとに休憩するために使用されます。

これは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で再現可能であり、cifsマウントが開いている場合は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（カーネル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ボリュームをマウントしてからコンテナを再起動すると、この問題が発生しました。
この問題は、同じ手順でRHEL7では発生しなかったようです。

$ 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にリベースすると思います。 このパッケージは、CentOS7でもすでに利用可能です。

修正に関連するドキュメント（RHNアクセスが必要）：
https://access.redhat.com/articles/3034221
https://bugzilla.redhat.com/show_bug.cgi?id=1436588

記事から：
「IPv6アドレスが重複している場合、またはアドレスの設定に問題がある場合、競合状態が発生しました。この競合状態により、アドレス参照カウントのリークが発生することがありました。その結果、ネットワークデバイスの登録解除の試行が失敗し、次のエラーメッセージが表示されました。 "unregister_netdevice：waiting自由になるために。 使用回数= 1 "。この更新により、基盤となるソースコードが修正され、ネットワークデバイスは、説明されている状況で期待どおりに登録解除されるようになりました。"

私はすでにこの修正をPaaSプールのすべてのシステムにデプロイしており、バグが発生することなくすでに2日が経過しています。 以前は、1日に少なくとも1つのシステムが凍結されていました。 再度バグが発生した場合は、ここで報告します。

カーネルバージョン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=1436588バグがありますこの変更により「修正」されました：

+- [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から1時間に1回このテストスクリプトを実行することで、システムのバグを再現できます。

#!/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を使用していません。
単純なブリッジとポートフォワーディング（userland-proxyに関係なく発生します
設定）。

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
。

OK、vxlanトンネルを使用していない場合は、間違いなく役に立ちません。

ところで、ネットワーク名前空間が削除されたときに「unregister_netdevice」メッセージの単一のインスタンスが表示された場合（コンテナ出口）、ネットデバイスを参照する何かが名前空間と同時に多かれ少なかれクリーンアップされた通常の状況と見なす必要があります
削除されていました。

より深刻なケースは、このメッセージが10秒ごとに繰り返され、停止しない場合です...
この場合、グローバルロックは永久に保持され、ネットワークがネットワークに接続されるたびにこのロックを取得する必要があるためです。
名前空間が追加または削除されます。ネットワーク名前空間を作成または削除しようとすると、
永遠にハングします。

2番目のタイプの問題を再現するためのかなり苦痛のない方法がある場合は、私は興味があります
見てください。

@hlrichardson上記の2番目のケースが

yumの使用中にcentos：7コンテナーをテストおよび構築しているときに、

こんにちは、みんな、

Linuxのnet-devメーリングリストには、カーネルのバグ（または少なくとも1つのバグ）に対する潜在的なパッチがあります。

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 / linux @ d747a7aが完全な修正ではないはずです。

$ uname -r
4.12.0-041200-generic

ライアン、信頼できる再現方法はありますか？

2017年7月6日16:29、「RyanCampbell」 [email protected]は次のように書いています。

4.12を実行しています（http://kernel.ubuntu.com/~から）
kernel-ppa / mainline / v4.12 /）そして私はまだこれをヒットしたので、torvalds / linux @
d747a7ahttps ：//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ほんの数回の反復の後、syslogの

@campbellr私は今これを3回再現しようとしていて、今週のかなりの部分を少しの運でそれに費やしました。 waiting for lo to become freeメッセージを数回受け取ることができましたが、その後クラッシュ/ハングすることはありません

テストスイートの場合：

• コンテナには多くのネットワークアクティビティがありますか？ もしそうなら、どちらの方向が支配的ですか？
• これを実行しているマシンの種類（コアの数、VMなど）
• 同時にたくさんのコンテナを作成しますか？
• コンテナは正常に終了しますか、それともクラッシュしますか？

上記の部分的な答えでさえ、それを絞り込むのに役立つかもしれません...
ありがとう

@rn Dockerは、通常はハングするネットリンク要求にタイムアウトを設定するため、ハングしなくなりました。 ただし、新しいコンテナを開始（または既存のコンテナを再起動）することはできません。停止時のコンテナのクリーンアップも奇妙なものになる可能性があります。

4.12でテストする機会はまだありませんが、vultrのkvmインスタンスで確実に再現できました。 私は群れを実行していますが、ヘッドレスクロームワーカーがヘルスチェックに失敗したり、定期的にクラッシュしたりすると、問題が発生します。 もちろん、この時点で、すべてのクラッシャーがネットワークエラーなどをきれいに処理していることを追跡したので、 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のバイナリブロブです。

これを実行しているマシンの種類（コアの数、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ユーザーの皆様、カーネルバージョン4.12を搭載した次のKubernetes AMIをリリースするために、_kops_に問題を公開しました。 チェックアウトへようこそ： https ：

また、ホストカーネル3.10.0-514.6.1.el7.x86_64およびdocker-ce-17.06.0.ce-1.el7.centos.x86_64を使用してcentos7.3でこれをヒットしました。

@FrankYuそれは役に立ちません。 このスレッドに効果的に参加するには、この問題を再現する正確な方法を提供し、最新のカーネルでテストしてください。 3.10は4年前にリリースされましたが、4日前からのリリースで修正されるのか、部分的にリリースされるのかについて話し合っています。

@danielgusmao私たちのRancherOSとAWSECS AMI linux OSにはすでにその「修正」があり（おそらくデフォルトでした）、それは私たちの問題を解決しません。 メッセージは常にログに表示されます。 おそらく唯一の希望は、カーネルパッチが広くバックポートされることです。 RedHat / Centos / AWS linuxのバグジラやフォーラムで検索したところ、それに向けた深刻な進歩の証拠はまだ見当たりませんでした。

明確にするために、メッセージ自体は良性であり、OPによって報告されたメッセージの後にカーネルがクラッシュしますが、そうではありません。

このメッセージの送信元であるコード内のコメントは、何が起こっているかを説明しています。 基本的に、ネットワークデバイス（コンテナ内のvethペアの終わりなど）のすべてのユーザー（IPスタックなど）は、ネットワークデバイスを使用しているときに、ネットワークデバイス構造の参照カウントをインクリメントします。 デバイスが取り外されると（たとえば、コンテナが取り外されると）、各ユーザーに通知が届き、参照カウントを減らす前に、クリーンアップ（開いているソケットを閉じるなど）を実行できるようになります。 このクリーンアップには時間がかかることがあるため、特に負荷が高い場合（インターフェイスが多い、接続が多いなど）、カーネルがメッセージをここに出力することがあります。

ネットワークデバイスのユーザーが参照カウントをデクリメントしない場合、カーネルの他の部分は、クリーンアップを待機しているタスクがスタックしていると判断し、クラッシュします。 カーネルのバグを示すのはこのクラッシュだけです（一部のユーザーは、コードパスを介して、参照カウントをデクリメントしませんでした）。 そのようなバグがいくつかあり、それらは最新のカーネルで修正されています（そしておそらく古いものにバックポートされています）。 私はそのようなクラッシュをトリガーするためにかなりの数のストレステストを書きました（そしてそれらを書き続けました）が、現代のカーネルでは再現できませんでした（しかし私は上記のメッセージをします）。

カーネルが実際にクラッシュした場合にのみ、この問題について報告してください。そうすれば、次のことに非常に関心があります。

• カーネルバージョン（ 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このパッチは、今後の安定版リリースにも

@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ジョブを使用）は、すでに実行されていると見なし（ start: Job is already running: docker ）、アップスタートを停止しようとするため、新しいdockerdプロセスを開始しません。ジョブも失敗します（ 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つのリポジトリ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（テストリポジトリ）と同じ結果
• 4.11.11-coreos： docker-samba-loopで同じ結果、 docker-nfs-loop試しません

お役に立てれば
乾杯

回避策は、私の場合は--net=hostを使用することです。 しかし、それは常に受け入れられる解決策ではありません

@piec 、詳細に感謝します。 この非常に長いコメントの最後に、もう少し質問があります。

SMBセットアップを使用して、さまざまなカーネルでさまざまなものを作成することができました。 NFSセットアップでもこれを試しましたが、サイコロはありません。

すべてのテストは、2つのvCPUと2GBのメモリで構成されたVMを備えたHyperKitのdocker 17.06.1-ceで実行されます（Mac用のDocker経由ですが、それは問題ではありません）。 LinuxKitカーネルを使用しているのは、それらを簡単に交換できるからです。

私はあなたの変更Dockerfile私はへの呼び出しを追加ことでdateに最初のコマンドを実行しても、追加として呼び出しをdateの前にandeafter docker runについてクライアント。

実験1（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..

unregister_netdeviceメッセージ（以下を参照）を含む、4.11.12カーネルが行うことのいくつかの反復を時々見た後、上記のカーネルクラッシュが発生します。 次のように、クラッシュのわずかな変化が見られることがあります。

[  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ドメインソケットコードにあり、
ここで報告されてい

実験2（4.11.12カーネル）

私はクラッシュを見ていない（4.11シリーズの最新安定している）、それは本当に遅い（インラインでの注釈である4.11.12 ---> ）：

# 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

これを1時間ほど実行し、同じパターンを繰り返しましたが、カーネルのクラッシュはありませんでした。

私が見るカーネルログには、次のものがたくさんあります。

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

それは10秒ごとのメッセージです。

これにより、1時間経ってもハングしたタスクの検出が開始されないため、4.11.12では、参照カウントが最終的に減少し、デバイスが解放されると思われますが、コンテナーを実行できる間隔から判断すると、時間がかかる場合があります。最大4分！

実験3（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（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を取得しているようです（2番目のものを除く）。 その間、新しいコンテナーを開始できないと思われます（実験2で示されているように）。おそらくタスクがハングしていないために、ハングしたタスクの検出が開始されないのは不思議です。

実験5（4.11.12 / 4.9.39、カーネルで追加のデバッグを有効にする）

これはdocker run間に1秒のスリープに戻ります

たくさんの追加のデバッグを可能にする別のカーネルがあります
LOCKDEP 、 RCU_TRACE 、 LOCKUP_DETECTORなどのオプション
もっと。

これらのデバッグオプションを有効にしてrepro4.11.12カーネルを実行しても、何もトリガーされませんでした。

通常のカーネルがクラッシュする4.9.39カーネルについても同様です。 デバッグオプションはタイミングをわずかに変更するため、これは、UNIXドメインソケットコードのクラッシュが示す追加の手がかりは、競合によるものである可能性があります。

もう少し深く掘る

さまざまなcontainerdプロセスのstraceは役に立ちません（
通常、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を処理しています。

ブロックされたタスクを表示する（2回）

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コンソールにアクセスでき、クラッシュダンプに関して何かあるかどうかを確認できますか、それとも私が見ているように大幅な遅延が発生するだけですか？ あなたがクラッシュダンプを持っているなら、私はそれを見ることに非常に興味があります。 また、ベアメタルで実行していますか、それともVMで実行していますか？ CPUとメモリの観点からあなたの構成は何ですか？

@rn調査に感謝します！

ベアメタルデスクトップPCで実行しているので、すべてにアクセスできます。 それはi7-4790K + 32GiBです。
現在、テストリポジトリ（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また、アンマウント後にDockerfileでリプロとsleep 1してこれをテストしました。すべてが期待どおりに機能し、ストールやunregister_netdevメッセージはありません。

これを今すぐ書いてnetdev@vger送ります

優秀な
アンマウント後のsleepで、セットアップのストールとunregister_netdevメッセージが修正されることを確認しました

umountは、そのnetnsに対して非同期アクションを生成し、そのアクションが終了する前にnetnsが削除されると、ブロックされ、最終的にタイムアウトになると思いませんか？ マウント後のスリープは、ネットが削除される前にこのようなものを終了させます。
しかし、それは単なる仮説です

私はアンマウントなしで、同じ違いを試しました。 これは、ネットワーク名前空間の削除です。 その9とマウント名前空間の削除は、とにかくアンマウントをトリガーします。

ああ、わかりました。

ちなみに、smbを使用して別のマシンで（開発中に）誤って問題を再現しました。 これはUbuntu16.04 PC、Linux4.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カーネルイメージで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-316881443のようにトリックが実行され

@rn情報をありがとう。 私はまだその方法を試していません。

こことnetdevメーリングリストへの最近の投稿は、カーネルストールに関するものにすぎないようです。
カーネル4.11と4.12でもカーネルがクラッシュします。

これと非常によく似た問題が発生しています（＃35068で詳しく説明されています）。 基本的に2ノードの群れを実行します。これは、スプレッド配置戦略を使用して4つのレプリカで単一のサービスを実行します。

これらの各サービスコンテナーで、ホストdocker.sockをボリュームとしてマウントし、コンテナー内からdocker runコマンドを実行します。コンテナーあたりの最大同時実行数は4です。 これにより、最大4つのコンテナが同時に作成され、 -rm介してすぐに削除されます。

上記のリファレンスに示されているARMv7の追加のカーネルログと例。

ip6_route_dev_notifyパニックは私たちにとって深刻な問題です。

これをもう少し見てみると、これは間違いなく次と同じバグではないと思います。

• 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_）で、次のブートカーネルオプションを使用して1つのCPUでのみ実行されます。

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

この状態になると、この状態のままになり、再起動が必要になります。 これ以上コンテナをスポーンすることはできません。 ipsec / openvpn接続を実行するイメージを実行し、トンネル内に小さなファイルをダウンロードすることで、それを再現します。 次に、インスタンスが存在します（通常、実行時間は10秒未満です）。 このようなコンテナを1台のマシンで1分間に数十回実行します。 上記の設定（1cpuのみ）を使用すると、マシンは約2時間でヒットします。

同じカーネルを使用しているが、CPUの数を制限しない別の再生装置は、コンテナー内で3秒間UDPモードでiperfを実行することです（したがって、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

ワークロードの説明（コンテナーのタイプ、ネットワーク負荷のタイプなど）：終了する前にスクリプトを実行する非常に短命のコンテナー（数秒から数分）。

そして理想的には単純再生産：

** kernel：[617624.412100] unregister_netdevice：loが解放されるのを待っています。 使用回数= 1

影響を受けるノードで古いコンテナを強制終了したり、新しいコンテナを起動したりできませんでした。機能を復元するには再起動する必要がありました。**

うまくいけば、根本的な原因/パッチがすぐに見つかります。

よろしくお願いします、

robputt796

@campbellr
ネットワークストレージと関係があるようだということに同意した。 kubernetesの永続ボリュームとしてcephkrbdを使用しています。
そして、コンテナのクラッシュを長時間実行した後の状況を再現できます。

この問題は10日前に割り当てられ、進行中の作業です。ここで何が起こっているかについての詳細を確認できます

うまくいけば、ダンストリートマンはそれを修正する方法を見つけます

Oopsは、コミット76da0704507bbc51875013f6557877ab308cfd0aによって修正されたカーネルバグが原因であることが判明しました。

ipv6：NETDEV_UNREGISTERに対してip6_route_dev_notify（）を1回だけ呼び出します

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76da0704507bbc51875013f6557877ab308cfd0a
（これは、「kernel：unregister_netdevice：loが解放されるのを待っています。Usagecount= 2」の問題ではなく、カーネルパニックを修正するだけです。）

（GitHubが古いコメントを非表示にしているため、ここでこれを繰り返します）

ここに到着する場合

ここで説明している問題はカーネルのバグであり、まだ完全には修正されていません。 この問題の発生を修正するパッチがカーネルに組み込まれましたが、他のパッチはまだ解決されていません。

_いくつかの_状況に役立つ可能性のあるオプションがいくつかありますが、すべてではありません（繰り返しますが、同じエラーを引き起こす問題の組み合わせである可能性が高いです）

「私もこれもあります」というコメントを残さないでください

「私もこれを持っています」はバグの解決に役立ちません。 問題の解決に役立つ可能性のある情報がある場合にのみコメントを残してください（その場合、アップストリームのカーネルにパッチを提供することが最善のステップである可能性があります）。

この問題があることを知らせたい場合は、上部の説明にある[

更新に関する最新情報を入手したい場合は、_サブスクライブボタン_を使用してください。

ここにあるすべてのコメントは、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/でます。

回避策はありませんか？

ホストネットワークを使用します（これにより、コンテナーの価値の多くが破壊されますが、そこに行きます）。

@ 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を無効にした後（fron 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：eth0が解放されるのを待っています。使用回数= 1」が発生しました。カーネルレベルでipv6を無効にしてみてください。 クラウドが機能することを願っています。

@ wuming5569そのバージョンのLinuxで問題が解決したかどうか

@ wuming5569たぶん、カーネル4.4.114をアップグレードして、「unregister_netdevice：loが解放されるのを待っています。Usagecount= 1」を修正し、「unregister_netdevice：eth0が解放されるのを待っています。Usagecount= 1」を修正します。
私は本番環境でテストしました。
@ddstreetこれはフィードバックです、何か助けはありますか？

@ wuming5569上記のように、メッセージ可能性があります。 カーネルがハングしますか？ハングしている場合、ネットワークパターンは何ですか？つまり、コンテナはどのタイプのネットワークを実行しますか？

CentOSで同じ問題が発生しました。 私のカーネルは3.10.0-693.17.1.el7.x86_64です。 しかし、syslogで同様のスタックトレースを取得できませんでした。

Centos7カーネル3.10.0-514.21.1.el7.x86_64およびdocker18.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は

CentOS7カーネル4.16.0-1.el7.elrepo.x86_64およびdocker18.03.0-ceでも同じ

クラッシュする前の数週間は機能しましたが、起動しようとすると完全にスタックしました。

この問題はカーネル3.10.0-693.21.1.el7でも発生しました

私はそれがまた起こることを確認することができます：

Linux 3.10.0-693.17.1.el7.x86_64
Red Hat Enterprise Linux Serverリリース7.4（Maipo）

ある程度の負荷をかけながら「servicedockerrestart」を行うことで再現できます。

@ wuming5569この問題を修正しましたか？ネットワークタイプは何ですか？ 私たちはこの問題に何週間も混乱してきました。
wechatアカウントをお持ちですか？

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にアップグレードしました。 観察。 このバグは、1つのノードで週に1回程度しか発生しませんでした。

grub boot paramsまたはsysctlでipv6を無効にしましたか？ ブートパラメータのみが機能します。 Sysctlはそれを修正しません。

2018年6月4日12:09:53 PMに、Sergey Pronin（ [email protected] （mailto：[email protected]））は次のように書いています。

4.15.18でさえこのバグを助けません
ipv6を無効にしても効果はありません

4.16.13にアップグレードしました。 観察。 このバグは、1つのノードで週に1回程度しか発生しませんでした。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHub（https://github.com/moby/moby/issues/5618#issuecomment-394410321）で表示するか、スレッドをミュートします（https://github.com/notifications/unsubscribe-auth） / AAo3HLYI_jnwjgtQ0ce-E4mc6Em5yeISks5t5VvRgaJpZM4B4L4Z）。

私にとって、ほとんどの場合、同じプロジェクト/ネットワークを再デプロイした後にバグが発生します

@qrpikeあなたが正しいです、私たちはsysctlだけを試しました。 幼虫を試してみましょう。 ありがとう！

4.9.88Debianカーネル。 再現可能。

@qrpikeあなたが正しいです、私たちはsysctlだけを試しました。 幼虫を試してみましょう。 ありがとう！

私の場合、ipv6を無効にしても違いはありませんでした。

@ spronin-aureaブートローダーでipv6を無効にすることは役に立ちましたか？

@qrpikeで、ipv6を無効にすると、使用しているノードについて教えてください。 カーネルバージョン、k8sバージョン、CNI、dockerバージョンなど。

@komljen私は過去2

私の側では、CoreOSも使用していますが、ipv6はgrubで無効になっていますが、まだ問題が発生しています

@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ではまだこの問題は発生していません

4.17.3-1カーネルを搭載したCentos7.5でも、問題が発生しました。

環境：
kubernetes 1.10.4
Docker 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の間に、関連するロックをリファクタリングするKirillTkhaiによるパッチが多数ありました。 影響を受けるディストリビューション/カーネルパッケージのメンテナは、おそらくそれらを安定したカーネルに適用/バックポートすることを検討し、それが役立つかどうかを確認する必要があります。
参照： 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
• docker：18.03.1

CentOS7で同じ問題

• カーネル：4.11.1-1.el7.elrepo.x86_64
• docker：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の関数の1つを含む1つ以上の他のトレースが、 net_mutex （ cleanup_net 、 net_ns_barrier 、 net_ns_init 、 {,un}register_pernet_{subsys,device} ）。 もちろん、安定したカーネルの場合、4.18からのすべてのロック変更をバックポートするよりも、修正可能な方法でデッドロックが発生した場合の方がはるかに簡単です。 しかし、これまでのところ、根本的な原因につながる痕跡は見ていません。 それが役立つかどうかはわかりませんが、問題が発生したときに、上記の関数を備えた他の/proc/*/stackが表示される可能性がありますか？

同じ問題！ 私のenvはdebian8です

RHEL、SWARM、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

数分後、マネージャーノードのコンソールに戻り、開始されたコンテナーが実行されなくなりました。

これは同じ問題を説明していますか、それともこれは別の「問題スイート」ですか？

事前にTHX！

アップデート
これは、sshコンソール（swarm manager bash）でも直接発生します。

アップデート
ホストマシン（群れの1つのマネージャーノード）：
Linux [MACHINENNAME] 3.10.0-514.2.2.el7.x86_64＃1 SMP Wed Nov 16 13:15:13 EST 2016 x86_64 x86_64 x86_64 GNU / Linux

しばらくしても問題が解決しない場合は、別の問題です。

CentOS7.5カーネル3.10.0-693.el7.x86_64およびdocker1.13.1でも同じ

同じ問題OEL7.5
うなめ-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
Docker情報
コンテナ：9
実行中：5
一時停止：0
停止：4
画像：6
サーバーバージョン：17.06.2-ol

dmesg
[2238374.718889] unregister_netdevice：loが解放されるのを待っています。 使用回数= 1
[2238384.762813] unregister_netdevice：loが解放されるのを待っています。 使用回数= 1
[2238392.792585] eth0：vethbed6d59から名前が変更されました

（GitHubが古いコメントを非表示にしているため、このhttps://github.com/moby/moby/issues/5618#issuecomment-351942943をここで繰り返します）

ここに到着する場合

ここで説明している問題はカーネルのバグであり、まだ完全には修正されていません。 この問題の発生を修正するパッチがカーネルに組み込まれましたが、他のパッチはまだ解決されていません。

_いくつかの_状況に役立つ可能性のあるオプションがいくつかありますが、すべてではありません（繰り返しますが、同じエラーを引き起こす問題の組み合わせである可能性が高いです）

「unregister_netdevice：loが解放されるのを待っています」エラー自体はバグではありません

カーネルクラッシュの場合はバグです（以下を参照）

「私もこれもあります」というコメントを残さないでください

「私もこれを持っています」はバグの解決に役立ちません。 問題の解決に役立つ可能性のある情報がある場合にのみコメントを残してください（その場合、アップストリームのカーネルにパッチを提供することが最善のステップである可能性があります）。

この問題があることを知らせたい場合は、上部の説明にある[

更新に関する最新情報を入手したい場合は、_サブスクライブボタン_を使用してください。

ここにあるすべてのコメントは、3000人を電子メール/通知を送信します。この問題に関する会話はまだ解決されていないため、ロックしたくありませんが、これを無視すると強制される可能性があります。

スレッドを（わずかに）短縮するために、有用な情報を追加しないコメントを削除します

この問題の解決を支援したい場合

• 非表示になっているコメントを含め、スレッド全体を読んでください。 それは長く、githubはコメントを非表示にします（したがって、コメントを再び表示するにはクリックする必要があります）。 このスレッドにすでに存在する情報があなたを助ける可能性がある場合はたくさんあります

• 役立つ情報については、このコメントhttps://github.com/moby/moby/issues/5618#issuecomment -316297818（およびその前後のコメント）をお読み

明確にするために、メッセージ自体は良性であり、OPによって報告されたメッセージの後にカーネルがクラッシュしますが、そうではありません。

このメッセージの送信元であるコード内のコメントは、何が起こっているかを説明しています。 基本的に、ネットワークデバイス（コンテナ内のvethペアの終わりなど）のすべてのユーザー（IPスタックなど）は、ネットワークデバイスを使用しているときに、ネットワークデバイス構造の参照カウントをインクリメントします。 デバイスが取り外されると（たとえば、コンテナが取り外されると）、各ユーザーに通知が届き、参照カウントを減らす前に、クリーンアップ（開いているソケットを閉じるなど）を実行できるようになります。 このクリーンアップには時間がかかることがあるため、特に負荷が高い場合（インターフェイスが多い、接続が多いなど）、カーネルがメッセージをここに出力することがあります。

ネットワークデバイスのユーザーが参照カウントをデクリメントしない場合、カーネルの他の部分は、クリーンアップを待機しているタスクがスタックしていると判断し、クラッシュします。 カーネルのバグを示すのはこのクラッシュだけです（一部のユーザーは、コードパスを介して、参照カウントをデクリメントしませんでした）。 そのようなバグがいくつかあり、それらは最新のカーネルで修正されています（そしておそらく古いものにバックポートされています）。 私はそのようなクラッシュをトリガーするためにかなりの数のストレステストを書きました（そしてそれらを書き続けました）が、現代のカーネルでは再現できませんでした（しかし私は上記のメッセージをします）。

*カーネルが実際にクラッシュした場合にのみ、この問題について報告してください*。そうすれば、次のことに非常に関心があります。

• カーネルバージョン（ uname -r出力）
• Linuxディストリビューション/バージョン
• Linuxベンダーの最新のカーネルバージョンを使用していますか？
• ネットワーク設定（ブリッジ、オーバーレイ、IPv4、IPv6など）
• ワークロードの説明（コンテナの種類、ネットワーク負荷の種類など）
• そして理想的には単純再生産

ありがとう！

Dockerを制限の下で実行していますか？ ulimits、cgroupsなどのように...

新しいsystemdには、設定していなくてもデフォルトの制限があります。 私は物事を無制限に設定しましたが、それ以来問題は発生していません（31日から視聴しています）。

私は多くの環境で同じ問題を抱えていました、そして私の解決策はファイアウォールを止めることでした。 今のところ、それは二度と起こらなかった

Rhel 7.5-3.10.0-862.3.2.el7.x86_64
Docker 1.13

@dElogicsどのバージョンのsystemdが「新しい」と見なされますか？ このデフォルトの制限はCentOS7.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バージョンCentOSLinuxリリース7.4.1708（コア）
ブリッジモード

同じ問題が発生しました。どうすればよいですか？

同じ問題：

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など]
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など]
CentOS Linuxリリース7.0.1406（コア）

Docker情報：
[ root @ zjsm-slavexx〜 ]
クライアント：
バージョン：17.04.0-ce
APIバージョン：1.28
Goバージョン：go1.7.5
Gitコミット：4845c56
構築：2017年4月3日月曜日18:01:50
OS / Arch：linux / amd64

サーバ：
バージョン：17.04.0-ce
APIバージョン：1.28（最小バージョン1.12）
Goバージョン：go1.7.5
Gitコミット：4845c56
構築：2017年4月3日月曜日18:01:50
OS / Arch：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日から視聴しています）。

わかりました、このバグはまだ発生していますが、確率は低下しています。

コンテナが正常に停止している場合（PID 1が存在する場合）、このバグは気になりません。

@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以降でこの問題を抱えていましたか？

このDanStreetmanの修正（https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d）は4.15カーネルバージョンに最初に含まれており、少なくとも誰かにとっては、4.16（https：/ /github.com/kubernetes/kubernetes/issues/64743#issuecomment-436839647）

誰かがそれを試しましたか？

@ victorgp4.15カーネルでまだ問題が発生しています。 4.16カーネルでテストしたときにここで報告します（できれば数週間以内に）。

カーネルバージョン：4.14.62を数か月使用しましたが、この問題は解消されました。

以前の解決策に追加するために、（SIGTERMに応答する）コンテナーを正常に停止しても、これがトリガーされることはありません。

また、問題を完全に解決するホスト名前空間でコンテナーを実行してみてください（許容できる場合）。

@dElogics 「ホスト名前空間」とはどういう意味ですか？ それは単に--privilegedですか？

@dElogics 「ホスト名前空間」とはどういう意味ですか？ それは単に--privilegedですか？

いいえ、それは--network = hostを意味します

カーネル4.4.0から4.15.0およびdocker1.11.2から18.09にアップグレードしてから、この問題は解消されました。

Dockerホストとして機能するVMのかなりの数のフリートで、この問題が1日に複数回発生しました（Dockerのユースケースを使用）。
45日が経過しましたが、これは表示されなくなりました。

後世のために、ハングしたDocker 1.11.2とprintkがunregister_netdevice: waiting for vethXXXXXを示しているスタックトレース（数百のVMで私たちのフリートで常に見られていたものと同様）はhttp：// pasteで見つけることができます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を呼び出し

コンテナを停止するときに一般的にバグが発生し、ネットでSKBがまだ参照されているため、vethが解放されないため、Dockerは15秒後にそのコンテナにKillを発行します。 Dockerデーモンはこの状況を適切に処理しませんが、最終的にはカーネルにバグがあります。 https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d（4.15アップストリームで受け入れられます。

一般に、カーネルのその部分はきれいな場所ではありません。

その価値のために... RHELLinuxカーネルを3.10.0から4.17.11にアップグレードしました。 （Kubernetesクラスターの実行）。 アップグレードする前は、このバグはさまざまなサーバーで毎日数回発生していました。 現在、アップグレードを3週間実行しています。 バグは1回だけ発生しました。 つまり、大まかに言うと99％削減されます。

@marckamerbeek RHELカーネルをコミュニティカーネルに更新しましたか？ その後、サポートされなくなります。

@BeatlorCentOSユーザーはこのようにすることができます。

centos 7.2にはまだこの問題があります： kernel：unregister_netdevice ：loが解放されるのを待っています。 使用回数= 1

@BeatlorRHELはまったく役に立ちませんでした。 安定した生産環境は、価値のないサポート契約よりも重要です。 4.17.11でも、現在も非常に安定しています。 もう大きな問題はありません。

@BeatlorRHELはまったく役に立ちませんでした。 安定した生産環境は、価値のないサポート契約よりも重要です。 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が解放されるのを待っています。 使用回数= 1

最新の4.19以降のカーネルへのアップグレードを試すことができます。

数ヶ月待つだけで、誰かが4.19カーネルについても不平を言うでしょう。 歴史が繰り返されるだけです。

みなさん、朗報です！

ここでの最後のコメント（執筆時点、17日前）以来、これらのエラーは二度と発生していません。 私のサーバー（そのうちの約30台）は、いくつかの古いパッケージでubuntu14.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/ee60ad219f5c7c4fb2f047f88037770063ef785f-5.1以降

私はhttps://github.com/kubernetes/kubernetes/issues/70427#issuecomment-470681000に挑戦し

Debian 9 Stretch（ 4.9.0-8-amd64 ）でDockerを実行しているマシンの1つでこの問題が発生しています。 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これはubuntu4.15.0-32で週に1回程度見られます。 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ですか？ 私はこの1週間、答えを見つけようとしていましたが、まだうまくいきませんでした。

@commixonの経験は、 https： //github.com/moby/moby/issues/5618#issuecomment -455800975で報告されているものと同じですが、数千のVMのフリート全体で、4.15.0で問題が再発することはありません。 Canonicalが提供する汎用のAWS最適化およびGCP最適化フレーバーのカーネル。 バニラ4.15.0での限定テストでも、これらの問題は示されませんでしたが、大規模なテストは行われませんでした。

どうもありがとう

@ethercflow @ 2rs2ts私たちはdebianも実行しています。 kpatch-buildを機能させようとすると多くの問題が発生しました。 回避策を見つけることができたら、投稿を続けます。 いずれにせよ、誰か他の解決策がありますか？ 問題を軽減するのはカーネルバージョン4.15または4.19ですか？ 私はこの1週間、答えを見つけようとしていましたが、まだうまくいきませんでした。

4.19にアップグレードできます。 それはバックポートにあります。

ところで、ここで私たちにとって1年になります。 ;）

実際にバックポートで4.19を試しましたが、他の領域でいくつかの大きなリグレッションが発生しました（EC2インスタンスはランダムに再起動し、起動時にネットワークが切断されます）。次の安定版までこれに対処する必要があると思います。

@ 2rs2ts過去4日間、バックポート（EC2内）から4.19を使用しており、問題はまったく発生していません。 カーネルクラッシュの問題はまったく発生しておらず、他のすべても問題ないようです。 違いはないと思いますが、Debianイメージはkops（https://github.com/kubernetes/kops/blob/master/docs/images.md#debian）から提供されたものに基づいています。 このイメージのカーネルを更新しましたが、ストックのDebianは更新していません。

友人、私は半年間安定した動作のために4.19カーネルを使用しています。 安定感もお楽しみいただければ幸いです。

私は、2週間ごとに80と443のポートを開いているコンテナを、別のコンピュータアクセスコンテナ80と
443は拒否されます

centos7.3カーネルバージョンは次のとおりです。
Linux browser1 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
Goバージョン：go1.10.4
Gitコミット：d7080c1
構築：2019年2月20日水曜日02:24:22
OS / Arch：linux / amd64
実験的：誤り

サーバ：
エンジン：
バージョン：18.06.3-ce
APIバージョン：1.38（最小バージョン1.12）
Goバージョン：go1.10.3
Gitコミット：d7080c1
構築：2019年2月20日水曜日02:25:33
OS / Arch：linux / amd64
実験的：誤り
[ root @ browser1〜 ]＃

dmesg：

[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

この問題はまだ発生しています:(修正方法に関する更新/アイデアはありませんか？

DebianStretchで起こっています。 これが発生したとき、Ansibleを介してJenkinsコンテナを更新しようとしていました。

この問題は、このコミットによって解決されました：
https://github.com/torvalds/linux/commit/ee60ad219f5c7c4fb2f047f88037770063ef785f
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