أرى مشكلة مشابهة جدًا لـ eth0. Ubuntu 12.04 أيضًا.

لا بد لي من تشغيل دورة الجهاز. من /var/log/kern.log :

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

مرحبًا ، هذا بدأ يحدث لي أيضًا.

إصدار عامل ميناء:

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

سجل النواة : http://pastebin.com/TubCy1tG

تفاصيل النظام :
تشغيل Ubuntu 14.04 LTS مع نواة مصححة (3.14.3-rt4). ومع ذلك ، نرى ذلك يحدث مع النواة الافتراضية linux-3.13.0-27-generic. المضحك ، مع ذلك ، أنه عندما يحدث هذا ، تتجمد جميع النوافذ الطرفية ، مما يسمح لي بكتابة بعض الأحرف على الأكثر قبل ذلك. نفس المصير يصيب أي أجهزة جديدة أفتحها أيضًا - وينتهي بي الأمر بالحاجة إلى تشغيل جهاز الكمبيوتر المحمول الفقير بالطاقة تمامًا مثل الطبيب الجيد أعلاه. للتسجيل ، أنا أقوم بتشغيل قشرة السمك في urxvt أو xterm في xmonad. لم يتم التحقق مما إذا كان يؤثر على bash عادي.

قد يكون هذا مناسبًا:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065434#yui_3_10_3_1_1401948176063_2050

نسخ قدر كبير نسبيًا من البيانات عبر الشبكة داخل حاوية
ثم الخروج من الحاوية يمكن أن يؤدي إلى إنقاص مفقود في per
حساب مرجع وحدة المعالجة المركزية على جهاز الشبكة.

من المؤكد أن إحدى المرات التي حدث فيها هذا بالنسبة لي كانت مباشرة بعد apt-get ting حزمة بها الكثير من التبعيات.

أدت الترقية من Ubuntu 12.04.3 إلى 14.04 إلى إصلاح هذا الأمر بالنسبة لي دون أي تغييرات أخرى.

أختبر هذا على RHEL7 ، 3.10.0-123.4.2.el7.x86_64

لقد لاحظت نفس الشيء يحدث مع واجهات شبكة VirtualBox الافتراضية الخاصة بي عندما أقوم بتشغيل 3.14-rt4. من المفترض أن تكون مثبتة في الفانيليا 3.13 أو شيء من هذا القبيل.

egasimus كذلك هنا - لقد سحبت مئات

قمت بالترقية إلى Debian kernel 3.14 ويبدو أن المشكلة قد اختفت. يبدو أن المشكلة كانت موجودة في بعض النوى <3.5 ، وتم إصلاحها في 3.5 ، وتراجعت في 3.6 ، وتم تصحيحها في شيء 3.12-3.14. https://bugzilla.redhat.com/show_bug.cgi؟id=880394

spiffytech هل لديك أي فكرة أين يمكنني الإبلاغ عن هذا فيما يتعلق بنكهة النواة الحقيقية؟ أعتقد أنهم يطلقون تصحيح RT فقط لكل إصدار آخر ، وسوف يكرهون حقًا رؤية 3.16-rt يخرجون مع هذا لا يزال معطلاً. : /

تحرير: تم حفظه في

أحصل على هذا على Ubuntu 14.10 بتشغيل 3.18.1. يظهر سجل Kernel

Dec 21 22:49:31 inotmac kernel: [15225.866600] unregister_netdevice: waiting for lo to become free. Usage count = 2
Dec 21 22:49:40 inotmac kernel: [15235.179263] INFO: task docker:19599 blocked for more than 120 seconds.
Dec 21 22:49:40 inotmac kernel: [15235.179268]       Tainted: G           OE  3.18.1-031801-generic #201412170637
Dec 21 22:49:40 inotmac kernel: [15235.179269] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 21 22:49:40 inotmac kernel: [15235.179271] docker          D 0000000000000001     0 19599      1 0x00000000
Dec 21 22:49:40 inotmac kernel: [15235.179275]  ffff8802082abcc0 0000000000000086 ffff880235c3b700 00000000ffffffff
Dec 21 22:49:40 inotmac kernel: [15235.179277]  ffff8802082abfd8 0000000000013640 ffff8800288f2300 0000000000013640
Dec 21 22:49:40 inotmac kernel: [15235.179280]  ffff880232cf0000 ffff8801a467c600 ffffffff81f9d4b8 ffffffff81cd9c60
Dec 21 22:49:40 inotmac kernel: [15235.179282] Call Trace:
Dec 21 22:49:40 inotmac kernel: [15235.179289]  [<ffffffff817af549>] schedule+0x29/0x70
Dec 21 22:49:40 inotmac kernel: [15235.179292]  [<ffffffff817af88e>] schedule_preempt_disabled+0xe/0x10
Dec 21 22:49:40 inotmac kernel: [15235.179296]  [<ffffffff817b1545>] __mutex_lock_slowpath+0x95/0x100
Dec 21 22:49:40 inotmac kernel: [15235.179299]  [<ffffffff8168d5c9>] ? copy_net_ns+0x69/0x150
Dec 21 22:49:40 inotmac kernel: [15235.179302]  [<ffffffff817b15d3>] mutex_lock+0x23/0x37
Dec 21 22:49:40 inotmac kernel: [15235.179305]  [<ffffffff8168d5f8>] copy_net_ns+0x98/0x150
Dec 21 22:49:40 inotmac kernel: [15235.179308]  [<ffffffff810941f1>] create_new_namespaces+0x101/0x1b0
Dec 21 22:49:40 inotmac kernel: [15235.179311]  [<ffffffff8109432b>] copy_namespaces+0x8b/0xa0
Dec 21 22:49:40 inotmac kernel: [15235.179315]  [<ffffffff81073458>] copy_process.part.28+0x828/0xed0
Dec 21 22:49:40 inotmac kernel: [15235.179318]  [<ffffffff811f157f>] ? get_empty_filp+0xcf/0x1c0
Dec 21 22:49:40 inotmac kernel: [15235.179320]  [<ffffffff81073b80>] copy_process+0x80/0x90
Dec 21 22:49:40 inotmac kernel: [15235.179323]  [<ffffffff81073ca2>] do_fork+0x62/0x280
Dec 21 22:49:40 inotmac kernel: [15235.179326]  [<ffffffff8120cfc0>] ? get_unused_fd_flags+0x30/0x40
Dec 21 22:49:40 inotmac kernel: [15235.179329]  [<ffffffff8120d028>] ? __fd_install+0x58/0x70
Dec 21 22:49:40 inotmac kernel: [15235.179331]  [<ffffffff81073f46>] SyS_clone+0x16/0x20
Dec 21 22:49:40 inotmac kernel: [15235.179334]  [<ffffffff817b3ab9>] stub_clone+0x69/0x90
Dec 21 22:49:40 inotmac kernel: [15235.179336]  [<ffffffff817b376d>] ? system_call_fastpath+0x16/0x1b
Dec 21 22:49:41 inotmac kernel: [15235.950976] unregister_netdevice: waiting for lo to become free. Usage count = 2
Dec 21 22:49:51 inotmac kernel: [15246.059346] unregister_netdevice: waiting for lo to become free. Usage count = 2

سأرسل docker version/info بمجرد عدم تجميد النظام :)

نحن نرى هذه المشكلة أيضًا. Ubuntu 14.04 ، 3.13.0-37-عام

على خادم Ubuntu 14.04 ، وجد فريقي أن تخفيض الإصدار من 3.13.0-40-generic إلى 3.13.0-32-generic "يحل" المشكلة. بالنظر إلى ملاحظةsbward ، فإن ذلك من شأنه أن يضع الانحدار بعد 3.13.0-32-عام وقبل (أو بما في ذلك) 3.13.0-37-عام.

سأضيف أنه في حالتنا ، نرى أحيانًا عدد استخدام _ سلبيًا.

