Moby: plantage du noyau après "unregister_netdevice: en attente que lo devienne libre. Nombre d'utilisations = 3"

Créé le 6 mai 2014  ·  518Commentaires  ·  Source: moby/moby

Cela se produit lorsque je me connecte au conteneur et que je ne peux pas quitter avec Ctrl-c.

Mon système est Ubuntu 12.04 , le noyau est 3.8.0-25-generic .

version docker :

root@wutq-docker:~# docker version
Client version: 0.10.0
Client API version: 1.10
Go version (client): go1.2.1
Git commit (client): dc9c28f
Server version: 0.10.0
Server API version: 1.10
Git commit (server): dc9c28f
Go version (server): go1.2.1
Last stable version: 0.10.0

J'ai utilisé le script https://raw.githubusercontent.com/dotcloud/docker/master/contrib/check-config.sh pour vérifier, et tout va bien.

J'ai regardé le syslog et j'ai trouvé ce message :

May  6 11:30:33 wutq-docker kernel: [62365.889369] unregister_netdevice: waiting for lo to become free. Usage count = 3
May  6 11:30:44 wutq-docker kernel: [62376.108277] unregister_netdevice: waiting for lo to become free. Usage count = 3
May  6 11:30:54 wutq-docker kernel: [62386.327156] unregister_netdevice: waiting for lo to become free. Usage count = 3
May  6 11:31:02 wutq-docker kernel: [62394.423920] INFO: task docker:1024 blocked for more than 120 seconds.
May  6 11:31:02 wutq-docker kernel: [62394.424175] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May  6 11:31:02 wutq-docker kernel: [62394.424505] docker          D 0000000000000001     0  1024      1 0x00000004
May  6 11:31:02 wutq-docker kernel: [62394.424511]  ffff880077793cb0 0000000000000082 ffffffffffffff04 ffffffff816df509
May  6 11:31:02 wutq-docker kernel: [62394.424517]  ffff880077793fd8 ffff880077793fd8 ffff880077793fd8 0000000000013f40
May  6 11:31:02 wutq-docker kernel: [62394.424521]  ffff88007c461740 ffff880076b1dd00 000080d081f06880 ffffffff81cbbda0
May  6 11:31:02 wutq-docker kernel: [62394.424526] Call Trace:                                                         
May  6 11:31:02 wutq-docker kernel: [62394.424668]  [<ffffffff816df509>] ? __slab_alloc+0x28a/0x2b2
May  6 11:31:02 wutq-docker kernel: [62394.424700]  [<ffffffff816f1849>] schedule+0x29/0x70
May  6 11:31:02 wutq-docker kernel: [62394.424705]  [<ffffffff816f1afe>] schedule_preempt_disabled+0xe/0x10
May  6 11:31:02 wutq-docker kernel: [62394.424710]  [<ffffffff816f0777>] __mutex_lock_slowpath+0xd7/0x150
May  6 11:31:02 wutq-docker kernel: [62394.424715]  [<ffffffff815dc809>] ? copy_net_ns+0x69/0x130
May  6 11:31:02 wutq-docker kernel: [62394.424719]  [<ffffffff815dc0b1>] ? net_alloc_generic+0x21/0x30
May  6 11:31:02 wutq-docker kernel: [62394.424724]  [<ffffffff816f038a>] mutex_lock+0x2a/0x50
May  6 11:31:02 wutq-docker kernel: [62394.424727]  [<ffffffff815dc82c>] copy_net_ns+0x8c/0x130
May  6 11:31:02 wutq-docker kernel: [62394.424733]  [<ffffffff81084851>] create_new_namespaces+0x101/0x1b0
May  6 11:31:02 wutq-docker kernel: [62394.424737]  [<ffffffff81084a33>] copy_namespaces+0xa3/0xe0
May  6 11:31:02 wutq-docker kernel: [62394.424742]  [<ffffffff81057a60>] ? dup_mm+0x140/0x240
May  6 11:31:02 wutq-docker kernel: [62394.424746]  [<ffffffff81058294>] copy_process.part.22+0x6f4/0xe60
May  6 11:31:02 wutq-docker kernel: [62394.424752]  [<ffffffff812da406>] ? security_file_alloc+0x16/0x20
May  6 11:31:02 wutq-docker kernel: [62394.424758]  [<ffffffff8119d118>] ? get_empty_filp+0x88/0x180
May  6 11:31:02 wutq-docker kernel: [62394.424762]  [<ffffffff81058a80>] copy_process+0x80/0x90
May  6 11:31:02 wutq-docker kernel: [62394.424766]  [<ffffffff81058b7c>] do_fork+0x9c/0x230
May  6 11:31:02 wutq-docker kernel: [62394.424769]  [<ffffffff816f277e>] ? _raw_spin_lock+0xe/0x20
May  6 11:31:02 wutq-docker kernel: [62394.424774]  [<ffffffff811b9185>] ? __fd_install+0x55/0x70
May  6 11:31:02 wutq-docker kernel: [62394.424777]  [<ffffffff81058d96>] sys_clone+0x16/0x20
May  6 11:31:02 wutq-docker kernel: [62394.424782]  [<ffffffff816fb939>] stub_clone+0x69/0x90
May  6 11:31:02 wutq-docker kernel: [62394.424786]  [<ffffffff816fb5dd>] ? system_call_fastpath+0x1a/0x1f
May  6 11:31:04 wutq-docker kernel: [62396.466223] unregister_netdevice: waiting for lo to become free. Usage count = 3
May  6 11:31:14 wutq-docker kernel: [62406.689132] unregister_netdevice: waiting for lo to become free. Usage count = 3
May  6 11:31:25 wutq-docker kernel: [62416.908036] unregister_netdevice: waiting for lo to become free. Usage count = 3
May  6 11:31:35 wutq-docker kernel: [62427.126927] unregister_netdevice: waiting for lo to become free. Usage count = 3
May  6 11:31:45 wutq-docker kernel: [62437.345860] unregister_netdevice: waiting for lo to become free. Usage count = 3

Après cela, j'ouvre un autre terminal et tue ce processus, puis redémarre docker, mais cela sera bloqué.

Je redémarre l'hôte et il affiche toujours ces messages pendant quelques minutes lors de l'arrêt :
screen shot 2014-05-06 at 11 49 27

arekernel arenetworking

Commentaire le plus utile

