Ich sehe ein sehr ähnliches Problem für eth0. Ubuntu 12.04 auch.

Ich muss die Maschine aus- und wieder einschalten. Von /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

Hey, das passierte auch gerade bei mir.

Docker-Version:

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

Kernel-Log : http://pastebin.com/TubCy1tG

Systemdetails :
Ausführen von Ubuntu 14.04 LTS mit gepatchtem Kernel (3.14.3-rt4). Aber um es mit dem standardmäßigen Linux-3.13.0-27-generischen Kernel zu sehen. Das Komische ist jedoch, dass in diesem Fall alle meine Terminalfenster einfrieren, sodass ich höchstens ein paar Zeichen vorher eingeben kann. Das gleiche Schicksal ereilt auch alle neuen, die ich öffne - und am Ende muss ich meinen armen Laptop aus- und wieder einschalten, genau wie der gute Arzt oben. Fürs Protokoll führe ich Fischshell in urxvt oder xterm in xmonad aus. Ich habe nicht überprüft, ob es sich auf die einfache Bash auswirkt.

Dies könnte relevant sein:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065434#yui_3_10_3_1_1401948176063_2050

Kopieren einer ziemlich großen Datenmenge über das Netzwerk innerhalb eines Containers
und dann das Verlassen des Containers kann ein fehlendes Dekrement in der Per auslösen
CPU-Referenzzähler auf einem Netzwerkgerät.

Tatsächlich passierte dies bei mir unter anderem direkt nach apt-get ting ein Paket mit einer Menge Abhängigkeiten.

Das Upgrade von Ubuntu 12.04.3 auf 14.04 hat dies für mich ohne weitere Änderungen behoben.

Ich erlebe dies auf RHEL7, 3.10.0-123.4.2.el7.x86_64

Ich habe festgestellt, dass das gleiche mit meinen virtuellen VirtualBox-Netzwerkschnittstellen passiert, wenn ich 3.14-rt4 verwende. Es soll in Vanilla 3.13 oder so behoben werden.

@egasimus Das gleiche hier - ich habe Hunderte von MB Daten

Ich habe auf Debian-Kernel 3.14 aktualisiert und das Problem scheint verschwunden zu sein. Anscheinend existierte das Problem in einigen Kerneln < 3.5, wurde in 3.5 behoben, in 3.6 regressiert und in etwas 3.12-3.14 gepatcht. https://bugzilla.redhat.com/show_bug.cgi?id=880394

@spiffytech Haben Sie eine Idee, wo ich dies bezüglich des Echtzeit-Kernel-Aromas melden kann? Ich denke, sie veröffentlichen nur einen RT-Patch für jede andere Version und würden es wirklich hassen, wenn 3.16-rt mit diesem immer noch defekt herauskommt. :/

EDIT: Habe es bei

Ich bekomme dies auf Ubuntu 14.10 mit 3.18.1. Kernel-Log zeigt

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

Ich werde docker version/info senden, sobald das System nicht mehr eingefroren ist :)

Wir sehen dieses Problem auch. Ubuntu 14.04, 3.13.0-37-generisch

Auf dem Ubuntu 14.04-Server hat mein Team festgestellt, dass ein Downgrade von 3.13.0-40-generic auf 3.13.0-32-generic das Problem "behebt". Angesichts der Beobachtung von @sbward würde dies die Regression nach 3.13.0-32-generic und vor (oder einschließlich) 3.13.0-37-generic setzen.

Ich füge hinzu, dass wir in unserem Fall manchmal eine _negative_ Nutzungszählung sehen.