FWIW لقد وصلنا إلى هذا الخطأ الذي يعمل lxc على نواة مضمونة (3.13.0-40-generic # 69-Ubuntu) تظهر الرسالة في dmesg متبوعة بتتبع المكدس هذا:

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

ركض في هذا على Ubuntu 14.04 و Debian jessie w / kernel 3.16.x.

أمر Docker:

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

يبدو أن هذه مشكلة سيئة للغاية ...

jbalonso حتى مع 3.13.0-32-generic أحصل على الخطأ بعد بضع مرات تشغيل ناجحة: سوب:

MrMMorris هل يمكنك مشاركة نص

كل شخص يرى هذا الخطأ على نظامه يقوم بتشغيل حزمة من نواة Linux على توزيعه قديمة جدًا ويفتقر إلى الإصلاحات لهذه المشكلة بالذات.

إذا واجهت هذه المشكلة ، فتأكد من تشغيل apt-get update && apt-get dist-upgrade -y وإعادة تشغيل نظامك. إذا كنت تستخدم Digital Ocean ، فستحتاج أيضًا إلى تحديد إصدار kernel الذي تم تثبيته للتو أثناء التحديث لأنهم لا يستخدمون أحدث إصدار من kernel تلقائيًا (راجع https://digitalocean.uservoice.com/forums/136585-digitalocean / اقتراحات / 2814988-give-option-to-use-the-droplet-s-own-bootloader).

يحتاج مستخدمو CentOS / RHEL / Fedora / Scientific Linux إلى تحديث أنظمتهم باستخدام yum update وإعادة التشغيل بعد تثبيت التحديثات.

عند الإبلاغ عن هذه المشكلة ، يرجى التأكد من أن نظامك مُصحح بالكامل ومُحدَّث بأحدث التحديثات الثابتة (لا توجد حزم تجريبية / اختبار / ألفا / بيتا / RC مثبتة يدويًا) مقدمة من بائع التوزيع الخاص بك.

تضمين التغريدة

قمت بتشغيل apt-get update && apt-get dist-upgrade -y

أوبونتو 14.04 3.13.0-46-عام

لا يزال يظهر الخطأ بعد docker run واحد فقط

يمكنني إنشاء AMI للتكاثر إذا لزم الأمر

MrMMorris شكرًا

أي شيء آخر يمكنني القيام به للمساعدة ، اسمحوا لي أن أعرف! :ابتسامة:

MrMMorris إذا كان بإمكانك توفير أداة إعادة إنتاج ، فهناك خطأ تم فتحه لـ Ubuntu وسيكون موضع تقدير كبير: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152

rsampaio إذا كان لدي وقت اليوم ،

تظهر هذه المشكلة أيضًا في الإصدار 3.16 (.7) على كل من Debian 7 و Debian 8: https://github.com/docker/docker/issues/9605#issuecomment -85025729. إعادة تشغيل الخادم هي الطريقة الوحيدة لإصلاح هذا في الوقت الحالي.

رؤية هذه المشكلة على RHEL 6.6 مع kernel 2.6.32-504.8.1.el6.x86_64 عند بدء تشغيل بعض حاويات Docker (وليس كل الحاويات)
_ kernel: unregister_netdevice : انتظار lo لتصبح حرة. عدد الاستخدام = -1_

مرة أخرى ، يبدو أن إعادة تشغيل الخادم هي الحل الوحيد في هذا الوقت

نرى هذا أيضًا على CoreOS (647.0.0) مع kernel 3.19.3.

إعادة التشغيل هي أيضًا الحل الوحيد الذي وجدته.

تم اختبار Debian jessie باستخدام نواة sid (4.0.2) - لا تزال المشكلة قائمة.

أي شخص يرى هذه المشكلة يشغل حاويات غير ubuntu؟

نعم فعلا. منها ديبيان.
19 июня 2015 г. 19:01 пользователь "popsikle" [email protected]
الأصل:

أي شخص يرى هذه المشكلة يشغل حاويات غير ubuntu؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/docker/docker/issues/5618#issuecomment -113556862.

هذه مشكلة kernel وليست مشكلة متعلقة بالصورة. لن يؤدي تبديل صورة إلى صورة أخرى إلى تحسين هذه المشكلة أو تفاقمها.

تواجه مشكلة في Debian Jessie على نواة BeagleBone Black تعمل 4.1.2-bone12

تجربة بعد التبديل من 4.1.2 إلى 4.2-rc2 (باستخدام git build 1.8.0).
حذف / var / lib / docker / * لا يحل المشكلة.
العودة إلى 4.1.2 يحل المشكلة.

أيضًا ، يواجه VirtualBox نفس المشكلة وهناك تصحيح لـ v5.0.0 (تم نقله إلى الإصدار 4) والذي يفترض أنه يقوم بشيء ما في جزء برنامج تشغيل kernel .. يستحق البحث لفهم المشكلة.

هذا هو الإصلاح في VirtualBox: https://www.virtualbox.org/attachment/ticket/12264/diff_unregister_netdev
إنهم لا يقومون بتعديل النواة في الواقع ، فقط وحدة النواة الخاصة بهم.

توجد أيضًا هذه المشكلة مع 4.2-rc2:

unregister_netdevice: انتظار vethf1738d3 ليصبح حراً. عدد الاستخدام = 1

تم تجميع 4.2-RC3 للتو ، ويبدو أنه يعمل مرة أخرى

@ nazar-pc شكرا على المعلومات. مجرد ضرب 4.1.3 ، كان مستاء جدا
techniq نفسه هنا ، خطأ نواة سيء جدًا. أتساءل عما إذا كان يجب علينا الإبلاغ عنه ليتم نقله إلى شجرة 4.1.

Linux docker13 3.19.0-22-generic # 22-Ubuntu SMP الثلاثاء 16 يونيو 17:15:15 بالتوقيت العالمي المنسق 2015 x86_64 x86_64 x86_64 GNU / Linux

Kernel من Ubuntu 15.04 ، نفس المشكلة

رأيت ذلك مع 4.2-rc3 أيضًا. لا يوجد خطأ واحد حول تسرب الجهاز :) يمكنني إعادة الإنتاج على أي نواة> = 4.1 تحت الحمل العالي.

أنا فقط عانيت من هذه المشكلة أيضا. Ubuntu 3.13.0-57-عام ، يتم توفيره عبر tutum. لسوء الحظ ، تملأ kern.log و syslog وتعطل الجهاز. يحدث ذلك على آلة قاعدة البيانات (postgres dockerized) ، لذلك يؤدي إلى انهيار النظام بأكمله ...

انضممت إلى جوقة "أنا أيضًا" ، فأنا أرى هذه المشكلة على Cloudstack VM الذي يقوم بتشغيل RancherOS (نظام تشغيل بسيط) 0.3.3 أثناء سحب صور عامل الإرساء من مستودع عامل ميناء خاص محلي. إنه يحدث كل عشر ثوانٍ ، لست متأكدًا مما إذا كان ذلك يعني شيئًا أم لا.

وجود هذه المشكلة أيضًا مع 4.2-rc7

أي أخبار عن هذا ، أي نواة يجب أن نستخدمها؟ يستمر في الحدوث حتى مع وجود نواة محدثة بالكامل (3.19.0-26 على Ubuntu 14.04)

لدينا هذه المشكلة أيضا. يحدث هذا بعد أن قمنا بتكوين userland-proxy = false. نحن نستخدم بعض البرامج النصية للشاشات التي ستنتج حاوية عامل إرساء جديدة لتنفيذ أمر nagios plugins كل دقيقة واحدة. ما أراه في شجرة العمليات هو أنه عالق في أمر docker rm ورؤية الكثير من الأخطاء في ملف kern.log

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

هذه هي معلومات نظامنا

ubuntu@prod-service-02:~$ docker version
Client:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Thu Sep 10 19:19:00 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Thu Sep 10 19:19:00 UTC 2015
 OS/Arch:      linux/amd64
ubuntu@prod-service-02:~$ docker info
Containers: 2
Images: 52
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: gelf
Kernel Version: 4.0.9-040009-generic
Operating System: Ubuntu 14.04.3 LTS
CPUs: 4
Total Memory: 7.304 GiB
Name: prod-service-02
ID: NOIK:LVBV:HFB4:GZ2Y:Q74F:Q4WW:ZE22:MDE7:7EBW:XS42:ZK4G:XNTB
WARNING: No swap limit support
Labels:
 provider=generic

تحديث: على الرغم من أن https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152 قال إنه تم إصلاحه بالفعل في 2015-08-17. لذلك حاولت استخدام kernel v3.19.8-ckt6-vivid الذي تم إنشاؤه على 02-Sep-2015 أو حتى v4.2.1-unstable الذي تم إنشاؤه في 21-Sep-2015 ولا يزال لديه مشكلة.

لقد واجهت المشكلة مرة أخرى باستخدام 3.19.0-28-generic ، لذا فإن أحدث نواة ubuntu ليست آمنة

نعم ، يبدو أن --userland-proxy=false ليس الخيار الأفضل الآن مع النوى القديمة :(

لا ، لقد حاولت --userland-proxy = خطأ لجميع إصدارات kernel 3.19 و 4.0 و 4.2 وما زالت المشكلة تحدث.

أنا أستخدم وكيل userland بدون iptables (--iptables = false) وأرى هذا مرة واحدة يوميًا كحد أدنى. للأسف ، كان الحل الوحيد هو المراقبة التي تعيد تعيين الخادم باستخدام تقنية SysRq.

تعمل أنظمتي على تشغيل بعض الحاويات التي تحتوي على الكثير من الكتابات المخطئة / المخطئة ، حيث أفاد آخرون أنها قد تؤدي إلى حدوث الخطأ.

"" "
معلومات عامل الإرساء $
الحاويات: 15
الصور: 148
سائق التخزين: aufs
الجذر Dir: / var / lib / docker / aufs
دعم نظام الملفات: extfs
Dirs: 178
Dirperm1 المدعومة: صحيح
سائق التنفيذ: أصلي -0.2
برنامج تشغيل التسجيل: ملف json
إصدار النواة: 3.19.0-26-generic
نظام التشغيل: Ubuntu 14.04.3 LTS
وحدات المعالجة المركزية: 12
إجمالي الذاكرة: 62.89 جيجا بايت
الاسم: * *
المعرّف: 2 ALJ: YTUH : QCNX: FPEO : YBG4: ZTL4: 2 EYK: AV7D : FN7C: IVNU: UWBL : YYZ5

نسخة عامل ميناء دولار
إصدار العميل: 1.7.0
إصدار واجهة برمجة تطبيقات العميل: 1.19.0
إصدار Go (العميل): go1.4.2
Git الالتزام (العميل): 0baf609
OS / Arch (العميل): linux / amd64
إصدار الخادم: 1.7.0
إصدار Server API: 1.19.0
إصدار Go (الخادم): go1.4.2
Git الالتزام (الخادم): 0baf609
OS / Arch (الخادم): linux / amd64 ```
"" "

لسوء الحظ ، أنا في نفس الحالة ، اليوم فشل خادم إنتاج 3 مرات بسبب هذا الخطأ ، والطريقة الوحيدة للتعامل مع ذلك هي استخدام بعض أوامر SysRq السحرية ..

صدم

ما زلت أرى هذا على أحدث نسخة من debian jessie باستخدام kernel 4.2.0

نفس المشكلة هنا. فجأة ، تعطلت ثلاثة من خوادم aws وكانت السجلات تصيح "unregister_netdevice: انتظار lo لتصبح مجانية. عدد الاستخدام = 1"

أوبونتو: 14.04
إصدار النواة: 3.13.0-63 عام
عامل ميناء: 1.7.1

سجل النظام

هل يوجد إصدار نواة آمن للاستخدام؟

تحدث المشكلة أيضًا مع kernel 4.2 من Ubuntu 15.10

حدث في كروس:

الصور: 1174
سائق التخزين: تراكب
دعم نظام الملفات: extfs
سائق التنفيذ: أصلي -0.2
برنامج تشغيل التسجيل: ملف json
إصدار النواة: 4.1.7-coreos
نظام التشغيل: CoreOS 766.4.0

خطأ kernel الذي قال @ killme2008 آخر مرة

ربما يجب عليك تجربة هذا التصحيح المطبق على النواة الخاصة بك http://www.spinics.net/lists/netdev/msg351337.html
الحزمة: حالة السباق في packet_bind

أو انتظر الشجرة الخلفية غير المستقرة ؛ سيأتي عاجلاً أم آجلاً.

: +1: أخبار سارة!

مرحبًا بالجميع ، أخبار جيدة!

منذ تعليقي الأخير هنا (في وقت كتابة هذا التقرير ، قبل 17 يومًا) لم تظهر لي هذه الأخطاء مرة أخرى. كانت خوادمي (حوالي 30 منهم) تعمل بنظام ubuntu 14.04 مع بعض الحزم القديمة.

بعد ترقية النظام بالكامل بما في ذلك docker-engine (من 1.7.1 إلى 1.8.3) + ترقية kernel إلى أحدث إصدار ممكن على repo الخاص بـ ubuntu ، تعمل خوادمي دون أي تكرار.

:8 الكرة:

حدث في 3 من حالات AWS الخاصة بنا اليوم أيضًا:

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

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

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

أواجه نفس المشكلة مع Ubuntu 14.04 ، كل الحزم محدثة وأحدث إصدار من linux-generic-lts-vivid kernel:

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

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

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

حصلت عليه أيضًا بأحدث linux-image-generic (3.13.0-67-generic).

تواجه نفس المشكلات هنا على rancherOS.

لا يزال يحدث في Fedora 22 (محدث) ....
يمكنني التخلص من الرسائل إذا قمت بإعادة تشغيل عامل الإرساء

إعادة تشغيل عامل ميناء systemctl
... تظهر الرسالة مرة أخرى لمدة 3-4 مرات ثم تتوقف

نفس الخطأ قابلني مع Coreos:

نسخة من coreos:

 core @ core-1-94 ~ $ cat / etc / os-release
 NAME = CoreOS
 المعرف = coreos
 الإصدار = 766.5.0
 VERSION_ID = 766.5.0
 BUILD_ID =
 PRETTY_NAME = "CoreOS 766.5.0"
 ANSI_COLOR = "1 ، 32"
 HOME_URL = "https://coreos.com/"
 BUG_REPORT_URL = "https://github.com/coreos/bugs/issues"

إصدار عامل ميناء:

 core @ core-1-94 ~ إصدار عامل ميناء
 إصدار العميل: 1.7.1
 إصدار واجهة برمجة تطبيقات العميل: 1.19.0
 إصدار Go (العميل): go1.4.2
 Git الالتزام (العميل): df2f73d-dirty
 OS / Arch (العميل): linux / amd64
 إصدار الخادم: 1.7.1
 إصدار Server API: 1.19.0
 إصدار Go (الخادم): go1.4.2
 Git الالتزام (الخادم): df2f73d-dirty
 OS / Arch (الخادم): linux / amd64

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

سجل النظام:

 ديسمبر 07 16:26:54 core-1-94 kernel: unregister_netdevice: انتظار veth775ea53 ليصبح مجانيًا. عدد الاستخدام = 1
 ديسمبر 07 16:26:54 core-1-94 kernel: unregister_netdevice: انتظار lo لتصبح مجانية. عدد الاستخدام = 2
 ديسمبر 07 16:26:55 core-194 sdnotify-proxy [1203]: I1207 08: 26: 55.930559 00001 vxlan.go: 340] تجاهل عدم تفويت: 4e: 5c: 47: 2f: 9a: 85، 10.244 .97.10
 ديسمبر 07 16:26:59 core-1-94 dockerd [1269]: time = "2015-12-07T16: 26: 59.448438648 + 08: 00" level = info msg = "GET / version"
 Dec 07 16:27:01 Core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 01.050588 00001 vxlan.go: 340] تجاهل عدم الخطأ: 5a: b1: f7: e9: 7d: d0، 10.244 .34.8
 ديسمبر 07 16:27:02 core-194 dockerd [1269]: time = "2015-12-07T16: 27: 02.398020120 + 08: 00" المستوى = info msg = "GET / version"
 ديسمبر 07 16:27:02 core-194 dockerd [1269]: time = "2015-12-07T16: 27: 02.398316249 + 08: 00" المستوى = info msg = "GET / version"
 ديسمبر 07 16:27:04 core-194 dockerd [1269]: time = "2015-12-07T16: 27: 04.449317389 + 08: 00" المستوى = info msg = "GET / version"
 كانون الأول (ديسمبر) 07 16:27:04 النواة - 1-94 النواة: unregister_netdevice: انتظار veth775ea53 ليصبح مجانيًا. عدد الاستخدام = 1
 ديسمبر 07 16:27:04 النواة-1-94 النواة: unregister_netdevice: انتظار lo لتصبح حرة. عدد الاستخدام = 2
 Dec 07 16:27:06 Core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 06.106573 00001 vxlan.go: 340] تجاهل لا تفوت: a6: 38: ac: 79: 93: f5، 10.244 .47.24
 ديسمبر 07 16:27:09 dockerd core-1-94 [1269]: time = "2015-12-07T16: 27: 09.449944048 + 08: 00" المستوى = info msg = "GET / version"
 ديسمبر 07 16:27:11 core-194 sdnotify-proxy [1203]: I1207 08: 27: 11.162578 00001 vxlan.go: 340] تجاهل عدم تفويت: 0e: f0: 6f: f4: 69: 57، 10.244 .71.24
 ديسمبر 07 16:27:12 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 12.502991197 + 08: 00" level = info msg = "GET / version"
 ديسمبر 07 16:27:12 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 12.503411160 + 08: 00" level = info msg = "GET / version"
 ديسمبر 07 16:27:14 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 14.450646841 + 08: 00" level = info msg = "GET / version"
 ديسمبر 07 16:27:14 core-194 kernel: unregister_netdevice: انتظار veth775ea53 ليصبح حراً. عدد الاستخدام = 1
 ديسمبر 07 16:27:14 core-194 kernel: unregister_netdevice: انتظار lo لتصبح مجانية. عدد الاستخدام = 2
 ديسمبر 07 16:27:16 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 16.282556 00001 vxlan.go: 340] تجاهل لا تفوت: a6: 62: 77: 31: ef: 68، 10.244 .13.6
 ديسمبر 07 16:27:19 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 19.451486277 + 08: 00" level = info msg = "GET / version"
 Dec 07 16:27:21 Core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 21.402559 00001 vxlan.go: 340] تجاهل عدم تفويت: 92: c4: 66: 52: cd: bb، 10.244 .24.7
 ديسمبر 07 16:27:22 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 22.575446889 + 08: 00" المستوى = info msg = "GET / version"
 ديسمبر 07 16:27:22 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 22.575838302 + 08: 00" level = info msg = "GET / version"
 ديسمبر 07 16:27:24 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 24.452320364 + 08: 00" level = info msg = "GET / version"
 ديسمبر 07 16:27:24 core-1-94 kernel: unregister_netdevice: انتظار veth775ea53 ليصبح حراً. عدد الاستخدام = 1
 ديسمبر 07 16:27:24 core-1-94 kernel: unregister_netdevice: انتظار lo لتصبح مجانية. عدد الاستخدام = 2
 Dec 07 16:27:26 Core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 26.394569 00001 vxlan.go: 340] تجاهل لا تفوت: 6a: f7: bf: ec: 03: 50، 10.244 .87.8
 ديسمبر 07 16:27:29 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 29.453171649 + 08: 00" المستوى = info msg = "GET / version"
 ديسمبر 07 16:27:29 core-1-94 systemd [1]: بدء إنشاء / تشغيل / coreos / motd ...
 ديسمبر 07 16:27:29 core-1-94 systemd [1]: تم البدء في إنشاء / تشغيل / coreos / motd.
 ديسمبر 07 16:27:32 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 32.671592437 + 08: 00" level = info msg = "GET / version"
 ديسمبر 07 16:27:32 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 32.671841436 + 08: 00" المستوى = info msg = "GET / version"
 ديسمبر 07 16:27:33 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 33.562534 00001 vxlan.go: 340] تجاهل لا تفوت: 22: b4: 62: d6: 25: b9، 10.244 .68.8
 ديسمبر 07 16:27:34 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 34.453953162 + 08: 00" level = info msg = "GET / version"
 ديسمبر 07 16:27:34 core-1-94 kernel: unregister_netdevice: انتظار veth775ea53 ليصبح حراً. عدد الاستخدام = 1
 ديسمبر 07 16:27:35 core-1-94 kernel: unregister_netdevice: انتظار lo لتصبح مجانية. عدد الاستخدام = 2

عيد ميلاد سعيد ، قضية دموية =)
6 مايو 2014

نفس الشيء هنا. مجرد إعادة التشغيل. أحدث إصدار عامل ميناء. أوبونتو 14.04.2018

samvignoli تم التعرف على هذا على أنه مشكلة في النواة ، لذلك للأسف لا يمكن إصلاحه في عامل الإرساء

thaJeztah هل لديك رابط لتعقب الأخطاء لمشكلة النواة؟
أو ربما المؤشر الذي تتأثر به النواة؟

حريصون على حل هذا في بيئتنا.

Rucknar آسف ، لا أفعل (ربما هناك واحد في هذه المناقشة ، لم أقرأ جميع التعليقات مرة أخرى)

Linux atlas2 3.19.0-33-generic # 38 ~ 14.04.1-Ubuntu SMP الجمعة 6 نوفمبر 18:17:28 بالتوقيت العالمي المنسق 2015 x86_64 x86_64 x86_64 GNU / Linux

Rucknar إذا قمت بالتمرير قليلاً إلى الأعلى - فسترى رابط التصحيح http://www.spinics.net/lists/netdev/msg351337.html. إنه الآن في لينكس ماستر ، أعتقد أنه سينتقل إلى Linux 4.4 ، ربما قام شخص ما بالفعل بنقله إلى الإصدارات السابقة ، لكن ليس متأكدًا.

شكرًا لكم جميعًا ، سنلقي نظرة على ما هو مطلوب في الترقية.

FWIW I backported آخر تصحيح مذكور هنا إلى ubuntu 3.19 وقمت أيضًا باختبار 4.2 kernel ولكن كلاهما غير ناجح. لا تزال المشكلة قائمة حتى في 4.4-rc3 net-next فرع في هذه المرحلة.

rsampaio كيف اختبرت ذلك؟ لا يمكنني تشغيل هذا الخطأ بشكل موثوق باستخدام عامل ميناء ، في الواقع ، على أي نواة. إنه يحدث فقط في بعض الأحيان.

fxposter ، لا يمكننا أيضًا إعادة إنتاج المشكلة خارج الإنتاج ، لذا اضطررت إلى تشغيل بعض الحالات باستخدام النواة المصححة في الإنتاج ، ويحدث ذلك كثيرًا لدرجة أنني أستطيع معرفة ما إذا كانت النواة قد تأثرت خلال 24 ساعة من تحميل الإنتاج.

نقوم أحيانًا بإصلاحه باستخدام مورد غير معتاد جدًا: ننقل أدلة الحاوية بعيدًا عن / var / lib / docker / aufs / mnt

مع ذلك ... ربما يمكننا "إعادة تشغيل عامل ميناء الخدمة" وإعادة الدلائل مرة أخرى.

خلاف ذلك ... إعادة التشغيل فقط.

rsampaio هل تتحدث عن إنتاج heroku الآن؟ كيف تتجنب داو هذه المشكلة ، لأن كل أعمالك مبنية على الحاويات / إلخ؟

rsampaio هل تستخدم --userland-proxy=false أم مجرد كمية كبيرة من الحاويات التي تم إنشاؤها؟ يمكنني إعادة إنتاجه بسهولة إلى حد ما باستخدام --userland-proxy=false ومع بعض التحميل بدون :)

@ LK4D4 أعتقد أنها مجرد كمية كبيرة من الحاويات التي تم إنشاؤها / تدميرها ، خاصة الحاويات التي تقوم بالكثير من حركة المرور الصادرة ، كما نستخدم LXC بدلاً من عامل الإرساء ، لكن الخطأ هو نفسه تمامًا كما هو موضح هنا ، يمكنني محاولة إعادة الإنتاج باستخدام طريقتك إذا كان من السهل وصفها و / أو لا تنطوي على حمل إنتاج ، فإن الفكرة هي الحصول على تعطل و _ ربما_ العثور على مزيد من التلميحات حول سبب هذا الخطأ بالضبط.

يمكنني إعادة إنتاج rsampaio مع الاستخدام المطول لـ https://github.com/crosbymichael/docker-stress

هل كانت هناك أي تحديثات / مقترحات لإصلاح هذا؟

@ joshrendek إنه خطأ في النواة. يبدو أنه حتى إصدار kernel 4.4 الذي تم إصداره حديثًا لا يصلحه ، لذلك هناك حالة سباق أخرى على الأقل في مكان ما :)

علة النواة

=)

samvignoli هل يمكنك الاحتفاظ بتعليقاتك بناءة؟ لا تتردد في فتح علاقات عامة إذا كانت لديك طرق لإصلاح هذه المشكلة.

هل تم الإبلاغ عن هذا الخطأ بالفعل في المنبع (القائمة البريدية لـ kernel)؟

بالتأكيد كان. يشير التعليق الأول إلى هذا الخطأ أيضًا: https://bugzilla.kernel.org/show_bug.cgi؟id=81211

مفتوح منذ عام 2014. لا توجد تعليقات من أي شخص يعمل عليه على الرغم من القول إنه على الأرجح تطبيق يستخدمه بشكل غير صحيح.

شكرا على الرابط جاستن! سوف أقصد لينوس =)

أطيب التحيات. = *: قلب:

samvignoli من فضلك لا تفعل هذا ، لا يساعد أي شخص.
هل يمكن لشخص ما إعادة إنتاج هذا في صورة VM صغيرة؟
ربما يمكنني جعل يدي متسخة باستخدام gdb والكثير من kprintf.

لا يزال الخلل مفتوحًا.

نظام التشغيل: CentOS 7.2
النواة: 4.4.2 elrepo kernel-ml
عامل ميناء: 1.10.2
fs: تراكبات مع xfs

سجل:

Message from syslogd<strong i="11">@host118</strong> at Feb 29 14:52:47 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

[root<strong i="14">@host118</strong> ~]# uname -a
Linux host118 4.4.2-1.el7.elrepo.x86_64 #1 SMP Thu Feb 18 10:20:19 EST 2016 x86_64 x86_64 x86_64 GNU/Linux
[root<strong i="15">@host118</strong> ~]# cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)
[root<strong i="16">@host118</strong> ~]# lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch
Distributor ID: CentOS
Description:    CentOS Linux release 7.2.1511 (Core)
Release:    7.2.1511
Codename:   Core
[root<strong i="17">@host118</strong> ~]# docker info
Containers: 5
 Running: 2
 Paused: 0
 Stopped: 3
Images: 154
Server Version: 1.10.2
Storage Driver: overlay
 Backing Filesystem: xfs
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 4.4.2-1.el7.elrepo.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.858 GiB
Name: host118
ID: 2NW7:Y54E:AHTO:AVDR:S2XZ:BGMC:ZO4I:BCAG:6RKW:KITO:KRM2:DQIZ
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

عرض السجل هذا عند تشغيل صورة sameersbn / docker-gitlab docker:

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

قد أكون محظوظًا - ولكن بعد تطبيق إعدادات النظام هذه ، انخفض حدوث هذا الأمر كثيرًا.

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 600
net.ipv4.tcp_tw_reuse = 1
net.netfilter.nf_conntrack_generic_timeout = 120
net.netfilter.nf_conntrack_max = 1555600000
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 300
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300

joshrendek ما هو الدافع وراء هذه الإعدادات؟

kmike كان هذا لإصلاح بعض مشكلات conntrack الأخرى (تمتلئ جداول IP) التي كنا نواجهها - يبدو أنه قد فعل شيئًا ما فيما يتعلق بمشكلتي الأصلية على الرغم من أنها أثر جانبي

هل يمكنك إظهار ما قبل / بعد حتى نتمكن من رؤية ما تغير بالفعل؟ هل أنت على استعداد للبحث الثنائي في هذه الإعدادات ومعرفة ما إذا كانت هناك مجموعة أصغر؟

أنا أستخدم CoreOS Stable (899.13.0) في Compute Engine VM. يحدث هذا الخطأ في كل مرة أقوم فيها بتشغيل الخادم بالعلامة التالية إلى 0 (الافتراضي). لقد اختبرت عدة مرات ذهابًا وإيابًا ومع تعطيل IPv6 ، يمكنني بدء تشغيل جميع الحاويات في العقدة دون أي خطأ:

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

أستخدم حاوية gcloud للتنزيل من GCR ، لذلك ربما تكون المشكلة هي IPv6 + تنزيل ميغابايت من الصور + إغلاق الحاويات بسرعة.

نسخة Docker للرجوع اليها:

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

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

لقد اختبرت أيضًا إشارات sysctl السابقة في هذه المشكلة ؛ لكن البعض لديه هذه القيمة بالفعل والباقي لا يبدو أنه يغير أي شيء متعلق بهذا الخطأ:

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 600
  -----> not found in CoreOS
net.ipv4.tcp_tw_reuse = 1
  -----> default: 0
net.netfilter.nf_conntrack_generic_timeout = 120
  -----> default: 600
net.netfilter.nf_conntrack_max = 1555600000
  -----> default: 65536
net.netfilter.nf_conntrack_tcp_timeout_close = 10
  -> already: 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
  -> already: 60
net.netfilter.nf_conntrack_tcp_timeout_established = 300
  -----> default: 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
  -> already: 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
  -> already: 30
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
  -> already: 300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
  -> already: 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
  -> already: 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
  -> already: 120
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
  -> already: 300

ما زلت أرى المشكلة عند تعيين net.ipv6.conf.all.disable_ipv6 = 1.

يمكن لأداة ضغط عامل الإرساء أن تنتج المشكلة بسهولة بالغة.
https://github.com/crosbymichael/docker-stress

هذا هو الثنائي الذي أنشأته للأداة أعلاه.
https://storage.googleapis.com/donny/main
https://storage.googleapis.com/donny/stress.json

بمجرد أن نرى السجل "unregister_netdevice: انتظار veth6c3b8b0 ليصبح مجانيًا. عدد الاستخدام" ، يتوقف عامل الإرساء. أعتقد أن هذه مشكلة نواة أثارتها عامل ميناء. سيحدث هذا فقط عندما يكون وكيل Docker userland مغلقًا (--userland-proxy = false).

لقد حدث هذا مع تمكين وكيل userland وبدونه ، لذلك لن أقول فقط عند إيقاف تشغيله.

يمكن أن يجعل الوضع أسوأ ؛ أعلم أننا حاولنا مرة أن نجعل --userland-proxy=false الخيار الافتراضي ، لكننا عدنا إلى ذلك بسبب وجود آثار جانبية https://github.com/docker/docker/issues/14856

لقد رأيت أيضًا الخطأ مرة واحدة منذ يوم أمس ، ومن الواضح أن تعطيل IPv6 ليس إصلاحًا ؛ ولكن بدون العلم لا يمكنني حتى بدء تشغيل جميع حاويات الخادم دون التخلص من عامل الإرساء.

يعمل على CoreOS 1010.1.0 مع kubernetes 1.2.2 و docker 1.10.3

أضافت Kubernetes علامة إلى kubelet (على الهاتف المحمول ، لذا لا يمكن البحث عنها)
وضع دبوس الشعر. قم بتغييره إلى "جسر منحل" أو أيًا كان ما هو صالح
القيمة. لم نشهد هذا الخطأ منذ إجراء هذا التغيير.

تضمين التغريدة

الرجاء تأكيد أو دحض؟
في 13 نيسان (أبريل) 2016 ، الساعة 12:43 ظهرًا ، "Aaron Crickenberger" [email protected]
كتب:

يعمل على CoreOS 1010.1.0 مع kubernetes 1.2.2 و docker
1.10.3

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/docker/docker/issues/5618#issuecomment -209617342

الحصول على هذا على AWS الذي يعمل بنظام التشغيل Linux 4.4.5-15.26.amzn1.x86_64 مع Docker الإصدار 1.9.1 ، قم ببناء a34a1d5 / 1.9.1.

يتم تشغيل Ruby 2.3.0 مع صورة Alpine داخل الحاوية مما تسبب في ذلك

النواة: [58551.548114] unregister_netdevice: انتظار lo لتصبح حرة. عدد الاستخدام = 1

أي إصلاح لهذا؟

شاهد هذا لأول مرة على Linux 3.19.0-18-generic #18~14.04.1-Ubuntu SMP Wed May 20 09:38:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

زوجان يعيدان التشغيل بإصلاحه.

MrMMorris تم الإصلاح لأنك متأكد من أن المشكلة قد اختفت إلى الأبد ، أو أنك لا تواجهها مرة أخرى بعد؟ يمكن أن تكون حالة سباق ...

من الواضح جدًا أن هذا سباق في النواة ، يخسر عددًا من المراجعة
مكان ما. هذا خطأ يصعب تعقبه حقًا ، ولكن بقدر ما يمكننا أن نقول
لا يزال موجودا.

يوم الاثنين 2 مايو 2016 الساعة 10:52 مساءً ، Sune Keller [email protected]
كتب:

MrMMorris https://github.com/MrMMorris ثابت لأنك متأكد من أن
اختفت المشكلة إلى الأبد ، أو لأنك لا تواجهها مرة أخرى
للتو؟ يمكن أن تكون حالة سباق ...

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/docker/docker/issues/5618#issuecomment -216444133

نعم. لقد جربت CoreOS 1032.0.0 مع kernel 4.5 ، ولا تزال المشكلة قائمة.

لقد واجهت هذا مرة أخرى على CoreOS 1010.1.0 مع kernel 4.5.0 أمس ، بعد أن بدأت عدة حاويات وقتلها في تتابع سريع.

لدي هذا الخطأ.

إصدار عامل السفن: 1.9.1
إصدار Kernel: 4.4.8-20.46.amzn1.x86_64
نظام التشغيل: Amazon Linux AMI 2016.03

sirlatrom غير ثابت. رؤية هذا مرة أخرى 😭 مطلوب عمليات إعادة تمهيد متعددة لحلها.

قيد التشغيل حاليًا 3.19.0-18-generic. سنحاول الترقية إلى الأحدث

كذلك هنا! صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة : صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة : صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة : صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة: صرخة ، صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة : صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة: صرخة:

samvignoli تعليقاتك ليست بناءة. من فضلك توقف عن النشر.

آسف ، نسيت وظيفة ممتاز.

مستنسخ في Fedora Server 23 - 4.2.5-300.fc23.x86_64. لا يمكن إعادة تشغيل خدمة Docker - أعد تشغيل العقدة فقط.

نفس المشكلة على Fedora 24 Kernel: 4.5.2-302.fc24.x86_64. لم يتسبب في حدوث أي توقف ، ولكن إرسال ملف سجل مزعج.

hapylestat هل يمكنك تجربة systemctl restart docker ؟ هذا تسبب في تعليق كل شيء من أجلي.

شكرا

يحدث هذا لأجهزتي (CoreOS ، EC2) بشكل متكرر. إذا كان الأمر مفيدًا على الإطلاق ، فإليك جميع السجلات المتعلقة بجهاز veth العالق في حالة واحدة من هذا الخطأ.

$ journalctl | grep veth96110d9
May 14 16:40:27 ip-10-100-37-14.eu-west-1.compute.internal systemd-udevd[4189]: Could not generate persistent MAC address for veth96110d9: No such file or directory
May 14 16:40:27 ip-10-100-37-14.eu-west-1.compute.internal kernel: IPv6: ADDRCONF(NETDEV_UP): veth96110d9: link is not ready
May 14 16:40:27 ip-10-100-37-14.eu-west-1.compute.internal systemd-networkd[665]: veth96110d9: Configured
May 14 16:40:27 ip-10-100-37-14.eu-west-1.compute.internal kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth96110d9: link becomes ready
May 14 16:40:27 ip-10-100-37-14.eu-west-1.compute.internal systemd-networkd[665]: veth96110d9: Gained carrier
May 14 16:40:27 ip-10-100-37-14.eu-west-1.compute.internal systemd-networkd[665]: veth96110d9: Lost carrier
May 14 16:40:27 ip-10-100-37-14.eu-west-1.compute.internal systemd-networkd[665]: veth96110d9: Removing non-existent address: fe80::98f4:98ff:fea2:d83b/64 (valid for ever)
May 14 16:40:32 ip-10-100-37-14.eu-west-1.compute.internal kernel: eth0: renamed from veth96110d9
May 14 16:53:45 ip-10-100-37-14.eu-west-1.compute.internal kernel: veth96110d9: renamed from eth0
May 14 16:53:45 ip-10-100-37-14.eu-west-1.compute.internal systemd-networkd[665]: veth96110d9: Configured
May 14 16:53:45 ip-10-100-37-14.eu-west-1.compute.internal systemd-networkd[665]: veth96110d9: Gained carrier
May 14 16:53:45 ip-10-100-37-14.eu-west-1.compute.internal kernel: IPv6: veth96110d9: IPv6 duplicate address fe80::42:aff:fee0:571a detected!
May 14 16:53:45 ip-10-100-37-14.eu-west-1.compute.internal systemd-networkd[665]: veth96110d9: Lost carrier
May 14 16:53:45 ip-10-100-37-14.eu-west-1.compute.internal systemd-networkd[665]: veth96110d9: Removing non-existent address: fe80::42:aff:fee0:571a/64 (valid for ever)
May 14 16:53:55 ip-10-100-37-14.eu-west-1.compute.internal kernel: unregister_netdevice: waiting for veth96110d9 to become free. Usage count = 1
May 14 16:54:05 ip-10-100-37-14.eu-west-1.compute.internal kernel: unregister_netdevice: waiting for veth96110d9 to become free. Usage count = 1
May 14 16:54:15 ip-10-100-37-14.eu-west-1.compute.internal kernel: unregister_netdevice: waiting for veth96110d9 to become free. Usage count = 1
May 14 16:54:25 ip-10-100-37-14.eu-west-1.compute.internal kernel: unregister_netdevice: waiting for veth96110d9 to become free. Usage count = 1
May 14 16:54:35 ip-10-100-37-14.eu-west-1.compute.internal kernel: unregister_netdevice: waiting for veth96110d9 to become free. Usage count = 1

يبدو أن هذا يحدث عندما أزيل العديد من الحاويات مرة واحدة (في حالتي ، عندما أحذف قرون k8s بشكل جماعي).

بالنسبة لأولئك الذين يقولون إن إعادة التشغيل تم إصلاحها - هل أعدت تشغيل الأجهزة أو أوقفتها / بدأت تشغيلها؟ على الأجهزة المادية ، اضطررت إلى استخدام إعادة تعيين الطاقة عن بُعد لإعادة تشغيل الجهاز.

@ joshrendek ، اضطررت إلى استخدام التمهيد البارد لـ iLO (أي دورة الطاقة المادية).

joshrendek لدي برنامج نصي الآن يتم تشغيله لمشاهدة هذا ويتم تنفيذ reboot -f عندما يحدث ذلك 😢.

ربما وجد المشكلة (أو حالفك الحظ). لقد قمت بنقل Docker Graph dir من قرص مقسم XFS إلى قرص مقسم EXT4 ولا يمكنني إعادة إنتاج المشكلة (بالإضافة إلى حل حمل من أخطاء XFS الأخرى التي كنت أحصل عليها). أتذكر vbatts قائلًا إن XFS غير مدعوم حتى الآن.

لقد حاولت الاستفزاز من خلال تشغيل build ، run ، stop ، delete في حلقة infinate على صور متنوعة ، وإنشاء حوالي 10 حاويات في كل دورة ، من أجل الساعات القليلة الماضية.

joedborg ما هو محرك الرسم البياني الذي تستخدمه؟ Devicemapper؟ تراكب؟

thaJeztah نقطة جيدة ، كان ينبغي أن أذكر ذلك. أنا أستخدم برنامج تشغيل Overlay مع دعم EXT4 FS (الآن).

اعتدت استخدام devicemapper (لأنني أستخدم خادم Fedora) ، لكن كان لدي الكثير من الألم (كما أعتقد الكثيرون يفعلون) ، خاصةً مع التسريبات حيث لن يعيد مصمم الخرائط مساحة إلى المسبح بمجرد حذف الحاوية.

إذا كان ذلك مفيدًا ، فأنا على Docker 1.11.1 و Kernel 4.2.5-300.fc23.x86_64.

joedborg مثير للاهتمام ، لأن مستندات RHEL ذكرت أن EXT4 فقط مدعوم على RHEL / CentOS 7.1 ، و XFS فقط على RHEL / CentOS 7.2. كنت أتوقع أن يعمل XFS على الإصدارات الأحدث في ذلك الوقت

thaJeztah آه هذا غريب. أحاول التفكير في أشياء أخرى قد تكون. لقد أعدت القراءة من الأعلى ويبدو أن بعض الأشخاص يقومون بتشغيل نفس التكوين. الشيء الآخر الوحيد المختلف هو أن قرص XFS هو مغزل وأن EXT4 هو SSD. سأستمر في نقع الاختبار في الوقت نفسه. لقد انتقلت أيضًا إلى prod لاستخدام نفس الإعداد ، لذلك في كلتا الحالتين سيكون لدينا إجابة في وقت قريب. ومع ذلك ، فقد كان يتم تحقيقه على كل stop قبل ، لذا فهو بالتأكيد أفضل.

joedborg حسنًا ، إنها معلومات مفيدة بالفعل

نفس الخطأ هنا ، من kernel 4.2 إلى 4.5 ، نفس docker verion.

راجع للشغل ، أنا أقوم بتشغيل العديد من أجهزة Virtualbox على نفس الصندوق في نفس الوقت.

$ docker version
Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:        Mon Oct 12 05:27:08 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:        Mon Oct 12 05:27:08 UTC 2015
 OS/Arch:      linux/amd64

$ docker info
Containers: 3
Images: 461
Storage Driver: devicemapper
 Pool Name: docker-253:7-1310721-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 18.08 GB
 Data Space Total: 107.4 GB
 Data Space Available: 18.37 GB
 Metadata Space Used: 26.8 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.121 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.90 (2014-09-01)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.5.0-0.bpo.1-amd64
Operating System: Debian GNU/Linux 8 (jessie)
CPUs: 4
Total Memory: 15.56 GiB
Name: tungsten
ID: HJX5:TKIH:TF4G:JCQA:MHQB:YYUD:DHBL:53M7:ZRY2:OCIE:FHY7:NLP6

أواجه هذه المشكلة باستخدام برنامج تشغيل الرسم البياني overlay ، مع الدليل على ext4 FS. لذلك لا أعتقد أن المشكلة هي xfs

obeattie نعم ، يبدو أن الناس يحصلون عليه devicemapper أيضًا. المس الخشب ، لم أواجه المشكلة مرة أخرى منذ التبديل. كما ذكرنا ، قمت أيضًا بتبديل القرص الفعلي. سيكون هذا أمرًا مثيرًا للاهتمام!

هذه المشكلة لا ترتبط بنظام الملفات بأي شكل من الأشكال. لقد رأيت هذه المشكلة مع zfs و overlayfs و devicemapper و btrfs و aufs. أيضا مع أو بدون مبادلة. لا يقتصر الأمر على عامل الإرساء ، لقد أصبت بنفس الخطأ مع lxc أيضًا. الحل الوحيد ، الذي أراه حاليًا ، هو عدم إيقاف الحاوية بشكل متزامن.

إذا كان ذلك مفيدًا ، فأنا أتلقى نفس رسالة الخطأ على أحدث مثيل ec2 مدعوم من AWS AMI. يظهر إصدار عامل ميناء-

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

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

مجرد القفز على متن الطائرة. أرى نفس السلوك في أحدث مثيل Amazon ec2. بعد فترة من الوقت ، تنقلب الحاوية وتصبح غير مستجيبة.

معلومات عامل الإرساء $
الحاويات: 2
الصور: 31
إصدار الخادم: 1.9.1
برنامج تشغيل التخزين: devicemapper
اسم البركة: docker-202: 1-263705-pool
حجم حوض السباحة: 65.54 kB
حجم الجهاز الأساسي: 107.4 جيجا بايت
دعم نظام الملفات:
ملف البيانات: / dev / loop0
ملف البيانات الوصفية: / dev / loop1
مساحة البيانات المستخدمة: 1.199 جيجا بايت
إجمالي مساحة البيانات: 107.4 جيجا بايت
مساحة البيانات المتوفرة: 5.754 جيجابايت
مساحة البيانات الوصفية المستخدمة: 2.335 ميجا بايت
إجمالي مساحة البيانات الوصفية: 2.147 جيجابايت
مساحة البيانات الوصفية المتوفرة: 2.145 جيجابايت
دعم Udev Sync: صحيح
تم تمكين الإزالة المؤجلة: خطأ
تم تمكين الحذف المؤجل: خطأ
عدد الأجهزة المحذوفة المؤجلة: 0
ملف حلقة البيانات: / var / lib / docker / devicemapper / devicemapper / data
ملف حلقة البيانات الوصفية: / var / lib / docker / devicemapper / devicemapper / metadata
إصدار المكتبة: 1.02.93-RHEL7 (2015-04-28)
سائق التنفيذ: أصلي -0.2
برنامج تشغيل التسجيل: ملف json
إصدار النواة: 4.4.10-22.54.amzn1.x86_64.0
نظام التشغيل: Amazon Linux AMI 2016.03
وحدات المعالجة المركزية: 1
إجمالي الذاكرة: 995.4 ميجابايت
الاسم: [منقح]
المعرّف: OB7A: Q6RX: ZRMK: 4R5H : ZUQY: BBNK : BJNN: OWKS : FNU4: 7NI2: AKRT: 5SEP

نسخة عامل ميناء دولار
عميل:
الإصدار: 1.9.1.1
إصدار API: 1.21
إصدار Go: go1.4.2
Git الالتزام: a34a1d5 / 1.9.1
مبني:
OS / Arch: لينكس / amd64

الخادم:
الإصدار: 1.9.1.1
إصدار API: 1.21
إصدار Go: go1.4.2
Git الالتزام: a34a1d5 / 1.9.1
مبني:
OS / Arch: لينكس / amd64

مثل التعليقات المذكورة أعلاه ، يعمل أيضًا على EC2 عبر ساق شجرة الفاصولياء المرنة باستخدام 64bit Amazon Linux 2016.03 v2.1.0 running Docker 1.9.1

إلى حد ما قصصية في هذا الوقت ، لكنني حاولت مؤخرًا الترقية من 4.2.0 إلى 4.5.5 kernel على حوالي 18 خادمًا كاختبار ، وأصبحت هذه المشكلة أسوأ إلى حد كبير (من عدة أيام إلى ما لا يزيد عن 4 ساعات بين الإصدارات).

كان هذا في دبيان 8

نفس الإعداد تمامًا مثل jonpaul و @ g0ddard

نتطلع لنرى كيف يمكننا التخفيف من هذا الخطأ.
أول شيء (قد ينجح وقد لا ينجح ، إنه محفوف بالمخاطر) هو إبقاء واجهة برمجة التطبيقات متاحة في الحالات التي يحدث فيها هذا: # 23178

أهلا. لقد تعرضت للعض من هذا الخطأ ...

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

أنا أستخدم Kubernetes 1.2.4 على CoreOS Beta و Flannel ويعمل على Azure. هل هناك طريقة للمساعدة في تصحيح هذه المشكلة؟ يبدو أن خيط علة النواة ميت. أفاد بعض الأشخاص أن تعطيل IPv6 على النواة ، باستخدام --userland-proxy=true أو استخدام aufs بدلاً من التخزين المتراكب ، يساعد في ذلك ، بينما لا يفعل الآخرون ... إنه أمر محير بعض الشيء.

Like @ justin8 لقد لاحظت هذا أيضًا بعد ترقية نظام Fedora 23 الخاص بي إلى kernel 4.5.5 ؛ تظل المشكلة مع kernel 4.5.6.

لقد واجهنا هذا الخطأ عندما كانت الحاوية تصل إلى حد الذاكرة الخاص بها. غير متأكد إذا كان مرتبطًا أم لا.

نفس المشكلة هنا

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

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

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

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

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

سنتوس 7.2
عامل ميناء 1.10.3
نفس المشكلة

لدي "خط واحد" سيعيد إنتاج هذه المشكلة في النهاية بالنسبة لي على EC2 (m4.large) يعمل بنظام CoreOS 1068.3.0 مع نواة 4.6.3 (حديثة جدًا جدًا). بالنسبة لي ، يستغرق الأمر حوالي 300 تكرار ولكن YMMV.

Linux ip-172-31-58-11.ec2.internal 4.6.3-coreos # 2 SMP السبت 25 يونيو 00:59:14 بالتوقيت العالمي المنسق 2016 x86_64 وحدة المعالجة المركزية Intel (R) Xeon (R) E5-2676 v3 @ 2.40 جيجا هرتز GenuineIntel جنو / لينكس
CoreOS بيتا (1068.3.0)
إصدار Docker 1.10.3 ، بناء 3cd164c

بضع مئات من التكرارات للحلقة هنا ستعلق في النهاية dockerd وستصدر النواة رسائل خطأ مثل

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

حلقة الناسخ هي

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

التعديلات

• لم أتمكن من التكاثر بهذا إلا عندما userland-proxy=false
• لم أتمكن من إعادة الإنتاج باستخدام VirtualBox (فقط ec2 حتى الآن) ، لذلك ربما يتعلق الأمر ببرنامج Hypervisor أيضًا

نصbtalbot ، أعلاه ، لا يعيد إنتاج المشكلة لي في Fedora 23 بعد عدة آلاف من التكرارات.

$ docker --version
Docker version 1.10.3, build f476348/1.10.3
$ docker info
Containers: 3
 Running: 0
 Paused: 0
 Stopped: 3
Images: 42
Server Version: 1.10.3
Storage Driver: devicemapper
 Pool Name: docker_vg-docker--pool
 Pool Blocksize: 524.3 kB
 Base Device Size: 107.4 GB
 Backing Filesystem: xfs
 Data file: 
 Metadata file: 
 Data Space Used: 17.69 GB
 Data Space Total: 73.67 GB
 Data Space Available: 55.99 GB
 Metadata Space Used: 5.329 MB
 Metadata Space Total: 130 MB
 Metadata Space Available: 124.7 MB
 Udev Sync Supported: true
 Deferred Removal Enabled: true
 Deferred Deletion Enabled: true
 Deferred Deleted Device Count: 0
 Library Version: 1.02.109 (2015-09-22)
Execution Driver: native-0.2
Logging Driver: journald
Plugins: 
 Volume: local
 Network: bridge null host
Kernel Version: 4.5.7-200.fc23.x86_64
Operating System: Fedora 23 (Workstation Edition)
OSType: linux
Architecture: x86_64
Number of Docker Hooks: 0
CPUs: 4
Total Memory: 15.56 GiB
Name: <hostname>
ID: TOKW:AWJF:3VZU:55QA:V3KD:ZCA6:4XWW:JBY2:2Q5C:3S65:3ZXV:XRXG
Registries: docker.io (secure)

تحدث هذه المشكلة بشكل متكرر في مجموعة Kubernetes الخاصة بي ، ولكن لا يمكنني إعادة إنتاجها بشكل موثوق باستخدام عوامل الإجهاد أو بطانةbtalbot . لقد حاولت تشغيله على اثنين من Azure VMs مع CoreOS 1068.3.0.

أول VM كان Standard_D1_v2 (3.5 جيجا بايت رام ، 1 نواة) - قام النص بأكثر من 3000 تكرار.
كان VM الثاني هو Standard_DS15_v2 (140 غيغابايت من ذاكرة الوصول العشوائي ، 20 نواة) - قام البرنامج النصي بأكثر من 7600 تكرار.

لقد قمت بتحديث تعليقي السابق (https://github.com/docker/docker/issues/5618#issuecomment-229545933) لتضمين أنه لا يمكنني إعادة إنتاج هذا إلا عندما يكون userland-proxy = false.

إنه يستنسخ بالنسبة لي على أجهزة افتراضية EC2 t2.micro (أحادية النواة) وكذلك m4.large (متعدد النواة) باستخدام HVM. لم أر ذلك يحدث باستخدام VirtualBox على الكمبيوتر المحمول الخاص بي حتى الآن بغض النظر عن إعداد وكيل userland.

لقد واجهنا هذا الخطأ أثناء استخدام Flannel مع تمكين hairpin-veth في مجموعة kubernetes (باستخدام وكيل iptables). كان هذا الخطأ يحدث فقط عندما توقفنا عن تشغيل الكثير من الحاويات. ننتقل إلى استخدام شبكة جسر cbr0 ووضع دبوس الشعر منحل الجسر ولا نراه مرة أخرى.
في الواقع ، من السهل إعادة إنتاج هذا الخطأ إذا كنت تستخدم hairpin-veth ، فقط ابدأ هذه المهمة بـ 100 حاوية مع kubernetes.

في 01/07/2016 08:01 ، كتب manoj0077:

btalbot https://github.com/btalbot لذلك مع 1.12 يمكننا إعادة التشغيل
dockerd دون التأثير على تشغيل الحاويات. لذلك سوف إعادة تشغيل dockerd
مساعدة هنا في هذه الحالة؟

AFAICT ، الحدث مع 1.12 ، لا تزال عمليات حاويات الرصيف أطفالًا
من عفريت عامل الميناء.

sercand كيف قمت بتعيين وضع دبوس الشعر منحل الجسر؟ لا يمكنني رؤية أي وثائق من عامل الميناء حول ذلك ، أو ربما يستخدمون اسمًا مختلفًا

هل هناك كلمة رسمية من Docker 🐳 حول متى يمكن النظر إلى هذا؟ هذه هي ثاني أكثر قضية مفتوحة تعليقًا ؛ شديد جدًا (يستلزم إعادة تشغيل المضيف) ؛ قابل للتكاثر ولا أرى أي تقدم حقيقي نحو تحديد السبب الجذري أو إصلاحه 😞.

يبدو أن هذا على الأرجح مشكلة نواة ، لكن التذكرة على Bugzilla ظلت راكدة لعدة أشهر. هل سيكون من المفيد نشر حالات الاختبار لدينا هناك؟

@ justin8 أعتقد أن هذه هي أعلام Kubelet: --configure-cbr0 و --hairpin-mode

sercand أنا أيضًا أستخدم Flannel. هل هناك عيب في استخدام --hairpin-mode=promiscuous-bridge ؟

obeattie أوافق. :(

FTR تمكنت من تكرار المشكلة باستخدامsercand الصورة وظيفة stresser على اختبار مجموعة Kubernetes أن أقوم بإعداد، ويستخدم أيضا الفانيلا ودبوس-veth.

sercand هل يمكنك رجاءً تفصيل الخطوات لبدء استخدام promiscuous-bridge ؟ أضفت العلم --configure-cbr0=true إلى kubelet للعقدة لكنها تشتكي:
ConfigureCBR0 requested, but PodCIDR not set. Will not configure CBR0 right now . اعتقدت أن هذا PodCIDR كان من المفترض أن يأتي من السيد؟ شكرا.

تحرير: يبدو أنني بحاجة إلى إضافة --allocate-node-cidrs=true --cluster-cidr=10.2.0.0/16 إلى تكوين مدير وحدة التحكم ، ولكن نظرًا لعدم وجود موفر سحابي (Azure) ، فمن المحتمل ألا تعمل المسارات.

@ justin8 لقد تابعت هذا المستند .
edevil من وضع منعطف التوثيق هو لـ "يسمح هذا لنقاط نهاية الخدمة بإعادة التوازن إلى نفسها إذا كان ينبغي عليهم محاولة الوصول إلى الخدمة الخاصة بهم". بالمناسبة ، تعمل مجموعتي في Azure ولم يكن من السهل تحقيقها.

sercand وفقًا للمستند ، إذا استخدمنا --allocate-node-cidrs=true على مدير وحدة التحكم ، فمن المفترض أن نستخدم موفر السحابة من أجل إعداد المسارات. نظرًا لعدم وجود موفر سحابة Kubernetes لـ Azure ، ألم تواجهك مشكلات؟ هل تقوم بإعداد المسارات يدويًا؟ شكرا.

edevil أستخدم هذا الريبو . لقد قمت بإنشاء هذا التكوين بسرعة واختبرته مرة واحدة فقط. آمل أن يكون ذلك كافياً لتوفير المنطق الأساسي وراء ذلك.

morvansbtalbot لم تحصل على فرصة لمحاولة مع 1.12 ...؟

أستطيع أن أؤكد أن الابتعاد عن hairpin-veth واستخدام جسر cbr0 لا يمكنني إعادة إنتاج المشكلة بعد الآن.

فقط في حالة: أي شخص لديه هذه المشكلة على المعدن؟ لقد رأينا هذا عند اختبار مجموعة المزارع في مختبر VMWare الخاص بنا ، ولكن لم نشاهده مطلقًا في نشر المعادن العارية الحقيقية.

نعم ، تحدث هذه المشكلة على المعدن العاري لأي نواة> = 4.3. لقد رأيت هذا على الكثير من الأجهزة المختلفة وتكوينات الأجهزة. الحل الوحيد بالنسبة لنا هو استخدام kernel 4.2.

من المؤكد أنه لا يزال يحدث في 4.2 ، لكنه أمر من حيث الحجم في كثير من الأحيان على أي شيء أحدث ، لقد تم اختبار كل إصدار رئيسي لمعرفة ما إذا كان أفضل ، ولا شيء حتى الآن

يحدث أيضًا في CoreOS alpha 1097.0.0.

النواة: 4.6.3
عامل ميناء: 1.11.2

لدي نفس المشكلة.

عامل ميناء: 1.11.2
النواة: 4.4.8-boot2docker.

المضيف: Docker-machine with VMWare Fusion driver على OS X.

أي حلول مقترحة؟

سيكون مفيدًا حقًا إذا كان بإمكان الأشخاص منكم الذين يمكنهم إعادة إنتاج المشكلة بشكل موثوق في بيئة يمكن فيها حدوث تعطل (ويعرف أيضًا باسم EC2) مشاركة ملف تفريغ الأعطال هذا ، ويمكن العثور على مزيد من المعلومات حول كيفية تمكين برنامج kdump في ubuntu الموثوق به هنا و هذه هي خيارات التعطل التي تحتاج إلى تمكينها عندما يكون kdump جاهزًا لإنشاء تعطل:

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

يمكن أن يساعد التعطل حقًا مطوري kernel في العثور على المزيد حول سبب تسرب المرجع ولكن ضع في اعتبارك أن التعطل يتضمن أيضًا تفريغ ذاكرة مضيفك وقد يحتوي على معلومات معقولة.

... معلومات معقولة.

: س

أنا على التوالي في نفس القضية.

Jul 13 10:48:34 kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1

Linux 4.6.3-1.el7.elrepo.x86_64
Docker: 1.11.2

المشكلة نفسها:

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

Docker version: 1.10.3

حدث للتو مباشرة على شاشة المحطة:

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

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

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

النظام

Linux svn.da.com.ar 4.4.14-24.50.amzn1.x86_64 #1 SMP Fri Jun 24 19:56:04 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

نفس المشكلة

Os: Amazon Linux AMI release 2016.03
Docker: 1.9.1

هنا ايضا:

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

أشاهد نفس المشكلة على EC2:

Docker version 1.11.2, build b9f10c9/1.11.2
NAME="Amazon Linux AMI"
VERSION="2016.03"
ID="amzn"
ID_LIKE="rhel fedora"
VERSION_ID="2016.03"
PRETTY_NAME="Amazon Linux AMI 2016.03"
CPE_NAME="cpe:/o:amazon:linux:2016.03:ga"
HOME_URL="http://aws.amazon.com/amazon-linux-ami/"

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

(على كل صفيرتي + pty عندما يحدث هذا)
"ببساطة" Debian Jessie + backports:

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

أهلا،

عندما أحاول تكرار المشكلة على بيئة خاضعة للرقابة من خلال إنشاء صور مدمرة جديدة لا يمكنني إعادة إنتاجها.

تم رفع المشكلة في أحد الخوادم التي تقوم بتشغيل Docker 1.9.1

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

أقوم بتناول حاوية 17753 بشكل متزامن حتى الآن في الوضع المتزامن ورفع حركة المرور إلى الإنترنت ، دون تسرب أي من واجهة veth *. هل يمكن لأي شخص لصق التعليمات لإعادة إظهار المشكلة باستمرار؟

pegerto يجب أن يكون من السهل جدًا --userland-proxy=false وقم بتدوير مجموعة من الحاويات في نفس الوقت. أفعل ذلك باستخدام https://github.com/crosbymichael/docker-stress

شكرا @ cpuguy83

تكوين البرنامج الخفي للحصول على --userland-proxy=false يمكنني بسهولة إعادة إنتاج المشكلة ، شكرًا لك ، يمكننا رؤية هذه المشكلة التي تؤثر على البرامج الخفية التي لا تقوم بتشغيل هذا التكوين.

أرى تفريغ kernel في خطاف netfilter الذي تم تقديمه من خلال فصل الشبكات عند> = 4.3 ، هل هناك أفكار حول سبب ظهور المشكلة بشكل أسوأ عند حدوث المسار عند 127/8؟

شكرا

رؤية هذه القضية أيضا. CoreOS 1068.8.0 و Docker 1.10.3 و kernel 4.6.3. لقد سحبت بعض سجلات النظام إذا كان أي شخص مهتمًا.

فقط حصلت على عدة ...
unregistered_netdevice: waiting for lo to become free. Usage count = 1
... على 2 VMs وعلى الكمبيوتر المحمول baremetal الخاص بي ، تعمل جميعها بنظام Ubuntu 16.04 وأحدث النواة (4.4.0-3 [456]).

والنتيجة هي أن كل شيء معلق ويتطلب إعادة تشغيل صعبة.
لم تختبر هذا قبل الأسبوع الماضي وأعتقد أن أحد VM كان عند 1.11.3 بينما كان الآخرون جميعًا عند 1.12.0.

RRAlex هذا ليس خاصًا بأي إصدار عامل ميناء.
إذا كنت تستخدم --userland-proxy=false في خيارات البرنامج الخفي ... أو (مما أفهمه) فأنت تستخدم kubernetes ، فمن المحتمل أن تواجه هذه المشكلة.

السبب هو أن الخيار --userland-proxy=false يمكّن NAT دبوس الشعر على واجهة الجسر ... هذا شيء تحدده kubernetes أيضًا عند إعداد الشبكة لحاوياتها.

رؤية هذا على عقدة BYO باستخدام Docker Cloud (و Docker Cloud agent).

رأيت هذا اليوم ، مرة واحدة (من حوالي 25 محاولة) في Amazon ECS AMIs الحالية ، تشغيل vanilla debian: jessie باستخدام أمر apt-get updates ، تثبيت pbzip2 ، ثم تشغيله (اختبار بسيط لوحدة المعالجة المركزية متعددة مؤشرات الترابط).

edevil
يصف معظمكم هنا أنك واجهت هذا الموقف أثناء استخدام Docker لبدء / إيقاف الحاويات ، لكنني واجهت نفس الموقف تمامًا بدون Docker ، على دبيان:

• Debian "Jessie" (= Debian الإصدار 8.5) ، على baremetal (لا يوجد جهاز افتراضي ، ولا سحابة ، ولكن أجهزة عادية)
• نواة 3.16.0-4-amd64
• بدأت 4 حاويات LXC
• أغلق حاوية LXC واحدة بـ "lxc-stop -n $ containerName"
• عند اكتمال هذا الأمر ، من المحتمل أن النواة أو الواجهات لم يتم "تنظيفها" بالكامل بعد ، لأنني عندما أقوم مباشرة بعد "lxc-stop" السابق بتشغيل "lxc-stop" جديد ، عندها لدي مشكلة kernel

لا توجد طريقة للاسترداد باستثناء إعادة ضبط الجهاز.

لذا من فضلك ، في تحقيقاتك لتحديد / حل هذه المشكلة ، لا تركز على Docker وحده. من الواضح أنها مشكلة عامة تتعلق بالإيقاف / التشغيل السريع للحاويات ، سواء كان ذلك من خلال Docker ، أو من خلال أوامر "lxc" العادية.

أعتقد أن هذه مشكلة لينوكس نواة.

لقد واجهت هذه المشكلة عندما يكون لدي 3 chroot (في الواقع pbuilder) يعمل مع حمولة ثقيلة جدًا.
جهازي هو Loongson 3A (آلة mips64el مع نواة 3.16).

عندما أحاول الخوض فيها ، واجهت هذه المشكلة.

لذلك قد لا تتعلق هذه المشكلة فقط بـ Docker أو lxc ، بل إنها تتعلق أيضًا بـ chroot.

إصدار Docker 1.11.2.

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

cat /etc/os-release 
NAME=openSUSE
VERSION="Tumbleweed"
VERSION_ID="20160417"
PRETTY_NAME="openSUSE Tumbleweed (20160417) (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:20160417"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
ID_LIKE="suse"

uname -a
Linux centre 4.5.0-3-default #1 SMP PREEMPT Mon Mar 28 07:27:57 UTC 2016 (8cf0ce6) x86_64 x86_64 x86_64 GNU/Linux

المعدن.

واجهتنا المشكلة مؤخرًا على المعدن العاري (المخصص على ovh) مع kernel 4.6.x و docker 1.11.2.
بعد قراءة التعليقات هنا وتجربة العديد من الحلول البديلة ، قمنا بخفض إصدار kernel الخاص بنا إلى الإصدار الأحدث من الفرع 3.14 (3.14.74) وترقية docker إلى 1.12.0 لتجنب https://github.com/docker/libnetwork/issues/1189 ويبدو أن كل شيء على ما يرام في الوقت الحالي.

آمل أن يكون هذا يمكن أن تساعد.

الكل ، أعتقد أنك لست بحاجة إلى نشر رسائل بعد الآن حول Docker أو chroot ، فالأمر كله يتعلق بنواة Linux.
لذا رجاءً ، هل يمكن لشخص أن يقف من يمكنه تصحيح أخطاء النواة بطريقة ما ، في الأجزاء التي يتم فيها تعطيل واجهات الشبكة الافتراضية للحاويات؟ ربما تحدث بعض ظروف السباق عندما لا يؤدي التوقف السابق للحاوية إلى تعطيل / تنظيف واجهتها الافتراضية بالكامل ، قبل طلب إيقاف جديد للحاوية.

rdelangh لا أعتقد أن هذه المشكلة مرتبطة بالضرورة بالنواة.

في Fedora 24 ، لا يمكنني إعادة إنتاج المشكلة مع Docker 1.10.3 من مستودعات Fedora ، فقط مع Docker 1.12.1 من مستودعات Docker الخاصة.

تم إجراء كلا الاختبارين باستخدام kernel 4.6.7-300.fc24.x86_64.

رؤية هذه المشكلة أيضًا على CoreOS 1068.10.0 و Docker 1.10.3 و kernel 4.6.3.

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

باستخدام Kubernetes 1.3.4 على CoreOS 1068.9.0 مستقر على EC2 ، docker 1.10.3 أرى هذه المشكلة.

unregister_netdevice: waiting for veth5ce9806 to become free. Usage count = 1
unregister_netdevice: waiting for veth5ce9806 to become free. Usage count = 1
unregister_netdevice: waiting for veth5ce9806 to become free. Usage count = 1
...
uname -a
Linux <redacted> 4.6.3-coreos #2 SMP Fri Aug 5 04:51:16 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz GenuineIntel GNU/Linux

رؤية هذه المشكلة أيضًا على Ubuntu 16.04 و Docker 1.12.1 و kernel 4.4.0-34-generic
waiting for lo to become free. Usage count = 1

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

...

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

بالنسبة لأولئك الذين يستخدمون Kubernetes <= 1.3.4 ، يمكنك استغلال هذه المشكلة: https://github.com/kubernetes/kubernetes/issues/30899 لإعادة إظهار هذه المشكلة. قمت بتشغيل مجموعة صغيرة مع وحدة تحكم واحدة (m4.large) وعاملين (m4.large) على CoreOS 1068.10.

من هناك يمكنك إنشاء وحدتي ReplicationController ، وقد اتصلت بهما hello و hello1 بناءً على هذا: http://pastebin.com/mAtPTrXH . تأكد من تغيير الأسماء والتسميات لتكون مختلفة.

بعد ذلك ، قم بإنشاء عمليتي نشر تتطابقان مع نفس الأسماء / التصنيفات المذكورة أعلاه بناءً على هذا: http://pastebin.com/SAnwLnCw .

_ بمجرد إنشاء عمليات النشر ، ستحصل على قدر هائل من حاويات البريد العشوائي_.

إذا تركته لفترة (عدة دقائق) ، فسترى الكثير من الأشياء التي تحاول الإنهاء / الإنشاء. يمكنك حذف عمليات النشر وترك الأمور تستقر. يجب أن ترى عددًا قليلاً من عمليات الإنهاء وإنشاء الحاويات. إذا أدخلت العقد ، فتحقق من dmesg و docker ps لمعرفة ما إذا كانت الأعراض المذكورة أعلاه ظاهرة.

في حالتي ، استغرق الأمر حوالي 5 دقائق من ترك هذا الخوف قبل رؤية المشكلة. أخطط لإجراء التغييرات التي كان sercand و edevil يتلاعبان بها ومعرفة ما إذا كان هذا يناسبني في هذه الحالة.

edevil بعد النظر في الالتزام المرتبط ، هل أصحح أنك عطلت / أزلت Flannel في بيئتك تمامًا لصالح جسر cbro الذي أنشأته Kubernetes لتجاوز هذه المشكلة؟

أرى من ناحيتي أنك لن تكون قادرًا على استخدامها جنبًا إلى جنب لأن الفانيل يريد استخدام docker0 وستعمل شبكتك الداخلية على cbr0 صحيح؟

@ alph486 هذا صحيح ، لقد توقفت عن استخدام الفانيلا. يمكنني استخدام الجسر وإعداد المسارات لشبكة pod.

@ alph486 flannel لا يريد استخدام docker0. إنه مجرد الجسر الافتراضي لـ Docker ، والذي يمكنك تجاوزه بخيار docker --bridge=cbr0 .
في CoreOS ، سيتعين عليك تجاوز وحدة docker systemd.

يمكن لعلم Kubelet --experimental-flannel-overlay قراءة تكوين الفانيلا ، وتكوين جسر عامل التحميل cbr0 باستخدام نظام CIDR للفلانيل.

سيؤدي أيضًا إلى تمكين وضع promiscuous بدلاً من veth-hairpin الذي يبدو أنه المشكلة.

شكرا dadux على المدخلات. إذا كانت K8s ستلتقط واجهة cbr0 التي تم تمهيدها بالفعل بواسطة الوحدة التي تم تجاوزها ، فيمكن أن تعمل مع هذا الحل ؛ سأحاول ذلك.

وفقًا للمستندات ، يبدو أن promiscuous-bridge هو القيمة الافتراضية لـ --hairpin-mode في kubelet v1.3.4 +. ما زلت أرى المشكلة في هذا ، لذلك لست متأكدًا تمامًا من أن هذا هو الحل الكامل.

لم أتمكن من إعادة إظهار المشكلة مرة أخرى بعد استخدام المكون الإضافي للشبكة kubenet (والذي تم تعيينه ليحل محل --configure-cbr0 ). أنا نوع من تجنب الخيار flannel-overlay بسبب عدم اليقين بشأن مستقبله (يبدو أنه مرتبط بـ --configure-cbr0 ).

إذا كان يستخدم البرنامج الخفي عامل ميناء الخاص بك docker0 الجسر، ووضع --hairpin-mode=promiscuous-bridge لن يكون لها تأثير مثل kubelet سيحاول تكوين جسر موجودة الامم المتحدة cbr0 .

بالنسبة إلى CoreOS ، الحل البديل الخاص بي لعكس سلوك Kubernetes ولكن ما زلت أستخدم الفانيلا:

• قم بإضافة اتصال systemd لـ docker.service لتكوين واجهة الجسر docker0 إلى الوضع المختلط. (بالتأكيد هناك رغبة أكثر أناقة في القيام بذلك؟):

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

• أخبر kubelet بعدم تثبيت دبوس الشعر في جسر الرصيف:
  kubelet --hairpin-mode=none

يمكنك التحقق مما إذا كان دبوس الشعر ممكّنًا للواجهات الخاصة بك باستخدام
brctl showstp docker0
أو
for f in /sys/devices/virtual/net/*/brport/hairpin_mode; do cat $f; done

أعتقد أن زميلي قد أصلح هذا مؤخرًا http://www.spinics.net/lists/netdev/msg393441.html ، لقد واجهنا هذه المشكلة في بيئتنا ثم وجدنا المشكلة ، مع هذا الإصلاح ، لم نواجه هذه المشكلة أبدًا. أكثر. يمكن لأي شخص واجه هذه المشكلة تجربة هذا التصحيح ومعرفة ما إذا كان سيحدث مرة أخرى. ومن تحليلنا ، يتعلق الأمر بـ ipv6 ، لذا يمكنك أيضًا محاولة تعطيل ipv6 الخاص بـ docker بـ --ipv6=false عند بدء تشغيل docker daemon

@ coolljt0725 ربما أكون مخطئًا ، ولكن ipv6 معطل افتراضيًا في عامل الإرساء ولقد قمت للتو بإعادة إنتاج المشكلة عبر عامل الإرساء مع خيار "--ipv6 = false" (وهو الخيار الافتراضي على أي حال). لم تجرب التصحيح الخاص بك حتى الآن.

dadux شكرا لك على مساعدتك. في Kubernetes 1.3.4 CoreOS 1068 Stable و Docker 10.3 و Flannel كطبقة شبكة ، لقد أصلحت المشكلة عن طريق إجراء التغييرات التالية في وحدات CoreOS الخاصة بي:

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

تمت إضافة ما يلي إلى kubelet.service :

        --hairpin-mode=none

ما هو تأثير هذه التغييرات على Docker / Kubernetes فيما يتعلق بكيفية تعامل O / S مع واجهات الحاويات؟
يجب أن أؤكد أنها مشكلة تتعلق بسلوك O / S الخاطئ ، وليس Docker أو Kubernetes ، لأننا (وبعض الأشخاص الآخرين في هذا الموضوع) لا نشغل Docker أو Kubernetes على الإطلاق ، لكننا ما زلنا نواجه نفس المواقف تمامًا عند إيقاف LXC حاويات بسرعة كبيرة واحدة تلو الأخرى.

rdelangh أنت على صواب. ومع ذلك ، تم إنشاء هذه المشكلة في مشروع Docker لتتبع السلوك من حيث صلته بـ Docker. هناك مشكلات أخرى مذكورة في سلسلة الرسائل هذه ، وهي تتبعها كمشكلة في نظام التشغيل ، ومشكلة K8s ، ومشكلة CoreOS. إذا وجدت المشكلة في LXC أو أي شيء آخر ، فنوصيك بشدة ببدء سلسلة محادثات هناك والربط هنا لزيادة الوعي حول هذه المشكلة.

عند استخدام Docker google لهذا الخطأ ، فمن المحتمل أن يهبطوا هنا. لذلك ، من المنطقي أن ننشر حلولاً بديلة لهذه المشكلة هنا بحيث يمكن للأشخاص المضي قدمًا إلى أن يتم إصلاح المشكلات الأساسية.

ما هو تأثير هذه التغييرات على Docker / Kubernetes فيما يتعلق بكيفية تعامل O / S مع واجهات الحاويات؟

1. يسمح تغيير عامل التشغيل في رسالتي لمكدس Kubernetes باستجواب عامل الإرساء والتأكد من سلامة النظام الأساسي عند حدوث المشكلة.
2. يخبر التغيير hairpin-mode أساسي K8s باستخدام جسر docker0 كما هو ، وبالتالي لن يحاول استخدام شبكات "kernel land" و "hairpin veth" حيث تبدأ المشكلة في Docker مسار التنفيذ.

إنه حل بديل لهذه المشكلة باستخدام K8s و Docker.

تم وضع رقعة الزملاء coolljt0725 في قائمة الانتظار للحصول على مستقر ، لذلك نأمل أن يتم نقلها إلى التوزيعات في وقت قريب بما فيه الكفاية. (منشور ديفيد ميلر: http://www.spinics.net/lists/netdev/msg393688.html)

ألست متأكدًا من مكان هذا الالتزام وما إذا كان ينبغي لنا إرساله إلى Ubuntu و RH وما إلى ذلك لمساعدتهم على تعقبه وإصداره احتياطيًا؟

سأظهر هنا في وقت ما أعتقد:
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/ipv6/addrconf.c

تحرير: يبدو أنه موجود هنا: https://github.com/torvalds/linux/blob/master/net/ipv6/addrconf.c

شكرًا لك على coolljt0725 وشركائه (والجميع في هذا الموضوع). نظرًا لأن العديد من الأشخاص لن يتمكنوا من التحديث إلى kernel باستخدام تصحيح ipv6 لبعض الوقت ، فقد تمكنت (الجميع حاليًا) من سحق هذا الخطأ بعد تجربة العديد من الاقتراحات من هذا الموضوع. أرغب في إنشاء منشور كامل لمتابعة الأشياء التي نجحت ولم تنجح حتى لا يرى أي شخص آخر المشكلة التي رأيتها.

TL ؛ DR تعطيل ipv6 في معلمات تمهيد Linux ، إعادة التشغيل. على coreos ، هذا يعني أن /usr/share/oem/grub.cfg يحتوي على المحتويات: set linux_append="ipv6.disable=1" ثم إعادة التشغيل. يمكن العثور هنا على اقتراح أكثر عمومية يجب أن يعمل على centos / ubuntu / debian / $ linuxes

• جربت ipvlan (l2، l3) / macvlan (bridge): أيا من هذين العملين على aws ، أو على الأقل ، لا أمتلك ولا يمكنني العثور على المعرفة اللازمة لفشل أي منهما للعمل على AWS. من خلال العمل ، أعني ، بدء تشغيل حاوية متصلة بشبكة مع ipvlan أو macvlan ، لم يكن قادرًا على اختبار اتصال البوابة / الاتصال بالإنترنت (نعم ، لقد اختبرت الفكرة الأساسية التي تعمل في بيئة غير نظامية). يبدو أن هذا في الواقع يحل المشكلة المطروحة ، ولكن بالنسبة لحالة الاستخدام الخاصة بنا ، نحتاج إلى أن نكون قادرين على الاتصال بالإنترنت - لحالات الاستخدام التي لا تفعل ذلك ، قد يكون هذا خيارًا قابلاً للتطبيق ويبدو مثيرًا جدًا مقابل الجسر .
• جربت العلامات التالية التي تم تمريرها إلى dockerd فردي ، ومع مجموعات معينة (نظرًا لعدم نجاح أي منها ، لم أكن علميًا بشأن تجربة أي من التركيبات وجميعها):

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

من المثير للاهتمام أن --ipv6=false لا يبدو أنه يفعل أي شيء - كان هذا محيرًا للغاية ، لا تزال الحاويات تتلقى عناوين inet6 مع هذه العلامة.

يعين --userland-proxy=false وضع دبوس الشعر ولم يكن من المتوقع أن يعمل حقًا. بالتزامن مع هذا ، كان لدي بعض الأمل ولكن هذا لم يحل المشكلة ، إما (ضبط docker0 على الوضع المختلط). هناك إشارة لإصلاح --userland-proxy=false هنا وقد يكون هذا في المنبع قريبًا ويستحق لقطة أخرى ، سيكون من الجيد إيقاف تشغيل هذا بغض النظر عن الخطأ المذكور في هذه المشكلة للأداء ولكن لسوء الحظ هناك شيء آخر علة في هذا الوقت.

• حاول تعطيل ipv6 عبر إعدادات sysctl كما هو موثق هنا وإعادة تشغيل systemd-networkd بعد تطبيق إعدادات sysctl ، وكذلك محاولة تعطيل ipv6 من dhcpcd كما هو موثق هنا ولم يكن هذا كافياً لتعطيل ipv6 لأنه لا يزال قيد التشغيل ، حتى لو لم تكن هناك واجهات. استخدامه.
• كما تم اقتراحه هنا ، قمنا بتجربة هذا الحل ، وإزالة حاوية واحدة فقط في كل مرة ، وما زلنا نواجه هذا الخطأ.

طويل جدا؛ قرأ: تعطيل ipv6 في إعدادات اليرقة الخاصة بك. اعادة التشغيل. ربح.

واجهت هذه المشكلة على CentOS 7.2 (3.10.0-327.28.3.el7.x86_64) و Docker 1.12.1 (w / o k8s). تنشأ المشكلة عندما تزداد حركة مرور الشبكة.
تمهيد kernel مع تعطيل ipv6 (وفقًا للنصيحة السابقة) لم يساعد.
لكن تحويل واجهة docker0 إلى الوضع المختلط قد أصلح هذا. تم استخدام نظام تسجيل الدخول بواسطة dadux (شكرًا لك!) - يبدو أنه يعمل بشكل جيد الآن.

rdallman لا يمنع إلغاء تنشيط ipv6 عبر اليرقة unregister_netdevice بالنسبة لي في ubuntu 16.06 (kernel 4.4.0-36-generic) أو 14.04 (kernel 3.13.0-95-generic). بغض النظر عن إعداد --userland-proxy (سواء أكان صحيحًا أم خطأ).

Ooooh ، هذا رائع ، تم وضع التصحيح في قائمة الانتظار للحصول على مستقر.
pingaboch لمشكلة أن --ipv6=false لا يفعل شيئًا.

@ trifle آسف :( شكرًا لنشر المعلومات ، لم نواجه مشكلات بعد بضعة أيام من الاختبار ولكننا سنقوم بالتحديث مرة أخرى إذا واجهتنا أية مشكلات. نحن نشغل coreos 1122.2 (kernel 4.7.0). تعيين docker0 على الوضع المختلط يبدو أنه يصلح هذا لبعض الأشخاص (لا حظ لنا).

RRAlex هل تعرف ما إذا كان أي شخص قد تواصل مع فريق Ubuntu kernel بخصوص

القائمة البريدية لفريق Ubuntu kernel:
https://lists.ubuntu.com/archives/kernel-team/2016-September/thread.html

التصحيح للنواة المستقرة:
https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d

سجل التزام Ubuntu kernel:
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/؟h=master-next
(التصحيح ليس هناك بعد)

leonsp لقد حاولت الاتصال بهم بشأن ما يبدو أنه المشكلة ذات الصلة:
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1403152

إذا نظرت إلى الرد الأخير (رقم 79) ، فقد قام شخص ما ببناء نواة لـ Xenial باستخدام هذا التصحيح:
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1403152

لست متأكدًا من الوقت الذي يتم فيه الانتقال في شجرة نواة Ubuntu الرئيسية ولا ما هي علاقة هذا الشخص بـ Ubuntu وما إذا كان ذلك سيساعد ...

لا يمكنني أيضًا العثور على الالتزامات المذكورة من هذا الموضوع في سجل التزام Ubuntu kernel.

RRAlex الالتزامات المذكورة موجودة على فرع ddstreet ~ ddstreet / + git / linux: lp1403152-xenial ، هذا هو السجل: https://code.launchpad.net/~ddstreet/+git/linux/+ref/lp1403152-xenial
لذلك ، يمكن لأي شخص لديه هذه المشكلة على Ubuntu 16.04 أن يجربها. https://launchpad.net/~ddstreet/+archive/ubuntu/lp1403152

ربما يعرف sforshee (لنواة أوبونتو)

لقد تمكنت أخيرًا من اختبار حل "ipv6.disable = 1". بالإضافة إلى ذلك - لقد قمت بالترقية إلى 4.7.2 kernel على debian 8 الخاص بي.
بعد ترقية kernel وتمكين "ipv6.disable = 1" في معلمات kernel ، تمكنت من التقاط مشكلة "انتظار lo" في عبء العمل الحقيقي حتى بدون علامة "--userland-proxy = false" لشيطان عامل الإرساء. الخبر السار هو أنه بعد تحديد "--userland-proxy = false" ومحاولة إعادة إنتاج المشكلة باستخدام "Docker-Stress" - لم يعد بإمكاني فعل ذلك. لكنني متأكد من أنها ستظهر مرة أخرى بغض النظر عن قيمة "--userland-proxy".
لذا مما أراه - IPv6 متورط بالتأكيد في هذه المشكلة ، لأنه الآن لم يعد ضغط عامل التحميل قادرًا على اكتشاف المشكلة. النبأ السيئ هو أن المشكلة لا تزال موجودة بالفعل (أي: تم حلها جزئيًا فقط).

سيتم تجميع أحدث 4.8rc7 لاحقًا لاختبار المزيد.

@ twang2218 @ coolljt0725

حسنًا .. لقد جربت للتو نواة Ubuntu xenial 4.4.0-36 مع التصحيح الخلفي من

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

لسوء الحظ ، لا يبدو أن هذا يحل المشكلة بالنسبة لي. لاحظ أنني أستخدم أيضًا "ipv6.disable = 1". هل ننظر إلى أسباب متعددة غير مرتبطة بنفس النتيجة؟ يبدو أن العديد من التعليقات في هذا الموضوع تشير إلى ذلك.

لا أعرف الكثير عن هذه الأشياء ، لكنني أعلم أن لدينا أخطاء مثل هذه من قبل. كما أفهمها ، ينتهي الأمر بنقل عدد المراجع إلى أي جهاز شبكة إلى lo عندما يتم تنظيف مساحة اسم الشبكة ، لذا فإن عبارة "انتظار lo لتصبح مجانية" تعني أن هناك تسريبًا للعدد المرجعي لبعض أجهزة الشبكة ولكن ليس بالضرورة لـ lo مباشرة. هذا يجعل هؤلاء دبًا يتعقبون ، لأنه بحلول الوقت الذي تعلم فيه أن هناك تسريبًا ، لا تعرف الجهاز المرتبط به.

لم أقرأ جميع التعليقات مرة أخرى ، ولكن إذا كان بإمكان شخص ما إعطائي منتجًا موثوقًا به على Ubuntu ، فسوف ألقي نظرة عليه وأرى ما إذا كان بإمكاني اكتشاف أي شيء.

sforshee ليس من السهل دائمًا إعادة الإنتاج ، ولكن كان هناك تصحيح تم إنشاؤه (يعمل على الأقل على إصلاح بعض الحالات المبلغ عنها هنا) ؛ http://www.spinics.net/lists/netdev/msg393441.html. تم قبول ذلك في المنبع https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d

haJeztah آه ، أرى السؤال الذي كنت

لذا فإن التصحيح موجود في قائمة الانتظار المنبع 4.4 المستقرة ، بالنسبة لـ 16.04 من المحتمل أن يتم تضمينه ليس في وحدة SRU التالية للنواة (والتي هي قيد التقدم بالفعل) ولكن بعد ذلك ، بعد حوالي 5-6 أسابيع من الآن. إذا كان مطلوبًا في 14.04 أيضًا ، فيرجى إبلاغي بذلك حتى يمكن نقله إلى الخلف.

sforshee بشكل أساسي سابقًا (قبل هذا التصحيح) والذي يمكن إعادة إنتاجه عن طريق تمكين ipv6 في kernel (يتم تمكينه افتراضيًا عادةً) ، وإضافة "--userland-proxy = false" إلى أعلام docker daemon ثم تشغيل docker-stress -c 100 ، من أجل مثال (عامل الضغط من هنا: https://github.com/crosbymichael/docker-stress)

fxposter شكرا. إذا كان هناك إصلاح لذلك على الرغم من أن كل ما أحتاج إلى القلق بشأنه هو الحصول على هذا الإصلاح في نواة Ubuntu. يمكنني أيضًا المساعدة في البحث في التسريبات الأخرى التي لم يتم إصلاحها بواسطة هذا التصحيح.

أواجه هذه المشكلة أيضًا. أنا أقوم بتشغيل عامل إرساء داخل صندوق rancherOS من AWS. في الواقع ، يحدث ذلك بشكل عشوائي بعد إعداد مجموعة مزرعة (3 مضيفين) وتشغيل تطبيق صغير فيه.

نفس ... فيدورا 24 ، يحدث بشكل عشوائي ، يمكن أن يكون جيدًا لمدة أسبوع ، مما أحصل عليه كل 10 ساعات
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

تجربة على CentOS 7 تشغيل kernel 3.10.0-327.36.1.el7 و docker 1.12.1

يبدو أن الرجوع إلى kernel 3.10.0-327.18.2.el7 مع بقائه على Docker 1.12.1 قد أدى إلى استقرار النظام.

أرى هذا أيضًا:
إصدار Docker 1.11.2
نظام التشغيل Ubuntu 16.04.1 4.4.0-38-generic

ipv6 معطل (نكش)

حدثت هذه المشكلة للتو بدون --userland-proxy=false (كذا!) على الخادم مع kernel 4.8.0-rc7 ، والذي يتضمن تصحيح ipv6 (كذا !!). لذلك ربما يتم إصلاح بعض المشاكل ، ولكن ليس كلها بالتأكيد.

هل يعرف أحد كيف يمكن تصحيح هذا على الإطلاق؟

اكتشفنا أن هذا يحدث فقط في الإعداد الخاص بنا عندما (تقريبًا) تنفد الذاكرة الخالية لدينا.

fxposter قد يكون من المفيد العثور على الحد الأدنى من حالات التكاثر ، وهو أمر صعب نوعًا ما: / ثم يمكننا استخدام ftrace للعثور على مسارات الكود على الأقل.

يحدث على CoreOS 1081.5.0 (4.6.3-coreos)

Linux blade08 4.6.3-coreos #2 SMP Sat Jul 16 22:51:51 UTC 2016 x86_64 Intel(R) Xeon(R) CPU X5650 @ 2.67GHz GenuineIntel GNU/Linux

@ LK4D4 للأسف لم يعد من الممكن إعادة إنتاجه عبر ضغط عامل التحميل (على الأقل لم أستطع). سأحاول محاكاة إعدادنا السابق باستخدام مجموعات الويب (التي تسببت في حدوث هذه المشكلة في كثير من الأحيان أكثر مما أريد).

fxposter يعمل هذا التصحيح فقط على إصلاح بعض المشكلات (ولكن في بيئتنا ، لم نواجهها بعد الآن مع هذا التصحيح) ، وليس كل شيء ،

الإصلاح في 4.4.22 مستقر https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.22

لقد أرسلت طلبًا إلى Redhat لتطبيق هذا التصحيح على Fedora 24.

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

4.4.0-42 لا يزال مكسورًا بالتأكيد ...
لقد ذكرتها هنا لـ Ubuntu ، ولكن ربما يكون لدى شخص ما فكرة أفضل:
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1403152

أرى هذا أيضًا ، إصدار Docker 1.11.2 ، إصدار b9f10c9 / 1.11.2 ، 64 بت Amazon Linux 2016.03 v2.1.6.

لا يزال يحدث. docker 1.12.2 ، armbian linux kernel 4.8.4 ، ipv6.disable = 1 في bootargs

كيف أصلح الخلل ، ألتقي به كل يوم

woshihaoren لا تستخدم --userland-proxy=false

للتوضيح - واجهنا الأمر مع تعطيل وكيل أرض المستخدم أيضًا

الحصول على هذا في Amazon Linux AMI 2016.9:

$ uname -a

Linux 4.4.23-31.54.amzn1.x86_64 #1 SMP

إصدار عامل ميناء:

العميل:
الإصدار: 1.11.2
إصدار API: 1.23
إصدار Go: go1.5.3
Git الالتزام: b9f10c9 / 1.11.2
مبني:
OS / Arch: لينكس / amd64

الخادم:
الإصدار: 1.11.2
إصدار API: 1.23
إصدار Go: go1.5.3
Git الالتزام: b9f10c9 / 1.11.2
مبني:
OS / Arch: لينكس / amd64
""

نواة centos7 4.4.30 مرة أخرى ~~~~

CoreOS 1185.3.0 و 4.7.3-coreos-r2 و Docker 1.11.2
قابل لإعادة الإنتاج بمجرد تشغيل 10..20 debian: jessie container مع "apt-get update" كأمر.

لا يزال CoreOS المستقر مضروبًا حاليًا. إصلاح السلسلة 4.7 في 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 - لا توجد حلول في هذا المنشور ، لكني أدرج ما طاردته حتى الآن ونظريات عملي الحالية. آمل أن يجد الأشخاص الآخرون الذين يطاردون هذا أيضًا بعض المعلومات هنا مفيدة أثناء تشغيلنا لهذا الشيء.

koendc شكرًا لنشر التصحيح الذي تم تقديمه في 4.7.5. أعدت تصحيح 4e1b3aa898ea93ec10e48c06f0e511de37c35b2d (المنبع 751eb6b6042a596b0080967c1a529a9fe98dac1d) إلى إعداد 4.5.5 [1] وتمكنت من إعادة إنتاج مشكلة جهاز unregister_netdevice بسهولة. من الممكن أن تعمل التغييرات الأخرى في 4.7.x kernel مع التصحيح المقدم لحل هذه المشكلة ، لكنني لم أقم بتأكيد ذلك بعد ، لذلك لا ينبغي أن نفقد كل الأمل بعد. أقوم باختبار 4.5.5 لأن لدي حالة اختبار قابلة للتكرار تسبب المشكلة ، تمت مناقشتها في [2].

أشياء أخرى أكدتها بناءً على الاختبار:

• 4.2 أكثر استقرارًا من أي نواة لاحقة
• 4.5.x قابل للتكرار بشكل تافه. من بين النوى الأحدث التي اختبرتها على نطاق واسع (4.8.2 و 4.8.6) ، لا تزال المشكلة موجودة ، على الرغم من أن وقت الظهور الأول يتراوح بين 60 و 48 ساعة
• يبدو أن المشكلة مرتبطة بحركة مرور الشبكة ونسبة الحاويات إلى سعة المورد الرئيسي (وحدة المعالجة المركزية الافتراضية). كما استعصى الآخرون ، قد يكون هذا مضارًا إذا كانت هذه بالفعل حالة عرقية

الخطوات التالية:

• صك نواة بعبارات printk المناسبة لمحاولة العثور على حالة لا يتم فيها تحرير الموارد المخصصة
• اختبر النواة 4.7.5 أو الأحدث مع / بدون التصحيح المذكور أعلاه لمعرفة ما إذا كانت المشكلة ستحدث
• قبل إحدى الحوادث مباشرة ، رأيت مجموعة مثيرة جدًا من الأخطاء IPv6: eth0: IPv6 duplicate address <blah> detected . قد يكون هذا نوعًا من الرنجة الحمراء الأخرى ، لكنني أريد أن أحاول ممارسة تعطيل IPv6 لمعرفة ما إذا كان هناك ارتباط

[1] الإعداد الكامل الخاص بي هو فضيلة GCE التي تدير نواة دبيان مخصصة قليلاً بناءً على 4.5.5 . Docker version 1.8.3, build f4bf5c7 يعمل فوق ذلك
[2] معلومات حالة الاختبار: لدي 20 عملية متوازية ، كل منها تبدأ خادم Node.js hello world داخل حاوية عامل إرساء. بدلاً من إرجاع hello world ، يقوم خادم Node.js بإرجاع 1 ميغابايت من النص العشوائي. العملية الرئيسية في حلقة ضيقة تبدأ الحاوية ، وتجعيد الشعر لاسترداد 1 ميغابايت من البيانات ، وتوقف الحاوية. باستخدام هذا الإعداد ، يمكنني إعادة إنتاج المشكلة باستمرار في 4-90 ثانية. لا يؤدي استخدام هذا الإعداد نفسه على مضيف فعلي أو داخل Virtualbox إلى إعادة إنتاج المشكلة ، على الرغم من اختلاف العناصر التي تغير متوسط ​​وقت الاستنساخ في مربع GCE. المتغيرات التي كنت ألعب بها: عدد عمليات الاختبار المتزامنة ، وحجم الحمولة المنقولة ، وكمية مكالمات curl. المتغيرين الأولين مرتبطان بالتأكيد ، على الرغم من أنني أعتقد أنه من المحتمل فقط تعديل المتغيرات من أجل إيجاد نقطة تشبع معقولة للفضيلة.

أنا أيضا أواجه هذا الخطأ.

أراه يتكرر 3 مرات بعد نشر الحاوية.

وصف

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

خطوات إعادة إظهار المشكلة:

1. ssh في مضيف عامل ميناء
2. قم بتشغيل حاوية

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

صِف النتائج التي تلقيتها:

فقط احصل على الخطأ يتكرر 3 مرات.

صِف النتائج التي توقعتها:
لا خطأ

معلومات إضافية تعتبرها مهمة (على سبيل المثال ، تحدث المشكلة من حين لآخر فقط):
بدأت للتو في الحدوث بعد نهاية هذا الأسبوع.

ناتج docker version :

 docker --version
Docker version 1.12.3, build 6b644ec

الناتج docker info :

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

تفاصيل إضافية عن البيئة (AWS و VirtualBox والمادية وما إلى ذلك):

آلة افتراضية:
فيدورا 24
OverlayFS2 على ext3

محرك منفصل مخصص لرسو السفن استخدام 24 عربة.
16 جيجا من الكبش.

Docker PS

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

صور عامل ميناء

 docker 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

حجم عامل الإرساء Ls

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

* DF -H *

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

DF -i

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

مجاني -lmh

free -lmh
              total        used        free      shared  buff/cache   available
Mem:            15G        3.0G         10G         19M        2.7G         12G
Low:            15G        5.6G         10G
High:            0B          0B          0B
Swap:          1.2G          0B        1.2G

لأي من المهتمين ، نحن (Travis CI) نطرح ترقية إلى v4.8.7 على Ubuntu 14.04. أظهرت اختبارات الحمل الخاصة بنا عدم حدوث أي خطأ موصوف هنا. في السابق ، كنا نشغل linux-image-generic-lts-xenial على Ubuntu 14.04. أخطط لنشر منشور مدونة في المستقبل القريب يصف المزيد من التفاصيل.

تحديث : كان يجب أن أذكر أننا نشغل مكدس عامل الإرساء هذا:

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

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

تحديث : ما زلنا نشهد هذا الخطأ في الإنتاج على Ubuntu Trusty + kernel v4.8.7. لا نعرف حتى الآن سبب اختفاء هذه الأخطاء في اختبارات الحمل المرحلية التي أعادت إنتاج الخطأ سابقًا ، ومع ذلك فإن معدل الخطأ في الإنتاج هو نفسه فعليًا. إلى الأمام وإلى الأعلى. لقد قمنا بتعطيل "الانفجار الداخلي التلقائي" بناءً على هذا الخطأ نظرًا لارتفاع معدل دوران المثيل .

وجدت أيضا في سنتوس 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

نفس الشيء يحدث هنا مع DigitalOcean VPS في اختبار دبيان:

# journalctl -p0 | tail -15

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

نظام

$ apt list --installed 'linux-image*'
Listing... Done
linux-image-3.16.0-4-amd64/now 3.16.36-1+deb8u2 amd64 [installed,local]
linux-image-4.8.0-1-amd64/testing,now 4.8.5-1 amd64 [installed,automatic]
linux-image-amd64/testing,now 4.8+76 amd64 [installed]

$ apt list --installed 'docker*'
Listing... Done
docker-engine/debian-stretch,now 1.12.3-0~stretch amd64 [installed]
N: There are 22 additional versions. Please use the '-a' switch to see them.

$ uname -a
Linux hostname 4.8.0-1-amd64 #1 SMP Debian 4.8.5-1 (2016-10-28) x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux testing (stretch)
Release:    testing
Codename:   stretch

$ docker info

Containers: 1
 Running: 1
 Paused: 0
 Stopped: 0
Images: 42
Server Version: 1.12.3
Storage Driver: devicemapper
 Pool Name: docker-254:1-132765-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: ext4
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 435 MB
 Data Space Total: 107.4 GB
 Data Space Available: 16.96 GB
 Metadata Space Used: 1.356 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.146 GB
 Thin Pool Minimum Free Space: 10.74 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.136 (2016-11-05)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.8.0-1-amd64
Operating System: Debian GNU/Linux stretch/sid
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 996.4 MiB
Name: hostname
ID: <redacted>
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 127.0.0.0/8

$ docker ps -a

CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS                              NAMES
0b54ed86ba70        squid/production    "/usr/sbin/squid -N"   29 hours ago        Up 29 hours         0.0.0.0:8080-8081->8080-8081/tcp   squid

$ ip link show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether de:ad:be:ff:ff:ff brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether de:ad:be:ff:ff:ff brd ff:ff:ff:ff:ff:ff
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether de:ad:be:ff:ff:ff brd ff:ff:ff:ff:ff:ff
234: veth64d2a77<strong i="12">@if233</strong>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default 
    link/ether de:ad:be:ff:ff:ff brd ff:ff:ff:ff:ff:ff link-netnsid 1

# ifconfig

docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 0.0.0.0
        inet6 dead::beef:dead:beef:ffff  prefixlen 64  scopeid 0x20<link>
        ether de:ad:be:ef:ff:ff  txqueuelen 0  (Ethernet)
        RX packets 3095526  bytes 1811946213 (1.6 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2642391  bytes 1886180372 (1.7 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 123.45.67.89  netmask 255.255.240.0  broadcast 123.45.67.89
        inet6 dead::beef:dead:beef:ffff  prefixlen 64  scopeid 0x0<global>
        inet6 dead::beef:dead:beef:ffff  prefixlen 64  scopeid 0x20<link>
        ether dead::beef:dead:beef:ffff  txqueuelen 1000  (Ethernet)
        RX packets 3014258  bytes 2087556505 (1.9 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3453430  bytes 1992544469 (1.8 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 178  bytes 15081 (14.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 178  bytes 15081 (14.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth64d2a77: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 dead::beef:dead:beef:ffff  prefixlen 64  scopeid 0x20<link>
        ether d2:00:ac:07:c8:45  txqueuelen 0  (Ethernet)
        RX packets 1259405  bytes 818486790 (780.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1103375  bytes 817423202 (779.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

لقد قمت باختبار 4.8.8 في حلقة ضيقة (انظر [2] من تعليقي السابق لحالة الاختبار) بدون توقف خلال الأيام الأربعة الماضية. حتى الان جيدة جدا.

حقائق

• التصحيح 751eb6b6 يقلل بشكل كبير من حدوث هذه المشكلة ، لكنه لا يقضي عليها تمامًا.

الافتراضات
أشار meatballhat إلى أن خوادم الإنتاج الخاصة بهم واجهت المشكلة أثناء تشغيل 4.8.7. هذا يترك لنا احتمالين:

• حالة الاختبار الخاصة بي معيبة (الاحتمال الأكبر)
• قدم 4.8.8 إصلاحًا. بالنظر إلى سجل التغيير 4.8.8 ، يشير كل من ارتكاب 5086cadf و 6fff1319 إلى مشكلات netdev التي تم حلها. لا أحد يذكر المشكلة صراحةً هنا ، لكن كلاهما قريب بما يكفي للشك.

هل يمكننا إقناع بعض الأشخاص بتجربة 4.8.8 لمعرفة ما إذا كانوا قادرين على إعادة إنتاج هذه المشكلة؟

reshen سأقوم

reshen بحث ممتاز. حتى الآن لم أتمكن أيضًا من إعادة إنتاج المشكلة باستخدام Linux 4.8.8 على Xubuntu 16.04.

لقد كنت أستخدم بنيات نواة Ubuntu الرئيسية . ليس لدي حالة اختبار محددة جيدًا ، ولكن يمكنني إعادة إنتاج المشكلة باستمرار من خلال بدء وإيقاف مجموعة حاويات عامل الإرساء التي أعمل بها.

لاختبار Linux 4.8.8 ، كان الأسهل بالنسبة لي هو التبديل من aufs إلى overlay2 كمشغل تخزين حيث أن إصدارات kernel الرئيسية لم تتضمن aufs. لا أعتقد أنه سيؤثر على الاختبار ، لكن يجب ملاحظته.

في الماضي ، قمت باختبار Linux 4.4.4 مع 751eb6b6 backportman بواسطة Dan Streetman ، لا يبدو أن هذا يقلل من المشكلة بالنسبة لي. سيكون من المثير للاهتمام معرفة ما إذا كان نقل البقعين اللذين لاحظتهما (5086cadf و 6fff1319) يمكن أن يعطي نفس النتيجة مثل 4.4.8.

Ubuntu 16.04 مع 4.4.0-47 كان لا يزال متأثرًا ... محاولة 4.4.0-49 الآن ، سيتم الإبلاغ عنه لاحقًا.

تحرير: 2016-11-28: -49 هو موقع يظهر أن سطر السجل في dmesg.

جربت ذلك على Fedora 25 (kernel 4.8.8) و Docker 1.12.3

لمعلوماتك: لقد قمنا بتشغيل Linux 4.8.8 بالتزامن مع Docker v1.12.3 على مضيف إنتاج واحد. يبلغ وقت التشغيل حاليًا 5.5 يومًا ويظل الجهاز ثابتًا.

نرى أحيانًا عددًا قليلاً من رسائل unregister_netdevice: waiting for lo to become free. Usage count = 1 في سجل النظام ، ولكن بخلاف ما سبق ، لا تتعطل النواة وتختفي الرسالة. أظن أن أحد التغييرات الأخرى التي تم إدخالها إما في Kernel أو في Docker يكتشف هذه الحالة ويتعافى منها الآن. بالنسبة لنا ، هذا الآن يجعل هذه الرسالة مزعجة ولكنها لم تعد خطأ فادحًا.

آمل أن يتمكن بعض الأشخاص الآخرين من تأكيد ما ورد أعلاه في أساطيل الإنتاج الخاصة بهم.

gtirloni - هل يمكنك توضيح ما إذا كان جهازك 4.8.8 / 1.12.3 قد تعطل أو إذا رأيت الرسالة للتو؟

شكرًا مقدمًا لكل من عمل على إعادة إنتاج / توفير معلومات مفيدة لتثليث هذا الشيء.

نحذف النظير لواجهة veth (docker0) بعد بدء تشغيل docker وإعادة تشغيل docker بعد ذلك عندما نقوم بتوفير المضيف باستخدام ansible. لم تحدث المشكلة منذ ذلك الحين.

أحصل أيضًا على نفس الخطأ في Raspberry Pi 2 الذي يعمل على Raspbian مع Docker.

معلومات Kernel
Linux rpi2 4.4.32-v7+ #924 SMP Tue Nov 15 18:11:28 GMT 2016 armv7l GNU/Linux

معلومات عامل الميناء

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

حدث ذلك بعد إنشاء حاوية تحتاج إلى تثبيت حوالي 50 ميغابايت من البرامج التي تم تنزيلها.

فقط إعادة التشغيل ستسمح لي باستخدام الجهاز مرة أخرى

أرى هذا في الواقع على Amazon Linux في مجموعة ECS - يتم إلقاء الرسالة من حين لآخر ولكنها لا تغلق ، مثل رؤية reshen الآن. Docker 1.11.2.0 تحديث تقارير Uname "4.4.14-24.50.amzn1.x86_64" هي الإصدار.

@ تحديث ، سأقوم ببناء 4.8.8 في نهاية هذا الأسبوع على الكمبيوتر المحمول الخاص بي ومعرفة ما إذا كان ذلك
يصلح لي!
ᐧ

يوم الخميس ، 1 كانون الأول (ديسمبر) 2016 ، الساعة 10:29 صباحًا ، إرنست مولر إخطارات github.com
كتب:

أرى هذا في الواقع على Amazon Linux في مجموعة ECS - الرسالة
رميات من حين لآخر لكنها لا تغلق ، مثل رؤية ريشن الآن.
Docker 1.11.2.0 تحديث تقارير Uname "4.4.14-24.50.amzn1.x86_64" هي الإصدار.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/docker/issues/5618#issuecomment-264220432 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AKklVRqoBUZDu3HMhGv3b6knnA6j6C_Qks5rDvXRgaJpZM4B4L4Z
.

-
كيفر فورزلاند
http://kfrz.work

لقد تمكنت أيضًا من إعادة إنتاج هذه المشكلة باستخدام https://github.com/crosbymichael/docker-stress على عقدة عامل Kubernetes تشغل CoreOS Stable 1185.3.0.

تشغيل docker_stress_linux_amd64 -k 3s -c 5 --containers 1000 : 5 عمال متزامنين ينشئون / يحذفون الحاويات ، وأقصى عمر للحاويات = 3 ثوانٍ ، وإنشاء ما يصل إلى 1000 حاوية على مثيل كبير m4. على AWS سيترك Docker daemon غير مستجيب بعد حوالي ثلاث دقائق.

تمت الترقية إلى CoreOS Beta 1235.1.0 ولم أتمكن من إعادة الإنتاج (كلا من عدم الاستجابة أو الرسالة unregister_netdevice في سجلات kernel). في حين أن تشغيل 5 عمال متزامنين في docker_stress سيقتل CoreOS Stable بعد بضع دقائق ، فقد تمكنت من تشغيل 10 و 15 عاملاً متزامنًا حتى اكتمال الاختبار باستخدام CoreOS Beta.

يتم إصدار CoreOS في "القنوات" لذلك لا يمكن ترقية النواة بمعزل عن غيرها. فيما يلي الاختلافات الرئيسية بين المستقر وبيتا:

CoreOS Stable 1185.3.0

النواة: 4.7.3

عامل ميناء: 1.11.2

CoreOS Beta 1235.1.0

النواة: 4.8.6

عامل ميناء: 1.12.3

رؤية هذه المشكلة على Amazon Elastic Beanstalk الذي يعمل بنظام 4.4.23-31.54.amzn1.x86_64

حدث للتو على CoreOS Stable 1185.5.0 ، Docker 1.12.2
بعد إعادة التشغيل كل شيء على ما يرام

تحديث: ظهرت مشكلة Docker daemon المعلقة مرة أخرى على مضيف يقوم بتشغيل CoreOS Beta 1235.1.0 مع Docker v1.12.3 و Linux kernel v4.8.6. 😢

1.12.4 و 1.13 ، من الناحية النظرية ، يجب عدم تجميدهما عند إصابة مشكلة النواة هذه.
سبب التجميد في Docker daemon هو أن البرنامج الخفي ينتظر رسالة netlink مرة أخرى من kernel (والتي لن تأتي أبدًا) أثناء الإمساك بالقفل على كائن الحاوية.

حدد 1.12.4 و 1.13 مهلة على طلب netlink هذا لتحرير قفل الحاوية على الأقل.
هذا لا يحل المشكلة ، ولكن على الأقل (نأمل) لا يجمد البرنامج الخفي بالكامل.
من المحتمل ألا تكون قادرًا على تدوير حاويات جديدة ، وبالمثل لن تكون قادرًا على هدمها لأنه يبدو أن جميع التفاعلات مع netlink stall بمجرد حدوث هذه المشكلة.

@ cpuguy83 FWIW ، أي حاويات قيد التشغيل تستمر في العمل بدون إصدار AFAIK عند تعليق البرنامج الخفي. في الواقع ، يعد بدء وإيقاف الحاويات أمرًا ملحوظًا (لا سيما التشغيل على Kubernetes ، كما نحن).

هذا لا يحل المشكلة ، ولكن على الأقل (نأمل) لا يجمد البرنامج الخفي بالكامل.

الجانب الإيجابي في تجميد البرنامج الخفي بالكامل هو أنه من السهل اكتشافه. يمكن لـ Kubernetes طرد العقدة ، وربما حتى إعادة التشغيل تلقائيًا. هل يجب أن يستمر البرنامج الخفي في العمل ، هل سيظل من الممكن العثور بسهولة على مشكلة kernel التي ظهرت على الإطلاق؟

seanknox يمكنني تزويدك بـ CoreOS 1248.1.0 AMI مخصص مع Docker مصحح (CoreOS Docker 1.12.3 + Upstream 1.12.4-rc1 Patches). لقد أصلحت حالات انقطاع الاتصال كل ساعتين على مجموعات CoreOS / K8s الخاصة بي. فقط أرسل لي معرّف حساب AWS الخاص بك على Deis Slack.

لقد شعرنا بألم كبير مع هذه المشكلة في مجموعة CoreOS الخاصة بنا. هل يمكن لأي شخص أن يخبرنا متى سيتم إصلاحه أخيرًا؟ نحلم بهذه اللحظة عندما نتمكن من النوم ليلا.

DenisIzmaylov إذا لم تقم بتعيين --userland-proxy=false ، فعندئذٍ بشكل عام لا يجب أن تواجه هذه المشكلة.

لكن بخلاف ذلك ، هذا خطأ في النواة ، ربما أخطاء نواة متعددة ، يقول البعض إنه تم حلها في 4.8 والبعض الآخر يقول لا. بالنسبة للبعض ، يبدو أن تعطيل ipv6 يعمل على إصلاحه ، والبعض الآخر ليس كذلك (ومن ثم ربما تكون هناك مشكلات متعددة ... أو على الأقل أسباب متعددة).

لقد رأيت هذه المشكلة في غضون ساعات على أنظمة تحميل عالية وبدونها --userland-proxy=false

تم التأكيد على أننا ما زلنا نرى أخطاء unregister_netdevice على kernel 4.8.12 . يستغرق الأمر حوالي 5 أيام للتشغيل. يبدو أن إعادة تشغيل النظام فقط يتعافى من المشكلة. يبدو أن إيقاف Docker معلق إلى أجل غير مسمى.

لم تجرب خدعة تعطيل ipv6 لتمهيد kernel حتى الآن.

Containers: 17
 Running: 14
 Paused: 0
 Stopped: 3
Images: 121
Server Version: 1.10.3
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 4.8.12-1.el7.elrepo.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 24
Total Memory: 62.86 GiB
Name: **REDACTED***
ID: **REDACTED***
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

سيكون رائعًا إذا كان بإمكان شخص ما تجربة ذلك باستخدام 1.12.5 ، والتي يجب أن تنتهي مهلة طلب netlink العالق الآن بدلاً من مجرد تعليق Docker.

@ cpuguy83 ومع ذلك ، لا يزال النظام غير قابل للاستخدام في تلك الحالة :)

@ LK4D4 أوه ، تمامًا ، أريد فقط رؤية تلك المهلات ؛)

الحصول على هذه المشكلة على Cent OS 7:

kernel: unregister_netdevice : انتظار lo لتصبح حرة. عدد الاستخدام = 1

Linux foo 3.10.0-514.2.2.el7.x86_64 # 1 SMP الثلاثاء 6 ديسمبر 23:06:41 بالتوقيت العالمي المنسق 2016 x86_64 x86_64 x86_64 جنو / لينكس

محرك عامل ميناء 1.12.5-1.el7.centos.x86_64

هذا يؤثر على تصميمات CI الخاصة بي التي تعمل داخل حاويات Docker ويبدو أنها تحتضر فجأة والتي تظهر خلالها رسالة وحدة التحكم هذه. هل هناك حل أو حل بديل؟ شكرا!

@ cpuguy83 لا يتعطل Docker بالنسبة لي عند حدوث هذا الخطأ ولكن يتم قتل الحاويات وهو ما يؤدي في وضعي إلى كسر وظائف Jenkins / CI الخاصة بي.

لذلك كنت أقوم بتشغيل Docker على جهاز centos 7 لفترة (11 شهرًا؟) دون مشكلة. قررت اليوم أن أجرب البرنامج الخفي للاستماع tcp ( أضف عنوان استماع tcp إلى / etc / sysconfig / docker ) وحصلت للتو على هذا الخطأ.

kernel: unregister_netdevice : انتظار lo لتصبح حرة. عدد الاستخدام = 1

لذا فإن عدد استخداماتي ليس 3.

الحاويات: 4
الجري: 3
متوقف مؤقتًا: 0
متوقف: 1
الصور: 67
إصدار الخادم: 1.10.3
سائق التخزين: btrfs
نسخة الإصدار: Btrfs v4.4.1
إصدار المكتبة: 101
سائق التنفيذ: أصلي -0.2
برنامج تشغيل التسجيل: ملف json
الإضافات:
الحجم: محلي
الشبكة: مضيف جسر فارغ
إصدار النواة: 3.10.0-514.2.2.el7.x86_64
نظام التشغيل: CentOS Linux 7 (Core)
OSType: لينكس
العمارة: x86_64
عدد خطاطيف الإرساء: 2
وحدات المعالجة المركزية: 24
إجمالي الذاكرة: 39.12 جيجابايت
الاسم: aimes-web-encoder
المعرّف: QK5Q: JCMA: ATGR : ND6W: YOT4: PZ7G: DBV5: PR26: YZQL: INRU : HAUC: CQ6B
السجلات: docker.io (آمن)

3.10.0-514.2.2.el7.x86_64 # 1 SMP الثلاثاء 6 ديسمبر 23:06:41 بالتوقيت العالمي المنسق 2016 x86_64 x86_64 x86_64 جنو / لينكس

عميل:
الإصدار: 1.10.3.1
إصدار API: 1.22
إصدار الحزمة: docker-common-1.10.3-59.el7.centos.x86_64
إصدار Go: go1.6.3
Git الالتزام: 3999ccb-unsupported
بني: الخميس 15 ديسمبر 17:24:43 2016
OS / Arch: لينكس / amd64

الخادم:
الإصدار: 1.10.3.1
إصدار API: 1.22
إصدار الحزمة: docker-common-1.10.3-59.el7.centos.x86_64
إصدار Go: go1.6.3
Git الالتزام: 3999ccb-unsupported
بني: الخميس 15 ديسمبر 17:24:43 2016
OS / Arch: لينكس / amd64

أستطيع أن أؤكدaamerik. أرى نفس المشكلة على إصدار kernel نفسه. لم تحدث تغييرات كبيرة مؤخرًا على النظام ، مع رؤية هذه المشكلة منذ اليوم.

رأيت نفس الرسالة kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1 على جهاز CentOS 7 الخاص بي وهو يشغّل صورة عامل إرساء لـ Jenkins. كان جهاز CentOS 7 الذي كنت أستخدمه حديثًا مع أحدث تصحيحات CentOS 7 اعتبارًا من 20 ديسمبر 2016 تقريبًا.

نظرًا لأن أحدث المراجع هنا يبدو أنها تستند إلى CentOS ، فسوف أقوم بتحويل مضيف التنفيذ الخاص بي إلى جهاز Ubuntu أو Debian.

أنا أقوم بتشغيل Docker version 1.12.5, build 7392c3b على جهاز CentOS 7 هذا. لم يتعطل Docker ، لكن عملية Jenkins التي كنت أجريها في Docker قُتلت عندما ظهرت هذه الرسالة.

شكرا جزيلا ل Docker! أنا أستخدمه طوال الوقت ، وأنا ممتن للغاية لعملك عليه!

أرى نفس المشكلة عند استخدام Jenkins مع Docker على جهاز Linux 4.8.15.

هل توصل أي شخص إلى إجراء إصلاح لنظام تشغيل المزارع؟

AFAICT ، هذه مشكلة تأمين في النظام الفرعي لمساحات أسماء الشبكات في Linux kernel. تم الإبلاغ عن هذا الخطأ منذ أكثر من عام ، بدون رد: https://bugzilla.kernel.org/show_bug.cgi؟id=97811 كان هناك بعض العمل على هذا (انظر هنا: http: //www.spinics. net / list / netdev / msg351337.html) لكن يبدو أنه ليس إصلاحًا كاملاً.

لقد حاولت تنفيذ الأمر ping على مشرف النظام الفرعي للشبكة مباشرةً ، بدون استجابة. FWIW ، يمكنني إعادة إنتاج المشكلة في غضون دقائق.

ستدفع Smyte 5000 دولار أمريكي لحل هذه المشكلة. يبدو أنني بحاجة إلى التحدث إلى شخص يعمل على النواة؟

petehunt أعتقد أن هناك عدة مشكلات في اللعب تسبب هذا الخطأ.

لقد نشرنا kernel 4.8.8 كما اقترح reshen وبينما يبدو الجهوزية أفضل قليلاً ، ما زلنا نرى هذه المشكلة في الإنتاج.

محاولة نشر Mesosphere من عقدة تمهيد التشغيل. جميع العقد هي CentOS 7.2 بحد أدنى مع تطبيق جميع التحديثات. تعرض عقدة التمهيد الخطأ كما لاحظ الآخرون أعلاه:

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

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

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

uname -r:

3.10.0-514.2.2.el7.x86_64

عامل ميناء -v:

Docker version 1.11.2, build b9f10c9

أستطيع أن أؤكد أن إعادة التشغيل تؤدي إلى إسكات الرسائل ، ولكن في اللحظة التي أنشر فيها الغلاف الجوي مرة أخرى ، تبدأ الرسائل بين الحين والآخر. Mesosphere هو انتشار كبير. ربما يمكن لأولئك الذين يحاولون إعادة إنشاء الخطأ استخدام المثبت لإعادة إنتاج الخطأ. يستغرق الأمر بضع دقائق قبل ظهور الخطأ بعد استخدام مفتاح البرنامج النصي الأول (--genconf وهي الخطوة الأولى).

لقد ضربنا هذا أيضًا. ومع ذلك ، فإن رسائل الخطأ في حالتنا تذكر الجهاز eth0 وليس lo . خطأي هو هذا:

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

أفترض أن أخطاء مثل ذكر eth0 بدلاً من lo لها نفس السبب الجذري لهذه المشكلة. إذا لم يكن الأمر كذلك ، يجب أن نفتح بطاقة جديدة بخصوص أخطاء eth0.

• نظام التشغيل: إصدار CentOS Linux 7.3.1611
• النواة: 3.10.0-514.2.2.el7.x86_64
• إصدار Docker 1.12.6 ، الإصدار 78d1802
• بدأ Docker بالخيارات: OPTIONS=" -H unix:///var/run/docker.sock --ip-forward=true --iptables=true --ip-masq=true --log-driver json-file --log-opt max-size=25m --log-opt max-file=2"
• Rancher 1.2.2 باستخدام IPsec (ذكر هذا منذ https://bugzilla.kernel.org/show_bug.cgi؟id=97811 وأخطاء أخرى تذكر IPsec)

لقد ضربنا هذا أيضًا.
خطأ: unregister_netdevice: انتظار lo لتصبح حرة.
نظام التشغيل: إصدار CentOS Linux 7.3.1611 (Core)
نواة 3.10.0-514.2.2.el7.x86_64
إصدار عامل الإرساء: 1.13.0-cs1-rc1
خيارات Docker:
{
"تعطيل التسجيل القديم": صحيح ،
"icc": صحيح ،
"السجلات غير الآمنة": [] ،
"ipv6": خطأ ،
"iptables": صحيح ،
"Storage-driver": "devicemapper"،
"خيارات التخزين": [
"dm.thinpooldev = / dev / mapper / docker_vg-thinpool" ،
"dm.use_defirmed_removal = صحيح" ،
"dm.use_defirmed_deletion = صحيح"
] ،
"userland-proxy": خطأ
}

لدي هذا على اثنين من أنظمة CentOS ، آخر التحديثات على واحد منهم على الأقل.

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

مرحبًا ، بالنسبة لكل الأشخاص المتأثرين بهذه المشكلة على RHEL أو CentOS ، لقد قمت بتحويل الالتزام من نواة الخط الرئيسي (torvalds / linux @ 751eb6b6042a596b0080967c1a529a9fe98dac1d) الذي يعمل على إصلاح حالة السباق في مرجع IPV6 IFP إلى 3.10.x kernels المستخدمة في توزيعات المؤسسة. هذا يجب أن يصلح هذه المشكلة.

يمكنك العثور على تقرير الخطأ مع تصحيح العمل هنا :
إذا كنت مهتمًا باختباره ولديك نظام RHEL 7 أو CentOS 7 ، فقد قمت بالفعل بتجميع أحدث إصدار CentOS 7.3 3.10.0-514.6.1.el7.x86_64 kernel مع التصحيح. قم بالرد على موضوع CentOS bugtracker ويمكنني أن أرسل لك رابطًا للبناء.

ملاحظة: قد تكون هناك مشكلة أخرى تتسبب في تسرب refcount ولكن هذا من شأنه إصلاح رسالة الخطأ للعديد منكم.

stefanlasiewskihenryiiijsoler

سأحاول أيضًا تجربة بناء بإضافة هذا الإصلاح: http://www.spinics.net/lists/netdev/msg351337.html لاحقًا الليلة.

iamthebot هل يعني ذلك أنه إذا قام أحدهم بتعطيل IPv6 ، فيجب أن

redbaron فقط إذا كانت هذه هي المشكلة التي تواجهها. أعتقد حقًا أن هناك العديد من مشكلات kernel التي يتم التعامل معها هنا.

redbaron ربما. يبدو أن # 20569 يشير إلى صعوبة تعطيل IPV6 تمامًا.

لذلك لتوضيح ما يحدث قليلاً تحت الغطاء الذي يولد هذه الرسالة ، تحتفظ النواة بعدد التشغيل لما إذا كان الجهاز قيد الاستخدام قبل إزالته من مساحة الاسم ، أو إلغاء تسجيله ، أو إلغاء تنشيطه ، وما إلى ذلك إذا كان هناك سبب متدلي بالإشارة إلى جهاز ، فسترى رسالة الخطأ هذه لأنه لا يمكن إلغاء تسجيلها عندما يستخدمه شيء آخر.

الإصلاحات التي رأيتها حتى الآن:

1. أصلح مشكلة فشل فيها تخصيص عنوان IPV6 (على سبيل المثال ، عنوان مكرر) ولكننا لا نصدر المرجع للجهاز قبل الخروج.
2. إصلاح مشكلة حيث يؤدي نقل مساحة اسم الجهاز بشكل صحيح إلى نقل المراجع إلى الجهاز إلى مساحة اسم الشبكة الجديدة مع ترك مرجع متدلي على مساحة الاسم القديمة. يستخدم Docker بشكل كبير مساحات أسماء الشبكة (كما يتضح من إصلاح kernel آخر كان لديّ Red Hat backport إلى 7.3 Z-Stream ومن المقرر أن يتم تضمينه في 7.4 الذي يمنع برنامج التشغيل macvlan الخاص بالرسو من العمل على السندات أو أجهزة الفريق)

أعتقد أنه لا تزال هناك حالة سباق أخرى عند تبديل مساحات الأسماء (يبدو أن هذا يحدث بعد إنشاء مجموعة من الحاويات الجديدة) ولكني سأحتاج إلى تكرار المشكلة بشكل موثوق من أجل تعقبها وكتابة تصحيح.

هل لدى أي شخص الحد الأدنى من الإجراءات لإعادة إنتاج هذا باستمرار؟ يبدو أنه يحدث بشكل عشوائي على أنظمتنا.

iamthebot ليس الأمر بسيطًا حقًا ، لكن أعتقد أنه يمكننا تزويدك ببيئة اختبار يمكنها إعادة إنتاج هذا بشكل موثوق. أرسل لي بريدًا إلكترونيًا ([email protected]) ويمكننا ترتيب التفاصيل.

ما زلت تواجه هذا في ظل الحمل الثقيل على Docker الإصدار 1.12.6 ، الإصدار 7392c3b / 1.12.6 على 4.4.39-34.54.amzn1.x86_64 AWS Linux AMI.

لدي 9 مضيفين لعمال الرصيف جميعهم متطابقون تقريبًا ، ولا أجرب هذا إلا في بعض منهم. قد يكون ذلك من قبيل المصادفة ، ولكن هناك شيء واحد مشترك لاحظته هو أنني أواجه هذه المشكلة فقط عند تشغيل الحاويات التي لا تتعامل مع SIGINT . عندما أقوم بـ docker stop هذه الحاويات ، فإنها تتوقف لمدة 10 ثوانٍ ثم تقتل الحاوية بشكل غير لائق.

يستغرق الأمر عدة أيام قبل أن تظهر المشكلة نفسها ، ويبدو أنها تظهر بشكل عشوائي ، وليس فورًا بعد تشغيل docker stop . هذا في الغالب قصصية ، ولكن ربما يساعد شخصًا ما.

لقد قمت بترقية جميع عُقد عامل الإرساء إلى kernel 3.10.0-514.6.1.el7.x86_64 على CentOS 7.3 كما ذكر iamthebot ولكن ما زلت أحصل على نفس الأخطاء:
26 يناير 13:52:49 XXX kernel: unregister_netdevice: انتظار lo لتصبح حرة. عدد الاستخدام = 1
رسالة من syslogd @ XXX في 26 كانون الثاني (يناير) 13:52:49 ...
kernel: unregister_netdevice : انتظار lo لتصبح حرة. عدد الاستخدام = 1

jsoler فقط هذا (يجب أن يعمل التصحيح على الألباب القديمة).

أرسل لي بريدًا إلكترونيًا ([email protected]) ويمكنني أن أرسل لك رابطًا إلى نواة مبنية مسبقًا. vitherman ، لسوء الحظ ، ليس لدي الكثير من الوقت للنظر في هذا (يبدو أن بعض الأجهزة ستحتاج إلى تجميعها للقبض على هذا الخطأ) لكنني صعدت المشكلة مع دعم Red Hat لذا فإن فريق kernel الخاص بهم سيستغرق بحث.

ckeeney يمكنني تأكيد هذا السلوك. لدينا تطبيق Node الذي تم إرساؤه والذي تسبب في الخطأ المذكور على النظام المضيف عندما تم إغلاقه. بعد تنفيذ وظيفة داخل تطبيق Node.js ، يمسك SIGINT و SIGTERM لإغلاق التطبيق بأمان ، لم يحدث الخطأ مرة أخرى.
أي كيندا منطقي. يستخدم تطبيق Node الواجهة الافتراضية التي ينشئها Docker. عندما لا يتم إغلاق Node بشكل صحيح ، يتوقف الجهاز ولا يمكن للنظام المضيف إلغاء تسجيله ، على الرغم من إيقاف حاوية Docker بنجاح.

فيما يلي مثال على مقتطف الشفرة:

function shutdown() {
    logger.log('info', 'Graceful shutdown.');

    httpServer.close();
    if (httpsServer) {
        httpsServer.close();
    }

    process.exit();
}

process.on('SIGINT', shutdown);
process.on('SIGTERM', shutdown);

@ michael-niemand هل هناك إشارة مختلفة يتم التعامل معها بشكل صحيح بواسطة Node افتراضيًا لإيقاف التشغيل النظيف؟ (يمكنك تحديد STOPSIGNAL في الصورة ، أو على docker run خلال العلم --stop-signal .

thaJeztah للحصول على شرح جيد للمشكلة ، والحل البديل ، راجع

ckeeney أدرك ذلك (على سبيل المثال ، العمليات التي تعمل كـ PID1 قد لا تتعامل مع SIGINT أو SIGTERM ). لهذا السبب ، كنت أتساءل عما إذا كان تحديد إشارة توقف مختلفة سيؤدي إلى إيقاف تشغيل نظيف حتى لو كان يعمل كـ PID1 .

بدلاً من ذلك ، يضيف عامل الإرساء 1.13 خيار --init (طلب السحب: https://github.com/docker/docker/pull/26061) ، والذي يقوم بإدراج الحرف الأول في الحاوية ؛ في هذه الحالة ، لا تعمل Node كـ PID1 ، مما قد يساعد في الحالات التي لا يمكنك فيها تحديث التطبيق.

iamthebot لقد قمت ببناء إصدار kernel 3.10.0-514.el7 مع التصحيح المدمج الخاص بك ولكني أحصل على نفس الخطأ. حسنًا ، لست متأكدًا مما إذا كنت قد قمت ببناء حزمة النواة الخاصة بـ centos بشكل جيد. هل يمكن أن تشاركني حزمة النواة الخاصة بك لاختبارها؟

شكرا

لقد / كنت أتعامل مع هذا الخطأ منذ ما يقرب من عام الآن. أستخدم CoreOS مع تمهيد PXE ، وقمت بتعطيل ipv6 في تكوين pxeboot ولم أر هذه المشكلة مرة واحدة منذ ذلك الحين.

حسنًا ، عطلت بيئتي IPv6 مع تكوين sysctl هذا
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
لكن ما زلت أتلقى الخطأ
kernel: unregister_netdevice : انتظار lo لتصبح حرة. عدد الاستخدام = 1

jsoler صحيح ، كنت أفعل ذلك أيضًا ، ما زال يحدث. مرة واحدة فقط فعلت ذلك مستوى pxe توقف.

label coreos
        menu label CoreOS
        kernel coreos/coreos_production_pxe.vmlinuz
        append initrd=coreos/coreos_production_pxe_image.cpio.gz ipv6.disable=1 cloud-config-url=http://...

مجرد ملاحظة - يبدو أن هناك مشاكل مختلفة في اللعب (قيل من قبل).

• يلاحظ بعض الأشخاص "في انتظار لو ..."
• لاحظ البعض "انتظار eth0"
• لاحظ البعض "انتظار فيت ؟؟؟؟؟"
• على تتبع أخطاء RedHat ، هناك حديث عن "انتظار ppp0"

لاحظ البعض وجود سجلات بالتناوب بين أيٍّ من تلك المذكورة أعلاه والبعض الآخر لديه واحد فقط مما سبق.

هناك أيضًا خطأ مشابه تم تسجيله في Ubuntu . في هذا الصدد ، يبدو أنهم وجدوا أن NFS هي المشكلة.

etlweather أعتقد أن القاسم المشترك الوحيد في الواقع هو ، حسنًا ، جهاز الشبكة الذي يتعذر إلغاء تسجيله بواسطة kernel كما تقول رسالة الخطأ. ومع ذلك ، فإن الأسباب _لماذا_ مختلفة بعض الشيء. بالنسبة لنا ، كانت بالتأكيد مشكلة الرصيف / العقدة المذكورة (veth). بالنسبة إلى eth ، فإن السبب هو على الأرجح شيء مختلف تمامًا.

لا يزال يحدث مع 4.9.0-0.bpo.1-amd64 على debian jessie مع docker 1.13.1. هل هناك أي تركيبة kernel - os مستقرة؟

قد لا تكون هذه مشكلة عامل إرساء بحت - أنا أحصل عليها على خادم Proxmox حيث أقوم فقط بتشغيل حاويات Vanilla LXC (ubuntu 16.04).

@ darth-veitcher إنها مشكلة نواة

thaJeztah وافق شكرا. كنت بصدد محاولة تثبيت 4.9.9 الليلة من mainline ومعرفة ما إذا كان ذلك يحل الأمور.

أقوم بتشغيل Docker 1.13.1 على Debian مع kernel 4.9.9-040909.

نعم ، لم تؤد ترقية kernel على Proxmox إلى الإصدار 4.9.9 إلى حل الخطأ. غريب لأنه ظهر للتو بعد عام بدون مشاكل.

قد يكون هناك شيء ما في البيان السابق في الجزء العلوي من الموضوع يتعلق بربطه بمشاركة NFS أو CIFS التي تم تحميلها.

مرسل من الايفون الخاص بي

في 14 فبراير 2017 ، الساعة 07:47 ، كتب ألفونسو دا سيلفا إخطارات github.com:

أقوم بتشغيل Docker 1.13.1 على Debian مع kernel 4.9.9-040909.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

لدي تذكرة بوغزيلا مفتوحة مع ريدهات بخصوص هذا.

بعض التطورات:
وضع Red Hat تصحيحات تسريب IPV6 من الخط الرئيسي على QA ، ويبدو أنهم في قائمة الانتظار لـ RHEL 7.4 وقد يتم نقلهم إلى 7.3. يجب أن يكون على CentOS-plus قريبًا أيضًا. ملاحظة: يعمل هذا التصحيح على إصلاح المشكلات في بعض الحالات فقط. إذا كان لديك نواة 4.x ، فهذه نقطة خلافية لأنها موجودة بالفعل.

هذه بالتأكيد حالة سباق في النواة مما يمكنني قوله ، مما يجعل العثور عليها أمرًا مزعجًا حقًا. لقد التقطت لقطة من نواة الخط الرئيسي الحالي وأعمل على إجراء المكالمات المختلفة بدءًا من النظام الفرعي IPV6. هذه المشكلة قابلة للتكرار بالتأكيد الآن: يبدو أن كل ما عليك فعله هو إنشاء مجموعة من الحاويات ، ودفع الكثير من حركة مرور الشبكة منها ، وتعطيل البرنامج داخل الحاويات ، وإزالتها. يؤدي القيام بذلك مرارًا وتكرارًا إلى حدوث المشكلة في دقائق ، ويتصدر محطة عمل فعلية رباعية النوى.

لسوء الحظ ، ليس لدي الكثير من الوقت للعمل على هذا: إذا كان هناك مطورو نواة هنا على استعداد للتعاون في تجهيز القطع الضرورية ، أعتقد أنه يمكننا إعداد مفترق وبدء العمل على تعقب هذا خطوة بخطوة .

iamthebot ، هل يمكن استنساخه في إعداد qemu-kvm؟

iamthebot لقد حاولت أن أعبر عن هذا عدة مرات بنواة مختلفة. في مكان ما أعلاه ، تم ذكر أن استخدام docker-stress -c 100 مع تعيين userland-proxy على false سيؤدي إلى تشغيله ، لكن لم يحالفني الحظ.

إذا كان لديك repro أكثر موثوقية (حتى لو استغرق الأمر وقتًا طويلاً للتشغيل) ، فيمكنني محاولة إلقاء نظرة

نواجه نفس الصعوبة في بيئات الإنتاج والتشغيل. سنقوم بالترقية إلى Docker 1.13 و Linux kernel 4.9 قريبًا ولكن كما ذكرنا سابقًا ؛ تتأثر هذه الإصدارات أيضًا.

$ docker -v
Docker version 1.12.3, build 6b644ec

$ uname -a
Linux 4.7.0-0.bpo.1-amd64 #1 SMP Debian 4.7.8-1~bpo8+1 (2016-10-19) x86_64 GNU/Linux

أواجه هذه المشكلة بانتظام إلى حد كبير على نظام التطوير الخاص بي ، دائمًا أثناء إغلاق الحاويات.

معلومات عامة

→ uname -a
Linux miriam 3.10.0-514.6.1.el7.x86_64 #1 SMP Sat Dec 10 11:15:38 EST 2016 x86_64 x86_64 x86_64 GNU/Linux

→ cat /etc/redhat-release
Red Hat Enterprise Linux Workstation release 7.3 (Maipo)

→ docker -v 
Docker version 1.13.0, build 49bf474

→ docker-compose -v 
docker-compose version 1.10.0, build 4bd6f1a

→ docker info 
Containers: 11
 Running: 0
 Paused: 0
 Stopped: 11
Images: 143
Server Version: 1.13.0
Storage Driver: overlay
 Backing Filesystem: xfs
 Supports d_type: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 03e5862ec0d8d3b3f750e19fca3ee367e13c090e
runc version: 2f7393a47307a16f8cee44a37b262e8b81021e3e
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 3.10.0-514.6.1.el7.x86_64
Operating System: Red Hat Enterprise Linux
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 31.19 GiB
Name: miriam
ID: QU56:66KP:C37M:LHXT:4ZMX:3DOB:2RUD:F2RR:JMNV:QCGZ:ZLWQ:6UO5
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 16
 Goroutines: 25
 System Time: 2017-02-15T10:47:09.010477057-06:00
 EventsListeners: 0
Http Proxy: http://xxxxxxxxxxxxxxxxxxxx:80
Https Proxy: http://xxxxxxxxxxxxxxxxxxxx:80
No Proxy: xxxxxxxxxxxxxxxxxxxx
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Docker daemon log

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

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

@ r-BenDoan إذا حاولت إيقاف حاوية لكنها لا تستجيب لـ SIGINT ، سينتظر عامل الشحن 10 ثوانٍ ثم يقتل الحاوية بشكل غير لائق. لقد واجهت هذا السلوك في حاويات nodejs الخاصة بي حتى أضفت معالجة الإشارة. إذا رأيت حاوية تستغرق 10 ثوانٍ للتوقف ، فمن المحتمل أنها لا تتعامل مع الإشارات ومن المرجح أن تؤدي إلى حدوث هذه المشكلة.

تأكد من أن حاوياتك يمكن أن تتوقف بأمان.

على الرغم من أنني لست الشخص الذي يعمل على إصلاح هذه المشكلة ، ولا أكون كثيرًا في Linux Kernel dev ، أعتقد أنني محق في القول إن تعليقات "أنا أيضًا" ليست مفيدة. أعني بهذا ، مجرد قول "لدي هذه المشكلة أيضًا ، مع Kernel vx.x و Docker 1.x" لا يجلب أي شيء جديد للمناقشة.

ومع ذلك ، أود أن أقترح أن التعليقات "أنا أيضًا" التي تصف بشكل أكبر البيئة وطريقة إعادة الإنتاج ستكون ذات قيمة كبيرة.

عند قراءة جميع التعليقات ، من الواضح أن هناك بعض المشكلات - كما نشرت سابقًا ، بعضها مع vethXYZ ، وبعضها مع eth0 والبعض الآخر مع lo0. هذا يشير إلى أنها قد تكون ناجمة عن مشاكل مختلفة. لذا فإن مجرد قول "أنا أيضًا" بدون وصف كامل للخطأ والبيئة قد يضلل الناس.

أيضًا ، عند وصف البيئة ، لا يكفي إعطاء إصدار Kernel و Docker. حسب الموضوع ، يبدو أن هناك بعض العوامل مثل تمكين IPv6 أم لا. NodeJS لا تستجيب لـ SIGINT (أو حاويات أخرى ، لا تقرع على NodeJS هنا).

لذا فإن وصف عبء العمل على البيئة سيكون مفيدًا. يحدث هذا أيضًا عندما يتم إيقاف تشغيل الحاوية ، لذلك أقترح أيضًا على الأشخاص الذين يواجهون هذه المشكلة الانتباه إلى الحاوية التي يتم إيقافها عند ظهور المشكلة برأسها القبيح.

بينما يبدو أن المشكلة تكمن في وجود حالة سباق في Kernel - فإن تحديد المشغل سيكون مفيدًا للغاية لأولئك الذين سيصلحون المشكلة. ويمكنه أيضًا أن يمنح المستخدمين المتأثرين حلاً فوريًا مثل تنفيذ معالج إشارة في تطبيق NodeJS (لا أعرف بنفسي أن هذا يمنع تشغيل المشكلة ، ولكن يبدو ذلك وفقًا للتعليقات السابقة للآخرين).

ربطت FWIW kubernetes هذا تمامًا بـ "وضع دبوس الشعر" و
توقف عن استخدام هذه الميزة تمامًا. لم نختبر هذا
مشكلة على الإطلاق ، عبر عشرات الآلاف من آلات الإنتاج وعلى نطاق واسع
المزيد من عمليات التشغيل التجريبية ، منذ التغيير.

حتى يتم إصلاح هذا ، التخلي عن السفينة. ابحث عن حل مختلف :(

في يوم الأربعاء 15 فبراير 2017 الساعة 10:00 صباحًا ، كتب ETL [email protected] :

على الرغم من أنني لست الشخص الذي يعمل على إصلاح هذه المشكلة ، فأنا لا أعمل كثيرًا في Linux
Kernel dev ، أعتقد أنني محق في القول إن تعليقات "أنا أيضًا" ليست كذلك
هذا مفيد. أعني بهذا ، فقط أقول "لدي هذه المشكلة أيضًا ، مع
Kernel vx.x و Docker 1.x "لا يجلبان أي شيء جديد إلى المناقشة.

ومع ذلك ، أود أن أقترح أن التعليقات "أنا أيضًا" التي تصف أكثر
ستكون البيئة وطريقة التكاثر ذات قيمة كبيرة.

عند قراءة جميع التعليقات ، من الواضح أن هناك بعض المشاكل -
كما نشرت سابقًا ، بعضها يحتوي على vethXYZ ، والبعض الآخر باستخدام eth0 والبعض الآخر مع lo0.
هذا يشير إلى أنها قد تكون ناجمة عن مشاكل مختلفة. اذن فقط
يقول "أنا أيضًا" بدون وصف كامل للخطأ وربما البيئة
تضليل الناس.

أيضًا ، عند وصف البيئة ، يتم إعطاء Kernel و Docker
الإصدار غير كافٍ. حسب الموضوع ، يبدو أن هناك بعض العوامل
مثل IPv6 تمكين أم لا. NodeJS لا يستجيب لـ SIGINT (أو ملفات
الحاويات ، وليس تقريع NodeJS هنا).

لذا فإن وصف عبء العمل على البيئة سيكون مفيدًا.
يحدث هذا أيضًا عندما يتم إغلاق حاوية ، لذلك سأفعل
نقترح أيضًا على الأشخاص الذين يعانون من هذه المشكلة الانتباه إلى ما
تم إيقاف الحاوية عندما ترجع المشكلة رأسها القبيح.

بينما يبدو أن المشكلة في Kernel وجود حالة سباق -
تحديد المشغل سيكون مفيدًا للغاية لأولئك الذين سيصلحون
المشكلة. ويمكنه أيضًا أن يمنح المستخدمين المتأثرين حلاً فوريًا
مثل تنفيذ معالج إشارة في تطبيق NodeJS (لا أعرف
أنا نفسي أن هذا يمنع المشكلة من الظهور ، لكن يبدو الأمر كذلك
التعليقات السابقة للآخرين).

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/docker/issues/5618#issuecomment-280087293 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AFVgVFmu1SiStZcLKtKuk1W-tjn6wOXlks5rcz0hgaJpZM4B4L4Z
.

نعم ، نحن ننتقل إلى gke ولم نعد نرى هذه المشكلة (لذلك لا مزيد من مكافأة الأخطاء منا :))

فقط كان لديه الخطأ مرة أخرى. كنت أحاول إصلاح تطبيق node.js الذي يستخدم مآخذ توصيل وبالتالي يوسع التطبيق كثيرًا. تم إنشاء تطبيق node.js أعلى https://github.com/deployd/deployd. آمل أن يقدم هذا المزيد من المعلومات. الأمر المثير للاهتمام أيضًا هو أن كلا الخادمين داخل سربتي عرضا خطأ unregister_netdevice في وقت واحد بعد أن أزلت الخدمة عبر خدمة docker service rm. تم تصغير الحاوية إلى 4 بحيث تم تشغيل حاويتين على كل جهاز.

حدث التعديل مرة أخرى! العمل على نفس تطبيق node.js. آخر 3 أو 4 أيام لم أعمل بشكل مباشر على تطبيق node.js هذا ولم يحدث أبدًا.

سيحاول Edit2 إضافة معالج إشارة إلى تطبيق nodejs. دعونا نرى ما إذا كان ذلك يساعد ....

لقد واجهت هذا الخطأ للتو ، بعد استخدام docker-py لنشر نسخة جديدة إلى EC. ومع ذلك ، تمكنت من الخروج باستخدام ctrl + C ، ولم أره منذ ذلك الحين (الآن بعد أن أصبحت معظم الصور تُبنى بسرعة أكبر من ذاكرة التخزين المؤقت)

`` `{" status ":" Pushed "،" progressDetail ": {}،" id ":" c0962ea0b9bc "}
{"الحالة": "المرحلة: الملخص: sha256: f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8 الحجم: 5737"}
{"progressDetail": {}، "aux": {"Tag": "stage"، "Digest": "sha256: f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8"، "الحجم": 5737}}

تم نشر صورة عامل ميناء بنجاح

رسالة من syslogd @ ip-172-31-31-68 في 16 فبراير 19:49:16 ...
النواة: [1611081.976079] unregister_netdevice: انتظار lo لتصبح حرة. عدد الاستخدام = 1

رسالة من syslogd @ ip-172-31-31-68 في 16 فبراير 19:49:27 ...
النواة: [1611092.220067] unregister_netdevice: انتظار lo لتصبح حرة. عدد الاستخدام = 1

[1] + توقف ./image-publish.py
[ root @ ip-172-31-xx-xx image-publish] # ^ C
[ root @ ip-172-31-xx-xx image-publish] #

thockin هل هذا الإعداد --hairpin-mode=none على الكوبيليتات؟

= لا شيء يكسر الحاويات التي تعيد NAT'ed إلى نفسها. نحن نستخدم
منحل الجسر افتراضيا.

يوم الخميس 16 فبراير 2017 الساعة 7:26 مساءً ، Kanat Bekt [email protected]
كتب:

thockin https://github.com/thockin هو هذا الإعداد - وضع الشعر = لا شيء
على kubelets؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/docker/issues/5618#issuecomment-280539673 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AFVgVLNwAH6NWVaIKhJfS147O9w_rtJEks5rdRN8gaJpZM4B4L4Z
.

thockin ما هي الحاويات التي قد ترغب في الوصول إلى نفسها عبر Service ClusterIP؟

اتضح أنه أكثر شيوعًا مما كنت أعتقد ، وعندما كسرناه ، الكثير
اشتكى من الناس.

في 17 فبراير 2017 ، الساعة 12:38 صباحًا ، كتب "مكسيم إيفانوف" [email protected] :

thockin https://github.com/thockin أي الحاويات قد ترغب في ذلك
الوصول إلى أنفسهم عبر خدمة ClusterIP؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/docker/issues/5618#issuecomment-280588366 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AFVgVLn3uBvUW-dQ72qst5_eYiFUtfSVks5rdVyIgaJpZM4B4L4Z
.

أعتقد أنني أعرف سبب تسبب بعض تطبيقات nodejs المرسومة في حدوث هذه المشكلة. تستخدم العقدة اتصالات البقاء على قيد الحياة لكل افتراضي. عند استخدام server.close() ، لا يقبل الخادم اتصالات جديدة. ولكن لا تزال الاتصالات النشطة الحالية مثل مآخذ الويب أو اتصالات HTTP المستمرة. عندما يتم أيضًا تغيير حجم التطبيق الذي تم إرساؤه إلى n ، فقد ينتج عن ذلك waiting for lo to become free لأنه عندما يتم إجباره على الإنهاء ، فقد تم تحرير أحدث. عندما يعيد docker توزيع هذا التطبيق إلى عقدة أخرى أو عندما يتم تصغير حجم التطبيق ، يرسل docker إشارة إلى التطبيق بأنه يجب إيقاف تشغيله. يستمع التطبيق إلى هذه الإشارة ويمكن أن يتفاعل. عندما لا يتم إغلاق التطبيق بعد بضع ثوانٍ ، ينهيه عامل التشغيل دون تردد. أضفت معالجات الإشارة واكتشفت أنه عند استخدام server.close() ، لا يتم إنهاء الخادم تمامًا ولكن "فقط" يتوقف عن قبول الاتصالات الجديدة (راجع https://github.com/nodejs/node/issues/2642). لذلك نحن بحاجة إلى التأكد من إغلاق الاتصالات المفتوحة مثل websockets أو http keep-live.

كيفية التعامل مع مآخذ الويب:
ينبعث تطبيق nodejs إلى جميع websockets closeSockets عند تلقي إشارة إيقاف التشغيل. يستمع العميل إلى هذا الحدث closeSockets ويستدعي sockets.disconnect() وبعد فترة وجيزة sockets.connect() . تذكر أنه تم استدعاء server.close() لذلك لا يقبل هذا المثيل طلبات جديدة. عندما تقوم مثيلات أخرى من هذا التطبيق المرسي ​​بتشغيل loadbalancer داخل عامل الإرساء ، فسوف تختار في النهاية مثيلًا لم يتم إيقاف تشغيله ويتم إنشاء اتصال ناجح. لن يكون للمثيل الذي يجب إيقاف تشغيله اتصالات مآخذ ويب مفتوحة.

var gracefulTermination = function(){
    //we don't want to kill everything without telling the clients that this instance stops
    //server.close() sets the server to a state on which he doesn't allow new connections
    //but the old connections (websockets) are still open and can be used
    server.close(function(){
        // this method is called when the server terminates
        console.log('close bknd');
            process.exit();
        });

        //iterate through all open websockets and emit 'closeSockets' to the clients.
    //Clients will then call disconnect() and connect() on their site to establish new connections
    //to other instances of this scaled app
    Object.keys(server.socketIoObj.sockets.sockets).forEach(function(id) {
        console.log("WebSocket ID:",id, " will be closed from the client.") 
        server.socketIoObj.to(id).emit('closeSockets');
    });

};
process.on( "SIGINT", function() {
    console.log('CLOSING [SIGINT]');
    gracefulTermination();
});
...

كيفية التعامل مع اتصالات HTTP المستمرة:
لا أعرف حاليًا كيف يمكن القيام بذلك على أكمل وجه. أسهل طريقة لتعطيل البقاء على قيد الحياة.

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

الاحتمال الآخر هو ضبط مهلة البقاء على رقم منخفض جدًا. على سبيل المثال 0.5 ثانية.

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

آمل أن يساعد هذا الآخرين :)

لدي نفس المشاكل. المرفقات هي جميع السجلات التي تم إنشاؤها من البرنامج النصي ecs-logs-Collector.
نقدر كثيرا على أي مساعدة :)

collect.zip

لدي نفس المشاكل.
إصدار Docker 1.13.1 ، بناء 092cba3
Linux Debian 4.8.6-x86_64-linode78

نسخة احتياطية من Linux 4.6.0-040600-generic # 201606100558 SMP الجمعة 10 يونيو 10:01:15 بالتوقيت العالمي المنسق 2016 x86_64 x86_64 x86_64 GNU / Linux
إصدار الخادم: 1.13.1

المشكلة نفسها. أنا أستخدم جبل في حاوية مميزة. بعد 4-5 مرات يتجمد. لدي أيضًا نفس المشكلة مع أحدث نواة قياسية لـ 16.04

الجميع ، etlweather هو الحال. لا تنشر "أنا أيضًا" إلا إذا كانت لديك طريقة موثوقة لإعادة إظهار المشكلة. في هذه الحالة ، قم بتفصيل الإجراء الخاص بك. لا يكفي إصدار docker و kernel ونحصل على الكثير من الإشعارات حول هذا الموضوع. كلما كان إجراء الإنجاب أبسط ، كان ذلك أفضل.

rneugebaredbaron لسوء الحظ ، فإن "repro" الحالي الذي أملكه هو خاص بالأجهزة (كل هذا ما عدا إثبات أن هذه حالة سباق). لم أحاول الحصول على نسخة QEMU ولكن هذه بالتأكيد هي الخطوة التالية حتى يتمكن العديد من الأشخاص من العمل على هذا الأمر والحصول على النتيجة المتوقعة (من الناحية المثالية في إعداد أساسي واحد لوحدة المعالجة المركزية). إذا كان لدى شخص ما بالفعل ، يرجى إرسال بريد إلكتروني إليّ (موجود في ملف التعريف الخاص بي). سأختبره بدقة وأرسله هنا.

نحصل على هذا كثيرًا في الحملة العالمية للتعليم كثيرًا. يتجمد Docker ويتوقف الجهاز عند إعادة التشغيل.

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

تعمل الحاوية على تشغيل تطبيق go ، وقد تم تكوين nat hairpin.

عامل ميناء:

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

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

نظام التشغيل Ubuntu 16.04 LTS ،

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

هل لدى أي شخص مقترح عمل حول هذا؟ حاولت تمكين --userland-proxy=true وما زال عامل الإرساء معلقًا بعد فترة. يبدو أن Kubernates لديه حل مما كتبه thockin أعلاه ، ولكن ليس من الواضح ما يفعله --hairpin-mode=promiscuous-bridge بالضبط وكيفية تكوين ذلك على تثبيت jane ubuntu 16.x docker العادي.

يمكنني تحقيق ذلك بشكل موثوق عند تشغيل Proxmox واستخدام الحاويات. على وجه التحديد ، إذا قمت بنقل قدر كبير من البيانات أو قمت بالفعل بنقل أي كمية من البيانات مؤخرًا ، فإن إغلاق الحاوية أو إيقافها بشدة سيؤدي إلى حدوث هذا الخطأ. لقد رأيته في أغلب الأحيان عندما أستخدم الحاويات التي تثبت NAS بداخلها ، ولكن قد يكون ذلك مصادفة.

# uname -a
Linux proxmox01 4.4.40-1-pve #1 SMP PVE 4.4.40-82 (Thu, 23 Feb 2017 15:14:06 +0100) x86_64 GNU/Linux

# cat /etc/debian_version
8.7

ومن داخل Proxmox:

proxmox-ve: 4.4-82 (running kernel: 4.4.40-1-pve)
pve-manager: 4.4-12 (running version: 4.4-12/e71b7a74)
pve-kernel-4.4.35-1-pve: 4.4.35-77
pve-kernel-4.4.40-1-pve: 4.4.40-82
lvm2: 2.02.116-pve3
corosync-pve: 2.4.2-1
libqb0: 1.0-1
pve-cluster: 4.0-48
qemu-server: 4.0-109
pve-firmware: 1.1-10
libpve-common-perl: 4.0-92
libpve-access-control: 4.0-23
libpve-storage-perl: 4.0-76
pve-libspice-server1: 0.12.8-2
vncterm: 1.3-1
pve-docs: 4.4-3
pve-qemu-kvm: 2.7.1-4
pve-container: 1.0-94
pve-firewall: 2.0-33
pve-ha-manager: 1.0-40
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u3
lxc-pve: 2.0.7-3
lxcfs: 2.0.6-pve1
criu: 1.6.0-1
novnc-pve: 0.5-8
smartmontools: 6.5+svn4324-1~pve80
zfsutils: 0.6.5.9-pve15~bpo80

تجدر الإشارة إلى أن Docker غير مثبت على هذا النظام ولم يتم تثبيته أبدًا. يسعدني تقديم أي بيانات يحتاجها المجتمع لاستكشاف هذه المشكلة وإصلاحها ، فقط أخبرني بالأوامر التي يجب تشغيلها.

أنا قادر على إعادة إنتاج هذا على centos 7.3 الذي يعمل كعقدة عامل سرب تعمل DTR مع تعيين وحدة تخزين nfs مُثبتة

إذا كنت ستصل إلى هنا

المشكلة التي تتم مناقشتها هنا هي خلل في النواة ولم يتم إصلاحها بعد. هناك عدد من الخيارات التي قد تساعد في _بعض_ المواقف ، ولكن ليس للجميع (على الأرجح مجموعة من المشكلات التي تؤدي إلى ظهور الخطأ نفسه)

لا تترك تعليقات "لدي هذا أيضًا"

"لدي هذا أيضًا" لا يساعد في حل الخطأ. اترك تعليقًا فقط إذا كانت لديك معلومات قد تساعد في حل المشكلة (في هذه الحالة ؛ قد يكون توفير تصحيح إلى kernel upstream هو أفضل خطوة).

إذا كنت تريد إعلامك بأن لديك هذه المشكلة أيضًا ، فاستخدم الزر "رائعة" في الوصف العلوي:

إذا كنت تريد البقاء على اطلاع على التحديثات ، فاستخدم زر _subscribe_.

يرسل كل تعليق هنا بريدًا إلكترونيًا / إشعارًا إلى أكثر من 3000 شخص لا أرغب في قفل المحادثة حول هذه المشكلة ، لأنه لم يتم حلها بعد ، ولكن قد تضطر إلى ذلك إذا تجاهلت ذلك.

شكرا!

كل هذا جيد وجيد ولكن ما هي الخيارات التي تساعد بالضبط؟ تسبب لنا هذه المشكلة مشكلات في الإنتاج ، لذا أود القيام بأي عمل حيال ضروري للتغلب على خطأ kernel.

إذا كان لدى شخص ما من Docker الوقت لتجربة حل Kubernetes ، من فضلك
اسمحوا لي أن أعرف ويمكننا توجيهك إليها. أنا غير قادر على استخراج التغييرات
وأصلحهم في Docker بنفسي الآن.

الخميس، 9 مارس 2017 في 07:46، ماثيو Newhook [email protected]
كتب:

كل هذا جيد وجيد ولكن ما هي بالضبط الخيارات التي تساعد؟
هذه المشكلة تسبب لنا مشاكل في الإنتاج لذا أود أن أفعل أي شيء
الحلول الضرورية للتغلب على خطأ kernel.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/docker/issues/5618#issuecomment-285388243 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AFVgVGdH5VX_oFWkImyo_TvlIuhmwMepks5rkB7MgaJpZM4B4L4Z
.

thockin شكرا. كنت أتابع قضية العلاقات العامة في Kubernetes باستخدام الحل البديل لوضع دبوس الشعر. ولكن خلال العديد من ذهابا وإيابا ، فقدت المسار إذا تخلصت طريقة الحل البديل من هذه المشكلة؟
(كما أفهم ، هناك سيناريوهات مختلفة تسبب عدم تناسق عدد المرجع في النواة).

إذا كان بإمكانك توجيهي إلى العلاقات العامة التي تعتقد أنها تعالج المشكلة في K8s ، فسأعمل على إصلاح هذا في عامل الإرساء على الأقل في حالة إيقاف تشغيل userland-proxy افتراضيًا. (ويمكننا اختباره باستخدام خطوات إعادة إنتاج ضغط عامل التحميل).

لست متأكدًا من أن لديّ علاقات عامة واحدة ، لكن يمكنك إلقاء نظرة على الوضع الحالي. يبدأ
هنا:

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

يوم السبت 11 مارس 2017 الساعة 10:49 مساءً ، Madhu Venugopal [email protected]
كتب:

thockin https://github.com/thockin شكرا. كنت أتابع
العلاقات العامة / المشكلة في Kubernetes مع الحل البديل لوضع دبوس الشعر. لكن خلال
كثيرًا ذهابًا وإيابًا ، فقدت المسار إذا تخلصت طريقة الحل البديل من هذا
مشكلة ؟
(كما أفهم ، هناك سيناريوهات مختلفة تؤدي إلى حساب المرجع
تناقض في النواة).

إذا كنت تستطيع أن تدلني على العلاقات العامة التي تعتقد أنها تعالج المشكلة في K8s ،
سأعمل على إصلاح هذا في عامل التحميل على الأقل في حالة الدوران
userland-proxy مغلق افتراضيًا. (ويمكننا اختباره باستخدام ضغط عامل التحميل
خطوات الاستنساخ).

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/docker/issues/5618#issuecomment-285926217 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AFVgVIlGs_QccxS6YYQiLNybddDzB4yUks5rk5VogaJpZM4B4L4Z
.

مرحبًا بالجميع ، فقط للتوضيح ، كل ما يفعله "حل kubernetes" هو تمكين الوضع المختلط على الجسر الأساسي. يمكنك تحقيق نفس الشيء باستخدام ip link set <bridgename> promisc on باستخدام iproute2. إنه يقلل من احتمال الوقوع في الخطأ ولكنه قد لا يقضي عليه تمامًا.

الآن ، من الناحية النظرية ، لا ينبغي أن يعمل هذا ... ولكن لسبب ما يبدو أن الوضع المختلط يجعل تفكيك الجهاز بطيئًا بدرجة كافية بحيث لا تحصل على سباق لتقليل عداد المرجع. ربما يمكن لأحد المساهمين في Kurbernetes أن يتناغم هنا إذا كانوا في هذا الموضوع.

يمكنني التحقق من أن الحل البديل (لا يتم إصلاحه) يعمل باستخدام repro الخاص بالبيئة. لا يمكنني التحقق حقًا من أنه يساعد إذا كنت تستخدم برامج تشغيل IPVLAN أو MACVLAN (نستخدم macvlan في prod) لأنه يبدو من الصعب جدًا الحصول على هذه الإعدادات لإنتاج هذا الخطأ. هل يمكن لأي شخص آخر لديه repro محاولة التحقق من الحل؟

مرحبًا بالجميع ، لقد حاولت تصحيح مشكلة kernel ، وكان لدي سلسلة بريد إلكتروني على القائمة البريدية لـ "netdev" ، لذلك أردت فقط نشر بعض النتائج هنا.

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

القضية التي نراها هي ذلك

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

أثناء إغلاق الحاوية. عند فحص مساحة اسم شبكة الحاوية ، يبدو أن الجهاز eth0 قد تم حذفه بالفعل ، ولكن بقي الجهاز lo فقط. وهناك هيكل آخر يحمل المرجع لهذا الجهاز.

بعد بعض البحث ، اتضح أن "الشيء" الذي يحتفظ بالمرجع هو أحد "ذاكرة التخزين المؤقت للتوجيه" ( struct dst_entry ). وهناك شيء ما يمنع هذا dst_entry من الحصول على gc'ed (العدد المرجعي لـ dst_entry أكبر من 0). لذلك قمت بتسجيل كل dst_hold() (زيادة عدد مرجع dst_entry بمقدار 1) ، و dst_release() (تقليل عدد مرجع dst_entry بمقدار 1) ، وهناك بالفعل مكالمات dst_hold() ثم dst_release() .

هنا السجلات المرفقة: kern.log.zip

ملخص:

• تمت إعادة تسمية الواجهة lo إلى lodebug لسهولة عملية greping
• يبدأ عدد المرجع لـ dst_entry بـ 1
• العدد المرجعي لـ dst_entry (الذي يحتفظ بمرجع lo) في النهاية هو 19
• هناك 258041 dst_hold() للمكالمات و 258023 dst_release() للمكالمات
• في مكالمات 258041 dst_hold() ، هناك 88034 udp_sk_rx_dst_set() (وهو ما يعني dst_hold() ) ، و 152536 inet_sk_rx_dst_set() ، و 17471 __sk_add_backlog()
• في مكالمات 258023 dst_release() ، يوجد 240551 inet_sock_destruct() و 17472 refdst_drop()

هناك مكالمات أكثر من udp_sk_rx_dst_set() و inet_sk_rx_dst_set() في المجمل أكثر من inet_sock_destruct() ، لذا يشتبه في وجود بعض المقابس في حالة "طي النسيان" ، وشيء يمنعها من التدمير.

تحديث:
تم إنشاء مآخذ التوصيل ( struct sock ) وتدميرها بشكل صحيح ، ولكن بالنسبة لبعض مآخذ TCP ، يتم استدعاء inet_sk_rx_dst_set() عدة مرات على نفس dst ، ولكن هناك واحد فقط المقابلة inet_sock_destruct() لتحرير المرجع إلى dst .

إليك الحل البديل CentOS 7.3 الذي أصلحه لي:

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

ها هي الرقعة التي تحلها:
https://bugs.centos.org/view.php؟id=12711&nbn=1

تحديث: تبين أن هذا لا يحل المشكلة بشكل دائم. ظهرت مرة أخرى بعد عدة ساعات برسالة الحائط التالية:
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

adrianotto - للتوضيح: هل يقوم تصحيح نواة CentOS بحل هذا؟ هل تشعر بالفضول فقط إذا كنت تقصد أن كل من الحل البديل ومسار kernel المرجعي لم يحل هذا بنجاح نهائيًا؟

stayclassychicagoadrianotto يعالج هذا التصحيح فقط أحد شروط السباق التي يمكن أن تؤدي إلى مشكلة "عدد الاستخدام" في النواة. إنه مجرد إصلاح خلفي من شيء موجود في نواة 4.x بالفعل. قد يحل مشاكلك لذلك يستحق المحاولة.

stayclassychicago قبل أن أجرب نواة 3.10.0-514.10.2.el7.centos.plus.x86_64 كنت أحصل على kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1 بشكل منتظم ، تقريبًا في كل مرة أشغل فيها حاوية بها docker run --rm ... عند خروج الحاوية. بعد ترقية kernel وإعادة التشغيل ، توقف تمامًا لعدة ساعات ، ثم عاد مرة أخرى. الآن نصف الوقت الذي أحذف فيه الحاويات يعمل بشكل صحيح ، حيث اعتاد على الخطأ في الوقت المحدد. لا أعرف على وجه اليقين ما إذا كانت النواة الجديدة تساعد ، لكنها لا تؤذي.

يبدو أنه من السهل جدًا إعادة الإنتاج عند وجود واجهة ربط LACP على الجهاز. لدينا مجموعة سرب من 3 عقد ، كل 3 مع واجهة ربط LACP مهيأة ، وهذه المشكلة في الأساس لا تسمح لنا بالعمل مع الكتلة. يتعين علينا إعادة تشغيل العقد كل 15-20 دقيقة.

تم التأكيد - بمجرد أن أزلت ارتباط LACP من الواجهات (تلك التي كانت تستخدم كواجهات رئيسية) ، كل شيء يعمل بشكل جيد لأكثر من 12 ساعة. تستخدم لكسر كل ~ 30 دقيقة.

هذا قابل للتكرار في Linux containerhost1 4.9.0-0.bpo.2-amd64 #1 SMP Debian 4.9.18-1~bpo8+1 (2017-04-10) x86_64 GNU/Linux مع تشغيل Docker version 17.04.0-ce, build 4845c56 في الوضع المميز عندما يكون لدينا cifs تتصاعد مفتوحة. عندما تتوقف الحاوية مع فتح الحوامل ، لا يستجيب Docker ونحصل على خطأ kernel:[ 1129.675495] unregister_netdevice: waiting for lo to become free. Usage count = 1 .

ubuntu 16.04 (kernel 4.4.0-78-generic) لا يزال لديه المشكلة. وعندما يحدث ذلك ، فإن أي تطبيق يحاول إنشاء مساحة اسم شبكة جديدة من خلال clone syscall سيتعطل

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

الحل الوحيد هو إعادة ضبط الجهاز.

واجهت هذه المشكلة عند تركيب وحدة تخزين NFS في حاوية ذات امتيازات ثم إعادة تشغيل الحاوية.
يبدو لي أن هذه المشكلة لم تحدث أبدًا على RHEL 7 بنفس الإجراء.

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

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

تدعي Red Hat أن لديها مثيلاً لهذا الخطأ تم إصلاحه اعتبارًا من إصدار kernel-3.10.0-514.21.1.el7. أفترض أنهم سيرسلون الإصلاح في أقرب وقت ممكن ويعيدون تعيينه إلى 4.12. هذه الحزمة متاحة بالفعل على CentOS 7 أيضًا.

الوثائق المتعلقة بالإصلاح (يلزم الوصول إلى RHN):
https://access.redhat.com/articles/3034221
https://bugzilla.redhat.com/show_bug.cgi؟id=1436588

من المقال:
"في حالة وجود عنوان IPv6 مكرر أو مشكلة في تعيين عنوان ، حدثت حالة تعارض. تسبب هذا السباق أحيانًا في حدوث تسرب في حساب مرجع العنوان. وبالتالي ، فشلت محاولات إلغاء تسجيل جهاز شبكة مع ظهور رسالة الخطأ التالية:" unregister_netdevice: انتظار لتصبح حرا. عدد الاستخدام = 1 ". مع هذا التحديث ، تم إصلاح التعليمات البرمجية المصدر الأساسية ، وأصبحت أجهزة الشبكة الآن غير مسجلة كما هو متوقع في الموقف الموصوف."

لقد قمت بالفعل بنشر هذا الإصلاح في جميع أنظمة مجموعة PaaS الخاصة بنا ، وكان هناك بالفعل يومين دون إصابة الخطأ. في وقت سابق ، كان لدينا نظام واحد على الأقل يتم تجميده يوميًا. سأبلغ هنا إذا أصابنا الخطأ مرة أخرى.

لدي إصدار kernel 3.10.0-514.21.1.el7.x86_64 ، ولا يزال لدي نفس الأعراض.

Message from syslogd<strong i="6">@docker</strong> at May 26 22:02:26 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1
# uname -a
Linux docker 3.10.0-514.21.1.el7.x86_64 #1 SMP Thu May 25 17:04:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
# uptime
 22:03:10 up 35 min,  3 users,  load average: 0.16, 0.07, 0.06

adrianotto على ما يبدو ، هناك عدة طرق

bcdonadio إذا نظرت إلى https://git.centos.org/commitdiff/rpms!kernel.git/b777aca52781bc9b15328e8798726608933ceded - سترى أن https://bugzilla.redhat.com/show_bug.cgi؟id=1436588 الخطأ هو "تم إصلاحه" من خلال هذا التغيير:

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

وهو موجود في نواة المنبع منذ 4.8 ، على ما أعتقد (https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d). و 4.9 و 4.10 بهما هذا الخطأ ، لذا فإن RedHat قد نقل بعض الإصلاحات من المنبع ، والتي ربما تحل بعض المشاكل ، ولكن بالتأكيد ليست كلها.

bcdonadio يمكنني إعادة إنتاج الخطأ على

#!/bin/sh

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

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

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

ينتج هذا البرنامج النصي فقط قائمة حزم باستخدام صورة في سجل Docker ، وآخر باستخدام واحدة تم إنشاؤها محليًا حتى أتمكن من مقارنتها. ملف Dockerfile هو هذا فقط:

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

بعد 2-4 دقائق يتلقى سجل النظام هذه الرسالة:

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

في آخر مرة حدث بعد بضع دقائق من تشغيل البرنامج النصي يدويًا. أعتقد أنه بعد انقضاء بعض المهلة بعد محاولة حذف الحاوية ، يتم رفع حالة الخطأ.

أنا متأكد من أن حالة الخطأ متقطعة ، لأن النص أعلاه يعمل كوظيفة cron في: 00 بعد كل خطأ. فيما يلي عينة من ناتج الخطأ الذي سجله سجل النظام:

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

لذلك يحدث ذلك في مكان ما في حدود 2 إلى 4 دقائق بعد تشغيل الحاويات والخروج منها ويتم حذفها بواسطة عامل الإرساء بسبب العلامة --rm. لاحظ أيضًا من السجل أعلاه أنه لا يوجد خطأ لكل حاوية يتم تشغيلها / حذفها ، لكنها متسقة إلى حد كبير.

هل من الممكن لشخص ما أن يرى ما إذا كان هذا التصحيح يحسن الأمور؟

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

hlrichardson هذا يبدو في الواقع مثل ذلك! سأحاول نقله إلى نواة 3.16 الخاصة بنا أو ترقية خوادم معينة وتجميع kernel 4.9 مع هذا التصحيح غدًا ، وسنرى كيف ستسير الأمور.

رغم ذلك ، بعد التحقق من الالتزام بمراجع هذا التصحيح (https://github.com/torvalds/linux/commit/0c1d70af924b966cc71e9e48920b2b635441aa50) - تم الالتزام به في 4.6 kernel ، بينما كانت المشكلة موجودة حتى من قبل :(

آه ، ربما لا يكون مرتبطًا ، ما لم تكن هناك أسباب متعددة (لسوء الحظ ، هناك العديد من الطرق التي يمكن بها تشغيل هذا النوع من الأخطاء ، لذلك هذا احتمال).

لقد واجهنا شخصيًا عدة مشكلات على الأقل هنا - في بعضها
تختفي سجلات "unregister_netdevice" بعد فترة من الوقت و
حاويات الرصيف قادرة على العمل بشكل جيد ، بينما في حاويات أخرى - جميع الحاويات
يتعطل الخادم ويحتاج إلى إعادة التشغيل.

في الواقع - نحن لا نستخدم vxlan على الخوادم التي تواجه هذه المشكلات - نستخدم ملفات
الجسور البسيطة وإعادة توجيه المنفذ (يحدث بغض النظر عن وكيل userland
الإعدادات).

في 30 مايو 2017 ، الساعة 22:54 ، كتب "hlrichardson" [email protected] :

آه ، ربما لا علاقة لها ، ما لم تكن هناك أسباب متعددة
(لسوء الحظ ، هناك العديد من الطرق التي يمكن من خلالها تشغيل هذا النوع من الأخطاء ، لذلك
هذا احتمال).

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/5618#issuecomment-304989068 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAGqoDHe1n3h9_eJ2kmeWcbhKRCX6rZoks5r_HPbgaJpZM4B4L4Z
.

حسنًا ، إذا كنت لا تستخدم أنفاق vxlan ، فلن يساعدك ذلك بالتأكيد.

راجع للشغل ، إذا رأيت مثيلًا واحدًا لرسالة "unregister_netdevice" عند حذف مساحة اسم الشبكة (خروج الحاوية) ، فيجب اعتباره موقفًا عاديًا حيث تم تنظيف شيء يشير إلى netdevice أكثر أو أقل في نفس الوقت
تم حذفه.

الحالة الأكثر خطورة هي حيث تتكرر هذه الرسالة كل 10 ثوانٍ ولا تتوقف أبدًا ...
في هذه الحالة ، يتم الاحتفاظ بالقفل العام إلى الأبد ، وبما أنه يجب الحصول على هذا القفل كلما كانت الشبكة
تتم إضافة مساحة الاسم أو حذفها ، وأي محاولة لإنشاء مساحة اسم للشبكة أو حذفها أيضًا
معلقة إلى الأبد.

إذا كانت لديك طريقة غير مؤلمة إلى حد ما لإعادة إنتاج النوع الثاني من المشاكل ، فسأكون مهتمًا بها
إلقاء نظرة.

hlrichardson نشاهد الحالة الثانية التي ذكرتها أعلاه على مجموعة من خوادمنا ، أي تتكرر الرسالة كل 10 ثوانٍ. ما هي المعلومات التي تريدني أن أشاركها؟

نرى هذا في Fedora 25 أثناء الاختبار وبناء centos: 7 حاويات أثناء استخدام yum. فشل Yum في إنهاء تنزيل قاعدة بيانات الحزمة وتوقف إلى أجل غير مسمى لأن الشبكة توقفت عن العمل بطريقة غريبة.

اهلا ياجماعة،

يوجد تصحيح محتمل لخلل kernel (أو واحد على الأقل من الأخطاء) في القائمة البريدية لـ Linux net-dev:

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

تم دمجه في شجرة الشبكة ، في قائمة الانتظار لشجرة مستقرة.

وفقًا لـ https://github.com/torvalds/linux/commit/d747a7a51b00984127a88113cdbbc26f91e9d815 - إنه في 4.12 (الذي تم إصداره أمس)!

fxposterkevinxucs سأحاول backporting هذا غدا سينت أو إس الحالية النواة.

أنا أقوم بتشغيل 4.12 (من http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12/) وما زلت أضرب هذا ، لذا يجب ألا يكون torvalds / linux @ d747a7a هو الإصلاح الكامل.

$ uname -r
4.12.0-041200-generic

رايان ، هل لديك طريقة موثوقة للتكاثر؟

في 6 يوليو 2017 الساعة 4:29 مساءً ، كتب "Ryan Campbell" [email protected] :

أنا أقوم بتشغيل 4.12 (من http://kernel.ubuntu.com/~
kernel-ppa / mainline / v4.12 /) وما زلت أضرب هذا ، لذا torvalds / linux @
d747a7a https://github.com/torvalds/linux/commit/d747a7a يجب ألا يكون
الإصلاح الكامل.

$ uname -r
4.12.0-041200 عام

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/5618#issuecomment-313413120 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAdcPCbVPDjPw6va-N5dM7CjYn2W4Bodks5sLO9ZgaJpZM4B4L4Z
.

justincormack لسوء الحظ ، ليس لدي مثال waiting for lo to become free in syslog) بعد عدد قليل من التكرارات.

campbellr لقد كنت أحاول إعادة عرض هذا الآن ثلاث مرات وقضيت جزءًا كبيرًا من هذا الأسبوع مع القليل من الحظ. تمكنت من الحصول على رسائل waiting for lo to become free بضع مرات ولكن بدون أعطال / توقف بعد ذلك. أحاول تقليل حالة الاختبار من خلال إنشاء مساحة اسم للشبكة وواجهات veth.

في مجموعة الاختبار الخاصة بك:

• هل تحتوي حاوياتك على الكثير من أنشطة الشبكة؟ إذا كان الأمر كذلك ، فما الاتجاه السائد؟
• ما نوع الجهاز الذي تقوم بتشغيله (عدد النوى ، هل هو جهاز افتراضي ، وما إلى ذلك)
• هل تقوم بإنشاء الكثير من الحاويات بشكل متزامن؟
• هل تخرج حاوياتك بشكل طبيعي أم أنها تتعطل؟

حتى الإجابات الجزئية لما ورد أعلاه قد تساعد في تضييق نطاقه ...
شكرا

لن يتم تعليق rn Docker بعد الآن لأنه يحدد مهلة على طلب netlink الذي عادةً ما يتعطل. لكنك لن تكون قادرًا على بدء تشغيل حاويات جديدة (أو إعادة تشغيل الحاويات الموجودة) ، فمن المحتمل أن يكون تنظيف الحاوية عند التوقف أمرًا غريبًا أيضًا.

لم تتح لي الفرصة للاختبار على 4.12 حتى الآن ، ولكن يمكنني إعادة الإنتاج بشكل موثوق على مثيلات kvm في vultr. أنا أركض سربًا وعمال الكروم مقطوعة الرأس يسببون المشاكل عندما يفشلون في الفحوصات الصحية أو يتعطلون بانتظام. بالطبع في هذه المرحلة ، لقد تعقبت جميع المتعطلين الذين يتعاملون مع أخطاء الشبكة بشكل نظيف وما إلى ذلك ، لذلك أرى waiting for lo to become free ولكن ليس كثيرًا ما يكفي لتعليق الأشياء لبضعة أسابيع.

لذلك يبدو أن الأشياء التي تساعد على التكاثر هي سيناريوهات شبكات أكثر تعقيدًا مقترنة بكميات كبيرة من حركة المرور في الحاويات وإعادة التدوير المستمر للحاويات و kvm.

rn لقد تمكنت من تضييق هذا الأمر إلى حاوية معينة في مجموعة الاختبار الخاصة بنا ، وتمكنت من إعادة الإنتاج باتباع الخطوات التالية:

1. بدء الحاوية (خدمة ويب داخلية قائمة على الإعصار - أحاول استخراج مثال بسيط لا يزال يضرب هذا)
2. تقديم طلب لخدمة الويب التي تعمل في الحاوية
3. انتظر الرد
4. قتل الحاوية

بعد 3 أو 4 تكرارات من هذا ، انتهى بي الأمر بالحصول على waiting for lo to become free وفي التكرار التالي ، فشل docker run مع docker: Error response from daemon: containerd: container did not start before the specified timeout.

هل تحتوي حاوياتك على الكثير من أنشطة الشبكة؟ إذا كان الأمر كذلك ، فما الاتجاه السائد؟

كمية صغيرة جدًا. في الخطوات المذكورة أعلاه ، طلب http عبارة عن مقدار صغير من json ، والاستجابة عبارة عن blob ثنائي يبلغ حجمه حوالي 10 ميجابايت.

ما نوع الجهاز الذي تقوم بتشغيله (عدد النوى ، هل هو جهاز افتراضي ، وما إلى ذلك)

هذا على جهاز سطح مكتب رباعي النواة (بدون جهاز افتراضي)

هل تقوم بإنشاء الكثير من الحاويات بشكل متزامن؟

لا ، كل شيء يتم بشكل متسلسل.

هل تخرج حاوياتك بشكل طبيعي أم أنها تتعطل؟

لقد تم إيقافهم بـ docker stop

1. بدء الحاوية (خدمة ويب داخلية قائمة على الإعصار - أحاول استخراج مثال بسيط لا يزال يضرب هذا)
2. تقديم طلب لخدمة الويب التي تعمل في الحاوية
3. انتظر الرد
4. قتل الحاوية

لقد أمضيت بعض الوقت في تجريد الحاوية واتضح أن خدمة الويب لا علاقة لها بهذا الخطأ. ما يبدو أنه يؤدي إلى هذا في حالتي هو تحميل مشاركة NFS داخل حاوية (تعمل بـ --privileged ).

على سطح المكتب الخاص بي ، يمكنني إعادة إنتاج ما يلي بشكل موثوق به ببساطة عدة مرات:

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

بالنسبة لمستخدمي Kubernetes ، فتحت مشكلة لـ _kops_ لإصدار Kubernetes AMI التالي مع إصدار Kernel 4.12. مرحبًا بكم في التحقق من ذلك: https://github.com/kubernetes/kops/issues/2901

لقد ضربت هذا أيضًا على centos 7.3 مع المضيف kernel 3.10.0-514.6.1.el7.x86_64 و docker-ce-17.06.0.ce-1.el7.centos.x86_64.

تضمين التغريدة للمشاركة بشكل مفيد في هذا الموضوع ، يرجى تقديم طريقة دقيقة لإعادة إنتاج هذه المشكلة ، والرجاء اختبارها على نواة حديثة. تم إصدار 3.10 قبل أربع سنوات ، ونحن نناقش حول ما إذا كان ثابتًا أو جزئيًا في إصدار منذ أربعة أيام.

danielgusmao لدينا RancherOS و AWS ECS AMI linux OS لديها بالفعل هذا "الإصلاح" في مكانه (ربما كان الافتراضي) ولا يحل المشكلة بالنسبة لنا. ما زلنا نرى الرسالة تظهر في السجلات طوال الوقت. من المحتمل أن يكون الأمل الوحيد هو أن يتم نقل تصحيح النواة على نطاق واسع. على الرغم من أنني بحثت في كل مكان ولا يمكنني رؤية أي دليل على تقدم جاد نحو ذلك حتى الآن في RedHat / Centos / AWS linux bugzillas والمنتديات.

لكي نكون واضحين ، الرسالة نفسها حميدة ، إنها تعطل النواة بعد الرسائل التي أبلغت عنها OP وهي ليست كذلك.

التعليق في الكود ، من أين تأتي هذه الرسالة ، يوضح ما يحدث. يقوم كل مستخدم بشكل أساسي ، مثل مكدس IP) لجهاز الشبكة (مثل نهاية زوج veth داخل حاوية) بزيادة عدد المرجع في بنية جهاز الشبكة عند استخدام جهاز الشبكة. عند إزالة الجهاز (على سبيل المثال ، عند إزالة الحاوية) يتم إخطار كل مستخدم حتى يتمكن من إجراء بعض التنظيف (مثل إغلاق المقابس المفتوحة وما إلى ذلك) قبل إنقاص العدد المرجعي. نظرًا لأن هذا التنظيف قد يستغرق بعض الوقت ، خاصةً في ظل الحمل الثقيل (الكثير من الواجهة ، والكثير من الاتصالات وما إلى ذلك) ، فقد تطبع kernel الرسالة هنا من حين لآخر.