(en répétant ceci https://github.com/moby/moby/issues/5618#issuecomment-351942943 ici encore, car GitHub cache les anciens commentaires)

Si vous arrivez ici

Le problème discuté ici est un bogue du noyau et n'a pas encore été complètement résolu. Certains correctifs ont été intégrés au noyau pour corriger _quelques_ occurrences de ce problème, mais d'autres ne sont pas encore résolus.

Il existe un certain nombre d'options qui peuvent aider dans _certaines_ situations, mais pas pour toutes (encore une fois, il s'agit très probablement d'une combinaison de problèmes qui déclenchent la même erreur)

L'erreur "unregister_netdevice: wait for lo to be free" elle-même n'est pas le bogue

Si c'est le plantage du noyau _après_ c'est un bogue (voir ci-dessous)

Ne laissez pas de commentaires "J'ai ça aussi"

"J'ai ça aussi" n'aide pas à résoudre le bug. ne laissez un commentaire que si vous avez des informations qui peuvent aider à résoudre le problème (auquel cas, fournir un correctif au noyau en amont peut être la meilleure étape).

Si vous voulez faire savoir que vous avez également ce problème, utilisez le bouton « pouce vers le haut » dans la description du haut :
screen shot 2017-03-09 at 16 12 17

Si vous souhaitez rester informé des mises à jour, utilisez le _bouton d'abonnement_.

screen shot 2017-03-09 at 16 11 03

Chaque commentaire ici envoie un e-mail/une notification à plus de 3000 personnes. Je ne veux pas verrouiller la conversation sur ce problème, car il n'est pas encore résolu, mais peut être forcé de le faire si vous l'ignorez.

Je vais supprimer les commentaires qui n'ajoutent pas d'informations utiles afin de raccourcir (légèrement) le fil

Si vous voulez aider à résoudre ce problème

  • Lire l'intégralité du fil, y compris les commentaires masqués ; c'est long, et github masque les commentaires (vous devrez donc cliquer pour les rendre à nouveau visibles). Il y a déjà beaucoup d'informations présentes dans ce fil qui pourraient éventuellement vous aider

screen shot 2018-07-25 at 15 18 14

Pour être clair, le message lui-même est bénin , c'est le crash du noyau après les messages rapportés par l'OP qui ne l'est pas.

Le commentaire dans le code, d'où vient ce message, explique ce qui se passe. Fondamentalement, chaque utilisateur, tel que la pile IP) d'un périphérique réseau (comme la fin d' veth paire ici de temps en temps .

Si un utilisateur de périphérique réseau ne décrémente jamais le nombre de références, une autre partie du noyau déterminera que la tâche en attente de nettoyage est bloquée et qu'elle plantera. C'est seulement ce plantage qui indique un bogue du noyau (certains utilisateurs, via un chemin de code, n'ont pas décrémenté le nombre de références). Il y a eu plusieurs bogues de ce type et ils ont été corrigés dans le noyau moderne (et éventuellement rétroportés sur les anciens). J'ai écrit pas mal de stress tests (et continue de les écrire) pour déclencher de tels plantages mais je n'ai pas pu reproduire sur les noyaux modernes (je fais cependant le message ci-dessus).

* Veuillez ne signaler ce problème que si votre noyau plante réellement *, et nous serions alors très intéressés par :

  • version du noyau (sortie de uname -r )
  • Distribution/version Linux
  • Êtes-vous sur la dernière version du noyau de votre fournisseur Linux ?
  • Configuration du réseau (pont, overlay, IPv4, IPv6, etc.)
  • Description de la charge de travail (quel type de conteneurs, quel type de charge réseau, etc.)
  • Et idéalement une simple reproduction

Merci!

Tous les 518 commentaires

Je vois un problème très similaire pour eth0. Ubuntu 12.04 aussi.

Je dois redémarrer la machine. À partir de /var/log/kern.log :

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

Hé, ça vient juste de commencer pour moi aussi.

Version Docker :

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

Journal du noyau : http://pastebin.com/TubCy1tG

Détails du système :
Exécution d'Ubuntu 14.04 LTS avec un noyau corrigé (3.14.3-rt4). Reste à voir cela se produire avec le noyau linux-3.13.0-27-generic par défaut. Ce qui est amusant, cependant, c'est que lorsque cela se produit, toutes les fenêtres de mon terminal se bloquent, me permettant de saisir au plus quelques caractères avant cela. Le même sort arrive à tous les nouveaux que j'ouvre - et je finis par avoir besoin de redémarrer mon pauvre ordinateur portable, tout comme le bon docteur ci-dessus. Pour mémoire, j'exécute fish shell dans urxvt ou xterm dans xmonad. Je n'ai pas vérifié si cela affecte le simple bash.

Cela peut être pertinent :
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065434#yui_3_10_3_1_1401948176063_2050

Copier une assez grande quantité de données sur le réseau à l'intérieur d'un conteneur
puis la sortie du conteneur peut déclencher un décrément manquant dans le per
nombre de références cpu sur un périphérique réseau.

Effectivement, l'une des fois où cela s'est produit pour moi, c'était juste après avoir apt-get ting un paquet avec une tonne de dépendances.

La mise à niveau d'Ubuntu 12.04.3 vers 14.04 a résolu ce problème pour moi sans aucun autre changement.

Je rencontre cela sur RHEL7, 3.10.0-123.4.2.el7.x86_64

J'ai remarqué la même chose avec mes interfaces réseau virtuelles VirtualBox lorsque j'exécute 3.14-rt4. C'est censé être corrigé dans vanilla 3.13 ou quelque chose comme ça.

@egasimus Idem ici - j'ai

J'ai mis à niveau vers le noyau Debian 3.14 et le problème semble avoir disparu. On dirait que le problème existait dans certains noyaux < 3.5, a été corrigé dans 3.5, a régressé dans 3.6 et a été corrigé dans quelque chose 3.12-3.14. https://bugzilla.redhat.com/show_bug.cgi?id=880394

@spiffytech Avez-vous une idée de l'endroit où je peux signaler cela concernant la saveur du noyau en temps réel ? Je pense qu'ils ne publient qu'un patch RT pour toutes les autres versions, et je détesterais vraiment voir la 3.16-rt sortir avec cette version encore cassée. :/

EDIT: l'a déposé sur kernel.org .

Je reçois ceci sur Ubuntu 14.10 exécutant un 3.18.1. Le journal du noyau s'affiche

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

J'enverrai docker version/info une fois que le système ne sera plus gelé :)

Nous constatons également ce problème. Ubuntu 14.04, 3.13.0-37-générique

Sur le serveur Ubuntu 14.04, mon équipe a constaté que la rétrogradation de 3.13.0-40-generic à 3.13.0-32-generic « résout » le problème. Compte tenu de l'observation de

J'ajouterai que, dans notre cas, nous voyons parfois un nombre d'utilisations _négatif_.

FWIW, nous avons rencontré ce bogue en exécutant lxc sur un noyau de confiance (3.13.0-40-generic #69-Ubuntu), le message apparaît dans dmesg suivi de cette trace de pile :

[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

Je l'ai rencontré sur Ubuntu 14.04 et Debian jessie avec le noyau 3.16.x.

Commande Docker :

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

Cela semble être un assez mauvais problème...

@jbalonso même avec 3.13.0-32-generic, j'obtiens l'erreur après seulement quelques exécutions réussies :sob:

@MrMMorris pourriez-vous partager un script de reproduction en utilisant des images disponibles publiquement ?

Tous ceux qui voient cette erreur sur leur système exécutent un package du noyau Linux sur leur distribution qui est beaucoup trop ancien et qui n'a pas les correctifs pour ce problème particulier.

Si vous rencontrez ce problème, assurez-vous d'exécuter apt-get update && apt-get dist-upgrade -y et de redémarrer votre système. Si vous êtes sur Digital Ocean, vous devez également sélectionner la version du noyau qui vient d'être installée lors de la mise à jour car ils n'utilisent pas automatiquement le dernier noyau (voir https://digitalocean.uservoice.com/forums/136585-digitalocean /suggestions/2814988-give-option-to-use-the-droplet-s-own-bootloader).

Les utilisateurs de CentOS/RHEL/Fedora/Scientific Linux doivent maintenir leurs systèmes à jour à l'aide de yum update et redémarrer après avoir installé les mises à jour.

Lorsque vous signalez ce problème, assurez-vous que votre système est entièrement corrigé et à jour avec les dernières mises à jour stables (pas de packages expérimental/test/alpha/beta/rc installés manuellement) fournies par le fournisseur de votre distribution.

@onclejack

J'ai couru apt-get update && apt-get dist-upgrade -y

Ubuntu 14.04 3.13.0-46-générique

Toujours obtenir l'erreur après un seul docker run

Je peux créer une AMI à reproduire si besoin

@MrMMorris Merci d'avoir confirmé qu'il s'agit toujours d'un problème avec le dernier package du noyau sur Ubuntu 14.04.

Tout ce que je peux faire pour vous aider, faites le moi savoir ! :le sourire:

@MrMMorris si vous pouvez fournir un reproducteur il y a un bogue ouvert pour Ubuntu et il sera très apprécié : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152

@rsampaio si j'ai le temps aujourd'hui, je l'

Ce problème apparaît également sur 3.16(.7) sur Debian 7 et Debian 8 : https://github.com/docker/docker/issues/9605#issuecomment -85025729. Le redémarrage du serveur est le seul moyen de résoudre ce problème pour le moment.

Voir ce problème sur RHEL 6.6 avec le noyau 2.6.32-504.8.1.el6.x86_64 lors du démarrage de certains conteneurs Docker (pas tous les conteneurs)
_ kernel:unregister_netdevice : en attente que lo devienne libre. Nombre d'utilisations = -1_

Encore une fois, le redémarrage du serveur semble être la seule solution pour le moment

Voir également cela sur CoreOS (647.0.0) avec le noyau 3.19.3.

Le redémarrage est également la seule solution que j'ai trouvée.

Testé Debian jessie avec le noyau de sid (4.0.2) - le problème persiste.

Quelqu'un a-t-il vu ce problème avec des conteneurs non-ubuntu ?

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

Quelqu'un a-t-il vu ce problème avec des conteneurs non-ubuntu ?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/docker/docker/issues/5618#issuecomment-113556862 .

Il s'agit d'un problème de noyau, pas d'un problème lié à l'image. Changer d'image pour une autre n'améliorera pas ou n'aggravera pas ce problème.

Problème rencontré sur Debian Jessie sur un BeagleBone Black exécutant le noyau 4.1.2-bone12

Expérience après le passage de 4.1.2 à 4.2-rc2 (en utilisant git build de 1.8.0).
La suppression de /var/lib/docker/* ne résout pas le problème.
Revenir à 4.1.2 résout le problème.

De plus, VirtualBox a le même problème et il existe un correctif pour la v5.0.0 (rétro-porté vers la v4) qui est censé faire quelque chose dans la partie pilote du noyau. Il vaut la peine de chercher à comprendre le problème.

Voici le correctif dans VirtualBox : https://www.virtualbox.org/attachment/ticket/12264/diff_unregister_netdev
Ils ne modifient pas réellement le noyau, juste leur module de noyau.

Ayant également ce problème avec 4.2-rc2 :

unregister_netdevice : en attente de la libération de vethf1738d3. Nombre d'utilisations = 1

Je viens de compiler 4.2-RC3, semble fonctionner à nouveau

@nazar-pc Merci pour l'info. Je viens de le frapper avec 4.1.3, j'étais assez contrarié
@techniq même ici, assez mauvais bug du noyau. Je me demande si nous devrions le signaler pour être rétroporté à l'arborescence 4.1.

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

Noyau d'Ubuntu 15.04, même problème

Je l'ai aussi vu avec 4.2-rc3. Il n'y a pas un seul bogue concernant les fuites de périphériques :) Je peux reproduire sur n'importe quel noyau >=4.1 sous haute charge.

Je viens d'avoir ce problème aussi. Ubuntu 3.13.0-57-generic, provisionné via tutum. Malheureusement, il remplit le kern.log et le syslog et plante la machine. Cela se produit sur la machine de la base de données (postgres dockerisé), donc cela arrête tout le système ...

Rejoignant le chœur de "moi aussi", je vois ce problème sur une VM cloudstack exécutant RancherOS (un système d'exploitation minimal) 0.3.3 tout en extrayant des images docker d'un dépôt docker privé local. Cela se produit toutes les dix secondes, je ne sais pas si cela signifie quelque chose ou non.

Ayant également ce problème avec 4.2-rc7

Des nouvelles à ce sujet, quel noyau doit-on utiliser ? Cela continue même avec un noyau entièrement à jour (3.19.0-26 sur Ubuntu 14.04)

Nous avons aussi ce problème. Cela se produit après avoir configuré userland-proxy=false. Nous utilisons des scripts de surveillance qui généreront un nouveau conteneur docker pour exécuter la commande des plugins nagios toutes les minutes. Ce que je vois dans l'arborescence des processus, c'est qu'il est bloqué sur la commande docker rm et qu'il y a beaucoup d'erreurs dans le fichier kern.log

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

Ce sont nos informations système

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

Mise à jour : bien que https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152 indique que c'est déjà corrigé le 2015-08-17. J'ai donc essayé avec le noyau v3.19.8-ckt6-vivid qui est construit sur 02-Sep-2015 ou même v4.2.1-unstable qui construit sur 21-Sep-2015 et a toujours un problème.

Je viens de résoudre à nouveau le problème en utilisant 3.19.0-28-generic , donc le dernier noyau Ubuntu n'est pas sûr

Oui, il semble que --userland-proxy=false ne soit pas la meilleure option maintenant avec les anciens noyaux :(

Non. J'ai essayé --userland-proxy=false pour toutes les versions du noyau 3.19, 4.0, 4.2 et le problème persiste.

J'utilise un proxy userland sans iptables (--iptables=false) et je le vois au moins une fois par jour. Malheureusement, la seule solution de contournement était un chien de garde qui a réinitialisé le serveur à l'aide de la technique SysRq.

Mes systèmes exécutent certains conteneurs qui sont de gros rédacteurs stdout/err, comme d'autres l'ont signalé, cela peut déclencher le bogue.

``````
$ informations sur le docker
Conteneurs : 15
Images : 148
Pilote de stockage : aufs
Répertoire racine : /var/lib/docker/aufs
Système de fichiers de sauvegarde : extfs
Répertoire : 178
Dirperm1 pris en charge : vrai
Pilote d'exécution : natif-0.2
Pilote de journalisation : fichier json
Version du noyau : 3.19.0-26-generic
Système d'exploitation : Ubuntu 14.04.3 LTS
Processeurs : 12
Mémoire totale : 62,89 Gio
Nom : * *
ID : 2 ALJ:YTUH : QCNX:FPEO :YBG4:ZTL4:2 EYK:AV7D :FN7C: IVNU:UWBL :YYZ5

$ version docker
Version client : 1.7.0
Version de l'API client : 1.19
Version Go (client) : go1.4.2
Git commit (client) : 0baf609
OS/Arch (client) : linux/amd64
Version du serveur : 1.7.0
Version de l'API du serveur : 1.19
Version Go (serveur) : go1.4.2
Git commit (serveur) : 0baf609
OS/Arch (serveur) : linux/amd64```
``````

Malheureusement, je suis dans le même cas, aujourd'hui un serveur de production a échoué 3 fois sur cette erreur, et le seul moyen de gérer cela est d'utiliser des commandes SysRq magiques..

cogner

Je vois toujours cela sur la dernière Debian Jessie utilisant le noyau 4.2.0

Même problème ici. Tout à coup, trois de mes serveurs aws sont tombés en panne et les journaux criaient "unregister_netdevice: wait for lo to be free. Usage count = 1"

Ubuntu : 14.04
Version du noyau : 3.13.0-63-generic
Docker : 1.7.1

Syslog
screenshot from 2015-10-22 11 53 41

Existe-t-il une version du noyau sûre à utiliser ?

Le problème se produit également avec le noyau 4.2 d'Ubuntu 15.10

arrivé dans coreos:

Images : 1174
Pilote de stockage : superposition
Système de fichiers de sauvegarde : extfs
Pilote d'exécution : natif-0.2
Pilote de journalisation : fichier json
Version du noyau : 4.1.7-coreos
Système d'exploitation : CoreOS 766.4.0

Le bogue du noyau que @killme2008 a dit la dernière fois

Vous devriez probablement essayer avec ce correctif appliqué sur votre noyau http://www.spinics.net/lists/netdev/msg351337.html
paquet : condition de concurrence dans packet_bind

ou attendez le rétroportage dans l'arborescence -stable ; ça viendra tôt ou tard.

:+1: Bonne nouvelle !

Salut tout le monde, bonne nouvelle !

Depuis mon dernier commentaire ici (au moment de la rédaction, il y a 17 jours), je n'ai plus ces erreurs. Mes serveurs (environ 30) exécutaient Ubuntu 14.04 avec des packages obsolètes.

Après une mise à niveau complète du système, y compris docker-engine (de 1.7.1 à 1.8.3) + mise à niveau du noyau vers la dernière version possible sur le référentiel d'ubuntu, mes serveurs fonctionnent sans aucun incident.

:8 balles:

Cela s'est également produit sur 3 de nos instances AWS aujourd'hui :

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

J'ai le même problème avec Ubuntu 14.04, tous les packages à jour et le dernier noyau linux-generic-lts-vivid :

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

Server:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 17:43:42 UTC 2015
 OS/Arch:      linux/amd64
$ docker info
Containers: 14
Images: 123
Server Version: 1.9.0
Storage Driver: aufs
 Root Dir: /mnt/docker-images/aufs
 Backing Filesystem: extfs
 Dirs: 151
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.19.0-32-generic
Operating System: Ubuntu 14.04.3 LTS
CPUs: 8
Total Memory: 29.45 GiB
Name: ip-172-31-35-202
ID: 3B7E:5DJL:S4IB:KUCL:6UKN:64OF:WCLO:JKGK:4OI2:I2R6:63EY:WATN
WARNING: No swap limit support

Je l'avais aussi avec le dernier linux-image-generic (3.13.0-67-generic).

Avoir les mêmes problèmes ici sur rancherOS.

Toujours en cours sur Fedora 22 (mis à jour)....
Je peux me débarrasser des messages si je redémarre docker

docker de redémarrage systemctl
... le message réapparaît environ 3 à 4 fois puis s'arrête

La même erreur me rencontre avec coreos:

version de coreos :

 core@core-1-94 ~ $ cat /etc/os-release
 NOM=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"

version docker :

 core@core-1-94 ~ $ version docker
 Version client : 1.7.1
 Version de l'API client : 1.19
 Version Go (client) : go1.4.2
 Git commit (client) : df2f73d-dirty
 OS/Arch (client) : linux/amd64
 Version du serveur : 1.7.1
 Version de l'API du serveur : 1.19
 Version Go (serveur) : go1.4.2
 Git commit (serveur) : df2f73d-dirty
 OS/Arch (serveur) : linux/amd64
 core@core-1-94 ~ $ uname -a
 Linux core-1-94 4.1.7-coreos-r1 #2 SMP jeu 5 novembre 02:10:23 UTC 2015 x86_64 Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz GenuineIntel GNU/Linux

journal du système:

 07 décembre 16:26:54 noyau core-1-94 : unregister_netdevice : en attente de la libération de veth775ea53. Nombre d'utilisations = 1
 Dec 07 16:26:54 noyau core-1-94 : unregister_netdevice : en attente que lo devienne libre. Nombre d'utilisations = 2
 Déc 07 16:26:55 core-1-94 sdnotify-proxy[1203]: I1207 08:26:55.930559 00001 vxlan.go:340] Ignorer pas un manque : 4e:5c:47:2f:9a:85, 10.244 .97.10
 07 décembre 16:26:59 core-1-94 dockerd[1269]: time="2015-12-07T16:26:59.448438648+08:00" level=info msg="GET /version"
 07 décembre 16:27:01 core-1-94 sdnotify-proxy[1203]: I1207 08:27:01.050588 00001 vxlan.go:340] Ignorer pas un manque : 5a:b1:f7:e9:7d:d0, 10.244 .34.8
 07 décembre 16:27:02 core-1-94 dockerd[1269]: time="2015-12-07T16:27:02.398020120+08:00" level=info msg="GET /version"
 07 décembre 16:27:02 core-1-94 dockerd[1269]: time="2015-12-07T16:27:02.398316249+08:00" level=info msg="GET /version"
 07 décembre 16:27:04 core-1-94 dockerd[1269]: time="2015-12-07T16:27:04.449317389+08:00" level=info msg="GET /version"
 07 décembre 16:27:04 noyau core-1-94 : unregister_netdevice : en attente de la libération de veth775ea53. Nombre d'utilisations = 1
 07 décembre 16:27:04 noyau core-1-94 : unregister_netdevice : en attente que lo devienne libre. Nombre d'utilisations = 2
 07 décembre 16:27:06 core-1-94 sdnotify-proxy[1203]: I1207 08:27:06.106573 00001 vxlan.go:340] Ignorer pas un manque: a6:38:ac:79:93:f5, 10.244 .47.24
 07 décembre 16:27:09 core-1-94 dockerd[1269]: time="2015-12-07T16:27:09.449944048+08:00" level=info msg="GET /version"
 07 décembre 16:27:11 core-1-94 sdnotify-proxy[1203]: I1207 08:27:11.162578 00001 vxlan.go:340] Ignorer pas un manque: 0e:f0:6f:f4:69:57, 10.244 .71.24
 07 décembre 16:27:12 core-1-94 dockerd[1269]: time="2015-12-07T16:27:12.502991197+08:00" level=info msg="GET /version"
 07 décembre 16:27:12 core-1-94 dockerd[1269]: time="2015-12-07T16:27:12.503411160+08:00" level=info msg="GET /version"
 07 décembre 16:27:14 core-1-94 dockerd[1269]: time="2015-12-07T16:27:14.450646841+08:00" level=info msg="GET /version"
 07 décembre 16:27:14 noyau core-1-94 : unregister_netdevice : en attente de la libération de veth775ea53. Nombre d'utilisations = 1
 07 décembre 16:27:14 noyau core-1-94 : unregister_netdevice : en attente que lo devienne libre. Nombre d'utilisations = 2
 Déc 07 16:27:16 core-1-94 sdnotify-proxy[1203]: I1207 08:27:16.282556 00001 vxlan.go:340] Ignorer pas un manque: a6:62:77:31:ef:68, 10.244 .13.6
 07 décembre 16:27:19 core-1-94 dockerd[1269]: time="2015-12-07T16:27:19.451486277+08:00" level=info msg="GET /version"
 Dec 07 16:27:21 core-1-94 sdnotify-proxy[1203]: I1207 08:27:21.402559 00001 vxlan.go:340] Ignorer pas un manque: 92:c4:66:52:cd:bb, 10.244 .24.7
 07 décembre 16:27:22 core-1-94 dockerd[1269]: time="2015-12-07T16:27:22.575446889+08:00" level=info msg="GET /version"
 07 décembre 16:27:22 core-1-94 dockerd[1269]: time="2015-12-07T16:27:22.575838302+08:00" level=info msg="GET /version"
 07 décembre 16:27:24 core-1-94 dockerd[1269]: time="2015-12-07T16:27:24.452320364+08:00" level=info msg="GET /version"
 07 décembre 16:27:24 noyau core-1-94 : unregister_netdevice : en attente de la libération de veth775ea53. Nombre d'utilisations = 1
 07 décembre 16:27:24 noyau core-1-94 : unregister_netdevice : en attente que lo devienne libre. Nombre d'utilisations = 2
 07 décembre 16:27:26 core-1-94 sdnotify-proxy[1203]: I1207 08:27:26.394569 00001 vxlan.go:340] Ignorer pas un manque : 6a:f7:bf:ec:03:50, 10.244 .87.8
 07 décembre 16:27:29 core-1-94 dockerd[1269]: time="2015-12-07T16:27:29.453171649+08:00" level=info msg="GET /version"
 07 décembre 16:27:29 core-1-94 systemd[1]: Démarrage de Generate /run/coreos/motd...
 07 déc. 16:27:29 core-1-94 systemd[1] : Lancement de la génération de /run/coreos/motd.
 07 décembre 16:27:32 core-1-94 dockerd[1269]: time="2015-12-07T16:27:32.671592437+08:00" level=info msg="GET /version"
 07 décembre 16:27:32 core-1-94 dockerd[1269]: time="2015-12-07T16:27:32.671841436+08:00" level=info msg="GET /version"
 Dec 07 16:27:33 core-1-94 sdnotify-proxy[1203]: I1207 08:27:33.562534 00001 vxlan.go:340] Ignorer pas un manque : 22:b4:62:d6:25:b9, 10.244 .68,8
 07 décembre 16:27:34 core-1-94 dockerd[1269]: time="2015-12-07T16:27:34.453953162+08:00" level=info msg="GET /version"
 07 décembre 16:27:34 noyau core-1-94 : unregister_netdevice : en attente de la libération de veth775ea53. Nombre d'utilisations = 1
 07 décembre 16:27:35 noyau core-1-94 : unregister_netdevice : en attente que lo devienne libre. Nombre d'utilisations = 2

joyeux anniversaire, problème sanglant =)
6 mai 2014

même chose ici. Juste en train de redémarrer. Dernière version du docker. Ubuntu 14.04.

@samvignoli cela a été identifié comme un problème de noyau, donc malheureusement pas quelque chose qui peut être corrigé dans docker

@thaJeztah Avez-vous un lien vers le bug tracker pour le problème du noyau ?
Ou peut-être un pointeur sur les noyaux affectés ?

Désireux de résoudre ce problème dans notre environnement.

@Rucknar désolé, je ne le fais pas (il y en a peut-être un dans cette discussion, je n'ai pas relu tous les commentaires)

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

@Rucknar si vous faites défiler un peu vers le haut - vous verrez le lien vers le patch http://www.spinics.net/lists/netdev/msg351337.html. Il est maintenant dans Linux master, je suppose qu'il ira à Linux 4.4, peut-être que quelqu'un l'avait déjà rétroporté vers les versions précédentes, mais pas sûr.

Merci à tous, je vais voir ce qui est nécessaire pour la mise à niveau.

FWIW J'ai rétroporté le dernier patch mentionné ici sur ubuntu 3.19 et j'ai également testé sur le noyau 4.2 sans succès. Le problème est toujours présent même sur la branche net-next 4.4-rc3 à ce stade.

@rsampaio Comment as-tu testé ça ? Je ne peux pas déclencher cette erreur de manière fiable en utilisant docker, en fait, sur n'importe quel noyau. Cela arrive juste parfois.

@fxposter nous ne pouvons pas non plus reproduire le problème en dehors de la production, j'ai donc dû démarrer quelques instances avec le noyau corrigé en production, cela arrive si fréquemment que je peux savoir si un noyau est affecté dans les 24h suivant la charge de production.

Parfois, nous le réparons avec une ressource très inhabituelle : nous déplaçons les répertoires de conteneurs loin de /var/lib/docker/aufs/mnt

Avec cela... PEUT-ÊTRE que nous pouvons « redémarrer le docker de service » et déplacer les répertoires en arrière.

Sinon... seulement en redémarrant.

@rsampaio tu parles de la production heroku maintenant ? Comment éviter ce problème, car toute votre entreprise est construite autour de conteneurs/etc ?

@rsampaio utilisez-vous --userland-proxy=false ou juste une grande quantité de conteneurs créés ? Je peux le reproduire assez facilement avec --userland-proxy=false et avec un peu de charge sans :)

@ LK4D4 Je pense qu'il ne s'agit que d'une grande quantité de conteneurs créés/détruits, en particulier des conteneurs faisant beaucoup de trafic sortant, nous utilisons également LXC au lieu de docker mais le bogue est exactement le même que celui décrit ici, je peux essayer de reproduire en utilisant votre méthode si elle est facile à décrire et/ou n'implique pas de charge de production, l'idée est d'obtenir un crashdump et _peut-être_ de trouver plus d'indices sur ce qui déclenche exactement ce bogue.

@rsampaio Je peux reproduire avec une utilisation prolongée de https://github.com/crosbymichael/docker-stress

Y a-t-il eu des mises à jour/propositions pour résoudre ce problème ?

@joshrendek c'est un bogue du noyau. On dirait que même le noyau 4.4 nouvellement publié ne le résout pas, il y a donc au moins une autre condition de concurrence quelque part :)

bogue du noyau
image

=)

@samvignoli pouvez-vous garder vos commentaires constructifs ? N'hésitez pas à ouvrir un PR si vous avez des moyens de résoudre ce problème.

Ce bogue a-t-il déjà été signalé en amont (liste de diffusion du noyau) ?

Sûr a été. le premier commentaire fait également référence à ce bogue : https://bugzilla.kernel.org/show_bug.cgi?id=81211

Ouvert depuis 2014. Aucun commentaire de quiconque y travaille, sauf pour dire qu'il s'agit très probablement d'une application qui l'utilise de manière incorrecte.

Merci pour le lien Justine ! Je vais troller Linus =)

sincères amitiés. =* :coeur:

@samvignoli s'il vous plaît ne faites pas cela, cela n'aide personne.
Quelqu'un peut-il reproduire cela dans une petite image de VM ?
Peut-être que je peux me salir les mains avec gdb et beaucoup de kprintf.

bug toujours ouvert.

Système d'exploitation : CentOS 7.2
noyau : 4.4.2 elrepo kernel-ml
docker : 1.10.2
fs : superpositions avec xfs

Journal:

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

ce journal s'affiche lors de l'exécution de l'image docker de sameersbn/docker-gitlab :

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

J'ai peut-être de la chance - mais après avoir appliqué ces paramètres sysctl, l'occurrence de cet événement a considérablement diminué.

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 quelle est la motivation derrière ces paramètres ?

@kmike c'était pour résoudre d'autres problèmes de conntrack (les tables ip se

Pourriez-vous montrer l'avant/après afin que nous puissions voir ce qui a réellement changé ? êtes-vous prêt à effectuer une recherche binaire dans ces paramètres et à voir s'il existe un ensemble plus petit ?

J'utilise CoreOS Stable (899.13.0) dans une VM Compute Engine. Cette erreur se produit chaque fois que je démarre le serveur avec le drapeau suivant à 0 (par défaut). J'ai testé plusieurs fois d'avant en arrière et avec IPv6 désactivé, je peux démarrer tous les conteneurs du nœud sans aucune erreur :

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

J'utilise le conteneur gcloud pour télécharger à partir de GCR, alors peut-être que le problème est IPv6 + téléchargement de Mo d'images + fermeture rapide des conteneurs.

Version Docker pour référence :

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

J'ai également testé les indicateurs sysctl précédents dans ce numéro ; mais certains ont déjà cette valeur et le reste ne semble rien changer en rapport avec cette erreur :

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

Je vois toujours le problème lorsque je définis net.ipv6.conf.all.disable_ipv6=1.

L'outil de stress docker peut produire le problème très facilement.
https://github.com/crosbymichael/docker-stress

C'est le binaire que j'ai construit pour l'outil ci-dessus.
https://storage.googleapis.com/donny/main
https://storage.googleapis.com/donny/stress.json

Une fois que nous voyons le journal "unregister_netdevice: wait for veth6c3b8b0 pour devenir libre. Compte d'utilisation", docker se bloque. Je pense qu'il s'agit d'un problème de noyau déclenché par docker. Cela ne se produira que lorsque docker userland-proxy est désactivé (--userland-proxy=false).

Cela s'est produit avec et sans proxy utilisateur activé, donc je ne dirais pas seulement quand il est éteint.

Il se peut que cela aggrave la situation ; Je sais que nous avons déjà essayé de faire de --userland-proxy=false la valeur par défaut, mais nous y sommes retournés car il y avait des effets secondaires https://github.com/docker/docker/issues/14856

J'ai également vu l'erreur une fois depuis hier, désactivant clairement IPv6, ce n'est pas un correctif; mais sans le drapeau, je ne peux même pas démarrer tous les conteneurs du serveur sans supprimer docker.

Exécuter cela sur CoreOS 1010.1.0 avec kubernetes 1.2.2 et docker 1.10.3

Kubernetes a ajouté un indicateur à kubelet (sur mobile, donc je ne peux pas le rechercher) pour
mode épingle à cheveux. Changez-le en "pont promiscuité" ou quel que soit le valide
La valeur est. Nous n'avons pas vu cette erreur depuis ce changement.

@bprashanh

S'il vous plaît confirmer ou réfuter?
Le 13 avril 2016 12:43, "Aaron Crickenberger" [email protected]
a écrit:

Exécuter cela sur CoreOS 1010.1.0 avec kubernetes 1.2.2 et docker
1.10.3

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/docker/docker/issues/5618#issuecomment-209617342

Obtenir cela sur AWS exécutant Linux 4.4.5-15.26.amzn1.x86_64 avec Docker version 1.9.1, build a34a1d5/1.9.1.

Ruby 2.3.0 avec l'image Alpine s'exécute à l'intérieur du conteneur, ce qui provoque cela

kernel :[58551.548114] unregister_netdevice : en attente de la libération de lo. Nombre d'utilisations = 1

Un correctif pour cela?

vu cela pour la première fois sur 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

Quelques redémarrages l'ont corrigé.

@MrMMorris Corrigé car vous êtes certain que le problème a disparu pour de bon, ou que vous ne le rencontrez pas encore pour l'instant? Peut-être une condition de course...

Il est assez clair qu'il s'agit d'une course dans le noyau, perdant un refcount
quelque part. C'est un bug VRAIMENT difficile à suivre, mais pour autant que nous puissions en juger
existe encore.

Le lundi 2 mai 2016 à 22h52, Sune Keller [email protected]
a écrit:

@MrMMorris https://github.com/MrMMorris Corrigé comme dans vous êtes certain que le
le problème a disparu pour de bon, ou en ce que vous ne le rencontrez plus
à l'instant? Peut-être une condition de course...

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/docker/docker/issues/5618#issuecomment-216444133

Ouais. J'ai essayé CoreOS 1032.0.0 avec le noyau 4.5 et le problème persiste.

J'ai rencontré cela à nouveau sur CoreOS 1010.1.0 avec le noyau 4.5.0 hier, c'était après que plusieurs conteneurs aient été démarrés et tués en succession rapide.

J'ai cette erreur.

Version Docker : 1.9.1
Version du noyau : 4.4.8-20.46.amzn1.x86_64
Système d'exploitation : Amazon Linux AMI 2016.03

@sirlatrom non corrigé. Voir cela à nouveau 😭 Nécessité de plusieurs redémarrages pour résoudre.

En cours d'exécution 3.19.0-18-generic. J'essaierai de passer à la dernière version

pareil ici! :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer : :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: : pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer : :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: : pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer : :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: : pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleure: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer : :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer: :pleurer:

@samvignoli vos commentaires ne sont pas constructifs. Merci d'arrêter de publier.

désolé, j'ai oublié la fonction pouce levé.

Reproduit dans Fedora Server 23 - 4.2.5-300.fc23.x86_64. Impossible de redémarrer le service Docker - redémarrez uniquement le nœud.

Même problème sur Fedora 24 Kernel : 4.5.2-302.fc24.x86_64. n'a causé aucun blocage, mais spamme un fichier journal.

@hapylestat Pouvez-vous essayer systemctl restart docker ? Cela a fait que tout pendait pour moi.

Merci

Cela arrive assez fréquemment sur mes machines (CoreOS, EC2). Au cas où cela vous serait utile, voici tous les journaux liés au périphérique veth bloqué dans une instance de ce bogue.

$ 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

Cela semble se produire lorsque je supprime plusieurs conteneurs à la fois (dans mon cas, lorsque je supprime en masse les pods k8s).

Pour ceux qui disent qu'un redémarrage l'a corrigé - avez-vous redémarré ou arrêté/démarré les machines ? Sur les machines physiques, j'ai dû utiliser une réinitialisation d'alimentation à distance pour faire redémarrer la machine.

@joshrendek , j'ai dû utiliser le démarrage à froid d'iLO (c'est-à-dire un cycle d'alimentation physique).

@joshrendek J'ai maintenant un script qui s'exécute et qui fait reboot -f quand cela se produit 😢.

J'ai peut-être trouvé le problème (ou j'ai juste eu de la chance). J'ai déplacé le répertoire graphique Docker d'un disque partitionné XFS vers un disque partitionné EXT4 et je ne peux pas reproduire le problème (ainsi que résoudre une charge d'autres bogues XFS que j'obtenais). Je me souviens de @vbatts disant que XFS n'est pas encore pris en charge.

J'ai essayé de provoquer en exécutant build , run , stop , delete dans une boucle infinie sur diverses images, créant environ 10 conteneurs à chaque cycle, pour les dernières heures.

@joedborg, quel pilote

@thaJeztah Bon point, j'aurais dû le mentionner. J'utilise le pilote Overlay avec (maintenant) EXT4 supportant FS.

J'avais l'habitude d'utiliser devicemapper (parce que j'utilise Fedora Server), mais j'ai eu beaucoup de mal (comme je pense que beaucoup le font), en particulier avec les fuites où le mappeur ne renvoyait pas d'espace au pool une fois qu'un conteneur avait été supprimé.

Si cela peut aider, je suis sur Docker 1.11.1 et Kernel 4.2.5-300.fc23.x86_64.

@joedborg intéressant, car la documentation RHEL mentionnait que seul EXT4 est pris en charge sur RHEL/CentOS 7.1 et uniquement XFS sur RHEL/CentOS 7.2. Je me serais attendu à ce que XFS fonctionne sur des versions plus récentes alors

@thaJeztah ah c'est étrange. J'essaie de penser à d'autres choses que cela pourrait être. J'ai relu depuis le début et il semble que certaines personnes utilisent la même configuration. La seule autre chose qui diffère est que le disque XFS est un axe et que l'EXT4 est un SSD. Je vais continuer les tests de trempage en attendant. J'ai également déplacé prod pour utiliser la même configuration, donc de toute façon, nous aurons une réponse avant longtemps. Cependant, cela fonctionnait sur presque tous les stop auparavant, donc c'est certainement mieux.

@joedborg bien, c'est une information utile en effet

même erreur ici, du noyau 4.2 à 4.5, même version de docker.

BTW, j'exécute plusieurs machines virtualbox sur la même boîte en même temps.

$ 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

Je rencontre ce problème en utilisant le pilote graphique overlay , avec le répertoire sur un ext4 FS. Donc je ne pense pas que xfs soit le problème 😢

@obeattie Oui, il semble que les gens l'obtiennent aussi sur devicemapper . Touchez du bois, je n'ai plus eu le problème depuis le changement. Comme mentionné, j'ai également échangé le disque physique. Cela va être intéressant !

Ce problème n'a aucun rapport avec le système de fichiers. J'ai vu ce problème avec zfs, overlayfs, devicemapper, btrfs et aufs. Aussi avec ou sans échange. Ce n'est même pas limité à docker, j'ai aussi rencontré le même bug avec lxc. La seule solution de contournement, que je vois actuellement, est de ne pas arrêter le conteneur simultanément.

si cela peut aider, j'obtiens le même message d'erreur sur la dernière instance ec2 soutenue par AWS AMI. la version docker montre-

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

Il suffit de monter à bord. Je constate le même comportement sur la dernière instance Amazon ec2. Après un certain temps, le conteneur se renverse et ne répond plus.

$ informations sur le docker
Conteneurs : 2
Images : 31
Version du serveur : 1.9.1
Pilote de stockage : mappeur de périphériques
Nom de la piscine : docker-202:1-263705-pool
Taille du bloc de piscine : 65,54 ko
Taille de l'appareil de base : 107,4 Go
Système de fichiers de sauvegarde :
Fichier de données : /dev/loop0
Fichier de métadonnées : /dev/loop1
Espace de données utilisé : 1,199 Go
Espace de données total : 107,4 Go
Espace de données disponible : 5,754 Go
Espace de métadonnées utilisé : 2 335 Mo
Espace de métadonnées total : 2,147 Go
Espace de métadonnées disponible : 2,145 Go
Udev Sync pris en charge : vrai
Suppression différée activée : false
Suppression différée activée : false
Nombre de périphériques supprimés différés : 0
Fichier de boucle de données : /var/lib/docker/devicemapper/devicemapper/data
Fichier de boucle de métadonnées : /var/lib/docker/devicemapper/devicemapper/metadata
Version de la bibliothèque : 1.02.93-RHEL7 (2015-01-28)
Pilote d'exécution : natif-0.2
Pilote de journalisation : fichier json
Version du noyau : 4.4.10-22.54.amzn1.x86_64
Système d'exploitation : Amazon Linux AMI 2016.03
Processeurs : 1
Mémoire totale : 995,4 Mio
Nom : [expurgé]
ID : OB7A:Q6RX : ZRMK:4R5H : ZUQY:BBNK : BJNN:OWKS :FNU4:7NI2: AKRT:5SEP

$ version docker
Client:
Version : 1.9.1
Version de l'API : 1.21
Version Go : go1.4.2
Validation Git : a34a1d5/1.9.1
Construit:
OS/Arch : linux/amd64

Serveur:
Version : 1.9.1
Version de l'API : 1.21
Version Go : go1.4.2
Validation Git : a34a1d5/1.9.1
Construit:
OS/Arch : linux/amd64

Identique aux commentaires ci-dessus, l'exécution sur EC2 se fait également via un haricot élastique en utilisant 64bit Amazon Linux 2016.03 v2.1.0 running Docker 1.9.1

Un peu anecdotique pour le moment, mais j'ai récemment essayé de passer du noyau 4.2.0 au noyau 4.5.5 sur environ 18 serveurs à titre de test, et ce problème s'est considérablement aggravé (de plusieurs jours à pas plus de 4 heures entre les problèmes).

C'était sur Debian 8

Exactement la même configuration que @g0ddard

Vous cherchez à voir comment nous pourrions être en mesure d'atténuer ce bug.
La première chose (qui peut fonctionner ou non, c'est risqué) est de garder l'API disponible dans les cas où cela se produit : #23178

Bonjour. J'ai aussi été piqué par ce bug...

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

J'utilise Kubernetes 1.2.4 sur CoreOS Beta, Flannel et je m'exécute sur Azure. Existe-t-il un moyen d'aider à déboguer ce problème ? Le fil de bogue du noyau semble mort. Certaines personnes signalent que la désactivation d'IPv6 sur le noyau, l'utilisation de --userland-proxy=true ou l'utilisation de aufs au lieu de l'aide au stockage de superposition, tandis que d'autres ne le font pas... C'est un peu déroutant.

Comme @justin8, j'ai également remarqué cela après la mise à niveau de mon système Fedora 23 vers le noyau 4.5.5; le problème persiste avec le noyau 4.5.6.

Nous avons rencontré ce bogue lorsque le conteneur atteignait sa limite de mémoire. Je ne sais pas si c'est lié ou non.

même problème ici

# 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
le même problème

J'ai un "one liner" qui finira par reproduire ce problème pour moi sur un EC2 (m4.large) exécutant CoreOS 1068.3.0 avec le noyau 4.6.3 (donc très récent). Pour moi, cela prend environ 300 itérations mais YMMV.

Linux ip-172-31-58-11.ec2.internal 4.6.3-coreos #2 SMP Sam 25 juin 00:59:14 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2676 v3 @ 2,40GHz GenuineIntel GNU/Linux
CoreOS bêta (1068.3.0)
Docker version 1.10.3, build 3cd164c

Quelques centaines d'itérations de la boucle ici finiront par bloquer dockerd et le noyau émettra des messages d'erreur comme

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

La boucle de reproduction est

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

MODIFICATIONS

  • Je n'ai pu reproduire avec cela que lorsque userland-proxy=false
  • Je n'ai PAS pu reproduire en utilisant VirtualBox (seulement ec2 jusqu'à présent) alors peut-être que c'est aussi lié à l'hyperviseur

Le script de @btalbot , ci-dessus, ne reproduit pas le problème pour moi sur Fedora 23 après plusieurs milliers d'itérations.

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

Ce problème se produit assez fréquemment sur mon cluster Kubernetes, mais je ne peux pas le reproduire de manière fiable avec les stresseurs ou la doublure unique de

La première machine virtuelle était un Standard_D1_v2 (3,5 Go de RAM, 1 cœur) - le script a fait > 3000 itérations.
La deuxième VM était une Standard_DS15_v2 (140 Go de RAM, 20 cœurs) - le script a fait > 7600 itérations.

J'ai mis à jour mon commentaire précédent (https://github.com/docker/docker/issues/5618#issuecomment-229545933) pour inclure que je ne peux le reproduire que lorsque userland-proxy=false.

Il se reproduit pour moi sur les machines virtuelles EC2 t2.micro (single core) ainsi que m4.large (multi core) à la fois en utilisant HVM. Je ne l'ai pas encore vu en utilisant VirtualBox sur mon ordinateur portable, quel que soit le paramètre de userland-proxy.

Nous avons rencontré ce bogue lors de l'utilisation de Flannel avec hairpin-veth activé sur le cluster kubernetes (à l'aide du proxy iptables). Ce bogue se produisait uniquement lorsque nous exécutions et arrêtions trop de conteneurs. Nous passons à l'utilisation du réseau de pont cbr0 et du mode en épingle à cheveux à pont de promiscuité et ne le revoyons plus jamais.
En fait, il est facile de reproduire ce bogue si vous utilisez hairpin-veth, commencez simplement ce travail avec 100 conteneurs avec kubernetes.

Le 01/07/2016 08:01, manoj0077 a écrit :

@btalbot https://github.com/btalbot donc avec 1.12 nous pouvons redémarrer
dockerd sans affecter les conteneurs en cours d'exécution. Donc dockerd redémarrerait
aider ici dans ce cas?

AFAICT, événement avec 1.12, les processus de conteneurs docker sont toujours des enfants
du démon docker.

@sercand comment avez-vous défini le mode épingle à cheveux promiscuous-bridge? Je ne vois aucune documentation de docker à ce sujet, ou peut-être qu'ils utilisent un nom différent

Y a-t-il un mot officiel de Docker 🐳 sur le moment où cela pourrait être examiné ? C'est le deuxième problème ouvert le plus commenté ; est très sévère (nécessitant un redémarrage de l'hôte) ; est reproductible ; et je ne vois pas de réel progrès pour cerner la cause profonde ou la réparer 😞.

Cela semble très probablement être un problème de noyau, mais le ticket sur Bugzilla stagne depuis des mois. Serait-il utile d'y poster nos cas de test ?

@justin8 Je pense que ce sont des drapeaux Kubelet : --configure-cbr0 et --hairpin-mode

@sercand J'utilise aussi la flanelle. Y a-t-il un inconvénient à utiliser --hairpin-mode=promiscuous-bridge ?

@obeattie je suis d'accord. :(

FTR J'ai réussi à reproduire le problème en utilisant le travail de

@sercand Pourriez-vous s'il vous plaît détailler les étapes pour commencer à utiliser promiscuous-bridge ? J'ai ajouté le drapeau --configure-cbr0=true au kubelet du nœud mais il se plaint :
ConfigureCBR0 requested, but PodCIDR not set. Will not configure CBR0 right now . Je pensais que ce PodCIDR était censé venir du maître ? Merci.

EDIT : Il semble que je devais ajouter --allocate-node-cidrs=true --cluster-cidr=10.2.0.0/16 à la configuration du gestionnaire de contrôleur, mais comme je n'ai pas de fournisseur de cloud (Azure), les routes ne fonctionneront probablement pas.

@ justin8 J'ai suivi cette doc .
@edevil de la documentation

@sercand Selon la doc, si nous utilisons --allocate-node-cidrs=true sur le gestionnaire de contrôleur, nous sommes censés utiliser un fournisseur de cloud pour qu'il configure les routes. Puisqu'il n'y a pas de fournisseur de cloud Kubernetes pour Azure, n'avez-vous pas eu de problèmes ? Configurez-vous les itinéraires manuellement ? Merci.

@edevil J'utilise terraform pour créer des itinéraires. Vous pouvez le trouver dans ce dépôt . J'ai rapidement créé cette configuration et testé une seule fois. J'espère que cela suffira à fournir une logique de base derrière cela.

@morvans @btalbot as -tu eu la chance d'essayer avec la 1.12...?

Je peux confirmer qu'en m'éloignant de hairpin-veth et en utilisant le pont cbr0, je ne peux plus reproduire le problème.

Juste au cas où : quelqu'un a-t-il ce problème sur le bare metal ? Nous avons vu cela lors du test du cluster rancher sur notre laboratoire VMWare, mais jamais vu sur un véritable déploiement bare metal.

Oui, ce problème se produit sur bare metal pour n'importe quel noyau >= 4.3. J'ai vu cela sur de nombreuses machines et configurations matérielles différentes. La seule solution pour nous était d'utiliser le noyau 4.2.

Cela se produit certainement toujours sur 4.2, mais c'est un ordre de grandeur plus souvent sur quelque chose de plus récent, j'ai testé chaque version majeure pour voir si c'est mieux, et rien pour le moment

Se produit également sur CoreOS alpha 1097.0.0.

Noyau : 4.6.3
Docker : 1.11.2

J'obtiens le même problème.

Docker : 1.11.2
Noyau : 4.4.8-boot2docker.

Hôte : Docker-machine avec pilote VMWare Fusion sur OS X.

Des solutions de contournement suggérées?

Ce serait vraiment utile si ceux d'entre vous qui peuvent reproduire le problème de manière fiable dans un environnement où un crashdump est possible (aka pas EC2) pouvaient en fait partager ce fichier de crashdump, plus d'informations sur la façon d'activer kdump dans ubuntu trusty peuvent être trouvées ici et voici les options de crash que vous devez activer lorsque kdump est prêt à générer un crashdump :

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

Le crashdump peut vraiment aider les développeurs du noyau à en savoir plus sur la cause de la fuite de référence, mais gardez à l'esprit qu'un crashdump inclut également un vidage mémoire de votre hôte et peut contenir des informations sensibles.

...informations sensibles.

:o

Je rencontre le même problème.

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

Même problème:

Ubuntu 14.04.4 LTS (GNU/Linux 3.19.0-25-generic x86_64)
Docker version: 1.10.3

Vient de se passer directement sur l'écran du terminal :

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

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

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

le système est

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

Même problème

Os: Amazon Linux AMI release 2016.03
Docker: 1.9.1

Ici aussi:

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

Je vois le même problème sur 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

(sur tous mes pty + beeper quand cela arrive)
« simplement » Debian Jessie + rétroporte :

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

Bonjour,

Lorsque j'essaie de reproduire le problème dans un environnement contrôlé en créant de nouvelles images destructrices, je ne peux pas le reproduire.

Le problème a été soulevé sur l'un des serveurs exécutant docker 1.9.1

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

Jusqu'à présent, j'ai déjeuné le conteneur 17753 en mode simultané et en augmentant le trafic vers Internet, sans aucune fuite de l'interface veth *. Quelqu'un peut-il coller des instructions pour reproduire systématiquement le problème ?

@pegerto devrait être assez facile à déclencher si vous avez --userland-proxy=false et que vous lancez un tas de conteneurs simultanément. Je le fais en utilisant https://github.com/crosbymichael/docker-stress

Merci @cpuguy83

Configurer le démon pour avoir --userland-proxy=false Je peux facilement reproduire le problème, merci, nous pouvons voir ce problème affecter les démons qui n'exécutent pas cette configuration.

Je vois un vidage du noyau au niveau du hook netfilter introduit par la ségrégation netns à >=4.3, pourquoi le problème semble-t-il pire lorsque la route se produit à 127/8 ?

Merci

Voir ce problème aussi. CoreOS 1068.8.0, Docker 1.10.3, noyau 4.6.3. J'ai extrait certains des journaux système si quelqu'un est intéressé.

Je viens d'en avoir plusieurs...
unregistered_netdevice: waiting for lo to become free. Usage count = 1
... sur 2 VM et sur mon ordinateur portable baremetal, tous exécutant Ubuntu 16.04 et les derniers noyaux (4.4.0-3[456]).

Le résultat est que tout se bloque et nécessite un redémarrage brutal.
Je n'ai pas connu cela avant la semaine dernière et je pense que l'une des VM était sur 1.11.3 tandis que les autres étaient toutes sur 1.12.0.

@RRAlex Ceci n'est spécifique à aucune version de docker.
Si vous utilisez --userland-proxy=false sur les options du démon... OU (d'après ce que j'ai compris) vous utilisez kubernetes, vous rencontrerez probablement ce problème.

La raison en est que l'option --userland-proxy=false active le NAT en épingle à cheveux sur l'interface du pont... c'est quelque chose que kubernetes définit également lorsqu'il configure la mise en réseau pour ses conteneurs.

Voir cela sur un nœud BYO à l'aide de Docker Cloud (et de l'agent Docker Cloud).

J'ai vu cela aujourd'hui, une fois (sur environ 25 essais) sur les AMI Amazon ECS actuelles, en exécutant vanilla debian:jessie avec une commande qui apt-get met à jour, installe pbzip2, puis l'exécute (simple test de processeur multithread).

@edevil
La plupart d'entre vous ici décrivent que vous rencontrez cette situation en utilisant Docker pour démarrer/arrêter des conteneurs, mais j'ai exactement la même situation sans Docker, sur Debian :

  • Debian "Jessie" (=Debian version 8.5), sur baremetal (pas de VM, pas de cloud, mais du matériel simple)
  • noyau 3.16.0-4-amd64
  • avoir 4 conteneurs LXC démarrés
  • fermez un conteneur LXC avec "lxc-stop -n $containerName"
  • lorsque cette commande se termine, le noyau ou les interfaces ne sont probablement pas encore entièrement "nettoyés", car lorsque je lance immédiatement après le précédent "lxc-stop" un nouveau "lxc-stop", alors j'ai le problème du noyau

Aucun moyen de récupérer sauf une réinitialisation matérielle de la machine.

Alors s'il vous plaît, dans vos enquêtes pour identifier / résoudre ce problème, ne vous concentrez pas uniquement sur Docker. Il est évident qu'il s'agit d'un problème générique avec les arrêts/démarrages rapides des conteneurs, que ce soit via Docker ou via des commandes "lxc" simples.

Je pense que c'est un problème de noyau Linux.

J'ai rencontré ce problème lorsque j'ai 3 chroot (en fait pbuilder) en cours d'exécution avec une charge très lourde.
Mon matériel est Loongson 3A (une machine mips64el avec noyau 3.16).

Lorsque j'essaie de m'y connecter, j'ai rencontré ce problème.

Donc, ce problème ne concerne pas seulement docker ou lxc, mais aussi chroot.

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

Metal à nu.

Nous avons eu le problème dernièrement sur bare metal (dédié à ovh) avec le kernel 4.6.x et le docker 1.11.2.
Après avoir lu les commentaires ici et essayé plusieurs solutions de contournement, nous avons rétrogradé notre noyau vers la dernière version de la branche 3.14 (3.14.74) et mis à niveau le docker vers 1.12.0 pour éviter https://github.com/docker/libnetwork/issues/1189 et tout semble s'arranger pour le moment.

J'espère que cela peut aider.

Tout, je pense que vous n'avez plus besoin de poster de messages sur Docker ou chroot, tout tourne autour du noyau Linux.
Alors, s'il vous plaît, quelqu'un peut-il se lever pour déboguer d'une manière ou d'une autre le noyau, dans les parties où il désactive les interfaces réseau virtuelles pour les conteneurs ? Peut-être qu'il y a des conditions de concurrence qui se produisent lorsqu'un arrêt précédent d'un conteneur n'a pas encore entièrement désactivé/nettoyé son interface virtuelle, avant qu'un nouvel arrêt d'un conteneur ne soit demandé.

@rdelangh Je ne pense pas que ce problème soit nécessairement lié au noyau.

Sur Fedora 24, je ne peux pas reproduire le problème avec Docker 1.10.3 des dépôts Fedora, uniquement avec Docker 1.12.1 des propres dépôts Docker.

Les deux tests ont été effectués avec le noyau 4.6.7-300.fc24.x86_64.

Voir ce problème également sur CoreOS 1068.10.0, Docker 1.10.3, noyau 4.6.3.

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

En utilisant Kubernetes 1.3.4 sur CoreOS 1068.9.0 stable sur EC2, docker 1.10.3, je vois ce problème.

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

Voir ce problème également sur Ubuntu 16.04, Docker 1.12.1, noyau 4.4.0-34-generic
waiting for lo to become free. Usage count = 1

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

...

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

Pour ceux qui utilisent Kubernetes <= 1.3.4, vous pouvez exploiter ce problème : https://github.com/kubernetes/kubernetes/issues/30899 pour reproduire ce problème. J'ai exécuté un petit cluster avec 1 contrôleur (m4.large) et 2 travailleurs (m4.large) sur CoreOS 1068.10.

À partir de là, vous pouvez créer 2 ReplicationControllers, je les ai appelés hello et hello1 fonction de ceci : http://pastebin.com/mAtPTrXH . Assurez-vous de changer les noms et les étiquettes pour qu'ils soient différents.

Ensuite, créez 2 déploiements correspondant aux mêmes noms/étiquettes que ci-dessus en fonction de ceci : http://pastebin.com/SAnwLnCw .

_Dès que vous créez les déploiements, vous obtenez une quantité folle de conteneurs de spam_.

Si vous le laissez allumé pendant un certain temps (plusieurs minutes), vous verrez beaucoup de choses essayer de terminer/créer. Vous pouvez supprimer les déploiements et laisser les choses se stabiliser. Vous devriez voir une bonne poignée Terncing et ContainerCreating. Si vous ssh dans les nœuds, vérifiez dmesg et docker ps pour voir si les symptômes ci-dessus sont apparents.

Dans mon cas, il m'a fallu environ 5 minutes pour laisser cette panique avant de voir le problème. Je prévois d'apporter les modifications avec lesquelles @sercand et @edevil jouaient et de voir si cela fonctionne pour moi dans ce cas.

@edevil Après avoir examiné votre commit lié, ai-je raison de dire que vous avez complètement désactivé/supprimé Flannel dans votre environnement en faveur du pont cbro créé par Kubernetes pour surmonter ce problème ?

Je vois de mon côté que vous ne seriez pas en mesure de les utiliser en tandem parce que la flanelle veut utiliser docker0 et que votre réseau interne fonctionnerait sur cbr0 correct ?

@ alph486 c'est correct, j'ai arrêté d'utiliser de la flanelle. J'utilise le pont et configure les routes pour le réseau de pods.

@ alph486 flannel ne veut pas utiliser docker0. C'est juste le pont par défaut pour docker, que vous pouvez remplacer avec l'option docker --bridge=cbr0 .
Sur CoreOS, vous devrez remplacer l'unité docker systemd.

Le drapeau Kubelet --experimental-flannel-overlay peut lire la configuration flannel et configurer le pont docker cbr0 avec le flannel CIDR.

Il activera également le mode promiscuous au lieu de veth-hairpin qui semble être le problème.

Merci @dadux pour la contribution. Si K8s récupère l'interface cbr0 qui a déjà été amorcée par l'unité surchargée, pourrait être en affaires avec cette solution ; Je vais l'essayer.

Selon la documentation, promiscuous-bridge semble être la valeur par défaut pour --hairpin-mode dans kubelet v1.3.4+. Je vois toujours le problème avec cela, donc je ne suis pas tout à fait sûr que ce soit la solution complète.

Je n'ai pas pu reproduire le problème après avoir utilisé le plugin réseau kubenet (qui est configuré pour remplacer --configure-cbr0 ). J'évite en quelque sorte l'option flannel-overlay raison de l'incertitude de son avenir (elle semble être liée à --configure-cbr0 ).

Si votre démon docker utilise le pont docker0 , la définition de --hairpin-mode=promiscuous-bridge n'aura aucun effet car le kubelet essaiera de configurer le pont inexistant cbr0 .

Pour CoreOS, ma solution de contournement pour refléter le comportement de Kubernetes mais toujours en utilisant la flanelle :

  • Ajoutez un drop-in systemd pour docker.service pour configurer l'interface du pont docker0 en mode promiscuité. (Sûrement qu'il y a une envie plus élégante de faire ça ?) :
- 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
  • Dites au kubelet de ne pas mettre d'épingle à cheveux dans le pont docker :
    kubelet --hairpin-mode=none

Vous pouvez vérifier si l'épingle à cheveux est activée pour vos interfaces avec
brctl showstp docker0
ou
for f in /sys/devices/virtual/net/*/brport/hairpin_mode; do cat $f; done

Je pense que mon collègue a corrigé cela récemment http://www.spinics.net/lists/netdev/msg393441.html , nous avons rencontré ce problème dans notre environnement et ensuite nous avons trouvé le problème, avec ce correctif, nous ne rencontrons jamais ce problème aucun Suite. Toute personne ayant rencontré ce problème pourrait essayer ce correctif et voir si cela se reproduisait. Et d'après notre analyse, il s'agit d'ipv6, vous pouvez donc également essayer de désactiver ipv6 de docker avec --ipv6=false lors du démarrage du démon docker

@ coolljt0725 Peut-être que je me trompe, mais ipv6 est désactivé par défaut dans docker et je viens de reproduire le problème via docker-stress avec l'option "--ipv6=false" (qui est la valeur par défaut de toute façon). Je n'ai pas encore essayé votre patch.

@dadux Merci pour votre aide. Sur Kubernetes 1.3.4 CoreOS 1068 Stable, Docker 10.3, Flannel en tant que couche réseau, j'ai résolu le problème en apportant les modifications suivantes à mes unités CoreOS :

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

Ajout des éléments suivants à kubelet.service :

        --hairpin-mode=none

Quel effet ces changements sur Docker/Kubernetes ont-ils en ce qui concerne la façon dont le système d'exploitation gère les interfaces pour les conteneurs ?
Je dois souligner qu'il s'agit d'un problème de mauvais comportement du système d'exploitation, et non de Docker ou de Kubernetes, car nous (et d'autres personnes dans ce fil de discussion) n'exécutons pas du tout Docker ou Kubernetes, mais rencontrons toujours exactement les mêmes situations lors de l'arrêt de LXC conteneurs assez rapidement les uns après les autres.

@rdelangh Vous avez raison. Cependant, ce problème a été créé dans le projet Docker pour suivre le comportement en ce qui concerne Docker. Il y a d'autres problèmes mentionnés dans ce fil de discussion comme un problème de système d'exploitation, un problème K8s et un problème CoreOS. Si vous avez trouvé le problème dans LXC ou autre chose, nous vous recommandons vivement de créer un fil de discussion là-bas et de créer un lien ici pour sensibiliser le public au problème.

Lorsque ceux qui utilisent Docker google pour cette erreur, ils atterriront probablement ici. Il est donc logique que nous publions ici des solutions de contournement à ce problème afin que, jusqu'à ce que les problèmes sous-jacents soient résolus, les utilisateurs puissent aller de l'avant.

Quel effet ces changements sur Docker/Kubernetes ont-ils en ce qui concerne la façon dont le système d'exploitation gère les interfaces pour les conteneurs ?

  1. Le changement de docker dans mon message permet à la pile Kubernetes d'interroger le docker et de s'assurer que la plate-forme est saine lorsque le problème se produit.
  2. le changement hairpin-mode indique essentiellement à K8s d'utiliser le pont docker0 tel quel, et n'essaiera donc pas d'utiliser le réseau "kernel land" et "hairpin veth" qui est l'endroit où le problème commence dans le Docker chemin d'exécution.

C'est une solution de contournement pour ce problème en utilisant K8s et Docker.

Le patch des collègues de coolljt0725 a été mis en file d'attente pour stable, donc j'espère qu'il sera rétroporté dans les distributions assez tôt. (Poste de David Miller : http://www.spinics.net/lists/netdev/msg393688.html )

Vous ne savez pas où se trouve ce commit et si nous devons l'envoyer à Ubuntu, RH, etc. pour les aider à le suivre et à le rétroporter ?

Va apparaître ici à un moment donné, je suppose:
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/ipv6/addrconf.c

EDIT : semble être présent ici : https://github.com/torvalds/linux/blob/master/net/ipv6/addrconf.c

Merci à coolljt0725 et co (et tout le monde dans ce fil). Étant donné que de nombreuses personnes ne pourront pas mettre à jour vers un noyau avec le correctif ipv6 pendant un certain temps (tout le monde actuellement), j'ai réussi à éliminer ce bogue après avoir essayé de nombreuses suggestions de ce fil. Je veux faire un article complet pour faire le suivi des choses qui ont fonctionné et qui n'ont pas fonctionné afin que personne d'autre n'ait à voir les problèmes que j'ai vus.

TL ; DR désactive ipv6 dans les paramètres de démarrage Linux, redémarrez. sur coreos, cela signifie que /usr/share/oem/grub.cfg a le contenu : set linux_append="ipv6.disable=1" puis un redémarrage. une suggestion plus générale qui devrait fonctionner sur centos/ubuntu/debian/$linuxes peut être trouvée ici

  • essayé ipvlan(l2,l3)/macvlan(bridge): ni l'un ni l'autre ne fonctionne sur aws, ou du moins, je ne possède pas et je n'ai pas pu trouver les connaissances nécessaires pour travailler sur aws. par travail, je veux dire, démarrer un conteneur connecté à un réseau avec ipvlan ou macvlan, n'a pas pu pinger la passerelle / se connecter à Internet (oui, j'ai testé l'idée de base en travaillant sur un environnement non-aws). Cela a en fait semblé résoudre le problème, mais pour notre cas d'utilisation, nous devons pouvoir nous connecter à Internet - pour les cas d'utilisation qui ne le font pas, cela peut être une option viable et semble assez sexy par rapport au pont .
  • essayé les drapeaux suivants passés à dockerd individuellement, et avec certaines combinaisons (puisqu'aucune d'entre elles ne semblait fonctionner, je n'étais pas trop scientifique pour essayer toutes les combinaisons):
--ipv6=false
—iptables=false
—ip-forward=false
—icc=false
—ip-masq=false
—userland-proxy=false

Fait intéressant, --ipv6=false ne semble vraiment rien faire -- c'était assez déroutant, les conteneurs recevaient toujours des adresses inet6 avec ce drapeau.

--userland-proxy=false définit le mode épingle à cheveux et n'était pas censé fonctionner vraiment. en conjonction avec cela, j'avais un peu d'espoir, mais cela n'a pas non plus résolu le problème (réglage de docker0 en mode promisc). Il y a une mention d'un correctif à --userland-proxy=false ici et cela peut être en amont bientôt et mérite un autre coup, ce serait bien de le désactiver quel que soit le bogue noté dans ce problème pour les performances mais malheureusement il en a encore un autre bug en ce moment.

  • essayé de désactiver ipv6 via les paramètres sysctl comme documenté ici et de redémarrer systemd-networkd après avoir appliqué les paramètres sysctl, ainsi que d'essayer de désactiver ipv6 de dhcpcd comme documenté ici et ce n'était pas suffisant pour désactiver ipv6 car il est toujours activé, même si aucune interface n'est En l'utilisant.
  • comme cela a été suggéré ici, nous avons essayé cette solution, en ne supprimant qu'un conteneur à la fois, et nous avons toujours rencontré ce bogue.

trop long; a lu : désactivez ipv6 dans vos paramètres grub. redémarrer. profit.

Face à ce problème sur CentOS 7.2 (3.10.0-327.28.3.el7.x86_64) et Docker 1.12.1 (sans k8s). Le problème survient lorsque le trafic réseau augmente.
Le démarrage du noyau avec IPv6 désactivé (conformément aux conseils précédents) n'a pas aidé.
Mais transformer l'interface docker0 en mode promisc a résolu ce problème. Le drop-in systemd utilisé par @dadux (merci!) - semble bien fonctionner maintenant.

@rdallman La désactivation d'ipv6 via grub n'empêche pas unregister_netdevice pour moi dans Ubuntu 16.06 (noyau 4.4.0-36-generic) ou 14.04 (noyau 3.13.0-95-generic). Quel que soit le paramètre --userland-proxy (vrai ou faux).

Ooooh, c'est cool ce patch a été mis en file d'attente pour stable.
ping @aoch pour le problème que --ipv6=false ne fait rien.

@trifle désolé :( merci d'avoir publié des informations, nous n'avons pas encore rencontré de problèmes après quelques jours de test, mais nous mettrons à jour si nous rencontrons des problèmes. nous exécutons coreos 1122.2 (noyau 4.7.0). réglage de docker0 en mode promisc semble résoudre ce problème pour certaines personnes (pas de chance pour nous).

@RRAlex Savez-vous si quelqu'un a contacté l'équipe du noyau Ubuntu concernant un rétroportage ? Nous avons un grand déploiement Docker de production sur un cluster Ubuntu affecté par le bogue.

Liste de diffusion de l'équipe du noyau Ubuntu :
https://lists.ubuntu.com/archives/kernel-team/2016-September/thread.html

Patch pour le noyau stable :
https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d

Journal de validation du noyau Ubuntu :
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/?h=master-next
(Le patch n'est pas encore là)

@leonsp J'ai essayé de les contacter sur ce qui semble être le problème connexe :
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1403152

Si vous regardez la dernière réponse (#79), quelqu'un a construit un noyau pour Xenial avec ce patch :
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1403152

Je ne sais pas quand cela va dans l'arborescence principale du noyau Ubuntu ni quelle est la relation de cette personne avec Ubuntu et si cela va aider ...

Je ne trouve pas non plus les commits mentionnés à partir de ce fil dans le journal des commits du noyau Ubuntu.

@RRAlex Les commits mentionnés se trouvent sur la branche de ddstreet ~ddstreet/+git/ linux:lp1403152-xenial , voici le journal : https://code.launchpad.net/~ddstreet/+git/linux/+ref/lp1403152-xenial
Ainsi, toute personne ayant ce problème sur Ubuntu 16.04 peut l'essayer. https://launchpad.net/~ddstreet/+archive/ubuntu/lp1403152

Peut-être que @sforshee sait (pour le noyau Ubuntu)

J'ai enfin réussi à tester la solution "ipv6.disable=1". En plus de cela, j'ai mis à niveau le noyau 4.7.2 sur ma Debian 8.
Après la mise à niveau du noyau et l'activation de "ipv6.disable=1" dans les paramètres du noyau, j'ai réussi à détecter le problème "en attente de lo" sur la charge de travail réelle, même sans l'indicateur "--userland-proxy=false" pour le démon docker. La bonne nouvelle est qu'après avoir spécifié "--userland-proxy=false" et essayé de reproduire le problème avec "docker-stress" - je ne peux plus le faire. Mais je suis à peu près sûr que cela se reproduira quelle que soit la valeur "--userland-proxy".
Donc, d'après ce que je vois, l'ipv6 est définitivement impliqué dans ce problème, car désormais docker-stress n'est plus en mesure de détecter le problème. La mauvaise nouvelle est que le problème est toujours là (c'est-à-dire qu'il n'est résolu que partiellement).

Compilera la dernière 4.8rc7 plus tard pour en tester davantage.

@twang2218 @coolljt0725

Hmmm.. donc je viens d'essayer le noyau Ubuntu xenial 4.4.0-36 avec le correctif rétroporté à partir du ppa de ddstreet :

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

Malheureusement, cela ne semble pas résoudre le problème pour moi. Notez que je fonctionne également avec "ipv6.disable=1". Recherchons-nous plusieurs causes non liées avec le même résultat ? Beaucoup de commentaires dans ce fil semblent le suggérer.

Je n'en sais pas trop à ce sujet, mais je sais que nous avons déjà eu des bugs comme celui-ci. Si je comprends bien, les décomptes de références vers n'importe quel périphérique réseau finissent par être transférés vers lo lorsqu'un espace de noms réseau est nettoyé, donc "attendre que lo devienne libre" signifie qu'il y a une fuite de décompte de références pour certains périphériques réseau mais pas nécessairement pour lo directement. Cela en fait un problème à localiser, car au moment où vous savez qu'il y a eu une fuite, vous ne savez pas à quel appareil elle était associée.

Je n'ai pas relu tous les commentaires, mais si quelqu'un peut me donner un reproducteur fiable sur Ubuntu, je vais y jeter un coup d'œil et voir si je peux comprendre quelque chose.

@sforshee ce n'est pas toujours facile à reproduire, mais un correctif a été créé (qui corrige au moins certains des cas signalés ici); http://www.spinics.net/lists/netdev/msg393441.html. Cela a été accepté en amont https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d

@thaJeztah ah, je vois la question que vous me posez maintenant.

Le correctif est donc dans la file d'attente stable 4.4 en amont, pour la 16.04, il est susceptible d'être inclus non pas dans le prochain noyau SRU (qui est déjà en cours) mais dans celui d'après, dans environ 5 à 6 semaines. S'il est également nécessaire dans 14.04, veuillez me le faire savoir afin qu'il puisse être rétroporté.

@sforshee essentiellement plus tôt (avant ce correctif) qui pouvait être reproduit en activant ipv6 dans le noyau (généralement activé par défaut), en ajoutant "--userland-proxy=false" aux indicateurs du démon docker, puis en exécutant docker-stress -c 100 , pour exemple (docker-stress vient d'ici : https://github.com/crosbymichael/docker-stress)

@fxposter merci. S'il existe un correctif pour celui-ci, tout ce dont j'ai vraiment besoin de m'inquiéter, c'est d'obtenir ce correctif dans le noyau Ubuntu. Je peux également aider à rechercher d'autres fuites qui ne sont pas corrigées par ce correctif.

J'ai aussi ce problème. J'exécute docker dans une boîte rancherOS d'AWS. En fait, cela se produit de manière aléatoire après la configuration d'un cluster de rancher (3 hôtes) et l'exécution d'une petite application dedans.

même ... Fedora 24, arrive au hasard, peut être bien pendant une semaine, alors j'en reçois un toutes les 10 heures
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Expérience sur CentOS 7 exécutant le noyau 3.10.0-327.36.1.el7 et docker 1.12.1

La rétrogradation vers le noyau 3.10.0-327.18.2.el7 tout en restant sur le docker 1.12.1 semble avoir stabilisé le système.

Je vois aussi ça :
Docker version 1.11.2
Ubuntu 16.04.1 4.4.0-38-générique

IPv6 désactivé (grub)

Je viens d'avoir ce problème sans --userland-proxy=false (sic !) sur le serveur avec le noyau 4.8.0-rc7, qui inclut le patch ipv6 (sic !!). Alors peut-être que cela résout certains des problèmes, mais pas tous, certainement.

Est-ce que n'importe qui sait comment ceci peut être débogué du tout ?

Nous avons découvert que cela ne se produit sur notre configuration que lorsque nous manquons (presque) de mémoire libre.

@fxposter Il serait utile de trouver un cas de reproduction minimal, ce qui est un peu difficile :/ Ensuite, nous pourrions utiliser ftrace pour au moins trouver les chemins de code.

Se passe sur 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 malheureusement, il n'est plus possible de le reproduire via docker-stress (du moins je ne pouvais pas). Je vais essayer d'imiter notre configuration précédente avec des webkits (qui ont déclenché ce problème bien plus souvent que je ne le souhaiterais).

@fxposter Ce correctif ne résout que certains des problèmes (mais dans notre environnement, nous ne le rencontrons plus avec ce correctif), pas tous, je laisserai mon collègue continuer à étudier ce problème. Si vous avez un moyen de reproduire cela, faites-le moi savoir, merci :)

J'ai posté une demande pour que Redhat applique ce correctif à Fedora 24.

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

4.4.0-42 est toujours cassé à coup sûr...
Je l'ai mentionné ici pour Ubuntu, mais peut-être que quelqu'un a une meilleure idée :
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1403152

Je vois aussi ceci, Docker version 1.11.2, build b9f10c9/1.11.2, 64 bits Amazon Linux 2016.03 v2.1.6.

encore arrivé. docker 1.12.2, noyau Linux armbian 4.8.4, ipv6.disable=1 dans bootargs

comment corriger le bug, je le rencontre tous les jours

@woshihaoren Ne pas utiliser --userland-proxy=false

Pour clarifier - nous y avons fait face avec userland-proxy désactivé aussi

Obtenir ceci sur Amazon Linux AMI 2016.9 :

$ uname -a

Linux 4.4.23-31.54.amzn1.x86_64 #1 SMP

Version Docker :

``` Client :
Version : 1.11.2
Version de l'API : 1.23
Version Go : go1.5.3
Validation Git : b9f10c9/1.11.2
Construit:
OS/Arch : linux/amd64

Serveur:
Version : 1.11.2
Version de l'API : 1.23
Version Go : go1.5.3
Validation Git : b9f10c9/1.11.2
Construit:
OS/Arch : linux/amd64
```

noyau centos7 4.4.30 à nouveau ~~~~

CoreOS 1185.3.0, 4.7.3-coreos-r2, Docker 1.11.2
Reproductible en exécutant simplement 10..20 conteneurs

CoreOS stable est actuellement toujours touché. Le correctif pour la série 4.7 est en 4.7.5 : https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.7.5

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

    ipv6: addrconf: fix dev refcont leak when DAD failed

TL; DR - Il n'y a pas de solutions dans ce post, mais je liste ce que j'ai poursuivi jusqu'à présent et mes théories de travail actuelles. J'espère que d'autres personnes qui recherchent également cela pourraient trouver des informations ici utiles pendant que nous examinons cette chose.

@koendc Merci d'avoir publié le correctif qui a été introduit dans 4.7.5. Je backportées la 4e1b3aa898ea93ec10e48c06f0e511de37c35b2d (751eb6b6042a596b0080967c1a529a9fe98dac1d en amont) pièce à ma configuration 4.5.5 [1] et a été en mesure de reproduire facilement le problème de unregister_netdevice. Il est possible que d'autres changements dans le noyau 4.7.x fonctionnent avec le correctif fourni pour résoudre ce problème, mais je ne l'ai pas encore confirmé, nous ne devrions donc pas encore perdre tout espoir. Je teste avec 4.5.5 parce que j'ai un cas de test reproductible pour causer le problème, discuté dans [2].

D'autres choses que j'ai confirmées sur la base des tests :

  • 4.2 est beaucoup plus stable que n'importe quel noyau ultérieur
  • 4.5.x est trivialement reproductible. Parmi les noyaux les plus récents que j'ai testés de manière approfondie (4.8.2 et 4.8.6), le problème existe toujours, bien que le temps jusqu'à la première occurrence variait de 60 à 48 heures.
  • Le problème semble être lié à la fois au trafic réseau et au rapport entre la capacité des conteneurs et la capacité de la ressource parent (cpu virt). Comme d'autres l'ont éludé, cela pourrait être un faux-fuyant s'il s'agit bien d'une condition de course

Prochaines étapes:

  • Instrumenter un noyau avec les instructions printk appropriées pour essayer de trouver un cas où les ressources allouées ne sont pas libérées
  • Testez le noyau 4.7.5 ou ultérieur avec/sans le correctif susmentionné pour voir si le problème se produit
  • Juste avant l'un des plantages, j'ai vu un ensemble très intéressant d'erreurs IPv6: eth0: IPv6 duplicate address <blah> detected . Peut-être un autre hareng rouge, mais je veux essayer d'exercer la désactivation ipv6 pour voir s'il y a une corrélation

[1] Ma configuration complète est une virt GCE exécutant un noyau Debian légèrement personnalisé basé sur 4.5.5 . Docker version 1.8.3, build f4bf5c7 s'exécute en plus de cela
[2] Informations sur le cas de test : j'ai 20 processus parallèles, chacun démarre un serveur Node.js hello world à l'intérieur d'un conteneur Docker. Au lieu de renvoyer hello world , le serveur Node.js renvoie 1 Mo de texte aléatoire. Le processus parent est dans une boucle étroite qui démarre le conteneur, effectue une boucle pour récupérer les 1 Mo de données et arrête le conteneur. En utilisant cette configuration, je peux reproduire systématiquement le problème en 4-90s. L'utilisation de cette même configuration sur un hôte physique ou à l'intérieur de la virtualbox ne reproduit pas le problème, malgré des éléments variables qui modifient le temps moyen de reproduction sur la boîte GCE. Variables avec lesquelles j'ai joué : nombre de processus de test simultanés, taille de la charge utile transférée et quantité d'appels curl. Les deux premières variables sont définitivement corrélées, même si je pense qu'il s'agit probablement simplement d'ajuster les variables afin de trouver un point de saturation raisonnable pour le virt.

Moi aussi j'ai cette erreur.

Je le vois répété 3 fois après le déploiement d'un conteneur.

La description

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

Étapes pour reproduire le problème :

  1. ssh dans l'hôte docker
  2. exécuter un conteneur
docker run -d --network=anetwork --name aname -p 9999:80 aimagename

Décrivez les résultats que vous avez reçus :

Il suffit de répéter l'erreur 3 fois.

Décrivez les résultats que vous attendiez :
Pas d'erreur

Informations supplémentaires que vous jugez importantes (par exemple, le problème n'arrive qu'occasionnellement) :
Ça vient juste de commencer après ce week-end.

Sortie de docker version :

 docker --version
Docker version 1.12.3, build 6b644ec

Sortie de docker info :

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

Détails supplémentaires sur l'environnement (AWS, VirtualBox, physique, etc.) :

Machine virtuelle:
Fedora 24
Superposition FS2 sur ext3

Disque séparé alloué pour docker utiliser 24 Go.
16 Go de ram.

Docker PS

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

Images Docker

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

Docker Volume Ls

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

* DF -H *

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

DF -i

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

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

Pour toutes les personnes intéressées, nous (Travis CI) déployons une mise à v4.8.7 sur Ubuntu 14.04. Nos tests de charge n'ont montré aucune occurrence de l'erreur décrite ici. Auparavant, nous utilisions linux-image-generic-lts-xenial sur Ubuntu 14.04. Je prévois de publier un article de blog dans un proche avenir décrivant plus de détails.


MISE À JOUR : j'aurais dû mentionner que nous exécutons cette pile de docker :

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

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

MISE À JOUR : Nous voyons _toujours_ cette erreur en production sur Ubuntu Trusty + kernel v4.8.7. Nous ne savons pas encore pourquoi ces erreurs ont disparu lors des tests de charge de mise en scène qui reproduisaient auparavant l'erreur, mais le taux d'erreur en production est effectivement le même. En avant et vers le haut. Nous avons désactivé « l'implosion automatique » en fonction de cette erreur étant donné le taux élevé de rotation des instances .

aussi trouvé dans 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

La même chose se passe ici avec un VPS DigitalOcean sur les tests Debian :


# journalctl -p0 | tail -15

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


Système

$ 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

J'ai testé 4.8.8 dans une boucle serrée (voir [2] de mon commentaire précédent pour le cas de test) non-stop au cours des 4 derniers jours. Jusqu'ici tout va bien.

Les faits

  • Le patch 751eb6b6 réduit considérablement l'apparition de ce problème, mais ne l'élimine pas entièrement.

Suppositions
@meatballhat a souligné que leurs serveurs de production ont rencontré le problème lors de l'exécution de 4.8.7. Cela nous laisse deux possibilités :

  • Mon cas de test de test est défectueux (la possibilité la plus probable)
  • 4.8.8 a introduit un correctif. En regardant le journal des

Pouvons-nous demander à quelques personnes d'essayer la version 4.8.8 pour voir s'ils sont capables de reproduire ce problème ?

@reshen Je vais nous mettre à jour vers la version 4.8.8 et faire un rapport :+1 : Merci beaucoup pour vos recherches !

@reshen Excellente recherche. Jusqu'à présent, je n'ai pas non plus été en mesure de reproduire le problème en utilisant Linux 4.8.8 sur Xubuntu 16.04.

J'ai utilisé les versions du noyau principal d'Ubuntu . Je n'ai pas de cas de test bien défini, mais je pouvais reproduire le problème de manière cohérente auparavant en démarrant et en arrêtant l'ensemble de conteneurs docker avec lesquels je travaille.

Pour tester Linux 4.8.8, le plus simple pour moi était de passer de aufs à overlay2 en tant que pilote de stockage car les versions du noyau principal n'incluaient pas aufs. Je ne pense pas que cela influencera le test, mais il convient de le noter.

Dans le passé, j'ai testé Linux 4.4.4 avec le 751eb6b6 rétroporté par Dan Streetman, cela n'a pas semblé réduire le problème pour moi. Il sera intéressant de voir si le rétroportage des deux correctifs que vous avez notés (5086cadf et 6fff1319) peut également donner le même résultat que 4.4.8.

Ubuntu 16.04 avec 4.4.0-47 était toujours affecté... essayer 4.4.0-49 maintenant, rapportera plus tard.

edit: 2016-11-28: -49 affiche toujours cette ligne de journal dans dmesg.

Expérimenté sur Fedora 25 (noyau 4.8.8) et Docker 1.12.3

Pour info : nous avons exécuté Linux 4.8.8 en conjonction avec Docker v1.12.3 sur un seul hôte de production. La disponibilité est actuellement de 5,5 jours et la machine reste stable.

Nous voyons occasionnellement une poignée de messages unregister_netdevice: waiting for lo to become free. Usage count = 1 dans syslog, mais contrairement à avant, le noyau ne plante pas et le message disparaît. Je soupçonne que l'un des autres changements introduits dans le noyau ou dans Docker détecte cette condition et s'en remet maintenant. Pour nous, cela rend désormais ce message ennuyeux mais n'est plus un bug critique.

J'espère que d'autres personnes pourront confirmer ce qui précède sur leurs flottes de production.

@gtirloni - pouvez-vous préciser si votre machine 4.8.8/1.12.3 s'est écrasée ou si vous venez de voir le message ?

Merci d'avance à tous ceux qui ont travaillé à reproduire/fournir des informations utiles pour trianguler cette chose.

nous supprimons la contrepartie de l'interface veth (docker0) après avoir démarré docker et redémarrons docker par la suite lorsque nous provisionnons l'hôte à l'aide d'ansible. Le problème n'est plus survenu depuis.

Je reçois également cette même erreur sur un Raspberry Pi 2 exécutant Raspbian avec Docker.

Informations sur le noyau
Linux rpi2 4.4.32-v7+ #924 SMP Tue Nov 15 18:11:28 GMT 2016 armv7l GNU/Linux

Informations sur le Docker

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

Cela s'est produit après la création d'un conteneur nécessitant l'installation d'environ 50 Mo de programmes téléchargés.

Seul un redémarrage me permettrait d'utiliser à nouveau la machine

Je le vois en fait sur Amazon Linux dans un cluster ECS - le message est parfois émis mais il ne se verrouille pas, comme le voit maintenant reshen. Docker 1.11.2. Uname signale "4.4.14-24.50.amzn1.x86_64" comme version.

@reshen Je vais construire 4.8.8 ce week-end sur mon ordinateur portable et voir si cela
le corrige pour moi!
??

Le jeu. 1er décembre 2016 à 10h29, Ernest Mueller [email protected]
a écrit:

Je vois cela sur Amazon Linux dans un cluster ECS - le message
lance de temps en temps mais il ne se bloque pas, comme reshen le voit maintenant.
Docker 1.11.2. Uname signale "4.4.14-24.50.amzn1.x86_64" comme version.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/docker/docker/issues/5618#issuecomment-264220432 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AKklVRqoBUZDu3HMhGv3b6knnA6j6C_Qks5rDvXRgaJpZM4B4L4Z
.

--
Keifer Furzland
http://kfrz.work

J'ai également pu reproduire ce problème à l'aide de https://github.com/crosbymichael/docker-stress sur un nœud de travail Kubernetes exécutant CoreOS Stable 1185.3.0.

Exécuter docker_stress_linux_amd64 -k 3s -c 5 --containers 1000 : 5 travailleurs simultanés créant/supprimant des conteneurs, durée de vie maximale des conteneurs = 3 s, créer jusqu'à 1 000 conteneurs sur une instance m4.large sur AWS laisserait le démon Docker inactif après environ trois minutes.

Mise à niveau vers CoreOS Beta 1235.1.0 et je n'ai pas pu reproduire (à la fois l'absence de réponse ou le message unregister_netdevice dans les journaux du noyau). Alors que l'exécution de 5 travailleurs docker_stress simultanés tuerait CoreOS Stable après quelques minutes, j'ai pu fonctionner avec 10 et 15 travailleurs simultanés jusqu'à la fin du test à l'aide de CoreOS Beta.

CoreOS est publié dans des "canaux", il n'est donc pas possible de mettre à niveau le noyau de manière isolée. Voici les principales différences entre stable et bêta :

CoreOS stable 1185.3.0

noyau : 4.7.3

docker : 1.11.2

CoreOS bêta 1235.1.0

noyau : 4.8.6

docker : 1.12.3

Voir ce problème sur Amazon Elastic Beanstalk exécutant 4.4.23-31.54.amzn1.x86_64

Just Happen sur CoreOS Stable 1185.5.0, Docker 1.12.2
Après un redémarrage tout va bien

Mise à jour : le problème du démon Docker bloqué a de nouveau frappé un hôte exécutant CoreOS Beta 1235.1.0 avec Docker v1.12.3 et le noyau Linux v4.8.6. ??

1.12.4 et 1.13 ne devraient, en théorie, pas se bloquer lorsque ce problème de noyau est atteint.
La raison pour laquelle le gel dans le démon docker se produit est que le démon attend un message netlink de retour du noyau (qui ne viendra jamais) tout en maintenant le verrou sur l'objet conteneur.

1.12.4 et 1.13 définissent un délai d'attente sur cette requête netlink pour au moins libérer le verrou du conteneur.
Cela ne résout __pas__ le problème, mais au moins (espérons-le) ne gèle pas l'ensemble du démon.
Vous ne pourrez probablement pas faire tourner de nouveaux conteneurs, et de la même manière, vous ne pourrez probablement pas les démolir car il semble que toutes les interactions avec netlink se bloquent une fois que ce problème est résolu.

@ cpuguy83 FWIW, tous les conteneurs en cours d'exécution continuent de s'exécuter sans problème AFAIK lorsque le démon est bloqué. En effet, c'est le démarrage et l'arrêt des conteneurs qui est perceptible (surtout fonctionnant sur Kubernetes, comme nous le sommes).

Cela ne résout pas le problème, mais au moins (espérons-le) ne gèle pas l'ensemble du démon.

Le seul avantage du fait que tout le démon est gelé est qu'il est facile à comprendre. Kubernetes peut expulser le nœud, peut-être même redémarrer automatiquement. Si le démon continuait à fonctionner, serait-il toujours possible de trouver facilement le problème du noyau ?

@seanknox Je pourrais vous fournir une AMI CoreOS 1248.1.0 personnalisée avec Docker corrigé (CoreOS Docker 1.12.3 + Upstream 1.12.4-rc1 Patches). Il a corrigé les blocages toutes les deux heures sur mes clusters CoreOS/K8s. Envoyez-moi simplement un ping avec votre identifiant de compte AWS sur le Deis Slack.

Nous avons eu un énorme problème avec ce problème sur notre cluster CoreOS. Quelqu'un pourrait-il dire quand il sera enfin réparé? Nous rêvons de ce moment où nous pouvons dormir la nuit.

@DenisIzmaylov Si vous ne définissez pas --userland-proxy=false , vous ne devriez généralement pas rencontrer ce problème.

Mais sinon, il s'agit d'un bogue dans le noyau, peut-être de plusieurs bogues du noyau, que certains disent résolus dans la 4.8 et d'autres non. Pour certains, la désactivation d'ipv6 semble résoudre le problème, d'autres non (il s'agit donc probablement de plusieurs problèmes... ou du moins de plusieurs causes).

J'ai vu ce problème en quelques heures sur des systèmes à forte charge avec et sans --userland-proxy=false

Confirmé que nous voyons toujours des erreurs unregister_netdevice sur le noyau 4.8.12 . Il faut environ 5 jours pour se déclencher. Seul un redémarrage du système semble se remettre du problème. L'arrêt de Docker semble se bloquer indéfiniment.

Je n'ai pas encore essayé l'astuce de désactivation d'ipv6 pour le démarrage du noyau.

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

Ce serait génial si quelqu'un pouvait essayer cela avec 1.12.5, qui devrait expirer sur la requête netlink bloquée maintenant au lieu de simplement suspendre Docker.

@ cpuguy83 cependant, le système est toujours inutilisable dans cet état :)

@ LK4D4 Oh, totalement, je veux juste voir ces délais d'attente ;)

Obtenir ce problème sur Cent OS 7 :

kernel:unregister_netdevice : en attente que lo devienne libre. Nombre d'utilisations = 1

Linux foo 3.10.0-514.2.2.el7.x86_64 #1 SMP mar. 6 déc. 23:06:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

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

Cela affecte mes versions de CI qui s'exécutent dans des conteneurs Docker et semblent mourir soudainement au cours desquelles ce message de console apparaît. Existe-t-il un correctif ou une solution de contournement ? Merci!

@ cpuguy83 Docker ne se

J'utilise donc docker sur une machine centos 7 depuis un certain temps (11 mois?) Sans problème. Aujourd'hui, j'ai décidé d'essayer le démon d'écoute tcp ( ajout de l'adresse d'écoute tcp à /etc/sysconfig/docker ) et je viens de recevoir cette erreur.

kernel:unregister_netdevice : en attente que lo devienne libre. Nombre d'utilisations = 1

donc mon nombre d'utilisation n'est pas 3.

Conteneurs : 4
Course à pied : 3
En pause : 0
Arrêté : 1
Images : 67
Version du serveur : 1.10.3
Pilote de stockage : btrfs
Version de construction : Btrfs v4.4.1
Version de la bibliothèque : 101
Pilote d'exécution : natif-0.2
Pilote de journalisation : fichier json
Plugins :
Volume : local
Réseau : hôte nul de pont
Version du noyau : 3.10.0-514.2.2.el7.x86_64
Système d'exploitation : CentOS Linux 7 (Core)
Type de système d'exploitation : Linux
Architecture : x86_64
Nombre de crochets Docker : 2
Processeurs : 24
Mémoire totale : 39,12 Gio
Nom : aimes-web-encodeur
ID : QK5Q : JCMA:ATGR :ND6W:YOT4:PZ7G:DBV5:PR26: YZQL:INRU : HAUC:CQ6B
Registres : docker.io (sécurisé)

3.10.0-514.2.2.el7.x86_64 #1 SMP mar. 6 déc. 23:06:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Client:
Version : 1.10.3
Version de l'API : 1.22
Version du package : docker-common-1.10.3-59.el7.centos.x86_64
Version Go : go1.6.3
Git commit : 3999ccb-non pris en charge
Construit: jeu. 15 déc. 17:24:43 2016
OS/Arch : linux/amd64

Serveur:
Version : 1.10.3
Version de l'API : 1.22
Version du package : docker-common-1.10.3-59.el7.centos.x86_64
Version Go : go1.6.3
Git commit : 3999ccb-non pris en charge
Construit: jeu. 15 déc. 17:24:43 2016
OS/Arch : linux/amd64

Je peux confirmer @aamerik. Je vois le même problème sur la même version du noyau. Aucun changement majeur récent sur le système, vu ce problème depuis aujourd'hui.

J'ai vu le même message kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1 sur ma machine CentOS 7 exécutant une image docker de Jenkins. La machine CentOS 7 que j'utilisais était à jour avec tous les derniers correctifs CentOS 7 en date du 20 décembre 2016.

Étant donné que les références les plus récentes ici semblent être basées sur CentOS, je vais basculer mon hôte d'exécution sur une machine Ubuntu ou Debian.

J'exécute Docker version 1.12.5, build 7392c3b sur cette machine CentOS 7. Docker ne s'est pas bloqué, mais le processus Jenkins que j'exécutais dans Docker a été tué lorsque ce message est apparu.

Merci beaucoup pour Docker ! Je l'utilise tout le temps et je suis profondément reconnaissant pour votre travail dessus !

Je vois le même problème lors de l'utilisation de Jenkins avec Docker sur une machine Linux 4.8.15.

Quelqu'un at - il atteint une procédure de correction pour le rancher os ?

AFAICT, il s'agit d'un problème de verrouillage dans le sous-système des espaces de noms réseau du noyau Linux. Ce bogue a été signalé il y a plus d'un an, sans réponse : https://bugzilla.kernel.org/show_bug.cgi?id=97811 Il y a eu du travail à ce sujet (voir ici : http://www.spinics. net/lists/netdev/msg351337.html) mais il semble que ce ne soit pas une solution complète.

J'ai essayé de faire un ping directement au mainteneur du sous-système réseau, sans réponse. FWIW, je peux reproduire le problème en quelques minutes.

Smyte paiera 5000 USD pour la résolution de ce problème. On dirait que j'ai besoin de parler à quelqu'un qui travaille sur le noyau ?

@petehunt Je pense qu'il y a plusieurs problèmes en jeu à l'origine de cette erreur.

Nous avons déployé le noyau 4.8.8 comme @reshen l'a suggéré et bien que la disponibilité semble un peu meilleure, nous continuons à voir ce problème en production.

Essayer de déployer Mesosphere à partir d'un nœud d'amorçage. Tous les nœuds sont CentOS 7.2 minimum avec toutes les mises à jour appliquées. Le nœud d'amorçage affiche l'erreur comme indiqué ci-dessus par d'autres :

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

Je peux confirmer qu'un redémarrage fait taire les messages, mais à la minute où je déploie à nouveau la mésosphère, les messages démarrent de temps en temps. La mésosphère est un déploiement assez important. Peut-être que ceux qui essaient de recréer l'erreur peuvent utiliser le programme d'installation pour reproduire l'erreur. Cela prend quelques minutes avant que l'erreur n'apparaisse après avoir utilisé le premier commutateur de script ( --genconf qui est la première étape ).

Nous avons également touché cela. Cependant, les messages d'erreur dans notre cas mentionnent l'appareil eth0 non lo . Mon erreur est la suivante :

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

Je suppose que les erreurs telles que mentionner eth0 au lieu de lo ont la même cause première que ce problème. Sinon, nous devrions ouvrir un nouveau ticket concernant les erreurs eth0.

  • Système d'exploitation : CentOS Linux version 7.3.1611
  • Noyau : 3.10.0-514.2.2.el7.x86_64
  • Docker version 1.12.6, version 78d1802
  • Docker a commencé avec des options : 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 utilisant IPsec (mentionné depuis https://bugzilla.kernel.org/show_bug.cgi?id=97811 et d'autres bogues mentionnent IPsec)

Nous avons également touché cela.
Erreur : unregister_netdevice : en attente de la libération de lo.
Système d'exploitation : CentOS Linux version 7.3.1611 (Core)
Noyau 3.10.0-514.2.2.el7.x86_64
Version Docker : 1.13.0-cs1-rc1
Options du Docker :
{
"disable-legacy-registry": vrai,
"icc":vrai,
"registres-non sécurisés":[],
"ipv6":faux,
"iptables":vrai,
"storage-driver": "devicemapper",
"options de stockage": [
"dm.thinpooldev=/dev/mapper/docker_vg-thinpool",
"dm.use_deferred_removal=true",
"dm.use_deferred_deletion=true"
],
"userland-proxy": false
}

J'ai ceci sur deux systèmes CentOS, les dernières mises à jour sur au moins l'un d'entre eux.

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

Hé, pour toutes les personnes concernées par ce problème sur RHEL ou CentOS, j'ai rétroporté le commit à partir des noyaux principaux (torvalds/linux@751eb6b6042a596b0080967c1a529a9fe98dac1d) qui corrige la condition de concurrence dans le nombre de références IPV6 IFP vers les noyaux 3.10.x utilisés dans les distributions d'entreprise. Cela devrait résoudre ce problème.

Vous pouvez trouver le rapport de bogue avec le correctif de travail ici :
Si vous souhaitez le tester et que vous possédez un système RHEL 7 ou CentOS 7, j'ai déjà compilé le dernier noyau CentOS 7.3 3.10.0-514.6.1.el7.x86_64 avec le correctif. Répondez au fil de discussion CentOS bugtracker et je pourrai vous envoyer un lien vers la version.

Remarque : il peut y avoir un autre problème provoquant une fuite de refcount, mais cela devrait corriger le message d'erreur pour beaucoup d'entre vous.

@stefanlasiewski @henryiii @jsoler

Je vais essayer une version en ajoutant également ce correctif : http://www.spinics.net/lists/netdev/msg351337.html plus tard ce soir.

@iamthebot cela signifie-t-il que si l'on désactive IPv6, cela devrait également résoudre le problème, même sans un correctif que vous venez de rétroporter ?

@redbaron uniquement si c'est le problème que vous rencontrez. Je pense vraiment qu'il y a plusieurs problèmes de noyau ici.

@redbaron peut-être. #20569 semble indiquer qu'il est difficile de désactiver complètement IPV6.

Donc, pour clarifier un peu ce qui se passe sous le capot qui génère ce message, le noyau maintient un compte courant de si un périphérique est en cours d'utilisation avant de le supprimer d'un espace de noms, de le désenregistrer, de le désactiver, etc. référence à un périphérique, vous verrez alors ce message d'erreur car il ne peut pas être désenregistré lorsqu'un autre utilisateur l'utilise.

Les correctifs que j'ai vu jusqu'à présent:

  1. Résoudre un problème où un problème avec une allocation d'adresse IPV6 échoue (par exemple, une adresse en double) mais nous ne publions pas la référence à l'appareil avant de quitter.
  2. Résoudre un problème où le déplacement de l'espace de noms d'un périphérique déplacera correctement les références de l'appareil vers le nouvel espace de noms réseau mais laissera une référence pendante sur l'ancien espace de noms. Docker utilise fortement les espaces de noms réseau (comme en témoigne un autre correctif du noyau que j'ai eu un backport Red Hat vers 7.3 Z-Stream et devrait être inclus dans 7.4 qui empêche le pilote macvlan de docker de fonctionner sur des périphériques bond ou d'équipe)

Je pense qu'il y a encore une autre condition de concurrence lors du changement d'espace de noms (cela semble se produire après la création d'un tas de nouveaux conteneurs), mais je devrai reproduire le problème de manière fiable afin de le traquer et d'écrire un correctif.

Quelqu'un a-t-il une procédure minimale pour reproduire cela de manière cohérente? Semblait se produire au hasard sur nos systèmes.

@iamthebot ce n'est pas vraiment simple, mais je pense que nous pouvons vous fournir un environnement de test qui peut reproduire cela de manière fiable. Envoyez-moi un e-mail ([email protected]) et nous pouvons organiser les détails.

Faites toujours l'expérience de cette charge sur Docker version 1.12.6, build 7392c3b/1.12.6 sur 4.4.39-34.54.amzn1.x86_64 AWS Linux AMI.

J'ai 9 hôtes docker presque identiques, et je n'en fais l'expérience que sur certains d'entre eux. C'est peut-être une coïncidence, mais une chose en commun que j'ai remarquée est que je ne semble avoir ce problème que lors de l'exécution de conteneurs qui ne gèrent pas SIGINT . Lorsque je docker stop ces conteneurs, il se bloque pendant 10 secondes, puis tue le conteneur sans grâce.

Il faut plusieurs jours avant que le problème ne se présente et semble apparaître de manière aléatoire, pas seulement immédiatement après l'exécution de docker stop . C'est surtout anecdotique, mais peut-être que cela aidera quelqu'un.

J'ai mis à niveau tous mes nœuds docker vers le noyau 3.10.0-514.6.1.el7.x86_64 sur CentOS 7.3 comme @iamthebot l'a mentionné, mais j'obtiens toujours les mêmes erreurs :
26 janvier 13:52:49 Noyau XXX : unregister_netdevice : en attente que lo devienne libre. Nombre d'utilisations = 1
Message de syslogd@XXX le 26 janvier 13:52:49 ...
kernel:unregister_netdevice : en attente que lo devienne libre. Nombre d'utilisations = 1

@jsoler juste pour être clair, avez-vous appliqué le correctif dans le fil de suivi des bogues avant de construire le noyau ? Ou utilisez-vous un noyau d'origine? Essayez également d'appliquer celui-ci (le correctif devrait fonctionner sur les noyaux plus anciens).

Envoyez-moi un e-mail ([email protected]) et je pourrai vous envoyer un lien vers un noyau pré-construit. @vitherman Je n'ai malheureusement pas beaucoup de temps pour examiner cela (on dirait qu'une certaine instrumentation devra être compilée pour attraper ce bogue) mais j'ai remonté le problème avec le support de Red Hat afin que leur équipe du noyau prenne un voir.

@ckeeney je peux confirmer ce comportement. Nous avons une application Node dockerisée qui a provoqué cette erreur sur le système hôte lors de sa fermeture. Après avoir implémenté une fonction dans l'application Node.js, qui attrape SIGINT et SIGTERM pour fermer correctement l'application, l'erreur ne s'est plus produite.
Ce qui a du sens ; l'application Node utilise l'interface virtuelle créée par Docker. Lorsque Node ne s'arrête pas correctement, le périphérique se bloque et le système hôte ne peut pas le désinscrire, même si le conteneur Docker a été arrêté avec succès.

voici un exemple d'extrait de code :

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 existe-t-il un signal différent correctement géré par Node par défaut pour un arrêt propre ? (vous pouvez spécifier le STOPSIGNAL dans l'image, ou sur docker run via le drapeau --stop-signal .

@thaJeztah pour une bonne explication du problème et une solution de contournement, voir nodejs/node-v0.x-archive#9131#issuecomment-72900581

@ckeeney J'en suis conscient (c'est-à-dire que les processus exécutés en tant que PID1 peuvent ne pas gérer SIGINT ou SIGTERM ). Pour cette raison, je me demandais si la spécification d'un signal d'arrêt différent ferait un arrêt propre même s'il s'exécute en tant que PID1 .

Alternativement, docker 1.13 ajoute une option --init (pull request : https://github.com/docker/docker/pull/26061), qui insère un init dans le conteneur ; dans ce cas, Node ne s'exécute pas en tant que PID1 , ce qui peut aider dans les cas où vous ne pouvez pas mettre à jour l'application.

@iamthebot J'ai construit la version 3.10.0-514.el7 du noyau avec votre correctif intégré mais j'obtiens la même erreur. Eh bien, je ne suis pas sûr d'avoir bien construit le paquet noyau de centos. Pourriez-vous me partager votre package de noyau pour le tester ?

Merci

J'ai/avais été confronté à ce bug depuis presque un an maintenant. J'utilise CoreOS avec le démarrage PXE, j'ai désactivé ipv6 dans la configuration pxeboot et je n'ai pas vu ce problème une seule fois depuis lors.

Eh bien, mon environnement a désactivé ipv6 avec cette configuration sysctl
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
mais j'ai toujours l'erreur
kernel:unregister_netdevice : en attente que lo devienne libre. Nombre d'utilisations = 1

@jsoler c'est vrai, je faisais ça aussi, ça arrivait

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

Juste une observation - il semble y avoir différents problèmes en jeu (cela a déjà été dit).

  • Certaines personnes notent "en attente de lo..."
  • certains ont noté "en attente de eth0"
  • certains ont noté "en attente de veth ?????"
  • Sur le suivi des bogues RedHat , il est question de "attendre ppp0"

Certains ont noté des journaux alternant entre l'un de ceux ci-dessus et d'autres n'ayant qu'un seul de ceux-ci.

Il existe également un bogue similaire enregistré sur Ubuntu . Sur celui-ci, ils semblent trouver que NFS est le problème.

@etlweather Je crois qu'en fait, le seul dénominateur commun est, eh bien, un périphérique réseau ne pouvant pas être désenregistré par le noyau comme le dit le message d'erreur. Cependant, les raisons _pourquoi_ sont quelque peu différentes. Pour nous, c'était certainement le problème mentionné de docker / node (veth). Pour eth, la cause est probablement quelque chose de complètement différent.

arrive toujours avec 4.9.0-0.bpo.1-amd64 sur debian jessie avec docker 1.13.1. Existe-t-il une combinaison noyau - système d'exploitation stable ?

Ce n'est peut-être pas un problème purement docker - je le reçois sur un serveur Proxmox où je n'exécute que des conteneurs vanilla LXC (ubuntu 16.04).

@darth-veitcher c'est un problème de noyau

@thaJeztah a accepté merci. J'allais essayer d'installer la 4.9.9 ce soir à partir de la ligne principale et voir si cela résout le problème.

Je le fais exécuter Docker 1.13.1 sur une Debian avec le noyau 4.9.9-040909.

Oui, la mise à niveau du noyau sur Proxmox vers la dernière version 4.9.9 n'a pas résolu l'erreur. Étrange car il vient d'apparaître après un an sans problèmes.

Il pourrait y avoir quelque chose dans une déclaration précédente plus haut dans le fil à propos de son lien avec les partages NFS ou CIFS montés.

Envoyé de mon iPhone

Le 14 février 2017, à 07h47, Alfonso da Silva [email protected] a écrit :

Je le fais exécuter Docker 1.13.1 sur une Debian avec le noyau 4.9.9-040909.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub ou coupez le fil de discussion.

J'ai un ticket bugzilla ouvert avec Redhat à ce sujet.

Quelques évolutions :
Red Hat a mis les correctifs de fuite de compte de référence IPV6 de la ligne principale sur QA, il semble qu'ils soient mis en file d'attente pour RHEL 7.4 et peuvent être rétroportés vers 7.3. Devrait bientôt être sur CentOS-plus. Remarque : ce correctif ne résout les problèmes que dans CERTAINS cas. Si vous avez un noyau 4.x, c'est un point discutable car ils sont déjà là.

Il s'agit certainement d'une condition de concurrence dans le noyau d'après ce que je peux dire, ce qui le rend vraiment ennuyeux à trouver. J'ai pris un instantané du noyau principal actuel et je travaille sur l'instrumentation des différents appels en commençant par le sous-système IPV6. Le problème est définitivement reproductible maintenant : il semble que tout ce que vous avez à faire est de créer un tas de conteneurs, d'en extraire une tonne de trafic réseau, de planter le programme à l'intérieur des conteneurs et de les supprimer. Faire cela encore et encore déclenche le problème en quelques minutes, sur un poste de travail physique à 4 cœurs.

Malheureusement, je n'ai pas beaucoup de temps pour travailler là-dessus : s'il y a des développeurs de noyau ici qui sont prêts à collaborer sur l'instrumentation des pièces nécessaires, je pense que nous pouvons mettre en place un fork et commencer à travailler sur cette recherche étape par étape .

@iamthebot , est-ce reproductible sur une configuration qemu-kvm ?

@iamthebot J'ai essayé de reproduire cela plusieurs fois avec différents noyaux. Quelque part ci-dessus, il a été mentionné que l'utilisation de docker-stress -c 100 avec userland-proxy défini sur false le déclencherait, mais je n'ai pas eu de chance.

Si vous avez une repro plus fiable (même si elle met beaucoup de temps à se déclencher) je peux essayer d'y jeter un oeil

Nous rencontrons la même difficulté dans nos environnements de production et de mise en scène. Nous allons bientôt passer à Docker 1.13 et au noyau Linux 4.9, mais comme d'autres déjà mentionnés ; ces versions sont également concernées.

$ 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

Je rencontre ce problème assez régulièrement sur mon système de développement, toujours lors de la fermeture des conteneurs.

Informations générales

→ 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



Journal du démon Docker

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

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

@r-BenDoan si vous essayez d'arrêter un conteneur mais qu'il ne répond pas à SIGINT, docker attendra 10 secondes, puis tuera le conteneur sans grâce. J'ai rencontré ce comportement dans mes conteneurs nodejs jusqu'à ce que j'ajoute la gestion du signal. Si vous voyez un conteneur mettre 10s à s'arrêter, il ne gère probablement pas les signaux et est plus susceptible de déclencher ce problème.

Assurez-vous que vos conteneurs peuvent s'arrêter gracieusement.

Bien que je ne sois pas celui qui résout ce problème, n'étant pas très intéressé par le développement du noyau Linux, je pense avoir raison de dire que les commentaires "moi aussi" ne sont pas très utiles. Je veux dire par là que le simple fait de dire "J'ai aussi ce problème, avec Kernel vx.x et Docker 1.x" n'apporte rien de nouveau à la discussion.

Cependant, je suggérerais que des commentaires "moi aussi" qui décrivent davantage l'environnement et la méthode de reproduction seraient d'une grande valeur.

En lisant tous les commentaires, il est clair qu'il y a quelques problèmes - comme je l'ai posté plus tôt, certains avec vethXYZ, certains avec eth0 et d'autres avec lo0. Cela suggère qu'ils pourraient être causés par des problèmes différents. Donc, le simple fait de dire "moi aussi" sans une description complète de l'erreur et de l'environnement peut induire les gens en erreur.

De plus, lors de la description de l'environnement, donner la version Kernel et Docker n'est pas suffisant. Selon le fil, il semble y avoir quelques facteurs tels que IPv6 activé ou non. NodeJS ne répond pas à SIGINT (ou à d'autres conteneurs, ne se moque pas de NodeJS ici).

Il serait donc utile de décrire la charge de travail sur l'environnement. En outre, cela se produit lorsqu'un conteneur est en cours d'arrêt. Par conséquent, je suggérerais également aux personnes confrontées à ce problème de faire attention au conteneur qui est arrêté lorsque le problème apparaît.

Bien qu'il semble que le problème réside dans le noyau ayant une condition de concurrence - l'identification du déclencheur sera d'une grande aide pour ceux qui résoudront le problème. Et cela peut même donner aux utilisateurs concernés une solution immédiate, telle que la mise en œuvre d'un gestionnaire de signal dans une application NodeJS (je ne sais pas moi-même si cela empêche le problème de se déclencher, mais cela semble être le cas selon les commentaires précédents des autres).

FWIW kubernetes a complètement corrélé cela avec le "mode épingle à cheveux" veth et
a complètement cessé d'utiliser cette fonctionnalité. Nous n'avons pas vécu cela
problème du tout, sur des dizaines de milliers de machines de production et largement
plus de tests, depuis le changement.

Jusqu'à ce que ce soit réglé, abandonnez le navire. Trouvez une autre solution :(

Le mercredi 15 février 2017 à 10h00, ETL [email protected] a écrit :

Bien que je ne sois pas celui qui résout ce problème, n'étant pas très intéressé par Linux
Dev Kernel, je pense avoir raison de dire que les commentaires "moi aussi" ne sont pas
qu'utile. J'entends par là, simplement dire "J'ai aussi ce problème, avec
Kernel vx.x et Docker 1.x" n'apportent rien de nouveau à la discussion.

Cependant, je suggérerais que les commentaires « moi aussi » qui décrivent davantage la
l'environnement et la méthode de reproduction seraient d'une grande valeur.

En lisant tous les commentaires, il est clair qu'il y a quelques problèmes -
comme je l'ai posté plus tôt, certains avec vethXYZ, certains avec eth0 et d'autres avec lo0.
Cela suggère qu'ils pourraient être causés par des problèmes différents. Alors juste
dire "moi aussi" sans description complète de l'erreur et de l'environnement peut
tromper les gens.

De plus, lors de la description de l'environnement, donner au Kernel et à Docker
la version n'est pas suffisante. Selon le fil, il semble y avoir quelques facteurs
comme ipv6 activé ou non. NodeJS ne répond pas à SIGINT (ou autre
conteneurs, pas de dénigrement sur NodeJS ici).

Il serait donc utile de décrire la charge de travail sur l'environnement.
De plus, cela se produit lorsqu'un conteneur est en cours d'arrêt, donc je voudrais
suggèrent également aux personnes confrontées à ce problème de prêter attention à ce
le conteneur est arrêté lorsque le problème fait surface.

Bien qu'il semble que le problème soit dans le noyau ayant une condition de concurrence -
l'identification du déclencheur sera d'une grande aide pour ceux qui répareront
le problème. Et cela peut même donner aux utilisateurs concernés une solution immédiate
comme l'implémentation d'un gestionnaire de signal dans une application NodeJS (je ne sais pas
moi-même que cela empêche le problème de se déclencher, mais il semble que par
commentaires antérieurs des autres).

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/docker/docker/issues/5618#issuecomment-280087293 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AFVgVFmu1SiStZcLKtKuk1W-tjn6wOXlks5rcz0hgaJpZM4B4L4Z
.

Oui, nous passons à gke et nous ne voyons plus ce problème (donc plus de bug bounty de notre part :))

Je viens d'avoir à nouveau l'erreur. J'essayais de réparer une application node.js qui utilise des sockets et a donc souvent mis l'application à l'échelle. L'application node.js a été créée sur https://github.com/deployd/deployd. J'espère que cela fournira plus d'informations. Ce qui était également intéressant, c'est que les deux serveurs de mon essaim affichaient l'erreur unregister_netdevice simultanément après avoir supprimé le service via docker service rm. Le conteneur a été mis à l'échelle à 4, donc deux conteneurs fonctionnaient sur chaque machine.

modifier C'est encore arrivé ! Travailler sur la même application node.js. Les 3 ou 4 derniers jours, je n'ai pas travaillé directement sur cette application node.js et cela ne s'est jamais produit.

edit2 essaiera d'ajouter un gestionnaire de signal à l'application nodejs. Voyons si cela aide....

Je viens de rencontrer cette erreur, après avoir utilisé docker-py pour publier une nouvelle instance sur EC. Cependant, j'ai pu quitter avec ctrl + C et je ne l'ai pas vu depuis (maintenant que la plupart des images se construisent plus rapidement à partir du cache)

```{"status":"Pushed","progressDetail":{},"id":"c0962ea0b9bc"}
{"status":"étape : condensé : sha256:f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8 taille : 5737"}
{"progressDetail":{},"aux":{"Tag":"stage","Digest":"sha256:f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8","Size":5737}}

Image Docker publiée avec succès

Message de syslogd@ip-172-31-31-68 au 16 février 19:49:16 ...
kernel :[1611081.976079] unregister_netdevice : en attente de la libération de lo. Nombre d'utilisations = 1

Message de syslogd@ip-172-31-31-68 au 16 février 19:49:27 ...
kernel :[1611092.220067] unregister_netdevice : en attente que lo devienne libre. Nombre d'utilisations = 1

[1]+ Arrêté ./image-publish.py
[ root@ip-172-31-xx-xx image-publish]# ^C
[ root@ip-172-31-xx-xx image-publish]#

@thockin est-ce que ce paramètre est --hairpin-mode=none sur les kubelets ?

=aucun casse les conteneurs qui sont renvoyés vers eux-mêmes par NAT. Nous utilisons
promiscuité-pont par défaut.

Le jeu. 16 février 2017 à 19h26, Kanat Bekt [email protected]
a écrit:

@thockin https://github.com/thockin est ce paramètre --hairpin-mode=none
sur les kubelets ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/docker/docker/issues/5618#issuecomment-280539673 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AFVgVLNwAH6NWVaIKhJfS147O9w_rtJEks5rdRN8gaJpZM4B4L4Z
.

@thockin quels conteneurs pourraient vouloir accéder à eux-mêmes via Service ClusterIP ?

Il s'avère que c'est plus courant que je ne le pensais, et quand nous l'avons cassé, beaucoup
des gens se sont plaints.

Le 17 février 2017 à 00h38, "Maxim Ivanov" [email protected] a écrit :

@thockin https://github.com/thockin quels conteneurs pourraient vouloir
accéder à eux-mêmes via Service ClusterIP ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/docker/docker/issues/5618#issuecomment-280588366 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AFVgVLn3uBvUW-dQ72qst5_eYiFUtfSVks5rdVyIgaJpZM4B4L4Z
.

Je pense savoir pourquoi certaines applications nodejs dockerisées pourraient causer ce problème. Le nœud utilise des connexions persistantes par défaut. Lorsque server.close() est utilisé, le serveur n'accepte pas les nouvelles connexions. Mais les connexions actives actuelles telles que les Websockets ou les connexions HTTP keep-alive sont toujours maintenues. Lorsque l'application dockerisée est également mise à l'échelle à n, cela peut entraîner waiting for lo to become free car lorsqu'elle est forcée de se terminer, une version plus récente a été libérée. Lorsque docker redistribue cette application à un autre nœud ou que l'application est réduite, docker envoie un signal à l'application pour qu'elle s'arrête. L'application écoute ce signal et peut réagir. Lorsque l'application ne s'arrête pas après quelques secondes, docker la termine sans hésitation. J'ai ajouté des gestionnaires de signaux et découvert que lors de l'utilisation de server.close() le serveur n'est pas parfaitement terminé mais "seulement" arrête d'accepter de nouvelles connexions (voir https://github.com/nodejs/node/issues/2642). Nous devons donc nous assurer que les connexions ouvertes telles que les Websockets ou http keep-alive sont également fermées.

Comment gérer les Websockets :
L'application nodejs émet à tous les websockets closeSockets lorsqu'un signal d'arrêt est reçu. Le client écoute cet événement closeSockets et appelle sockets.disconnect() et peu après sockets.connect() . N'oubliez pas que server.close() été appelé, donc cette instance n'accepte pas de nouvelles requêtes. Lorsque d'autres instances de cette application dockerisée s'exécutent, l'équilibreur de charge à l'intérieur de docker finira par choisir une instance qui n'est pas arrêtée et qu'une connexion réussie est établie. L'instance qui devrait s'arrêter n'aura pas de connexions websockets ouvertes.

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

Comment gérer les connexions HTTP persistantes :
Actuellement, je ne sais pas comment cela peut être fait parfaitement. Le moyen le plus simple est de désactiver le keep-alive.

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

Une autre possibilité consiste à définir le délai d'attente de maintien d'activité sur un nombre très faible. Par exemple 0,5 seconde.

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

J'espère que cela pourra aider d'autres :)

J'ai les mêmes problèmes. Les pièces jointes sont tous des journaux créés à partir du script ecs-logs-collector.
Très apprécié pour toute aide :)

collect.zip

J'ai les mêmes problèmes.
Docker version 1.13.1, build 092cba3
Linux debian 4.8.6-x86_64-linode78

Sauvegarde Linux 4.6.0-040600-generic #201606100558 SMP Ven 10 juin 10:01:15 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Version du serveur : 1.13.1

Même problème. J'utilise mount dans un conteneur privilégié. Après 4-5 courses, il gèle. J'ai également le même problème avec le dernier noyau standard pour 16.04

Tout le monde, @etlweather est sur place. Ne postez un "moi aussi" que si vous avez un moyen fiable de reproduire le problème. Dans ce cas, détaillez votre procédure. Une version docker et kernel ne suffit pas et nous recevons beaucoup de notifications à ce sujet. Plus votre procédure de reproduction est simple, mieux c'est.

@rneugeba @redbaron Malheureusement, le "repro" actuel que j'ai est très spécifique au matériel (tout sauf prouver qu'il s'agit d'une condition de

Nous obtenons cela assez fréquemment dans GCE. Docker se bloque et la machine se bloque au redémarrage.

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

Le conteneur exécute une application go et a configuré un nat en épingle à cheveux.

Docker:

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

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

Ubuntu 16.04 LTS,

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

Est-ce que n'importe qui a un travail suggéré pour ceci ? J'ai essayé d'activer --userland-proxy=true et docker se bloque toujours après un certain temps. Il semble que Kubernates ait une solution à partir de ce que @thockin a écrit ci-dessus, mais on ne sait pas exactement ce que fait --hairpin-mode=promiscuous-bridge et comment le configurer sur une simple installation de docker jane ubuntu 16.x.

Je peux faire en sorte que cela se produise de manière fiable lors de l'exécution de Proxmox et de l'utilisation de conteneurs. Plus précisément, si j'ai déplacé une quantité considérable de données ou déplacé vraiment une quantité de données très récemment, l'arrêt ou l'arrêt brutal du conteneur produira cette erreur. Je l'ai vu le plus souvent lorsque j'utilise des conteneurs qui montent mon NAS à l'intérieur, mais cela pourrait être une coïncidence.

# 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

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

Il convient de noter que Docker n'est pas installé sur ce système et ne l'a jamais été. Je suis heureux de fournir toutes les données dont la communauté a besoin pour résoudre ce problème, dites-moi simplement quelles commandes exécuter.

Je suis capable de reproduire cela sur centos 7.3 exécuté en tant que nœud de travail d'essaim exécutant dtr avec un volume nfs monté mappé

Si vous arrivez ici

Le problème discuté ici est un bogue du noyau et n'a pas encore été corrigé. Il existe un certain nombre d'options qui peuvent aider pour _certaines_ situations, mais pas pour toutes (c'est très probablement une combinaison de problèmes qui déclenchent la même erreur)

Ne laissez pas de commentaires "J'ai ça aussi"

"J'ai ça aussi" n'aide pas à résoudre le bug. ne laissez un commentaire que si vous avez des informations qui peuvent aider à résoudre le problème (auquel cas, fournir un correctif au noyau en amont peut être la meilleure étape).

Si vous voulez faire savoir que vous avez également ce problème, utilisez le bouton « pouce vers le haut » dans la description du haut :
screen shot 2017-03-09 at 16 12 17

Si vous souhaitez rester informé des mises à jour, utilisez le _bouton d'abonnement_.

screen shot 2017-03-09 at 16 11 03

Chaque commentaire ici envoie un e-mail/une notification à plus de 3000 personnes. Je ne veux pas verrouiller la conversation sur ce problème, car il n'est pas encore résolu, mais peut être forcé de le faire si vous l'ignorez.

Merci!

C'est bien beau, mais quelles sont _exactement_ les options qui aident ? Ce problème nous cause des problèmes en production, j'aimerais donc faire tout ce qui est nécessaire pour contourner le bogue du noyau.

Si quelqu'un de Docker a le temps d'essayer la solution de contournement de Kubernetes, veuillez
faites-le moi savoir et nous pourrons vous l'indiquer. Je ne parviens pas à extraire les modifications
et les patcher dans Docker moi-même, maintenant.

Le jeu. 9 mars 2017 à 7h46, Matthew Newhook [email protected]
a écrit:

C'est bien beau, mais quelles sont exactement les options qui aident?
Ce problème nous cause des problèmes de production, donc j'aimerais faire n'importe quoi
contournements qui sont nécessaires pour contourner le bogue du noyau.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/docker/docker/issues/5618#issuecomment-285388243 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AFVgVGdH5VX_oFWkImyo_TvlIuhmwMepks5rkB7MgaJpZM4B4L4Z
.

@thockin merci. Je suivais le PR/problème dans Kubernetes avec la solution de contournement en mode épingle à cheveux. Mais au cours des nombreux allers-retours, j'ai perdu la trace si la solution de contournement résout effectivement ce problème ?
(D'après ce que je comprends, il existe différents scénarios qui provoquent l'incohérence du nombre de références dans le noyau).

Si vous pouvez m'indiquer le PR qui, selon vous, résout le problème dans K8s, je m'efforcerai d'obtenir ce correctif dans docker au moins dans le cas où le proxy userland est désactivé par défaut. (Et nous pouvons le tester en utilisant les étapes de reproduction docker-stress).

Je ne suis pas sûr d'avoir un seul PR, mais vous pouvez regarder l'état actuel. Début
ici:

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

Le sam. 11 mars 2017 à 22:49, Madhu Venugopal [email protected]
a écrit:

@thockin https://github.com/thockin merci. je suivais le
PR/problème dans Kubernetes avec la solution de contournement en mode épingle à cheveux. Mais pendant la
beaucoup d'allers-retours, j'ai perdu la trace si la solution de contournement se débarrasse en fait de cela
problème ?
(D'après ce que je comprends, il existe différents scénarios qui provoquent le ref-count
incohérence dans le noyau).

Si vous pouvez m'indiquer le PR qui, selon vous, résout le problème dans K8s,
Je vais travailler pour que cela soit patché dans docker au moins pour le cas du tournage
userland-proxy désactivé par défaut. (Et on peut le tester en utilisant le docker-stress
étapes de reproduction).

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/docker/docker/issues/5618#issuecomment-285926217 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AFVgVIlGs_QccxS6YYQiLNybddDzB4yUks5rk5VogaJpZM4B4L4Z
.

Hé tous, juste pour être clair, tout ce que la "solution de contournement de kubernetes" fait est d'activer le mode promiscuité sur le pont sous-jacent. Vous pouvez obtenir la même chose avec ip link set <bridgename> promisc on utilisant iproute2. Cela diminue la probabilité de rencontrer le bogue mais peut ne pas l'éliminer complètement.

Maintenant, en théorie, cela ne devrait pas fonctionner ... mais pour une raison quelconque, le mode promiscuité semble ralentir le démontage de l'appareil juste assez pour que vous n'ayez pas une course pour décrémenter le compteur de références. Peut-être que l'un des contributeurs de Kurbernetes peut intervenir ici s'il est sur ce fil.

Je peux vérifier que la solution de contournement (NOT FIX) fonctionne à l'aide de ma reproduction spécifique à l'environnement. Je ne peux pas vraiment vérifier que cela aide si vous utilisez les pilotes IPVLAN ou MACVLAN (nous utilisons macvlan dans prod) car il semble très difficile d'obtenir que ces configurations produisent ce bogue. Quelqu'un d'autre peut-il essayer de vérifier la solution de contournement?

Salut à tous, j'ai essayé de déboguer le problème du noyau, j'avais une chaîne de courrier électronique sur la liste de diffusion "netdev", donc je voulais juste poster quelques résultats ici.

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

Le problème que nous constatons est que

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

pendant l'arrêt du conteneur. Lorsque j'inspecte l'espace de noms du réseau de conteneurs, il semble que le périphérique eth0 ait déjà été supprimé, mais que seul le périphérique lo y reste. Et il existe une autre structure contenant la référence de cet appareil.

Après quelques recherches, il s'avère que la "chose" contenant la référence est l'un des "caches de routage" ( struct dst_entry ). Et quelque chose empêche ce dst_entry d'être gc'ed (le nombre de références pour dst_entry est supérieur à 0). J'ai donc enregistré chaque dst_hold() (incrémenter le nombre de références dst_entry de 1) et dst_release() (décrémenter le nombre de références dst_entry de 1), et il y a en effet plus d'appels dst_hold() que dst_release() .

Voici les logs joints : kern.log.zip

Sommaire:

  • l'interface lo été renommée en lodebug pour faciliter la saisie
  • le nombre de références pour dst_entry commence par 1
  • le nombre de références pour dst_entry (qui contient la référence pour lo) à la fin est 19
  • il y a 258041 appels au total dst_hold() , et 258023 appels au total dst_release()
  • dans les appels 258041 dst_hold() , il y a 88034 udp_sk_rx_dst_set() (qui est alors appelé dst_hold() ), 152536 inet_sk_rx_dst_set() , et 17471 __sk_add_backlog()
  • dans les appels 258023 dst_release() , il y a 240551 inet_sock_destruct() et 17472 refdst_drop()

Il y a plus d'appels udp_sk_rx_dst_set() et inet_sk_rx_dst_set() au total que inet_sock_destruct() .

METTRE À JOUR:
Il s'avère que les sockets ( struct sock ) sont créés et détruits correctement, mais pour certains sockets TCP, inet_sk_rx_dst_set() sont appelés plusieurs fois sur le même dst , mais il n'y en a qu'un correspondant inet_sock_destruct() pour libérer la référence au dst .

Voici la solution de contournement CentOS 7.3 qui l'a corrigé pour moi :

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

Voici le patch qui le résout :
https://bugs.centos.org/view.php?id=12711&nbn=1

MISE À JOUR : Cela s'est avéré ne pas résoudre le problème de manière permanente. Il est réapparu plusieurs heures plus tard avec le message mural suivant :
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

@adrianotto - pour clarifier : le correctif du noyau CentOS résout-il ce problème ? Juste curieux de savoir si vous vouliez dire que votre solution de contournement et le chemin du noyau de référence n'ont pas réussi à résoudre ce problème de manière permanente?

@stayclassychicago @adrianotto Ce correctif ne traite que l'une des conditions de

@stayclassychicago avant d'essayer le noyau 3.10.0-514.10.2.el7.centos.plus.x86_64 je recevais le kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1 très régulièrement, presque à chaque fois que j'exécutais un conteneur avec docker run --rm ... lorsque le conteneur sortait. Après la mise à niveau et le redémarrage du noyau, il s'est complètement arrêté pendant plusieurs heures, puis est revenu à nouveau. Maintenant, la moitié du temps, je supprime des conteneurs, cela fonctionne correctement, là où il y avait des erreurs très souvent. Je ne sais pas avec certitude si le nouveau noyau aide, mais cela ne fait pas de mal.

On dirait qu'il est très facile à reproduire lorsqu'il y a une interface de liaison LACP sur la machine. Nous avons un cluster swarm à 3 nœuds, tous les 3 avec une interface de liaison LACP configurée, et ce problème ne nous permet fondamentalement pas de travailler avec le cluster. Nous devons redémarrer les nœuds toutes les 15-20 minutes.

Confirmé - dès que j'ai supprimé la liaison LACP des interfaces (celles-ci ont été utilisées comme interfaces principales), tout fonctionne correctement pendant plus de 12 heures. Utilisé pour se casser toutes les ~30 minutes.

Ceci est reproductible sur 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 avec Docker version 17.04.0-ce, build 4845c56 s'exécutant en mode privilégié lorsque nous avons des montages cifs ouverts. Lorsque le conteneur s'arrête avec les montages ouverts, Docker ne répond plus et nous obtenons l'erreur kernel:[ 1129.675495] unregister_netdevice: waiting for lo to become free. Usage count = 1 .

Ubuntu 16.04 (kernel 4.4.0-78-generic) a toujours le problème. Et quand cela se produit, toute application qui essaie de créer un nouvel espace de noms réseau via un clonage syscall sera bloquée

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

La seule solution est de réinitialiser la machine.

J'ai rencontré ce problème lors du montage du volume NFS dans un conteneur privilégié, puis du redémarrage du conteneur.
Il me semble que ce problème ne s'est jamais produit sur RHEL 7 avec la même procédure.

$ 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 prétend avoir une instance de ce bogue corrigée à partir de la version kernel-3.10.0-514.21.1.el7. Je suppose qu'ils vont remonter le correctif dès que possible et rebaser sur 4.12. Ce package est également déjà disponible sur CentOS 7.

Documentation relative au correctif (accès RHN requis) :
https://access.redhat.com/articles/3034221
https://bugzilla.redhat.com/show_bug.cgi?id=1436588

De l'article :
« En cas d'adresse IPv6 en double ou de problème de définition d'une adresse, une condition de concurrence s'est produite. Cette condition de concurrence a parfois provoqué une fuite de comptage de références d'adresses. Par conséquent, les tentatives de désinscription d'un périphérique réseau ont échoué avec le message d'erreur suivant : « unregister_netdevice : en attente pour devenir libre. Nombre d'utilisations = 1". Avec cette mise à jour, le code source sous-jacent a été corrigé et les périphériques réseau se désinscrivent désormais comme prévu dans la situation décrite."

J'ai déjà déployé ce correctif dans tous les systèmes de notre pool PaaS, et cela fait déjà 2 jours que le bug n'a pas été touché. Auparavant, nous avons eu au moins un système gelé par jour. Je ferai un rapport ici si nous rencontrons à nouveau le bogue.

J'ai la version du noyau 3.10.0-514.21.1.el7.x86_64, et j'ai toujours le même symptôme.

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 Apparemment, il existe plusieurs façons de

@bcdonadio Si vous regardez https://git.centos.org/commitdiff/rpms!kernel.git/b777aca52781bc9b15328e8798726608933ceded - vous verrez que le bogue https://bugzilla.redhat.com/show_bug.cgi?id=1436588 est "corrigé" par ce changement :

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

Qui est dans le noyau amont depuis 4.8, je crois (https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d). Et 4.9 et 4.10 ont ce bogue présent, donc RedHat vient de rétroporter certains des correctifs en amont, ce qui résout probablement certains problèmes, mais certainement pas tous.

@bcdonadio Je peux reproduire le bogue sur mon système en exécutant ce script de test une fois par heure à partir de cron :

#!/bin/sh

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

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

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

Ce script produit simplement une liste de packages à l'aide d'une image dans le registre Docker et une autre à l'aide d'une liste construite localement afin que je puisse les comparer. Le Dockerfile est juste ceci :

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

2-4 minutes plus tard, syslog reçoit ce message :

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

La dernière occurrence s'est produite quelques minutes après avoir exécuté le script manuellement. Je suppose qu'après un certain délai d'attente après la tentative de suppression du conteneur, la condition d'erreur est levée.

Je suis certain que la condition d'erreur est intermittente, car le script ci-dessus s'exécute comme une tâche cron à :00 après chaque erreur. Voici un exemple de la sortie d'erreur enregistrée par syslog :

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

Cela se produit donc quelque part dans la plage de 2 à 4 minutes après l'exécution et la sortie des conteneurs et est supprimé par docker à cause de l'indicateur --rm. Notez également dans le journal ci-dessus qu'il n'y a pas d'erreur pour chaque conteneur exécuté/supprimé, mais c'est assez cohérent.

Serait-il possible pour quelqu'un de voir si ce patch améliore les choses ?

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

@hlrichardson Cela y ressemble vraiment ! Je vais essayer de le rétroporter sur notre noyau 3.16 ou de mettre à niveau des serveurs spécifiques et de compiler le noyau 4.9 avec ce patch demain, nous verrons comment ça se passe.

Cependant, après avoir vérifié les références de validation de ce correctif (https://github.com/torvalds/linux/commit/0c1d70af924b966cc71e9e48920b2b635441aa50) - il a été validé dans le noyau 4.6, alors que le problème était là même avant :(

Ah, donc peut-être pas lié, à moins qu'il n'y ait plusieurs causes (malheureusement, ce type de bug peut être déclenché de plusieurs manières, c'est donc une possibilité).

Nous avons personnellement rencontré au moins plusieurs problèmes ici - dans certains d'entre eux, ces
Les journaux "unregister_netdevice" disparaissent après un certain temps et
les conteneurs docker peuvent fonctionner correctement, tandis que dans d'autres - tous les conteneurs
reste bloqué et le serveur doit être redémarré.

En fait - nous n'utilisons pas vxlan sur les serveurs qui rencontrent ces problèmes - nous utilisons
ponts simples et redirection de port (cela se produit indépendamment de userland-proxy
Les paramètres).

Le 30 mai 2017 à 22h54, "hlrichardson" [email protected] a écrit :

Ah, donc peut-être pas lié, à moins qu'il y ait plusieurs causes
(malheureusement, il existe de nombreuses façons de déclencher ce type de bogue, donc
c'est une possibilité).

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/moby/moby/issues/5618#issuecomment-304989068 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAGqoDHe1n3h9_eJ2kmeWcbhKRCX6rZoks5r_HPbgaJpZM4B4L4Z
.

OK, si vous n'utilisez pas de tunnels vxlan, cela ne vous aidera certainement pas.

BTW, si vous voyez une seule instance du message "unregister_netdevice" lorsqu'un espace de noms réseau est supprimé (sortie du conteneur), cela devrait être considéré comme une situation normale dans laquelle quelque chose faisant référence à un périphérique net a été nettoyé plus ou moins en même temps que l'espace de noms
était en train d'être supprimé.

Le cas le plus grave est celui où ce message se répète toutes les 10 secondes et ne s'arrête jamais...
dans ce cas, un verrou global est maintenu pour toujours, et puisque ce verrou doit être acquis chaque fois que le réseau
l'espace de noms est ajouté ou supprimé, toute tentative de création ou de suppression d'un espace de noms réseau est également
pend pour toujours.

Si vous avez un moyen assez simple de reproduire le deuxième type de problème, je serais intéressé par
Jeter un oeil.

@hlrichardson Nous voyons le 2ème cas que vous mentionnez ci-dessus sur un tas de nos serveurs, c'est-à-dire un message répété toutes les 10 secondes. Quelles informations voulez-vous que je partage ?

Voir cela sur Fedora 25 lors du test et de la création de conteneurs centos:7 en utilisant yum. Yum n'a pas réussi à terminer le téléchargement de la base de données des packages et s'est bloqué indéfiniment car le réseau a cessé de fonctionner de manière étrange.

Salut les gars,

Il existe un correctif potentiel pour le bogue du noyau (ou au moins un des bogues) dans la liste de diffusion Linux net-dev :

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

Il est fusionné dans l'arbre net, mis en file d'attente pour l'arbre stable.

@fxposter @kevinxucs J'essaierai de rétroporter cela vers le noyau CentOS actuel demain.

J'exécute la version 4.12 (depuis http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12/) et j'y arrive toujours, donc torvalds/ linux@d747a7a ne doit pas être la solution complète.

$ uname -r
4.12.0-041200-generic

Ryan, avez-vous un moyen fiable de vous reproduire ?

Le 6 juillet 2017 à 16h29, "Ryan Campbell" [email protected] a écrit :

J'exécute la version 4.12 (depuis http://kernel.ubuntu.com/~
kernel-ppa/mainline/v4.12/) et je frappe toujours ceci, donc torvalds/linux@
d747a7a https://github.com/torvalds/linux/commit/d747a7a ne doit pas être
le correctif complet.

$ uname -r
4.12.0-041200-générique

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/moby/moby/issues/5618#issuecomment-313413120 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAdcPCbVPDjPw6va-N5dM7CjYn2W4Bodks5sLO9ZgaJpZM4B4L4Z
.

@justincormack Malheureusement, je n'ai pas d'exemple minimal que je puisse partager, mais nous avons une suite de tests qui crée et détruit beaucoup de conteneurs et je rencontre généralement ce problème (commandes docker suspendues, beaucoup de waiting for lo to become free dans syslog) après seulement quelques itérations.

@campbellr J'ai essayé de reproduire cela maintenant trois fois et j'ai passé une bonne partie de cette semaine dessus avec peu de chance. J'ai réussi à obtenir les messages waiting for lo to become free plusieurs fois mais sans plantage/blocage par la suite. J'essaie de réduire le cas de test en créant simplement un espace de noms réseau et des interfaces veth.

Dans votre suite de tests :

  • vos conteneurs ont-ils beaucoup d'activité réseau ? Si oui, quelle direction est prédominante ?
  • Quel type de machine exécutez-vous celle-ci (nombre de cœurs, est-ce une machine virtuelle, etc.)
  • Créez-vous beaucoup de conteneurs simultanément ?
  • Vos conteneurs sortent-ils normalement ou tombent-ils en panne ?

Même des réponses partielles à ce qui précède peuvent aider à le réduire...
Merci

@rn Docker ne se

Je n'ai pas encore eu l'occasion de tester la 4.12, mais j'ai pu reproduire de manière fiable sur les instances kvm de vultr. J'exécute swarm et mes travailleurs chromés sans tête causent des problèmes lorsqu'ils échouent aux vérifications de l'état de santé ou se bloquent régulièrement. Bien sûr, à ce stade, j'ai localisé tous les planteurs qui gèrent correctement les erreurs de réseau, etc. Je vois donc waiting for lo to become free mais pas assez souvent pour bloquer les choses pendant quelques semaines.

Il semble donc que les éléments qui aident à se reproduire soient des scénarios de mise en réseau plus complexes combinés à de grandes quantités de trafic dans les conteneurs, un recyclage constant des conteneurs et un kvm.

@rn J'ai réussi à réduire cela à un conteneur spécifique dans notre suite de tests et j'ai pu reproduire avec les étapes suivantes :

  1. démarrer le conteneur (un service Web interne basé sur la tornade - j'essaie d'extraire un exemple minimal qui atteint toujours cela)
  2. faire une demande au service Web s'exécutant dans le conteneur
  3. attendre la réponse
  4. tuer le conteneur

Après 3 ou 4 itérations, je finis par obtenir waiting for lo to become free et à l'itération suivante, docker run échoue avec docker: Error response from daemon: containerd: container did not start before the specified timeout.

vos conteneurs ont-ils beaucoup d'activité réseau ? Si oui, quelle direction est prédominante ?

Une assez petite quantité. Dans les étapes mentionnées ci-dessus, la requête http est une petite quantité de json et la réponse est un blob binaire d'environ 10 Mo.

Quel type de machine exécutez-vous celle-ci (nombre de cœurs, est-ce une machine virtuelle, etc.)

C'est sur une machine de bureau à 4 cœurs (pas de VM)

Créez-vous beaucoup de conteneurs simultanément ?

Non, tout est fait en série.

Vos conteneurs sortent-ils normalement ou tombent-ils en panne ?

Ils sont arrêtés avec docker stop

  1. démarrer le conteneur (un service Web interne basé sur la tornade - j'essaie d'extraire un exemple minimal qui atteint toujours cela)
  2. faire une demande au service Web s'exécutant dans le conteneur
  3. attendre la réponse
  4. tuer le conteneur

J'ai passé du temps à démonter le conteneur et il s'est avéré que le service Web n'avait rien à voir avec le bogue. Ce qui semble déclencher cela dans mon cas, c'est le montage d'un partage NFS dans un conteneur (exécuté avec --privileged ).

Sur mon bureau, je peux reproduire de manière fiable en exécutant simplement ce qui suit à quelques reprises :

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

Utilisateurs de Kubernetes, j'ai ouvert un problème à _kops_ pour publier la prochaine AMI Kubernetes avec Kernel version 4.12. Bienvenue pour le vérifier : https://github.com/kubernetes/kops/issues/2901

J'ai également touché ceci sur centos 7.3 avec le noyau hôte 3.10.0-514.6.1.el7.x86_64 et docker-ce-17.06.0.ce-1.el7.centos.x86_64.

@FrankYu ce n'est pas utile. Pour participer utilement à ce fil de discussion, veuillez fournir un moyen exact de reproduire ce problème, et veuillez tester sur un noyau moderne. 3.10 est sorti il ​​y a quatre ans, nous discutons pour savoir s'il est corrigé ou partiellement sur une version d'il y a quatre jours.

@danielgusmao nos systèmes d'exploitation Linux RancherOS et AWS ECS AMI ont déjà ce "correctif" en place (probablement la valeur par défaut) et cela ne résout pas le problème pour nous. Nous voyons toujours le message apparaître dans les journaux tout le temps. Le seul espoir probable est que le correctif du noyau soit largement rétroporté. Bien que j'aie cherché partout et que je n'aie encore vu aucune preuve de progrès sérieux vers cela dans les bugzillas et forums RedHat/Centos/AWS Linux.

Pour être clair, le message lui-même est bénin , c'est le crash du noyau après les messages rapportés par l'OP qui ne l'est pas.

Le commentaire dans le code, d'où vient ce message, explique ce qui se passe. Fondamentalement, chaque utilisateur, tel que la pile IP) d'un périphérique réseau (comme la fin d' veth paire ici de temps en temps .

Si un utilisateur de périphérique réseau ne décrémente jamais le nombre de références, une autre partie du noyau déterminera que la tâche en attente de nettoyage est bloquée et qu'elle plantera. C'est seulement ce plantage qui indique un bogue du noyau (certains utilisateurs, via un chemin de code, n'ont pas décrémenté le nombre de références). Il y a eu plusieurs bogues de ce type et ils ont été corrigés dans le noyau moderne (et éventuellement rétroportés sur les anciens). J'ai écrit pas mal de stress tests (et continue de les écrire) pour déclencher de tels plantages mais je n'ai pas pu reproduire sur les noyaux modernes (je fais cependant le message ci-dessus).

Veuillez ne signaler ce problème que si votre noyau plante réellement, et nous serions alors très intéressés par :

  • version du noyau (sortie de uname -r )
  • Distribution/version Linux
  • Êtes-vous sur la dernière version du noyau de votre fournisseur Linux ?
  • Configuration du réseau (pont, overlay, IPv4, IPv6, etc.)
  • Description de la charge de travail (quel type de conteneurs, quel type de charge réseau, etc.)
  • Et idéalement une simple reproduction

Merci

[ @thaJeztah pourriez-vous changer le titre en quelque chose comme kernel crash after "unregister_netdevice: waiting for lo to become free. Usage count = 3" pour le rendre plus explicite]

Devrait être corrigé dans le noyau 4.12 ou plus tard. Vérifiez s'il vous plaît. https://access.redhat.com/solutions/3105941
et lien vers le correctif https://github.com/torvalds/linux/commit/d747a7a51b00984127a88113cdbbc26f91e9d815

@drweber vous trouverez également ce patch dans les prochaines versions stables (pour l'instant 4.11.12, 4.9.39, 4.4.78, 3.18.62)

@rn

Si un utilisateur de périphérique réseau ne décrémente jamais le nombre de références, une autre partie du noyau déterminera que la tâche en attente de nettoyage est bloquée et qu'elle plantera. C'est seulement ce plantage qui indique un bogue du noyau (certains utilisateurs, via un chemin de code, n'ont pas décrémenté le nombre de références). Il y a eu plusieurs bogues de ce type et ils ont été corrigés dans le noyau moderne (et éventuellement rétroportés sur les anciens). J'ai écrit pas mal de stress tests (et continue de les écrire) pour déclencher de tels plantages mais je n'ai pas pu reproduire sur les noyaux modernes (je fais cependant le message ci-dessus).

Veuillez ne signaler ce problème que si votre noyau plante réellement...

Nous avons un problème légèrement différent dans notre environnement sur lequel j'espère obtenir des éclaircissements (kernel 3.16.0-77-generic, Ubuntu 14.04, docker 1.12.3-0~trusty. Nous avons des milliers d'hôtes exécutant docker, 2 -3 conteneurs par hôte, et nous le constatons sur < 1% du total des hôtes exécutant docker).

En fait, nous ne voyons jamais le crash du noyau, mais à la place (comme les reporters originaux pour autant que je sache), le processus dockerd est obsolète. Upstart (en utilisant le travail /etc/init/docker.conf du package en amont) ne démarrera pas un nouveau processus dockerd car il pense qu'il est déjà en cours d'exécution ( start: Job is already running: docker ) et tente d'arrêter l'upstart le travail échoue également ( 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>

Étant donné que nous fonctionnons principalement avec un réseau de pont (sur un périphérique de pont personnalisé) dans dmesg nous voyons un message légèrement différent faisant référence à l'interface virtuelle :

[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

Étant donné que upstart semble refuser de redémarrer dockerd ou reconnaître que le processus en cours d'exécution précédemment est un zombie, la seule solution que nous avons trouvée est de redémarrer l'hôte.

Bien que notre résultat semble différent (le noyau ne plante pas), la cause première semble identique ou similaire. N'est-ce pas le même problème alors ? Existe-t-il une solution de contournement connue ou un moyen pour que le travail de démarrage docker redevienne exécutable lorsque cela se produit ?

@campbellr Je peux reproduire ce problème avec votre approche sur le noyau 4.12.2-1.
BTW, si je démonte le stockage NFS avant l'arrêt du conteneur, ce problème ne se produira pas.

même problème.

[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

Salut,

Je viens de créer 2 repos https://github.com/piec/docker-samba-loop et https://github.com/piec/docker-nfs-loop qui contiennent le setup nécessaire pour reproduire ce bug

Mes résultats:

  • Noyau 4.11.3-1-ARCH (Arch Linux) : je génère le bug avec docker-samba-loop en quelques itérations (<10). Je ne peux pas le reproduire avec docker-nfs-loop
  • 4.11.9-1-ARCH mêmes résultats ( versions )
  • 4.12.3-1-ARCH (test repo) mêmes résultats
  • 4.11.11-coreos : mêmes résultats pour docker-samba-loop , n'a pas essayé docker-nfs-loop

J'espère que cela t'aides
À votre santé

Une solution de contournement consiste à utiliser --net=host dans mon cas. Mais ce n'est pas toujours une solution acceptable

@piec , merci beaucoup pour les détails. J'ai encore quelques questions à vous poser à la fin de ce très long commentaire.

En utilisant la configuration SMB, j'ai pu produire un certain nombre de choses avec différents noyaux. J'ai également essayé cela avec la configuration NFS, mais pas de dés.

Tous les tests sont exécutés avec docker 17.06.1-ce sur HyperKit avec une VM configurée avec 2 vCPU et 2 Go de mémoire (via Docker pour Mac, mais cela ne devrait pas avoir d'importance). J'utilise des noyaux LinuxKit, car je peux facilement les échanger.

J'ai modifié votre Dockerfile en ce sens que j'ai ajouté un appel à date comme première commande exécutée et j'ai également ajouté un appel à date avant et après le docker run pour le client.

Expérience 1 (noyau 4.9.39)

Avec la version 4.9.39 (dernier noyau stable 4.9.x), j'obtiens un plantage du noyau :

# 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

et en dmesg :

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

Parfois, je vois plusieurs itérations de ce que fait le noyau 4.11.12, y compris les messages unregister_netdevice (voir ci-dessous), puis j'obtiens le plantage du noyau ci-dessus. Parfois, je vois de légères variations pour le crash, comme :

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

Les plantages sont dans le code socket du domaine unix et similaires/identiques à ce qui est
rapporté ici , bien qu'avec ce nouveau cas de test, il soit beaucoup plus facile à reproduire.

Expérience 2 (noyau 4.11.12)

Avec 4.11.12 (qui est la dernière version stable de la série 4.11) je ne vois aucun plantage, mais c'est vraiment lent (annotations en ligne avec ---> ):

# 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

J'ai fait fonctionner cela pendant environ une heure avec le même motif qui se répète, mais aucun plantage du noyau.

Je vois les journaux du noyau, beaucoup de :

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

C'est un message toutes les dix secondes.

Étant donné que cela ne provoque pas le déclenchement de la détection des tâches bloquées même après une heure, je soupçonne qu'avec 4.11.12, le nombre de références finit par être décrémenté et que l'appareil est libéré, mais, à en juger par les intervalles où je peux exécuter des conteneurs, cela peut prendre jusqu'à 4 minutes !

Expérience 3 (noyau 4.11.12)

Le crash du noyau dans l'OP a indiqué que le noyau s'est écrasé car une tâche bloquée a été détectée. Je n'ai pas vu ce plantage lors de mes tests, j'ai donc modifié le paramètre sysctl lié à la détection des tâches bloquées :

# 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

Cela réduit le délai d'attente à 60 secondes et panique le noyau si une tâche bloquée est détectée. Comme cela prend environ 2 minutes avant que dockerd plaint que containerd ne démarre pas, réduire la détection des tâches bloquées à 60s devrait déclencher une panique du noyau si une seule tâche était bloquée. Hélas il n'y a eu aucun plantage dans les logs

Expérience 4 (noyau 4.11.12)

Ensuite, j'augmente les sleep après chaque docker run à 5 minutes pour voir si les messages sont continus. Dans ce cas, tous les docker run semblent fonctionner, ce qui est un peu attendu puisque d'après les expériences précédentes, un docker run fonctionnerait toutes les 4 minutes environ

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

Il semble que nous obtenions environ 200 secondes de unregister_netdevice sur presque tous les docker run (sauf pour le second). Je soupçonne que pendant ce temps, nous ne pouvons pas démarrer de nouveaux conteneurs (comme indiqué par l'expérience 2. Il est curieux que la détection des tâches bloquées ne démarre pas, probablement parce qu'aucune tâche n'est bloquée.

Expérience 5 (4.11.12/4.9.39 avec une activation de débogage supplémentaire dans le noyau)

Cela revient au sommeil 1s entre docker run

Nous avons un autre noyau qui a permis un tas de débogages supplémentaires
options, telles que LOCKDEP , RCU_TRACE , LOCKUP_DETECTOR et quelques
Suite.

L'exécution des noyaux repro 4.11.12 avec ces options de débogage activées n'a rien déclenché.

Idem pour le noyau 4.9.39, où le noyau normal plante. Les options de débogage changent légèrement le timing, donc c'est peut-être un indice supplémentaire que le plantage dans le code du socket de domaine unix montre qu'il est dû à une course.

Creuser un peu plus

strace sur les divers processus containerd n'est pas utile (il
n'est généralement pas parce qu'il est écrit en Go). Beaucoup de longues stalles dans
futex(...FUTEX_WAIT...) avec toute information sur où/pourquoi.

Certains fouinent avec sysrq :

Augmenter la verbosité :

echo 9 > /proc/sysrq-trigger

Trace de pile de tous les processeurs :

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

Rien ici, CPU1 est inactif, CPU0 gère le sysrq.

Afficher les tâches bloquées (deux fois)

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

Cela montre que les files d'attente de travail netns et cleanup_net sont occupées. J'ai trouvé un problème quelque peu connexe il y a quelque temps ici , mais cette fois, la file d'attente cleanup_net travail

Sommaire

  • Je pense que le plantage sur les noyaux 4.9.x n'est pas lié mais semble être corrigé dans 4.11.x. Cela nécessite un peu plus de tri.
  • Contrairement à certains rapports précédents, aucune tâche bloquée n'est signalée, mais c'est difficile à dire car il y a très peu de traces de pile sur ce problème.
  • Quelque chose est bloqué pendant très longtemps (2-4 minutes). C'est probablement lié à l'état de la file d'attente
  • Le vidage de la file d'attente de travail nécessite une analyse plus approfondie, en particulier pourquoi la file d'attente de travail reste dans cet état aussi longtemps.
  • Les messages unregister_netdev semblent pas liés au correctif récent (qui se trouve à la fois dans les versions 4.9.39 et 4.11.12). C'est peut-être parce que la file d'attente de travail cleanup_net ne progresse pas et donc le message est imprimé.
  • On ne sait pas du tout comment/pourquoi SMB déclenche cela. J'ai écrit quelque 60 tests de stress étranges pour les espaces de noms réseau et différentes charges de travail et je n'ai pu déclencher aucun problème. Les tests étaient basés sur runc , je devrais peut-être essayer containerd .

Je vais creuser un peu plus et ensuite envoyer un résumé à netdev .

@piec avez-vous accès à la console et pouvez-vous voir s'il y a quelque chose en termes de vidage sur incident ou voyez-vous également d'énormes retards comme je le vois? Si vous avez un vidage sur incident, je serais très intéressé de le voir. De plus, utilisez-vous du bare metal ou dans une VM ? Quelle est votre configuration en termes de processeurs et de mémoire ?

@rn merci pour les enquêtes !

Je fonctionne sur un PC de bureau baremetal donc j'ai accès à tout. C'est un i7-4790K + 32 Gio.
Actuellement, je fonctionne sur un noyau Arch Linux + à jour à partir du référentiel de test (4.12.3-1-ARCH)

Dans mon cas, tout se comporte comme vous le décrivez dans votre expérience 2 (noyau 4.11.12) :

  • Une fois que le conteneur client-smb existe, l'exécution de nouveaux conteneurs est impossible pendant plus de 4 minutes.
  • Je n'ai jamais de plantage du noyau
  • Le message unregister_netdevice: waiting for lo to become free. Usage count = 1 apparaît à plusieurs reprises si j'essaie d'exécuter un nouveau conteneur dans les 4 minutes et plus après la sortie du client-smb. Et n'apparaît que si vous exécutez un nouveau conteneur dans ce laps de temps de 4 minutes. L'exécution d'un nouveau conteneur après ces 4 minutes sera "normale"

Je suppose donc qu'il y a un problème quelque part dans le processus de nettoyage du conteneur smb-client lié aux interfaces réseau

Il existe en fait une reproduction beaucoup plus simple de ce problème (qui, d'ailleurs, n'est pas le problème d'origine).

Ce script démarre simplement un serveur SMB sur l'hôte, puis crée un espace de noms réseau avec une paire veth , exécute mount; ls; unmount dans l'espace de noms réseau, puis supprime l'espace de noms réseau.

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

Notez que l'ajout d'un simple sleep 1 après le démontage, soit lors de l'exécution dans l'espace de noms, soit avant la suppression de l'espace de noms réseau fonctionne sans blocage du tout lors de la création du nouvel espace de noms. Une mise en veille après la suppression de l'ancien espace de noms ne réduit pas le décrochage.

@piec J'ai également testé cela avec votre repro et un sleep 1 dans le Dockerfile après le démontage et tout fonctionne comme prévu, pas de blocage, pas unregister_netdev messages

Je vais l'écrire maintenant et l'envoyer à netdev@vger

Excellent
Je confirme qu'un sleep après le démontage corrige également le blocage et les messages unregister_netdev dans ma configuration

Ne pensez-vous pas que umount génère une action asynchrone par rapport à ses réseaux qui se bloqueront et finiront par expirer si les réseaux sont supprimés avant la fin de cette action ? Un sommeil après le montage laisserait ces choses se terminer avant que les réseaux ne soient supprimés.
Mais ce n'est qu'une hypothèse

J'ai essayé sans le démonter, même différence. C'est la suppression de l'espace de noms du réseau. Cela 9 et la suppression de l'espace de noms de montage déclenchera le démontage de toute façon.

Ah ok

Au fait, j'ai reproduit le problème par erreur (en développant) sur une autre machine avec smb à nouveau. C'est un PC Ubuntu 16.04, Linux 4.4.0-77-generic. Et il y a un backtrace de tâche bloquée qui pourrait être intéressant. Pas de plantage et même délai de ~4 minutes.

[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

Le fil netdev@vger est ici https://www.mail-archive.com/[email protected]/msg179703.html si quelqu'un veut suivre les progrès.

@piec oui, c'est prévu.

J'ai également rencontré ce bogue et j'ai pu reproduire Oopses avec la méthode docker-samba-loop de @piec sur les images du noyau Ubuntu :

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

J'ai ajouté mes conclusions au rapport de bogue Ubuntu : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407 et https://github.com/fho/docker-samba-loop

@fho merci. En fait, vous n'avez pas du tout besoin de docker pour reproduire, le simple fait d'exécuter le client samba dans un espace de noms réseau fera l'affaire selon https://github.com/moby/moby/issues/5618#issuecomment -318681443

@rn merci pour l'info. Je n'ai pas encore essayé de cette façon.

Les messages récents ici et et sur la liste de diffusion netdev semblent ne concerner que les décrochages du noyau.
J'ai également des plantages du noyau avec les noyaux 4.11 et 4.12.

Je vois un problème très similaire à celui-ci (comme détaillé dans #35068). Nous exécutons essentiellement un essaim à deux nœuds, qui exécute un service unique avec 4 réplicas en utilisant une stratégie de placement de propagation.

Dans chacun de ces conteneurs de services, nous montons l'hôte docker.sock en tant que volume, et à partir du conteneur, nous exécutons les commandes docker run , avec une simultanéité maximale de 4 par conteneur. Il en résulte que jusqu'à 4 conteneurs sont créés simultanément et immédiatement supprimés via -rm .

Journaux de noyau supplémentaires et exemples sur ARMv7 indiqués dans la référence ci-dessus.

ip6_route_dev_notify La panique est un problème sérieux pour nous.

Je pense qu'en y regardant un peu plus, ce n'est certainement PAS le même bug que :

Je pense que c'est un problème en amont du noyau avec la couche ipv6.

Ces informations peuvent être pertinentes.

Nous sommes capables de reproduire le problème avec _unregister_netdevice : attendre que lo devienne libre. Nombre d'utilisations = 1_ avec le noyau 4.14.0-rc3 avec _CONFIG_PREEMPT_NONE=y_ et ne s'exécutant que sur un seul processeur avec les options de noyau de démarrage suivantes :

BOOT_IMAGE=/boot/vmlinuz-4.14.0-rc3 root=/dev/mapper/vg0-root ro quiet vsycall=émuler nosmp

Une fois que nous avons atteint cet état, il reste dans cet état et un redémarrage est nécessaire. Plus aucun conteneur ne peut être généré. Nous le reproduisons en exécutant des images en faisant des connexions ipsec/openvpn + en téléchargeant un petit fichier à l'intérieur des tunnels. Alors les instances existent (généralement elles s'exécutent < 10s). Nous exécutons 10s de ces conteneurs par minute sur une seule machine. Avec les paramètres mentionnés ci-dessus (seulement 1cpu), la machine l'atteint en ~2 heures.

Un autre reproducteur avec le même noyau, mais sans limiter le nombre de processeurs, consiste à exécuter iperf en mode UDP pendant 3 secondes à l'intérieur du conteneur (il n'y a donc aucune communication TCP). Si nous exécutons 10 de ces conteneurs en parallèle, attendez qu'ils soient tous terminés et recommencez, nous rencontrons le problème en moins de 10 minutes (sur une machine à 40 cœurs).

Dans nos deux reproducteurs, nous avons ajouté « ip route flush table all ; ifconfigvers le bas; dormez 10" avant d'exister à partir de conteneurs. Cela ne semble pas avoir d'effet.

Salut,

Juste pour ajouter au feu, nous voyons également ce problème, comme demandé voici ce qui suit...

Version du noyau : Linux exe-v3-worker 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64 GNU/Linux

Distribution/version Linux : Debian 9.1 (avec tous les paquets à jour)

Êtes-vous sur la dernière version du noyau de votre fournisseur Linux ? Oui

Configuration du réseau (pont, superposition, IPv4, IPv6, etc.) : IPv4 uniquement, NAT selon la configuration Docker par défaut

Description de la charge de travail (quel type de conteneurs, quel type de charge réseau, etc.) : Conteneurs de très courte durée (de quelques secondes à quelques minutes) exécutant des scripts avant de sortir.

Et idéalement une simple reproduction :

**kernel :[617624.412100] unregister_netdevice : en attente de la libération de lo. Nombre d'utilisations = 1

Impossible de tuer l'ancien conteneur ou d'en démarrer de nouveaux sur les nœuds affectés, a dû redémarrer pour restaurer la fonctionnalité.**

Espérons que nous trouverons bientôt une cause racine / un correctif.

Meilleures salutations,

robputt796

@campbellr
convenu qu'il semble avoir quelque chose à voir avec le stockage en réseau. J'utilise ceph krbd comme volume persistant dans kubernetes.
Et je peux reproduire la situation après un crash de conteneur de longue durée.

Le problème a été attribué il y a 10 jours et c'est un travail en cours, vous pouvez voir plus d'informations sur ce qui se passe ici https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407

Espérons que Dan Streetman trouve comment y remédier

Il s'avère que l'Oups est causé par un bogue du noyau qui a été corrigé par le commit 76da0704507bbc51875013f6557877ab308cfd0a :

ipv6 : n'appelez ip6_route_dev_notify() qu'une seule fois pour NETDEV_UNREGISTER

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76da0704507bbc51875013f6557877ab308cfd0a
(Cela corrige simplement la panique du noyau, pas le problème "kernel:unregister_netdevice: wait for lo to be free. Usage count = 2".)

(en répétant cela ici, car GitHub cache d'anciens commentaires)

Si vous arrivez ici

Le problème discuté ici est un bogue du noyau et n'a pas encore été complètement résolu. Certains correctifs ont été intégrés au noyau pour corriger _quelques_ occurrences de ce problème, mais d'autres ne sont pas encore résolus.

Il existe un certain nombre d'options qui peuvent aider dans _certaines_ situations, mais pas pour toutes (encore une fois, il s'agit très probablement d'une combinaison de problèmes qui déclenchent la même erreur)

Ne laissez pas de commentaires "J'ai ça aussi"

"J'ai ça aussi" n'aide pas à résoudre le bug. ne laissez un commentaire que si vous avez des informations qui peuvent aider à résoudre le problème (auquel cas, fournir un correctif au noyau en amont peut être la meilleure étape).

Si vous voulez faire savoir que vous avez également ce problème, utilisez le bouton « pouce vers le haut » dans la description du haut :
screen shot 2017-03-09 at 16 12 17

Si vous souhaitez rester informé des mises à jour, utilisez le _bouton d'abonnement_.

screen shot 2017-03-09 at 16 11 03

Chaque commentaire ici envoie un e-mail/une notification à plus de 3000 personnes. Je ne veux pas verrouiller la conversation sur ce problème, car il n'est pas encore résolu, mais peut être forcé de le faire si vous l'ignorez.

Je vais supprimer les commentaires qui n'ajoutent pas d'informations utiles afin de raccourcir (légèrement) le fil

Si vous voulez aider à résoudre ce problème

  • Lisez tout le fil; c'est long, et github masque les commentaires (vous devrez donc cliquer pour les rendre à nouveau visibles). Il y a déjà beaucoup d'informations présentes dans ce fil qui pourraient éventuellement vous aider
  • Lisez ce commentaire https://github.com/moby/moby/issues/5618#issuecomment -316297818 (et les commentaires à cette époque) pour obtenir des informations qui peuvent être utiles.

Merci!

Je pense avoir résolu ce problème, du moins lorsqu'il est causé par une connexion socket TCP du noyau. Des noyaux de test pour Ubuntu sont disponibles et j'aimerais recevoir des commentaires s'ils aident / corrigent ce problème pour quiconque ici. Le correctif est soumis en amont ; plus de détails sont dans le bogue LP :
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/comments/46

Désolé de gâcher la célébration, mais nous avons pu reproduire le problème. Nous travaillons maintenant avec @ddstreet sur https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/ .

N'y a-t-il pas de solutions de contournement ?

Utilisez la mise en réseau de l'hôte (qui détruit une grande partie de la valeur des conteneurs, mais voilà).

@pumba-lt Nous avons eu ce problème il y a environ 1,5 ans, il y a environ 1 an, j'ai désactivé ipv6 au niveau du noyau (pas sysctl) et je n'ai pas eu le problème une seule fois. Exécution d'un cluster de 48 lames.

Normalement en : /etc/default/grub
GRUB_CMDLINE_LINUX="xxxxx ipv6.disable=1"

Cependant, j'utilise le démarrage PXE, donc ma configuration PXE a :

      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

Je vous assure que vous ne reverrez plus ce problème.

Tout le monde s'il vous plaît comprendre qu'il s'agit d'un SYMPTME commun qui a de nombreuses causes. Ce qui a fonctionné pour vous pour éviter cela peut ne pas fonctionner pour quelqu'un d'autre.

Je peux confirmer que nos problèmes ont été résolus après avoir désactivé IPv6 au démarrage (fichier de configuration de grub). A eu de nombreux problèmes dans un cluster à 7 nœuds, fonctionne bien maintenant.

Je ne me souviens pas où j'ai trouvé la solution, ou l'ai-je trouvée moi-même, merci @qrpike d' avoir suggéré cela aux autres :) !!

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

commettre edaafa805e0f9d09560a4892790b8e19cab8bf09
Auteur : Dan Streetman [email protected]
Date : jeu. 18 janvier 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]>

"Unregister_netdevice: en attente que eth0 devienne libre. Nombre d'utilisations = 1" bien que j'aie mis à niveau la version du noyau vers la 4.4.118 et la version docker 17.09.1-ce, je devrais peut-être essayer de désactiver ipv6 au niveau du noyau . J'espère que le cloud fonctionnera.

@ wuming5569 s'il vous plaît laissez-moi savoir si cela a fonctionné pour vous avec cette version de Linux

@ wuming5569 peut-être, mettre à niveau le noyau 4.4.114, corriger "unregister_netdevice: attendre que lo devienne libre. Nombre d'utilisations = 1", pas pour "unregister_netdevice: attendre que eth0 devienne libre. Nombre d'utilisations = 1".
J'ai testé en production.
@ddstreet c'est un retour, de l'aide ?

@ wuming5569 comme mentionné ci-dessus, les messages eux-mêmes sont bénins mais ils peuvent éventuellement conduire à la suspension du noyau. Votre noyau se bloque et si oui, quel est votre modèle de réseau, c'est-à-dire quel type de réseau font vos conteneurs ?

J'ai rencontré le même problème sur CentOS. Mon noyau est 3.10.0-693.17.1.el7.x86_64. Mais, je n'ai pas obtenu de trace de pile similaire dans syslog.

Idem sur le noyau Centos7 3.10.0-514.21.1.el7.x86_64 et docker 18.03.0-ce

@danielefranceschi Je vous recommande de passer au dernier noyau CentOS (au moins 3.10.0-693). Cela ne résoudra pas le problème, mais cela semble être beaucoup moins fréquent. Dans les noyaux 3.10.0-327 et 3.10.0-514, nous voyions la trace de la pile, mais de mémoire, je ne pense pas que nous en ayons vu dans 3.10.0-693.

@alexhexabeam 3.10.0-693 semble fonctionner parfaitement, tnx :)

Idem sur le noyau CentOS7 4.16.0-1.el7.elrepo.x86_64 et docker 18.03.0-ce

Cela a fonctionné pendant des semaines avant le crash et quand j'ai essayé de monter, cela a complètement bloqué.

Le problème s'est également produit avec le noyau 3.10.0-693.21.1.el7

Je peux confirmer que cela se produit également sur :

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

Je peux le reproduire en faisant "service docker restart" tout en ayant une certaine charge.

@ wuming5569 avez-vous résolu ce problème ? Quel est votre type de réseau ? nous avons été confus par ce problème pendant des semaines.
Avez-vous un compte wechat ?

4admin2root, compte tenu du correctif que vous avez mentionné, https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.114 ,

est-il sûr de désactiver le proxy userland pour le démon docker, si le noyau récent approprié est installé? Il n'est pas très clair si c'est de

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

Étant donné que les deux sont plus anciens que le correctif du noyau

Merci

nous avons été confus par ce problème pendant des semaines.
Linux 3.10.0-693.17.1.el7.x86_64
CentOS Linux version 7.4.1708 (Core)

Quelqu'un peut-il confirmer si le dernier noyau 4.14 a ce problème ? On dirait que non. Personne sur Internet n'a rencontré ce problème avec le noyau 4.14.

Je vois cela dans le noyau 4.15.15-1, Centos7

En regardant les journaux des modifications, https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.15.8 a un correctif pour SCTP, mais pas TCP. Vous pouvez donc essayer la dernière version 4.14.

  • même 4.15.18 n'aide pas avec ce bug
  • désactiver ipv6 n'aide pas aussi bien

nous avons maintenant mis à niveau vers 4.16.13. Observer. Ce bug nous frappait sur un seul nœud environ une fois par semaine.

Avez-vous désactivé ipv6 dans les paramètres de démarrage grub ou sysctl ? Seuls les paramètres de démarrage fonctionneront. Sysctl ne le résoudra pas.

Le 4 juin 2018 à 12:09:53 PM, Sergey Pronin ( [email protected] (mailto:[email protected])) a écrit :

même 4.15.18 n'aide pas avec ce bug
désactiver ipv6 n'aide pas aussi bien

nous avons maintenant mis à niveau vers 4.16.13. Observer. Ce bug nous frappait sur un seul nœud environ une fois par semaine.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub(https://github.com/moby/moby/issues/5618#issuecomment-394410321), ou coupez le fil (https://github.com/notifications/unsubscribe-auth /AAo3HLYI_jnwjgtQ0ce-E4mc6Em5yeISks5t5VvRgaJpZM4B4L4Z).

pour moi, la plupart du temps le bug apparaît après avoir redéployé le même projet/réseau

@qrpike vous avez raison, nous n'avons essayé que sysctl. Laisse-moi essayer avec de la bouffe. Merci!

4.9.88 Noyau Debian. Reproductible.

@qrpike vous avez raison, nous n'avons essayé que sysctl. Laisse-moi essayer avec de la bouffe. Merci!

Dans mon cas, la désactivation d'ipv6 n'a fait aucune différence.

@spronin-aurea La désactivation d'ipv6 au niveau du chargeur de démarrage a-t-elle été utile ?

@qrpike pouvez-vous nous parler des nœuds que vous utilisez si la désactivation d'ipv6 vous a aidé dans votre cas ? Version noyau, version k8s, CNI, version docker etc.

@komljen J'utilise CoreOS depuis 2 ans sans un seul incident. Depuis ~ver 1000. Je ne l'ai pas essayé récemment, mais si je ne désactive pas ipv6, le bogue se produit.

De mon côté, j'utilise aussi CoreOS, ipv6 désactivé avec grub et j'ai toujours le problème

@deimosfr J'utilise actuellement le démarrage PXE pour tous mes nœuds :

      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

Cependant, mon nœud principal qui est l'hôte PXE est également CoreOS et démarre à partir du disque, et n'a pas non plus le problème.

Quelles versions de noyau utilisez-vous ?

Ceux dont j'ai eu le problème étaient sur 4.14.32-coreos et avant. Je ne rencontre pas encore ce problème sur 4.14.42-coreos

Centos 7.5 avec le noyau 4.17.3-1, a toujours le problème.

Env :
kubernetes 1.10.4
Docker 13.1
avec le plugin réseau Flannel.

Enregistrer :
[ 89.790907] IPv6 : ADDRCONF(NETDEV_UP) : eth0 : le lien n'est pas prêt
[ 89.798523] IPv6 : ADDRCONF(NETDEV_CHANGE) : eth0 : le lien devient prêt
[ 89.799623] cni0 : le port 8 (vethb8a93c6f) est entré en état de blocage
[ 89.800547] cni0 : le port 8 (vethb8a93c6f) est entré dans l'état désactivé
[ 89.801471] l'appareil vethb8a93c6f est entré en mode promiscuité
[ 89.802323] cni0 : le port 8 (vethb8a93c6f) est entré en état de blocage
[ 89.803200] cni0 : le port 8 (vethb8a93c6f) est entré dans l'état de transfert

kernel:unregister_netdevice : en attente que lo devienne libre. Nombre d'utilisations = 1。

Maintenant :
L'IP du nœud peut atteindre, mais ne peut utiliser aucun service réseau, comme ssh...

Les symptômes ici sont similaires à de nombreux rapports dans divers autres endroits. Tout cela a à voir avec les espaces de noms réseau. Les personnes qui rencontrent cela pourraient-elles voir si unshare -n bloque, et si c'est le cas, à partir d'un autre terminal, effectuez cat /proc/$pid/stack du processus d'annulation du partage pour voir s'il se bloque dans copy_net_ns() ? Cela semble être un dénominateur commun pour de nombreux problèmes, y compris certaines traces trouvées ici. Entre la 4.16 et la 4.18, Kirill Tkhai a apporté un certain nombre de correctifs qui ont beaucoup remanié le verrouillage impliqué. Les responsables des paquets de distribution/noyau affectés devraient probablement envisager de les appliquer/rétroporter vers des noyaux stables et voir si cela aide.
Voir aussi : 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

Compte tenu des changements de verrouillage dans 4.18, il serait bon de tester le 4.18rc actuel, surtout si vous pouvez le déclencher de manière plus ou moins fiable, car d'après ce que j'ai vu, il y a beaucoup de gens où le changement de version du noyau a également changé la probabilité que cela se produise beaucoup.

J'ai eu ces problèmes avec Kubernetes et après être passé à la dernière version stable de CoreOS - 1745.7.0, le problème a disparu :

  • noyau : 4.14.48
  • docker : 18.03.1

même problème sur CentOS 7

  • noyau : 4.11.1-1.el7.elrepo.x86_64
  • docker : 17.12.0-ce

@Blub Voir la même chose sur CoreOS 1688.5.3, noyau 4.14.32

ip-10-72-101-86 core # cat /proc/59515/stack
[<ffffffff9a4df14e>] copy_net_ns+0xae/0x200
[<ffffffff9a09519c>] create_new_namespaces+0x11c/0x1b0
[<ffffffff9a0953a9>] unshare_nsproxy_namespaces+0x59/0xb0
[<ffffffff9a07418d>] SyS_unshare+0x1ed/0x3b0
[<ffffffff9a003977>] do_syscall_64+0x67/0x120
[<ffffffff9a800081>] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[<ffffffffffffffff>] 0xffffffffffffffff

En théorie, il peut y avoir une ou plusieurs autres traces quelque part contenant l'une des fonctions de net_namespace.c verrouillant le net_mutex ( cleanup_net , net_ns_barrier , net_ns_init , {,un}register_pernet_{subsys,device} ). Pour les noyaux stables, il serait bien sûr beaucoup plus facile s'il y avait un blocage particulier d'une manière qui pourrait être corrigée, que de rétroporter toutes les modifications de verrouillage de la version 4.18. Mais jusqu'à présent, je n'ai pas vu de trace menant à la cause première. Je ne sais pas si cela vous aidera, mais peut-être que d'autres /proc/*/stack avec les fonctions ci-dessus sont visibles lorsque le problème apparaît ?

même problème ! et mon environnement est debian 8
debian-docker
docker

RHEL, ESSAI, 18.03.0-ce

  1. Connexion au nœud du gestionnaire via ssh
  2. Démarrage manuel d'un conteneur sur un nœud de gestionnaire :

    sudo docker run -it -v /import:/temp/eximport -v /home/myUser:/temp/exhome docker.repo.myHost/ fedora:23 /bin/bash

  3. Après un certain temps sans rien faire :

    [ racine@8a9857c25919 monRépertoire]#
    Message de syslogd@se1-shub-t002 du 19 juillet 11:56:03 ...
    kernel:unregister_netdevice : en attente que lo devienne libre. Nombre d'utilisations = 1

Au bout de quelques minutes je suis de retour sur la console du manager node et le conteneur démarré ne fonctionne plus.

Cela décrit-il le même problème ou s'agit-il d'une autre « suite de problèmes » ?

THX d'avance !

METTRE À JOUR
Cela se produit également directement sur la console ssh (sur le bash du gestionnaire de swarm).

METTRE À JOUR
Machine hôte (un nœud de gestionnaire dans l'essaim) :
Linux [NOM MACHINE] 3.10.0-514.2.2.el7.x86_64 #1 SMP mer. 16 novembre 13:15:13 EST 2016 x86_64 x86_64 x86_64 GNU/Linux

Si cela ne résout pas après un certain temps, alors c'est un problème différent.

Idem sur le noyau CentOS7.5 3.10.0-693.el7.x86_64 et docker 1.13.1

Le même problème OEL 7.5
uname -a
4.1.12-124.16.1.el7uek.x86_64 #2 SMP Lun 11 juin 20:09:51 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
informations sur les dockers
Conteneurs : 9
Course à pied : 5
En pause : 0
Arrêté : 4
Images : 6
Version du serveur : 17.06.2-ol

dmesg
[2238374.718889] unregister_netdevice : en attente que lo se libère. Nombre d'utilisations = 1
[2238384.762813] unregister_netdevice : en attente de la libération de lo. Nombre d'utilisations = 1
[2238392.792585] eth0 : renommé à partir de vethbed6d59

(en répétant ceci https://github.com/moby/moby/issues/5618#issuecomment-351942943 ici encore, car GitHub cache les anciens commentaires)

Si vous arrivez ici

Le problème discuté ici est un bogue du noyau et n'a pas encore été complètement résolu. Certains correctifs ont été intégrés au noyau pour corriger _quelques_ occurrences de ce problème, mais d'autres ne sont pas encore résolus.

Il existe un certain nombre d'options qui peuvent aider dans _certaines_ situations, mais pas pour toutes (encore une fois, il s'agit très probablement d'une combinaison de problèmes qui déclenchent la même erreur)

L'erreur "unregister_netdevice: wait for lo to be free" elle-même n'est pas le bogue

Si c'est le plantage du noyau _après_ c'est un bogue (voir ci-dessous)

Ne laissez pas de commentaires "J'ai ça aussi"

"J'ai ça aussi" n'aide pas à résoudre le bug. ne laissez un commentaire que si vous avez des informations qui peuvent aider à résoudre le problème (auquel cas, fournir un correctif au noyau en amont peut être la meilleure étape).

Si vous voulez faire savoir que vous avez également ce problème, utilisez le bouton « pouce vers le haut » dans la description du haut :
screen shot 2017-03-09 at 16 12 17

Si vous souhaitez rester informé des mises à jour, utilisez le _bouton d'abonnement_.

screen shot 2017-03-09 at 16 11 03

Chaque commentaire ici envoie un e-mail/une notification à plus de 3000 personnes. Je ne veux pas verrouiller la conversation sur ce problème, car il n'est pas encore résolu, mais peut être forcé de le faire si vous l'ignorez.

Je vais supprimer les commentaires qui n'ajoutent pas d'informations utiles afin de raccourcir (légèrement) le fil

Si vous voulez aider à résoudre ce problème

  • Lire l'intégralité du fil, y compris les commentaires masqués ; c'est long, et github masque les commentaires (vous devrez donc cliquer pour les rendre à nouveau visibles). Il y a déjà beaucoup d'informations présentes dans ce fil qui pourraient éventuellement vous aider

screen shot 2018-07-25 at 15 18 14

Pour être clair, le message lui-même est bénin , c'est le crash du noyau après les messages rapportés par l'OP qui ne l'est pas.

Le commentaire dans le code, d'où vient ce message, explique ce qui se passe. Fondamentalement, chaque utilisateur, tel que la pile IP) d'un périphérique réseau (comme la fin d' veth paire ici de temps en temps .

Si un utilisateur de périphérique réseau ne décrémente jamais le nombre de références, une autre partie du noyau déterminera que la tâche en attente de nettoyage est bloquée et qu'elle plantera. C'est seulement ce plantage qui indique un bogue du noyau (certains utilisateurs, via un chemin de code, n'ont pas décrémenté le nombre de références). Il y a eu plusieurs bogues de ce type et ils ont été corrigés dans le noyau moderne (et éventuellement rétroportés sur les anciens). J'ai écrit pas mal de stress tests (et continue de les écrire) pour déclencher de tels plantages mais je n'ai pas pu reproduire sur les noyaux modernes (je fais cependant le message ci-dessus).

* Veuillez ne signaler ce problème que si votre noyau plante réellement *, et nous serions alors très intéressés par :

  • version du noyau (sortie de uname -r )
  • Distribution/version Linux
  • Êtes-vous sur la dernière version du noyau de votre fournisseur Linux ?
  • Configuration du réseau (pont, overlay, IPv4, IPv6, etc.)
  • Description de la charge de travail (quel type de conteneurs, quel type de charge réseau, etc.)
  • Et idéalement une simple reproduction

Merci!

Est-ce que vous utilisez Docker sous certaines limites ? Comme les ulimits, les groupes de contrôle, etc.

le plus récent systemd a une limite par défaut même si vous ne l'avez pas définie. J'ai mis les choses sur illimité et le problème ne s'est plus produit depuis (je regarde depuis 31 jours).

J'ai eu le même problème dans de nombreux environnements et ma solution était d'arrêter le pare-feu. Cela ne s'est pas reproduit, pour l'instant

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

@dElogics Quelle version de systemd est considérée comme "la plus récente" ? Cette limite par défaut est-elle activée dans le système CentOS 7.5 ?

De plus, lorsque vous demandez si nous exécutons docker sous certaines limites, voulez-vous dire le démon docker ou les conteneurs individuels ?

Le démon docker. Le systemd comme dans Debian 9 (232-25).

Je ne suis pas sûr de RHEL, mais j'ai personnellement vu ce problème sur RHEL aussi. Je définirais LimitNOFILE=1048576, LimitNPROC=infinity, LimitCORE=infinity, TasksMax=infinity

kernel : unregister_netdevice : en attente de la libération de eth0. Nombre d'utilisations = 3
noyau 4.4.146-1.el7.elrepo.x86_64
version linux CentOS Linux version 7.4.1708 (Core)
mode pont

J'ai eu le même problème, que puis-je faire ?

Même problème:

CentOS Linux version 7.5.1804 (Core)
Docker version 18.06.1-ce, build e68fc7a
Version du noyau : 3.10.0-693.el7.x86_64

Le problème similaire que j'ai rencontré ici...
Y a-t-il des mouvements que je pourrais effectuer en ce moment ? Sil te plait aide moi...

CentOS 7.0.1406
[ root@zjsm-slavexx etc]# uname -a
Linux zjsm-slave08 3.10.0-123.el7.x86_64 #1 SMP Lun 30 juin 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 (Core)

Informations sur le docker :
[ root@zjsm-slavexx ~]# version du docker
Client:
Version : 17.04.0-ce
Version de l'API : 1.28
Version Go : go1.7.5
Validation Git : 4845c56
Construit: Lun 3 Avr 18:01:50 2017
OS/Arch : linux/amd64

Serveur:
Version : 17.04.0-ce
Version API : 1.28 (version minimale 1.12)
Version Go : go1.7.5
Validation Git : 4845c56
Construit: Lun 3 Avr 18:01:50 2017
OS/Arch : linux/amd64
Expérimental : faux

Noyau CentOS Linux version 7.2.1511 : 3.10.0-327.el7.x86_64
même problème

J'ai expérimenté ce problème.

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 , vous devriez peut-être ajouter votre commentaire en haut du message d'origine, car les gens l'ignorent toujours.

$ 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 

l'a réparé.

@hzbd Vous voulez dire supprimer le réseau de ponts défini par l'utilisateur ? Avez-vous essayé de creuser plus loin pour savoir pourquoi? S'il vous plaît laissez-moi savoir si vous l'avez fait. J'apprécie vraiment ça.

En attente d'être réparé

Est-ce que vous utilisez Docker sous certaines limites ? Comme les ulimits, les groupes de contrôle, etc.

le plus récent systemd a une limite par défaut même si vous ne l'avez pas définie. J'ai mis les choses sur illimité et le problème ne s'est plus produit depuis (je regarde depuis 31 jours).

Ok, ce bogue persiste, mais la probabilité a diminué.

Je pense que si les conteneurs sont gracieusement arrêtés (le PID 1 existe), alors ce bug ne nous dérangera pas.

@dElogics merci de nous l'avoir fait savoir, pourriez-vous s'il vous plaît nous montrer quelles commandes vous avez exécutées pour définir ces limites systemd sur illimité. J'aime essayer ça aussi.

@dElogics merci de nous l'avoir fait savoir, pourriez-vous s'il vous plaît nous montrer quelles commandes vous avez exécutées pour définir ces limites systemd sur illimité. J'aime essayer ça aussi.

Vous devez modifier l'unité systemd de docker. L'unité systemd que j'utilise (uniquement les parties pertinentes) --

[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

Quelqu'un a-t-il eu ce problème dans un noyau 4.15 ou plus récent ?

Ce correctif de Dan Streetman (https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d) est d'abord inclus dans la version du noyau 4.15 et il semble qu'au moins pour quelqu'un, cela ne se produit plus depuis la mise à niveau vers la 4.16 (https:/ /github.com/kubernetes/kubernetes/issues/64743#issuecomment-436839647)

Quelqu'un l'a-t-il essayé ?

@victorgp Nous rencontrons toujours le problème avec le noyau 4.15. Nous rapporterons ici lorsque nous aurons testé avec le noyau 4.16 (espérons-le dans quelques semaines).

Nous avons utilisé la version du noyau

Pour ajouter à mes résolutions précédentes - un arrêt gracieux des conteneurs (qui répondent à SIGTERM) ne déclenche jamais cela.

Essayez également d'exécuter les conteneurs dans l'espace de noms de l'hôte (si cela vous convient), ce qui résout complètement le problème.

@dElogics Qu'entendez-vous par "espace de noms d'hôte" ? Est-ce simplement --privileged ?

@dElogics Qu'entendez-vous par "espace de noms d'hôte" ? Est-ce simplement --privileged ?

Non, cela signifie --network=host

Depuis la mise à niveau du noyau 4.4.0 vers 4.15.0 et du docker 1.11.2 vers 18.09, le problème a disparu.

Dans un parc important de machines virtuelles agissant en tant qu'hôtes Docker, ce problème apparaissait plusieurs fois par jour (avec notre cas d'utilisation Docker).
45 jours et nous ne voyons plus cela.

Pour la postérité, une trace de pile d'un Docker 1.11.2 accroché avec printk affichant unregister_netdevice: waiting for vethXXXXX (similaire à ce que nous voyions toujours dans notre flotte, dans des centaines de VM) peut être trouvée sur http://paste .ubuntu.com/p/6RgkpX352J/ (la référence intéressante du conteneur est 0xc820001980 )

goroutine 8809 [syscall, 542 minutes, locked to thread]:
syscall.Syscall6(0x2c, 0xd, 0xc822f3d200, 0x20, 0x0, 0xc822f3d1d4, 0xc, 0x20, 0xc82435fda0, 0x10)
    /usr/local/go/src/syscall/asm_linux_amd64.s:44 +0x5
syscall.sendto(0xd, 0xc822f3d200, 0x20, 0x20, 0x0, 0xc822f3d1d4, 0xc80000000c, 0x0, 0x0)
    /usr/local/go/src/syscall/zsyscall_linux_amd64.go:1729 +0x8c
syscall.Sendto(0xd, 0xc822f3d200, 0x20, 0x20, 0x0, 0x7faba31bded8, 0xc822f3d1c8, 0x0, 0x0)
    /usr/local/go/src/syscall/syscall_unix.go:258 +0xaf
github.com/vishvananda/netlink/nl.(*NetlinkSocket).Send(0xc822f3d1c0, 0xc82435fda0, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go:333 +0xd4
github.com/vishvananda/netlink/nl.(*NetlinkRequest).Execute(0xc82435fda0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go:215 +0x111
github.com/vishvananda/netlink.LinkDel(0x7fab9c2b15d8, 0xc825ef2240, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/vishvananda/netlink/link_linux.go:615 +0x16b
github.com/docker/libnetwork/drivers/bridge.(*driver).DeleteEndpoint(0xc8204aac30, 0xc8203ae780, 0x40, 0xc826e7b800, 0x40, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go:1060 +0x5cf
github.com/docker/libnetwork.(*endpoint).deleteEndpoint(0xc822945b00, 0xc82001ac00, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/endpoint.go:760 +0x261
github.com/docker/libnetwork.(*endpoint).Delete(0xc822945b00, 0x7fab9c2b0a00, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/endpoint.go:735 +0xbcb
github.com/docker/libnetwork.(*sandbox).delete(0xc8226bc780, 0xc8229f0600, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/sandbox.go:217 +0xd3f
github.com/docker/libnetwork.(*sandbox).Delete(0xc8226bc780, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/sandbox.go:175 +0x32
github.com/docker/docker/daemon.(*Daemon).releaseNetwork(0xc820001980, 0xc820e23a40)
    /usr/src/docker/.gopath/src/github.com/docker/docker/daemon/container_operations.go:732 +0x4f1
github.com/docker/docker/daemon.(*Daemon).Cleanup(0xc820001980, 0xc820e23a40)
    /usr/src/docker/.gopath/src/github.com/docker/docker/daemon/start.go:163 +0x62
github.com/docker/docker/daemon.(*Daemon).StateChanged(0xc820001980, 0xc825f9fac0, 0x40, 0xc824155b50, 0x4, 0x8900000000, 0x0, 0x0, 0x0, 0x0, ...)
    /usr/src/docker/.gopath/src/github.com/docker/docker/daemon/monitor.go:39 +0x60a
github.com/docker/docker/libcontainerd.(*container).handleEvent.func2()
    /usr/src/docker/.gopath/src/github.com/docker/docker/libcontainerd/container_linux.go:177 +0xa5
github.com/docker/docker/libcontainerd.(*queue).append.func1(0xc820073c01, 0xc820f9a2a0, 0xc821f3de20, 0xc822ddf9e0)
    /usr/src/docker/.gopath/src/github.com/docker/docker/libcontainerd/queue_linux.go:26 +0x47
created by github.com/docker/docker/libcontainerd.(*queue).append
    /usr/src/docker/.gopath/src/github.com/docker/docker/libcontainerd/queue_linux.go:28 +0x1da

De là, nous pouvons observer qu'il s'est accroché dans https://github.com/moby/moby/blob/v1.11.2/daemon/container_operations.go#L732

qui nous dirige vers https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/sandbox.go#L175

Et
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/endpoint.go#L760

Qui va dans le pilote de pont libnetwork (vérifiez la description géniale)
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go#L1057 -L1061

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

Et finalement dans ce socket netlink, appelle https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go#L333

Nous pensons que le bogue se produit en général lors de l'arrêt d'un conteneur et que les SKB étant toujours référencés dans les réseaux, le veth n'est pas publié, alors Docker envoie un Kill à ce conteneur après 15 secondes. Le démon Docker ne gère pas cette situation avec élégance, mais en fin de compte, le bogue est dans le noyau. Nous pensons que https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d (accepté en 4.15 en amont) et les commits qui lui sont liés (il y en a plusieurs) agissent comme une atténuation.

En général, cette partie du noyau n'est pas un endroit joli.

Pour ce que ça vaut... nous avons mis à niveau le noyau Linux RHEL de 3.10.0 à 4.17.11. (En cours d'exécution du cluster Kubernetes). Avant la mise à niveau, ce bogue se produisait quotidiennement plusieurs fois sur différents serveurs. Fonctionne avec la mise à niveau depuis trois semaines maintenant. Le bug n'est survenu qu'une seule fois. Donc grosso modo est réduit de 99%.

@marckamerbeek Vous avez mis à jour le noyau RHEL vers un noyau communautaire ? Ensuite, il n'est plus pris en charge.

L' utilisateur de

centos 7.2 a toujours ce problème : kernel:unregister_netdevice : en attente que lo devienne libre. Nombre d'utilisations = 1

@Beatlor RHEL ne nous a pas du tout aidés. Un environnement de production stable est plus important qu'un contrat de support sans valeur. Nous courons toujours très stable maintenant sur 4.17.11. Plus de gros problèmes.

@Beatlor RHEL ne nous a pas du tout aidés. Un environnement de production stable est plus important qu'un contrat de support sans valeur. Nous courons toujours très stable maintenant sur 4.17.11. Plus de gros problèmes.

Oui, je n'ai pas non plus eu ce problème après la mise à niveau du noyau vers 4.17.0-1.el7.elrepo.x86_64. J'ai déjà essayé (4.4.x, 4.8, 4.14) et cela a échoué. Il semble que le problème ne se reproduira plus dans le noyau 4.17+.

centos 7.2 a toujours ce problème : kernel:unregister_netdevice : en attente que lo devienne libre. Nombre d'utilisations = 1

Vous pouvez essayer de mettre à niveau vers le dernier noyau 4.19+.

Attendez quelques mois et quelqu'un viendra aussi se plaindre du noyau 4.19. Juste l'histoire qui se répète.

Salut tout le monde, bonne nouvelle !

Depuis mon dernier commentaire ici (au moment de la rédaction, il y a 17 jours), je n'ai plus ces erreurs. Mes serveurs (environ 30) exécutaient Ubuntu 14.04 avec des packages obsolètes.

Après une mise à niveau complète du système, y compris docker-engine (de 1.7.1 à 1.8.3) + mise à niveau du noyau vers la dernière version possible sur le référentiel d'ubuntu, mes serveurs fonctionnent sans aucun incident.

??

quelle version du noyau mettez-vous à niveau ?

Voici une tentative de résumer ce problème, à partir des commentaires de ce problème, https://github.com/kubernetes/kubernetes/issues/70427 , https://github.com/kubernetes/kubernetes/issues/64743 , et https : //access.redhat.com/solutions/3659011

Versions du noyau observées avec ce problème

Les versions du noyau prétendaient ne pas avoir déclenché ce problème

commits du noyau associés

Je défie https://github.com/kubernetes/kubernetes/issues/70427#issuecomment -470681000 car nous n'avons pas vu cela avec des milliers de machines virtuelles dans 4.15.0 alors que nous le voyions des dizaines de fois par jour sur 4.4. 0, y a-t-il d'autres rapports à ce sujet dans 4.15.0 ?

Je vois ce problème avec l'une de mes machines exécutant Docker sur Debian 9 Stretch ( 4.9.0-8-amd64 ). Je rencontre ce problème avec un tunnel créé dans le conteneur Docker via Docker Gen et il génère une panique du noyau :

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

Voici nos informations Docker :

Client:
 Version:           18.09.3
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        774a1f4
 Built:             Thu Feb 28 06:34:04 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.3
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.8
  Git commit:       774a1f4
  Built:            Thu Feb 28 05:59:55 2019
  OS/Arch:          linux/amd64
  Experimental:     false

Est-ce que quelqu'un sait s'il existe une solution temporaire à ce problème sans redémarrer l'ensemble de la machine ? Nous préférerions vraiment ne pas avoir à redémarrer toute la machine lorsque nous rencontrons ce problème.

Quelque peu hors sujet, nous ne pouvons pas non plus supprimer les messages de panique du noyau dans le terminal. J'ai essayé dmesg -D et dmesg -n 1 . Cependant, pas de chance. Existe-t-il un moyen de supprimer ce type de messages de panique du noyau depuis le terminal ? C'est ennuyeux d'essayer de taper des commandes et d'avoir ce message toutes les 10 secondes environ.

Merci.

Ces noyaux vanille sont-ils fortement corrigés par des distributions avec des correctifs rétroportés ?

@pmoust Je vois cela sur Ubuntu 4.15.0-32 une fois par semaine environ. certainement beaucoup mieux depuis 4.4.0

@iavael, je vais essayer de répertorier les informations de distribution dans le résumé si la référence le fournit.

Quelqu'un a-t-il vu ce bug avec 4.19 ?

Quelqu'un a-t-il vu ce bug avec 4.19 ?

https://github.com/kubernetes/kubernetes/issues/64743#issuecomment -451351435
https://github.com/kubernetes/kubernetes/issues/64743#issuecomment -461772385

Ces informations peuvent vous être utiles.

@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 Veuillez regarder ceci 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 Veuillez regarder ceci https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs-while-testing-tidb-operator-in-k8s/

J'ai suivi la documentation, mais j'obtiens toujours une erreur.

[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

Ce message lui-même n'est pas le bogue ; c'est le noyau qui plante après coup ; 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 Veuillez regarder ceci https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs-while-testing-tidb-operator-in-k8s/

J'ai suivi la documentation, mais j'obtiens toujours une erreur.

[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

Après le redémarrage, ok···

@vincent927 BTW,Vous devez mettre livepatch_route.ko dans /var/lib/kpatch/$(uname -r), lorsque vous activez kpatch.service, le ko peut être chargé automatiquement après le redémarrage.

Nous l'avons soudainement obtenu dans notre entreprise aujourd'hui dans plusieurs clusters kubernetes.

  • uname -a :
    Linux ip-10-47-17-58 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux
  • docker version :

    Client:
     Version:           18.09.5
     API version:       1.39
     Go version:        go1.10.8
     Git commit:        e8ff056dbc
     Built:             Thu Apr 11 04:44:28 2019
     OS/Arch:           linux/amd64
     Experimental:      false
    
    Server: Docker Engine - Community
     Engine:
      Version:          18.09.2
      API version:      1.39 (minimum version 1.12)
      Go version:       go1.10.6
      Git commit:       6247962
      Built:            Sun Feb 10 03:42:13 2019
      OS/Arch:          linux/amd64
      Experimental:     false
    
  • kubectl version (serveur) :
    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"}

Nous ne connaissons pas encore la cause ; nous utilisons ces versions du logiciel ci-dessus depuis plusieurs mois sans aucun problème. Je commente juste pour ajouter à la liste des "versions de logiciels qui rencontrent ce bogue" pour le moment.

@ethercflow J'ai lu cela, mais depuis que nous utilisons Debian dans mon entreprise, il n'est pas simple pour nous d'implémenter le correctif dans ce message.

@ethercflow @2rs2ts nous

@commixon notre expérience est toujours la même que celle rapportée dans https://github.com/moby/moby/issues/5618#issuecomment -455800975, sur une flotte de milliers de machines virtuelles aucune réapparition du problème avec 4.15.0 sur versions de noyaux génériques, optimisées pour AWS et GCP fournies par Canonical. Un test limité sur vanilla 4.15.0 n'a montré aucun de ces problèmes non plus, mais n'a pas été testé à grande échelle.

Merci beaucoup @pmoust . Je vais les essayer. Dans tous les cas, j'essaierai également de patcher kpatch pour qu'il fonctionne avec Debian (en tant que projet parallèle) et publierai des mises à jour ici pour toute personne intéressée.

@ethercflow @2rs2ts nous

Vous pouvez passer à 4.19. C'est dans les backports.

BTW cela fait un an pour nous ici. ;)

Nous avons en fait essayé le 4.19 dans les backports, mais il y avait des régressions majeures dans d'autres domaines (les instances EC2 redémarreraient simplement au hasard, puis la mise en réseau serait interrompue au démarrage.) Je suppose que nous devrons gérer cela jusqu'à la prochaine écurie.

@2rs2ts Au cours des 4 derniers jours, nous utilisons 4.19 à partir des rétroportages (dans EC2) et nous n'avons rencontré aucun problème. Le problème de plantage du noyau n'est pas apparu du tout et tout le reste semble bien aussi. Je ne pense pas que cela fasse une différence, mais nous avons basé notre image Debian sur celle fournie par kops (https://github.com/kubernetes/kops/blob/master/docs/images.md#debian). Nous avons mis à jour le noyau dans cette image et non le stock Debian.

Mes amis, j'utilise le noyau 4.19 pour un fonctionnement stable depuis six mois. J'espère que vous pourrez également profiter de la stabilité.

J'ai un conteneur ouvert 80 et port 443, toutes les 2 semaines, à partir d'un autre conteneur d'accès informatique 80 et
443 est nier

La version du noyau centos7.3 est :
Navigateur Linux1 3.10.0-514.el7.x86_64 #1 SMP Mar 22 novembre 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

root@browser1 ~]# version du docker
Client:
Version : 18.06.3-ce
Version API : 1.38
Version Go : go1.10.4
Validation Git : d7080c1
Construit: mer févr. 20 02:24:22 2019
OS/Arch : linux/amd64
Expérimental : faux

Serveur:
Moteur:
Version : 18.06.3-ce
Version API : 1.38 (version minimale 1.12)
Version Go : go1.10.3
Validation Git : d7080c1
Construit: mer févr. 20 02:25:33 2019
OS/Arch : linux/amd64
Expérimental : faux
[ root@browser1 ~]#

dmesg :

[1063959.636785] unregister_netdevice : en attente de la libération de lo. Nombre d'utilisations = 1
[1071340.887512] br-af29e1edc1b8 : le port 5 (vethc2ac4f8) est entré dans l'état désactivé
[1071340.891753] br-af29e1edc1b8 : le port 5 (vethc2ac4f8) est entré dans l'état désactivé
[1071340.895118] l'appareil vethc2ac4f8 a quitté le mode promiscuité
[1071340.895138] br-af29e1edc1b8 : le port 5 (vethc2ac4f8) est entré dans l'état désactivé
[1071340.990505] le périphérique veth5e4f161 est entré en mode promiscuité
[1071340.990897] IPv6 : ADDRCONF(NETDEV_UP) : veth5e4f161 : le lien n'est pas prêt
[1071340.990904] br-af29e1edc1b8 : le port 5 (veth5e4f161) est entré dans l'état de transfert
[1071340.990924] br-af29e1edc1b8 : le port 5 (veth5e4f161) est entré dans l'état de transfert
[1071341.231405] IPv6 : ADDRCONF(NETDEV_CHANGE) : veth5e4f161 : le lien devient prêt
[1071355.991701] br-af29e1edc1b8 : le port 5 (veth5e4f161) est entré dans l'état de transfert
[1071551.533907] br-af29e1edc1b8 : le port 5 (veth5e4f161) est entré dans l'état désactivé
[1071551.537564] br-af29e1edc1b8 : le port 5 (veth5e4f161) est entré dans l'état désactivé
[1071551.540295] le périphérique veth5e4f161 a quitté le mode promiscuité
[1071551.540313] br-af29e1edc1b8 : le port 5 (veth5e4f161) est entré dans l'état désactivé
[1071551.570924] le périphérique veth8fd3a0a est entré en mode promiscuité
[1071551.571550] IPv6 : ADDRCONF(NETDEV_UP) : veth8fd3a0a : le lien n'est pas prêt
[1071551.571556] br-af29e1edc1b8 : le port 5 (veth8fd3a0a) est entré dans l'état de transfert
[1071551.571582] br-af29e1edc1b8 : le port 5 (veth8fd3a0a) est entré dans l'état de transfert
[1071551.841656] IPv6 : ADDRCONF(NETDEV_CHANGE) : veth8fd3a0a : le lien devient prêt
[1071566.613998] br-af29e1edc1b8 : le port 5 (veth8fd3a0a) est entré dans l'état de transfert
[1071923.465082] br-af29e1edc1b8 : le port 5 (veth8fd3a0a) est entré dans l'état désactivé
[1071923.470215] br-af29e1edc1b8 : le port 5 (veth8fd3a0a) est entré dans l'état désactivé
[1071923.472888] le périphérique veth8fd3a0a a quitté le mode promiscuité
[1071923.472904] br-af29e1edc1b8 : le port 5 (veth8fd3a0a) est entré dans l'état désactivé
[1071923.505580] le périphérique veth9e693ae est entré en mode promiscuité
[1071923.505919] IPv6 : ADDRCONF(NETDEV_UP) : veth9e693ae : le lien n'est pas prêt
[1071923.505925] br-af29e1edc1b8 : le port 5 (veth9e693ae) est entré dans l'état de transfert
[1071923.505944] br-af29e1edc1b8 : le port 5 (veth9e693ae) est entré dans l'état de transfert
[1071923.781658] IPv6 : ADDRCONF(NETDEV_CHANGE) : veth9e693ae : le lien devient prêt
[1071938.515044] br-af29e1edc1b8 : le port 5 (veth9e693ae) est entré dans l'état de transfert

Quelqu'un a-t-il vu ce bug avec 4.19 ?

Oui. J'ai le problème sur le noyau 4.19.4-1.e17.elrep.x86_64

Bonjour,

Je vois aussi cette erreur. Avons-nous une solution à ce problème ? Noyau 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

Ce problème persiste :( pas de mise à jour/d'idées sur la façon de le résoudre ?

Se passe sur Debian Stretch. J'essayais de mettre à jour mon conteneur Jenkins via Ansible lorsque cela s'est produit.

Ce problème a été résolu par ce commit :
https://github.com/torvalds/linux/commit/ee60ad219f5c7c4fb2f047f88037770063ef785f
Utilisation de kpatch

curl -SOL https://raw.githubusercontent.com/Aleishus/kdt/master/kpatchs/route.patch
kpatch-build -t vmlinux route.patch 
mkdir -p /var/lib/kpatch/${UNAME} 
cp -a livepatch-route.ko /var/lib/kpatch/${UNAME}
systemctl restart kpatch
kpatch list

Ce problème a été résolu par ce commit :
torvalds/ linux@ee60ad2
Utilisation de kpatch

curl -SOL https://raw.githubusercontent.com/Aleishus/kdt/master/kpatchs/route.patch
kpatch-build -t vmlinux route.patch 
mkdir -p /var/lib/kpatch/${UNAME} 
cp -a livepatch-route.ko /var/lib/kpatch/${UNAME}
systemctl restart kpatch
kpatch list

Cela doit être à partir de 4.19.30.

Je ne suis pas sûr que torvalds/ linux@ee60ad2 soit le correctif définitif - nous l'avons vu dans 4.4.0 AFAR, alors que https://github.com/torvalds/linux/commit/deed49df7390d5239024199e249190328f1651e7 n'a été ajouté qu'en 4.5.0

Nous avons reproduit le même bogue en utilisant un noyau de diagnostic qui avait des retards insérés artificiellement pour que les routes d'exception de découverte PMTU atteignent cette fenêtre.

  1. Correctif de débogage du noyau :
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index a0163c5..6b9e7ee 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -133,6 +133,8 @@

 static int ip_min_valid_pmtu __read_mostly = IPV4_MIN_MTU;

+static int ref_leak_test;
+
/*
  * Interface to generic destination cache.
  */
@@ -1599,6 +1601,9 @@ static void ip_del_fnhe(struct fib_nh *nh, __be32 daddr)
    fnhe = rcu_dereference_protected(*fnhe_p, lockdep_is_held(&fnhe_lock));
    while (fnhe) {
        if (fnhe->fnhe_daddr == daddr) {
+           if (ref_leak_test)
+               pr_info("XXX pid: %d, %s: fib_nh:%p, fnhe:%p, daddr:%x\n",
+                   current->pid,  __func__, nh, fnhe, daddr);
            rcu_assign_pointer(*fnhe_p, rcu_dereference_protected(
                fnhe->fnhe_next, lockdep_is_held(&fnhe_lock)));
            fnhe_flush_routes(fnhe);
@@ -2145,10 +2150,14 @@ static struct rtable *__mkroute_output(const struct fib_result *res,

        fnhe = find_exception(nh, fl4->daddr);
        if (fnhe) {
+           if (ref_leak_test)
+               pr_info("XXX pid: %d, found fnhe :%p\n", current->pid, fnhe);
            prth = &fnhe->fnhe_rth_output;
            rth = rcu_dereference(*prth);
            if (rth && rth->dst.expires &&
`               time_after(jiffies, rth->dst.expires)) {
+               if (ref_leak_test)
+                   pr_info("eXX pid: %d, del fnhe :%p\n", current->pid, fnhe);
                ip_del_fnhe(nh, fl4->daddr);
                fnhe = NULL;
            } else {
@@ -2204,6 +2213,14 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
 #endif
    }

+   if (fnhe && ref_leak_test) {
+       unsigned long  time_out;
+
+       time_out = jiffies + ref_leak_test;
+       while (time_before(jiffies, time_out))
+           cpu_relax();
+       pr_info("XXX pid: %d, reuse fnhe :%p\n", current->pid, fnhe);
+   }
    rt_set_nexthop(rth, fl4->daddr, res, fnhe, fi, type, 0);
    if (lwtunnel_output_redirect(rth->dst.lwtstate))
        rth->dst.output = lwtunnel_output;
@@ -2733,6 +2750,13 @@ static int ipv4_sysctl_rtcache_flush(struct ctl_table *__ctl, int write,
        .proc_handler   = proc_dointvec,
    },
    {
+       .procname   = "ref_leak_test",
+       .data       = &ref_leak_test,
+       .maxlen     = sizeof(int),
+       .mode       = 0644,
+       .proc_handler   = proc_dointvec,
+   },
+   {
        .procname   = "max_size",
        .data       = &ip_rt_max_size,
        .maxlen     = sizeof(int),
  1. Script du mode utilisateur:

ref_leak_test_begin.sh :

#!/bin/bash

# constructing a basic network with netns
# client <-->gateway <--> server
ip netns add svr
ip netns add gw
ip netns add cli

ip netns exec gw sysctl net.ipv4.ip_forward=1

ip link add svr-veth type veth peer name svrgw-veth
ip link add cli-veth type veth peer name cligw-veth

ip link set svr-veth netns svr
ip link set svrgw-veth netns gw
ip link set cligw-veth netns gw
ip link set cli-veth netns cli

ip netns exec svr ifconfig svr-veth 192.168.123.1
ip netns exec gw ifconfig svrgw-veth 192.168.123.254
ip netns exec gw ifconfig cligw-veth 10.0.123.254
ip netns exec cli ifconfig cli-veth 10.0.123.1

ip netns exec cli route add default gw 10.0.123.254
ip netns exec svr route add default gw 192.168.123.254

# constructing concurrently accessed scenes with nerperf
nohup ip netns exec svr  netserver -L 192.168.123.1

nohup ip netns exec cli  netperf -H 192.168.123.1 -l 300 &
nohup ip netns exec cli  netperf -H 192.168.123.1 -l 300 &
nohup ip netns exec cli  netperf -H 192.168.123.1 -l 300 &
nohup ip netns exec cli  netperf -H 192.168.123.1 -l 300 &

# Add delay
echo 3000 > /proc/sys/net/ipv4/route/ref_leak_test

# making PMTU discovery exception routes
echo 1 >  /proc/sys/net/ipv4/route/mtu_expires
for((i=1;i<=60;i++));
do
  for j in 1400  1300 1100 1000
  do
    echo "set mtu to "$j;
    ip netns exec svr ifconfig  svr-veth  mtu $j;
    ip netns exec cli ifconfig  cli-veth  mtu $j;
    ip netns exec gw ifconfig svrgw-veth  mtu $j;
    ip netns exec gw ifconfig cligw-veth  mtu $j;
    sleep 2;
  done
done

ref_leak_test_end.sh :

#!/bin/bash

echo 0 > /proc/sys/net/ipv4/route/ref_leak_test

pkill netserver
pkill netperf

ip netns exec cli ifconfig cli-veth down
ip netns exec gw ifconfig svrgw-veth down
ip netns exec gw ifconfig cligw-veth down
ip netns exec svr ifconfig svr-veth down

ip netns del svr
ip netns del gw
ip netns del cli

Le processus de test:

  • chargez d'abord le noyau de débogage,
  • puis exécutez ref_leak_test_begin.sh ,
  • attendez quelques secondes, lancez ref_leak_test_end.sh ,
  • et enfin vous pouvez observer l'erreur.
[root<strong i="13">@iZuf6h1kfgutxc3el68z2lZ</strong> test]# bash ref_leak_test_begin.sh
net.ipv4.ip_forward = 1
nohup: ignoring input and appending output to ‘nohup.out’
nohup: set mtu to 1400
appending output to ‘nohup.out’
nohup: appending output to ‘nohup.out’
nohup: appending output to ‘nohup.out’
nohup: appending output to ‘nohup.out’
set mtu to 1300
set mtu to 1100
set mtu to 1000
set mtu to 1400
set mtu to 1300
set mtu to 1100
^C
[root<strong i="14">@iZuf6h1kfgutxc3el68z2lZ</strong> test]# bash ref_leak_test_end.sh
[root<strong i="15">@iZuf6h1kfgutxc3el68z2lZ</strong> test]#
Message from syslogd<strong i="16">@iZuf6h1kfgutxc3el68z2lZ</strong> at Nov  4 20:29:43 ...
 kernel:unregister_netdevice: waiting for cli-veth to become free. Usage count = 1

Après quelques tests, torvalds/ linux@ee60ad2 peut en effet corriger ce bug.

Quelqu'un a-t-il vu ce bug avec 4.19 ?

même

Oui, sur Debian ! Y a-t-il un moyen de le supprimer ?

J'ai découvert que mes journaux Docker étaient également spammés. Noyau 5.4.0, Docker 19.03.8 :

Mar 21 18:46:14 host.mysite.com dockerd[16544]: time="2020-03-21T18:46:14.127275161Z" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Mar 21 18:45:13 host.mysite.com dockerd[16544]: time="2020-03-21T18:45:13.642050333Z" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Mar 21 18:44:13 host.mysite.com dockerd[16544]: time="2020-03-21T18:44:13.161364216Z" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Mar 21 18:43:12 host.mysite.com dockerd[16544]: time="2020-03-21T18:43:12.714725302Z" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"

J'ai finalement découvert comment supprimer ces messages d'ailleurs. À partir de cette question sur StackExchange , j'ai commenté cette ligne dans /etc/rsyslog.conf :

# Everybody gets emergency messages
#*.emerg                    :omusrmsg:*

Option très nucléaire, mais au moins maintenant mon système est à nouveau utilisable !

@steelcowboy Vous pouvez configurer rsyslog pour

J'ai écrit ce qui suit dans /etc/rsyslog.d/40-unreigster-netdevice.conf et redémarré rsyslog systemctl restart rsyslog .

# match frequent not relevant emergency messages generated by Docker when transfering large amounts of data through the network
:msg,contains,"unregister_netdevice: waiting for lo to become free. Usage count = 1" /dev/null

# discard matching messages
& stop

Des nouvelles ici ?

Cette page vous a été utile?
0 / 5 - 0 notes