FWIW haben wir diesen Fehler beim Ausführen von lxc auf einem vertrauenswürdigen Kernel (3.13.0-40-generic #69-Ubuntu) festgestellt. Die Meldung erscheint in dmesg gefolgt von diesem Stacktrace:

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

Bin auf Ubuntu 14.04 und Debian Jessie mit Kernel 3.16.x darauf gestoßen.

Docker-Befehl:

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

Das scheint ein ziemlich schlimmes Problem zu sein...

@jbalonso auch mit 3.13.0-32-generic bekomme ich den Fehler nach nur wenigen erfolgreichen Durchläufen :sob:

@MrMMorris könnten Sie ein Reproduktionsskript mit öffentlich verfügbaren Bildern teilen?

Jeder, der diesen Fehler auf seinem System sieht, führt ein Paket des Linux-Kernels auf seiner Distribution aus, das viel zu alt ist und dem die Fixes für dieses spezielle Problem fehlen.

Wenn dieses Problem auftritt, stellen Sie sicher, dass Sie apt-get update && apt-get dist-upgrade -y ausführen und Ihr System neu starten. Wenn Sie auf Digital Ocean sind, müssen Sie auch die Kernel-Version auswählen, die gerade während des Updates installiert wurde, da sie nicht automatisch den neuesten Kernel verwenden (siehe https://digitalocean.uservoice.com/forums/136585-digitalocean /suggestions/2814988-give-option-to-use-the-droplet-s-own-bootloader).

CentOS/RHEL/Fedora/Scientific Linux-Benutzer müssen ihre Systeme mit yum update neuesten Stand halten und nach der Installation der Updates neu starten.

Wenn Sie dieses Problem melden, stellen Sie bitte sicher, dass Ihr System vollständig gepatcht und mit den neuesten stabilen Updates (keine manuell installierten Experimental-/Test-/Alpha-/Beta-/RC-Pakete) vom Lieferanten Ihrer Distribution auf dem neuesten Stand ist.

@unclejack

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

ubuntu 14.04 3.13.0-46-generisch

Bekomme den Fehler immer noch nach nur einem docker run

Ich kann bei Bedarf ein AMI zum Reproduzieren erstellen

@MrMMorris Vielen Dank, dass Sie bestätigt haben, dass es immer noch ein Problem mit dem neuesten

Alles, was ich tun kann, um zu helfen, lass es mich wissen! :Lächeln:

@MrMMorris Wenn Sie einen Reproduzierer bereitstellen können, ist ein Fehler für Ubuntu geöffnet und wird sehr geschätzt: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152

@rsampaio wenn ich heute Zeit habe, werde ich das auf jeden Fall für dich besorgen!

Dieses Problem tritt auch unter 3.16(.7) auf Debian 7 und Debian 8 auf: https://github.com/docker/docker/issues/9605#issuecomment -85025729. Ein Neustart des Servers ist derzeit die einzige Möglichkeit, dies zu beheben.

Dieses Problem wird bei RHEL 6.6 mit Kernel 2.6.32-504.8.1.el6.x86_64 beim Starten einiger Docker-Container (nicht aller Container) angezeigt.
_ kernel:unregister_netdevice : Warten darauf, dass lo frei wird. Nutzungsanzahl = -1_

Auch hier scheint ein Neustart des Servers derzeit die einzige Lösung zu sein

Sehen Sie dies auch auf CoreOS (647.0.0) mit Kernel 3.19.3.

Neustart ist auch die einzige Lösung, die ich gefunden habe.

Getestet Debian Jessie mit dem Kernel von sid (4.0.2) - das Problem bleibt.

Kennt jemand dieses Problem bei der Ausführung von Nicht-Ubuntu-Containern?

Jawohl. Debians.
19. Mai 2015 г. 19:01 ользователь "popsikle" [email protected]
написал:

Kennt jemand dieses Problem bei der Ausführung von Nicht-Ubuntu-Containern?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/5618#issuecomment -113556862.

Dies ist ein Kernelproblem, kein Bildproblem. Das Wechseln eines Bildes gegen ein anderes wird dieses Problem nicht verbessern oder verschlimmern.

Probleme mit Debian Jessie auf einem BeagleBone Black mit 4.1.2-Bone12-Kernel

Erfahrung nach dem Wechsel von 4.1.2 auf 4.2-rc2 (mit Git-Build von 1.8.0).
Das Löschen von /var/lib/docker/* löst das Problem nicht.
Ein Zurückschalten auf 4.1.2 behebt das Problem.

Außerdem hat VirtualBox das gleiche Problem und es gibt einen Patch für v5.0.0 (retro-portiert auf v4), der angeblich etwas im Kerneltreiberteil tut. Es lohnt sich, das Problem zu verstehen.

Dies ist der Fix in der VirtualBox: https://www.virtualbox.org/attachment/ticket/12264/diff_unregister_netdev
Sie modifizieren nicht wirklich den Kernel, sondern nur ihr Kernel-Modul.

Habe auch dieses Problem mit 4.2-rc2:

unregister_netdevice: warten, bis vethf1738d3 frei wird. Nutzungsanzahl = 1

Gerade 4.2-RC3 kompiliert, scheint wieder zu funktionieren

@nazar-pc Danke für die Info. Habe es gerade mit 4.1.3 getroffen, war ziemlich sauer
@techniq das gleiche hier, ziemlich schlimmer Kernel-Bug. Ich frage mich, ob wir melden sollten, dass es auf den Baum 4.1 zurückportiert wird.

Linux docker13 3.19.0-22-generic #22-Ubuntu SMP Di 16. Juni 17:15:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Kernel von Ubuntu 15.04, gleiches Problem

Ich habe es auch mit 4.2-rc3 gesehen. Es gibt keinen einzigen Fehler bezüglich Gerätelecks :) Ich kann auf jedem Kernel >=4.1 unter hoher Last reproduzieren.

Dieses Problem hatte ich auch gerade. Ubuntu 3.13.0-57-generic, bereitgestellt über Tutum. Leider füllt es kern.log und syslog und bringt die Maschine zum Absturz. Es passiert auf der Datenbankmaschine (dockerisierte Postgres), also bringt es das gesamte System zum Erliegen...

Ich schließe mich dem Chor von "me too" an und sehe dieses Problem auf einer Cloudstack-VM, auf der RancherOS (ein minimales Betriebssystem) 0.3.3 ausgeführt wird, während Docker-Images aus einem lokalen privaten Docker-Repository gezogen werden. Es passiert alle zehn Sekunden, ich bin mir nicht sicher, ob das etwas bedeutet oder nicht.

Habe auch dieses Problem mit 4.2-rc7

Gibt es Neuigkeiten dazu, welchen Kernel sollen wir verwenden? Es passiert auch mit einem vollständig aktuellen Kernel (3.19.0-26 auf Ubuntu 14.04)

Dieses Problem haben wir auch. Dies geschieht, nachdem wir userland-proxy=false konfiguriert haben. Wir verwenden einige Monitor-Skripte, die alle 1 Minute einen neuen Docker-Container erzeugen, um den Befehl Nagios-Plugins auszuführen. Was ich im Prozessbaum sehe, ist, dass er beim Befehl docker rm hängen bleibt und viele Fehler in der Datei kern.log sehen

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

Das sind unsere Systeminformationen

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

Update: Obwohl https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152 sagte, es sei bereits am 17.08.2015 behoben. Also habe ich es mit dem Kernel v3.19.8-ckt6-vivid versucht, der am 02.09.2015 erstellt wurde, oder sogar v4.2.1-unstable, der am 21.09.2015 erstellt wurde, und habe immer noch ein Problem.

Ich habe das Problem gerade erneut mit 3.19.0-28-generic , daher ist der neueste Ubuntu-Kernel nicht sicher

Yup, es scheint, als ob --userland-proxy=false mit älteren Kerneln jetzt nicht die beste Option ist :(

Nein. Ich habe --userland-proxy=false für alle 3.19, 4.0, 4.2 Kernelversionen ausprobiert und das Problem tritt immer noch auf.

Ich verwende den Userland-Proxy ohne iptables (--iptables=false) und sehe dies mindestens einmal pro Tag. Leider war die einzige Problemumgehung ein Watchdog, der den Server mit der SysRq-Technik hart zurücksetzte.

Meine Systeme führen einige Container aus, die schwere Standard- / Fehlerschreiber sind, da andere berichteten, dass dies den Fehler auslösen könnte.

``````
$ Docker-Info
Behälter: 15
Bilder: 148
Speichertreiber: aufs
Root-Verzeichnis: /var/lib/docker/aufs
Backup-Dateisystem: extfs
Dirs: 178
Dirperm1 unterstützt: true
Ausführungstreiber: native-0.2
Protokollierungstreiber: json-Datei
Kernel-Version: 3.19.0-26-generic
Betriebssystem: Ubuntu 14.04.3 LTS
CPUs: 12
Gesamtspeicher: 62,89 GiB
Name: * *
ID: 2 ALJ:YTUH : QCNX:FPEO :YBG4:ZTL4:2 EYK:AV7D :FN7C: IVNU:UWBL :YYZ5

$ Docker-Version
Client-Version: 1.7.0
Client-API-Version: 1.19
Go-Version (Client): go1.4.2
Git-Commit (Client): 0baf609
Betriebssystem/Arch (Client): linux/amd64
Serverversion: 1.7.0
Server-API-Version: 1.19
Go-Version (Server): go1.4.2
Git-Commit (Server): 0baf609
Betriebssystem/Arch (Server): linux/amd64```
``````

Leider bin ich im gleichen Fall, heute ist ein Produktionsserver dreimal aufgrund dieses Fehlers ausgefallen, und die einzige Möglichkeit, dies zu beheben, besteht darin, einige magische SysRq-Befehle zu verwenden.

stoßen

Ich sehe dies immer noch auf dem neuesten Debian-Jessie mit Kernel 4.2.0

Selbes Problem hier. Plötzlich fielen drei meiner aws-Server aus und die Protokolle riefen "unregister_netdevice: wait for lo to free. Usage count = 1"

Ubuntu: 14.04
Kernel-Version: 3.13.0-63-generic
Docker: 1.7.1

Syslog

Gibt es eine sichere Kernel-Version?

Problem tritt auch mit Kernel 4.2 von Ubuntu 15.10 auf

passiert in coreos:

Bilder: 1174
Speichertreiber: Overlay
Backup-Dateisystem: extfs
Ausführungstreiber: native-0.2
Protokollierungstreiber: json-Datei
Kernel-Version: 4.1.7-coreos
Betriebssystem: CoreOS 766.4.0

Der Kernel-Bug, den @killme2008 letztes Mal gesagt hat

Sie sollten es wahrscheinlich mit diesem Patch versuchen, der auf Ihrem Kernel angewendet wird http://www.spinics.net/lists/netdev/msg351337.html
Paket: Racebedingung in packet_bind

oder warte auf den Backport im -stable-Baum; es wird früher oder später kommen.

:+1: Tolle Neuigkeiten!

Hallo zusammen, gute Nachrichten!

Seit meinem letzten Kommentar hier (zum Zeitpunkt des Schreibens vor 17 Tagen) habe ich diese Fehler nicht mehr bekommen. Auf meinen Servern (ungefähr 30) liefen Ubuntu 14.04 mit einigen veralteten Paketen.

Nach einem kompletten System-Upgrade inklusive Docker-Engine (von 1.7.1 auf 1.8.3) + Kernel-Upgrade auf die neuste mögliche Version im Repo von Ubuntu laufen meine Server ohne Vorkommnisse.

:8 Ball:

Ist heute auch auf 3 unserer AWS-Instanzen passiert:

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

Ich habe das gleiche Problem mit Ubuntu 14.04, allen Paketen auf dem neuesten Stand und dem neuesten linux-generic-lts-vivid Kernel:

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

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

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

Ich hatte es auch mit dem neuesten linux-image-generic (3.13.0-67-generic).

Habe die gleichen Probleme hier auf rancherOS.

Passiert immer noch auf Fedora 22 (aktualisiert)....
Ich kann die Nachrichten loswerden, wenn ich Docker neu starte

systemctl docker neu starten
... die Meldung erscheint noch einmal ca. 3-4 mal und stoppt dann

Der gleiche Fehler tritt mir bei Coreos auf:

Coreos-Version:

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

 core@core-1-94 ~ $ Docker-Version
 Client-Version: 1.7.1
 Client-API-Version: 1.19
 Go-Version (Client): go1.4.2
 Git-Commit (Client): df2f73d-dirty
 Betriebssystem/Arch (Client): linux/amd64
 Serverversion: 1.7.1
 Server-API-Version: 1.19
 Go-Version (Server): go1.4.2
 Git-Commit (Server): df2f73d-dirty
 Betriebssystem/Arch (Server): linux/amd64

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

Systemprotokoll:

 07. Dez. 16:26:54 core-1-94 kernel: unregister_netdevice: wartet darauf, dass veth775ea53 frei wird. Nutzungsanzahl = 1
 07. Dez 16:26:54 core-1-94 kernel: unregister_netdevice: warte darauf, dass lo frei wird. Nutzungsanzahl = 2
 07. Dez. 16:26:55 core-1-94 sdnotify-proxy[1203]: I1207 08:26:55.930559 00001 vxlan.go:340] Nicht verpassen: 4e:5c:47:2f:9a:85, 10.244 .97.10
 07. Dez 16:26:59 core-1-94 dockerd[1269]: time="2015-12-07T16:26:59.448438648+08:00" level=info msg="GET /version"
 07. Dez. 16:27:01 core-1-94 sdnotify-proxy[1203]: I1207 08:27:01.050588 00001 vxlan.go:340] Ignorieren kein Miss: 5a:b1:f7:e9:7d:d0, 10.244 .34.8
 07. Dez 16:27:02 core-1-94 dockerd[1269]: time="2015-12-07T16:27:02.398020120+08:00" level=info msg="GET /version"
 07. Dez 16:27:02 core-1-94 dockerd[1269]: time="2015-12-07T16:27:02.398316249+08:00" level=info msg="GET /version"
 07. Dez 16:27:04 core-1-94 dockerd[1269]: time="2015-12-07T16:27:04.449317389+08:00" level=info msg="GET /version"
 07. Dez. 16:27:04 core-1-94 kernel: unregister_netdevice: wartet darauf, dass veth775ea53 frei wird. Nutzungsanzahl = 1
 07. Dez 16:27:04 core-1-94 kernel: unregister_netdevice: warte darauf, dass lo frei wird. Nutzungsanzahl = 2
 07. Dez. 16:27:06 core-1-94 sdnotify-proxy[1203]: I1207 08:27:06.106573 00001 vxlan.go:340] Ignorieren keinen Fehler: a6:38:ac:79:93:f5, 10.244 .47.24
 07. Dez 16:27:09 core-1-94 dockerd[1269]: time="2015-12-07T16:27:09.449944048+08:00" level=info msg="GET /version"
 07. Dez 16:27:11 core-1-94 sdnotify-proxy[1203]: I1207 08:27:11.162578 00001 vxlan.go:340] Ignorieren kein Miss: 0e:f0:6f:f4:69:57, 10.244 .71.24
 07. Dez. 16:27:12 core-1-94 dockerd[1269]: time="2015-12-07T16:27:12.502991197+08:00" level=info msg="GET /version"
 07. Dez 16:27:12 core-1-94 dockerd[1269]: time="2015-12-07T16:27:12.503411160+08:00" level=info msg="GET /version"
 07. Dez 16:27:14 core-1-94 dockerd[1269]: time="2015-12-07T16:27:14.450646841+08:00" level=info msg="GET /version"
 07. Dez. 16:27:14 core-1-94 kernel: unregister_netdevice: wartet darauf, dass veth775ea53 frei wird. Nutzungsanzahl = 1
 07. Dez 16:27:14 core-1-94 kernel: unregister_netdevice: warte darauf, dass lo frei wird. Nutzungsanzahl = 2
 07. Dez. 16:27:16 core-1-94 sdnotify-proxy[1203]: I1207 08:27:16.282556 00001 vxlan.go:340] Nicht verpassen: a6:62:77:31:ef:68, 10.244 .13.6
 07. Dez 16:27:19 core-1-94 dockerd[1269]: time="2015-12-07T16:27:19.451486277+08:00" level=info msg="GET /version"
 07. Dez 16:27:21 core-1-94 sdnotify-proxy[1203]: I1207 08:27:21.402559 00001 vxlan.go:340] Ignorieren kein Miss: 92:c4:66:52:cd:bb, 10.244 0,24,7
 07. Dez 16:27:22 core-1-94 dockerd[1269]: time="2015-12-07T16:27:22.575446889+08:00" level=info msg="GET /version"
 07. Dez 16:27:22 core-1-94 dockerd[1269]: time="2015-12-07T16:27:22.575838302+08:00" level=info msg="GET /version"
 07. Dez 16:27:24 core-1-94 dockerd[1269]: time="2015-12-07T16:27:24.452320364+08:00" level=info msg="GET /version"
 07. Dez. 16:27:24 core-1-94 kernel: unregister_netdevice: wartet darauf, dass veth775ea53 frei wird. Nutzungsanzahl = 1
 07. Dez 16:27:24 core-1-94 kernel: unregister_netdevice: warte darauf, dass lo frei wird. Nutzungsanzahl = 2
 07. Dez 16:27:26 core-1-94 sdnotify-proxy[1203]: I1207 08:27:26.394569 00001 vxlan.go:340] Ignorieren kein Miss: 6a:f7:bf:ec:03:50, 10.244 .87.8
 07. Dez 16:27:29 core-1-94 dockerd[1269]: time="2015-12-07T16:27:29.453171649+08:00" level=info msg="GET /version"
 07. Dez. 16:27:29 core-1-94 systemd[1]: Generieren von /run/coreos/motd wird gestartet...
 07. Dez. 16:27:29 core-1-94 systemd[1]: Gestartet Generieren /run/coreos/motd.
 07. Dez 16:27:32 core-1-94 dockerd[1269]: time="2015-12-07T16:27:32.671592437+08:00" level=info msg="GET /version"
 07. Dez. 16:27:32 core-1-94 dockerd[1269]: time="2015-12-07T16:27:32.671841436+08:00" level=info msg="GET /version"
 07. Dez 16:27:33 core-1-94 sdnotify-proxy[1203]: I1207 08:27:33.562534 00001 vxlan.go:340] Ignorieren kein Miss: 22:b4:62:d6:25:b9, 10.244 .68,8
 07. Dez 16:27:34 core-1-94 dockerd[1269]: time="2015-12-07T16:27:34.453953162+08:00" level=info msg="GET /version"
 07. Dez. 16:27:34 core-1-94 kernel: unregister_netdevice: wartet darauf, dass veth775ea53 frei wird. Nutzungsanzahl = 1
 07. Dez 16:27:35 core-1-94 kernel: unregister_netdevice: warte darauf, dass lo frei wird. Nutzungsanzahl = 2

Alles Gute zum Geburtstag, verdammtes Problem =)
6. Mai 2014

Das selbe hier. Nur Neustart. Neueste Docker-Version. Ubuntu 14.04.

@samvignoli dies wurde als Kernel-Problem identifiziert, also leider nicht etwas, das in Docker behoben werden kann

@thaJeztah Hast du einen Link zum Bugtracker für das
Oder vielleicht ein Hinweis darauf, welche Kernel betroffen sind?

Wir möchten, dass dies in unserer Umgebung gelöst wird.

@Rucknar Entschuldigung, tue ich nicht (vielleicht gibt es einen in dieser Diskussion, ich habe nicht alle Kommentare zurückgelesen)

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

@Rucknar, wenn Sie ein wenig nach oben scrollen, sehen Sie den Link zum Patch http://www.spinics.net/lists/netdev/msg351337.html. Es ist jetzt in Linux-Master, ich denke, es wird auf Linux 4.4 gehen, vielleicht hat es jemand bereits auf frühere Versionen zurückportiert, aber nicht sicher.

Vielen Dank an alle, werde prüfen, was beim Upgrade erforderlich ist.

FWIW Ich habe den letzten hier erwähnten Patch auf Ubuntu 3.19 zurückportiert und auch auf dem 4.2-Kernel getestet, beides erfolglos. Das Problem ist zu diesem Zeitpunkt auch auf 4.4-rc3 net-next branch noch vorhanden.

@rsampaio Wie hast du das getestet? Ich kann diesen Fehler nicht zuverlässig mit Docker auf jedem Kernel auslösen. Es passiert einfach manchmal.

@fxposter wir können das Problem auch außerhalb der Produktion nicht reproduzieren, daher musste ich einige Instanzen mit dem gepatchten Kernel in der Produktion booten.

Manchmal beheben wir es mit einer sehr ungewöhnlichen Ressource: Wir verschieben die Containerverzeichnisse von /var/lib/docker/aufs/mnt

Damit ... VIELLEICHT können wir den Docker-Neustart starten und die Verzeichnisse zurück verschieben.

Ansonsten... nur Neustart.

@rsampaio redest du jetzt von der Heroku-Produktion? Wie können Sie dieses Problem vermeiden, da Ihr gesamtes Geschäft um Container/etc herum aufgebaut ist?

@rsampaio verwenden Sie --userland-proxy=false oder nur eine große Anzahl erstellter Container? Ich kann es ziemlich einfach mit --userland-proxy=false reproduzieren und mit etwas Last ohne :)

@LK4D4 Ich glaube, es ist nur eine große Menge erstellter / zerstörter Container, insbesondere Container, die viel ausgehenden Datenverkehr ausführen. Wir verwenden auch LXC anstelle von Docker, aber der Fehler ist genau derselbe wie der hier beschriebene. Ich kann versuchen, ihn zu reproduzieren Wenn Sie Ihre Methode verwenden, wenn sie leicht zu beschreiben ist und/oder keine Produktionsauslastung erfordert, besteht die Idee darin, einen Crashdump zu erstellen und _vielleicht_ weitere Hinweise zu finden, was genau diesen Fehler auslöst.

@rsampaio Ich kann bei längerer Nutzung von https://github.com/crosbymichael/docker-stress reproduzieren

Gab es irgendwelche Updates / Vorschläge für die Behebung dieses Problems?

@joshrendek es ist ein Kernel-Bug. Sieht so aus, als ob selbst der neu veröffentlichte Kernel 4.4 das nicht behebt, also gibt es irgendwo noch mindestens eine weitere Race Condition :)

Kernel-Fehler

=)

@samvignoli könnten Sie Ihre Kommentare konstruktiv halten? Fühlen Sie sich frei, eine PR zu öffnen, wenn Sie Möglichkeiten haben, dieses Problem zu beheben.

Wurde dieser Fehler bereits im Upstream (Kernel-Mailingliste) gemeldet?

Sicher war. Der erste Kommentar verweist auch auf diesen Fehler: https://bugzilla.kernel.org/show_bug.cgi?id=81211

Seit 2014 geöffnet. Keine Kommentare von jemandem, der daran arbeitet, außer zu sagen, dass es höchstwahrscheinlich eine Anwendung ist, die es falsch verwendet.

Danke für den Link, Justin! Ich werde Linus trollen =)

mit freundlichen Grüßen. =* :herz:

@samvignoli bitte mach das nicht, es hilft niemandem.
Kann das jemand in einem kleinen VM-Image reproduzieren?
Vielleicht kann ich mir mit gdb und viel kprintf die Hände schmutzig machen.

Fehler noch offen.

Betriebssystem: CentOS 7.2
Kernel: 4.4.2 elrepo-Kernel-ml
Docker: 1.10.2
fs: overlayfs mit xfs

Protokoll:

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

diese Protokollanzeige beim Ausführen von sameersbn/docker-gitlab docker image:

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

Ich habe vielleicht nur Glück - aber nach dem Anwenden dieser sysctl-Einstellungen ist die Häufigkeit dieses Ereignisses weit zurückgegangen.

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 was ist die Motivation hinter diesen Einstellungen?

@kmike Dies war, um einige andere Conntrack-Probleme (IP-Tabellen werden voll) zu beheben, die wir hatten - es scheint jedoch als Nebeneffekt etwas in Bezug auf mein ursprüngliches Problem getan zu haben

Könnten Sie das Vorher/Nachher zeigen, damit wir sehen können, was sich tatsächlich geändert hat? Sind Sie bereit, diese Einstellungen binär zu durchsuchen und zu sehen, ob es einen kleineren Satz gibt?

Ich verwende CoreOS Stable (899.13.0) in einer Compute Engine-VM. Dieser Fehler tritt jedes Mal auf, wenn ich den Server mit dem folgenden Flag auf 0 (Standardeinstellung) starte. Ich habe mehrmals hin und her getestet und mit deaktiviertem IPv6 kann ich alle Container im Knoten ohne Fehler starten:

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

Ich verwende den gcloud-Container, um von GCR herunterzuladen, also ist das Problem möglicherweise IPv6 + Herunterladen von MBs an Bildern + Schließen der Container schnell.

Docker-Version als Referenz:

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

Ich habe auch die vorherigen sysctl-Flags in dieser Ausgabe getestet; aber einige haben diesen Wert bereits und der Rest schien nichts im Zusammenhang mit diesem Fehler zu ändern:

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

Ich sehe das Problem immer noch, wenn ich net.ipv6.conf.all.disable_ipv6=1 setze.

Das Docker-Stress-Tool kann das Problem sehr einfach erzeugen.
https://github.com/crosbymichael/docker-stress

Dies ist die Binärdatei, die ich für das obige Tool erstellt habe.
https://storage.googleapis.com/donny/main
https://storage.googleapis.com/donny/stress.json

Sobald wir das Protokoll "unregister_netdevice: wait for veth6c3b8b0 to free. Usage count" sehen, hängt Docker. Ich denke, dies ist ein Kernel-Problem, das von Docker ausgelöst wird. Dies geschieht nur, wenn der Docker userland-proxy ausgeschaltet ist (--userland-proxy=false).

Ich habe dies mit und ohne aktiviertem Userland-Proxy passieren lassen, also würde ich nicht nur sagen, wenn er ausgeschaltet ist.

Es könnte sein, dass es die Situation verschlimmert; Ich weiß, dass wir einmal versucht haben, --userland-proxy=false zum Standard zu machen, dies jedoch zurückgesetzt, weil es Nebenwirkungen gab https://github.com/docker/docker/issues/14856

Ich habe den Fehler seit gestern auch einmal gesehen, das Deaktivieren von IPv6 ist kein Fix; aber ohne das Flag kann ich nicht einmal alle Container des Servers starten, ohne Docker zu zerstören.

Läuft auf CoreOS 1010.1.0 mit Kubernetes 1.2.2 und Docker 1.10.3

Kubernetes hat kubelet (auf Mobilgeräten, kann es nicht nachschlagen) ein Flag hinzugefügt für
Haarnadelmodus. Ändere es in "Promiscuous Bridge" oder was auch immer gültig ist
Wert ist. Dieser Fehler ist seit dieser Änderung nicht mehr aufgetreten.

@bprashanh

Bitte bestätigen oder widerlegen?
Am 13. April 2016 12:43 Uhr, "Aaron Crickenberger" [email protected]
schrieb:

Läuft auf CoreOS 1010.1.0 mit Kubernetes 1.2.2 und Docker
1.10.3

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/5618#issuecomment -209617342

Um dies auf AWS mit Linux 4.4.5-15.26.amzn1.x86_64 mit Docker-Version 1.9.1 zu erhalten, erstellen Sie a34a1d5/1.9.1.

Ruby 2.3.0 mit Alpine-Image läuft im Container und verursacht dies

Kernel:[58551.548114] unregister_netdevice: Warten darauf, dass lo frei wird. Nutzungsanzahl = 1

Irgendeine Lösung dafür?

habe das zum ersten Mal auf 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

Ein paar Neustarts haben es behoben.

@MrMMorris Behoben, da Sie sicher sind, dass das Problem

Es ist ziemlich klar, dass dies ein Rennen im Kernel ist, bei dem ein Refcount verloren geht
irgendwo. Dies ist ein WIRKLICH schwer zu verfolgender Fehler, aber soweit wir das beurteilen können
existiert immernoch.

Am Montag, 2. Mai 2016 um 22:52 Uhr, Sune Keller [email protected]
schrieb:

@MrMMorris https://github.com/MrMMorris Behoben, da Sie sicher sind, dass
das Problem ist für immer verschwunden, oder du erlebst es nicht wieder
Jetzt? Könnte eine Rennbedingung sein...

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/5618#issuecomment -216444133

Jep. Ich habe CoreOS 1032.0.0 mit Kernel 4.5 ausprobiert und das Problem besteht immer noch.

Ich bin gestern wieder auf CoreOS 1010.1.0 mit Kernel 4.5.0 gestoßen, nachdem mehrere Container in schneller Folge gestartet und beendet wurden.

Ich habe diesen Fehler.

Docker-Version: 1.9.1
Kernel-Version: 4.4.8-20.46.amzn1.x86_64
Betriebssystem: Amazon Linux AMI 2016.03

@sirlatrom nicht behoben. Wiedersehen 😭 Mehrere Neustarts erforderlich, um das Problem zu beheben.

Derzeit läuft 3.19.0-18-generic. Werde versuchen, auf die neueste Version zu aktualisieren

Ich auch! :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei : :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: : schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei : :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: : schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei : :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: : schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei : :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei: :schrei:

@samvignoli Ihre Kommentare sind nicht konstruktiv. Bitte hör auf zu posten.

Sorry, hab die Daumen hoch Funktion vergessen.

Reproduziert in Fedora Server 23 - 4.2.5-300.fc23.x86_64. Der Docker-Dienst kann nicht neu gestartet werden - starten Sie nur den Knoten neu.

Gleiches Problem beim Fedora 24 Kernel: 4.5.2-302.fc24.x86_64. hat keine Hänger verursacht, aber eine Log-Datei spammt.

@hapylestat Kannst du systemctl restart docker versuchen? Dies hat dazu geführt, dass alles für mich hängen blieb.

Vielen Dank

Dies passiert bei meinen (CoreOS, EC2)-Rechnern ziemlich häufig. Falls es überhaupt hilfreich ist, hier sind alle Protokolle, die sich auf das festsitzende Veth-Gerät in einem Fall dieses Fehlers beziehen.

$ 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

Dies scheint zu passieren, wenn ich viele Container gleichzeitig entferne (in meinem Fall, wenn ich k8s-Pods en-masse lösche).

Für diejenigen, die sagen, dass ein Neustart das Problem behoben hat - haben Sie die Maschinen neu gestartet oder gestoppt / gestartet? Auf physischen Maschinen musste ich einen Remote-Power-Reset verwenden, um die Maschine wieder hochzufahren.

@joshrendek , ich musste den Kaltstart von iLO verwenden (dh einen physischen Power-Cycle).

@joshrendek Ich habe jetzt ein Skript, das darauf reboot -f tut, wenn es passiert 😢.

Könnte das Problem gefunden haben (oder einfach nur Glück gehabt haben). Ich habe das Docker-Graph-Verzeichnis von einer XFS-partitionierten Festplatte auf eine EXT4-partitionierte Festplatte verschoben und kann das Problem nicht reproduzieren (sowie eine Menge anderer XFS-Fehler, die ich bekam). Ich erinnere mich , dass

Ich habe versucht zu provozieren, indem ich build , run , stop , delete in einer Endlosschleife für verschiedene Bilder ausgeführt habe, wobei pro Zyklus etwa 10 Container erstellt wurden die letzten Stunden.

@joedborg Welchen Grafiktreiber verwendest du? Gerätezuordnung? Überlagerung?

@thaJeztah Guter Punkt, das hätte ich erwähnen sollen. Ich verwende Overlay-Treiber mit (jetzt) ​​EXT4-Backing FS.

Ich habe früher den Devicemapper verwendet (weil ich Fedora Server verwende), aber ich hatte jede Menge Schmerzen (wie ich glaube, viele), insbesondere bei Lecks, bei denen der Mapper nach dem Löschen eines Containers keinen Platz mehr in den Pool zurückgibt.

Wenn es hilft, bin ich auf Docker 1.11.1 und Kernel 4.2.5-300.fc23.x86_64.

@joedborg interessant, weil in den RHEL-Dokumenten erwähnt wurde, dass nur EXT4 unter RHEL/CentOS 7.1 und nur XFS unter RHEL/CentOS 7.2 unterstützt wird. Ich hätte erwartet, dass XFS dann auf neueren Versionen funktioniert

@thaJeztah ah das ist seltsam. Ich versuche, an andere Dinge zu denken, die es sein könnten. Ich habe noch einmal von oben gelesen und es scheint, dass einige Leute die gleiche Konfiguration ausführen. Der einzige andere Unterschied besteht darin, dass die XFS-Festplatte eine Spindel ist und die EXT4 eine SSD. Ich werde in der Zwischenzeit die Einweichtests fortsetzen. Ich habe auch prod auf das gleiche Setup umgestellt, so dass wir in Kürze eine Antwort haben werden. Allerdings war es vorher bei fast jedem stop so, also ist es sicherlich besser.

@joedborg na ja, das sind in der Tat nützliche Informationen

gleicher Fehler hier, von Kernel 4.2 bis 4.5, gleiche Docker-Version.

Übrigens, ich betreibe mehrere Virtualbox-Maschinen gleichzeitig auf derselben Box.

$ 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

Ich habe dieses Problem mit dem overlay Grafiktreiber, wobei sich das Verzeichnis auf einem ext4 FS befindet. Also denke ich nicht, dass xfs das Problem ist 😢

@obeattie Ja, die Leute scheinen es auch auf devicemapper zu bekommen. Holz anfassen, das Problem hatte ich seit dem Wechsel nicht mehr. Wie bereits erwähnt, habe ich auch die physische Festplatte getauscht. Das wird interessant!

Dieses Problem korreliert in keiner Weise mit dem Dateisystem. Ich habe dieses Problem mit zfs, overlayfs, devicemapper, btrfs und aufs gesehen. Auch mit oder ohne Wechsel. Es ist nicht einmal auf Docker beschränkt, ich habe den gleichen Fehler auch mit lxc gehabt. Die einzige Problemumgehung, die ich derzeit sehe, besteht darin, den Container nicht gleichzeitig zu stoppen.

Wenn es hilft, erhalte ich dieselbe Fehlermeldung auf der neuesten ec2-Instance, die von AWS AMI unterstützt wird. Docker-Version zeigt-

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

Einfach an Bord springen. Ich sehe das gleiche Verhalten bei der neuesten Amazon ec2-Instance. Nach einiger Zeit kippt der Behälter einfach um und reagiert nicht mehr.

$ Docker-Info
Behälter: 2
Bilder: 31
Serverversion: 1.9.1
Speichertreiber: devicemapper
Poolname: docker-202:1-263705-pool
Pool-Blockgröße: 65,54 kB
Basisgerätegröße: 107,4 GB
Backup-Dateisystem:
Datendatei: /dev/loop0
Metadatendatei: /dev/loop1
Verwendeter Datenspeicher: 1.199 GB
Datenspeicher insgesamt: 107,4 GB
Verfügbarer Datenspeicher: 5.754 GB
Verwendeter Metadaten-Speicherplatz: 2,335 MB
Metadatenspeicher insgesamt: 2.147 GB
Verfügbarer Metadatenspeicher: 2.145 GB
Unterstützte Udev-Synchronisierung: wahr
Deferred Removal aktiviert: false
Verzögerte Löschung aktiviert: false
Anzahl verzögerter gelöschter Geräte: 0
Datenschleifendatei: /var/lib/docker/devicemapper/devicemapper/data
Metadaten-Schleifendatei: /var/lib/docker/devicemapper/devicemapper/metadata
Bibliotheksversion: 1.02.93-RHEL7 (2015-01-28)
Ausführungstreiber: native-0.2
Protokollierungstreiber: json-Datei
Kernel-Version: 4.4.10-22.54.amzn1.x86_64
Betriebssystem: Amazon Linux AMI 2016.03
CPUs: 1
Gesamtspeicher: 995,4 MiB
Name: [redigiert]
ID: OB7A:Q6RX: ZRMK:4R5H : ZUQY:BBNK : BJNN:OWKS :FNU4:7NI2: AKRT:5SEP

$ Docker-Version
Klient:
Version: 1.9.1
API-Version: 1.21
Go-Version: go1.4.2
Git-Commit: a34a1d5/1.9.1
Gebaut:
Betriebssystem/Arch: linux/amd64

Server:
Version: 1.9.1
API-Version: 1.21
Go-Version: go1.4.2
Git-Commit: a34a1d5/1.9.1
Gebaut:
Betriebssystem/Arch: linux/amd64

Wie in den obigen Kommentaren, läuft auch auf EC2 zufällig über Elastic Beanstalk mit 64bit Amazon Linux 2016.03 v2.1.0 running Docker 1.9.1

Etwas anekdotisch zu diesem Zeitpunkt, aber ich habe kürzlich versucht, testweise auf etwa 18 Servern ein Upgrade von Kernel 4.2.0 auf 4.5.5 durchzuführen, und dieses Problem wurde erheblich schlimmer (von mehreren Tagen auf nicht mehr als 4 Stunden zwischen den Problemen).

Das war auf Debian 8

Genau das gleiche Setup wie @jonpaul und @g0ddard

Wir suchen nach Möglichkeiten, diesen Fehler zu beheben.
Die erste Sache (die funktionieren kann oder auch nicht, es ist riskant) ist, die API in Fällen verfügbar zu halten, in denen dies auftritt: #23178

Hallo. Ich bin auch von diesem Fehler gebissen worden...

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

Ich verwende Kubernetes 1.2.4 auf CoreOS Beta, Flannel und laufe auf Azure. Gibt es eine Möglichkeit, dieses Problem zu beheben? Der Kernel-Bug-Thread scheint tot zu sein. Einige Leute berichten, dass das Deaktivieren von IPv6 im Kernel, die Verwendung von --userland-proxy=true oder die Verwendung von aufs anstelle von Overlay-Speicher helfen, während andere dies nicht tun ... Es ist ein bisschen verwirrend.

Wie @justin8 habe ich dies auch bemerkt, nachdem ich mein Fedora 23-System auf Kernel 4.5.5 aktualisiert hatte; das Problem bleibt mit Kernel 4.5.6.

Wir sind auf diesen Fehler gestoßen, als der Container sein Speicherlimit erreichte. Unsicher, ob es damit zusammenhängt oder nicht.

gleiches Problem hier

# 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
Dasselbe Problem

Ich habe einen "Einzeiler", der dieses Problem für mich auf einem EC2 (m4.large) mit CoreOS 1068.3.0 mit dem 4.6.3-Kernel (also sehr aktuell) reproduzieren wird. Für mich dauert es ungefähr 300 Iterationen, aber YMMV.

Linux ip-172-31-58-11.ec2.internal 4.6.3-coreos #2 SMP Sa 25. Juni 00:59:14 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2676 v3 @ 2,40GHz GenuineIntel GNU/Linux
CoreOS-Beta (1068.3.0)
Docker-Version 1.10.3, Build 3cd164c

Ein paar hundert Wiederholungen der Schleife hier werden schließlich dockerd hängen und der Kernel gibt Fehlermeldungen aus wie

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

Die Reproduktionsschleife ist

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

BEARBEITUNG

• Ich konnte damit nur reproduzieren, wenn userland-proxy=false
• Ich konnte NICHT mit VirtualBox reproduzieren (bisher nur ec2), also hängt es vielleicht auch mit dem Hypervisor zusammen

Das obige Skript von

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

Dieses Problem tritt bei meinem Kubernetes-Cluster ziemlich häufig auf, aber ich kann es mit den Stressern oder dem One -Liner von @btalbot nicht zuverlässig reproduzieren. Ich habe versucht, es auf zwei Azure-VMs mit CoreOS 1068.3.0 auszuführen.

Die erste VM war eine Standard_D1_v2 (3,5 GB Ram, 1 Kern) - das Skript hat > ​​3000 Iterationen gemacht.
Zweite VM war eine Standard_DS15_v2 (140GB Ram, 20 Kerne) - das Skript hat >7600 Iterationen gemacht.

Ich habe meinen vorherigen Kommentar (https://github.com/docker/docker/issues/5618#issuecomment-229545933) dahingehend aktualisiert, dass ich dies nur reproduzieren kann, wenn userland-proxy=false.

Es reproduziert für mich auf EC2 t2.micro (Single Core) VMs sowie m4.large (Multi Core) beide mit HVM. Ich habe noch nicht gesehen, dass es mit VirtualBox auf meinem Laptop passiert ist, unabhängig von der Einstellung von userland-proxy.

Wir sind auf diesen Fehler gestoßen, als wir Flannel mit aktiviertem Hairpin-veth im Kubernetes-Cluster verwendet haben (unter Verwendung von iptables-Proxy). Dieser Fehler trat nur auf, wenn wir zu viele Container ausführen und stoppen. Wir wechseln zur Verwendung des cbr0-Bridge-Netzwerks und des Promiscuous-Bridge-Hairpin-Modus und sehen es nie wieder.
Tatsächlich ist es einfach, diesen Fehler zu reproduzieren, wenn Sie Hairpin-veth verwenden, starten Sie diesen Job einfach mit 100 Containern mit Kubernetes.

Am 01.07.2016 08:01 schrieb manoj0077:

@btalbot https://github.com/btalbot also mit 1.12 können wir neu starten
dockerd, ohne laufende Container zu beeinträchtigen. Also würde Dockerd neu starten
Hilfe hier in diesem Fall?

AFAICT, Event mit 1.12, Docker-Container-Prozesse sind noch Kinder
des Docker-Daemons.

@sercand wie hast du den Promiscuous-Bridge-Haarnadelmodus eingestellt? Ich kann keine Dokumentation von Docker dazu sehen, oder vielleicht verwenden sie einen anderen Namen

Gibt es ein offizielles Wort von Docker 🐳, wann dies betrachtet werden könnte? Dies ist das am zweithäufigsten kommentierte offene Thema ; ist sehr schwerwiegend (erfordert einen Neustart des Hosts); ist reproduzierbar; und ich sehe keinen wirklichen Fortschritt, um die Ursache zu finden oder zu beheben 😞.

Dies scheint höchstwahrscheinlich ein Kernel-Problem zu sein, aber das Ticket auf Bugzilla stagniert seit Monaten. Wäre es hilfreich, unsere Testfälle dort zu posten?

@justin8 Ich denke, das sind Kubelet-Flags: --configure-cbr0 und --hairpin-mode

@sercand Ich verwende auch Flanell. Gibt es einen Nachteil bei der Verwendung von --hairpin-mode=promiscuous-bridge ?

@obeattie Ich stimme zu. :(

FTR Ich habe es geschafft, das Problem mit dem Stresser -Job von @sercand auf einem von mir eingerichteten Kubernetes-

@sercand Könnten Sie bitte die Schritte beschreiben, um mit der Verwendung von promiscuous-bridge zu beginnen? Ich habe das Flag --configure-cbr0=true zum Kubelet des Knotens hinzugefügt, aber es beschwert sich:
ConfigureCBR0 requested, but PodCIDR not set. Will not configure CBR0 right now . Ich dachte, dieses PodCIDR sollte vom Master kommen? Vielen Dank.

BEARBEITEN: Es scheint, dass ich --allocate-node-cidrs=true --cluster-cidr=10.2.0.0/16 zur Controller-Manager-Konfiguration hinzufügen musste, aber da ich keinen Cloud-Anbieter (Azure) habe, funktionieren die Routen wahrscheinlich nicht.

@justin8 Ich bin diesem Dokument gefolgt.
@edevil aus der Dokumentation hairpin-mode ist für "Dies ermöglicht es Endpunkten eines Dienstes, Lasten auf sich selbst auszugleichen, wenn sie versuchen sollten, auf ihren eigenen Dienst zuzugreifen". Übrigens läuft mein Cluster in Azure und es war keine leichte Aufgabe.

@sercand Laut dem Dokument sollten wir, wenn wir --allocate-node-cidrs=true auf dem Controller-Manager verwenden, einen Cloud-Anbieter verwenden, damit er die Routen einrichtet. Da es für Azure keinen Kubernetes-Cloudanbieter gibt, hatten Sie da keine Probleme? Richten Sie die Routen manuell ein? Vielen Dank.

@edevil Ich verwende Terraform, um Routen zu erstellen. Sie finden es in diesem Repo . Ich habe diese Konfiguration schnell erstellt und nur einmal getestet. Ich hoffe, es reicht aus, die grundlegende Logik dahinter zu erläutern.

@morvans @btalbot hast du es mit 1.12 versuchen können ...?

Ich kann bestätigen, dass ich das Problem nicht mehr reproduzieren kann, wenn ich mich von Hairpin-veth wegbewege und die cbr0-Brücke verwende.

Nur für den Fall: Hat jemand dieses Problem mit dem Bare Metal? Wir haben dies beim Testen von Rancher-Clustern in unserem VMWare-Labor gesehen, aber noch nie bei einer echten Bare-Metal-Bereitstellung.

Ja, dieses Problem tritt auf Bare Metal für jeden Kernel >= 4.3 auf. Habe dies auf vielen verschiedenen Maschinen und Hardwarekonfigurationen gesehen. Die einzige Lösung für uns war die Verwendung von Kernel 4.2.

Es passiert definitiv immer noch auf 4.2, aber es ist eine Größenordnung häufiger bei neueren Versionen. Ich habe jede Hauptversion getestet, um zu sehen, ob sie besser ist, und noch nichts

Passiert auch auf CoreOS alpha 1097.0.0.

Kernel: 4.6.3
Docker: 1.11.2

Ich habe das gleiche Problem.

Docker: 1.11.2
Kernel: 4.4.8-boot2docker.

Host: Docker-Maschine mit VMWare Fusion-Treiber unter OS X.

Irgendwelche Lösungsvorschläge?

Wäre wirklich hilfreich, wenn diejenigen von Ihnen, die das Problem zuverlässig in einer Umgebung reproduzieren können, in der ein Crashdump möglich ist (auch bekannt als EC2), diese Crashdump-Datei tatsächlich teilen könnten. Weitere Informationen zum Aktivieren von Kdump in Ubuntu Trusty finden Sie hier und Dies sind die Absturzoptionen, die Sie aktivieren müssen, wenn kdump bereit ist, einen Crashdump zu erstellen:

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

Der Crashdump kann Kernel-Entwicklern wirklich helfen, mehr über die Ursache des Referenzlecks herauszufinden, aber bedenken Sie, dass ein Crashdump auch einen Speicherabzug Ihres Hosts enthält und möglicherweise sinnvolle Informationen enthält.

...vernünftige Informationen.

:Ö

Ich stoße auf das gleiche Problem.

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

Gleicher Fehler:

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

Docker version: 1.10.3

Ist gerade direkt auf dem Terminalbildschirm passiert:

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

System ist

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

Gleiches Problem

Os: Amazon Linux AMI release 2016.03
Docker: 1.9.1

Hier auch:

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

Ich sehe das gleiche Problem bei 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

(auf allen meinen pty + pieper, wenn dies passiert)
"einfach" Debian Jessie + Backports:

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

Hallo,

Wenn ich versuche, das Problem über eine kontrollierte Umgebung zu replizieren, indem ich neue Bilder erstelle, kann ich es nicht reproduzieren.

Das Problem wurde auf einem der Server angesprochen, auf denen Docker 1.9.1 ausgeführt wird

 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

Ich esse gleichzeitig 17753 Container im gleichzeitigen Modus und erhöhe den Datenverkehr zum Internet, ohne die veth * -Schnittstelle zu verlieren. Kann jemand Anweisungen einfügen, um das Problem konsistent zu reproduzieren?

@pegerto Sollte ziemlich einfach auszulösen sein, wenn Sie --userland-proxy=false und gleichzeitig eine Reihe von Containern starten. Ich mache dies mit https://github.com/crosbymichael/docker-stress

Danke @cpuguy83

Konfigurieren des Daemons mit --userland-proxy=false Ich kann das Problem leicht reproduzieren, danke, wir können sehen, dass dieses Problem Daemons betrifft, die diese Konfiguration nicht ausführen.

Ich sehe einen Kernel-Dump am netfilter-Hook, der durch die netns-Segregation bei >=4.3 eingeführt wurde.

Vielen Dank

Sehe dieses Problem auch. CoreOS 1068.8.0, Docker 1.10.3, Kernel 4.6.3. Ich habe einige der Systemprotokolle gezogen, wenn jemand interessiert ist.

Habe gerade mehrere...
unregistered_netdevice: waiting for lo to become free. Usage count = 1
... auf 2 VMs und auf meinem Bare-Metal-Laptop, alle mit Ubuntu 16.04 und den neuesten Kerneln (4.4.0-3[456]).

Das Ergebnis ist, dass alles hängt und einen harten Neustart erfordert.
Ich habe dies vor letzter Woche noch nicht erlebt und ich denke, eine der VMs war auf 1.11.3, während die anderen alle auf 1.12.0 waren.

@RRAlex Dies ist nicht spezifisch für eine Docker-Version.
Wenn Sie --userland-proxy=false für die Daemon-Optionen verwenden ... ODER (soweit ich das verstehe) Sie Kubernetes verwenden, werden Sie wahrscheinlich auf dieses Problem stoßen.

Der Grund dafür ist, dass die Option --userland-proxy=false Hairpin-NAT auf der Bridge-Schnittstelle aktiviert ... Dies ist etwas, das Kubernetes auch festlegt, wenn es das Netzwerk für seine Container einrichtet.

Dies wird auf einem BYO-Knoten mit Docker Cloud (und Docker Cloud Agent) angezeigt.

Habe dies heute einmal (von etwa 25 Versuchen) auf aktuellen Amazon ECS-AMIs gesehen, auf denen Vanilla debian:jessie mit einem Befehl ausgeführt wurde, der apt-get aktualisiert, pbzip2 installiert und dann ausführt (einfacher Multithread-CPU-Test).

@edevil
Die meisten von Ihnen hier beschreiben, dass Sie auf diese Situation stoßen, wenn Sie Docker zum Starten/Stoppen von Containern verwenden, aber ich habe genau die gleiche Situation ohne Docker unter Debian:

• Debian "Jessie" (=Debian Version 8.5), auf Baremetal (keine VM, keine Cloud, sondern reine Hardware)
• Kernel 3.16.0-4-amd64
• habe 4 LXC-Container gestartet
• schließe einen LXC-Container mit "lxc-stop -n $containerName"
• Wenn dieser Befehl abgeschlossen ist, sind der Kernel oder die Schnittstellen wahrscheinlich noch nicht vollständig 'aufgeräumt', denn wenn ich unmittelbar nach dem vorherigen "lxc-stop" einen neuen "lxc-stop" starte, habe ich das Kernel-Problem

Keine Wiederherstellungsmöglichkeit außer einem Hard-Reset der Maschine.

Konzentrieren Sie sich daher bei Ihren Untersuchungen, um dieses Problem zu lokalisieren / zu lösen, nicht allein auf Docker. Es ist offensichtlich ein allgemeines Problem beim schnellen Stoppen/Starten von Containern, sei es durch Docker oder durch einfache "lxc" -Befehle.

Ich würde denken, dass dies ein Problem des Linux-Kernels ist.

Ich bin auf dieses Problem gestoßen, als ich 3 chroot (eigentlich pbuilder) mit sehr hoher Last ausgeführt habe.
Meine Hardware ist Loongson 3A (eine mips64el-Maschine mit 3.16-Kernel).

Als ich versuche, hinein zu ssh, bin ich auf dieses Problem gestoßen.

Dieses Problem kann also nicht nur über Docker oder lxc, sondern sogar über chroot liegen.

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

Rohmetall.

Wir hatten das Problem kürzlich auf Bare Metal (dediziert auf ovh) mit Kernel 4.6.x und Docker 1.11.2.
Nachdem wir die Kommentare hier gelesen und mehrere Problemumgehungen ausprobiert hatten, haben wir unseren Kernel auf die neueste Version des 3.14-Zweigs (3.14.74) herabgestuft und Docker auf 1.12.0 aktualisiert, um https://github.com/docker/libnetwork/issues/1189 . zu vermeiden und jetzt scheint alles in ordnung zu sein.

Ich hoffe, das kann helfen.

Alles, ich denke, Sie müssen keine Nachrichten mehr über Docker oder chroot posten, es dreht sich alles um den Linux-Kernel.
Kann also bitte jemand aufstehen, der den Kernel in irgendeiner Weise debuggen kann, in den Teilen, in denen virtuelle Netzwerkschnittstellen für Container deaktiviert werden? Möglicherweise treten einige Race-Conditions auf, wenn ein vorheriger Stopp eines Containers seine virtuelle Schnittstelle noch nicht vollständig deaktiviert/bereinigt hat, bevor ein neuer Stopp eines Containers angefordert wird.

@rdelangh Ich glaube nicht, dass dieses Problem unbedingt mit dem Kernel zusammenhängt.

Auf Fedora 24 kann ich das Problem mit Docker 1.10.3 aus den Fedora-Repos nicht reproduzieren, nur mit Docker 1.12.1 aus den Docker-eigenen Repos.

Beide Tests wurden mit Kernel 4.6.7-300.fc24.x86_64 durchgeführt.

Dieses Problem wird auch auf CoreOS 1068.10.0, Docker 1.10.3, Kernel 4.6.3.

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

Bei Verwendung von Kubernetes 1.3.4 auf CoreOS 1068.9.0 stabil auf EC2, Docker 1.10.3 sehe ich dieses Problem.

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

Dieses Problem wird auch unter Ubuntu 16.04, Docker 1.12.1, Kernel 4.4.0-34-generic angezeigt
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

Für diejenigen, die Kubernetes <= 1.3.4 verwenden, können Sie dieses Problem ausnutzen: https://github.com/kubernetes/kubernetes/issues/30899 , um dieses Problem zu reproduzieren. Ich habe einen kleinen Cluster mit 1 Controller (m4.large) und 2 Workern (m4.large) auf CoreOS 1068.10 ausgeführt.

Von dort aus können Sie 2 ReplicationController erstellen, ich habe sie hello und hello1 basierend darauf genannt: http://pastebin.com/mAtPTrXH . Stellen Sie sicher, dass die Namen und Beschriftungen unterschiedlich sind.

Erstellen Sie dann zwei Bereitstellungen mit denselben Namen/Labels wie oben auf der Grundlage: http://pastebin.com/SAnwLnCw .

_Sobald Sie die Bereitstellungen erstellen, erhalten Sie eine unglaubliche Menge an Spam-Containern_.

Wenn Sie es für eine Weile (einige Minuten) eingeschaltet lassen, werden Sie viele Dinge sehen, die versuchen, zu beenden/zu erstellen. Sie können die Bereitstellungen löschen und die Dinge stabilisieren lassen. Sie sollten eine gute Handvoll Terminating und ContainerCreating sehen. Wenn Sie per SSH in die Knoten einsteigen, überprüfen Sie dmesg und docker ps zu sehen, ob die oben genannten Symptome offensichtlich sind.

In meinem Fall habe ich ungefähr 5 Minuten gebraucht, um das ausflippen zu lassen, bevor ich das Problem sah. Ich plane, die Änderungen vorzunehmen, mit denen @sercand und @edevil gespielt haben, und schaue, ob dies in diesem Fall für mich funktioniert.

@edevil Liege ich nach dem Betrachten Ihres verknüpften Commits richtig, dass Sie Flannel in Ihrer Umgebung insgesamt zugunsten der von Kubernetes erstellten cbro Brücke deaktiviert/entfernt haben, um dieses Problem zu überwinden?

Ich sehe meinerseits, dass Sie sie nicht zusammen verwenden können, weil Flanell docker0 möchte und Ihr internes Netzwerk an cbr0 richtig?

@alph486 das ist richtig, ich habe aufgehört, Flanell zu verwenden. Ich benutze die Bridge und richte die Routen für das Pod-Netzwerk ein.

@alph486 Flanell möchte docker0 nicht verwenden. Es ist nur die Standardbrücke für Docker, die Sie mit der Option --bridge=cbr0 docker überschreiben können.
Unter CoreOS müssten Sie die Docker-Systemd-Unit überschreiben.

Das Kubelet-Flag --experimental-flannel-overlay kann die Flanell-Konfiguration lesen und die Docker-Bridge cbr0 mit der Flanell-CIDR konfigurieren.

Es wird auch den promiscuous Modus anstelle des veth-hairpin Modus aktivieren, der das Problem zu sein scheint.

Danke @dadux für den Input. Wenn K8s die cbr0 Schnittstelle übernimmt, die bereits von der überschriebenen Einheit gebootet wurde, könnte diese Lösung im Geschäft sein; ich werde es versuchen.

Laut Dokumentation scheint promiscuous-bridge der Standardwert für --hairpin-mode in Kubelet v1.3.4+ zu sein. Ich sehe das Problem immer noch damit, daher bin ich mir nicht ganz sicher, ob das die ganze Lösung ist.

Ich konnte das Problem nicht mehr reproduzieren, nachdem ich das kubenet Netzwerk-Plugin verwendet habe (das --configure-cbr0 ). Ich vermeide die Option flannel-overlay aufgrund der Ungewissheit ihrer Zukunft (sie scheint an --configure-cbr0 gebunden zu sein).

Wenn Ihr Docker-Daemon die docker0 Bridge verwendet, hat die Einstellung von --hairpin-mode=promiscuous-bridge keine Auswirkung, da das Kubelet versucht, die nicht vorhandene Bridge cbr0 zu konfigurieren.

Für CoreOS meine Problemumgehung, um das Kubernetes-Verhalten zu spiegeln, aber weiterhin Flanell zu verwenden:

• Fügen Sie ein systemd-Drop-In für docker.service hinzu, um die Bridge docker0 Schnittstelle für den Promiscuous-Modus zu konfigurieren. (Sicher gibt es eine elegantere Möglichkeit, dies zu tun?) :

- 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

• Sagen Sie dem Kubelet, dass es keine Haarnadelkurve in der Docker Bridge setzen soll:
  kubelet --hairpin-mode=none

Sie können überprüfen, ob Hairpin für Ihre Schnittstellen aktiviert ist mit
brctl showstp docker0
oder
for f in /sys/devices/virtual/net/*/brport/hairpin_mode; do cat $f; done

Ich glaube, mein Kollege hat dies kürzlich behoben http://www.spinics.net/lists/netdev/msg393441.html , wir sind auf dieses Problem in unserer Umgebung gestoßen und haben dann das Problem gefunden mehr. Jeder, der auf dieses Problem gestoßen ist, kann diesen Patch ausprobieren und sehen, ob es erneut auftritt. Und aus unserer Analyse bezog es sich auf IPv6, sodass Sie auch versuchen können, IPv6 von Docker mit --ipv6=false deaktivieren, wenn Sie den Docker-Daemon starten

@coolljt0725 Vielleicht

@dadux Danke für deine Hilfe. Auf Kubernetes 1.3.4 CoreOS 1068 Stable, Docker 10.3, Flannel als Netzwerkschicht habe ich das Problem behoben, indem ich die folgenden Änderungen an meinen CoreOS-Einheiten vorgenommen habe:

    - 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

Folgendes zu kubelet.service hinzugefügt:

        --hairpin-mode=none

Welche Auswirkungen haben diese Änderungen auf Docker/Kubernetes in Bezug auf den Umgang des Betriebssystems mit Schnittstellen für Container?
Ich muss betonen, dass es sich um ein Problem mit falschem Betriebssystem-Verhalten handelt, nicht um Docker oder Kubernetes, da wir (und einige andere Leute in diesem Thread) überhaupt nicht Docker oder Kubernetes ausführen, aber beim Stoppen von LXC immer noch auf genau die gleichen Situationen stoßen Container recht schnell hintereinander.

@rdelangh Du hast

Wenn diejenigen, die Docker google für diesen Fehler verwenden, werden sie wahrscheinlich hier landen. Daher ist es sinnvoll, dass wir hier Problemumgehungen für dieses Problem veröffentlichen, damit die Leute weitermachen können, bis die zugrunde liegenden Probleme behoben sind.

Welche Auswirkungen haben diese Änderungen auf Docker/Kubernetes in Bezug auf den Umgang des Betriebssystems mit Schnittstellen für Container?

1. Die Docker-Änderung in meinem Beitrag ermöglicht es dem Kubernetes-Stack, den Docker abzufragen und sicherzustellen, dass die Plattform fehlerfrei ist, wenn das Problem auftritt.
2. Die Änderung von hairpin-mode weist K8s im Wesentlichen an, die docker0 Brücke unverändert zu verwenden, und versucht daher nicht, "Kernelland"-Netzwerke und "Hairpin-Veth" zu verwenden, wo das Problem im Docker beginnt Ausführungspfad.

Es ist eine Problemumgehung für dieses Problem mit K8s und Docker.

Der Patch der coolljt0725-Kollegen wurde für Stable in die Warteschlange gestellt, so dass er hoffentlich bald genug in die Distributionen zurückportiert wird. (Post von David Miller: http://www.spinics.net/lists/netdev/msg393688.html )

Nicht sicher, wo sich dieses Commit befindet und ob wir es an Ubuntu, RH usw. senden sollen, um ihnen zu helfen, es zu verfolgen und zurückzuportieren?

Irgendwann werde ich hier auftauchen, denke ich:
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/ipv6/addrconf.c

EDIT: scheint hier vorhanden zu sein: https://github.com/torvalds/linux/blob/master/net/ipv6/addrconf.c

Danke an coolljt0725 und Co (und alle in diesem Thread). Da viele Leute für einige Zeit nicht in der Lage sein werden, mit dem IPv6-Patch auf einen Kernel zu aktualisieren (derzeit alle), habe ich es geschafft, diesen Fehler zu beheben, nachdem ich viele der Vorschläge aus diesem Thread ausprobiert habe. Ich möchte einen vollständigen Beitrag erstellen, um Dinge nachzuverfolgen, die funktioniert haben und nicht funktioniert haben, damit niemand anderes die Probleme sehen muss, die ich gesehen habe.

TL;DR IPv6 in den Linux-Boot-Parametern deaktivieren, neu starten. Auf Coreos bedeutet dies, dass /usr/share/oem/grub.cfg den Inhalt hat: set linux_append="ipv6.disable=1" und dann einen Neustart. einen allgemeineren Vorschlag, der unter centos/ubuntu/debian/$linuxes funktionieren sollte, finden Sie hier

• versucht ipvlan(l2,l3)/macvlan(bridge): keines davon funktioniert an aws, oder zumindest besitze ich nicht das Wissen, um einen von ihnen dazu zu bringen, an aws zu arbeiten. mit Arbeit meine ich, das Starten eines Containers, der mit ipvlan oder macvlan an ein Netzwerk angeschlossen ist, konnte das Gateway nicht pingen / keine Verbindung zum Internet herstellen (ja, ich habe die Grundidee getestet, die in einer nicht-aws-Umgebung arbeitet). Dies schien das vorliegende Problem tatsächlich zu lösen, aber für unseren Anwendungsfall müssen wir in der Lage sein, eine Verbindung zum Internet herzustellen – für Anwendungsfälle, die dies nicht tun, kann dies eine praktikable Option sein und sieht im Vergleich zur Brücke ziemlich sexy aus .
• versuchte die folgenden Flags, die einzeln an dockerd , und mit bestimmten Kombinationen (da keine von ihnen zu funktionieren schien, war ich nicht zu wissenschaftlich, wenn ich alle Kombinationen ausprobierte):

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

interessanterweise scheint --ipv6=false nicht wirklich etwas zu tun -- das war ziemlich verwirrend, Container erhielten immer noch inet6-Adressen mit diesem Flag.

--userland-proxy=false setzt den Haarnadelmodus und sollte nicht wirklich funktionieren. In Verbindung damit hatte ich etwas Hoffnung, aber auch dies löste das Problem nicht (docker0 auf den promisc-Modus setzen). Es gibt einen Hinweis auf eine Lösung zu --userland-proxy=false hier und diese stromaufwärts bald und es lohnt sich ein weiterer Schuss sein können, wäre es schön, dies unabhängig von der Fehler in dieser Ausgabe für die Leistung festgestellt auszuschalten , aber leider hat es noch eine weitere Fehler zu diesem Zeitpunkt.

• habe versucht, IPv6 über die hier dokumentierten sysctl-Einstellungen zu deaktivieren und systemd-networkd nach dem Anwenden der sysctl-Einstellungen neu zu starten, sowie versucht, IPv6 von dhcpcd wie hier dokumentiert zu deaktivieren
• Wie hier vorgeschlagen, haben wir diese Lösung ausprobiert und nur einen Container gleichzeitig entfernt, und wir wurden immer noch mit diesem Fehler konfrontiert.

zu lang; habe gelesen: Deaktivieren Sie IPv6 in Ihren Grub-Einstellungen. Neustart. profitieren.

Dieses Problem trat unter CentOS 7.2 (3.10.0-327.28.3.el7.x86_64) und Docker 1.12.1 (ohne k8s) auf. Das Problem tritt auf, wenn der Netzwerkverkehr zunimmt.
Das Booten des Kernels mit deaktiviertem IPv6 (wie in den vorherigen Ratschlägen) hat nicht geholfen.
Aber das Versetzen der Docker0-Schnittstelle in den Promisc-Modus hat dies behoben. Gebrauchtes systemd-Drop-in von @dadux (danke!) - scheint jetzt gut zu funktionieren.

@rdallman Das Deaktivieren von IPv6 über Grub verhindert unregister_netdevice für mich weder in Ubuntu 16.06 (Kernel 4.4.0-36-generic) noch in 14.04 (Kernel 3.13.0-95-generic). Unabhängig von der Einstellung --userland-proxy (entweder wahr oder falsch).

Ooooh, das ist cool, dass der Patch für Stable in die Warteschlange gestellt wurde.
ping @aboch für das Problem, dass --ipv6=false nichts tut.

@trifle sorry :( danke für das Posten von Informationen, wir haben nach einigen Testtagen noch keine Probleme, werden aber wieder aktualisieren, wenn wir auf Probleme stoßen. Wir führen Coreos 1122.2 (Kernel 4.7.0) aus. Docker0 auf den Promisc-Modus setzen scheint dies für einige Leute zu beheben (kein Glück für uns).

@RRAlex Wissen Sie, ob sich jemand bezüglich eines Backports an das Ubuntu-Kernel-Team

Mailingliste des Ubuntu-Kernel-Teams:
https://lists.ubuntu.com/archives/kernel-team/2016-September/thread.html

Patch für den stabilen Kernel:
https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d

Ubuntu-Kernel-Commit-Protokoll:
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/?h=master-next
(Patch ist noch nicht da)

@leonsp Ich habe versucht, sie zu dem damit verbundenen Problem zu kontaktieren:
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1403152

Wenn Sie sich die letzte (#79) Antwort ansehen, hat jemand mit diesem Patch einen Kernel für Xenial erstellt:
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1403152

Ich bin mir jedoch nicht sicher, wann es in den Hauptkernelbaum von Ubuntu geht, noch in welcher Beziehung diese Person zu Ubuntu steht und ob das hilft ...

Ich kann die erwähnten Commits aus diesem Thread auch nicht im Ubuntu-Kernel-Commit-Log finden.

@RRAlex Die erwähnten Commits befinden sich im ddstreet-Zweig ~ddstreet/+git/ linux:lp1403152-xenial , hier ist das Protokoll: https://code.launchpad.net/~ddstreet/+git/linux/+ref/lp1403152-xenial
Jeder mit diesem Problem unter Ubuntu 16.04 kann es also ausprobieren. https://launchpad.net/~ddstreet/+archive/ubuntu/lp1403152

Möglicherweise weiß @sforshee (für den Ubuntu-Kernel)

Ich habe es endlich geschafft, die Lösung "ipv6.disable=1" zu testen. Darüber hinaus habe ich auf meinem Debian 8 auf Kernel 4.7.2 aktualisiert.
Nach dem Kernel-Upgrade und dem Aktivieren von "ipv6.disable=1" in den Kernel-Parametern habe ich es geschafft, das "waiting for lo"-Problem bei echter Arbeitslast auch ohne "--userland-proxy=false" Flag für den Docker-Daemon abzufangen. Die gute Nachricht ist, dass ich nach der Angabe von "--userland-proxy=false" und dem Versuch, das Problem mit "docker-stress" zu reproduzieren, das nicht mehr tun kann. Aber ich bin mir ziemlich sicher, dass es unabhängig vom Wert von "--userland-proxy" wieder auftreten wird.
So wie ich sehe, ist IPv6 definitiv an diesem Problem beteiligt, da Docker-Stress das Problem jetzt nicht mehr erfassen kann. Die schlechte Nachricht ist, dass das Problem tatsächlich immer noch da ist (dh es ist nur teilweise behoben).

Wird später das neueste 4.8rc7 kompilieren, um mehr zu testen.

@twang2218 @coolljt0725

Hmmm.. also habe ich gerade den Ubuntu xenial 4.4.0-36 Kernel mit dem Patch von ddstreet's ppa zurückportiert :

$ 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

Leider scheint dies das Problem für mich nicht zu lösen. Beachten Sie, dass ich auch mit "ipv6.disable=1" arbeite. Betrachten wir mehrere unabhängige Ursachen mit dem gleichen Ergebnis? Viele Kommentare in diesem Thread scheinen dies nahe zu legen.

Ich weiß nicht allzu viel darüber, aber ich weiß, dass wir solche Fehler schon einmal hatten. Wie ich es verstehe, werden Referenzzählungen zu jedem Netzwerkgerät am Ende auf lo übertragen, wenn ein Netzwerk-Namespace bereinigt wird direkt. Das macht es zu einem Bären, den man aufspüren kann, denn bis Sie wissen, dass es ein Leck gab, wissen Sie nicht, mit welchem ​​​​Gerät es verbunden war.

Ich habe nicht alle Kommentare durchgelesen, aber wenn mir jemand einen zuverlässigen Reproduzierer auf Ubuntu geben kann, werde ich ihn mir ansehen und sehen, ob ich etwas herausfinden kann.

@sforshee es ist nicht immer einfach zu reproduzieren, aber es wurde ein Patch erstellt (der zumindest einige der hier gemeldeten Fälle behebt); http://www.spinics.net/lists/netdev/msg393441.html. Das wurde Upstream akzeptiert https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d

@thaJeztah ah, ich sehe die Frage, die du mir jetzt gestellt hast.

Der Patch befindet sich also in der Upstream-4.4-Stable-Queue, für 16.04 wird er wahrscheinlich nicht in der nächsten Kernel-SRU (die bereits in Arbeit ist) enthalten sein, sondern in der nächsten, in etwa 5-6 Wochen. Wenn es auch in 14.04 benötigt wird, lassen Sie es mich bitte wissen, damit es zurückportiert werden kann.

@sforshee im Grunde früher (vor diesem Patch), das reproduziert werden konnte, indem man IPv6 im Kernel aktiviert (normalerweise standardmäßig aktiviert), indem man "--userland-proxy=false" zu den Docker-Daemon-Flags hinzufügt und dann docker-stress -c 100 ausführt, for Beispiel (docker-stress stammt von hier: https://github.com/crosbymichael/docker-stress)

@fxposter danke. Wenn es dafür einen Fix gibt, muss ich mich nur darum kümmern, diesen Fix in den Ubuntu-Kernel zu integrieren. Ich kann auch helfen, andere Lecks zu untersuchen, die durch diesen Patch nicht behoben werden.

Ich habe dieses Problem auch. Ich führe Docker in einer rancherOS-Box von AWS aus. Tatsächlich geschieht dies zufällig, nachdem ein Rancher-Cluster (3 Hosts) eingerichtet und eine kleine Anwendung darin ausgeführt wurde.

Das gleiche... Fedora 24, zufällig passieren, kann eine Woche lang in Ordnung sein, dann bekomme ich alle 10 Stunden einen
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Erfahrung mit CentOS 7 mit Kernel 3.10.0-327.36.1.el7 und Docker 1.12.1

Ein Downgrade auf Kernel 3.10.0-327.18.2.el7, während man auf Docker 1.12.1 bleibt, scheint das System stabilisiert zu haben.

Das sehe ich auch:
Docker-Version 1.11.2
Ubuntu 16.04.1 4.4.0-38-generisch

IPv6 deaktiviert (grub)

Hatte gerade dieses Problem ohne --userland-proxy=false (sic!) auf einem Server mit Kernel 4.8.0-rc7, der den IPv6-Patch enthält (sic!!). Vielleicht behebt es einige der Probleme, aber definitiv nicht alle.

Weiß jemand wie man das überhaupt debuggen kann?

Wir haben festgestellt, dass dies bei unserem Setup nur auftritt, wenn wir (fast) keinen freien Speicher mehr haben.

@fxposter Es wäre nützlich, einen minimalen Reproduktionsfall zu finden, was ziemlich schwer ist :/ Dann könnten wir ftrace verwenden, um zumindest Codepfade zu finden.

Geschieht auf 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 leider ist es nicht mehr möglich, es über Docker-Stress zu reproduzieren (zumindest konnte ich es nicht). Ich werde versuchen, unser vorheriges Setup mit Webkits nachzuahmen (die dieses Problem häufiger ausgelöst haben, als mir lieb ist).

@fxposter Dieser Patch behebt nur einige der Probleme (aber in unserer Umgebung treten wir mit diesem Patch nie mehr auf), nicht alle, ich lasse meinen Kollegen dieses Problem weiter untersuchen. Wenn Sie eine Möglichkeit haben, dies zu reproduzieren, lassen Sie es mich bitte wissen, danke :)

Der Fix ist in 4.4.22 stabil https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.22

Ich habe Redhat gebeten, diesen Patch auf Fedora 24 anzuwenden.

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

4.4.0-42 ist sicher noch kaputt...
Ich habe es hier für Ubuntu erwähnt, aber vielleicht hat jemand eine bessere Idee:
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1403152

Ich sehe das auch, Docker-Version 1.11.2, Build b9f10c9/1.11.2, 64bit Amazon Linux 2016.03 v2.1.6.

noch passiert. docker 1.12.2, armbian linux kernel 4.8.4, ipv6.disable=1 in bootargs

wie man den Fehler behebt, ich treffe ihn jeden Tag

@woshihaoren Benutze nicht --userland-proxy=false

Zur Verdeutlichung - wir haben es auch mit deaktiviertem Userland-Proxy konfrontiert

Erhalten Sie dies auf Amazon Linux AMI 2016.9:

$ uname -a

Linux 4.4.23-31.54.amzn1.x86_64 #1 SMP

Docker-Version:

``` Kunde:
Version: 1.11.2
API-Version: 1.23
Go-Version: go1.5.3
Git-Commit: b9f10c9/1.11.2
Gebaut:
Betriebssystem/Arch: linux/amd64

Server:
Version: 1.11.2
API-Version: 1.23
Go-Version: go1.5.3
Git-Commit: b9f10c9/1.11.2
Gebaut:
Betriebssystem/Arch: linux/amd64
```

centos7-Kernel 4.4.30 wieder~~~~

CoreOS 1185.3.0, 4.7.3-coreos-r2, Docker 1.11.2
Reproduzierbar, wenn nur 10..20 debian :jessie- Container mit "apt-get update" als Befehl ausgeführt werden.

CoreOS Stable ist derzeit noch angeschlagen. Der Fix für die 4.7-Serie ist in 4.7.5: https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.7.5

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

    ipv6: addrconf: fix dev refcont leak when DAD failed

TL;DR - In diesem Beitrag gibt es keine Lösungen, aber ich liste auf, was ich bisher verfolgt habe und meine aktuellen Arbeitstheorien. Ich hoffe, dass andere Leute, die das auch verfolgen, einige Informationen hier hilfreich finden, während wir dieses Ding herunterfahren.

@koendc Danke für die Veröffentlichung des Patches, der in 4.7.5 eingeführt wurde. Ich habe den Patch 4e1b3aa898ea93ec10e48c06f0e511de37c35b2d (upstream 751eb6b6042a596b0080967c1a529a9fe98dac1d) auf mein 4.5.5-Setup [1] zurückportiert und konnte das Problem unregister_netdevice problemlos reproduzieren. Es ist möglich, dass andere Änderungen im 4.7.x-Kernel mit dem bereitgestellten Patch zusammenwirken, um dieses Problem zu beheben, aber ich habe das noch nicht bestätigt, also sollten wir noch nicht alle Hoffnung verlieren. Ich teste mit 4.5.5, weil ich einen reproduzierbaren Testfall habe, der das in [2] beschriebene Problem verursacht.

Andere Dinge, die ich aufgrund von Tests bestätigt habe:

• 4.2 ist viel stabiler als jeder neuere Kernel
• 4.5.x ist trivial reproduzierbar. Von den neueren Kerneln, die ich ausgiebig getestet habe (4.8.2 und 4.8.6), besteht das Problem immer noch, obwohl die Zeit bis zum ersten Auftreten zwischen 60s und 48 Stunden lag
• Das Problem scheint sowohl mit dem Netzwerkverkehr als auch mit dem Verhältnis von Containern zur Kapazität der übergeordneten Ressource (virt CPU) zu korrelieren. Wie andere sich entzogen haben, könnte dies ein Ablenkungsmanöver sein, wenn dies tatsächlich eine Rassenbedingung ist

Nächste Schritte:

• Instrumentieren Sie einen Kernel mit den entsprechenden printk-Anweisungen, um einen Fall zu finden, in dem zugewiesene Ressourcen nicht freigegeben werden
• Testen Sie den Kernel 4.7.5 oder höher mit/ohne den oben genannten Patch, um zu sehen, ob das Problem auftritt
• Kurz vor einem der Abstürze sah ich eine sehr interessante Reihe von IPv6: eth0: IPv6 duplicate address <blah> detected Fehlern. Könnte ein weiterer Ablenkungsmanöver sein, aber ich möchte versuchen, IPv6 zu deaktivieren, um zu sehen, ob es einen Zusammenhang gibt

[1] Mein vollständiges Setup ist ein GCE virt, auf dem ein leicht angepasster Debian-Kernel basierend auf 4.5.5 . Docker version 1.8.3, build f4bf5c7 läuft noch dazu
[2] Testfall-Informationen: Ich habe 20 parallele Prozesse, die jeweils einen Node.js- Hello-World- Server in einem Docker-Container starten. Anstatt hello world , gibt der Node.js-Server 1 MB zufälligen Text zurück. Der übergeordnete Prozess befindet sich in einer engen Schleife, die den Container startet, sich zusammenrollt, um die 1 MB an Daten abzurufen, und den Container stoppt. Mit diesem Setup kann ich das Problem in 4-90s konsistent reproduzieren. Die Verwendung desselben Setups auf einem physischen Host oder innerhalb der Virtualbox reproduziert das Problem nicht, trotz unterschiedlicher Elemente, die die mittlere Zeit bis zur Reproduktion auf der GCE-Box ändern. Variablen, mit denen ich gespielt habe: Anzahl gleichzeitiger Testprozesse, Größe der übertragenen Nutzlast und Anzahl der curl-Aufrufe. Die ersten beiden Variablen sind definitiv korreliert, obwohl ich denke, dass es wahrscheinlich nur um die Anpassung der Variablen geht, um einen vernünftigen Sättigungspunkt für die virt zu finden.

Auch ich habe diesen Fehler.

Ich sehe, dass es nach dem Bereitstellen eines Containers dreimal wiederholt wird.

Beschreibung

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

Schritte zum Reproduzieren des Problems:

1. ssh in den Docker-Host
2. einen Container laufen lassen

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

Beschreiben Sie die Ergebnisse, die Sie erhalten haben:

Lass den Fehler einfach 3 mal wiederholen.

Beschreiben Sie die erwarteten Ergebnisse:
Kein Fehler

Zusätzliche Informationen, die Sie für wichtig erachten (z. B. ein Problem tritt nur gelegentlich auf):
Hat erst nach diesem Wochenende angefangen.

Ausgabe von docker version :

 docker --version
Docker version 1.12.3, build 6b644ec

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

Zusätzliche Umgebungsdetails (AWS, VirtualBox, physisch usw.):

Virtuelle Maschine:
Fedora 24
OverlayFS2 auf ext3

Separates Laufwerk, das für die Docker-Nutzung 24 Gigs zugewiesen ist.
16 Gig RAM.

Docker PS

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

Docker-Images

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

Docker-Volume Ls

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

*DF-H *

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

DF -i

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

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

Für alle Interessierten führen wir (Travis CI) ein Upgrade auf v4.8.7 auf Ubuntu 14.04 ein. Unsere Lasttests zeigten keine Vorkommen des hier beschriebenen Fehlers. Zuvor haben wir linux-image-generic-lts-xenial auf Ubuntu 14.04 ausgeführt. Ich plane, in naher Zukunft einen Blog-Beitrag zu veröffentlichen, in dem mehr Details beschrieben werden.

UPDATE : Ich hätte erwähnen sollen, dass wir diesen Docker-Stack ausführen:

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

UPDATE : Wir sehen diesen Fehler _noch_ in der Produktion auf Ubuntu Trusty + Kernel v4.8.7. Wir wissen noch nicht, warum diese Fehler in Staging-Lasttests verschwanden, die den Fehler zuvor reproduzierten, aber die Fehlerrate in der Produktion ist praktisch dieselbe. Vorwärts und aufwärts. Wir haben die "automatische Implosion" aufgrund dieses Fehlers aufgrund der hohen Instanzumwandlungsrate deaktiviert.

auch gefunden in Centos 7

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

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

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

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

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

Das Gleiche passiert hier mit einem DigitalOcean-VPS beim Debian-Testen:

# 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

System

$ 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

Ich habe 4.8.8 in einer engen Schleife (siehe [2] aus meinem früheren Kommentar zum Testfall) die letzten 4 Tage ununterbrochen getestet. So weit, ist es gut.

Fakten

• Patch 751eb6b6 reduziert das Auftreten dieses Problems erheblich, beseitigt es jedoch nicht vollständig.

Vermutungen
@meatballhat wies darauf hin, dass auf ihren Produktionsservern das Problem beim Ausführen von 4.8.7 aufgetreten ist. Damit bleiben uns zwei Möglichkeiten:

• Mein Testtestfall ist fehlerhaft (die wahrscheinlichere Möglichkeit)
• 4.8.8 führte einen Fix ein. Wenn man sich das Changelog 4.8.8 ansieht, erwähnen die Commits 5086cadf und 6fff1319 beide Netdev-Probleme, die behoben wurden. Keiner ruft das Problem hier explizit hervor, aber beide sind nahe genug, um verdächtig zu sein.

Können wir einige Leute dazu bringen, 4.8.8 auszuprobieren, um zu sehen, ob sie dieses Problem reproduzieren können?

@reshen Ich werde uns auf 4.8.8 aktualisieren und berichten :+1: Vielen Dank für Ihre Recherche!

@reshen Hervorragende Recherche. Auch unter Linux 4.8.8 auf Xubuntu 16.04 konnte ich das Problem bisher nicht reproduzieren.

Ich habe die Ubuntu-Mainline-Kernel-Builds verwendet . Ich habe keinen gut definierten Testfall, aber ich konnte das Problem vorher konsequent reproduzieren, indem ich die Docker-Container, mit denen ich arbeite, starte und stoppte.

Um Linux 4.8.8 zu testen, war es für mich am einfachsten, von aufs zu overlay2 als Speichertreiber zu wechseln, da die Mainline-Kernel-Builds aufs nicht enthalten. Ich glaube nicht, dass dies den Test beeinflusst, aber es sollte beachtet werden.

In der Vergangenheit habe ich Linux 4.4.4 mit dem von Dan Streetman zurückportierten 751eb6b6 getestet, dies schien das Problem für mich nicht zu verringern. Es wird interessant sein zu sehen, ob auch das Zurückportieren der beiden von Ihnen notierten Patches (5086cadf und 6fff1319) das gleiche Ergebnis wie 4.4.8 liefern kann.

Ubuntu 16.04 mit 4.4.0-47 war immer noch betroffen... probiere jetzt 4.4.0-49, werde später berichten.

edit: 2016-11-28: -49 zeigt diese Protokollzeile in dmesg an.

Habe dies auf Fedora 25 (Kernel 4.8.8) und Docker 1.12.3 erlebt

Zu Ihrer Information: Wir haben Linux 4.8.8 in Verbindung mit Docker v1.12.3 auf einem einzigen Produktionshost ausgeführt. Die Betriebszeit beträgt derzeit 5,5 Tage und die Maschine bleibt stabil.

Wir sehen gelegentlich eine Handvoll unregister_netdevice: waiting for lo to become free. Usage count = 1 Meldungen im Syslog, aber im Gegensatz zu früher stürzt der Kernel nicht ab und die Meldung verschwindet. Ich vermute, dass eine der anderen Änderungen, die entweder im Kernel oder in Docker eingeführt wurden, diesen Zustand erkennt und sich jetzt davon erholt. Für uns ist diese Meldung nun zwar ärgerlich, aber kein kritischer Fehler mehr.

Ich hoffe, einige andere Leute können das oben genannte auf ihren Produktionsflotten bestätigen.

@gtirloni - können Sie klären, ob Ihr 4.8.8/1.12.3-Computer abgestürzt ist oder ob Sie die Nachricht gerade gesehen haben?

Vielen Dank im Voraus an alle, die daran gearbeitet haben, nützliche Informationen zu reproduzieren/zur Verfügung zu stellen, um dieses Ding zu triangulieren.

Wir löschen das Gegenstück der veth-Schnittstelle (docker0) nach dem Starten von Docker und starten Docker danach neu, wenn wir den Host mit ansible bereitstellen. Problem ist seitdem nicht aufgetreten.

Ich erhalte denselben Fehler auch auf einem Raspberry Pi 2, auf dem Raspbian mit Docker ausgeführt wird.

Kernel-Info
Linux rpi2 4.4.32-v7+ #924 SMP Tue Nov 15 18:11:28 GMT 2016 armv7l GNU/Linux

Docker-Info

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

Dies geschah, nachdem ein Container erstellt wurde, der etwa 50 MB heruntergeladener Programme benötigte.

Nur ein Neustart würde mich die Maschine wieder benutzen lassen

Ich sehe dies tatsächlich unter Amazon Linux in einem ECS-Cluster - die Nachricht wird gelegentlich ausgelöst, aber sie stürzt nicht ab, wie es Reshen jetzt sieht. Docker 1.11.2. Uname meldet als Version "4.4.14-24.50.amzn1.x86_64".

@reshen Ich werde dieses Wochenende 4.8.8 auf meinem Laptop bauen und sehen, ob das so ist
behebt es für mich!
ᐧ

Am Do, 1. Dezember 2016 um 10:29 Uhr, Ernest Mueller [email protected]
schrieb:

Ich sehe dies tatsächlich auf Amazon Linux in einem ECS-Cluster - die Nachricht
wirft gelegentlich, aber es schließt nicht ab, wie es Reshen jetzt sieht.
Docker 1.11.2. Uname meldet als Version "4.4.14-24.50.amzn1.x86_64".

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/5618#issuecomment-264220432 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AKklVRqoBUZDu3HMhGv3b6knnA6j6C_Qks5rDvXRgaJpZM4B4L4Z
.

--
Keifer Fürzland
http://kfrz.work

Ich konnte dieses Problem auch mit https://github.com/crosbymichael/docker-stress auf einem Kubernetes-Worker-Knoten mit CoreOS Stable 1185.3.0 reproduzieren.

Ausführen von docker_stress_linux_amd64 -k 3s -c 5 --containers 1000 : 5 gleichzeitige Worker, die Container erstellen/löschen, maximale Lebensdauer von Containern = 3s, Erstellen von bis zu 1000 Containern auf einer m4.large-Instanz auf AWS würde den Docker-Daemon nach etwa drei Minuten nicht mehr reagieren lassen.

Auf CoreOS Beta 1235.1.0 aktualisiert und ich konnte es nicht reproduzieren (sowohl die Nicht-Reaktion als auch die unregister_netdevice Meldung in den Kernel-Logs). Während das Ausführen von 5 gleichzeitigen docker_stress-Workern CoreOS Stable nach wenigen Minuten beenden würde, konnte ich mit 10 und 15 gleichzeitigen Workern bis zum Abschluss des Tests mit CoreOS Beta laufen.

CoreOS wird in "Kanälen" veröffentlicht, sodass es nicht möglich ist, den Kernel isoliert zu aktualisieren. Hier sind die Hauptunterschiede zwischen Stable und Beta:

CoreOS Stabil 1185.3.0

Kernel: 4.7.3

Docker: 1.11.2

CoreOS Beta 1235.1.0

Kernel: 4.8.6

Docker: 1.12.3

Dieses Problem wird in Amazon Elastic Beanstalk mit 4.4.23-31.54.amzn1.x86_64 angezeigt

Passieren Sie einfach auf CoreOS Stable 1185.5.0, Docker 1.12.2
Nach einem Neustart ist alles in Ordnung

Update: Das Problem mit dem hängenden Docker-Daemon ist auf einem Host mit CoreOS Beta 1235.1.0 mit Docker v1.12.3 und Linux-Kernel v4.8.6 erneut aufgetreten. 😢

1.12.4 und 1.13 sollten theoretisch nicht einfrieren, wenn dieses Kernelproblem auftritt.
Der Grund für das Einfrieren des Docker-Daemons liegt darin, dass der Daemon auf eine Netlink-Nachricht vom Kernel wartet (die nie kommen wird), während er die Sperre für das Container-Objekt hält.

1.12.4 und 1.13 setzen einen Timeout für diese Netlink-Anforderung, um zumindest die Containersperre aufzuheben.
Dadurch wird das Problem __nicht__ behoben , aber zumindest (hoffentlich) friert nicht der gesamte Daemon ein.
Sie werden wahrscheinlich nicht in der Lage sein, neue Container zu starten, und Sie werden sie wahrscheinlich auch nicht abreißen können, da es so aussieht, als ob alle Interaktionen mit Netlink stagnieren, sobald dieses Problem auftritt.

@cpuguy83 FWIW, alle laufenden Container werden weiterhin ohne

Dies behebt das Problem nicht, aber zumindest (hoffentlich) friert nicht der gesamte Daemon ein.

Der einzige Vorteil des ganzen Daemons, der eingefroren ist, ist, dass er leicht herauszufinden ist. Kubernetes kann den Knoten entfernen, vielleicht sogar automatisch neu starten. Sollte der Daemon einfach weiterlaufen, wäre es dann noch möglich, das aufgetretene Kernel-Problem zu finden?

@seanknox Ich könnte Ihnen ein benutzerdefiniertes CoreOS 1248.1.0 AMI mit gepatchtem Docker (CoreOS Docker 1.12.3 + Upstream 1.12.4-rc1-Patches) zur Verfügung stellen. Auf meinen CoreOS/K8s-Clustern wurden alle paar Stunden Aufhängungen behoben. Pingen Sie mich einfach mit Ihrer AWS Account-ID auf Deis Slack an.

Wir haben große Probleme mit diesem Problem auf unserem CoreOS-Cluster. Kann jemand sagen wann es endlich behoben wird? Wir träumen von diesem Moment, in dem wir nachts schlafen können.

@DenisIzmaylov Wenn Sie --userland-proxy=false nicht festlegen, sollten Sie im Allgemeinen nicht auf dieses Problem stoßen .

Aber ansonsten ist dies ein Fehler im Kernel, möglicherweise mehrere Kernel-Fehler, von denen einige sagen, dass sie in 4.8 behoben sind und andere nicht. Für einige scheint das Deaktivieren von IPv6 das Problem zu beheben, andere nicht (daher sind es wahrscheinlich mehrere Probleme ... oder zumindest mehrere Ursachen).

Ich habe dieses Problem innerhalb von Stunden auf Hochlastsystemen mit und ohne --userland-proxy=false

Bestätigt, dass wir immer noch unregister_netdevice Fehler in Kernel 4.8.12 sehen . Es dauert etwa 5 Tage, um auszulösen. Nur ein Neustart des Systems scheint das Problem zu beheben. Das Stoppen von Docker scheint auf unbestimmte Zeit zu hängen.

Habe den IPv6-Trick für den Kernel-Boot noch nicht ausprobiert.

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

Wäre genial, wenn jemand dies mit 1.12.5 versuchen könnte, was jetzt bei der hängenden Netlink-Anfrage ein Timeout haben sollte, anstatt nur Docker zu hängen.

@ cpuguy83 jedoch ist das System in diesem Zustand immer noch unbrauchbar :)

@LK4D4 Oh, total, ich möchte nur diese Timeouts sehen;)

Beheben dieses Problems unter Cent OS 7:

kernel:unregister_netdevice : Warten, bis lo frei wird. Nutzungsanzahl = 1

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

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

Dies wirkt sich auf meine CI-Builds aus, die in Docker-Containern ausgeführt werden und plötzlich zu sterben scheinen, während diese Konsolenmeldung angezeigt wird. Gibt es eine Lösung oder einen Workaround? Danke!

@ cpuguy83 Docker hängt für mich nicht, wenn dieser Fehler auftritt, aber die Container werden getötet, was in meiner Situation meine Jenkins / CI-Jobs unterbricht.

Also habe ich Docker für eine Weile (11 Monate?) ohne Probleme auf einem Centos 7-Rechner ausgeführt. Heute habe ich beschlossen, den TCP-Listening-Daemon auszuprobieren ( die TCP-Listening-Adresse wurde zu /etc/sysconfig/docker hinzugefügt ) und habe gerade diesen Fehler erhalten.

kernel:unregister_netdevice : Warten, bis lo frei wird. Nutzungsanzahl = 1

meine Nutzungsanzahl ist also nicht 3.

Behälter: 4
Laufen: 3
Angehalten: 0
Gestoppt: 1
Bilder: 67
Serverversion: 1.10.3
Speichertreiber: btrfs
Build-Version: Btrfs v4.4.1
Bibliotheksversion: 101
Ausführungstreiber: native-0.2
Protokollierungstreiber: json-Datei
Plugins:
Lautstärke: lokal
Netzwerk: Null-Host überbrücken
Kernel-Version: 3.10.0-514.2.2.el7.x86_64
Betriebssystem: CentOS Linux 7 (Kern)
Betriebssystemtyp: Linux
Architektur: x86_64
Anzahl Docker-Haken: 2
CPUs: 24
Gesamtspeicher: 39,12 GiB
Name: aimes-web-encoder
ID: QK5Q: JCMA:ATGR :ND6W:YOT4:PZ7G:DBV5:PR26: YZQL:INRU : HAUC:CQ6B
Registrierungen: docker.io (sicher)

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

Klient:
Version: 1.10.3
API-Version: 1.22
Paketversion: docker-common-1.10.3-59.el7.centos.x86_64
Go-Version: go1.6.3
Git-Commit: 3999ccb-nicht unterstützt
Gebaut: Do 15. Dez 17:24:43 2016
Betriebssystem/Arch: linux/amd64

Server:
Version: 1.10.3
API-Version: 1.22
Paketversion: docker-common-1.10.3-59.el7.centos.x86_64
Go-Version: go1.6.3
Git-Commit: 3999ccb-nicht unterstützt
Gebaut: Do 15. Dez. 17:24:43 Uhr 2016
Betriebssystem/Arch: linux/amd64

Ich kann @aamerik bestätigen. Ich sehe das gleiche Problem bei der gleichen Kernel-Version. Keine größeren Änderungen in letzter Zeit am System, dieses Problem seit heute.

Ich habe dieselbe kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1 Meldung auf meinem CentOS 7-Computer gesehen, auf dem ein Docker-Image von Jenkins ausgeführt wurde. Der CentOS 7-Computer, den ich verwendet habe, war mit den neuesten CentOS 7-Patches (Stand: 20. Dezember 2016) auf dem neuesten Stand.

Da die neuesten Referenzen hier auf CentOS basieren, werde ich meinen Ausführungshost auf einen Ubuntu- oder Debian-Rechner umstellen.

Ich führe Docker version 1.12.5, build 7392c3b auf diesem CentOS 7-Rechner aus. Docker hat sich nicht aufgehängt, aber der Jenkins-Prozess, den ich in Docker ausgeführt habe, wurde beendet, als diese Meldung angezeigt wurde.

Vielen Dank für Docker! Ich benutze es die ganze Zeit und bin zutiefst dankbar für Ihre Arbeit daran!

Ich sehe das gleiche Problem, wenn ich Jenkins mit Docker auf einem Linux 4.8.15-Computer verwende.

Hat jemand eine Lösung für Rancher OS gefunden?

AFAICT, dies ist ein Sperrproblem im Netzwerk-Namespaces-Subsystem des Linux-Kernels. Dieser Fehler wurde vor über einem Jahr ohne Antwort gemeldet: https://bugzilla.kernel.org/show_bug.cgi?id=97811 Es wurde daran gearbeitet (siehe hier: http://www.spinics. net/lists/netdev/msg351337.html), aber es scheint keine vollständige Lösung zu sein.

Ich habe versucht, den Netzwerk-Subsystem-Maintainer direkt anzupingen, ohne darauf zu reagieren. FWIW, ich kann das Problem in wenigen Minuten reproduzieren.

Smyte zahlt 5000 USD für die Lösung dieses Problems. Klingt so, als müsste ich mit jemandem sprechen, der am Kernel arbeitet?

@petehunt Ich glaube, es gibt mehrere Probleme, die diesen Fehler verursachen.

Wir haben den Kernel 4.8.8 wie von @reshen vorgeschlagen

Es wird versucht, Mesosphere von einem Bootstrap-Knoten aus bereitzustellen. Alle Knoten sind CentOS 7.2 minimal mit allen angewendeten Updates. Der Bootstrap-Knoten zeigt den Fehler an, wie oben von anderen erwähnt:

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

Ich kann bestätigen, dass ein Neustart die Nachrichten zum Schweigen bringt, aber sobald ich Mesosphere wieder einsetze, starten die Nachrichten ab und zu. Mesosphäre ist eine ziemlich große Bereitstellung. Vielleicht können diejenigen, die versuchen, den Fehler zu reproduzieren, das Installationsprogramm verwenden, um den Fehler zu reproduzieren. Es dauert ein paar Minuten, bis der Fehler nach dem ersten Skriptwechsel ( --genconf ist der erste Schritt ) auftritt.

Wir haben das auch getroffen. Allerdings erwähnen die Fehlermeldungen in unserem Fall das Gerät eth0 nicht lo . Mein Fehler ist dieser:

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

Ich gehe davon aus, dass Fehler wie das Erwähnen von eth0 anstelle von lo dieselbe Ursache haben wie dieses Problem. Wenn nicht, sollten wir ein neues Ticket bezüglich der eth0-Fehler eröffnen.

• Betriebssystem: CentOS Linux-Version 7.3.1611
• Kernel: 3.10.0-514.2.2.el7.x86_64
• Docker-Version 1.12.6, Build 78d1802
• Docker begann mit Optionen: OPTIONS=" -H unix:///var/run/docker.sock --ip-forward=true --iptables=true --ip-masq=true --log-driver json-file --log-opt max-size=25m --log-opt max-file=2"
• Rancher 1.2.2 mit IPsec (Erwähnung, da https://bugzilla.kernel.org/show_bug.cgi?id=97811 und andere Fehler IPsec erwähnen)

Wir haben das auch getroffen.
Fehler: unregister_netdevice: Warten darauf, dass lo frei wird.
Betriebssystem: CentOS Linux-Version 7.3.1611 (Kern)
Kernel 3.10.0-514.2.2.el7.x86_64
Docker-Version: 1.13.0-cs1-rc1
Docker-Optionen:
{
"disable-legacy-registry": wahr,
"icc": wahr,
"unsichere-Registrierungen":[],
"ipv6": falsch,
"iptables":wahr,
"storage-driver": "devicemapper",
"Speicheroptionen": [
"dm.thinpooldev=/dev/mapper/docker_vg-thinpool",
"dm.use_deferred_removal=true",
"dm.use_deferred_deletion=true"
],
"userland-proxy": false
}

Ich habe dies auf zwei CentOS-Systemen, neueste Updates auf mindestens einem von ihnen.

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

Hey, für alle, die von diesem Problem auf RHEL oder CentOS betroffen sind, habe ich den Commit der Mainline-Kernel (torvalds/linux@751eb6b6042a596b0080967c1a529a9fe98dac1d) zurückportiert, der die Race-Bedingung im IPV6-IFP-Refcount auf 3.10.x-Kernel behebt, die in Enterprise-Distributionen verwendet werden. Dies sollte dieses Problem beheben.

Den Fehlerbericht mit funktionierendem Patch finden Sie hier :
Wenn Sie daran interessiert sind, es zu testen und ein RHEL 7- oder CentOS 7-System haben, habe ich mit dem Patch bereits den neuesten CentOS 7.3 3.10.0-514.6.1.el7.x86_64-Kernel kompiliert. Antworten Sie auf den CentOS Bugtracker-Thread und ich kann Ihnen einen Link zum Build senden.

Hinweis: Möglicherweise gibt es ein anderes Problem, das ein Refcount-Leck verursacht, aber dies sollte die Fehlermeldung für viele von Ihnen beheben.

@stefanlasiewski @henryiii @jsoler

Ich werde einen Build ausprobieren, der auch diesen Fix hinzufügt: http://www.spinics.net/lists/netdev/msg351337.html später heute Abend.

@iamthebot bedeutet das, dass das Problem auch ohne einen Patch, den Sie gerade

@redbaron nur, wenn dies das Problem ist, auf das Sie treffen. Ich denke wirklich, dass es hier mehrere Kernel-Probleme gibt.

@redbaron vielleicht. #20569 scheint darauf hinzuweisen, dass es schwierig ist, IPv6 vollständig zu deaktivieren.

Um ein wenig zu verdeutlichen, was unter der Haube passiert, die diese Nachricht generiert, zählt der Kernel, ob ein Gerät verwendet wird, bevor es aus einem Namespace entfernt, die Registrierung aufgehoben, deaktiviert usw Verweis auf ein Gerät, dann wird diese Fehlermeldung angezeigt, da die Registrierung nicht aufgehoben werden kann, wenn sie von einer anderen Person verwendet wird.

Die Fixes, die ich bisher gesehen habe:

1. Beheben Sie ein Problem, bei dem ein Problem mit einer IPv6-Adresszuweisung fehlschlägt (z. B. eine doppelte Adresse), aber wir den Verweis auf das Gerät vor dem Beenden nicht freigeben.
2. Behebung eines Problems, bei dem das Verschieben des Namespace eines Geräts die Verweise auf das Gerät korrekt in den neuen Netzwerk-Namespace verschiebt, aber eine hängende Referenz auf dem alten Namespace verbleibt. Docker nutzt stark Netzwerk-Namespaces (wie durch einen anderen Kernel-Fix belegt, dass ich Red Hat auf 7.3 Z-Stream zurückportieren ließ und für die Aufnahme in 7.4 vorgesehen ist, was verhindert, dass der Macvlan-Treiber von Docker auf Bond- oder Team-Geräten funktioniert)

Ich denke, es gibt noch eine andere Race Condition beim Wechseln von Namespaces (dies scheint nach dem Erstellen einer Reihe neuer Container zu passieren), aber ich muss das Problem zuverlässig replizieren, um es zu finden und einen Patch zu schreiben.

Hat jemand ein minimales Verfahren, um dies konsequent zu reproduzieren? Scheint auf unseren Systemen zufällig zu passieren.

@iamthebot es ist nicht wirklich einfach, aber ich denke, wir können Ihnen eine Testumgebung zur Verfügung stellen, die dies zuverlässig reproduzieren kann. Senden Sie mir eine E-Mail ([email protected]) und wir können die Details arrangieren.

Erleben Sie dies immer noch unter hoher Last auf Docker-Version 1.12.6, Build 7392c3b/1.12.6 auf 4.4.39-34.54.amzn1.x86_64 AWS Linux AMI.

Ich habe 9 Docker-Hosts, die alle fast identisch sind, und erlebe dies nur bei einigen von ihnen. Es mag Zufall sein, aber eine Gemeinsamkeit ist mir aufgefallen, dass ich dieses Problem anscheinend nur habe, wenn ich Container ausführe, die SIGINT nicht verarbeiten. Wenn ich diese Container docker stop lege, hängt es 10 Sekunden lang und tötet dann den Container unhöflich.

Es dauert mehrere Tage, bis das Problem auftaucht und scheint zufällig aufzutreten, nicht nur sofort nach dem Ausführen von docker stop . Dies ist meist anekdotisch, aber vielleicht hilft es jemandem.

Ich habe alle meine Docker-Knoten auf Kernel 3.10.0-514.6.1.el7.x86_64 auf CentOS 7.3 aktualisiert, wie
26. Jan 13:52:49 XXX-Kernel: unregister_netdevice: wartet darauf, dass lo frei wird. Nutzungsanzahl = 1
Nachricht von syslogd@XXX am 26. Januar 13:52:49 ...
kernel:unregister_netdevice : Warten, bis lo frei wird. Nutzungsanzahl = 1

@jsoler, nur um das angewendet , bevor du den Kernel erstellt hast? Oder verwendest du einen Stock-Kernel? Versuchen Sie auch, diesen anzuwenden (Patch sollte auf älteren Kerneln funktionieren).

Schicken Sie mir eine E-Mail ([email protected]) und ich kann Ihnen einen Link zu einem vorgefertigten Kernel senden. @vitherman Ich habe leider nicht viel Zeit, um mich damit zu

@ckeeney Ich kann dieses Verhalten bestätigen. Wir haben eine dockerisierte Node-Anwendung, die beim Herunterfahren den genannten Fehler auf dem Host-System verursacht hat. Nach der Implementierung einer Funktion in der Node.js-Anwendung, die SIGINT und SIGTERM abfängt, um die Anwendung ordnungsgemäß herunterzufahren, ist der Fehler nicht mehr aufgetreten.
Was irgendwie Sinn macht; die Node-Anwendung verwendet die virtuelle Schnittstelle, die Docker erstellt. Wenn Node nicht ordnungsgemäß heruntergefahren wird, hängt das Gerät und das Hostsystem kann die Registrierung nicht aufheben, obwohl der Docker-Container erfolgreich gestoppt wurde.

Hier ist ein Beispiel-Code-Snippet:

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 Gibt es ein anderes Signal, das von Node standardmäßig für ein sauberes Herunterfahren ordnungsgemäß verarbeitet wird? (Sie können das STOPSIGNAL im Bild oder auf docker run durch das --stop-signal Flag angeben.

@thaJeztah für eine gute Erklärung des Problems und eine Problemumgehung siehe

@ckeeney Das ist mir bekannt (dh Prozesse, die als PID1 können möglicherweise nicht mit SIGINT oder SIGTERM umgehen ). Aus diesem Grund habe ich mich gefragt, ob die Angabe eines anderen Stoppsignals auch bei der Ausführung als PID1 einen sauberen Shutdown bewirken würde.

Alternativ fügt Docker 1.13 eine --init Option hinzu (Pull-Request: https://github.com/docker/docker/pull/26061), die eine Init in den Container einfügt; In diesem Fall wird Node nicht als PID1 , was in Fällen hilfreich sein kann, in denen Sie die Anwendung nicht aktualisieren können.

@iamthebot Ich habe die Kernelversion 3.10.0-514.el7 mit integriertem Patch erstellt, aber ich erhalte den gleichen Fehler. Nun, ich bin mir nicht sicher, ob ich das Kernel-Paket von centos gut gebaut habe. Könnten Sie mir Ihr Kernel-Paket zum Testen zur Verfügung stellen?

Vielen Dank

Ich beschäftige/beschäftige mich seit fast einem Jahr mit diesem Fehler. Ich verwende CoreOS mit PXE-Boot, ich habe IPv6 in der pxeboot-Konfiguration deaktiviert und habe dieses Problem seitdem kein einziges Mal gesehen.

Nun, meine Umgebung hat IPv6 mit dieser sysctl-Konfiguration deaktiviert
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
aber ich bekomme immer noch den Fehler
kernel:unregister_netdevice : Warten, bis lo frei wird. Nutzungsanzahl = 1

@jsoler richtig, das habe ich auch gemacht, ist trotzdem passiert. Erst als ich es auf pxe-Ebene getan habe, hörte es auf.

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

Nur eine Beobachtung - es scheinen verschiedene Probleme im Spiel zu sein (das wurde bereits gesagt).

• Einige Leute bemerken "Warten auf Lo..."
• einige haben notiert "Warten auf eth0"
• einige haben bemerkt "warte auf veth????"
• Beim RedHat-Bug-Tracking wird von "Warten auf ppp0" gesprochen.

Einige haben festgestellt, dass Protokolle zwischen den oben genannten wechseln und andere nur eine der oben genannten haben.

Es gibt auch einen ähnlichen Fehler, der unter Ubuntu protokolliert wurde . In diesem Fall scheint NFS das Problem zu sein.

@etlweather Ich glaube, dass der einzige gemeinsame Nenner tatsächlich darin besteht, dass ein abgemeldet werden kann, wie die Fehlermeldung sagt. Die Gründe _warum_ sind jedoch etwas anders. Bei uns war es definitiv das erwähnte Docker/Node-Problem (veth). Für eth ist die Ursache höchstwahrscheinlich etwas ganz anderes.

Passiert immer noch mit 4.9.0-0.bpo.1-amd64 auf Debian Jessie mit Docker 1.13.1. Gibt es eine Kernel-OS-Kombination, die stabil ist?

Dies ist möglicherweise kein reines Docker-Problem - ich bekomme es auf einem Proxmox-Server, auf dem ich nur Vanilla-LXC-Container (Ubuntu 16.04) ausführe.

@darth-veitcher es ist ein Kernel-Problem

@thaJeztah stimmte zu, danke. Wollte heute Abend 4.9.9 von Mainline installieren und sehen, ob das Probleme behebt.

Ich bekomme es mit Docker 1.13.1 auf einem Debian mit Kernel 4.9.9-040909.

Ja, das Upgrade des Kernels auf Proxmox auf die neueste Version 4.9.9 hat den Fehler nicht behoben. Seltsam, da es erst nach einem Jahr ohne Probleme erschienen ist.

Möglicherweise steht in einer früheren Anweisung weiter oben im Thread etwas darüber, dass sie entweder mit eingehängten NFS- oder CIFS-Freigaben verknüpft ist.

von meinem Iphone gesendet

Am 14. Februar 2017 um 07:47 Uhr schrieb Alfonso da Silva [email protected] :

Ich bekomme es mit Docker 1.13.1 auf einem Debian mit Kernel 4.9.9-040909.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

Ich habe diesbezüglich ein Bugzilla-Ticket bei Redhat geöffnet.

Einige Entwicklungen:
Red Hat hat die IPV6-Refcount-Leak-Patches von Mainline auf QA gestellt, es sieht so aus, als ob sie für RHEL 7.4 in der Warteschlange stehen und möglicherweise auf 7.3 zurückportiert werden. Sollte bald auch auf CentOS-plus sein. Hinweis: Dieser Patch behebt nur in EINIGEN Fällen Probleme. Wenn Sie einen 4.x-Kernel haben, ist dies ein strittiger Punkt, da sie bereits vorhanden sind.

Dies ist definitiv eine Race Condition im Kernel, soweit ich das beurteilen kann, was es wirklich nervig macht, es zu finden. Ich habe einen Schnappschuss des aktuellen Mainline-Kernels gemacht und arbeite an der Instrumentierung der verschiedenen Aufrufe, beginnend mit dem IPv6-Subsystem. Das Problem ist jetzt definitiv reproduzierbar: Alles, was Sie tun müssen, ist, eine Reihe von Containern zu erstellen, eine Menge Netzwerkverkehr aus ihnen zu schieben, das Programm in den Containern zum Absturz zu bringen und sie zu entfernen. Wenn Sie dies immer wieder tun, wird das Problem innerhalb von Minuten ausgelöst, am besten auf einer physischen 4-Core-Workstation.

Leider habe ich nicht viel Zeit, um daran zu arbeiten: Wenn es hier Kernel-Entwickler gibt, die bereit sind, bei der Instrumentierung der notwendigen Teile mitzuarbeiten, denke ich, können wir eine Abzweigung einrichten und daran arbeiten, dies Schritt für Schritt zu suchen .

@iamthebot , ist es auf einem qemu-kvm-Setup reproduzierbar?

@iamthebot Ich habe mehrmals versucht, dies mit verschiedenen Kerneln zu docker-stress -c 100 mit userland-proxy auf false ausgelöst wird, aber ich hatte kein Glück.

Wenn Sie ein zuverlässigeres Repro haben (auch wenn es lange dauert, bis es ausgelöst wird), kann ich es versuchen und nachsehen

Wir stoßen in unseren Produktions- und Staging-Umgebungen auf die gleiche Schwierigkeit. Wir werden bald auf Docker 1.13 und Linux-Kernel 4.9 aktualisieren, aber wie bereits erwähnt; auch diese Versionen sind betroffen.

$ 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

Ich habe dieses Problem ziemlich regelmäßig auf meinem Entwicklungssystem, immer beim Herunterfahren von Containern.

Allgemeine Information

→ 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-Daemon-Log

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 Wenn Sie versuchen, einen Container zu stoppen, aber er nicht auf SIGINT reagiert, wartet Docker 10 Sekunden und beendet dann den Container unhöflich. Ich bin auf dieses Verhalten in meinen nodejs-Containern gestoßen, bis ich die Signalbehandlung hinzugefügt habe. Wenn Sie sehen, dass ein Container 10 Sekunden braucht, um zu stoppen, verarbeitet er wahrscheinlich keine Signale und löst dieses Problem eher aus.

Stellen Sie sicher, dass Ihre Container ordnungsgemäß stoppen können.

Obwohl ich nicht derjenige bin, der dieses Problem behebt, da ich nicht viel mit Linux-Kernel-Entwicklung zu tun habe, denke ich, dass ich recht habe, wenn ich sage, dass die "ich auch" -Kommentare nicht so hilfreich sind. Damit meine ich, nur zu sagen "Ich habe dieses Problem auch, mit Kernel vx.x und Docker 1.x" bringt nichts Neues in die Diskussion.

Ich würde jedoch vorschlagen, dass "ich auch"-Kommentare, die mehr die Umgebung und die Methode der Reproduktion beschreiben, von großem Wert wären.

Beim Lesen aller Kommentare wird klar, dass es ein paar Probleme gibt - wie ich vorhin gepostet habe, einige mit vethXYZ, einige mit eth0 und andere mit lo0. Dies deutet darauf hin, dass sie durch verschiedene Probleme verursacht werden könnten. Wenn Sie also nur "Ich auch" sagen, ohne den Fehler und die Umgebung vollständig zu beschreiben, kann dies die Leute in die Irre führen.

Auch bei der Beschreibung der Umgebung reicht die Angabe der Kernel- und Docker-Version nicht aus. Laut Thread scheint es ein paar Faktoren zu geben, z. B. IPv6 aktiviert oder nicht. NodeJS reagiert nicht auf SIGINT (oder andere Container, die hier nicht auf NodeJS schlagen).

Es wäre also nützlich, zu beschreiben, wie hoch die Arbeitsbelastung der Umgebung ist. Dies tritt auch auf, wenn ein Container heruntergefahren wird, daher würde ich den Leuten, die dieses Problem haben, vorschlagen, darauf zu achten, welcher Container gestoppt wird, wenn das Problem seinen hässlichen Kopf zeigt.

Obwohl es den Anschein hat, dass das Problem darin liegt, dass der Kernel eine Race Condition hat, wird die Identifizierung des Auslösers für diejenigen, die das Problem beheben, eine enorme Hilfe sein. Und es kann den betroffenen Benutzern sogar eine sofortige Lösung bieten, z. B. die Implementierung eines Signalhandlers in einer NodeJS-Anwendung (ich weiß selbst nicht, ob dies das Auslösen des Problems verhindert, aber es scheint so, wie frühere Kommentare anderer).

FWIW kubernetes hat dies vollständig mit dem "Hairpin-Modus" von veth korreliert und
hat die Verwendung dieser Funktion vollständig eingestellt. Das haben wir noch nicht erlebt
Problem überhaupt, über Zehntausende von Produktionsmaschinen und weitläufig
weitere Testläufe, seit dem Wechsel.

Bis dies behoben ist, verlassen Sie das Schiff. Finde eine andere Lösung :(

Am Mittwoch, den 15. Februar 2017 um 10:00 Uhr schrieb ETL [email protected] :

Obwohl ich nicht derjenige bin, der dieses Problem behebt, bin ich nicht viel von Linux
Kernel-Entwickler, ich denke, ich habe Recht, wenn ich sage, dass die "Ich auch"-Kommentare es nicht sind
das hilfreich. Damit meine ich, nur zu sagen: "Ich habe dieses Problem auch, mit
Kernel vx.x and Docker 1.x" bringt nichts Neues in die Diskussion.

Ich würde jedoch vorschlagen, dass "ich auch" Kommentare vorschlagen, die mehr beschreiben
Umgebung und Methode zur Reproduktion von großem Wert wären.

Beim Lesen aller Kommentare wird klar, dass es ein paar Probleme gibt -
wie ich vorhin gepostet habe, einige mit vethXYZ, einige mit eth0 und andere mit lo0.
Dies deutet darauf hin, dass sie durch verschiedene Probleme verursacht werden könnten. Also nur
"Ich auch" sagen, ohne den Fehler und die Umgebung vollständig zu beschreiben, kann
Menschen in die Irre führen.

Wenn Sie die Umgebung beschreiben, geben Sie auch den Kernel und Docker
Version ist nicht ausreichend. Laut Thread scheint es ein paar Faktoren zu geben
wie IPv6 aktiviert oder nicht. NodeJS reagiert nicht auf SIGINT (oder andere
Container, hier kein Bashing auf NodeJS).

Es wäre also nützlich, zu beschreiben, wie hoch die Arbeitsbelastung der Umgebung ist.
Dies tritt auch auf, wenn ein Container heruntergefahren wird, daher würde ich
schlagen Sie den Menschen, die dieses Problem haben, auch vor, auf was zu achten
Container wird gestoppt, wenn das Problem seinen hässlichen Kopf zeigt.

Obwohl das Problem anscheinend darin liegt, dass der Kernel eine Race-Bedingung hat -
Die Identifizierung des Auslösers wird denjenigen, die das Problem beheben, eine enorme Hilfe sein
Das Thema. Und es kann den betroffenen Benutzern sogar eine sofortige Lösung bieten
wie die Implementierung eines Signalhandlers in einer NodeJS-Anwendung (ich weiß es nicht)
Ich selbst, dass dies verhindert, dass das Problem ausgelöst wird, aber es scheint so per
frühere Kommentare anderer).

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/5618#issuecomment-280087293 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AFVgVFmu1SiStZcLKtKuk1W-tjn6wOXlks5rcz0hgaJpZM4B4L4Z
.

Ja, wir ziehen zu gke um und sehen dieses Problem nicht mehr (also kein Bug-Bounty mehr von uns :))

Hatte den Fehler gerade wieder. Ich habe versucht, eine node.js-Anwendung zu reparieren, die Sockets verwendet, und habe die Anwendung daher häufig skaliert. Die node.js-App wurde auf https://github.com/deployd/deployd erstellt. Ich hoffe, dass dies ein paar mehr Informationen liefert. Interessant war auch, dass beide Server in meinem Schwarm gleichzeitig den Fehler unregister_netdevice anzeigten, nachdem ich den Dienst über den Docker-Dienst rm entfernt hatte. Der Container wurde auf 4 skaliert, sodass auf jeder Maschine zwei Container liefen.

edit Ist schon wieder passiert! Arbeiten an derselben node.js-App. In den letzten 3 oder 4 Tagen habe ich nicht direkt an dieser node.js-Anwendung gearbeitet und es ist nie aufgetreten.

edit2 wird versuchen, der nodejs-App einen Signalhandler hinzuzufügen. Mal sehen ob das hilft....

Ich bin gerade auf diesen Fehler gestoßen, nachdem ich docker-py verwendet hatte, um eine neue Instanz in EC zu veröffentlichen. Ich konnte jedoch mit Strg + C beenden und habe es seitdem nicht mehr gesehen (jetzt, da die meisten Bilder schneller aus dem Cache erstellt werden)

```{"status":"Pushed","progressDetail":{},"id":"c0962ea0b9bc"}
{"status":"Stufe: Auszug: sha256:f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8 Größe: 5737"}
{"progressDetail":{},"aux":{"Tag":"stage","Digest":"sha256:f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8","Size":5737}}

Docker-Image erfolgreich veröffentlicht

Nachricht von syslogd@ip-172-31-31-68 am 16. Februar 19:49:16 ...
Kernel:[1611081.976079] unregister_netdevice: Warten darauf, dass lo frei wird. Nutzungsanzahl = 1

Nachricht von syslogd@ip-172-31-31-68 am 16. Februar 19:49:27 ...
Kernel:[1611092.220067] unregister_netdevice: Warten darauf, dass lo frei wird. Nutzungsanzahl = 1

[1]+ Angehalten ./image-publish.py
[ root@ip-172-31-xx-xx Bildveröffentlichung ]# ^C
[ root@ip-172-31-xx-xx Bildveröffentlichung ]#

@thockin ist diese Einstellung --hairpin-mode=none auf den Kubelets?

=none bricht Container, die mit NAT auf sich selbst zurückgeführt werden. Wir gebrauchen
promiscuous-bridge standardmäßig.

Am Donnerstag, 16. Februar 2017 um 19:26 Uhr, Kanat Bekt [email protected]
schrieb:

@tockin https://github.com/tockin ist diese Einstellung --hairpin-mode=none
auf den Kubelets?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/5618#issuecomment-280539673 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AFVgVLNwAH6NWVaIKhJfS147O9w_rtJEks5rdRN8gaJpZM4B4L4Z
.

@thockin Welche Container möchten möglicherweise über Service ClusterIP auf sich selbst zugreifen?

Es stellt sich heraus, dass es häufiger vorkommt, als ich dachte, und als wir es brachen, viele
der Leute beschwerten sich.

Am 17. Februar 2017 um 00:38 Uhr schrieb "Maxim Ivanov" [email protected] :

@tockin https://github.com/tockin welche Container vielleicht möchten
selbst über Service ClusterIP zugreifen?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/5618#issuecomment-280588366 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AFVgVLn3uBvUW-dQ72qst5_eYiFUtfSVks5rdVyIgaJpZM4B4L4Z
.

Ich glaube, ich weiß, warum eine dockerisierte Nodejs-App dieses Problem verursachen könnte. Node verwendet standardmäßig Keep-Alive-Verbindungen. Wenn server.close() verwendet wird, akzeptiert der Server keine neuen Verbindungen. Aktuelle aktive Verbindungen wie Websockets oder HTTP-Keep-Alive-Verbindungen werden jedoch weiterhin aufrechterhalten. Wenn die dockerisierte App auch auf n skaliert wird, kann dies zu waiting for lo to become free da bei der Zwangsbeendigung lo neuere freigegeben werden. Wenn Docker diese App an einen anderen Knoten verteilt oder die App verkleinert wird, sendet Docker ein Signal an die App, dass sie heruntergefahren werden soll. Die App hört auf dieses Signal und kann reagieren. Wenn die App nach einigen Sekunden nicht beendet wird, beendet Docker sie ohne zu zögern. Ich habe Signalhandler hinzugefügt und festgestellt, dass bei Verwendung von server.close() der Server nicht perfekt beendet wird, sondern "nur" keine neuen Verbindungen mehr akzeptiert (siehe https://github.com/nodejs/node/issues/2642). Daher müssen wir sicherstellen, dass auch offene Verbindungen wie Websockets oder http-Keep-Alive geschlossen werden.

Umgang mit Websockets:
Die nodejs-App sendet an alle Websockets closeSockets wenn ein Shutdown-Signal empfangen wird. Der Client hört auf dieses closeSockets Ereignis und ruft sockets.disconnect() und kurz darauf sockets.connect() . Denken Sie daran, dass server.close() aufgerufen wurde, damit diese Instanz keine neuen Anfragen akzeptiert. Wenn andere Instanzen dieser dockerisierten App ausgeführt werden, wählt der Loadbalancer im Docker schließlich eine Instanz aus, die nicht heruntergefahren wird, und eine erfolgreiche Verbindung wird hergestellt. Die Instanz, die heruntergefahren werden soll, hat keine offenen Websockets-Verbindungen.

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

So handhaben Sie Keep-Alive-HTTP-Verbindungen:
Derzeit weiß ich nicht, wie das perfekt gemacht werden kann. Am einfachsten ist es, Keep-Alive zu deaktivieren.

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

Eine andere Möglichkeit besteht darin, das Keep-Alive-Timeout auf einen sehr niedrigen Wert zu setzen. Zum Beispiel 0,5 Sekunden.

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

Hoffe das konnte anderen helfen :)

Ich habe die gleichen Probleme. Anhänge sind alle Protokolle, die aus dem ecs-logs-collector-Skript erstellt wurden.
Bin für jede Hilfe dankbar :)

sammeln.zip

Ich habe die gleichen Probleme.
Docker-Version 1.13.1, Build 092cba3
Linux debian 4.8.6-x86_64-linode78

Linux-Backup 4.6.0-040600-generic #201606100558 SMP Fr Jun 10 10:01:15 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Serverversion: 1.13.1

Gleicher Fehler. Ich verwende Mount im privilegierten Container. Nach 4-5 Durchläufen friert es ein. Ich habe auch das gleiche Problem mit dem neuesten Standard-Kernel für 16.04

Jeder, @etlweather ist

@rneugeba @redbaron Leider ist das aktuelle "Repro", das ich habe, sehr hardwarespezifisch (alles außer dass dies eine Rennbedingung ist). Ich habe nicht versucht, ein QEMU-Repro zu erhalten, aber das ist definitiv der nächste Schritt, damit mehrere Personen tatsächlich daran arbeiten und das erwartete Ergebnis erzielen können (idealerweise in einem 1-CPU-Kern-Setup). Wenn jemand schon eine hat, schick mir bitte eine E-Mail (sie steht in meinem Profil). Ich werde es ausgiebig testen und hier posten.

Wir bekommen dies in GCE ziemlich häufig. Docker friert ein und die Maschine hängt beim Neustart.

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

Der Container führt eine Go-Anwendung aus und hat die konfigurierte Hairpin-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.04LTS,

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

Hat jemand einen Lösungsvorschlag dafür? Ich habe versucht, --userland-proxy=true aktivieren und Docker hängt nach einer Weile immer noch. Es scheint, dass Kubernates eine Lösung von dem hat, was @tockin oben geschrieben hat, aber es ist nicht klar, was --hairpin-mode=promiscuous-bridge genau macht und wie man das bei einer einfachen Jane Ubuntu 16.x Docker-Installation konfiguriert.

Ich kann dies zuverlässig erreichen, wenn ich Proxmox ausführe und Container verwende. Insbesondere wenn ich in letzter Zeit eine beträchtliche Datenmenge oder wirklich eine beliebige Datenmenge verschoben habe, führt das Herunterfahren oder das harte Stoppen des Containers zu diesem Fehler. Ich habe es am häufigsten gesehen, wenn ich Container verwende, die mein NAS darin einbinden, aber das könnte ein Zufall sein.

# 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

Und innerhalb von 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

Es ist erwähnenswert, dass Docker auf diesem System nicht installiert ist und noch nie war. Ich stelle gerne alle Daten zur Verfügung, die die Community benötigt, um dieses Problem zu beheben. Sagen Sie mir einfach, welche Befehle ausgeführt werden sollen.

Ich kann dies auf Centos 7.3 reproduzieren, die als Schwarm-Worker-Knoten ausgeführt werden, auf dem dtr mit einem zugeordneten gemounteten nfs-Volume ausgeführt wird

Wenn Sie hier ankommen

Das hier diskutierte Problem ist ein Kernel-Bug und wurde noch nicht behoben. Es gibt eine Reihe von Optionen, die für _manche_ Situationen hilfreich sein können, aber nicht für alle (es ist höchstwahrscheinlich eine Kombination von Problemen, die denselben Fehler auslösen).

Hinterlasse keine "Das habe ich auch"-Kommentare

"Ich habe das auch" hilft nicht, den Fehler zu beheben. Hinterlassen Sie nur einen Kommentar, wenn Sie Informationen haben, die zur Lösung des Problems beitragen können (in diesem Fall ist die Bereitstellung eines Patches für den Kernel-Upstream möglicherweise der beste Schritt).

Wenn Sie wissen möchten, dass Sie auch dieses Problem haben , verwenden Sie

Wenn Sie über Updates informiert bleiben möchten, verwenden Sie den _Abonnieren-Button_.

Jeder Kommentar hier sendet eine E-Mail / Benachrichtigung an über 3000 Personen. Ich möchte die Konversation zu diesem Thema nicht abschließen, da es noch nicht gelöst ist, aber möglicherweise gezwungen wird, wenn Sie dies ignorieren.

Vielen Dank!

Das ist alles schön und gut, aber welche Möglichkeiten helfen _genau_? Dieses Problem verursacht uns Probleme in der Produktion, daher würde ich gerne alle Workarounds tun, die notwendig sind, um den Kernel-Bug zu umgehen.

Wenn jemand von Docker Zeit hat, den Kubernetes-Workaround auszuprobieren, bitte
lass es mich wissen und wir können dich darauf hinweisen. Ich kann die Änderungen nicht extrahieren
und patchen Sie sie jetzt selbst in Docker.

Am Donnerstag, 9. März 2017 um 7:46 Uhr, Matthew Newhook [email protected]
schrieb:

Das ist alles schön und gut, aber was genau sind die Optionen, die helfen?
Dieses Problem verursacht uns Probleme in der Produktion, also würde ich gerne tun, was auch immer
Workarounds, die notwendig sind, um den Kernel-Bug zu umgehen.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/5618#issuecomment-285388243 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AFVgVGdH5VX_oFWkImyo_TvlIuhmwMepks5rkB7MgaJpZM4B4L4Z
.

@thockin danke. Ich habe das PR/Problem in Kubernetes mit dem Hairpin-Mode-Workaround verfolgt. Aber während des vielen Hin und Hers habe ich den Überblick verloren, wenn die Problemumgehung dieses Problem tatsächlich beseitigt ?
(Wie ich weiß, gibt es verschiedene Szenarien, die die Ref-Count-Inkonsistenz im Kernel verursachen).

Wenn Sie mich auf den PR verweisen können, von dem Sie glauben, dass er das Problem in K8s behebt, werde ich daran arbeiten, dies zumindest für den Fall, dass der Userland-Proxy standardmäßig deaktiviert ist, im Docker gepatcht zu bekommen. (Und wir können es mit den Docker-Stress-Reproduktionsschritten testen).

Ich bin mir nicht sicher, ob ich eine einzige PR habe, aber Sie können sich den aktuellen Stand ansehen. Start
Hier:

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

Am Samstag, 11. März 2017 um 22:49 Uhr, Madhu Venugopal [email protected]
schrieb:

@thockin https://github.com/thockin danke. Ich habe die verfolgt
PR/Problem in Kubernetes mit der Problemumgehung im Hairpin-Modus. Aber während der
Vieles hin und her, ich habe den Überblick verloren, wenn der Workaround das tatsächlich beseitigt
Ausgabe ?
(Wie ich weiß, gibt es verschiedene Szenarien, die den Ref-Count verursachen
Inkonsistenz im Kernel).

Wenn Sie mich auf die PR verweisen können, die Ihrer Meinung nach das Problem in K8s anspricht,
Ich werde daran arbeiten, dass dies im Docker zumindest für den Fall des Drehens gepatcht wird
userland-proxy standardmäßig deaktiviert. (Und wir können es mit dem Docker-Stress testen
Reproduktionsschritte).

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/docker/docker/issues/5618#issuecomment-285926217 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AFVgVIlGs_QccxS6YYQiLNybddDzB4yUks5rk5VogaJpZM4B4L4Z
.

Hey alle, nur um es klarzustellen, die einzige "Kubernetes-Problemumgehung" besteht darin, den Promiscuous-Modus auf der zugrunde liegenden Bridge zu aktivieren. Dasselbe erreichen Sie mit ip link set <bridgename> promisc on mit iproute2. Es verringert die Wahrscheinlichkeit, auf den Fehler zu stoßen, beseitigt ihn jedoch möglicherweise nicht vollständig.

Theoretisch sollte dies nicht funktionieren ... aber aus irgendeinem Grund scheint der Promiscuous-Modus den Geräte-Teardown gerade so langsam zu machen, dass Sie kein Rennen bekommen, um den Ref-Zähler zu verringern. Vielleicht kann sich einer der Kurbernetes-Mitwirkenden hier einmischen, wenn er in diesem Thread ist.

Ich kann überprüfen, ob die Problemumgehung (NICHT FIX) mit meinem umgebungsspezifischen Repro funktioniert. Ich kann nicht wirklich überprüfen, ob es hilft, wenn Sie die IPVLAN- oder MACVLAN-Treiber verwenden (wir verwenden macvlan in prod), da es sehr schwierig scheint, diese Setups dazu zu bringen, diesen Fehler zu erzeugen. Kann jemand mit einem Repro versuchen, die Problemumgehung zu überprüfen?

Hallo zusammen, ich habe versucht, das Kernelproblem zu debuggen, hatte eine E-Mail-Kette auf der Mailingliste "netdev", also wollte ich hier nur einige Ergebnisse posten.

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

Das Problem, das wir sehen, ist das

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

während der Containerabschaltung. Wenn ich den Namespace des Containernetzwerks inspiziere, scheint es, als ob das eth0 Gerät bereits gelöscht wurde, aber nur das lo Gerät dort verbleibt. Und es gibt eine andere Struktur, die die Referenz für dieses Gerät enthält.

Nach einigem Suchen stellt sich heraus, dass das "Ding", das die Referenz enthält, einer der "Routing-Cache" ( struct dst_entry ) ist. Und etwas verhindert, dass dieses bestimmte dst_entry gc'ed wird (der Referenzzähler für dst_entry ist größer als 0). Also loggte ich alle dst_hold() (erhöhe dst_entry Referenzzähler um 1) und dst_release() (verringere dst_entry Referenzzähler um 1), und es gibt tatsächlich mehr dst_hold() Aufrufe als dst_release() .

Hier sind die Protokolle im Anhang: kern.log.zip

Zusammenfassung:

• die lo Schnittstelle wurde in lodebug umbenannt, um das Greifen zu erleichtern
• der Referenzzähler für dst_entry beginnt mit 1
• der Referenzzähler für dst_entry (der die Referenz für lo enthält) am Ende ist 19
• es gibt insgesamt 258041 dst_hold() Anrufe und 258023 insgesamt dst_release() Anrufe
• in den 258041 dst_hold() Calls gibt es 88034 udp_sk_rx_dst_set() (die dann dst_hold() ), 152536 inet_sk_rx_dst_set() und 17471 __sk_add_backlog()
• in den 258023 dst_release() Anrufen gibt es 240551 inet_sock_destruct() und 17472 refdst_drop()

Es gibt insgesamt mehr udp_sk_rx_dst_set() und inet_sk_rx_dst_set() Aufrufe als inet_sock_destruct() .

AKTUALISIEREN:
Es stellte sich heraus, dass Sockets ( struct sock ) korrekt erstellt und zerstört wurden, aber für einige der TCP-Sockets werden inet_sk_rx_dst_set() mehrmals auf demselben dst aufgerufen, aber es gibt nur einen entsprechenden inet_sock_destruct() , um den Verweis auf dst freizugeben.

Hier ist der CentOS 7.3-Workaround, der es für mich behoben hat:

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

Hier ist der Patch, der es behebt:
https://bugs.centos.org/view.php?id=12711&nbn=1

UPDATE: Es stellte sich heraus, dass das Problem nicht dauerhaft gelöst wurde. Es tauchte einige Stunden später wieder mit der folgenden Wandnachricht auf:
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

@adrianotto - zur Klarstellung:

@stayclassychicago @adrianotto Dieser Patch

@stayclassychicago Bevor ich den 3.10.0-514.10.2.el7.centos.plus.x86_64 Kernel ausprobierte, bekam ich sehr regelmäßig kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1 , fast jedes Mal, wenn ich einen Container mit docker run --rm ... ausführte, wenn der Container beendet wurde. Nach dem Kernel-Upgrade und dem Neustart blieb es für viele Stunden vollständig stehen und kam dann wieder zurück. Jetzt die Hälfte der Zeit, die ich Container lösche, funktioniert es einwandfrei, wo es früher sehr oft zu Fehlern kam. Ich weiß nicht genau, ob der neue Kernel hilft, aber es schadet nicht.

Es sieht so aus, als ob es sehr einfach zu reproduzieren ist, wenn die Maschine eine LACP-Bonding-Schnittstelle hat. Wir haben einen Schwarm-Cluster mit 3 Knoten, alle 3 mit einer konfigurierten LACP-Bonding-Schnittstelle, und dieses Problem erlaubt uns im Grunde nicht, mit dem Cluster zu arbeiten. Wir müssen Knoten alle 15-20 Minuten neu starten.

Bestätigt - sobald ich das LACP-Bonden von den Interfaces (die als Hauptinterfaces verwendet wurden) entfernt habe, funktioniert alles für mehr als 12 Stunden einwandfrei. Wird alle ~30 Minuten gebrochen.

Dies ist reproduzierbar auf 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 wobei Docker version 17.04.0-ce, build 4845c56 im privilegierten Modus läuft, wenn wir cifs-Mounts geöffnet haben. Wenn der Container mit geöffneten Mounts stoppt, reagiert Docker nicht mehr und wir erhalten den kernel:[ 1129.675495] unregister_netdevice: waiting for lo to become free. Usage count = 1 -Fehler.

Ubuntu 16.04 (Kernel 4.4.0-78-generic) hat das Problem immer noch. Und wenn es passiert, bleibt jede Anwendung, die versucht, einen neuen Netzwerk-Namespace über den Klon-Systemaufruf zu erstellen, stecken

[ 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

Die einzige Lösung besteht darin, die Maschine hart zurückzusetzen.

Ich bin auf dieses Problem gestoßen, als ich ein NFS-Volume in einem privilegierten Container gemountet und dann den Container neu gestartet habe.
Es scheint mir, dass dieses Problem bei RHEL 7 mit dem gleichen Verfahren nie aufgetreten ist.

$ 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 behauptet, dass eine Instanz dieses Fehlers mit der Veröffentlichung von kernel-3.10.0-514.21.1.el7 behoben wurde. Ich nehme an, sie werden den Fix so schnell wie möglich vorspielen und auf 4.12 umbasieren. Dieses Paket ist auch bereits für CentOS 7 verfügbar.

Dokumentation zum Fix (RHN-Zugriff erforderlich):
https://access.redhat.com/articles/3034221
https://bugzilla.redhat.com/show_bug.cgi?id=1436588

Aus dem Artikel:
"Im Falle einer doppelten IPv6-Adresse oder eines Problems beim Festlegen einer Adresse ist eine Race-Bedingung aufgetreten. Diese Race-Bedingung führte manchmal zu einem Leck beim Zählen von Adressreferenzen. Folglich schlugen Versuche zum Aufheben der Registrierung eines Netzwerkgeräts mit der folgenden Fehlermeldung fehl: "unregister_netdevice: waiting um frei zu werden. Nutzungsanzahl = 1". Mit diesem Update wurde der zugrunde liegende Quellcode behoben, und Netzwerkgeräte melden sich jetzt wie erwartet in der beschriebenen Situation ab."

Ich habe diesen Fix bereits in allen Systemen unseres PaaS-Pools implementiert und es sind bereits 2 Tage vergangen, ohne dass der Fehler auftritt. Früher wurde mindestens ein System pro Tag eingefroren. Ich werde hier berichten, wenn der Fehler wieder auftritt.

Ich habe die Kernel-Version 3.10.0-514.21.1.el7.x86_64 und habe immer noch das gleiche Symptom.

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 Anscheinend gibt es mehrere Möglichkeiten, dieses Problem zu

@bcdonadio Wenn Sie sich https://git.centos.org/commitdiff/rpms!kernel.git/b777aca52781bc9b15328e8798726608933ceded ansehen, werden Sie https://bugzilla.redhat.com/show_bug.cgi?id=1436588 Fehler ist "behoben" durch diese Änderung:

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

Was seit 4.8 im Upstream-Kernel ist, glaube ich (https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d). Und 4.9 und 4.10 haben diesen Fehler, also hat RedHat nur einige der Fixes vom Upstream zurückportiert, die wahrscheinlich einige Probleme beheben, aber definitiv nicht alle.

@bcdonadio Ich kann den Fehler auf meinem System reproduzieren, Testskript einmal pro Stunde von Cron aus ausführe:

#!/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

Dieses Skript erstellt nur eine Paketliste mit einem Image in der Docker-Registrierung und ein weiteres mit einem, das lokal erstellt wurde, damit ich sie vergleichen kann. Das Dockerfile ist genau das:

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

2-4 Minuten später bekommt syslog diese Meldung:

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

Beim letzten Vorfall geschah ein paar Minuten, nachdem ich das Skript manuell ausgeführt hatte. Ich vermute, dass die Fehlerbedingung ausgelöst wird, nachdem eine Zeitüberschreitung nach dem Versuch des Löschens des Containers verstrichen ist.

Ich bin mir sicher, dass die Fehlerbedingung zeitweise auftritt, da das obige Skript um :00 nach jedem Fehler als Cron-Job ausgeführt wird. Hier ist ein Beispiel der Fehlerausgabe, die syslog aufgezeichnet hat:

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

Es passiert also irgendwo im Bereich von 2 bis 4 Minuten nach dem Ausführen und Beenden der Container und werden von Docker aufgrund des Flags --rm gelöscht. Beachten Sie auch aus dem obigen Protokoll, dass nicht für jeden Container, der ausgeführt/gelöscht wird, ein Fehler auftritt, aber er ist ziemlich konsistent.

Wäre es möglich, dass jemand sieht, ob dieser Patch die Dinge verbessert?

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

@hlrichardson Das sieht tatsächlich so aus! Ich werde versuchen, es morgen auf unseren 3.16-Kernel zurück zu portieren oder bestimmte Server zu aktualisieren und Kernel 4.9 mit diesem Patch morgen zu kompilieren, wir werden sehen, wie es läuft.

Nach Überprüfung der Commit-Referenzen dieses Patches (https://github.com/torvalds/linux/commit/0c1d70af924b966cc71e9e48920b2b635441aa50) wurde es jedoch im 4.6-Kernel festgeschrieben, während das Problem schon vorher da war :(

Ah, also vielleicht nicht verwandt, es sei denn, es gibt mehrere Ursachen (leider gibt es viele Möglichkeiten, wie diese Art von Fehler ausgelöst werden kann, also ist dies eine Möglichkeit).

Wir persönlich haben hier mindestens mehrere Probleme angesprochen - in einigen davon diese
"unregister_netdevice"-Protokolle verschwinden nach einiger Zeit einfach und
Docker-Container können gut funktionieren, während in anderen - alle Container
hängen geblieben und der Server muss neu gestartet werden.

Tatsächlich verwenden wir vxlan nicht auf Servern, die diese Probleme haben - wir verwenden
einfache Bridges und Portweiterleitung (es geschieht unabhängig vom Userland-Proxy
die Einstellungen).

Am 30. Mai 2017, 22:54 Uhr, schrieb "hlrichardson" [email protected] :

Ah, also vielleicht nicht verwandt, es sei denn, es gibt mehrere Ursachen
(Leider gibt es viele Möglichkeiten, wie diese Art von Fehler ausgelöst werden kann, also
das ist eine Möglichkeit).

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/moby/moby/issues/5618#issuecomment-304989068 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAGqoDHe1n3h9_eJ2kmeWcbhKRCX6rZoks5r_HPbgaJpZM4B4L4Z
.

OK, wenn Sie keine vxlan-Tunnel verwenden, wird es definitiv nicht helfen.

Übrigens, wenn Sie beim Löschen eines Netzwerk-Namespaces (Container-Exit) eine einzelne Instanz der Meldung "unregister_netdevice" sehen, sollte dies als normale Situation angesehen werden, in der etwas, das auf ein Netdevice verweist, mehr oder weniger gleichzeitig mit dem Namespace bereinigt wurde
wurde gelöscht.

Der schwerwiegendere Fall ist, dass diese Nachricht alle 10 Sekunden wiederholt wird und nie aufhört ...
in diesem Fall wird eine globale Sperre für immer gehalten, und da diese Sperre jedes Mal erworben werden muss, wenn Netzwerk
Namespace hinzugefügt oder gelöscht wird, auch jeder Versuch, einen Netzwerk-Namespace zu erstellen oder zu löschen
hängt für immer.

Wenn Sie eine ziemlich schmerzlose Möglichkeit haben, die zweite Art von Problem zu reproduzieren, wäre ich daran interessiert
sich etwas ansehen.

@hlrichardson Wir sehen den zweiten Fall, den Sie oben erwähnt haben, auf einer Reihe unserer Server, dh eine Nachricht, die alle 10 Sekunden wiederholt wird. Welche Informationen soll ich teilen?

Sehen Sie dies auf Fedora 25, während Sie centos:7- Container testen und bauen, während Sie yum verwenden. Yum konnte das Herunterladen der Paketdatenbank nicht beenden und blieb auf unbestimmte Zeit hängen, weil das Netzwerk auf seltsame Weise nicht mehr funktionierte.

Hallo Leute,

Es gibt einen möglichen Patch für den Kernel-Fehler (oder zumindest einen der Fehler) in der Linux-Net-dev-Mailingliste:

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

Es ist im Netzbaum zusammengeführt, in der Warteschlange für den stabilen Baum.

Laut https://github.com/torvalds/linux/commit/d747a7a51b00984127a88113cdbbc26f91e9d815 - es ist in 4.12 (die gestern veröffentlicht wurde)!

@fxposter @kevinxucs Ich werde morgen versuchen, dies auf den aktuellen CentOS-Kernel zurückzuportieren.

Ich verwende 4.12 (von http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12/) und habe immer noch dieses Problem, also muss torvalds/ linux@d747a7a nicht die vollständige Lösung sein.

$ uname -r
4.12.0-041200-generic

Ryan, hast du eine zuverlässige Methode zur Reproduktion?

Am 6. Juli 2017 um 16:29 Uhr schrieb "Ryan Campbell" [email protected] :

Ich verwende 4.12 (von http://kernel.ubuntu.com/~
kernel-ppa/mainline/v4.12/) und ich habe immer noch das gefunden, also torvalds/linux@
d747a7a https://github.com/torvalds/linux/commit/d747a7a darf nicht sein
die Komplettlösung.

$ uname -r
4.12.0-041200-generisch

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/moby/moby/issues/5618#issuecomment-313413120 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAdcPCbVPDjPw6va-N5dM7CjYn2W4Bodks5sLO9ZgaJpZM4B4L4Z
.

@justincormack Leider habe ich kein Minimalbeispiel, das ich teilen kann, aber wir haben eine Testsuite, die viele Container erstellt und zerstört, und normalerweise waiting for lo to become free in syslog) nach nur wenigen Iterationen.

@campbellr Ich habe das jetzt dreimal versucht zu waiting for lo to become free Nachrichten zu erhalten, aber danach ohne Abstürze / Hängenbleiben. Ich versuche, den Testfall zu reduzieren, indem ich nur Netzwerk-Namespace und veth-Schnittstellen erstelle.

In Ihrer Testsuite:

• Haben Ihre Container viel Netzwerkaktivität? Wenn ja, welche Richtung ist vorherrschend?
• Auf welcher Art von Maschine führen Sie diese aus (Anzahl der Kerne, ist es eine VM usw.)
• Erstellen Sie viele Container gleichzeitig?
• Verlassen Ihre Container normal oder stürzen sie ab?

Selbst teilweise Antworten auf die oben genannten Punkte können helfen, es einzugrenzen ...
Danke

@rn Docker hängt nicht mehr, da es ein Timeout für die Netlink-Anforderung festlegt, die normalerweise hängen würde. Aber Sie könnten keine neuen Container starten (oder vorhandene neu starten), wahrscheinlich wäre die Containerbereinigung beim Stoppen auch seltsam.

Ich hatte noch keine Gelegenheit, 4.12 zu testen, konnte aber auf den kvm-Instanzen bei vultr zuverlässig reproduzieren. Ich laufe Schwarm und meine kopflosen Chromarbeiter verursachen die Probleme, wenn sie die Gesundheitsprüfungen nicht bestehen oder regelmäßig abstürzen. Natürlich habe ich zu diesem Zeitpunkt alle Crasher aufgespürt, die Netzwerkfehler sauber verarbeiten usw. Ich sehe also waiting for lo to become free aber nicht oft genug, um Dinge für ein paar Wochen aufzuhängen.

Es scheint also, dass die Dinge, die bei der Reproduktion helfen, komplexere Netzwerkszenarien in Kombination mit großen Mengen an Verkehr in die Container, ständigem Container-Recycling und KVM sind.

@rn Ich konnte dies auf einen bestimmten Container in unserer Testsuite

1. start container (ein interner Tornado-basierter Webdienst - ich versuche, ein minimales Beispiel zu extrahieren, das immer noch darauf trifft)
2. Stellen Sie eine Anfrage an den Webdienst, der im Container ausgeführt wird
3. warte auf antwort
4. Behälter töten

Nach 3 oder 4 Iterationen bekomme ich waiting for lo to become free und bei der nächsten Iteration scheitert docker run mit docker: Error response from daemon: containerd: container did not start before the specified timeout.

Haben Ihre Container viel Netzwerkaktivität? Wenn ja, welche Richtung ist vorherrschend?

Eine ziemlich kleine Menge. In den oben genannten Schritten ist die http-Anfrage eine kleine Menge von JSON, und die Antwort ist ein binäres Blob, das etwa 10 MB groß ist.

Auf welcher Art von Maschine führen Sie diese aus (Anzahl der Kerne, ist es eine VM usw.)

Dies ist auf einem 4-Kern-Desktop-Computer (keine VM)

Erstellen Sie viele Container gleichzeitig?

Nein, alles wird seriell gemacht.

Verlassen Ihre Container normal oder stürzen sie ab?

Sie werden mit docker stop gestoppt

1. start container (ein interner Tornado-basierter Webdienst - ich versuche, ein minimales Beispiel zu extrahieren, das immer noch darauf trifft)
2. Stellen Sie eine Anfrage an den Webdienst, der im Container ausgeführt wird
3. warte auf antwort
4. Behälter töten

Ich habe einige Zeit damit verbracht, den Container zu entfernen, und es stellte sich heraus, dass der Webservice nichts mit dem Fehler zu tun hatte. Was dies in meinem Fall auszulösen scheint, ist das Mounten einer NFS-Freigabe in einem Container (der mit --privileged ).

Auf meinem Desktop kann ich einfach folgendes ein paar Mal zuverlässig reproduzieren:

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

Kubernetes-Benutzer, ich habe _kops_ ein Problem geöffnet, um das nächste Kubernetes-AMI mit Kernel-Version 4.12 zu veröffentlichen. Willkommen, um es auszuprobieren: https://github.com/kubernetes/kops/issues/2901

Ich habe dies auch auf centos 7.3 mit Hostkernel 3.10.0-514.6.1.el7.x86_64 und docker-ce-17.06.0.ce-1.el7.centos.x86_64 getroffen.

@FrankYu das ist nicht hilfreich. Um sinnvoll an diesem Thread teilzunehmen, geben Sie bitte eine genaue Möglichkeit an, dieses Problem zu reproduzieren, und testen Sie bitte auf einem modernen Kernel. 3.10 wurde vor vier Jahren veröffentlicht, wir diskutieren darüber, ob es behoben ist oder teilweise auf einem Release von vor vier Tagen basiert.

@danielgusmao unsere RancherOS- und AWS ECS AMI-Linux-Betriebssysteme haben diesen "Fix" bereits installiert (war wahrscheinlich der Standard) und behebt das Problem für uns nicht. Wir sehen die Nachricht immer noch in den Protokollen. Die einzige Hoffnung ist wahrscheinlich, dass der Kernel-Patch weit zurückportiert wird. Obwohl ich mich umgesehen habe und in RedHat/Centos/AWS-Linux-Bugzillas und -Foren noch keine Anzeichen für ernsthafte Fortschritte in dieser Richtung sehen kann.

Um es klar zu sagen, die Nachricht selbst ist gutartig , es ist der Kernel-Absturz nach den vom OP gemeldeten Nachrichten, was nicht der Fall ist.

Der Kommentar im Code, aus dem diese Nachricht stammt, erklärt, was passiert. Grundsätzlich erhöht jeder Benutzer, z. B. der IP-Stack) eines Netzwerkgeräts (z. B. das Ende eines veth Paares in einem Container) einen Referenzzähler in der Netzwerkgerätestruktur, wenn er das Netzwerkgerät verwendet. Wenn das Gerät entfernt wird (z. B. wenn der Container entfernt wird), wird jeder Benutzer benachrichtigt, damit er einige Bereinigungen durchführen kann (z. B. offene Sockets schließen usw.), bevor der Referenzzähler verringert wird. Da diese Bereinigung einige Zeit in Anspruch nehmen kann, insbesondere unter hoher Last (viele Schnittstellen, viele Verbindungen usw.), kann der Kernel die Nachricht hier und da ab und zu ausgeben .

Wenn ein Benutzer eines Netzwerkgeräts den Referenzzähler nie verringert, wird ein anderer Teil des Kernels feststellen, dass die Aufgabe, die auf die Bereinigung wartet, hängen bleibt und abstürzt. Nur dieser Absturz weist auf einen Kernel-Bug hin (einige Benutzer haben über einen Codepfad den Referenzzähler nicht verringert). Es gab mehrere solcher Fehler und sie wurden im modernen Kernel behoben (und möglicherweise auf ältere zurückportiert). Ich habe einige Stresstests geschrieben (und schreibe sie weiter), um solche Abstürze auszulösen, konnte sie aber auf modernen Kerneln nicht reproduzieren (ich tue jedoch die obige Meldung).

Bitte melden Sie dieses Problem nur, wenn Ihr Kernel tatsächlich abstürzt, und dann wären wir sehr interessiert an:

• Kernel-Version (Ausgabe von uname -r )
• Linux-Distribution/Version
• Verwenden Sie die neueste Kernel-Version Ihres Linux-Anbieters?
• Netzwerkeinrichtung (Bridge, Overlay, IPv4, IPv6 usw.)
• Beschreibung der Arbeitslast (welche Art von Containern, welche Art von Netzwerklast usw.)
• Und idealerweise eine einfache Reproduktion

Vielen Dank

[ @thaJeztah könnten Sie den Titel in etwas wie kernel crash after "unregister_netdevice: waiting for lo to become free. Usage count = 3" ändern, um es deutlicher zu machen]

Sollte in Kernel 4.12 oder später behoben sein. Bitte prüfen. https://access.redhat.com/solutions/3105941
und Link zum Patch https://github.com/torvalds/linux/commit/d747a7a51b00984127a88113cdbbc26f91e9d815

@drweber Sie finden diesen Patch auch in kommenden stabilen Releases (vorerst 4.11.12, 4.9.39, 4.4.78, 3.18.62)

@rn

Wenn ein Benutzer eines Netzwerkgeräts den Referenzzähler nie verringert, wird ein anderer Teil des Kernels feststellen, dass die Aufgabe, die auf die Bereinigung wartet, hängen bleibt und abstürzt. Nur dieser Absturz weist auf einen Kernel-Bug hin (einige Benutzer haben über einen Codepfad den Referenzzähler nicht verringert). Es gab mehrere solcher Fehler und sie wurden im modernen Kernel behoben (und möglicherweise auf ältere zurückportiert). Ich habe einige Stresstests geschrieben (und schreibe sie weiter), um solche Abstürze auszulösen, konnte sie aber auf modernen Kerneln nicht reproduzieren (ich tue jedoch die obige Meldung).

Bitte melden Sie dieses Problem nur, wenn Ihr Kernel tatsächlich abstürzt ...

Wir haben ein etwas anderes Problem in unserer Umgebung, von dem ich hoffe, dass es etwas geklärt wird (Kernel 3.16.0-77-generic, Ubuntu 14.04, docker 1.12.3-0~trusty. Wir haben Tausende von Hosts, auf denen Docker, 2 . läuft -3 Container pro Host, und wir sehen dies bei < 1% der gesamten Hosts, auf denen Docker ausgeführt wird).

Wir sehen eigentlich nie den Kernel-Absturz, aber stattdessen (wie die ursprünglichen Reporter, soweit ich das beurteilen kann) ist der dockerd Prozess nicht mehr aktiv. Upstart (mit dem Job /etc/init/docker.conf aus dem Upstream-Paket) startet keinen neuen dockerd Prozess, weil er denkt, dass er bereits läuft ( start: Job is already running: docker ) und versucht, den Upstart zu stoppen Job schlägt ebenfalls fehl ( 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>

Da wir in dmesg hauptsächlich mit Bridge-Netzwerken (auf einem benutzerdefinierten Bridge-Gerät) arbeiten, sehen wir eine etwas andere Meldung bezüglich der virtuellen Schnittstelle:

[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

Da Upstart den Neustart von dockerd zu verweigern scheint oder erkennt, dass der zuvor laufende Prozess ein Zombie ist, ist die einzige Lösung, die wir gefunden haben, den Host neu zu starten.

Während unser Ergebnis anders aussieht (der Kernel stürzt nicht ab), klingt die Ursache gleich oder ähnlich. Ist das dann nicht das gleiche Problem? Gibt es eine bekannte Problemumgehung oder eine Möglichkeit, den Upstart-Job docker wieder lauffähig zu machen, wenn dies auftritt?

@campbellr Ich kann dieses Problem mit Ihrem Ansatz auf Kernel 4.12.2-1 reproduzieren.
Übrigens, wenn ich den NFS-Speicher unmounte, bevor der Container gestoppt wird, tritt dieses Problem nicht auf.

gleiches Problem.

[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

Hi,

Ich habe gerade 2 Repos https://github.com/piec/docker-samba-loop und https://github.com/piec/docker-nfs-loop erstellt , die das notwendige Setup enthalten, um diesen Fehler zu reproduzieren

Meine Ergebnisse:

• 4.11.3-1-ARCH (Arch Linux) Kernel: Ich generiere den Fehler mit docker-samba-loop in einigen Iterationen (<10). Ich kann es nicht reproduzieren mit docker-nfs-loop
• 4.11.9-1-ARCH gleiche Ergebnisse ( Versionen )
• 4.12.3-1-ARCH (Test-Repo) gleiche Ergebnisse
• 4.11.11-coreos: gleiche Ergebnisse für docker-samba-loop , docker-nfs-loop nicht ausprobiert

Hoffe das hilft
Danke schön

Ein Workaround ist, in meinem Fall --net=host zu verwenden. Aber es ist nicht immer eine akzeptable Lösung

@piec , vielen Dank für die Details. Am Ende dieses sehr langen Kommentars habe ich noch ein paar Fragen an Sie.

Mit dem SMB-Setup konnte ich eine Reihe von Dingen mit verschiedenen Kerneln produzieren. Ich habe dies auch mit dem NFS-Setup versucht, aber keine Würfel.

Alle Tests werden mit Docker 17.06.1-ce auf HyperKit mit einer VM ausgeführt, die mit 2 vCPUs und 2 GB Arbeitsspeicher konfiguriert ist (über Docker für Mac, aber das sollte keine Rolle spielen). Ich verwende LinuxKit-Kernel, weil ich sie leicht austauschen kann.

Ich habe Ihr Dockerfile modifiziert, indem ich als ersten ausgeführten Befehl einen Aufruf zu date hinzugefügt habe und auch einen Aufruf zu date vor und nach dem docker run für die Klient.

Experiment 1 (4.9.39 Kernel)

Mit 4.9.39 (neuester stabiler 4.9.x-Kernel) bekomme ich einen Kernel-Absturz:

# 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

und in 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..

Manchmal sehe ich mehrere Iterationen dessen, was der 4.11.12-Kernel tut, einschließlich der unregister_netdevice Meldungen (siehe unten) und bekomme dann den Kernel-Absturz oben. Manchmal sehe ich leichte Variationen für den Absturz, wie zum Beispiel:

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

Die Abstürze sind im Unix-Domain-Socket-Code und ähnlich/identisch mit dem, was ist
berichtet hier , obwohl es mit diesem neuen Testfall viel einfacher zu reproduzieren ist.

Experiment 2 (4.11.12 Kernel)

Mit 4.11.12 (das ist das neueste Stable in der 4.11-Serie) sehe ich keine Abstürze, aber es ist wirklich langsam (Anmerkungen inline mit ---> ):

# 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

Ich ließ dies ungefähr eine Stunde lang laufen, wobei sich das gleiche Muster wiederholte, aber kein Kernel-Absturz.

In den Kernel-Logs sehe ich viele:

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

Das ist eine Nachricht alle zehn Sekunden.

Da dies nicht dazu führt, dass die Erkennung hängender Aufgaben auch nach einer Stunde einsetzt, vermute ich, dass mit 4.11.12 der Referenzzähler schließlich dekrementiert und das Gerät freigegeben wird, aber nach den Intervallen, in denen ich Container ausführen kann, kann es dauern bis zu 4 Minuten!

Experiment 3 (4.11.12 Kernel)

Der Kernel-Absturz im OP zeigte an, dass der Kernel abgestürzt ist, weil eine aufgehängte Aufgabe erkannt wurde. Ich habe diesen Absturz bei meinen Tests nicht gesehen, daher habe ich die Einstellung sysctl Bezug auf die Erkennung hängender Aufgaben geändert:

# 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

Dies reduziert das Timeout auf 60 Sekunden und versetzt den Kernel in Panik, wenn ein hängender Task erkannt wurde. Da es etwa 2 Minuten dauert, bis sich dockerd beschwert hat, dass containerd nicht gestartet wurde, sollte die Reduzierung der Erkennung hängender Aufgaben auf 60s eine Kernel-Panik auslösen, wenn eine einzelne Aufgabe hängen blieb. Leider gab es keinen Absturz in den Protokollen

Experiment 4 (4.11.12 Kernel)

Als nächstes erhöhe ich die sleep nach jedem docker run auf 5 Minuten, um zu sehen, ob die Nachrichten kontinuierlich sind. In diesem Fall scheinen alle docker run s zu funktionieren, was irgendwie zu erwarten ist, da aus den vorherigen Experimenten ein docker run alle 4 Minuten oder so funktionieren würde

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

Es sieht so aus, als würden wir auf fast jedem docker run ungefähr 200 Sekunden im Wert von unregister_netdevice docker run (außer dem zweiten). Ich vermute, dass wir während dieser Zeit keine neuen Container starten können (wie in Experiment 2 gezeigt). Es ist merkwürdig, dass die Erkennung hängender Aufgaben nicht aktiviert wird, vermutlich weil keine Aufgabe hängen ist.

Experiment 5 (4.11.12/4.9.39 mit einer zusätzlichen Debugging-Aktivierung im Kernel)

Dies ist das Zurückkehren in 1s Schlaf zwischen docker run

Wir haben einen anderen Kernel, der eine Reihe zusätzlicher Debugs ermöglichte
Optionen wie LOCKDEP , RCU_TRACE , LOCKUP_DETECTOR und ein paar
mehr.

Das Ausführen des Repro-Kernels 4.11.12 mit diesen aktivierten Debug-Optionen hat nichts ausgelöst.

Dito für den Kernel 4.9.39, wo der normale Kernel abstürzt. Die Debug-Optionen ändern das Timing geringfügig, so dass dies möglicherweise ein zusätzlicher Hinweis darauf ist, dass der Absturz im Unix-Domain-Socket-Code auf ein Rennen zurückzuführen ist.

Ein bisschen tiefer graben

strace bei den verschiedenen containerd Prozessen ist nicht hilfreich (es
normalerweise nicht, weil es in Go geschrieben ist). Viele lange Stände in
futex(...FUTEX_WAIT...) mit Informationen zum Wo/Warum.

Einige stöbern mit sysrq herum:

Erhöhen Sie die Ausführlichkeit:

echo 9 > /proc/sysrq-trigger

Stacktrace von allen CPUs:

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

Nichts hier, CPU1 ist im Leerlauf, CPU0 verarbeitet die sysrq.

Gesperrte Aufgaben anzeigen (zweimal)

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

Dies zeigt, dass sowohl die Arbeitswarteschlangen netns als auch cleanup_net beschäftigt sind. Ich habe hier vor einiger Zeit ein etwas verwandtes Problem cleanup_net Arbeitswarteschlange in einem anderen Zustand.

Zusammenfassung

• Ich denke, der Absturz bei 4.9.x-Kerneln hat nichts damit zu tun, scheint aber in 4.11.x behoben zu sein. Dies erfordert etwas mehr Triage.
• Im Gegensatz zu einigen früheren Berichten werden keine aufgehängten Tasks gemeldet, aber es ist schwer zu sagen, da es zu diesem Problem nur sehr wenige Stack-Traces gibt.
• Etwas ist sehr lange blockiert (2-4 Minuten). Es hängt wahrscheinlich mit dem Status der Arbeitswarteschlange zusammen
• Der Dump der Arbeitswarteschlange erfordert mehr Analyse, insbesondere warum die Arbeitswarteschlange so lange in diesem Zustand bleibt.
• Die unregister_netdev Meldungen scheinen nichts mit dem letzten Fix zu tun zu haben (der sowohl in 4.9.39 als auch in 4.11.12) enthalten ist. Dies liegt möglicherweise daran, dass die cleanup_net Arbeitswarteschlange nicht voranschreitet und daher die Nachricht gedruckt wird.
• Es ist völlig unklar, wie / warum SMB dies auslöst. Ich habe ungefähr 60 ungerade Stresstests für Netzwerk-Namespaces und verschiedene Workloads geschrieben und konnte keine Probleme auslösen. Die Tests basierten auf runc , vielleicht sollte ich containerd versuchen.

Ich werde noch ein bisschen graben und dann eine Zusammenfassung an netdev senden.

@piec hast du Konsolenzugriff und kannst sehen, ob es etwas in Bezug auf Crash-Dump gibt oder siehst du auch nur riesige Verzögerungen, wie ich sehe? Wenn Sie einen Crash-Dump haben, wäre ich sehr daran interessiert, ihn zu sehen. Laufen Sie auch auf Bare Metal oder in einer VM? Wie sieht Ihre Konfiguration in Bezug auf CPUs und Speicher aus?

@rn danke für die Untersuchungen!

Ich laufe auf einem Bare-Metal-Desktop-PC, damit ich auf alles zugreifen kann. Es ist ein i7-4790K + 32 GiB.
Aktuell laufe ich auf einem aktuellen Arch Linux + Kernel aus dem Testing Repo (4.12.3-1-ARCH)

In meinem Fall verhält sich alles so, wie Sie es in Ihrem Experiment 2 (4.11.12 Kernel) beschreiben:

• Nachdem der client-smb-Container existiert, ist das Ausführen neuer Container für 4+ Minuten nicht möglich.
• Ich habe nie Kernel-Abstürze
• Die Meldung unregister_netdevice: waiting for lo to become free. Usage count = 1 wiederholt angezeigt, wenn ich versuche, einen neuen Container in der Verzögerung von mehr als 4 Minuten auszuführen, nachdem der Client-smb beendet wurde. Und erscheint nur, wenn Sie in diesen 4 Minuten einen neuen Container ausführen. Das Ausführen eines neuen Containers nach diesen 4 Minuten ist "normal"

Ich nehme an, es gibt irgendwo beim Bereinigungsprozess des smb-client-Containers ein Problem im Zusammenhang mit Netzwerkschnittstellen

Es gibt tatsächlich eine viel einfachere Reproduktion dieses Problems (was übrigens nicht das ursprüngliche Problem ist).

Dieses Skript startet einfach einen SMB-Server auf dem Host und erstellt dann einen Netzwerk-Namespace mit einem veth Paar, führt mount; ls; unmount im Netzwerk-Namespace aus und entfernt dann den Netzwerk-Namespace.

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

Beachten Sie, dass das Hinzufügen eines einfachen sleep 1 nach dem Unmount, entweder bei der Ausführung im Namespace oder vor dem Löschen des Netzwerk-Namespace, funktioniert, ohne beim Erstellen des neuen Namespace zu stoppen. Ein Sleep nach dem Löschen des alten Namespace reduziert das Abwürgen nicht.

@piec Ich habe dies auch mit deinem Repro und einem sleep 1 im Dockerfile nach dem Unmounten getestet und alles funktioniert wie erwartet, kein Abwürgen, keine unregister_netdev Meldungen.

Ich schreibe das jetzt auf und sende es an netdev@vger

Exzellent
Ich bestätige, dass ein sleep nach dem Unmounten von Fixes ins Stocken geraten und unregister_netdev in meinem Setup angezeigt wird

Glaubst du nicht, dass umount eine asynchrone Aktion in Bezug auf ihre Netns generiert, die blockiert und schließlich abläuft, wenn die Netns entfernt wird, bevor diese Aktion beendet ist? Ein Schlaf nach dem Mounten würde dieses Zeug beenden lassen, bevor die Netns entfernt werden.
Aber das ist nur eine Hypothese

Ich habe es ohne Unmount versucht, der gleiche Unterschied. Es ist das Löschen des Netzwerk-Namespace. Diese 9 und das Entfernen des Mount-Namespaces lösen das Unmounten trotzdem aus.

Ah okay

Übrigens habe ich das Problem versehentlich (während der Entwicklung) auf einem anderen Computer mit smb wieder reproduziert. Es ist ein Ubuntu 16.04 PC, Linux 4.4.0-77-generic. Und es gibt eine hängende Task-Rückverfolgung, die interessant sein könnte. Kein Absturz und gleiche ~4 Minuten Verzögerung.

[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

Der netdev@vger- Thread ist hier https://www.mail-archive.com/[email protected]/msg179703.html wenn jemand den Fortschritt verfolgen möchte.

@piec ja, das wird erwartet.

Ich bin auch auf diesen Fehler gestoßen und konnte Oopses mit der docker-samba-loop-Methode von @piec auf den Ubuntu-Kernel-Images

• 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

Ich habe meine Ergebnisse dem Ubuntu-Fehlerbericht hinzugefügt: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407 und https://github.com/fho/docker-samba-loop

@fho danke. Sie benötigen eigentlich überhaupt keinen Docker zum Repro, nur das Ausführen des Samba-Clients in einem Netzwerk-Namespace genügt gemäß https://github.com/moby/moby/issues/5618#issuecomment -318681443

@rn danke für die Info. So habe ich es noch nicht probiert.

Die letzten Posts hier und auf der netdev-Mailingliste scheinen sich nur um Kernel-Stalls zu drehen.
Ich habe auch Kernel-Abstürze mit Kernel 4.11 und 4.12.

Ich sehe ein Problem, das diesem sehr ähnlich ist (wie in #35068 beschrieben). Wir betreiben im Grunde einen Schwarm mit zwei Knoten, der einen einzelnen Dienst mit 4 Replikaten unter Verwendung einer Spread-Placement-Strategie ausführt.

In jedem dieser Service-Container mounten wir den Host docker.sock als Volume, und innerhalb des Containers führen wir docker run Befehle mit einer maximalen Parallelität von 4 pro Container aus. Dies führt dazu, dass bis zu 4 Container gleichzeitig erstellt und anschließend über -rm sofort entfernt werden.

Zusätzliche Kernel-Logs und Beispiele zu ARMv7 in der obigen Referenz.

ip6_route_dev_notify Panik ist für uns ein ernstes Problem.

Ich denke, wenn man sich das etwas genauer ansieht, ist dies definitiv NICHT der gleiche Fehler wie:

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

Ich denke, dies ist ein Problem im Upstream im Kernel mit der IPv6-Schicht.

Diese Informationen können relevant sein.

Wir können das Problem mit _unregister_netdevice reproduzieren: warten, bis lo frei wird. Nutzungszähler = 1_ mit 4.14.0-rc3-Kernel mit _CONFIG_PREEMPT_NONE=y_ und nur auf einer CPU mit folgenden Boot-Kernel-Optionen ausgeführt:

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

Sobald wir diesen Zustand erreichen, bleibt er in diesem Zustand und ein Neustart ist erforderlich. Es können keine Container mehr gespawnt werden. Wir reproduzieren es, indem wir Bilder ausführen, die ipsec/openvpn-Verbindungen herstellen + eine kleine Datei in den Tunneln herunterladen. Dann existieren die Instanzen (normalerweise laufen sie < 10s). Wir lassen 10 solcher Container pro Minute auf einer Maschine laufen. Mit den oben genannten Einstellungen (nur 1cpu) schafft es die Maschine in ~2 Stunden.

Ein anderer Reproduzierer mit dem gleichen Kernel, aber ohne Begrenzung der Anzahl der CPUs, soll iperf einfach 3 Sekunden im UDP-Modus innerhalb des Containers laufen lassen (es gibt also überhaupt keine TCP-Kommunikation). Wenn wir 10 solcher Container parallel ausführen, warten, bis alle fertig sind, und es erneut tun, haben wir das Problem in weniger als 10 Minuten (auf einer Maschine mit 40 Kernen).

In unseren beiden Reproduzierern haben wir "ip route flush table all; ifconfigNieder; 10" schlafen, bevor sie aus Containern existieren. Es scheint keine Auswirkungen zu haben.

Hi,

Nur um das Feuer noch zu verstärken, sehen wir auch dieses Problem, wie hier angefordert...

Kernel-Version: 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-Distribution/Version: Debian 9.1 (mit allen aktuellen Paketen)

Verwenden Sie die neueste Kernel-Version Ihres Linux-Anbieters? Jawohl

Netzwerk-Setup (Bridge, Overlay, IPv4, IPv6 usw.): Nur IPv4, NATed als Standard-Docker-Setup

Beschreibung der Arbeitslast (welche Art von Containern, welche Art von Netzwerklast usw.): Sehr kurzlebige Container (von wenigen Sekunden bis zu einigen Minuten), die Skripte ausführen, bevor sie beendet werden.

Und idealerweise eine einfache Reproduktion:

**kernel:[617624.412100] unregister_netdevice: wartet darauf, dass lo frei wird. Nutzungsanzahl = 1

Konnte alte Container nicht beenden oder neue auf den betroffenen Knoten starten, musste neu gestartet werden, um die Funktionalität wiederherzustellen.**

Hoffentlich finden wir bald eine Ursache/einen Patch.

Mit freundlichen Grüßen,

robputt796

@campbellr
stimmte zu, dass es etwas mit Netzwerkspeicher zu tun zu haben scheint. Ich verwende ceph krbd als persistentes Volume in Kubernetes.
Und ich kann die Situation nach einem lang andauernden Container-Absturz reproduzieren.

Das Problem wurde vor 10 Tagen zugewiesen und ist in Arbeit. Weitere Informationen zu den Vorgängen finden Sie hier https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407

Hoffentlich findet Dan Streetman heraus, wie man das Problem beheben kann

Es stellt sich heraus, dass das Oops durch einen Kernel-Fehler verursacht wird, der durch den Commit 76da0704507bbc51875013f6557877ab308cfd0a behoben wurde:

ipv6: ip6_route_dev_notify() nur einmal für NETDEV_UNREGISTER aufrufen

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76da0704507bbc51875013f6557877ab308cfd0a
(Es behebt lediglich die Kernel-Panik, nicht das Problem "kernel:unregister_netdevice: wait for lo to be free. Usage count = 2".)

(hier noch einmal wiederholen, da GitHub alte Kommentare versteckt)

Wenn Sie hier ankommen

Das hier diskutierte Problem ist ein Kernel-Bug und wurde noch nicht vollständig behoben. Einige Patches wurden in den Kernel eingefügt, die _einige_ Vorkommen dieses Problems beheben, aber andere sind noch nicht behoben.

Es gibt eine Reihe von Optionen, die für _manche_ Situationen hilfreich sein können, aber nicht für alle (wiederum; höchstwahrscheinlich handelt es sich um eine Kombination von Problemen, die denselben Fehler auslösen).

Hinterlasse keine "Das habe ich auch"-Kommentare

"Ich habe das auch" hilft nicht, den Fehler zu beheben. Hinterlassen Sie nur einen Kommentar, wenn Sie Informationen haben, die zur Lösung des Problems beitragen können (in diesem Fall ist die Bereitstellung eines Patches für den Kernel-Upstream möglicherweise der beste Schritt).

Wenn Sie wissen möchten, dass Sie auch dieses Problem haben , verwenden Sie

Wenn Sie über Updates informiert bleiben möchten, verwenden Sie den _Abonnieren-Button_.

Jeder Kommentar hier sendet eine E-Mail / Benachrichtigung an über 3000 Personen. Ich möchte die Konversation zu diesem Thema nicht abschließen, da es noch nicht gelöst ist, aber möglicherweise gezwungen wird, wenn Sie dies ignorieren.

Ich werde Kommentare entfernen, die keine nützlichen Informationen hinzufügen, um den Thread (etwas) zu kürzen

Wenn Sie bei der Lösung dieses Problems helfen möchten

• Lesen Sie den ganzen Thread; es ist lang und github blendet Kommentare aus (Sie müssen also klicken, um diese wieder sichtbar zu machen). In diesem Thread sind bereits viele Informationen vorhanden, die Ihnen möglicherweise helfen könnten
• Lesen Sie diesen Kommentar https://github.com/moby/moby/issues/5618#issuecomment -316297818 (und Kommentare zu dieser Zeit) für Informationen, die hilfreich sein können.

Vielen Dank!

Ich glaube, ich habe dieses Problem behoben, zumindest wenn es durch eine Kernel-TCP-Socket-Verbindung verursacht wurde. Test-Kernel für Ubuntu sind verfügbar und ich würde mich über Feedback freuen, wenn sie dies für jeden hier helfen / beheben. Patch wird stromaufwärts übermittelt; Weitere Details sind im LP-Bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/comments/46

Es tut uns leid, die Feier zu verderben, aber wir konnten das Problem reproduzieren. Wir arbeiten jetzt mit @ddstreet daran unter https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/ .

Gibt es keine Problemumgehungen?

Verwenden Sie Hostnetzwerke (was einen Großteil des Wertes von Containern zerstört, aber los geht's).

@pumba-lt Wir hatten dieses Problem vor etwa 1,5 Jahren, vor etwa einem Jahr habe ich IPv6 auf Kernel-Ebene (nicht sysctl) deaktiviert und hatte das Problem nicht einmal. Ausführen eines Clusters von 48 Blades.

Normalerweise in: /etc/default/grub
GRUB_CMDLINE_LINUX="xxxxx ipv6.disable=1"

Ich verwende jedoch PXE-Boot, daher hat meine PXE-Konfiguration:

      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

Ich versichere Ihnen, Sie werden dieses Problem nicht mehr sehen.

Bitte haben Sie Verständnis dafür, dass dies ein häufiges SYMPTOM ist, das viele Ursachen hat. Was für Sie funktioniert hat, um dies zu vermeiden, funktioniert möglicherweise nicht für jemand anderen.

Ich kann bestätigen, dass unsere Probleme behoben wurden, nachdem IPv6 beim Booten deaktiviert wurde (aus der Konfigurationsdatei von Grub). Hatte zahlreiche Probleme in einem 7-Knoten-Cluster, läuft jetzt reibungslos.

Ich weiß nicht mehr, wo ich die Lösung gefunden habe, oder habe ich sie trotzdem selbst gefunden, danke @qrpike , dass hast :) !!

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

begehen edaafa805e0f9d09560a4892790b8e19cab8bf09
Autor: Dan Streetman [email protected]
Datum: Do 18. Jan. 16:14:26 2018 -0500

net: tcp: close sock if net namespace is exiting


[ Upstream commit 4ee806d51176ba7b8ff1efd81f271d7252e03a1d ]

When a tcp socket is closed, if it detects that its net namespace is
exiting, close immediately and do not wait for FIN sequence.

For normal sockets, a reference is taken to their net namespace, so it will
never exit while the socket is open.  However, kernel sockets do not take a
reference to their net namespace, so it may begin exiting while the kernel
socket is still open.  In this case if the kernel socket is a tcp socket,
it will stay open trying to complete its close sequence.  The sock's dst(s)
hold a reference to their interface, which are all transferred to the
namespace's loopback interface when the real interfaces are taken down.
When the namespace tries to take down its loopback interface, it hangs
waiting for all references to the loopback interface to release, which
results in messages like:

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

These messages continue until the socket finally times out and closes.
Since the net namespace cleanup holds the net_mutex while calling its
registered pernet callbacks, any new net namespace initialization is
blocked until the current net namespace finishes exiting.

After this change, the tcp socket notices the exiting net namespace, and
closes immediately, releasing its dst(s) and their reference to the
loopback interface, which lets the net namespace continue exiting.

Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=97811
Signed-off-by: Dan Streetman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

Die Verwendung von SCTP in netns könnte dies ebenfalls auslösen, Korrekturen in 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

immer noch passiert "unregister_netdevice: Warten auf eth0 wird frei. Usage count = 1" obwohl ich die Kernel-Version auf 4.4.118 und Docker-Version 17.09.1-ce aktualisiert habe ，vielleicht sollte ich versuchen, IPv6 auf Kernel-Ebene zu deaktivieren. Hoffe, es Cloud-Arbeit.

@wuming5569 Bitte lassen Sie mich wissen, ob es mit dieser Linux-Version für Sie funktioniert hat

@wuming5569 Vielleicht aktualisieren Sie den Kernel 4.4.114, beheben Sie "unregister_netdevice: Warten, bis lo frei wird. Nutzungszähler = 1", nicht für "unregister_netdevice: Warten, bis eth0 frei wird. Nutzungszähler = 1".
Ich habe in der Produktion getestet.
@ddstreet Dies ist ein Feedback, irgendeine Hilfe?

@wuming5569 Wie oben erwähnt, sind die Nachrichten selbst gutartig, können jedoch schließlich dazu führen, dass der Kernel hängt. Hängt Ihr Kernel und wenn ja, wie sieht Ihr Netzwerkmuster aus, dh welche Art von Netzwerk betreiben Ihre Container?

Hatte das gleiche Problem auf CentOS. Mein Kernel ist 3.10.0-693.17.1.el7.x86_64. Aber ich habe in Syslog keinen ähnlichen Stack-Trace erhalten.

Gleiches auf Centos7-Kernel 3.10.0-514.21.1.el7.x86_64 und Docker 18.03.0-ce

@danielefranceschi Ich empfehle Ihnen, auf den neuesten CentOS-Kernel (mindestens 3.10.0-693) zu aktualisieren. Es wird das Problem nicht lösen, aber es scheint viel seltener zu sein. In den Kerneln 3.10.0-327 und 3.10.0-514 haben wir den Stack-Trace gesehen, aber meiner Erinnerung nach haben wir in 3.10.0-693 keinen davon gesehen.

@alexhexabeam 3.10.0-693 scheint einwandfrei zu funktionieren, tnx :)

Gleiches auf CentOS7-Kernel 4.16.0-1.el7.elrepo.x86_64 und Docker 18.03.0-ce

Es funktionierte wochenlang vor dem Absturz und als es versucht wurde, hochzufahren, blieb es vollständig hängen.

Das Problem trat auch mit Kernel 3.10.0-693.21.1.el7 auf

Ich kann bestätigen, dass es auch passiert auf:

Linux 3.10.0-693.17.1.el7.x86_64
Red Hat Enterprise Linux Server-Version 7.4 (Maipo)

Ich kann es reproduzieren, indem ich "Service Docker-Neustart" durchführe, während ich eine bestimmte Last habe.

@wuming5569 Haben Sie dieses Problem behoben? Was ist Ihr Netzwerktyp? wir sind seit Wochen von diesem Problem verwirrt.
Haben Sie ein Wechat-Konto?

4admin2root, angesichts des von Ihnen erwähnten Fixes https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.114 ,

Ist es sicher, den Userland-Proxy für den Docker-Daemon zu deaktivieren, wenn der richtige aktuelle Kernel installiert ist? Es ist nicht ganz klar, ob es von

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

Da beide älter sind als der Kernel-Fix

Dankeschön

wir sind seit Wochen von diesem Problem verwirrt.
Linux 3.10.0-693.17.1.el7.x86_64
CentOS Linux-Version 7.4.1708 (Kern)

Kann jemand bestätigen, ob der neueste 4.14-Kernel dieses Problem hat? Scheint nicht so zu sein. Niemand im Internet hatte dieses Problem mit dem 4.14-Kernel.

Ich sehe dies im Kernel 4.15.15-1, Centos7

Wenn man sich die Änderungsprotokolle ansieht, hat https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.15.8 einen Fix für SCTP, aber nicht für TCP. Sie können also die neueste Version 4.14 ausprobieren.

• selbst 4.15.18 hilft nicht bei diesem Fehler
• IPv6 deaktivieren hilft auch nicht

wir haben jetzt auf 4.16.13 aktualisiert. Beobachten. Dieser Fehler traf uns nur ungefähr einmal pro Woche auf einem Knoten.

Haben Sie IPv6 in Grub-Boot-Parametern oder sysctl deaktiviert? Nur Bootparameter funktionieren. Sysctl wird es nicht beheben.

Am 4. Juni 2018 um 12:09:53 schrieb Sergey Pronin ( [email protected] (mailto:[email protected])):

selbst 4.15.18 hilft nicht bei diesem Fehler
IPv6 deaktivieren hilft auch nicht

wir haben jetzt auf 4.16.13 aktualisiert. Beobachten. Dieser Fehler traf uns nur ungefähr einmal pro Woche auf einem Knoten.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an (https://github.com/moby/moby/issues/5618#issuecomment-394410321) oder schalten Sie den Thread stumm (https://github.com/notifications/unsubscribe-auth /AAo3HLYI_jnwjgtQ0ce-E4mc6Em5yeISks5t5VvRgaJpZM4B4L4Z).

für mich taucht der Fehler meistens auf, nachdem das gleiche Projekt/Netzwerk erneut bereitgestellt wurde

@qrpike du hast recht, wir haben es nur mit sysctl versucht. Lass es mich mit Grub versuchen. Vielen Dank!

4.9.88 Debian-Kernel. Reproduzierbar.

@qrpike du hast recht, wir haben es nur mit sysctl versucht. Lass es mich mit Grub versuchen. Vielen Dank!

In meinem Fall hat das Deaktivieren von IPv6 keinen Unterschied gemacht.

@spronin-aurea Hat das Deaktivieren von IPv6 beim Bootloader geholfen?

@qrpike Können Sie uns etwas über die von Ihnen verwendeten Knoten sagen, wenn die Deaktivierung von IPv6 in Ihrem Fall geholfen hat? Kernel-Version, k8s-Version, CNI, Docker-Version usw.

@komljen Ich habe CoreOS in den letzten 2 Jahren ohne einen einzigen Vorfall verwendet. Seit ~ver 1000. Ich habe es in letzter Zeit nicht ausprobiert, aber wenn ich IPv6 nicht deaktiviere, tritt der Fehler auf.

Auf meiner Seite verwende ich auch CoreOS, IPv6 mit Grub deaktiviert und das Problem tritt immer noch auf

@deimosfr Ich verwende derzeit PXE-Boot für alle meine Knoten:

      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

Mein Hauptknoten, der der PXE-Host ist, ist jedoch auch CoreOS und bootet von der Festplatte und hat das Problem auch nicht.

Welche Kernel-Versionen laufen bei euch?

Die, bei denen ich das Problem bekam, waren auf 4.14.32-coreos und davor. Dieses Problem tritt bei 4.14.42-coreos noch nicht auf

Centos 7.5 mit 4.17.3-1-Kernel hat das Problem immer noch.

Umgebung:
Kubernetes 1.10.4
Docker 13.1
mit Flanell-Netzwerk-Plugin.

Protokoll :
[ 89.790907] IPv6: ADDRCONF(NETDEV_UP): eth0: Link ist nicht bereit
[ 89.798523] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: Link wird bereit
[ 89.799623] cni0: Port 8(vethb8a93c6f) trat in den Sperrzustand ein
[ 89.800547] cni0: Port 8(vethb8a93c6f) ist in den deaktivierten Zustand übergegangen
[ 89.801471] Gerät vethb8a93c6f wechselte in den Promiscuous-Modus
[ 89.802323] cni0: Port 8(vethb8a93c6f) ist in den Sperrzustand eingetreten
[ 89.803200] cni0: Port 8(vethb8a93c6f) hat den Weiterleitungsstatus erreicht

kernel:unregister_netdevice : Warten, bis lo frei wird. Nutzungszähler = 1。

Jetzt :
Die Knoten-IP kann Netzwerkdienste wie ssh erreichen, aber nicht verwenden.

Die Symptome hier ähneln vielen Berichten an verschiedenen anderen Stellen. Alles was mit Netzwerk-Namespaces zu tun hat. Könnten die Leute, die darauf stoßen, bitte sehen, ob unshare -n hängt, und wenn ja, von einem anderen Terminal aus cat /proc/$pid/stack des Unshare-Prozesses durchführen, um zu sehen, ob es in copy_net_ns() hängt? Dies scheint ein gemeinsamer Nenner für viele der Probleme zu sein, einschließlich einiger hier gefundener Rückverfolgungen. Zwischen 4.16 und 4.18 gab es eine Reihe von Patches von Kirill Tkhai, die das betroffene Locking stark überarbeitet haben. Die betroffenen Distributions-/Kernel-Paketbetreuer sollten wahrscheinlich versuchen, sie auf stabile Kernel anzuwenden/zurückportieren und sehen, ob das hilft.
Siehe auch: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779678

@Blub

sudo cat /proc/122355/stack
[<ffffffff8157f6e2>] copy_net_ns+0xa2/0x180
[<ffffffff810b7519>] create_new_namespaces+0xf9/0x180
[<ffffffff810b775a>] unshare_nsproxy_namespaces+0x5a/0xc0
[<ffffffff81088983>] SyS_unshare+0x193/0x300
[<ffffffff816b8c6b>] tracesys+0x97/0xbd
[<ffffffffffffffff>] 0xffffffffffffffff

Angesichts der Locking-Änderungen in 4.18 wäre es gut, die aktuelle 4.18rc zu testen, vor allem, wenn Sie sie mehr oder weniger zuverlässig auslösen können, da meiner Meinung nach viele Leute das Ändern von Kernel-Versionen auch die Wahrscheinlichkeit dafür verändert haben viel.

Ich hatte dieses Problem mit Kubernetes und nach dem Wechsel auf die neueste stabile CoreOS-Version - 1745.7.0 ist das Problem behoben:

• Kernel: 4.14.48
• Docker: 18.03.1

gleiches Problem bei CentOS 7

• Kernel: 4.11.1-1.el7.elrepo.x86_64
• Docker: 17.12.0-ce

@Blub Sehe das gleiche auf CoreOS 1688.5.3, Kernel 4.14.32

ip-10-72-101-86 core # cat /proc/59515/stack
[<ffffffff9a4df14e>] copy_net_ns+0xae/0x200
[<ffffffff9a09519c>] create_new_namespaces+0x11c/0x1b0
[<ffffffff9a0953a9>] unshare_nsproxy_namespaces+0x59/0xb0
[<ffffffff9a07418d>] SyS_unshare+0x1ed/0x3b0
[<ffffffff9a003977>] do_syscall_64+0x67/0x120
[<ffffffff9a800081>] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[<ffffffffffffffff>] 0xffffffffffffffff

Theoretisch kann es irgendwo einen oder mehrere andere Traces geben, die eine der Funktionen von net_namespace.c enthalten, die net_mutex ( cleanup_net , net_ns_barrier , net_ns_init , {,un}register_pernet_{subsys,device} ). Für stabile Kernel wäre es natürlich viel einfacher, wenn es eine bestimmte Sache gäbe, die sich beheben ließe, als alle Locking-Änderungen von 4.18 zurück zu portieren. Aber bisher habe ich keine Spur gesehen, die zur Ursache führt. Ich weiß nicht, ob es hilft, aber vielleicht sind andere /proc/*/stack s mit den oben genannten Funktionen sichtbar, wenn das Problem auftritt?

gleicher Fehler ! und mein env ist debian 8

RHEL, SCHWARM, 18.03.0-ce

1. Verbindung zum Managerknoten über ssh . herstellen

2. Manuelles Starten eines Containers auf einem Managerknoten:

   sudo docker run -it -v /import:/temp/eximport -v /home/myUser:/temp/exhome docker.repo.myHost/ fedora:23 /bin/bash

3. Nach einiger Zeit nichts tun:

   [ root@8a9857c25919 myDir]#
   Nachricht von syslogd@se1-shub-t002 am 19. Juli 11:56:03 ...
   kernel:unregister_netdevice : Warten, bis lo frei wird. Nutzungsanzahl = 1

Nach Minuten bin ich wieder auf der Konsole des Managerknotens und der gestartete Container läuft nicht mehr.

Beschreibt dies das gleiche Problem oder ist dies eine andere "Problemsuite"?

THX im Voraus!

AKTUALISIEREN
Dies geschieht auch direkt auf der ssh-Konsole (auf der Swarmmanager-Bash).

AKTUALISIEREN
Host-Rechner (ein Manager-Knoten im Schwarm):
Linux [MACHINENNAME] 3.10.0-514.2.2.el7.x86_64 #1 SMP Mi 16. Nov 13:15:13 EST 2016 x86_64 x86_64 x86_64 GNU/Linux

Wenn dies nach einiger Zeit nicht behoben wird, ist dies ein anderes Problem.

Gleiches auf CentOS7.5 Kernel 3.10.0-693.el7.x86_64 und Docker 1.13.1

Das gleiche Problem OEL 7,5
uname -a
4.1.12-124.16.1.el7uek.x86_64 #2 SMP Mo 11. Juni 20:09:51 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
Docker-Infos
Behälter: 9
Laufen: 5
Angehalten: 0
Gestoppt: 4
Bilder: 6
Serverversion: 17.06.2-ol

dmesg
[2238374.718889] unregister_netdevice: Warten darauf, dass lo frei wird. Nutzungsanzahl = 1
[2238384.762813] unregister_netdevice: Warten darauf, dass lo frei wird. Nutzungsanzahl = 1
[2238392.792585] eth0: umbenannt von vethbed6d59

(diese https://github.com/moby/moby/issues/5618#issuecomment-351942943 hier noch einmal wiederholen, da GitHub alte Kommentare versteckt)

Wenn Sie hier ankommen

Das hier diskutierte Problem ist ein Kernel-Bug und wurde noch nicht vollständig behoben. Einige Patches wurden in den Kernel eingefügt, die _einige_ Vorkommen dieses Problems beheben, aber andere sind noch nicht behoben.

Es gibt eine Reihe von Optionen, die für _manche_ Situationen hilfreich sein können, aber nicht für alle (wiederum; höchstwahrscheinlich handelt es sich um eine Kombination von Problemen, die denselben Fehler auslösen).

Der Fehler "unregister_netdevice: Warten darauf, dass lo frei wird" selbst ist nicht der Fehler

Wenn der Kernel _nach_ abstürzt, ist das ein Fehler (siehe unten)

Hinterlasse keine "Das habe ich auch"-Kommentare

"Ich habe das auch" hilft nicht, den Fehler zu beheben. Hinterlassen Sie nur einen Kommentar, wenn Sie Informationen haben, die zur Lösung des Problems beitragen können (in diesem Fall ist die Bereitstellung eines Patches für den Kernel-Upstream möglicherweise der beste Schritt).

Wenn Sie wissen möchten, dass Sie auch dieses Problem haben , verwenden Sie

Wenn Sie über Updates informiert bleiben möchten, verwenden Sie den _Abonnieren-Button_.

Jeder Kommentar hier sendet eine E-Mail / Benachrichtigung an über 3000 Personen. Ich möchte die Konversation zu diesem Thema nicht abschließen, da es noch nicht gelöst ist, aber möglicherweise gezwungen wird, wenn Sie dies ignorieren.

Ich werde Kommentare entfernen, die keine nützlichen Informationen hinzufügen, um den Thread (etwas) zu kürzen

Wenn Sie bei der Lösung dieses Problems helfen möchten

• Lesen Sie den gesamten Thread, einschließlich der versteckten Kommentare ; es ist lang und github blendet Kommentare aus (Sie müssen also klicken, um diese wieder sichtbar zu machen). In diesem Thread sind bereits viele Informationen vorhanden, die Ihnen möglicherweise helfen könnten

• Lesen Sie diesen Kommentar https://github.com/moby/moby/issues/5618#issuecomment -316297818 (und Kommentare zu dieser Zeit) für Informationen, die hilfreich sein können:

Um es klar zu sagen, die Nachricht selbst ist gutartig , es ist der Kernel-Absturz nach den vom OP gemeldeten Nachrichten, was nicht der Fall ist.

Der Kommentar im Code, aus dem diese Nachricht stammt, erklärt, was passiert. Grundsätzlich erhöht jeder Benutzer, z. B. der IP-Stack) eines Netzwerkgeräts (z. B. das Ende eines veth Paares in einem Container) einen Referenzzähler in der Netzwerkgerätestruktur, wenn er das Netzwerkgerät verwendet. Wenn das Gerät entfernt wird (z. B. wenn der Container entfernt wird), wird jeder Benutzer benachrichtigt, damit er einige Bereinigungen durchführen kann (z. B. offene Sockets schließen usw.), bevor der Referenzzähler verringert wird. Da diese Bereinigung einige Zeit in Anspruch nehmen kann, insbesondere unter hoher Last (viele Schnittstellen, viele Verbindungen usw.), kann der Kernel die Nachricht hier und da ab und zu ausgeben .

Wenn ein Benutzer eines Netzwerkgeräts den Referenzzähler nie verringert, wird ein anderer Teil des Kernels feststellen, dass die Aufgabe, die auf die Bereinigung wartet, hängen bleibt und abstürzt. Nur dieser Absturz weist auf einen Kernel-Bug hin (einige Benutzer haben über einen Codepfad den Referenzzähler nicht verringert). Es gab mehrere solcher Fehler und sie wurden im modernen Kernel behoben (und möglicherweise auf ältere zurückportiert). Ich habe einige Stresstests geschrieben (und schreibe sie weiter), um solche Abstürze auszulösen, konnte sie aber auf modernen Kerneln nicht reproduzieren (ich tue jedoch die obige Meldung).

* Bitte melden Sie dieses Problem nur, wenn Ihr Kernel tatsächlich abstürzt *, dann wären wir sehr interessiert an:

• Kernel-Version (Ausgabe von uname -r )
• Linux-Distribution/Version
• Verwenden Sie die neueste Kernel-Version Ihres Linux-Anbieters?
• Netzwerkeinrichtung (Bridge, Overlay, IPv4, IPv6 usw.)
• Beschreibung der Arbeitslast (welche Art von Containern, welche Art von Netzwerklast usw.)
• Und idealerweise eine einfache Reproduktion

Vielen Dank!

Läuft Docker unter irgendwelchen Grenzen? Wie ulimits, cgroups etc...

neueres systemd hat ein Standardlimit, auch wenn Sie es nicht festgelegt haben. Ich habe die Dinge auf unbegrenzt eingestellt und das Problem ist seitdem nicht mehr aufgetreten (Seit 31 Tagen geschaut).

Ich hatte das gleiche Problem in vielen Umgebungen und meine Lösung war Firewall stoppen. Es ist vorerst nicht wieder passiert

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

@dElogics Welche Version von systemd gilt als "neuer"? Ist dieses Standardlimit in CentOS 7.5 systemd aktiviert?

Und wenn Sie fragen, ob wir Docker unter irgendwelchen Limits ausführen, meinen Sie damit den Docker-Daemon oder die einzelnen Container?

Der Docker-Daemon. Das systemd wie in Debian 9 (232-25).

Bei RHEL bin ich mir nicht sicher, aber ich habe dieses Problem auch persönlich bei RHEL gesehen. Ich würde LimitNOFILE=1048576, LimitNPROC=unendlich, LimitCORE=unendlich, TasksMax=unendlich setzen

Kernel: unregister_netdevice: Warten darauf, dass eth0 frei wird. Nutzungsanzahl = 3
Kernel 4.4.146-1.el7.elrepo.x86_64
Linux-Version CentOS Linux-Version 7.4.1708 (Kern)
Brückenmodus

Ich hatte das gleiche Problem, was kann ich tun?

Gleicher Fehler:

CentOS Linux-Version 7.5.1804 (Kern)
Docker-Version 18.06.1-ce, Build e68fc7a
Kernel-Version: 3.10.0-693.el7.x86_64

Das ähnliche Problem, das ich hier kennengelernt habe...
Gibt es irgendwelche Bewegungen, die ich jetzt ausführen könnte? Bitte hilf mir...

CentOS 7.0.1406
[ root@zjsm-slavexx etc]# uname -a
Linux zjsm-slave08 3.10.0-123.el7.x86_64 #1 SMP Mo 30. Juni 12:09:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[ root@zjsm-slavexx etc]# cat /etc/centos-release
CentOS Linux-Version 7.0.1406 (Kern)

Docker-Informationen:
[ root@zjsm-slavexx ~]# Docker-Version
Klient:
Version: 17.04.0-ce
API-Version: 1.28
Go-Version: go1.7.5
Git-Commit: 4845c56
Gebaut: Mo 3. Apr 18:01:50 2017
Betriebssystem/Arch: linux/amd64

Server:
Version: 17.04.0-ce
API-Version: 1.28 (Mindestversion 1.12)
Go-Version: go1.7.5
Git-Commit: 4845c56
Gebaut: Mo 3. Apr 18:01:50 2017
Betriebssystem/Arch: linux/amd64
Experimentell: falsch

CentOS Linux Release 7.2.1511 Kernel: 3.10.0-327.el7.x86_64
gleiches Problem

Ich habe dieses Problem experimentiert.

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 , vielleicht solltest du deinen Kommentar oben in den ursprünglichen Beitrag

$ 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 

repariert.

@hzbd Du meinst das benutzerdefinierte Bridge-Netzwerk löschen? Haben Sie versucht, weiter zu graben, um herauszufinden, warum? Bitte lassen Sie es mich wissen, wenn Sie das getan haben. Ich schätze das sehr.

Warten darauf, behoben zu werden

Läuft Docker unter irgendwelchen Grenzen? Wie ulimits, cgroups etc...

neueres systemd hat ein Standardlimit, auch wenn Sie es nicht festgelegt haben. Ich habe die Dinge auf unbegrenzt eingestellt und das Problem ist seitdem nicht mehr aufgetreten (Seit 31 Tagen geschaut).

Ok, dieser Fehler tritt immer noch auf, aber die Wahrscheinlichkeit hat sich verringert.

Ich denke, wenn die Container anmutig gestoppt werden (PID 1 exist()s), dann wird uns dieser Fehler nicht stören.

@dElogics danke für die

@dElogics danke für die

Sie müssen die systemd-Einheit von Docker ändern. Die von mir verwendete Systemd-Einheit (nur relevante Teile) --

[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

Hatte jemand dieses Problem in einem Kernel 4.15 oder neuer?

Dieser Dan Streetman-Fix (https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d) ist erstmals in der Kernelversion 4.15 enthalten und es scheint, dass zumindest für jemanden dies seit dem Upgrade auf 4.16 (https:// /github.com/kubernetes/kubernetes/issues/64743#issuecomment-436839647)

Hat es jemand ausprobiert?

@victorgp Wir haben immer noch das Problem mit dem 4.15-Kernel. Wir werden hier berichten, wenn wir mit Kernel 4.16 getestet haben (hoffentlich in ein paar Wochen).

Wir haben einige Monate lang die Kernel- Version 4.14.62 verwendet , dieses Problem ist verschwunden.

Um meine vorherigen Vorsätze zu ergänzen -- ein anmutiges Stoppen von Containern (die auf SIGTERM reagieren) löst dies nie aus.

Versuchen Sie auch, die Container im Host-Namespace auszuführen (falls dies für Sie akzeptabel ist), wodurch das Problem vollständig behoben wird.

@dElogics Was meinst du mit "Host-Namespace"? Ist es einfach --privileged ?

@dElogics Was meinst du mit "Host-Namespace"? Ist es einfach --privileged ?

Nein, es bedeutet --network=host

Seit dem Upgrade von Kernel 4.4.0 auf 4.15.0 und Docker 1.11.2 auf 18.09 ist das Problem verschwunden.

In einer beträchtlichen Flotte von VMs, die als Docker-Hosts fungierten, trat dieses Problem mehrmals täglich auf (mit unserem Docker-Anwendungsfall).
45 Tage in und wir sehen das nicht mehr.

Für die Nachwelt kann ein Stack-Trace eines hängenden Docker 1.11.2 mit printk's, der unregister_netdevice: waiting for vethXXXXX anzeigt (ähnlich dem, was wir immer in unserer Flotte in Hunderten von VMs sahen), unter http://paste . gefunden werden .ubuntu.com/p/6RgkpX352J/ (die interessante Container-Ref ist 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

Daraus können wir sehen, dass es in https://github.com/moby/moby/blob/v1.11.2/daemon/container_operations.go#L732 gehangen hat

was uns auf https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/sandbox.go#L175 verweist

Und
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/endpoint.go#L760

Welches geht in den libnetwork Bridge-Treiber (überprüfe die tolle Beschreibung)
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go#L1057 -L1061

Wechsel zu netlink
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go#L601 -L617
https://github.com/moby/moby/blob/v1.11.2//vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go#L215

Und schließlich in diesem Netlink-Socket, ruft https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go#L333 auf

Wir glauben, dass der Fehler im Allgemeinen beim Stoppen eines Containers auftritt und da SKBs immer noch in den netns referenziert werden, wird das veth nicht freigegeben. Docker gibt dann nach 15s einen Kill an diesen Container aus. Der Docker-Daemon geht mit dieser Situation nicht elegant um, aber letztendlich liegt der Fehler im Kernel. Wir glauben, dass https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d (akzeptiert in 4.15 Upstream) und damit verbundene Commits (es gibt mehrere) als Minderung dienen.

Im Allgemeinen ist dieser Teil des Kernels kein schöner Ort.

Was es wert ist ... wir haben den RHEL-Linux-Kernel von 3.10.0 auf 4.17.11 aktualisiert. (Kubernetes-Cluster wird ausgeführt). Vor dem Upgrade trat dieser Fehler mehrmals täglich auf verschiedenen Servern auf. Läuft jetzt seit drei Wochen mit dem Upgrade. Fehler trat nur einmal auf. Also grob gesagt um 99% reduziert.

@marckamerbeek Sie haben den RHEL-Kernel zu einem Community-Kernel aktualisiert? Dann wird es nicht mehr unterstützt.

@Beatlor CentOS-Benutzer können dies tun.

centos 7.2 hat immer noch dieses Problem: kernel:unregister_netdevice : Warten darauf, dass lo frei wird. Nutzungsanzahl = 1

@Beatlor RHEL hat uns überhaupt nicht geholfen. Eine stabile Produktionsumgebung ist wichtiger als ein wertloser Supportvertrag. Wir laufen jetzt noch sehr stabil am 4.17.11. Keine großen Probleme mehr.

@Beatlor RHEL hat uns überhaupt nicht geholfen. Eine stabile Produktionsumgebung ist wichtiger als ein wertloser Supportvertrag. Wir laufen jetzt noch sehr stabil am 4.17.11. Keine großen Probleme mehr.

Ja, dieses Problem hatte ich auch nicht, nachdem ich den Kernel auf 4.17.0-1.el7.elrepo.x86_64 aktualisiert hatte. Ich habe dies schon einmal versucht (4.4.x, 4.8, 4.14..) und es ist fehlgeschlagen. Es scheint, dass das Problem im 4.17+-Kernel nicht mehr auftritt.

centos 7.2 hat immer noch dieses Problem: kernel:unregister_netdevice : Warten darauf, dass lo frei wird. Nutzungsanzahl = 1

Sie können versuchen, auf den neuesten 4.19+ Kernel zu aktualisieren.

Warten Sie einfach ein paar Monate und jemand wird sich auch über den 4.19-Kernel beschweren. Nur die Geschichte wiederholt sich.

Hallo zusammen, gute Nachrichten!

Seit meinem letzten Kommentar hier (zum Zeitpunkt des Schreibens vor 17 Tagen) habe ich diese Fehler nicht mehr bekommen. Auf meinen Servern (ungefähr 30) liefen Ubuntu 14.04 mit einigen veralteten Paketen.

Nach einem kompletten System-Upgrade inklusive Docker-Engine (von 1.7.1 auf 1.8.3) + Kernel-Upgrade auf die neuste mögliche Version im Repo von Ubuntu laufen meine Server ohne Vorkommnisse.

🎱

Welche Kernel-Version rüstest du auf?

vielleicht verwandt damit https://github.com/torvalds/linux/commit/f186ce61bb8235d80068c390dc2aad7ca427a4c2

Hier ist ein Versuch, dieses Problem anhand der Kommentare zu diesem Problem zusammenzufassen: https://github.com/kubernetes/kubernetes/issues/70427 , https://github.com/kubernetes/kubernetes/issues/64743 und https: //access.redhat.com/solutions/3659011

Beobachtete Kernel-Versionen mit diesem Problem

• RHEL7 3.10.0-862
• 4.15.0
• 4.20.0

Kernel-Versionen behaupteten, dieses Problem nicht auszulösen

• RHEL7 3.10.0-957.10.1
• 4.19.12
• 4.17.0
• 4.17.11

Verwandte Kernel-Commits

• https://github.com/torvalds/linux/commit/f186ce61bb8235d80068c390dc2aad7ca427a4c2 - seit 4.12
• https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d - seit 4.15
• https://github.com/torvalds/linux/commit/ee60ad219f5c7c4fb2f047f88037770063ef785f - seit 5.1

Ich fordere https://github.com/kubernetes/kubernetes/issues/70427#issuecomment -470681000 heraus, da wir dies mit Tausenden von VMs in 4.15.0 nicht gesehen haben, während wir es am 4.4. 0, gibt es mehr Berichte darüber in 4.15.0?

Ich sehe dieses Problem bei einem meiner Computer, auf dem Docker unter Debian 9 Stretch ( 4.9.0-8-amd64 ) ausgeführt wird. Ich habe dieses Problem mit einem Tunnel, der über Docker Gen im Docker-Container erstellt wurde und eine Kernel-Panik generiert:

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

Hier unsere Docker-Informationen:

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

Weiß jemand, ob es eine vorübergehende Lösung dafür gibt, ohne die gesamte Maschine neu zu starten? Wir würden es vorziehen, nicht den gesamten Computer neu starten zu müssen, wenn dieses Problem auftritt.

Etwas off-topic, können wir die Kernel-Panik-Meldungen auch im Terminal nicht unterdrücken. Ich habe dmesg -D und dmesg -n 1 ausprobiert. Jedoch kein Glück. Gibt es eine Möglichkeit, diese Art von Kernel-Panik-Nachrichten aus dem Terminal heraus zu unterdrücken? Es ist ärgerlich zu versuchen, Befehle einzugeben und diese Meldung alle 10 Sekunden oder so erscheinen zu lassen.

Vielen Dank.

Sind diese Vanilla-Kernel oder stark von Distributionen mit zurückportierten Fixes gepatcht?

@pmoust Ich sehe dies etwa einmal pro Woche auf Ubuntu 4.15.0-32. definitiv viel besser seit 4.4.0

@iavael Ich werde versuchen, die Distributionsinformationen in der Zusammenfassung

Hat jemand diesen Fehler mit 4.19 gesehen?

Hat jemand diesen Fehler mit 4.19 gesehen?

https://github.com/kubernetes/kubernetes/issues/64743#issuecomment -451351435
https://github.com/kubernetes/kubernetes/issues/64743#issuecomment -461772385

Diese Informationen können für Sie hilfreich sein.

@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 Bitte schau dir das an 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 Bitte schau dir das an https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs-while-testing-tidb-operator-in-k8s/

Ich habe die Dokumentation befolgt, aber ich bekomme immer noch einen Fehler.

[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

Diese Nachricht selbst ist nicht der Fehler; es ist der Kernel, der danach abstürzt; 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 Bitte schau dir das an https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs-while-testing-tidb-operator-in-k8s/

Ich habe die Dokumentation befolgt, aber ich bekomme immer noch einen Fehler.

[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

Nach dem Neustart, ok···

@vincent927 BTW，Sie sollten livepatch_route.ko nach /var/lib/kpatch/$(uname -r) legen, wenn kpatch.service aktiviert ist, kann die ko nach dem Neustart automatisch geladen werden.

Das haben wir heute in unserem Unternehmen plötzlich in mehreren Kubernetes-Clustern bekommen.

• 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):
  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"}

Wir kennen die Ursache noch nicht; Wir führen diese Versionen der oben genannten Software seit mehreren Monaten ohne Probleme aus. Ich kommentiere nur, um die Liste der "Softwareversionen, bei denen dieser Fehler auftritt" vorerst zu ergänzen.

@2rs2ts Hätten Sie https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs-while-testing-tidb-operator-in-k8s/?

@ethercflow Ich habe das gelesen, aber da wir Debian in meiner Firma betreiben, ist es für uns nicht einfach, den Fix in diesem Beitrag zu implementieren.

@ethercflow @2rs2ts wir führen auch Debian aus. Ich bin auf viele Probleme gestoßen, als ich versuchte, kpatch-build zum Laufen zu bringen. Wenn ich einen Workaround finde, halte ich euch auf dem Laufenden. Hat auf jeden Fall jemand eine andere Lösung? Ist es Kernel-Version 4.15 oder 4.19, die das Problem abschwächt? Ich habe in der letzten Woche versucht, die Antwort zu finden und es immer noch nicht geschafft.

@commixon unsere Erfahrung ist immer noch die gleiche wie in https://github.com/moby/moby/issues/5618#issuecomment -455800975 gemeldet, über eine Flotte von tausend VMs kein erneutes Auftreten des Problems ab 4.15.0 generische, AWS-optimierte und GCP-optimierte Varianten der Kernel von Canonical. Der eingeschränkte Test auf Vanilla 4.15.0 zeigte ebenfalls keine dieser Probleme, wurde jedoch nicht im großen Maßstab getestet.

Vielen Dank @pmoust . Werde sie ausprobieren. Auf jeden Fall werde ich auch versuchen, kpatch zu patchen, damit es mit Debian funktioniert (als Nebenprojekt) und Updates hier für alle Interessierten posten.

@ethercflow @2rs2ts wir führen auch Debian aus. Ich bin auf viele Probleme gestoßen, als ich versuchte, kpatch-build zum Laufen zu bringen. Wenn ich einen Workaround finde, halte ich euch auf dem Laufenden. Hat auf jeden Fall jemand eine andere Lösung? Ist es Kernel-Version 4.15 oder 4.19, die das Problem abschwächt? Ich habe in der letzten Woche versucht, die Antwort zu finden und es immer noch nicht geschafft.

Sie können auf 4.19 upgraden. Es ist in den Backports.

Übrigens ist es ein Jahr für uns hier. ;)

Wir haben tatsächlich 4.19 in den Backports ausprobiert, aber es gab einige größere Rückschritte in anderen Bereichen (die EC2-Instanzen würden einfach zufällig neu starten und dann würde das Netzwerk beim Start unterbrochen werden).

@2rs2ts In den letzten 4 Tagen verwenden wir 4.19 von Backports (in EC2) und haben überhaupt keine Probleme gesehen. Das Kernel-Absturzproblem ist überhaupt nicht aufgetreten und alles andere scheint auch in Ordnung zu sein. Ich glaube nicht, dass es einen Unterschied macht, aber wir haben unser Debian-Image auf das von kops (https://github.com/kubernetes/kops/blob/master/docs/images.md#debian) gestützt. Wir haben den Kernel in diesem Image aktualisiert und nicht das Standard-Debian.

Freunde, ich benutze den 4.19-Kernel für einen stabilen Betrieb seit einem halben Jahr. Ich hoffe, dass Sie auch Stabilität genießen können.

Ich habe alle 2 Wochen einen Container mit offenem 80- und 443-Port, von einem anderen Computerzugriff auf Container 80 und
443 ist leugnen

centos7.3 Kernel-Version ist:
Linux-Browser1 3.10.0-514.el7.x86_64 #1 SMP Di 22. Nov 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

root@browser1 ~]# Docker-Version
Klient:
Version: 18.06.3-ce
API-Version: 1.38
Go-Version: go1.10.4
Git-Commit: d7080c1
Gebaut: Mi 20 Feb 02:24:22 2019
Betriebssystem/Arch: linux/amd64
Experimentell: falsch

Server:
Motor:
Version: 18.06.3-ce
API-Version: 1.38 (Mindestversion 1.12)
Go-Version: go1.10.3
Git-Commit: d7080c1
Gebaut: Mi 20 Feb 02:25:33 2019
Betriebssystem/Arch: linux/amd64
Experimentell: falsch
[ root@browser1 ~]#

dmesg:

[1063959.636785] unregister_netdevice: Warten darauf, dass lo frei wird. Nutzungsanzahl = 1
[1071340.887512] br-af29e1edc1b8: Port 5 (vethc2ac4f8) wechselte in den deaktivierten Zustand
[1071340.891753] br-af29e1edc1b8: Port 5 (vethc2ac4f8) trat in den deaktivierten Zustand ein
[1071340.895118] Gerät vethc2ac4f8 hat den promiskuitiven Modus verlassen
[1071340.895138] br-af29e1edc1b8: Port 5 (vethc2ac4f8) trat in den deaktivierten Zustand ein
[1071340.990505] Gerät veth5e4f161 wechselte in den Promiscuous-Modus
[1071340.990897] IPv6: ADDRCONF(NETDEV_UP): veth5e4f161: Link ist nicht bereit
[1071340.990904] br-af29e1edc1b8: Port 5(veth5e4f161) hat den Weiterleitungsstatus erreicht
[1071340.990924] br-af29e1edc1b8: Port 5(veth5e4f161) hat den Weiterleitungsstatus erreicht
[1071341.231405] IPv6: ADDRCONF(NETDEV_CHANGE): veth5e4f161: Link wird bereit
[1071355.991701] br-af29e1edc1b8: Port 5(veth5e4f161) hat den Weiterleitungsstatus erreicht
[1071551.533907] br-af29e1edc1b8: Port 5 (veth5e4f161) trat in den deaktivierten Zustand ein
[1071551.537564] br-af29e1edc1b8: Port 5 (veth5e4f161) trat in den deaktivierten Zustand ein
[1071551.540295] Gerät veth5e4f161 hat den Promiscuous-Modus verlassen
[1071551.540313] br-af29e1edc1b8: Port 5 (veth5e4f161) trat in den deaktivierten Zustand ein
[1071551.570924] Gerät veth8fd3a0a wechselte in den Promiscuous-Modus
[1071551.571550] IPv6: ADDRCONF(NETDEV_UP): veth8fd3a0a: Link ist nicht bereit
[1071551.571556] br-af29e1edc1b8: Port 5(veth8fd3a0a) hat den Weiterleitungsstatus erreicht
[1071551.571582] br-af29e1edc1b8: Port 5(veth8fd3a0a) hat den Weiterleitungsstatus erreicht
[1071551.841656] IPv6: ADDRCONF(NETDEV_CHANGE): veth8fd3a0a: Link wird bereit
[1071566.613998] br-af29e1edc1b8: Port 5(veth8fd3a0a) hat den Weiterleitungsstatus erreicht
[1071923.465082] br-af29e1edc1b8: Port 5 (veth8fd3a0a) wechselte in den deaktivierten Zustand
[1071923.470215] br-af29e1edc1b8: Port 5 (veth8fd3a0a) wechselte in den deaktivierten Zustand
[1071923.472888] Gerät veth8fd3a0a hat den Promiscuous-Modus verlassen
[1071923.472904] br-af29e1edc1b8: Port 5 (veth8fd3a0a) wechselte in den deaktivierten Zustand
[1071923.505580] Gerät veth9e693ae wechselte in den Promiscuous-Modus
[1071923.505919] IPv6: ADDRCONF(NETDEV_UP): veth9e693ae: Link ist nicht bereit
[1071923.505925] br-af29e1edc1b8: Port 5(veth9e693ae) hat den Weiterleitungsstatus erreicht
[1071923.505944] br-af29e1edc1b8: Port 5(veth9e693ae) hat den Weiterleitungsstatus erreicht
[1071923.781658] IPv6: ADDRCONF(NETDEV_CHANGE): veth9e693ae: Link wird bereit
[1071938.515044] br-af29e1edc1b8: Port 5(veth9e693ae) hat den Weiterleitungsstatus erreicht

Hat jemand diesen Fehler mit 4.19 gesehen?

Jawohl. Ich habe das Problem mit Kernel 4.19.4-1.e17.elrep.x86_64

Hallo,

Ich sehe diesen Fehler auch. Haben wir eine Lösung für dieses Problem? Kernel 3.10.0-514.26.2.el7.x86_64

[username@ip-10-1-4-64 ~]$
Message from syslogd@ip-10-1-4-64 at Jul 19 10:50:01 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Message from syslogd@ip-10-1-4-64 at Jul 19 10:50:48 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Dieses Problem tritt immer noch auf :(kein Update/Ideen zur Behebung?

Geschieht auf Debian Stretch. Ich habe versucht, meinen Jenkins-Container über Ansible zu aktualisieren, als dies geschah.

Dieses Problem wurde durch diesen Commit gelöst:
https://github.com/torvalds/linux/commit/ee60ad219f5c7c4fb2f047f88037770063ef785f
kpatch verwenden

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

Dieses Problem wurde durch diesen Commit gelöst:
torvalds/ linux@ee60ad2
kpatch verwenden

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

Dies muss ab 4.19.30 sein.