إذا لم يقلل مستخدم جهاز الشبكة من عدد المرجع ، سيحدد جزء آخر من النواة أن المهمة التي تنتظر التنظيف عالقة وستتعطل. إن هذا الانهيار فقط هو الذي يشير إلى خطأ في kernel (بعض المستخدمين ، عبر بعض مسارات الكود ، لم يقللوا عدد المرجع). كان هناك العديد من هذه الأخطاء وتم إصلاحها في النواة الحديثة (وربما تم إرجاعها إلى الأقدم). لقد كتبت عددًا قليلاً من اختبارات الإجهاد (وأواصل كتابتها) لإثارة مثل هذه الأعطال ولكن لم أتمكن من التكاثر على النوى الحديثة (لكني أفعل الرسالة أعلاه).

الرجاء الإبلاغ عن هذه المشكلة فقط في حالة تعطل النواة الخاصة بك بالفعل ، ومن ثم سنكون مهتمين جدًا بما يلي:

• إصدار kernel (ناتج uname -r )
• توزيع / إصدار Linux
• هل تستخدم أحدث إصدار من kernel لبائع Linux الخاص بك؟
• إعداد الشبكة (جسر ، تراكب ، IPv4 ، IPv6 ، إلخ)
• وصف عبء العمل (ما نوع الحاويات ، وما نوع تحميل الشبكة ، وما إلى ذلك)
• ومن الناحية المثالية استنساخ بسيط

شكرا

[ thaJeztah ، هل يمكنك تغيير العنوان إلى شيء مثل kernel crash after "unregister_netdevice: waiting for lo to become free. Usage count = 3" لجعله أكثر وضوحًا]

يجب إصلاحه في kernel 4.12 أو متأخرًا. يرجى المراجعة. https://access.redhat.com/solutions/3105941
و رابط التصحيح https://github.com/torvalds/linux/commit/d747a7a51b00984127a88113cdbbc26f91e9d815

drweber ستجد هذا التصحيح أيضًا في الإصدارات المستقرة القادمة (حاليًا 4.11.12 ، 4.9.39 ، 4.4.78 ، 3.18.62)

rn

إذا لم يقلل مستخدم جهاز الشبكة من عدد المرجع ، سيحدد جزء آخر من النواة أن المهمة التي تنتظر التنظيف عالقة وستتعطل. إن هذا الانهيار فقط هو الذي يشير إلى خطأ في kernel (بعض المستخدمين ، عبر بعض مسارات الكود ، لم يقللوا عدد المرجع). كان هناك العديد من هذه الأخطاء وتم إصلاحها في النواة الحديثة (وربما تم إرجاعها إلى الأقدم). لقد كتبت عددًا قليلاً من اختبارات الإجهاد (وأواصل كتابتها) لإثارة مثل هذه الأعطال ولكن لم أتمكن من التكاثر على النوى الحديثة (لكني أفعل الرسالة أعلاه).

الرجاء الإبلاغ عن هذه المشكلة فقط في حالة تعطل النواة الخاصة بك بالفعل ...

نواجه مشكلة مختلفة قليلاً في بيئتنا وآمل أن أحصل على بعض التوضيح حول (kernel 3.16.0-77-generic ، Ubuntu 14.04 ، docker 1.12.3-0 ~ Trusty. لدينا الآلاف من المضيفين الذين يقومون بتشغيل عامل الإرساء ، 2 -3 حاويات لكل مضيف ، ونحن نشهد هذا على <1٪ من إجمالي المضيفين الذين يقومون بتشغيل عامل الإرساء).

في الواقع ، لا نرى تعطل kernel مطلقًا ، ولكن بدلاً من ذلك (مثل المراسلين الأصليين بقدر ما أستطيع أن أقول) عملية dockerd لم تعد موجودة. مبتدئ (باستخدام الوظيفة /etc/init/docker.conf من الحزمة الأولية) لن يبدأ عملية dockerd لأنه يعتقد أنها قيد التشغيل بالفعل ( start: Job is already running: docker ) ، ومحاولة إيقاف مغرور فشلت الوظيفة أيضًا ( docker start/killed, process <pid of defunct process> ).

$ ps -ely
S   UID   PID  PPID  C PRI  NI   RSS    SZ WCHAN  TTY          TIME CMD
...
Z     0 28107     1  0  80   0     0     0 -      ?        00:18:05 dockerd <defunct>

نظرًا لأننا نستخدم في الغالب شبكات الجسر (على جهاز جسر مخصص) في dmesg فإننا نرى رسالة مختلفة قليلاً تشير إلى الواجهة الافتراضية:

[7895942.484851] unregister_netdevice: waiting for vethb40dfbc to become free. Usage count = 1
[7895952.564852] unregister_netdevice: waiting for vethb40dfbc to become free. Usage count = 1
[7895962.656984] unregister_netdevice: waiting for vethb40dfbc to become free. Usage count = 1

نظرًا لأن المبتدئ يبدو أنه يرفض إعادة تشغيل dockerd أو يدرك أن العملية التي كانت قيد التشغيل سابقًا هي زومبي ، فإن الحل الوحيد الذي وجدناه هو إعادة تشغيل المضيف.

في حين أن نتائجنا تبدو مختلفة (النواة لا تتعطل) ، فإن السبب الجذري يبدو متشابهًا أو متشابهًا. أليست هذه هي القضية نفسها إذن؟ هل هناك أي حل بديل أو طريقة لجعل المهمة المبتدئة docker تصبح قابلة للتشغيل مرة أخرى عند حدوث ذلك؟

campbellr يمكنني إعادة إنتاج هذه المشكلة بنهجك على kernel 4.12.2-1.
راجع للشغل ، إذا قمت بإلغاء تحميل تخزين NFS قبل إيقاف الحاوية ، فلن تحدث هذه المشكلة.

نفس المشكلة.

[root<strong i="6">@docker1</strong> ~]# cat /etc/redhat-release 
CentOS Linux release 7.3.1611 (Core) 
[root<strong i="7">@docker1</strong> ~]# uname  -r
3.10.0-514.26.2.el7.x86_64
[root<strong i="8">@docker1</strong> ~]# docker version
Client:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-1.12.6-32.git88a4867.el7.centos.x86_64
 Go version:      go1.7.4
 Git commit:      88a4867/1.12.6
 Built:           Mon Jul  3 16:02:02 2017
 OS/Arch:         linux/amd64

Server:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-1.12.6-32.git88a4867.el7.centos.x86_64
 Go version:      go1.7.4
 Git commit:      88a4867/1.12.6
 Built:           Mon Jul  3 16:02:02 2017
 OS/Arch:         linux/amd64

أهلا،

لقد قمت للتو بإنشاء مستودعات 2 https://github.com/piec/docker-samba-loop و https://github.com/piec/docker-nfs-loop التي تحتوي على الإعداد اللازم لإعادة إنتاج هذا الخطأ

نتائجي:

• 4.11.3-1-ARCH (Arch Linux) kernel: لقد قمت بإنشاء الخطأ باستخدام docker-samba-loop في عدد قليل من التكرارات (<10). لا يمكنني إعادة إنتاجه باستخدام docker-nfs-loop
• 4.11.9-1-ARCH نفس النتائج ( الإصدارات )
• 4.12.3-1-ARCH (اختبار الريبو) نفس النتائج
• 4.11.11-coreos: نفس النتائج لـ docker-samba-loop ، لم أحاول docker-nfs-loop

أتمنى أن يساعدك هذا
هتافات

الحل هو استخدام --net=host في حالتي. لكنه ليس دائمًا حلاً مقبولاً

@ قطعة ، شكرًا جزيلاً على التفاصيل. لدي بعض الأسئلة الإضافية لك في نهاية هذا التعليق الطويل جدًا.

باستخدام إعداد SMB ، تمكنت من إنتاج عدد من الأشياء بنواة مختلفة. لقد جربت هذا أيضًا مع إعداد NFS ولكن بدون نرد.

يتم تشغيل جميع الاختبارات باستخدام Docker 17.06.1-ce على HyperKit مع جهاز افتراضي مكون من وحدتي vCPU وذاكرة 2GB (عبر Docker لنظام التشغيل Mac ، ولكن لا ينبغي أن يكون ذلك مهمًا). أنا أستخدم نواة LinuxKit ، لأنه يمكنني استبدالها بسهولة.

لقد قمت بتعديل Dockerfile حيث أضفت مكالمة إلى date كأول أمر تم تنفيذه وأضفت أيضًا مكالمة إلى date قبل وبعد docker run لـ زبون.

التجربة 1 (4.9.39 نواة)

مع 4.9.39 (أحدث نواة مستقرة 4.9.x) ، أحصل على تعطل kernel:

# while true; do  date;    docker run -it --rm --name client-smb --cap-add=SYS_ADMIN --cap-add DAC_READ_SEARCH --link samba:samba client-smb:1;  date;   sleep 1; done
Thu 27 Jul 2017 14:12:51 BST
+ date
Thu Jul 27 13:12:52 UTC 2017
+ mount.cifs //172.17.0.2/public /mnt/ -o vers=3.0,user=nobody,password=
+ date
Thu Jul 27 13:12:52 UTC 2017
+ ls -la /mnt
total 1028
drwxr-xr-x    2 root     root             0 Jul 27 10:11 .
drwxr-xr-x    1 root     root          4096 Jul 27 13:12 ..
-rwxr-xr-x    1 root     root             3 Jul 27 10:11 bla
+ umount /mnt
+ echo umount ok
umount ok
Thu 27 Jul 2017 14:12:52 BST
Thu 27 Jul 2017 14:12:53 BST

---> First iteration suceeds and then hangs on the docker run

و dmesg :

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

في بعض الأحيان ، أرى عدة تكرارات لما تقوم به النواة 4.11.12 ، بما في ذلك الرسائل unregister_netdevice (انظر أدناه) ثم الحصول على تعطل kernel أعلاه. أرى أحيانًا اختلافات طفيفة في الحادث ، مثل:

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

الأعطال في رمز مقبس مجال يونكس ومماثلة / متطابقة لما هو موجود
تم الإبلاغ عنها هنا ، على الرغم من أنه مع حالة الاختبار الجديدة هذه ، فإنه من الأسهل بكثير إعادة الإنتاج.

التجربة 2 (4.11.12 نواة)

مع الإصدار 4.11.12 (وهو أحدث إصدار ثابت في سلسلة 4.11) ، لا أرى أي أعطال ، ولكنه بطيء حقًا (التعليقات التوضيحية مضمنة مع ---> ):

# while true; do  date;    docker run -it --rm --name client-smb --cap-add=SYS_ADMIN --cap-add DAC_READ_SEARCH --link samba:samba client-smb:1;  date;   sleep 1; done
Thu 27 Jul 2017 13:48:04 BST
+ date
Thu Jul 27 12:48:05 UTC 2017
+ mount.cifs //172.17.0.2/public /mnt/ -o vers=3.0,user=nobody,password=
+ date
Thu Jul 27 12:48:05 UTC 2017
+ ls -la /mnt
total 1028
drwxr-xr-x    2 root     root             0 Jul 27 10:11 .
drwxr-xr-x    1 root     root          4096 Jul 27 12:48 ..
-rwxr-xr-x    1 root     root             3 Jul 27 10:11 bla
+ umount /mnt
+ echo umount ok
umount ok
Thu 27 Jul 2017 13:48:05 BST

---> First iteration takes one second

Thu 27 Jul 2017 13:48:06 BST
docker: Error response from daemon: containerd: container did not start before the specified timeout.
Thu 27 Jul 2017 13:50:07 BST

---> Second iteration fails after 2 minutes with dockerd unable to start the container

Thu 27 Jul 2017 13:50:08 BST
+ date
Thu Jul 27 12:51:52 UTC 2017
+ mount.cifs //172.17.0.2/public /mnt/ -o vers=3.0,user=nobody,password=
+ date
Thu Jul 27 12:51:53 UTC 2017
+ ls -la /mnt
total 1028
drwxr-xr-x    2 root     root             0 Jul 27 10:11 .
drwxr-xr-x    1 root     root          4096 Jul 27 12:50 ..
-rwxr-xr-x    1 root     root             3 Jul 27 10:11 bla
+ umount /mnt
+ echo umount ok
umount ok
Thu 27 Jul 2017 13:51:53 BST

---> Third iterations succeeds, BUT it takes almost 2 minutes between docker run and the container running

Thu 27 Jul 2017 13:51:54 BST
docker: Error response from daemon: containerd: container did not start before the specified timeout.
Thu 27 Jul 2017 13:53:55 BST

---> Fourth iteration fails after two minutes

Thu 27 Jul 2017 13:53:56 BST
+ date
Thu Jul 27 12:55:37 UTC 2017
+ mount.cifs //172.17.0.2/public /mnt/ -o vers=3.0,user=nobody,password=
+ date
Thu Jul 27 12:55:37 UTC 2017
+ ls -la /mnt
total 1028
drwxr-xr-x    2 root     root             0 Jul 27 10:11 .
drwxr-xr-x    1 root     root          4096 Jul 27 12:53 ..
-rwxr-xr-x    1 root     root             3 Jul 27 10:11 bla
+ umount /mnt
+ echo umount ok
umount ok
Thu 27 Jul 2017 13:55:38 BST

---> Fifth iteration succeeds, but almost 2 minutes between docker run and the container executing

لقد كان هذا يعمل لمدة ساعة أو نحو ذلك مع تكرار نفس النمط ، ولكن بدون تحطم kernel.

أنا سجلات النواة التي أراها ، الكثير من:

[   84.940380] unregister_netdevice: waiting for lo to become free. Usage count = 1
[   95.082151] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  105.253289] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  115.477095] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  125.627059] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  135.789298] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  145.969455] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  156.101126] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  166.303333] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  176.445791] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  186.675958] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  196.870265] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  206.998238] unregister_netdevice: waiting for lo to become free. Usage count = 1
[...]

هذه رسالة كل عشر ثوان.

نظرًا لأن هذا لا يتسبب في بدء اكتشاف المهمة المعلقة حتى بعد ساعة ، أظن أنه مع 4.11.12 يتناقص العدد المرجعي في النهاية ويتم تحرير الجهاز ، ولكن وفقًا للفترات الفاصلة التي يمكنني فيها تشغيل الحاويات ، فقد يستغرق الأمر تصل إلى 4 دقائق!

التجربة 3 (4.11.12 نواة)

أشار تعطل kernel في OP إلى تعطل kernel بسبب اكتشاف مهمة معلقة. لم أشاهد هذا التعطل أثناء الاختبار ، لذلك قمت بتغيير إعداد sysctl المتعلق باكتشاف المهمة المعلقة:

# sysctl -a | grep kernel.hung_task
kernel.hung_task_check_count = 4194304
kernel.hung_task_panic = 0
kernel.hung_task_timeout_secs = 120
kernel.hung_task_warnings = 10
# sysctl -w kernel.hung_task_timeout_secs = 60
# sysctl -w kernel.hung_task_panic=1

يؤدي هذا إلى تقليل المهلة إلى 60 ثانية ويثير الذعر للنواة إذا تم اكتشاف مهمة معلقة. نظرًا لأن الأمر يستغرق حوالي دقيقتين قبل أن يشتكي dockerd من أن containerd لم يبدأ ، فإن تقليل اكتشاف المهمة المعلقة إلى 60 ثانية يجب أن يؤدي إلى حالة من الذعر في kernel إذا تم تعليق مهمة واحدة. للأسف لم يكن هناك عطل في السجلات

التجربة 4 (4.11.12 نواة)

بعد ذلك ، أقوم بزيادة sleep بعد كل docker run إلى 5 دقائق لمعرفة ما إذا كانت الرسائل مستمرة. في هذه الحالة ، يبدو أن جميع docker run s تعمل ، وهو أمر متوقع نوعًا ما لأنه من التجارب السابقة ، سيعمل docker run كل 4 دقائق أو نحو ذلك

---> This is after the first run
[  281.406660] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  291.455945] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  301.721340] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  311.988572] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  322.258805] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  332.527383] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  342.796511] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  353.059499] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  363.327472] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  373.365562] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  383.635923] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  393.684949] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  403.950186] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  414.221779] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  424.490110] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  434.754925] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  445.022243] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  455.292106] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  465.557462] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  475.826946] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  486.097833] unregister_netdevice: waiting for lo to become free. Usage count = 1

---> 200+ seconds of messages and then nothing for almost 400 seconds

[  883.924399] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  893.975810] unregister_netdevice: waiting for lo to become free. Usage count = 1
...
[ 1088.624065] unregister_netdevice: waiting for lo to become free. Usage count = 1
[ 1098.891297] unregister_netdevice: waiting for lo to become free. Usage count = 1

---> 200+ seconds of messages and then a gap of 90 seconds

[ 1185.119327] unregister_netdevice: waiting for lo to become free. Usage count = 1
[ 1195.387962] unregister_netdevice: waiting for lo to become free. Usage count = 1
...
[ 1390.040035] unregister_netdevice: waiting for lo to become free. Usage count = 1
[ 1400.307359] unregister_netdevice: waiting for lo to become free. Usage count = 1

---> 200+ seconds of messages and then a gap of 80+ seconds

[ 1486.325724] unregister_netdevice: waiting for lo to become free. Usage count = 1
[ 1496.591715] unregister_netdevice: waiting for lo to become free. Usage count = 1
...
[ 1680.987216] unregister_netdevice: waiting for lo to become free. Usage count = 1
[ 1691.255068] unregister_netdevice: waiting for lo to become free. Usage count = 1

---> 200+ seconds of messages and then a gap of 90+ seconds

[ 1787.547334] unregister_netdevice: waiting for lo to become free. Usage count = 1
[ 1797.819703] unregister_netdevice: waiting for lo to become free. Usage count = 1

يبدو أننا نحصل على ما يقرب من 200 ثانية بقيمة unregister_netdevice على كل docker run (باستثناء الثانية). أظن أنه خلال ذلك الوقت لا يمكننا بدء حاويات جديدة (كما هو موضح في التجربة 2. من الغريب أن اكتشاف المهمة المعلقة لا يبدأ ، ربما بسبب عدم تعليق أي مهمة.

التجربة 5 (4.11.12 / 4.9.39 مع تمكين تصحيح أخطاء إضافي في kernel)

هذا يعود إلى نوم 1s بين docker run

لدينا نواة أخرى أتاحت مجموعة من التصحيح الإضافي
الخيارات ، مثل LOCKDEP و RCU_TRACE و LOCKUP_DETECTOR وعدد قليل
أكثر.

لم يؤدي تشغيل repro 4.11.12 kernels مع تمكين خيارات التصحيح هذه إلى تشغيل أي شيء.

الشيء نفسه بالنسبة للنواة 4.9.39 ، حيث تتعطل النواة العادية. تعمل خيارات التصحيح على تغيير التوقيت بشكل طفيف ، لذلك ربما يكون هذا دليلًا إضافيًا على أن التعطل في رمز مقبس مجال unix الذي يظهر بسبب سباق.

الحفر أعمق قليلا

strace على مختلف العمليات containerd غير مفيد (إنه
عادة ليس لأنه مكتوب في Go). الكثير من الأكشاك الطويلة في
futex(...FUTEX_WAIT...) مع أي معلومات حول مكان / لماذا.

البعض يتجول بـ sysrq :

زيادة الإسهاب:

echo 9 > /proc/sysrq-trigger

تتبع المكدس من جميع وحدات المعالجة المركزية (CPU):

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

لا شيء هنا ، CPU1 خامل ، CPU0 يتعامل مع sysrq.

إظهار المهام المحظورة (مرتين)

echo w > /proc/sysrq-trigger
[  467.167062] sysrq: SysRq : Show Blocked State
[  467.167731]   task                        PC stack   pid father
[  467.168580] kworker/u4:6    D    0   293      2 0x00000000
[  467.169096] Workqueue: netns cleanup_net
[  467.169487] Call Trace:
[  467.169732]  __schedule+0x582/0x701
[  467.170073]  schedule+0x89/0x9a
[  467.170338]  schedule_timeout+0xbf/0xff
[  467.170666]  ? del_timer_sync+0xc1/0xc1
[  467.171011]  schedule_timeout_uninterruptible+0x2a/0x2c
[  467.171422]  ? schedule_timeout_uninterruptible+0x2a/0x2c
[  467.171866]  msleep+0x1e/0x22
[  467.172155]  netdev_run_todo+0x173/0x2c4
[  467.172499]  rtnl_unlock+0xe/0x10
[  467.172770]  default_device_exit_batch+0x13c/0x15f
[  467.173226]  ? __wake_up_sync+0x12/0x12
[  467.173550]  ops_exit_list+0x29/0x53
[  467.173850]  cleanup_net+0x1a8/0x261
[  467.174153]  process_one_work+0x276/0x4fb
[  467.174487]  worker_thread+0x1eb/0x2ca
[  467.174800]  ? rescuer_thread+0x2d9/0x2d9
[  467.175136]  kthread+0x106/0x10e
[  467.175406]  ? __list_del_entry+0x22/0x22
[  467.175737]  ret_from_fork+0x2a/0x40
[  467.176167] runc:[1:CHILD]  D    0  2609   2606 0x00000000
[  467.176636] Call Trace:
[  467.176849]  __schedule+0x582/0x701
[  467.177152]  schedule+0x89/0x9a
[  467.177451]  schedule_preempt_disabled+0x15/0x1e
[  467.177827]  __mutex_lock+0x2a0/0x3ef
[  467.178133]  ? copy_net_ns+0xbb/0x17c
[  467.178456]  mutex_lock_killable_nested+0x1b/0x1d
[  467.179068]  ? mutex_lock_killable_nested+0x1b/0x1d
[  467.179489]  copy_net_ns+0xbb/0x17c
[  467.179798]  create_new_namespaces+0x12b/0x19b
[  467.180151]  unshare_nsproxy_namespaces+0x8f/0xaf
[  467.180569]  SyS_unshare+0x17b/0x302
[  467.180925]  entry_SYSCALL_64_fastpath+0x1f/0xc2
[  467.181303] RIP: 0033:0x737b97
[  467.181559] RSP: 002b:00007fff1965ab18 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
[  467.182182] RAX: ffffffffffffffda RBX: 0000000002277bd8 RCX: 0000000000737b97
[  467.182805] RDX: 0000000000000000 RSI: 0000000000867a0f RDI: 000000006c020000
[  467.183368] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[  467.184014] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[  467.184639] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[  477.286653] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  487.457828] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  497.659654] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  507.831614] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  518.030241] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  528.232963] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  538.412263] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  548.583610] unregister_netdevice: waiting for lo to become free. Usage count = 1
echo w > /proc/sysrq-trigger
[  553.969592] sysrq: SysRq : Show Blocked State
[  553.970411]   task                        PC stack   pid father
[  553.971208] kworker/u4:6    D    0   293      2 0x00000000
[  553.971686] Workqueue: netns cleanup_net
[  553.972058] Call Trace:
[  553.972305]  __schedule+0x582/0x701
[  553.972690]  schedule+0x89/0x9a
[  553.973039]  schedule_timeout+0xbf/0xff
[  553.973462]  ? del_timer_sync+0xc1/0xc1
[  553.973890]  schedule_timeout_uninterruptible+0x2a/0x2c
[  553.974706]  ? schedule_timeout_uninterruptible+0x2a/0x2c
[  553.975244]  msleep+0x1e/0x22
[  553.975539]  netdev_run_todo+0x173/0x2c4
[  553.975950]  rtnl_unlock+0xe/0x10
[  553.976303]  default_device_exit_batch+0x13c/0x15f
[  553.976725]  ? __wake_up_sync+0x12/0x12
[  553.977121]  ops_exit_list+0x29/0x53
[  553.977501]  cleanup_net+0x1a8/0x261
[  553.977869]  process_one_work+0x276/0x4fb
[  553.978245]  worker_thread+0x1eb/0x2ca
[  553.978578]  ? rescuer_thread+0x2d9/0x2d9
[  553.978933]  kthread+0x106/0x10e
[  553.979283]  ? __list_del_entry+0x22/0x22
[  553.979774]  ret_from_fork+0x2a/0x40
[  553.980244] runc:[1:CHILD]  D    0  2609   2606 0x00000000
[  553.980728] Call Trace:
[  553.980949]  __schedule+0x582/0x701
[  553.981254]  schedule+0x89/0x9a
[  553.981533]  schedule_preempt_disabled+0x15/0x1e
[  553.981917]  __mutex_lock+0x2a0/0x3ef
[  553.982220]  ? copy_net_ns+0xbb/0x17c
[  553.982524]  mutex_lock_killable_nested+0x1b/0x1d
[  553.982909]  ? mutex_lock_killable_nested+0x1b/0x1d
[  553.983311]  copy_net_ns+0xbb/0x17c
[  553.983606]  create_new_namespaces+0x12b/0x19b
[  553.983977]  unshare_nsproxy_namespaces+0x8f/0xaf
[  553.984363]  SyS_unshare+0x17b/0x302
[  553.984663]  entry_SYSCALL_64_fastpath+0x1f/0xc2
[  553.985080] RIP: 0033:0x737b97
[  553.985306] RSP: 002b:00007fff1965ab18 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
[  553.985861] RAX: ffffffffffffffda RBX: 0000000002277bd8 RCX: 0000000000737b97
[  553.986383] RDX: 0000000000000000 RSI: 0000000000867a0f RDI: 000000006c020000
[  553.986811] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[  553.987182] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[  553.987551] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
/ # [  558.844761] unregister_netdevice: waiting for lo to become free. Usage count = 1

يوضح هذا أن كلاً من قوائم انتظار العمل netns و cleanup_net مشغولة. لقد وجدت مشكلة ذات صلة إلى حد ما منذ فترة طويلة هنا ، ولكن هذه المرة قائمة عمل cleanup_net في حالة مختلفة.

ملخص

• أعتقد أن التعطل في نواة 4.9.x غير مرتبط ولكن يبدو أنه تم إصلاحه في 4.11.x. هذا يحتاج إلى مزيد من الفرز.
• على عكس بعض التقارير السابقة ، لم يتم الإبلاغ عن أي مهام معلقة ، ولكن من الصعب معرفة ذلك نظرًا لوجود عدد قليل جدًا من تتبعات المكدس حول هذه المشكلة.
• تم حظر شيء ما لفترة طويلة جدًا (2-4 دقائق). من المحتمل أن يكون مرتبطًا بحالة قائمة الانتظار
• يحتاج تفريغ قائمة العمل إلى مزيد من التحليل ، خاصةً سبب بقاء قائمة العمل في تلك الحالة لفترة طويلة.
• تبدو الرسائل unregister_netdev غير مرتبطة بالإصلاح الأخير (الموجود في كل من 4.9.39 و 4.11.12). ربما يرجع ذلك إلى أن قائمة انتظار العمل cleanup_net لا تتقدم ، وبالتالي تتم طباعة الرسالة.
• من غير الواضح تمامًا كيف / لماذا يقوم SMB بإثارة ذلك. لقد كتبت حوالي 60 اختبار جهد فردي لمساحات أسماء الشبكات وأحمال عمل مختلفة ولم أتمكن من إثارة أي مشكلات. استندت الاختبارات إلى runc ، ربما يجب أن أحاول containerd .

سأحفر أكثر قليلاً ثم أرسل ملخصًا إلى netdev .

piec هل لديك حق الوصول إلى وحدة التحكم ويمكنك معرفة ما إذا كان هناك أي شيء فيما يتعلق بتفريغ الأعطال أو هل ترى أيضًا تأخيرات ضخمة كما أرى؟ إذا كان لديك مكب نفايات ، سأكون مهتمًا جدًا برؤيته. أيضا ، هل تعمل على المعدن أو في VM؟ ما هو التكوين الخاص بك من حيث وحدات المعالجة المركزية والذاكرة؟

rn شكرا على التحقيقات!

أنا أعمل على كمبيوتر مكتبي baremetal حتى أتمكن من الوصول إلى كل شيء. إنه i7-4790K + 32 جيجا بايت.
أعمل حاليًا على نواة Arch Linux + محدّثة من ريبو الاختبار (4.12.3-1-ARCH)

في حالتي ، يتصرف كل شيء كما وصفته في تجربتك 2 (4.11.12 kernel):

• بعد وجود حاوية client-smb ، من المستحيل تشغيل حاويات جديدة لمدة تزيد عن 4 دقائق.
• ليس لدي أي أعطال نواة
• تظهر الرسالة unregister_netdevice: waiting for lo to become free. Usage count = 1 بشكل متكرر إذا حاولت تشغيل أي حاوية جديدة في أكثر من 4 دقائق تأخير بعد خروج العميل الصغير. ولا يظهر إلا إذا قمت بتشغيل حاوية جديدة في تلك الفترة الزمنية التي تبلغ 4 دقائق. سيكون تشغيل حاوية جديدة بعد هذه الدقائق الأربع "طبيعيًا"

لذلك أفترض أن هناك مشكلة في مكان ما في عملية تنظيف حاوية عميل SMB المتعلقة بواجهات الشبكة

هناك في الواقع نسخة أبسط بكثير من هذه المشكلة (والتي ، راجع للشغل ليس هو الإصدار الأصلي).

يبدأ هذا البرنامج النصي للتو خادم SMB على المضيف ثم ينشئ مساحة اسم شبكة بزوج veth ، وينفذ mount; ls; unmount في مساحة اسم الشبكة ثم يزيل مساحة اسم الشبكة.

apk add --no-cache iproute2 samba samba-common-tools cifs-utils

# SMB server setup
cat <<EOF > /etc/samba/smb.conf
[global]
    workgroup = WORKGROUP
    netbios name = FOO
    passdb backend = tdbsam
    security = user
    guest account = nobody
    strict locking = no
    min protocol = SMB2
[public]
    path = /share
    browsable = yes
    read only = no
    guest ok = yes
    browseable = yes
    create mask = 777
EOF
adduser -D -G nobody nobody && smbpasswd -a -n nobody
mkdir /share && chmod ugo+rwx /share && touch /share/foo
chown -R nobody.nobody /share

# Bring up a veth pair
ip link add hdev type veth peer name nsdev
ip addr add 10.0.0.1/24 dev hdev
ip link set hdev up

# Start SMB server and sleep for it to serve
smbd -D; sleep 5

# Client setup
ip netns add client-ns
ip link set nsdev netns client-ns
ip netns exec client-ns ip addr add 10.0.0.2/24 dev nsdev
ip netns exec client-ns ip link set lo up
ip netns exec client-ns ip link set nsdev up
sleep 1 # wait for the devices to come up

# Execute (mount, ls, unmount) in the network namespace and a new mount namespace
ip netns exec client-ns unshare --mount \
    /bin/sh -c 'mount.cifs //10.0.0.1/public /mnt -o vers=3.0,guest; ls /mnt; umount /mnt'

# Delete the client network namespace.
ip netns del client-ns

# Create a new network namespace
# This will stall for up to 200s
ip netns add new-netns

لاحظ أن إضافة sleep 1 بسيط بعد إلغاء التحميل ، إما عند التنفيذ في مساحة الاسم أو قبل حذف مساحة اسم الشبكة يعمل دون توقف على الإطلاق عند إنشاء مساحة الاسم الجديدة. النوم بعد حذف مساحة الاسم القديمة ، لا يقلل من المماطلة.

piec لقد اختبرت هذا أيضًا مع ملفك و sleep 1 في Dockerfile بعد إلغاء التثبيت ويعمل كل شيء كما هو متوقع ، بدون توقف ، لا رسائل unregister_netdev .

سأكتب هذا الآن وأرسله إلى netdev@vger

ممتاز
أؤكد أن sleep بعد إلغاء تثبيت إصلاحات المماطلة ورسائل unregister_netdev في الإعداد الخاص بي أيضًا

ألا تعتقد أن umount يولد إجراءً غير متزامن بالنسبة لشبكاته التي ستمنع وتنتهي في النهاية إذا تمت إزالة الشبكات قبل انتهاء هذا الإجراء؟ النوم بعد التثبيت سيسمح لهذه الأشياء بالانتهاء قبل إزالة الشبكات.
لكن هذه مجرد فرضية

حاولت بدون تحميل ، نفس الاختلاف. إنه حذف مساحة اسم الشبكة. سيؤدي ذلك 9 وإزالة مساحة اسم التحميل إلى تشغيل إلغاء التحميل على أي حال.

آه طيب

بالمناسبة ، أعدت إنتاج المشكلة عن طريق الخطأ (أثناء التطوير) على جهاز آخر باستخدام SMB مرة أخرى. إنه جهاز كمبيوتر Ubuntu 16.04 ، Linux 4.4.0-77 عام. وهناك تتبع خلفي لمهمة معلق قد يكون ممتعًا. لا تحطم ونفس ~ 4 دقائق تأخير.

[6409720.564230] device vethff6396b entered promiscuous mode
[6409720.564415] IPv6: ADDRCONF(NETDEV_UP): vethff6396b: link is not ready
[6409723.844595] unregister_netdevice: waiting for lo to become free. Usage count = 1
[6409726.812872] INFO: task exe:17732 blocked for more than 120 seconds.
[6409726.812918]       Tainted: P           O    4.4.0-77-generic #98-Ubuntu
[6409726.812959] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[6409726.813007] exe             D ffff8809952bbcb8     0 17732      1 0x00000000
[6409726.813013]  ffff8809952bbcb8 ffffffff821d9a20 ffff88103856c600 ffff880ffae2d400
[6409726.813018]  ffff8809952bc000 ffffffff81ef7724 ffff880ffae2d400 00000000ffffffff
[6409726.813021]  ffffffff81ef7728 ffff8809952bbcd0 ffffffff81837845 ffffffff81ef7720
[6409726.813025] Call Trace:
[6409726.813036]  [<ffffffff81837845>] schedule+0x35/0x80
[6409726.813040]  [<ffffffff81837aee>] schedule_preempt_disabled+0xe/0x10
[6409726.813044]  [<ffffffff81839729>] __mutex_lock_slowpath+0xb9/0x130
[6409726.813048]  [<ffffffff818397bf>] mutex_lock+0x1f/0x30
[6409726.813053]  [<ffffffff81726a2e>] copy_net_ns+0x6e/0x120
[6409726.813059]  [<ffffffff810a168b>] create_new_namespaces+0x11b/0x1d0
[6409726.813062]  [<ffffffff810a17ad>] copy_namespaces+0x6d/0xa0
[6409726.813068]  [<ffffffff8107f1d5>] copy_process+0x905/0x1b70
[6409726.813073]  [<ffffffff810805d0>] _do_fork+0x80/0x360
[6409726.813077]  [<ffffffff81080959>] SyS_clone+0x19/0x20
[6409726.813081]  [<ffffffff8183b972>] entry_SYSCALL_64_fastpath+0x16/0x71
[6409733.941041] unregister_netdevice: waiting for lo to become free. Usage count = 1
[6409744.021494] unregister_netdevice: waiting for lo to become free. Usage count = 1

موضوع netdev @ vger موجود هنا https://www.mail-archive.com/[email protected]/msg179703.html إذا كان أي شخص يريد متابعة التقدم.

@ قطعة نعم ، هذا متوقع.

واجهت أيضًا هذا الخطأ وتمكنت من إعادة إنتاج Oopses باستخدام طريقة docker -samba-loop من

• لينكس صورة 4.4.0-93 عام
• لينكس صورة 4.10.0-1004-gcp
• لينكس صورة 4.10.0-32 عام
• لينكس صورة 4.11.0-14 عام
• لينكس صورة 4.12.10-041210 عام = 4.12.10-041210.20170830

أضفت نتائجي إلى تقرير أخطاء Ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407 و https://github.com/fho/docker-samba-loop

fho شكرا. أنت في الواقع لا تحتاج إلى عامل إرساء على الإطلاق لإعادة إصداره ، فقط تشغيل عميل سامبا في مساحة اسم شبكة سيفي بالغرض وفقًا لـ https://github.com/moby/moby/issues/5618#issuecomment -318681443

rn شكرا للمعلومات. لم أحاول بهذه الطريقة بعد.

يبدو أن المشاركات الأخيرة هنا وعلى القائمة البريدية لـ netdev تتعلق فقط بأكشاك kernel.
أواجه أعطال kernel أيضًا مع kernel 4.11 و 4.12.

أرى مشكلة مشابهة جدًا لهذا (كما هو مفصل في # 35068). نحن ندير بشكل أساسي سربًا ثنائي العقد ، والذي يدير خدمة واحدة مع 4 نسخ متماثلة باستخدام استراتيجية وضع الانتشار.

في كل من حاويات الخدمة هذه ، نقوم بتركيب docker.sock المضيف كوحدة تخزين ، ومن داخل الحاوية ننفذ أوامر docker run ، بحد أقصى للتزامن 4 لكل حاوية. ينتج عن هذا إنشاء ما يصل إلى 4 حاويات بشكل متزامن ، وإزالتها فورًا بعد ذلك عبر -rm .

سجلات kernel إضافية وأمثلة على ARMv7 موضحة في المرجع أعلاه.

ip6_route_dev_notify الذعر مشكلة خطيرة بالنسبة لنا.

أعتقد أنه بالنظر إلى هذا أكثر قليلاً ، فهذا بالتأكيد ليس نفس الخطأ مثل:

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

أعتقد أن هذه مشكلة في المنبع في النواة مع طبقة IPv6.

قد تكون هذه المعلومات ذات صلة.

نحن قادرون على إعادة إنتاج المشكلة مع _unregister_netdevice: انتظار lo لتصبح حرة. عدد الاستخدام = 1_ مع نواة 4.14.0-rc3 مع _CONFIG_PREEMPT_NONE = y_ وتعمل فقط على وحدة معالجة مركزية واحدة مع خيارات نواة التمهيد التالية:

BOOT_IMAGE = / boot / vmlinuz-4.14.0-rc3 root = / dev / mapper / vg0-root ro quiet vsyscall = محاكاة nosmp

بمجرد أن نصل إلى هذه الحالة ، يبقى في هذه الحالة ويلزم إعادة التشغيل. لا يمكن إنتاج المزيد من الحاويات. نقوم بإعادة إنتاجه عن طريق تشغيل الصور بعمل اتصالات ipsec / openvpn + تنزيل ملف صغير داخل الأنفاق. ثم توجد المثيلات (عادةً ما تكون أقل من 10 ثوانٍ). نقوم بتشغيل 10 حاويات من هذه الحاويات في الدقيقة على جهاز واحد. مع الإعدادات المذكورة أعلاه (1 وحدة معالجة مركزية فقط) ، يصل الجهاز إليها في حوالي ساعتين.

هناك أداة إعادة إنتاج أخرى لها نفس النواة ، ولكن بدون تحديد عدد وحدات المعالجة المركزية ، وهي تشغيل iperf في وضع UDP لمدة 3 ثوانٍ داخل الحاوية (لذلك لا يوجد اتصال TCP على الإطلاق). إذا قمنا بتشغيل 10 من هذه الحاويات بالتوازي ، فانتظر حتى تنتهي جميعها ونقوم بذلك مرة أخرى ، فإننا نواجه المشكلة في أقل من 10 دقائق (على 40 آلة نواة).

في كل من القائمين بإعادة الإنتاج لدينا ، أضفنا "ip route flush table all؛ ifconfigتحت؛ النوم 10 "قبل التواجد من الحاويات. لا يبدو أن له أي تأثير.

أهلا،

فقط للإضافة إلى النار ، نشهد أيضًا هذه المشكلة ، كما هو مطلوب ، إليك ما يلي ...

إصدار النواة: Linux exe-v3-worker 4.9.0-3-amd64 # 1 SMP Debian 4.9.30-2 + ​​deb9u5 (2017-09-19) x86_64 GNU / Linux

توزيع / إصدار Linux: Debian 9.1 (مع تحديث جميع الحزم)

هل تستخدم أحدث إصدار من kernel لبائع Linux الخاص بك؟ نعم

إعداد الشبكة (الجسر ، التراكب ، IPv4 ، IPv6 ، إلخ): IPv4 فقط ، NATed وفقًا لإعداد Docker الافتراضي

وصف حمل العمل (ما نوع الحاويات ، وما نوع تحميل الشبكة ، وما إلى ذلك): حاويات قصيرة العمر (من بضع ثوانٍ إلى بضع دقائق) تعمل على تشغيل البرامج النصية قبل الخروج.

ومن الناحية المثالية استنساخ بسيط:

** النواة: [617624.412100] unregister_netdevice: انتظار lo لتصبح مجانية. عدد الاستخدام = 1

تعذر قتل الحاوية القديمة أو بدء تشغيل حاويات جديدة على العقد المتأثرة ، واضطررت إلى إعادة التشغيل لاستعادة الوظائف. **

نأمل أن نجد سببًا جذريًا / تصحيحًا قريبًا.

تحياتي الحارة،

روبوت 796

تضمين التغريدة
وافق على أنه يبدو أن له علاقة بتخزين الشبكات. أنا أستخدم ceph krbd كمجلد ثابت في kubernetes.
ويمكنني إعادة إنتاج الموقف بعد مرور وقت طويل على تحطم الحاوية.

تم تعيين المشكلة منذ 10 أيام وهي قيد التنفيذ ، ويمكنك رؤية المزيد من الأفكار حول ما يحدث هنا https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407

نأمل أن يكتشف دان ستريتمان كيفية إصلاحها

تبين أن سبب الخطأ هو خلل في kernel تم إصلاحه عن طريق الالتزام 76da0704507bbc51875013f6557877ab308cfd0a:

ipv6: اتصل فقط بـ ip6_route_dev_notify () مرة واحدة لـ NETDEV_UNREGISTER

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/؟id=76da0704507bbc51875013f6557877ab308cfd0a
(إنه يعمل فقط على إصلاح حالة الذعر في kernel ، وليس مشكلة "kernel: unregister_netdevice: انتظار lo لتصبح مجانية. عدد الاستخدام = 2".)

(كرر هذا هنا مرة أخرى ، لأن GitHub يخفي التعليقات القديمة)

إذا كنت ستصل إلى هنا

المشكلة التي تتم مناقشتها هنا هي خلل في النواة ولم يتم إصلاحها بالكامل بعد. دخلت بعض التصحيحات في النواة والتي تعمل على إصلاح بعض حالات حدوث هذه المشكلة ، ولكن لم يتم حل البعض الآخر بعد.

هناك عدد من الخيارات التي قد تساعد في _بعض_ المواقف ، ولكن ليس للجميع (مرة أخرى ، من المرجح أن تكون مجموعة من المشكلات تؤدي إلى ظهور الخطأ نفسه)

لا تترك تعليقات "لدي هذا أيضًا"

"لدي هذا أيضًا" لا يساعد في حل الخطأ. اترك تعليقًا فقط إذا كانت لديك معلومات قد تساعد في حل المشكلة (في هذه الحالة ؛ قد يكون توفير تصحيح إلى kernel upstream هو أفضل خطوة).

إذا كنت تريد إعلامك بأن لديك هذه المشكلة أيضًا ، فاستخدم الزر "رائعة" في الوصف العلوي:

إذا كنت تريد البقاء على اطلاع على التحديثات ، فاستخدم زر _subscribe_.

يرسل كل تعليق هنا بريدًا إلكترونيًا / إشعارًا إلى أكثر من 3000 شخص لا أرغب في قفل المحادثة حول هذه المشكلة ، لأنه لم يتم حلها بعد ، ولكن قد تضطر إلى ذلك إذا تجاهلت ذلك.

سأقوم بإزالة التعليقات التي لا تضيف معلومات مفيدة من أجل تقصير الموضوع (قليلاً)

إذا كنت تريد المساعدة في حل هذه المشكلة

• اقرأ الموضوع بالكامل ؛ إنه طويل ، ويقوم جيثب بإخفاء التعليقات (لذلك عليك النقر لإظهارها مرة أخرى). هناك الكثير من المعلومات الموجودة في هذا الموضوع بالفعل والتي يمكن أن تساعدك
• اقرأ هذا التعليق https://github.com/moby/moby/issues/5618#issuecomment -316297818 (والتعليقات حول ذلك الوقت) للحصول على معلومات يمكن أن تكون مفيدة.

شكرا!

أعتقد أنني أصلحت هذه المشكلة ، على الأقل عندما كان سببها اتصال مأخذ توصيل kernel TCP. تتوفر نواة اختبار لـ Ubuntu وأود الحصول على تعليقات إذا كانت تساعد / تصلح هذا لأي شخص هنا. يتم تقديم التصحيح المنبع ؛ مزيد من التفاصيل في علة LP:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/comments/46

آسف لإفساد الاحتفال ، لكننا تمكنا من إعادة إظهار المشكلة. نحن نعمل الآن مع ddstreet عليه على https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/ .

هل لا توجد حلول؟

استخدم الشبكات المضيفة (التي تدمر الكثير من قيمة الحاويات ، ولكن هناك تذهب).

@ pumba-lt كانت لدينا هذه المشكلة منذ حوالي 1.5 عام ، منذ حوالي عام واحد قمت بتعطيل ipv6 على مستوى النواة (وليس sysctl) ولم أواجه هذه المشكلة مرة واحدة. تشغيل مجموعة من 48 ريش.

عادة في: /etc/default/grub
GRUB_CMDLINE_LINUX="xxxxx ipv6.disable=1"

ومع ذلك ، فأنا أستخدم تمهيد PXE ، لذلك فإن تهيئة PXE لديّ:

      DEFAULT menu.c32
      prompt 0
      timeout 50
      MENU TITLE PXE Boot
      label coreos
              menu label CoreOS
              kernel mykernel
              append initrd=myimage ipv6.disable=1 elevator=deadline cloud-config-url=myurl

أؤكد لك أنك لن ترى هذه المشكلة مرة أخرى.

يرجى تفهم الجميع أن هذه هي الأعراض الشائعة التي لها العديد من الأسباب. ما نجح في تجنبه قد لا يعمل مع شخص آخر.

يمكنني أن أؤكد أن مشكلاتنا قد تم حلها بعد تعطيل IPv6 عند التمهيد (ملف تكوين fron grub). واجهت العديد من المشكلات في كتلة 7 عقدة ، وتعمل بسلاسة الآن.

لا أتذكر أين وجدت الحل ، أو هل وجدته بنفسي ، على أي حال ، شكرًا qrpike لاقتراح هذا للآخرين :) !!

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

الالتزام edaafa805e0f9d09560a4892790b8e19cab8bf09
المؤلف: Dan Streetman [email protected]
التاريخ: الخميس 18 يناير 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]>

يمكن أن يؤدي استخدام SCTP في الشبكات أيضًا إلى حدوث هذا ، والإصلاحات في 4.16-rc1:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/؟id=4a31a6b19f9ddf498c81f5c9b089742b7472a6f8
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/؟id=957d761cf91cdbb175ad7d8f5472336a4d54dbf2

لا يزال يحدث "unregister_netdevice: انتظار eth0 ليصبح مجانيًا. عدد الاستخدام = 1" على الرغم من أنني قمت بترقية إصدار kernel إلى 4.4.118 ، وإصدار docker 17.09.1-ce ربما يجب أن أحاول تعطيل ipv6 على مستوى النواة. نأمل أن تعمل سحابة.

@ wuming5569 من فضلك أعلمني إذا كان يعمل معك مع هذا الإصدار من لينكس

@ wuming5569 ، ربما ، قم بترقية kernel 4.4.114 إصلاح "unregister_netdevice: انتظار lo ليصبح مجانيًا. عدد الاستخدام = 1" ، وليس لـ "unregister_netdevice: انتظار eth0 ليصبح مجانيًا. عدد الاستخدام = 1".
اختبرت في الإنتاج.
ddstreet هذا

@ wuming5569 كما هو مذكور أعلاه ، الرسائل الخاصة بهم حميدة ولكنها قد تؤدي في النهاية إلى تعليق النواة. هل تتعطل النواة الخاصة بك ، وإذا كان الأمر كذلك ، فما هو نمط الشبكة لديك ، أي ما نوع الشبكات التي تقوم بها حاوياتك؟

واجهت نفس المشكلة على CentOS. نواة بلدي هو 3.10.0-693.17.1.el7.x86_64. لكن ، لم أحصل على تتبع مكدس مماثل في سجل النظام.

نفس الشيء في Centos7 kernel 3.10.0-514.21.1.el7.x86_64 و docker 18.03.0-ce

danielefranceschi أوصيك بالترقية إلى أحدث إصدار من CentOS kernel (على الأقل 3.10.0-693). لن تحل المشكلة ، لكن يبدو أنها أقل تكرارًا. في النوى 3.10.0-327 و 3.10.0-514 ، كنا نشاهد تتبع المكدس ، لكن حسب ذاكرتي ، لا أعتقد أننا رأينا أيًا منها في 3.10.0-693.

يبدو أن alexhexabeam 3.10.0-693 يعمل بشكل لا تشوبه شائبة ، tnx :)

نفس الشيء في CentOS7 kernel 4.16.0-1.el7.elrepo.x86_64 و docker 18.03.0-ce

لقد نجح الأمر لأسابيع قبل الانهيار وعندما نحاول رفعه ، فإنه عالق تمامًا.

حدثت المشكلة أيضًا مع kernel 3.10.0-693.21.1.el7

يمكنني أن أؤكد حدوث ذلك أيضًا في:

لينكس 3.10.0 - 693.17.1.el7.x86_64
الإصدار 7.4 من Red Hat Enterprise Linux Server (Maipo)

يمكنني إعادة إنتاجه عن طريق إجراء "إعادة تشغيل عامل إرساء الخدمة" أثناء وجود قدر معين من التحميل.

@ wuming5569 هل أصلحت هذه المشكلة؟ ما هو نوع شبكتك؟ لقد ارتبكتنا هذه القضية لأسابيع.
هل لديك حساب wechat؟

4admin2root ، بالنظر إلى الإصلاح الذي ذكرته ، https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.114 ،

هل من الآمن تعطيل وكيل userland لبرنامج docker daemon ، إذا تم تثبيت نواة حديثة مناسبة؟ ليس من الواضح ما إذا كان من

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

نظرًا لأن كلاهما أقدم من إصلاح kernel

شكرا لك

لقد ارتبكتنا هذه القضية لأسابيع.
لينكس 3.10.0 - 693.17.1.el7.x86_64
إصدار CentOS Linux 7.4.1708 (Core)

هل يمكن لأي شخص تأكيد ما إذا كانت أحدث نواة 4.14 بها هذه المشكلة؟ يبدو أنه لا يفعل ذلك. لم يواجه أي شخص حول الإنترنت هذه المشكلة مع 4.14 kernel.

أرى هذا في نواة 4.15.15-1 ، Centos7

بالنظر إلى سجلات التغيير ، https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.15.8 لديه إصلاح لـ SCTP ، ولكن ليس TCP. لذلك قد ترغب في تجربة الإصدار 4.14 الأحدث.

• حتى 4.15.18 لا يساعد في هذا الخطأ
• لا يساعد تعطيل ipv6 أيضًا

قمنا الآن بالترقية إلى 4.16.13. المراقبة. كان هذا الخطأ يصيبنا في عقدة واحدة مرة واحدة تقريبًا في الأسبوع.

هل قمت بتعطيل ipv6 في معلمات تمهيد اليرقة أو sysctl؟ ستعمل معلمات التمهيد فقط. لن يقوم Sysctl بإصلاحه.

في 4 يونيو 2018 الساعة 12:09:53 مساءً ، كتب سيرجي برونين ( [email protected] (mailto: [email protected])):

حتى 4.15.18 لا يساعد في هذا الخطأ
لا يساعد تعطيل ipv6 أيضًا

قمنا الآن بالترقية إلى 4.16.13. المراقبة. كان هذا الخطأ يصيبنا في عقدة واحدة مرة واحدة تقريبًا في الأسبوع.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو قم بعرضها على GitHub (https://github.com/moby/moby/issues/5618#issuecomment-394410321) ، أو تجاهل الموضوع (https://github.com/notifications/unsubscribe-auth / AAo3HLYI_jnwjgtQ0ce-E4mc6Em5yeISks5t5VvRgaJpZM4B4L4Z).

بالنسبة لي ، يظهر الخطأ في معظم الأوقات بعد إعادة نشر نفس المشروع / الشبكة مرة أخرى

qrpike أنت على حق ، لقد حاولنا فقط sysctl. اسمحوا لي أن أحاول مع اليرقة. شكرا!

4.9.88 نواة دبيان. قابلة للتكرار.

qrpike أنت على حق ، لقد حاولنا فقط sysctl. اسمحوا لي أن أحاول مع اليرقة. شكرا!

في حالتي ، لم يحدث تعطيل IPv6 أي فرق.

@ spronin-aurea هل يساعد تعطيل ipv6 في محمل الإقلاع؟

qrpike ، هل يمكنك إخبارنا بالعقد التي تستخدمها إذا كان تعطيل ipv6 مفيدًا في حالتك؟ إصدار Kernel ، إصدار k8s ، CNI ، إصدار docker ، إلخ.

komljen لقد كنت أستخدم CoreOS على مدار العامين الماضيين دون أي حادث. منذ ~ الإصدار 1000. لم أجربه مؤخرًا ولكن إذا لم أقم بتعطيل ipv6 ، فسيحدث الخطأ.

من جانبي ، أنا أستخدم CoreOS أيضًا ، IPv6 معطل مع اليرقة وما زلت أعاني من المشكلة

deimosfr أستخدم حاليًا تمهيد PXE لجميع العقد الخاصة بي:

      DEFAULT menu.c32
      prompt 0
      timeout 50
      MENU TITLE PXE Boot Blade 1
      label coreos
              menu label CoreOS ( blade 1 )
              kernel coreos/coreos_production_pxe.vmlinuz
              append initrd=coreos/coreos_production_pxe_image.cpio.gz ipv6.disable=1 net.ifnames=1 biosdevname=0 elevator=deadline cloud-config-url=http://HOST_PRIV_IP:8888/coreos-cloud-config.yml?host=1 root=LABEL=ROOT rootflags=noatime,discard,rw,seclabel,nodiratime

ومع ذلك ، فإن العقدة الرئيسية التي هي مضيف PXE هي أيضًا CoreOS ويتم تشغيلها من القرص ، وليس لديها مشكلة أيضًا.

ما هي إصدارات النواة التي تشغلونها يا رفاق؟

تلك التي حصلت عليها كانت على 4.14.32-coreos وما قبلها. أنا لا أواجه هذه المشكلة حتى الآن على 4.14.42-coreos

Centos 7.5 مع نواة 4.17.3-1 ، لا تزال تواجه المشكلة.

Env:
kubernetes 1.10.4
Docker 13.1.2 تحديث
مع المكون الإضافي لشبكة Flannel.

سجل :
[89.790907] IPv6: ADDRCONF (NETDEV_UP): eth0: الرابط غير جاهز
[89.798523] IPv6: ADDRCONF (NETDEV_CHANGE): eth0: الرابط يصبح جاهزًا
[89.799623] cni0: دخل المنفذ 8 (vethb8a93c6f) في حالة الحظر
[89.800547] cni0: دخل المنفذ 8 (vethb8a93c6f) في حالة التعطيل
[89.801471] دخل الجهاز vethb8a93c6f في الوضع المختلط
[89.802323] cni0: دخل المنفذ 8 (vethb8a93c6f) في حالة الحظر
[89.803200] cni0: دخل المنفذ 8 (vethb8a93c6f) في حالة إعادة التوجيه

kernel: unregister_netdevice : انتظار lo لتصبح حرة. عدد الاستخدام = 1。

حاليا :
يمكن أن يصل عنوان IP للعقدة ، ولكن لا يمكنه استخدام أي من خدمات الشبكة ، مثل ssh ...

الأعراض هنا تشبه الكثير من التقارير في أماكن أخرى مختلفة. كل ما يتعلق بمساحات الشبكة. هل يمكن للأشخاص الذين يواجهون هذا الأمر معرفة ما إذا كان unshare -n معلقًا ، وإذا كان الأمر كذلك ، من محطة طرفية أخرى ، قم بإجراء cat /proc/$pid/stack لعملية إلغاء المشاركة لمعرفة ما إذا كانت معلقة في copy_net_ns() ؟ يبدو أن هذا هو القاسم المشترك للعديد من المشكلات بما في ذلك بعض الخلفيات الموجودة هنا. بين 4.16 و 4.18 ، كان هناك عدد من التصحيحات بواسطة Kirill Tkhai لإعادة هيكلة القفل المتضمن كثيرًا. من المحتمل أن ينظر القائمون على صيانة حزمة التوزيعات / النواة المتأثرة في تطبيقها / نقلها إلى نواة مستقرة ومعرفة ما إذا كان ذلك يساعد.
راجع أيضًا: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779678

تضمين التغريدة

sudo cat /proc/122355/stack
[<ffffffff8157f6e2>] copy_net_ns+0xa2/0x180
[<ffffffff810b7519>] create_new_namespaces+0xf9/0x180
[<ffffffff810b775a>] unshare_nsproxy_namespaces+0x5a/0xc0
[<ffffffff81088983>] SyS_unshare+0x193/0x300
[<ffffffff816b8c6b>] tracesys+0x97/0xbd
[<ffffffffffffffff>] 0xffffffffffffffff

نظرًا لتغييرات القفل في 4.18 ، سيكون من الجيد اختبار 4.18rc الحالي ، خاصةً إذا كان بإمكانك تشغيله بشكل أكثر أو أقل موثوقية ، كما رأيته هناك العديد من الأشخاص حيث أدى تغيير إصدارات kernel أيضًا إلى تغيير احتمالية حدوث ذلك كثيرا.

واجهت هذه المشكلات مع Kubernetes وبعد التبديل إلى أحدث إصدار مستقر من CoreOS - 1745.7.0 ، اختفت المشكلة:

• النواة: 4.14.48
• عامل ميناء: 18.03.1

نفس المشكلة على CentOS 7

• النواة: 4.11.1-1.el7.elrepo.x86_64
• عامل ميناء: 17.12.0-ce

Blub رؤية نفس الأمر على CoreOS 1688.5.3 ، kernel 4.14.32

ip-10-72-101-86 core # cat /proc/59515/stack
[<ffffffff9a4df14e>] copy_net_ns+0xae/0x200
[<ffffffff9a09519c>] create_new_namespaces+0x11c/0x1b0
[<ffffffff9a0953a9>] unshare_nsproxy_namespaces+0x59/0xb0
[<ffffffff9a07418d>] SyS_unshare+0x1ed/0x3b0
[<ffffffff9a003977>] do_syscall_64+0x67/0x120
[<ffffffff9a800081>] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[<ffffffffffffffff>] 0xffffffffffffffff

من الناحية النظرية ، قد يكون هناك أثر آخر أو أكثر في مكان ما يحتوي على إحدى الوظائف من net_namespace.c لتأمين net_mutex ( cleanup_net ، net_ns_barrier ، net_ns_init ، {,un}register_pernet_{subsys,device} ). بالنسبة للنواة المستقرة ، سيكون من الأسهل بالطبع إذا كان هناك شيء واحد يتم إيقافه بطريقة يمكن إصلاحها ، بدلاً من نقل جميع تغييرات القفل من 4.18. لكن حتى الآن لم أر أي أثر يؤدي إلى السبب الجذري. لا أعرف ما إذا كان ذلك سيساعد ، ولكن ربما تكون /proc/*/stack s الأخرى مع الوظائف المذكورة أعلاه مرئية عند ظهور المشكلة؟

المشكلة نفسها ! و حسدتي هي دبيان 8

RHEL ، SWARM ، 18.03.0 م

1. الاتصال بعقدة المدير عبر ssh

2. بدء تشغيل حاوية على عقدة المدير يدويًا:

   sudo docker run -it -v / import: / temp / eximport -v / home / myUser: / temp / exhome docker.repo.myHost / fedora: 23 / bin / bash

3. بعد فترة من الوقت لا تفعل شيئًا:

   [ root @ 8a9857c25919 myDir] #
   رسالة من syslogd @ se1-shub-t002 في 19 تموز (يوليو) 11:56:03 ...
   kernel: unregister_netdevice : انتظار lo لتصبح حرة. عدد الاستخدام = 1

بعد دقائق ، عدت إلى وحدة التحكم في عقدة المدير ولم تعد الحاوية التي تم تشغيلها تعمل بعد الآن.

هل هذا يصف نفس المشكلة أم أن هذه "مجموعة مشاكل" أخرى؟

THX مقدما!

تحديث
يحدث هذا أيضًا مباشرة على وحدة التحكم ssh (في bash مدير السرب).

تحديث
الجهاز المضيف (عقدة مدير واحدة في السرب):
Linux [MACHINENNAME] 3.10.0-514.2.2.el7.x86_64 # 1 SMP الأربعاء 16 تشرين الثاني (نوفمبر) 13:15:13 EST 2016 x86_64 x86_64 x86_64 GNU / Linux

إذا لم يتم إصلاح ذلك بعد مرور بعض الوقت ، فهذه مشكلة مختلفة.

نفس الشيء على CentOS7.5 kernel 3.10.0-693.el7.x86_64 و docker 1.13.1

نفس المشكلة OEL 7.5
uname -a
4.1.12-124.16.1.el7uek.x86_64 # 2 SMP الاثنين 11 يونيو 20:09:51 PDT 2018 x86_64 x86_64 x86_64 GNU / Linux
معلومات عامل الميناء
الحاويات: 9
الجري: 5
متوقف مؤقتًا: 0
متوقف: 4
الصور: 6
إصدار الخادم: 17.06.2-ol

dmesg
[2238374.718889] unregister_netdevice: انتظار lo لتصبح حرة. عدد الاستخدام = 1
[2238384.762813] unregister_netdevice: انتظار lo لتصبح حرة. عدد الاستخدام = 1
[2238392.792585] eth0: تمت إعادة تسميته من vethbed6d59

(كرر هذا https://github.com/moby/moby/issues/5618#issuecomment-351942943 هنا مرة أخرى ، لأن GitHub يخفي التعليقات القديمة)

إذا كنت ستصل إلى هنا

المشكلة التي تتم مناقشتها هنا هي خلل في النواة ولم يتم إصلاحها بالكامل بعد. دخلت بعض التصحيحات في النواة والتي تعمل على إصلاح بعض حالات حدوث هذه المشكلة ، ولكن لم يتم حل البعض الآخر بعد.

هناك عدد من الخيارات التي قد تساعد في _بعض_ المواقف ، ولكن ليس للجميع (مرة أخرى ، من المرجح أن تكون مجموعة من المشكلات تؤدي إلى ظهور الخطأ نفسه)

الخطأ "unregister_netdevice: انتظار lo لتصبح حرة" ليس الخطأ بحد ذاته

إذا كان تعطل kernel _after_ فهذا خطأ (انظر أدناه)

لا تترك تعليقات "لدي هذا أيضًا"

"لدي هذا أيضًا" لا يساعد في حل الخطأ. اترك تعليقًا فقط إذا كانت لديك معلومات قد تساعد في حل المشكلة (في هذه الحالة ؛ قد يكون توفير تصحيح إلى kernel upstream هو أفضل خطوة).

إذا كنت تريد إعلامك بأن لديك هذه المشكلة أيضًا ، فاستخدم الزر "رائعة" في الوصف العلوي:

إذا كنت تريد البقاء على اطلاع على التحديثات ، فاستخدم زر _subscribe_.

يرسل كل تعليق هنا بريدًا إلكترونيًا / إشعارًا إلى أكثر من 3000 شخص لا أرغب في قفل المحادثة حول هذه المشكلة ، لأنه لم يتم حلها بعد ، ولكن قد تضطر إلى ذلك إذا تجاهلت ذلك.

سأقوم بإزالة التعليقات التي لا تضيف معلومات مفيدة من أجل تقصير الموضوع (قليلاً)

إذا كنت تريد المساعدة في حل هذه المشكلة

• اقرأ الموضوع بأكمله ، بما في ذلك التعليقات المخفية ؛ إنه طويل ، ويقوم جيثب بإخفاء التعليقات (لذلك عليك النقر لإظهارها مرة أخرى). هناك الكثير من المعلومات الموجودة في هذا الموضوع بالفعل والتي يمكن أن تساعدك

• اقرأ هذا التعليق https://github.com/moby/moby/issues/5618#issuecomment -316297818 (والتعليقات حول ذلك الوقت) للحصول على معلومات يمكن أن تكون مفيدة:

لكي نكون واضحين ، الرسالة نفسها حميدة ، إنها تعطل النواة بعد الرسائل التي أبلغت عنها OP وهي ليست كذلك.

التعليق في الكود ، من أين تأتي هذه الرسالة ، يوضح ما يحدث. يقوم كل مستخدم بشكل أساسي ، مثل مكدس IP) لجهاز الشبكة (مثل نهاية زوج veth داخل حاوية) بزيادة عدد المرجع في بنية جهاز الشبكة عند استخدام جهاز الشبكة. عند إزالة الجهاز (على سبيل المثال ، عند إزالة الحاوية) يتم إخطار كل مستخدم حتى يتمكن من إجراء بعض التنظيف (مثل إغلاق المقابس المفتوحة وما إلى ذلك) قبل إنقاص العدد المرجعي. نظرًا لأن هذا التنظيف قد يستغرق بعض الوقت ، خاصةً في ظل الحمل الثقيل (الكثير من الواجهة ، والكثير من الاتصالات وما إلى ذلك) ، فقد تطبع kernel الرسالة هنا من حين لآخر.

إذا لم يقلل مستخدم جهاز الشبكة من عدد المرجع ، سيحدد جزء آخر من النواة أن المهمة التي تنتظر التنظيف عالقة وستتعطل. إن هذا الانهيار فقط هو الذي يشير إلى خطأ في kernel (بعض المستخدمين ، عبر بعض مسارات الكود ، لم يقللوا عدد المرجع). كان هناك العديد من هذه الأخطاء وتم إصلاحها في النواة الحديثة (وربما تم إرجاعها إلى الأقدم). لقد كتبت عددًا قليلاً من اختبارات الإجهاد (وأواصل كتابتها) لإثارة مثل هذه الأعطال ولكن لم أتمكن من التكاثر على النوى الحديثة (لكني أفعل الرسالة أعلاه).

* يُرجى الإبلاغ عن هذه المشكلة فقط في حالة تعطل النواة الخاصة بك * ، ومن ثم سنكون مهتمين جدًا بما يلي:

• إصدار kernel (ناتج uname -r )
• توزيع / إصدار Linux
• هل تستخدم أحدث إصدار من kernel لبائع Linux الخاص بك؟
• إعداد الشبكة (جسر ، تراكب ، IPv4 ، IPv6 ، إلخ)
• وصف عبء العمل (ما نوع الحاويات ، وما نوع تحميل الشبكة ، وما إلى ذلك)
• ومن الناحية المثالية استنساخ بسيط

شكرا!

هل أنتم يا رفاق تديرون عامل ميناء تحت أي حدود؟ مثل ulimits ، cgroups إلخ ...

أحدث systemd له حد افتراضي حتى لو لم تقم بتعيينه. لقد قمت بتعيين الأشياء على وضع غير محدود ولم تحدث المشكلة منذ ذلك الحين (المشاهدة منذ 31 يومًا).

واجهت نفس المشكلة في العديد من البيئات وكان الحل الخاص بي هو إيقاف جدار الحماية. لم يحدث ذلك مرة أخرى ، في الوقت الحالي

Rhel 7.5 - 3.10.0-862.3.2.el7.x86_64
Docker 1.13.0 تحديث

dElogics ما هو إصدار systemd الذي يعتبر "أحدث"؟ هل تم تمكين هذا الحد الافتراضي في نظام CentOS 7.5؟

أيضًا ، عندما تسأل عما إذا كنا نقوم بتشغيل عامل ميناء تحت أي حدود ، فهل تقصد برنامج عامل الإرساء الخفي ، أم الحاويات الفردية؟

خفي عامل ميناء. النظام كما في دبيان 9 (232-25).

لست متأكدًا من RHEL ، لكنني شخصيًا رأيت هذه المشكلة على RHEL أيضًا. لقد قمت بتعيين LimitNOFILE = 1048576 ، LimitNPROC = ما لا نهاية ، LimitCORE = ما لا نهاية ، TasksMax = ما لا نهاية

kernel: unregister_netdevice: انتظار eth0 ليصبح مجانيًا. عدد الاستخدام = 3
نواة 4.4.146-1.el7.elrepo.x86_64
إصدار Linux CentOS Linux الإصدار 7.4.1708 (Core)
وضع الجسر

لدي نفس المشكلة ، ماذا أفعل؟

المشكلة نفسها:

إصدار CentOS Linux 7.5.1804 (Core)
إصدار Docker 18.06.1-ce ، بناء e68fc7a
إصدار النواة: 3.10.0-693.el7.x86_64

القضية المماثلة التي التقيت بها هنا ...
هل هناك أي حركات يمكنني القيام بها الآن؟ أرجوك أن تساعدني...

CentOS 7.0.1406.0
[ root @ zjsm-slavexx وما إلى ذلك] # uname -a
Linux zjsm-slave08 3.10.0-123.el7.x86_64 # 1 SMP الاثنين 30 يونيو 12:09:22 بالتوقيت العالمي المنسق 2014 x86_64 x86_64 x86_64 GNU / Linux
[ root @ zjsm-slavexx etc] # cat / etc / centos-release
إصدار CentOS Linux 7.0.1406 (Core)

معلومات عامل الميناء:
[ root @ zjsm-slavexx ~] # إصدار عامل ميناء
عميل:
الإصدار: 17.04.0-ce
إصدار API: 1.28
إصدار Go: go1.7.5
Git الالتزام: 4845c56
تاريخ البناء: الإثنين 3 أبريل 18:01:50 2017
OS / Arch: لينكس / amd64

الخادم:
الإصدار: 17.04.0-ce
إصدار API: 1.28 (الحد الأدنى للإصدار 1.12)
إصدار Go: go1.7.5
Git الالتزام: 4845c56
تاريخ البناء: الإثنين 3 أبريل 18:01:50 2017
OS / Arch: لينكس / amd64
التجريبية: خطأ

إصدار CentOS Linux 7.2.1511 kernel: 3.10.0-327.el7.x86_64
نفس المشكلة

لقد جربت هذه المشكلة.

Ubuntu 16.04.3 LTS
Kernel 4.4.0-87-generic #110-Ubuntu SMP Tue Jul 18 12:55:35 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Docker version:
Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:42:18 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:56 2017
 OS/Arch:      linux/amd64
 Experimental: false

thaJeztah ، ربما يجب عليك إضافة تعليقك إلى أعلى

$ docker network ls
NETWORK ID          NAME                     DRIVER              SCOPE
b3fc47abfff2        bridge                   bridge              local
f9474559ede8        dockerfile_cluster_net   bridge              local
ef999de68a96        host                     host                local
e7b41d23674c        none                     null                local
$ docker network rm f9474559ede8 

تم التصليح.

hzbd تقصد حذف شبكة الجسر المعرفة من قبل المستخدم؟ هل حاولت البحث أكثر لمعرفة السبب؟ واسمحوا لي أن أعرف إذا فعلت ذلك. انا حقا اقدر هذا.

في انتظار الإصلاح

هل أنتم يا رفاق تديرون عامل ميناء تحت أي حدود؟ مثل ulimits ، cgroups إلخ ...

أحدث systemd له حد افتراضي حتى لو لم تقم بتعيينه. لقد قمت بتعيين الأشياء على وضع غير محدود ولم تحدث المشكلة منذ ذلك الحين (المشاهدة منذ 31 يومًا).

حسنًا ، لا يزال هذا الخطأ يحدث ، لكن الاحتمال قد انخفض.

أعتقد أنه إذا توقفت الحاويات بأمان (يوجد PID 1 (موجودة) ، فلن يزعجنا هذا الخطأ.

dElogics شكرًا لإعلامنا ، هل يمكنك أن توضح لنا الأوامر التي

dElogics شكرًا لإعلامنا ، هل يمكنك أن توضح لنا الأوامر التي

يجب عليك تعديل وحدة systemd من عامل الإرساء. وحدة systemd التي أستخدمها (الأجزاء ذات الصلة فقط) -

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target docker.socket firewalld.service flannel.service
Wants=network-online.target
Requires=docker.socket

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker

ExecReload=/bin/kill -s HUP $MAINPID
LimitNOFILE=1048576
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNPROC=infinity
LimitCORE=infinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this version.
TasksMax=infinity
TimeoutStartSec=0
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
# kill only the docker process, not all processes in the cgroup
KillMode=process
# restart the docker process if it exits prematurely
Restart=on-failure
StartLimitBurst=3
StartLimitInterval=60s

[Install]
WantedBy=multi-user.target

هل واجه شخص ما هذه المشكلة في نواة 4.15 أو أحدث؟

تم تضمين إصلاح Dan Streetman هذا (https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d) لأول مرة في إصدار 4.15 kernel ويبدو أنه على الأقل بالنسبة لشخص ما لم يعد يحدث بعد الآن منذ الترقية إلى 4.16 (https: / /github.com/kubernetes/kubernetes/issues/64743#issuecomment-436839647)

هل جربها شخص ما؟

victorgp ما زلنا نواجه مشكلة نواة 4.15. سنبلغ هنا عندما اختبرنا 4.16 نواة (نأمل في غضون أسابيع قليلة).

استخدمنا إصدار النواة

للإضافة إلى قراراتي السابقة - لا تؤدي حاويات التوقف بأمان (التي تستجيب لـ SIGTERM) إلى تشغيل هذا مطلقًا.

حاول أيضًا تشغيل الحاويات في مساحة اسم المضيف (إذا كان ذلك مقبولًا بالنسبة لك) مما يحل المشكلة تمامًا.

dElogics ماذا تقصد ب "مساحة اسم المضيف"؟ هل هو ببساطة --privileged ؟

dElogics ماذا تقصد ب "مساحة اسم المضيف"؟ هل هو ببساطة --privileged ؟

لا ، هذا يعني - الشبكة = المضيف

منذ الترقية من kernel 4.4.0 إلى 4.15.0 و docker 1.11.2 إلى 18.09 اختفت المشكلة.

في أسطول كبير من الأجهزة الافتراضية التي تعمل كمضيفين لرسو السفن ، واجهتنا هذه المشكلة تظهر عدة مرات في اليوم (مع حالة استخدام Docker الخاصة بنا).
45 يومًا ولم نعد نرى هذا.

للأجيال القادمة ، يمكن العثور على تتبع مكدس لـ Docker معلق 1.11.2 w / printk يظهر unregister_netdevice: waiting for vethXXXXX (على غرار ما كنا نراه دائمًا في أسطولنا ، في مئات من الأجهزة الافتراضية) على http: // لصق .ubuntu.com / p / 6RgkpX352J / (مرجع الحاوية المثير للاهتمام هو 0xc820001980 )

goroutine 8809 [syscall, 542 minutes, locked to thread]:
syscall.Syscall6(0x2c, 0xd, 0xc822f3d200, 0x20, 0x0, 0xc822f3d1d4, 0xc, 0x20, 0xc82435fda0, 0x10)
    /usr/local/go/src/syscall/asm_linux_amd64.s:44 +0x5
syscall.sendto(0xd, 0xc822f3d200, 0x20, 0x20, 0x0, 0xc822f3d1d4, 0xc80000000c, 0x0, 0x0)
    /usr/local/go/src/syscall/zsyscall_linux_amd64.go:1729 +0x8c
syscall.Sendto(0xd, 0xc822f3d200, 0x20, 0x20, 0x0, 0x7faba31bded8, 0xc822f3d1c8, 0x0, 0x0)
    /usr/local/go/src/syscall/syscall_unix.go:258 +0xaf
github.com/vishvananda/netlink/nl.(*NetlinkSocket).Send(0xc822f3d1c0, 0xc82435fda0, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go:333 +0xd4
github.com/vishvananda/netlink/nl.(*NetlinkRequest).Execute(0xc82435fda0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go:215 +0x111
github.com/vishvananda/netlink.LinkDel(0x7fab9c2b15d8, 0xc825ef2240, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/vishvananda/netlink/link_linux.go:615 +0x16b
github.com/docker/libnetwork/drivers/bridge.(*driver).DeleteEndpoint(0xc8204aac30, 0xc8203ae780, 0x40, 0xc826e7b800, 0x40, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go:1060 +0x5cf
github.com/docker/libnetwork.(*endpoint).deleteEndpoint(0xc822945b00, 0xc82001ac00, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/endpoint.go:760 +0x261
github.com/docker/libnetwork.(*endpoint).Delete(0xc822945b00, 0x7fab9c2b0a00, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/endpoint.go:735 +0xbcb
github.com/docker/libnetwork.(*sandbox).delete(0xc8226bc780, 0xc8229f0600, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/sandbox.go:217 +0xd3f
github.com/docker/libnetwork.(*sandbox).Delete(0xc8226bc780, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/sandbox.go:175 +0x32
github.com/docker/docker/daemon.(*Daemon).releaseNetwork(0xc820001980, 0xc820e23a40)
    /usr/src/docker/.gopath/src/github.com/docker/docker/daemon/container_operations.go:732 +0x4f1
github.com/docker/docker/daemon.(*Daemon).Cleanup(0xc820001980, 0xc820e23a40)
    /usr/src/docker/.gopath/src/github.com/docker/docker/daemon/start.go:163 +0x62
github.com/docker/docker/daemon.(*Daemon).StateChanged(0xc820001980, 0xc825f9fac0, 0x40, 0xc824155b50, 0x4, 0x8900000000, 0x0, 0x0, 0x0, 0x0, ...)
    /usr/src/docker/.gopath/src/github.com/docker/docker/daemon/monitor.go:39 +0x60a
github.com/docker/docker/libcontainerd.(*container).handleEvent.func2()
    /usr/src/docker/.gopath/src/github.com/docker/docker/libcontainerd/container_linux.go:177 +0xa5
github.com/docker/docker/libcontainerd.(*queue).append.func1(0xc820073c01, 0xc820f9a2a0, 0xc821f3de20, 0xc822ddf9e0)
    /usr/src/docker/.gopath/src/github.com/docker/docker/libcontainerd/queue_linux.go:26 +0x47
created by github.com/docker/docker/libcontainerd.(*queue).append
    /usr/src/docker/.gopath/src/github.com/docker/docker/libcontainerd/queue_linux.go:28 +0x1da

من ذلك يمكننا ملاحظة أنه تم تعليقه في https://github.com/moby/moby/blob/v1.11.2/daemon/container_operations.go#L732

مما يوجهنا إلى https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/sandbox.go#L175

و
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/endpoint.go#L760

الذي يذهب إلى برنامج تشغيل جسر libnetwork (تحقق من الوصف الرائع)
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go#L1057 -L1061

الانتقال إلى 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

وفي النهاية في مقبس netlink هذا ، اتصل بـ https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go#L333

نشعر أن الخطأ بشكل عام يحدث عند إيقاف حاوية وبسبب استمرار الإشارة إلى SKBs في الشبكات ، لم يتم تحرير veth ، ثم يصدر Docker أمر قتل لتلك الحاوية بعد 15 ثانية. لا يتعامل Docker daemon مع هذا الموقف بأمان ، ولكن الخطأ في النهاية موجود في النواة. نعتقد أن https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d (مقبول في 4.15 المنبع) والالتزامات المرتبطة به (هناك العديد) تعمل كتخفيف.

بشكل عام ، هذا الجزء من النواة ليس مكانًا جميلًا.

لما تستحقه ... قمنا بترقية RHEL Linux kernel من 3.10.0 إلى 4.17.11. (تشغيل مجموعة Kubernetes على). قبل الترقية ، كان هذا الخطأ يحدث يوميًا عدة مرات على خوادم مختلفة. يعمل مع الترقية لمدة ثلاثة أسابيع الآن. حدث الخلل مرة واحدة فقط. يقال تقريبًا أنه تم تقليله بنسبة 99٪.

marckamerbeek هل قمت بتحديث RHEL Kernel إلى مجتمع Kernel؟ ثم لم يعد مدعومًا.

يمكن لمستخدم Beatlor CentOS فعل مثل هذا.

سنتوس 7.2 لا يزال لديه هذه المشكلة: kernel: unregister_netdevice : انتظار lo لتصبح حرة. عدد الاستخدام = 1

Beatlor RHEL لم يساعدنا على الإطلاق. تعد بيئة الإنتاج المستقرة أكثر أهمية من بعض عقود الدعم التي لا قيمة لها. ما زلنا نعمل بثبات كبير الآن عند 4.17.11. لا توجد قضايا كبيرة بعد الآن.

Beatlor RHEL لم يساعدنا على الإطلاق. تعد بيئة الإنتاج المستقرة أكثر أهمية من بعض عقود الدعم التي لا قيمة لها. ما زلنا نعمل بثبات كبير الآن عند 4.17.11. لا توجد قضايا كبيرة بعد الآن.

نعم ، لم أواجه هذه المشكلة أيضًا بعد ترقية kernel إلى 4.17.0-1.el7.elrepo.x86_64. لقد جربت هذا من قبل (4.4.x ، 4.8 ، 4.14 ..) وفشلت. يبدو أن المشكلة لن تحدث مرة أخرى في 4.17+ النواة.

سنتوس 7.2 لا يزال لديه هذه المشكلة: kernel: unregister_netdevice : انتظار lo لتصبح حرة. عدد الاستخدام = 1

يمكنك محاولة الترقية إلى أحدث إصدار من 4.19+ kernel.

فقط انتظر لبضعة أشهر وسيأتي شخص ما يشكو من نواة 4.19 أيضًا. مجرد التاريخ يعيد نفسه.

مرحبًا بالجميع ، أخبار جيدة!

منذ تعليقي الأخير هنا (في وقت كتابة هذا التقرير ، قبل 17 يومًا) لم تظهر لي هذه الأخطاء مرة أخرى. كانت خوادمي (حوالي 30 منهم) تعمل بنظام ubuntu 14.04 مع بعض الحزم القديمة.

بعد ترقية النظام بالكامل بما في ذلك docker-engine (من 1.7.1 إلى 1.8.3) + ترقية kernel إلى أحدث إصدار ممكن على repo الخاص بـ ubuntu ، تعمل خوادمي دون أي تكرار.

🎱

ما هو إصدار النواة الذي تقوم بترقيته؟

ربما تتعلق بهذا https://github.com/torvalds/linux/commit/f186ce61bb8235d80068c390dc2aad7ca427a4c2

فيما يلي محاولة لتلخيص هذه المشكلة ، من تعليقات هذه المشكلة ، https://github.com/kubernetes/kubernetes/issues/70427 و https://github.com/kubernetes/kubernetes/issues/64743 و https: //access.redhat.com/solutions/3659011

إصدارات kernel المرصودة مع هذه المشكلة

• RHEL7 3.10.0 - 862
• 4.15.0
• 4.20.0

ادعت إصدارات Kernel أنها لا تسبب هذه المشكلة

• RHEL7 3.10.0-957.10.1
• 4.19.12
• 4.17.0
• 4.17.11

إلتزامات kernel ذات الصلة

• https://github.com/torvalds/linux/commit/f186ce61bb8235d80068c390dc2aad7ca427a4c2 - منذ 4.12
• https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d - منذ 4.15
• https://github.com/torvalds/linux/commit/ee60ad219f5c7c4fb2f047f88037770063ef785f - منذ 5.1

أتحدى https://github.com/kubernetes/kubernetes/issues/70427#issuecomment -470681000 لأننا لم نشاهد هذا مع الآلاف من VMs في 4.15.0 بينما كنا نراه عشرات المرات يوميًا على 4.4. 0 ، هل هناك المزيد من التقارير عنه في 4.15.0؟

أرى هذه المشكلة مع أحد أجهزتي التي تشغل Docker على Debian 9 Stretch ( 4.9.0-8-amd64 ). أواجه هذه المشكلة مع نفق تم إنشاؤه داخل حاوية Docker عبر Docker Gen ويولد حالة من الذعر في النواة:

Message from syslogd<strong i="7">@xxxx</strong> at Apr 29 15:55:41 ...
 kernel:[719739.507961] unregister_netdevice: waiting for tf-xxxxxxxx to become free. Usage count = 1

إليك معلومات Docker الخاصة بنا:

Client:
 Version:           18.09.3
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        774a1f4
 Built:             Thu Feb 28 06:34:04 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.3
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.8
  Git commit:       774a1f4
  Built:            Thu Feb 28 05:59:55 2019
  OS/Arch:          linux/amd64
  Experimental:     false

هل يعرف أي شخص ما إذا كان هناك إصلاح مؤقت لهذا الأمر دون إعادة تشغيل الجهاز بالكامل؟ نفضل حقًا عدم الاضطرار إلى إعادة تشغيل الجهاز بالكامل عندما نواجه هذه المشكلة.

خارج الموضوع إلى حد ما ، لا يمكننا قمع رسائل الذعر kernel داخل المحطة أيضًا. لقد جربت dmesg -D و dmesg -n 1 . ومع ذلك ، لا حظ. هل هناك طريقة لمنع هذا النوع من رسائل الذعر kernel من داخل الجهاز؟ من المزعج محاولة كتابة الأوامر وظهور هذه الرسالة كل 10 ثوانٍ أو نحو ذلك.

شكرا.

هل حبات الفانيليا هذه أم مرقعة بشدة بواسطة توزيعات مع إصلاحات خلفية؟

pmoust أرى هذا على ubuntu 4.15.0-32 مرة واحدة في الأسبوع أو نحو ذلك. بالتأكيد أفضل بكثير منذ 4.4.0

iavael سأحاول سرد معلومات التوزيع في الملخص إذا كان المرجع يوفرها.

رأى أي شخص هذا الخطأ مع 4.19؟

رأى أي شخص هذا الخطأ مع 4.19؟

https://github.com/kubernetes/kubernetes/issues/64743#issuecomment -451351435
https://github.com/kubernetes/kubernetes/issues/64743#issuecomment -461772385

قد تكون هذه المعلومات مفيدة لك.

tankywoodrpancakeegasimuscsabahenkspiffytechibuildthecloudsbwardjbalonsorsampaioMrMMorrisrsampaiounclejackchrisjstevensonpopsiklefxposter @ scher200victorgpjstangroome @ Xuexiang825dElogicsNowakerpmoustmarckamerbeekBeatlorwarmchang Jovons @ 247687009jwongz @ tao12345666333clkao يرجى الاطلاع على هذا https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs- while- testing- tidb- operator- in- k8s/

tankywoodrpancakeegasimuscsabahenkspiffytechibuildthecloudsbwardjbalonsorsampaioMrMMorrisrsampaiounclejackchrisjstevensonpopsiklefxposter @ scher200victorgpjstangroome @ Xuexiang825dElogicsNowakerpmoustmarckamerbeekBeatlorwarmchang Jovons @ 247687009jwongz @ tao12345666333clkao يرجى الاطلاع على هذا https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs- while- testing- tidb- operator- in- k8s/

لقد اتبعت الوثائق ، لكنني ما زلت أتلقى خطأ.

[root<strong i="39">@node1</strong> ~]# kpatch list
Loaded patch modules:
livepatch_route [enabled]

Installed patch modules:
[root<strong i="40">@node1</strong> ~]#
Message from syslogd<strong i="41">@node1</strong> at May  7 15:59:11 ...
 kernel:unregister_netdevice: waiting for eth0 to become free. Usage count = 1

هذه الرسالة في حد ذاتها ليست الخطأ. إنها النواة التي تحطمت بعد ذلك ؛ https://github.com/moby/moby/issues/5618#issuecomment -407751991

tankywoodrpancakeegasimuscsabahenkspiffytechibuildthecloudsbwardjbalonsorsampaioMrMMorrisrsampaiounclejackchrisjstevensonpopsiklefxposter @ scher200victorgpjstangroome @ Xuexiang825dElogicsNowakerpmoustmarckamerbeekBeatlorwarmchang Jovons @ 247687009jwongz @ tao12345666333clkao يرجى الاطلاع على هذا https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs- while- testing- tidb- operator- in- k8s/

لقد اتبعت الوثائق ، لكنني ما زلت أتلقى خطأ.

[root<strong i="40">@node1</strong> ~]# kpatch list
Loaded patch modules:
livepatch_route [enabled]

Installed patch modules:
[root<strong i="41">@node1</strong> ~]#
Message from syslogd<strong i="42">@node1</strong> at May  7 15:59:11 ...
 kernel:unregister_netdevice: waiting for eth0 to become free. Usage count = 1

بعد إعادة التشغيل ، موافق ···

@ vincent927 BTW يجب عليك وضع livepatch_route.ko في / var / lib / kpatch / $ (uname -r) ، عند تمكين kpatch.service ، يمكن أن يتم تحميل ko تلقائيًا بعد إعادة التشغيل.

حصلنا على هذا في شركتنا فجأة اليوم في عدة مجموعات kubernetes.

• uname -a :
  Linux ip-10-47-17-58 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux

• docker version :

  Client:
   Version:           18.09.5
   API version:       1.39
   Go version:        go1.10.8
   Git commit:        e8ff056dbc
   Built:             Thu Apr 11 04:44:28 2019
   OS/Arch:           linux/amd64
   Experimental:      false
  
  Server: Docker Engine - Community
   Engine:
    Version:          18.09.2
    API version:      1.39 (minimum version 1.12)
    Go version:       go1.10.6
    Git commit:       6247962
    Built:            Sun Feb 10 03:42:13 2019
    OS/Arch:          linux/amd64
    Experimental:     false
  

• kubectl version (الخادم):
  Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.2", GitCommit:"cff46ab41ff0bb44d8584413b598ad8360ec1def", GitTreeState:"clean", BuildDate:"2019-01-10T23:28:14Z", GoVersion:"go1.11.4", Compiler:"gc", Platform:"linux/amd64"}

لا نعرف السبب بعد. لقد قمنا بتشغيل هذه الإصدارات من البرنامج أعلاه لعدة أشهر دون مشاكل. أنا فقط أعلق لأضيف إلى قائمة "إصدارات البرامج التي تواجه هذا الخطأ" في الوقت الحالي.

@ 2rs2ts هل جربت https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs- while-testing-tidb-operator-in-k8s/ ؟

ethercflow لقد قرأت ذلك ولكن بما أننا المنشور .

ethercflow @ 2rs2ts نحن أيضًا

commixon تجربتنا لا تزال هي نفسها كما ورد في https://github.com/moby/moby/issues/5618#issuecomment -455800975 ، عبر أسطول من آلاف VMs لا إعادة حدوث المشكلة مع / 4.15.0 على النكهات العامة والمحسّنة لـ AWS والمحسّنة لـ GCP المقدمة من Canonical. لم يُظهر الاختبار المحدود على الفانيليا 4.15.0 أيًا من هذه المشكلات أيضًا ، ولكن لم يتم اختباره على نطاق واسع.

شكرا جزيلا pmoust . سوف تجربهم. على أي حال ، سأحاول أيضًا تصحيح kpatch للعمل مع دبيان (كمشروع جانبي) ونشر التحديثات هنا لأي شخص مهتم.

ethercflow @ 2rs2ts نحن أيضًا

يمكنك الترقية إلى 4.19. إنه في backports.

راجع للشغل لقد كان عام بالنسبة لنا هنا. ؛)

لقد جربنا بالفعل 4.19 في backports ولكن كان لديه بعض الانحدارات الرئيسية في مناطق أخرى (سيتم إعادة تشغيل مثيلات EC2 بشكل عشوائي ومن ثم سيتم كسر الشبكة عند بدء التشغيل.) أعتقد أنه سيتعين علينا التعامل مع هذا حتى الاستقرار التالي.

@ 2rs2ts خلال الأيام الأربعة الماضية ، نستخدم 4.19 من backports (في EC2) ولم نشهد أي مشاكل على الإطلاق. لم تظهر مشكلة تعطل kernel على الإطلاق ويبدو أن كل شيء آخر على ما يرام أيضًا. لا أعتقد أن هذا يحدث أي فرق ولكننا استندنا إلى الصورة التي قدمتها شركة kops (https://github.com/kubernetes/kops/blob/master/docs/images.md#debian). قمنا بتحديث النواة في هذه الصورة وليس Debian الأسهم.

أصدقائي ، لقد كنت أستخدم نواة 4.19 للتشغيل المستقر لمدة نصف عام. آمل أن تستمتع بالاستقرار أيضًا.

لدي حاوية مفتوحة 80 و 443 منفذًا ، كل أسبوعين ، من حاوية وصول كمبيوتر أخرى 80 و
443 ينكر

إصدار centos7.3 kernel هو:
متصفح Linux 1 3.10.0-514.el7.x86_64 # 1 SMP الثلاثاء 22 نوفمبر 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux

root @ browser1 ~] # إصدار عامل ميناء
عميل:
الإصدار: 18.06.3-ce
إصدار API: 1.38
نسخة Go: go1.10.4
Git الالتزام: d7080c1
تاريخ البناء: الأربعاء 20 فبراير ، 02:24:22 2019
OS / Arch: لينكس / amd64
التجريبية: خطأ

الخادم:
محرك:
الإصدار: 18.06.3-ce
إصدار API: 1.38 (الحد الأدنى للإصدار 1.12)
نسخة Go: go1.10.3
Git الالتزام: d7080c1
تاريخ البناء: الأربعاء 20 فبراير ، 02:25:33 2019
OS / Arch: لينكس / amd64
التجريبية: خطأ
[ root @ browser1 ~] #

dmesg:

[1063959.636785] unregister_netdevice: انتظار lo لتصبح حرة. عدد الاستخدام = 1
[1071340.887512] br-af29e1edc1b8: تم إدخال المنفذ 5 (vethc2ac4f8) في حالة التعطيل
[1071340.891753] br-af29e1edc1b8: تم إدخال المنفذ 5 (vethc2ac4f8) في حالة التعطيل
[1071340.895118] غادر الجهاز vethc2ac4f8 الوضع المختلط
[1071340.895138] br-af29e1edc1b8: تم إدخال المنفذ 5 (vethc2ac4f8) في حالة التعطيل
[1071340.990505] دخل الجهاز veth5e4f161 في الوضع المختلط
[1071340.990897] IPv6: ADDRCONF (NETDEV_UP): veth5e4f161: الرابط غير جاهز
[1071340.990904] br-af29e1edc1b8: تم إدخال المنفذ 5 (veth5e4f161) في حالة إعادة التوجيه
[1071340.990924] br-af29e1edc1b8: تم إدخال المنفذ 5 (veth5e4f161) في حالة إعادة التوجيه
[1071341.231405] IPv6: ADDRCONF (NETDEV_CHANGE): veth5e4f161: الرابط يصبح جاهزًا
[1071355.991701] br-af29e1edc1b8: تم إدخال المنفذ 5 (veth5e4f161) في حالة إعادة التوجيه
[1071551.533907] br-af29e1edc1b8: تم إدخال المنفذ 5 (veth5e4f161) في حالة التعطيل
[1071551.537564] br-af29e1edc1b8: تم إدخال المنفذ 5 (veth5e4f161) في حالة التعطيل
[1071551.540295] غادر الجهاز veth5e4f161 الوضع المختلط
[1071551.540313] br-af29e1edc1b8: تم إدخال المنفذ 5 (veth5e4f161) في حالة التعطيل
[1071551.570924] دخل الجهاز veth8fd3a0a في الوضع المختلط
[1071551.571550] IPv6: ADDRCONF (NETDEV_UP): veth8fd3a0a: الرابط غير جاهز
[1071551.571556] br-af29e1edc1b8: تم إدخال المنفذ 5 (veth8fd3a0a) في حالة إعادة التوجيه
[1071551.571582] br-af29e1edc1b8: تم إدخال المنفذ 5 (veth8fd3a0a) في حالة إعادة التوجيه
[1071551.841656] IPv6: ADDRCONF (NETDEV_CHANGE): veth8fd3a0a: الرابط يصبح جاهزًا
[1071566.613998] br-af29e1edc1b8: تم إدخال المنفذ 5 (veth8fd3a0a) في حالة إعادة التوجيه
[1071923.465082] br-af29e1edc1b8: تم إدخال المنفذ 5 (veth8fd3a0a) في حالة التعطيل
[1071923.470215] br-af29e1edc1b8: تم إدخال المنفذ 5 (veth8fd3a0a) في حالة التعطيل
[1071923.472888] غادر الجهاز veth8fd3a0a الوضع المختلط
[1071923.472904] br-af29e1edc1b8: تم إدخال المنفذ 5 (veth8fd3a0a) في حالة التعطيل
[1071923.505580] دخل الجهاز veth9e693ae في الوضع المختلط
[1071923.505919] IPv6: ADDRCONF (NETDEV_UP): veth9e693ae: الرابط غير جاهز
[1071923.505925] br-af29e1edc1b8: تم إدخال المنفذ 5 (veth9e693ae) في حالة إعادة التوجيه
[1071923.505944] br-af29e1edc1b8: تم إدخال المنفذ 5 (veth9e693ae) في حالة إعادة التوجيه
[1071923.781658] IPv6: ADDRCONF (NETDEV_CHANGE): veth9e693ae: أصبح الرابط جاهزًا
[1071938.515044] br-af29e1edc1b8: تم إدخال المنفذ 5 (veth9e693ae) في حالة إعادة التوجيه

رأى أي شخص هذا الخطأ مع 4.19؟

نعم فعلا. لدي مشكلة في kernel 4.19.4-1.e17.elrep.x86_64

أهلا،

أنا أيضا أرى هذا الخطأ. هل لدينا أي حل لهذه المشكلة؟ نواة 3.10.0-514.26.2.el7.x86_64

[username@ip-10-1-4-64 ~]$
Message from syslogd@ip-10-1-4-64 at Jul 19 10:50:01 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Message from syslogd@ip-10-1-4-64 at Jul 19 10:50:48 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

لا تزال هذه المشكلة تحدث: (لا يوجد تحديث / أفكار حول كيفية الإصلاح؟

يحدث في Debian Stretch. كنت أحاول تحديث حاوية Jenkins الخاصة بي عبر Ansible عندما حدث هذا.

تم حل هذه المشكلة من خلال هذا الالتزام:
https://github.com/torvalds/linux/commit/ee60ad219f5c7c4fb2f047f88037770063ef785f
باستخدام kpatch

curl -SOL https://raw.githubusercontent.com/Aleishus/kdt/master/kpatchs/route.patch
kpatch-build -t vmlinux route.patch 
mkdir -p /var/lib/kpatch/${UNAME} 
cp -a livepatch-route.ko /var/lib/kpatch/${UNAME}
systemctl restart kpatch
kpatch list

تم حل هذه المشكلة من خلال هذا الالتزام:
تورفالدس / لينكس @ ee60ad2
باستخدام kpatch

curl -SOL https://raw.githubusercontent.com/Aleishus/kdt/master/kpatchs/route.patch
kpatch-build -t vmlinux route.patch 
mkdir -p /var/lib/kpatch/${UNAME} 
cp -a livepatch-route.ko /var/lib/kpatch/${UNAME}
systemctl restart kpatch
kpatch list

يجب أن يكون هذا في 4.19.30 فصاعدًا.