मैं eth0 के लिए एक समान समस्या देख रहा हूँ। उबंटू 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

सिस्टम विवरण :
पैच किए गए कर्नेल (3.14.3-rt4) के साथ Ubuntu 14.04 LTS चलाना। फिर भी यह देखने के लिए कि यह डिफ़ॉल्ट लिनक्स-3.13.0-27-जेनेरिक कर्नेल के साथ होता है। हालाँकि, जो मज़ेदार है, वह यह है कि जब ऐसा होता है, तो मेरी सभी टर्मिनल विंडो फ्रीज हो जाती हैं, जिससे मुझे इससे पहले कुछ अक्षर टाइप करने पड़ते हैं। मेरे द्वारा खोले गए किसी भी नए भाग्य का भी यही हश्र होता है - और मुझे अपने खराब लैपटॉप को ऊपर के अच्छे डॉक्टर की तरह ही पावर साइकिल चलाने की आवश्यकता होती है। रिकॉर्ड के लिए, मैं xmonad में urxvt या xterm में मछली खोल चला रहा हूं। जाँच नहीं की है कि क्या यह सादे बैश को प्रभावित करता है।

यह प्रासंगिक हो सकता है:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065434#yui_3_10_3_1_1401948176063_2050

एक कंटेनर के अंदर नेटवर्क पर काफी बड़ी मात्रा में डेटा की प्रतिलिपि बनाना
और फिर कंटेनर से बाहर निकलने से प्रति में एक लापता कमी हो सकती है
एक नेटवर्क डिवाइस पर सीपीयू संदर्भ गणना।

निश्चित रूप से, मेरे लिए यह एक बार apt-get निर्भरता के एक टन के साथ पैकेज को टिंग करने के बाद सही था।

उबंटू १२.०४.३ से १४.०४ में अपग्रेड करने से यह मेरे लिए बिना किसी अन्य बदलाव के तय हो गया।

मैं इसे RHEL7, 3.10.0-123.4.2.el7.x86_64 पर अनुभव करता हूं

जब मैं 3.14-rt4 चला रहा होता हूं, तो मैंने अपने वर्चुअलबॉक्स वर्चुअल नेटवर्क इंटरफेस के साथ भी ऐसा ही देखा है। इसे वेनिला 3.13 या कुछ और में तय किया जाना चाहिए।

@egasimus वही - मैंने कंटेनर को मारने से पहले सैकड़ों एमबी डेटा खींचा, फिर यह त्रुटि मिली।

मैंने डेबियन कर्नेल 3.14 में अपग्रेड किया और ऐसा प्रतीत होता है कि समस्या दूर हो गई है। ऐसा लगता है कि समस्या कुछ कर्नेल <3.5 में मौजूद थी, 3.5 में तय की गई थी, 3.6 में वापस आ गई थी, और 3.12-3.14 में कुछ पैच किया गया था। https://bugzilla.redhat.com/show_bug.cgi?id=880394

@spiffytech क्या आपके पास कोई विचार है जहां मैं रीयलटाइम कर्नेल स्वाद के बारे में इसकी रिपोर्ट कर सकता हूं? मुझे लगता है कि वे केवल हर दूसरे संस्करण के लिए एक आरटी पैच जारी कर रहे हैं, और वास्तव में 3.16-आरटी को अभी भी टूटे हुए देखने से नफरत करेंगे। :/

संपादित करें: इसे kernel.org पर

मैं इसे Ubuntu 14.10 पर 3.18.1 चला रहा हूं। कर्नेल लॉग दिखाता है

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 भेजूंगा :)

हम इस मुद्दे को भी देख रहे हैं। उबंटू 14.04, 3.13.0-37-जेनेरिक

उबंटू 14.04 सर्वर पर, मेरी टीम ने पाया है कि 3.13.0-40-जेनेरिक से 3.13.0-32-जेनेरिक में डाउनग्रेड करने से समस्या "हल" हो जाती है। @sbward के अवलोकन को देखते हुए, यह

मैं इसे जोड़ दूंगा, हमारे मामले में, हम कभी-कभी एक _negative_ उपयोग गणना देखते हैं।

FWIW हमने भरोसेमंद कर्नेल (3.13.0-40-जेनेरिक # 69-उबंटू) पर lxc चलाने वाले इस बग को मारा, संदेश dmesg में दिखाई देता है जिसके बाद यह स्टैकट्रेस होता है:

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

उबंटू 14.04 और डेबियन जेसी w/कर्नेल 3.16.x पर इसमें भाग लें।

डॉकर कमांड:

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

यह एक बहुत ही खराब मुद्दा लगता है ...

@jbalonso 3.13.0-32 -जेनेरिक के साथ भी मुझे केवल कुछ सफल रनों के बाद त्रुटि मिलती है: सोब:

@MrMMorris क्या आप सार्वजनिक उपलब्ध छवियों का उपयोग करके एक पुनरुत्पादक स्क्रिप्ट साझा कर सकते हैं?

हर कोई जो अपने सिस्टम पर इस त्रुटि को देख रहा है, वह अपने वितरण पर लिनक्स कर्नेल का एक पैकेज चला रहा है जो बहुत पुराना है और इस विशेष समस्या के समाधान की कमी है।

यदि आप इस समस्या में भाग लेते हैं, तो सुनिश्चित करें कि आप apt-get update && apt-get dist-upgrade -y चलाते हैं और अपने सिस्टम को रीबूट करते हैं। यदि आप डिजिटल महासागर पर हैं, तो आपको कर्नेल संस्करण का चयन करने की भी आवश्यकता है जो अभी अद्यतन के दौरान स्थापित किया गया था क्योंकि वे स्वचालित रूप से नवीनतम कर्नेल का उपयोग नहीं करते हैं (देखें https://digitalocean.uservoice.com/forums/136585-digitalocean /suggestions/2814988-दे-विकल्प-टू-यूज-द-ड्रॉपलेट-एस-ओन-बूटलोडर)।

CentOS/RHEL/Fedora/Scientific Linux उपयोगकर्ताओं को yum update का उपयोग करके अपने सिस्टम को अद्यतन रखने और अद्यतनों को स्थापित करने के बाद रीबूट करने की आवश्यकता है।

इस समस्या की रिपोर्ट करते समय, कृपया सुनिश्चित करें कि आपका सिस्टम आपके वितरण के विक्रेता द्वारा प्रदान किए गए नवीनतम स्थिर अपडेट (मैन्युअल रूप से स्थापित कोई प्रयोगात्मक/परीक्षण/अल्फा/बीटा/आरसी पैकेज) के साथ पूरी तरह से पैच और अद्यतित है।

@अंकलजैक

मैं भागा apt-get update && apt-get dist-upgrade -y

उबंटू 14.04 3.13.0-46-जेनेरिक

केवल एक docker run बाद भी त्रुटि प्राप्त करें

यदि आवश्यक हो तो मैं पुनरुत्पादन के लिए एएमआई बना सकता हूं

@MrMMorris यह पुष्टि करने के लिए धन्यवाद कि यह अभी भी Ubuntu 14.04 पर नवीनतम कर्नेल पैकेज के साथ एक समस्या है।

मदद के लिए मैं और कुछ भी कर सकता हूं, मुझे बताएं! :मुस्कुराओ:

@MrMMorris यदि आप एक पुनरुत्पादक प्रदान कर सकते हैं तो उबंटू के लिए एक बग खोला गया है और इसकी बहुत सराहना की जाएगी: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152

@rsampaio अगर आज मेरे पास समय है, तो मैं निश्चित रूप से आपके लिए इसे प्राप्त करूंगा!

यह समस्या ३.१६ (.७) पर डेबियन ७ और डेबियन ८ दोनों पर भी दिखाई देती है: https://github.com/docker/docker/issues/9605#issuecomment -85025729। सर्वर को रिबूट करना अभी के लिए इसे ठीक करने का एकमात्र तरीका है।

आरएचईएल 6.6 पर कर्नेल 2.6.32-504.8.1.el6.x86_64 के साथ इस मुद्दे को देखते हुए कुछ डॉकटर कंटेनर शुरू करते समय (सभी कंटेनर नहीं)
_ कर्नेल: unregister_netdevice : लो के मुक्त होने की प्रतीक्षा में। उपयोग गणना = -1_

फिर से, सर्वर को रीबूट करना इस समय एकमात्र समाधान प्रतीत होता है

इसे CoreOS (647.0.0) पर कर्नेल 3.19.3 के साथ भी देख रहे हैं।

रिबूटिंग भी एकमात्र समाधान है जो मैंने पाया है।

सिड के कर्नेल (4.0.2) के साथ परीक्षण डेबियन जेसी - समस्या बनी हुई है।

इस मुद्दे को गैर-उबंटू कंटेनर चलाने वाला कोई भी देख रहा है?

हां। डेबियन वाले।
19 मई 2015 ई. 19:01 пользователь "popsikle" [email protected]
अंग्रेजी:

इस मुद्दे को गैर-उबंटू कंटेनर चलाने वाला कोई भी देख रहा है?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/docker/docker/issues/5618#issuecomment -113556862।

यह एक कर्नेल समस्या है, छवि से संबंधित समस्या नहीं है। किसी छवि को किसी अन्य के लिए स्विच करने से न तो सुधार होगा और न ही यह समस्या और भी बदतर होगी।

4.1.2-बोन12 कर्नेल चलाने वाले बीगलबोन ब्लैक पर डेबियन जेसी पर समस्या का अनुभव

४.१.२ से ४.२-आरसी२ पर स्विच करने के बाद अनुभव (१.८.० के गिट बिल्ड का उपयोग करके)।
/var/lib/docker/* को हटाने से समस्या का समाधान नहीं होता है।
4.1.2 पर वापस जाने से समस्या हल हो जाती है।

इसके अलावा, वर्चुअलबॉक्स में एक ही समस्या है और v5.0.0 (रेट्रो-पोर्टेड टू v4) के लिए पैच है जो माना जाता है कि कर्नेल ड्राइवर भाग में कुछ करता है .. समस्या को समझने के लायक है।

वर्चुअलबॉक्स में यह ठीक है: https://www.virtualbox.org/attachment/ticket/12264/diff_unregister_netdev
वे वास्तव में कर्नेल को संशोधित नहीं करते हैं, केवल उनके कर्नेल मॉड्यूल।

4.2-आरसी 2 के साथ भी यह समस्या है:

unregister_netdevice: vethf1738d3 के मुक्त होने की प्रतीक्षा कर रहा है। उपयोग गिनती = 1

बस 4.2-RC3 संकलित, फिर से काम करने लगता है

@ नज़र-पीसी जानकारी के लिए धन्यवाद। बस इसे 4.1.3 के साथ मारा, बहुत परेशान था
@techniq यहाँ वही, बहुत खराब कर्नेल बग। मुझे आश्चर्य है कि क्या हमें इसकी रिपोर्ट 4.1 पेड़ पर वापस भेजनी चाहिए।

लिनक्स डॉकर13 3.19.0-22-जेनेरिक #22-उबंटू एसएमपी मंगल जून 16 17:15:15 यूटीसी 2015 x86_64 x86_64 x86_64 जीएनयू/लिनक्स

Ubuntu 15.04 से कर्नेल, वही मुद्दा

मैंने इसे 4.2-आरसी3 के साथ भी देखा। डिवाइस रिसाव के बारे में एक बग नहीं है :) मैं किसी भी कर्नेल> = 4.1 पर हाईलोड के तहत पुन: पेश कर सकता हूं।

मुझे भी बस यही समस्या थी। उबंटू 3.13.0-57-जेनेरिक, टुटम के माध्यम से प्रावधानित। दुर्भाग्य से यह kern.log और syslog को भर देता है और मशीन को क्रैश कर देता है। यह डेटाबेस मशीन (डॉकराइज्ड पोस्टग्रेज) पर होता है, इसलिए यह पूरे सिस्टम को नीचे लाता है ...

"मुझे भी" के कोरस में शामिल होकर, मैं एक स्थानीय निजी डॉकर रेपो से डॉकर छवियों को खींचते समय रैंचरोस (एक न्यूनतम ओएस) 0.3.3 चलाने वाले क्लाउडस्टैक वीएम पर इस समस्या को देख रहा हूं। यह हर दस सेकंड में हो रहा है, निश्चित नहीं कि इसका कोई मतलब है या नहीं।

4.2-rc7 . के साथ भी यह समस्या है

इस पर कोई खबर, हमें किस कर्नेल का उपयोग करना चाहिए? यह पूरी तरह से अप-टू-डेट कर्नेल (उबंटू 14.04 पर 3.19.0-26) के साथ भी होता रहता है।

हमें भी यह समस्या हुई है। यह तब होता है जब हम userland-proxy=false कॉन्फ़िगर करते हैं। हम कुछ मॉनिटर स्क्रिप्ट का उपयोग कर रहे हैं जो हर 1 मिनट में nagios प्लगइन्स कमांड को निष्पादित करने के लिए नए डॉकटर कंटेनर को स्पॉन करेगा। मैं प्रोसेस ट्री पर जो देख रहा हूं वह docker rm कमांड पर अटका हुआ है और kern.log फ़ाइल में बहुत सारी त्रुटियां देख रहा है

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

यह हमारे सिस्टम की जानकारी है

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

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

अपडेट: हालांकि https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152 ने कहा कि यह 2015-08-17 को पहले से ही तय है। इसलिए मैंने कर्नेल v3.19.8-ckt6-vivid के साथ प्रयास किया जो 02-सितंबर-2015 को निर्मित होता है या यहां तक ​​कि v4.2.1-अस्थिर जो 21-सितंबर-2015 को निर्मित होता है और अभी भी एक समस्या है।

मैंने 3.19.0-28-generic का उपयोग करके समस्या को फिर से मारा है, इसलिए नवीनतम उबंटू कर्नेल सुरक्षित नहीं है

हाँ, ऐसा लगता है कि --userland-proxy=false पुराने कर्नेल के साथ अब सबसे अच्छा विकल्प नहीं है :(

नहीं। मैंने कोशिश की --userland-proxy=false सभी 3.19, 4.0, 4.2 कर्नेल संस्करण के लिए और समस्या अभी भी होती है।

मैं iptables (--iptables=false) के बिना यूजरलैंड प्रॉक्सी का उपयोग कर रहा हूं और इसे प्रति दिन एक बार न्यूनतम के रूप में देख रहा हूं। अफसोस की बात है कि एकमात्र समाधान एक निगरानीकर्ता था जो SysRq तकनीक का उपयोग कर सर्वर को हार्ड रीसेट करता था।

मेरे सिस्टम कुछ कंटेनर चलाते हैं जो भारी स्टडआउट/गलती लेखक हैं, जैसा कि अन्य ने बताया कि यह बग को ट्रिगर कर सकता है।

``````
$ डोकर जानकारी
कंटेनर: 15
छवियां: 148
भंडारण चालक: aufs
रूट डिर: /var/lib/docker/aufs
बैकिंग फाइल सिस्टम: extfs
डायर: 178
Dirperm1 समर्थित: सच
निष्पादन चालक: देशी-0.2
लॉगिंग ड्राइवर: json-file
कर्नेल संस्करण: 3.19.0-26-जेनेरिक
ऑपरेटिंग सिस्टम: उबंटू 14.04.3 एलटीएस
सीपीयू: 12
कुल मेमोरी: 62.89 जीआईबी
नाम: * *
आईडी: 2 ALJ:YTUH : QCNX:FPEO :YBG4:ZTL4:2 EYK:AV7D :FN7C: IVNU:UWBL :YYZ5

$ डोकर संस्करण
ग्राहक संस्करण: 1.7.0
क्लाइंट एपीआई संस्करण: 1.19
गो संस्करण (क्लाइंट): go1.4.2
गिट प्रतिबद्ध (क्लाइंट): 0baf609
ओएस/आर्क (क्लाइंट): linux/amd64
सर्वर संस्करण: 1.7.0
सर्वर एपीआई संस्करण: 1.19
गो संस्करण (सर्वर): go1.4.2
गिट प्रतिबद्ध (सर्वर): 0baf609
ओएस/आर्क (सर्वर): linux/amd64```
``````

दुर्भाग्य से, मैं उसी मामले में हूं, आज एक उत्पादन सर्वर इस त्रुटि पर 3 बार विफल हुआ, और इसे संभालने का एकमात्र तरीका कुछ जादू SysRq कमांड का उपयोग करना है।

टक्कर

मैं अभी भी इसे कर्नेल 4.2.0 . का उपयोग करते हुए नवीनतम डेबियन जेसी पर देख रहा हूँ

वही समस्या है। अचानक, मेरे तीन एडब्ल्यूएस सर्वर नीचे चले गए और लॉग चिल्ला रहे थे "unregister_netdevice: lo के मुक्त होने की प्रतीक्षा कर रहा है। उपयोग गणना = 1"

उबंटू: 14.04
कर्नेल संस्करण: 3.13.0-63-जेनेरिक
डोकर: 1.7.1

सिसलोग

क्या उपयोग में सुरक्षित कर्नेल संस्करण है?

समस्या Ubuntu 15.10 के कर्नेल 4.2 के साथ भी होती है

कोरोस में हुआ:

छवियां: ११७४
भंडारण चालक: ओवरले
बैकिंग फाइल सिस्टम: extfs
निष्पादन चालक: देशी-0.2
लॉगिंग ड्राइवर: json-file
कर्नेल संस्करण: 4.1.7-कोरोस
ऑपरेटिंग सिस्टम: कोरओएस 766.4.0

कर्नेल बग जो @killme2008 ने पिछली बार कहा था

आपको शायद अपने कर्नेल http://www.spinics.net/lists/netdev/msg351337.html के शीर्ष पर लागू इस पैच के साथ प्रयास करना चाहिए
पैकेट: पैकेट_बाइंड में दौड़ की स्थिति

या बैकपोर्ट इन -स्टेबल ट्री की प्रतीक्षा करें; यह जल्दी या बाद में आएगा।

:+1: अच्छी खबर!

हे सब लोग, अच्छी खबर!

यहां मेरी आखिरी टिप्पणी के बाद से (लेखन के समय, 17 दिन पहले) मुझे ये त्रुटियां दोबारा नहीं मिली हैं। मेरे सर्वर (उनमें से लगभग 30) कुछ पुराने पैकेजों के साथ ubuntu 14.04 चला रहे थे।

डॉकर-इंजन (1.7.1 से 1.8.3 तक) + कर्नेल अपग्रेड सहित पूर्ण सिस्टम अपग्रेड के बाद उबंटू के रेपो पर नवीनतम संभावित संस्करण में, मेरे सर्वर बिना किसी घटना के चल रहे हैं।

:8 गेंद:

हमारे एडब्ल्यूएस उदाहरण में से 3 पर आज भी हुआ:

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

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

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

मुझे उबंटू 14.04 के साथ एक ही समस्या हो रही है, सभी पैकेज अप-टू-डेट और नवीनतम linux-generic-lts-vivid कर्नेल:

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

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

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

मेरे पास यह नवीनतम linux-image-generic (3.13.0-67-जेनेरिक) के साथ भी था।

RancherOS पर यहाँ समान समस्याएँ हैं।

फेडोरा 22 (अपडेट) पर अभी भी हो रहा है ....
अगर मैं डॉकर को पुनरारंभ करता हूं तो मैं संदेशों से छुटकारा पा सकता हूं

systemctl पुनरारंभ docker
... संदेश लगभग 3-4 बार फिर से प्रकट होता है और फिर रुक जाता है

वही त्रुटि मुझे कोरोस के साथ मिलती है:

कोरोस का संस्करण:

 कोर @ कोर-1-94 ~ $ बिल्ली / आदि / ओएस-रिलीज
 नाम = कोरओएस
 आईडी = कोरोस
 संस्करण=766.5.0
 VERSION_ID=766.5.0
 BUILD_ID=
 PRETTY_NAME="कोरओएस 766.5.0"
 ANSI_COLOR="1;32"
 HOME_URL="https://coreos.com/"
 BUG_REPORT_URL="https://github.com/coreos/bugs/issues"

डोकर संस्करण:

 कोर @ कोर-1-94 ~ $ डोकर संस्करण
 ग्राहक संस्करण: 1.7.1
 क्लाइंट एपीआई संस्करण: 1.19
 गो संस्करण (क्लाइंट): go1.4.2
 गिट प्रतिबद्ध (क्लाइंट): df2f73d-dirty
 ओएस/आर्क (क्लाइंट): linux/amd64
 सर्वर संस्करण: 1.7.1
 सर्वर एपीआई संस्करण: 1.19
 गो संस्करण (सर्वर): go1.4.2
 गिट प्रतिबद्ध (सर्वर): df2f73d-dirty
 ओएस/आर्क (सर्वर): linux/amd64

 कोर @ कोर-1-94 ~ $ uname -a
 Linux core-1-94 4.1.7-coreos-r1 #2 SMP गुरु नवंबर 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 कोर-1-94 कर्नेल: unregister_netdevice: veth775ea53 के मुक्त होने की प्रतीक्षा में। उपयोग गिनती = 1
 दिसम्बर 07 16:26:54 कोर-1-94 कर्नेल: unregister_netdevice: लो के मुक्त होने की प्रतीक्षा में। उपयोग गणना = 2
 दिसंबर 07 16:26:55 कोर-1-94 एसडीनोटिफाई-प्रॉक्सी [1203]: I1207 08: 26: 55.930559 00001 vxlan.go:340] कोई चूक नहीं: 4e:5c:47:2f:9a:85, 10.244 .97.10
 दिसंबर 07 16:26:59 कोर-1-94 डॉकर्ड [१२६९]: समय = "२०१५-१२-०७ टी १६: २६: ५९.४४८४३८६४८+०८:००" स्तर = जानकारी संदेश = "प्राप्त / संस्करण"
 दिसंबर 07 16:27:01 कोर-1-94 एसडीनोटिफाई-प्रॉक्सी [1203]: I1207 08: 27: 01.050588 00001 vxlan.go:340] कोई चूक नहीं: 5a:b1:f7:e9:7d:d0, 10.244 .34.8
 दिसंबर 07 16:27:02 कोर-1-94 डॉकर्ड [१२६९]: समय = "२०१५-१२-०७ टी १६: २७: ०२.३९८०२०१२०+०८:००" स्तर = जानकारी संदेश = "प्राप्त / संस्करण"
 दिसंबर 07 16:27:02 कोर-1-94 डॉकर्ड [१२६९]: समय = "२०१५-१२-०७ टी १६: २७: ०२.३९८३१६२४९+०८:००" स्तर = जानकारी संदेश = "प्राप्त / संस्करण"
 ०७ दिसंबर १६:२७:०४ कोर-1-94 डॉकर्ड [१२६९]: समय = "२०१५-१२-०७ टी १६: २७: ०४.४४९३१७३८९+०८:००" स्तर = जानकारी संदेश = "प्राप्त / संस्करण"
 07 दिसंबर 16:27:04 कोर-1-94 कर्नेल: unregister_netdevice: veth775ea53 के मुक्त होने की प्रतीक्षा में। उपयोग गिनती = 1
 दिसंबर 07 16:27:04 कोर-1-94 कर्नेल: unregister_netdevice: लो के फ्री होने की प्रतीक्षा में। उपयोग गणना = 2
 दिसंबर 07 16:27:06 कोर-1-94 एसडीनोटिफाई-प्रॉक्सी [1203]: I1207 08: 27: 06.106573 00001 vxlan.go:340] कोई चूक नहीं: a6:38:ac:79:93:f5, 10.244 .47.24
 दिसंबर 07 16:27:09 कोर-1-94 डॉकर्ड [1269]: समय = "2015-12-07T16: 27: 09.449944048 + 08:00" स्तर = जानकारी संदेश = "प्राप्त / संस्करण"
 दिसंबर 07 16:27:11 कोर-1-94 एसडीनोटिफाई-प्रॉक्सी[1203]: I1207 08:27:11.162578 00001 vxlan.go:340] मिस न करना: 0e:f0:6f:f4:69:57, 10.244 .71.24
 दिसंबर 07 16:27:12 कोर-1-94 डॉकर्ड [१२६९]: समय = "२०१५-१२-०७ टी १६: २७: १२.५०२९९११९७+०८:००" स्तर = जानकारी संदेश = "प्राप्त / संस्करण"
 दिसंबर 07 16:27:12 कोर-1-94 डॉकर्ड [1269]: समय = "2015-12-07 टी 16: 27: 12.503411160 + 08:00" स्तर = जानकारी संदेश = "प्राप्त / संस्करण"
 दिसंबर 07 16:27:14 कोर-1-94 डॉकर्ड [१२६९]: समय = "२०१५-१२-०७ टी १६: २७: १४.४५०६४६८४१+०८:००" स्तर = जानकारी संदेश = "प्राप्त / संस्करण"
 दिसंबर 07 16:27:14 कोर-1-94 कर्नेल: unregister_netdevice: veth775ea53 के मुक्त होने की प्रतीक्षा में। उपयोग गिनती = 1
 दिसम्बर 07 16:27:14 कोर-1-94 कर्नेल: unregister_netdevice: लो के मुक्त होने की प्रतीक्षा में। उपयोग गिनती = 2
 दिसंबर 07 16:27:16 कोर-1-94 एसडीनोटिफाई-प्रॉक्सी[1203]: I1207 08:27:16.282556 00001 vxlan.go:340] कोई चूक नहीं: a6:62:77:31:ef:68, 10.244 .13.6
 दिसंबर 07 16:27:19 कोर-1-94 डॉकर्ड [१२६९]: समय = "२०१५-१२-०७ टी १६: २७: १९.४५१४८६२७७+०८:००" स्तर = जानकारी संदेश = "प्राप्त / संस्करण"
 दिसंबर 07 16:27:21 कोर-1-94 एसडीनोटिफाई-प्रॉक्सी [1203]: I1207 08:27:21.402559 00001 vxlan.go:340] कोई चूक नहीं: 92:c4:66:52:cd:bb, 10.244 .24.7
 दिसंबर 07 16:27:22 कोर-1-94 डॉकर्ड [१२६९]: समय = "२०१५-१२-०७ टी १६: २७: २२.५७५४४६८८९+०८:००" स्तर = जानकारी संदेश = "प्राप्त / संस्करण"
 दिसंबर 07 16:27:22 कोर-1-94 डॉकर्ड [१२६९]: समय = "२०१५-१२-०७ टी १६: २७: २२.५७५८३८३०२+०८:००" स्तर = जानकारी संदेश = "प्राप्त / संस्करण"
 दिसंबर 07 16:27:24 कोर-1-94 डॉकर्ड [१२६९]: समय = "२०१५-१२-०७ टी १६: २७: २४.४५२३२०३६४+०८:००" स्तर = जानकारी संदेश = "प्राप्त / संस्करण"
 दिसंबर 07 16:27:24 कोर-1-94 कर्नेल: unregister_netdevice: veth775ea53 के मुक्त होने की प्रतीक्षा में। उपयोग गिनती = 1
 दिसम्बर 07 16:27:24 कोर-1-94 कर्नेल: unregister_netdevice: लो के मुक्त होने की प्रतीक्षा में। उपयोग गिनती = 2
 दिसंबर 07 16:27:26 कोर-1-94 एसडीनोटिफाई-प्रॉक्सी [1203]: I1207 08: 27: 26.394569 00001 vxlan.go:340] कोई चूक नहीं: 6a:f7:bf:ec:03:50, 10.244 .८७.८
 दिसंबर 07 16:27:29 कोर-1-94 डॉकर्ड [१२६९]: समय = "२०१५-१२-०७ टी १६: २७: २९.४५३१७१६४९+०८:००" स्तर = जानकारी संदेश = "प्राप्त / संस्करण"
 ०७ दिसंबर १६:२७:२९ कोर-१-९४ सिस्टमडी [1]: जनरेट/रन/कोरोस/मोट...
 दिसंबर 07 16:27:29 कोर-1-94 सिस्टमडी[1]: जनरेट /रन/कोरोस/मोटद शुरू किया।
 दिसंबर 07 16:27:32 कोर-1-94 डॉकर्ड [१२६९]: समय = "२०१५-१२-०७ टी १६: २७: ३२.६७१५९२४३७+०८:००" स्तर = जानकारी संदेश = "प्राप्त / संस्करण"
 दिसंबर 07 16:27:32 कोर-1-94 डॉकर्ड [१२६९]: समय = "२०१५-१२-०७ टी १६: २७: ३२.६७१८४१४३६+०८:००" स्तर = जानकारी संदेश = "प्राप्त / संस्करण"
 दिसम्बर 07 16:27:33 कोर-1-94 एसडीनोटिफाई-प्रॉक्सी[1203]: I1207 08:27:33.562534 00001 vxlan.go:340] मिस न करना: 22:b4:62:d6:25:b9, 10.244 .68.8
 दिसंबर 07 16:27:34 कोर-1-94 डॉकर्ड [१२६९]: समय = "२०१५-१२-०७ टी १६: २७: ३४.४५३९५३१६२+०८:००" स्तर = जानकारी संदेश = "प्राप्त / संस्करण"
 दिसंबर 07 16:27:34 कोर-1-94 कर्नेल: unregister_netdevice: veth775ea53 के मुक्त होने की प्रतीक्षा में। उपयोग गिनती = 1
 दिसम्बर 07 16:27:35 कोर-1-94 कर्नेल: unregister_netdevice: लो के मुक्त होने की प्रतीक्षा में। उपयोग गिनती = 2

जन्मदिन मुबारक हो, खूनी मुद्दा =)
6 मई 2014

इधर भी ऐसा ही है। बस रिबूट हो रहा है। नवीनतम डॉकर संस्करण। उबंटू 14.04।

@samvignoli इसे कर्नेल समस्या के रूप में पहचाना गया है, इसलिए दुर्भाग्य से ऐसा कुछ नहीं है जिसे

@thaJeztah क्या आपको कर्नेल समस्या के लिए बग ट्रैकर का लिंक मिला है?
या शायद एक संकेतक जिससे कर्नेल प्रभावित होता है?

हमारे परिवेश में इसे हल करने के लिए उत्सुक हैं।

@Rucknar क्षमा करें, मैं नहीं (शायद इस चर्चा में एक है, मैंने सभी टिप्पणियों को वापस नहीं पढ़ा है)

लिनक्स एटलस2 3.19.0-33-जेनेरिक #38~14.04.1-उबंटू एसएमपी शुक्र 6 नवंबर 18:17:28 यूटीसी 2015 x86_64 x86_64 x86_64 जीएनयू/लिनक्स

@Rucknar यदि आप थोड़ा ऊपर की ओर स्क्रॉल करते हैं - तो आपको पैच का लिंक http://www.spinics.net/lists/netdev/msg351337.html दिखाई देगा। यह अब लिनक्स मास्टर में है, मुझे लगता है कि यह लिनक्स 4.4 पर जाएगा, हो सकता है कि किसी ने इसे पहले से ही पिछले संस्करणों में बैकपोर्ट कर दिया हो, लेकिन निश्चित नहीं है।

सभी का धन्यवाद, देखेंगे कि अपग्रेड करने में क्या आवश्यक है।

FWIW मैंने यहां बताए गए अंतिम पैच को ubuntu 3.19 में बैकपोर्ट किया और मैंने 4.2 कर्नेल पर भी परीक्षण किया, दोनों असफल रहे। इस बिंदु पर 4.4-आरसी3 नेट-नेक्स्ट शाखा पर भी समस्या अभी भी मौजूद है।

@rsampaio आपने इसका परीक्षण कैसे किया? मैं वास्तव में, किसी भी कर्नेल पर डॉकर का उपयोग करके इस गलती को विश्वसनीय रूप से ट्रिगर नहीं कर सकता। यह कभी-कभी ही होता है।

@fxposter हम उत्पादन के बाहर की समस्या को भी पुन: उत्पन्न नहीं कर सकते हैं, इसलिए मुझे उत्पादन में पैच किए गए कर्नेल के साथ कुछ उदाहरणों को बूट करना पड़ा, यह इतनी बार होता है कि मैं यह पता लगा सकता हूं कि उत्पादन लोड के 24 घंटों के भीतर कर्नेल प्रभावित होता है या नहीं।

कभी-कभी हम इसे एक बहुत ही असामान्य संसाधन के साथ ठीक करते हैं: हम कंटेनर निर्देशिकाओं को /var/lib/docker/aufs/mnt से दूर ले जाते हैं

इसके साथ ... शायद हम 'सर्विस डॉकर पुनरारंभ' कर सकते हैं और निर्देशिकाओं को वापस ले जा सकते हैं।

अन्यथा... केवल रीबूट हो रहा है।

@rsampaio क्या आप अब उसकेोकू उत्पादन के बारे में बात कर रहे हैं? आप इस समस्या से कैसे बचते हैं, क्योंकि आपका सारा व्यवसाय कंटेनरों/आदि के आसपास बना हुआ है?

@rsampaio क्या आप --userland-proxy=false या केवल उच्च मात्रा में निर्मित कंटेनरों का उपयोग करते हैं? मैं इसे --userland-proxy=false साथ काफी आसान पुन: पेश कर सकता हूं और बिना कुछ लोड के साथ :)

@ LK4D4 मेरा मानना ​​​​है कि यह केवल निर्मित/नष्ट कंटेनरों की एक उच्च मात्रा है, विशेष रूप से कंटेनर बहुत अधिक आउटबाउंड ट्रैफिक कर रहे हैं, हम डॉकटर के बजाय एलएक्ससी का भी उपयोग करते हैं लेकिन बग बिल्कुल वैसा ही है जैसा कि यहां वर्णित है, मैं पुन: पेश करने का प्रयास कर सकता हूं अपनी पद्धति का उपयोग करना यदि इसका वर्णन करना आसान है और/या इसमें उत्पादन भार शामिल नहीं है, तो विचार क्रैशडम्प प्राप्त करना है और _maybe_ इस बग को वास्तव में ट्रिगर करने के बारे में अधिक संकेत प्राप्त करना है।

@rsampaio मैं https://github.com/crosbymichael/docker-stress के लंबे समय तक उपयोग के साथ पुन: पेश कर सकता हूं

क्या इसे ठीक करने के लिए कोई अपडेट/प्रस्ताव आया है?

@joshrendek यह एक कर्नेल बग है। ऐसा लगता है कि हाल ही में जारी कर्नेल 4.4 भी इसे ठीक नहीं करता है, इसलिए कहीं न कहीं कम से कम एक और दौड़ की स्थिति है :)

कर्नेल बग

=)

@samvignoli क्या आप अपनी टिप्पणियों को रचनात्मक रख सकते हैं? यदि आपके पास इस समस्या को ठीक करने के तरीके हैं तो पीआर खोलने के लिए स्वतंत्र महसूस करें।

क्या यह बग पहले से ही अपस्ट्रीम (कर्नेल मेलिंगलिस्ट) की सूचना दी गई थी?

ज़रूर हुआ है। पहली टिप्पणी इस बग का भी संदर्भ देती है: https://bugzilla.kernel.org/show_bug.cgi?id=81211

2014 के बाद से खुला। इस पर काम करने वाले किसी भी व्यक्ति की कोई टिप्पणी नहीं, हालांकि यह कहने के अलावा कि यह सबसे अधिक संभावना है कि यह गलत तरीके से उपयोग करने वाला एप्लिकेशन है।

लिंक के लिए धन्यवाद, जस्टिन! मैं लिनुस को ट्रोल करूँगा =)

सधन्यवाद। =* :दिल:

@samvignoli कृपया ऐसा न करें, यह किसी की मदद नहीं करता है।
क्या कोई इसे छोटी वीएम छवि में पुन: पेश कर सकता है?
हो सकता है कि मैं अपने हाथों को gdb और बहुत सारे kprintf से गंदा कर सकूं।

बग अभी भी खुला है।

ओएस: सेंटोस 7.2
कर्नेल: 4.4.2 एलरेपो कर्नेल-एमएल
डोकर: 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 image चलाते समय यह लॉग शो:

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

मैं बस भाग्यशाली हो सकता हूं - लेकिन इन sysctl सेटिंग्स को लागू करने के बाद ऐसा होने की घटना कम हो गई है।

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

@joshrendek इन सेटिंग्स के पीछे क्या प्रेरणा है?

@kmike यह कुछ अन्य कॉनट्रैक मुद्दों (आईपी टेबल पूर्ण होने) को ठीक करने के लिए था जो हम अनुभव कर रहे थे - ऐसा लगता है कि साइड इफेक्ट के रूप में मेरे मूल मुद्दे के संबंध में कुछ किया गया है

क्या आप पहले/बाद में दिखा सकते हैं ताकि हम देख सकें कि वास्तव में क्या बदला है? क्या आप इन सेटिंग्स को बाइनरी खोजने के लिए तैयार हैं और देखें कि कोई छोटा सेट है या नहीं?

मैं एक कंप्यूट इंजन VM में CoreOS स्टेबल (899.13.0) का उपयोग कर रहा हूं। यह त्रुटि तब होती है जब मैं सर्वर को निम्न ध्वज के साथ 0 (डिफ़ॉल्ट) पर प्रारंभ करता हूं। मैंने कई बार आगे और पीछे परीक्षण किया है और IPv6 अक्षम होने पर मैं बिना किसी त्रुटि के सभी कंटेनरों को नोड में शुरू कर सकता हूं:

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

मैं GCR से डाउनलोड करने के लिए gcloud कंटेनर का उपयोग करता हूं, इसलिए शायद समस्या IPv6 + छवियों के MB का डाउनलोड + कंटेनरों को जल्दी से बंद करने की है।

संदर्भ के लिए डॉकर संस्करण:

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-proxy बंद हो (--userland-proxy=false)।

मैंने यह उपयोगकर्तालैंड प्रॉक्सी सक्षम के साथ और उसके बिना किया है, इसलिए मैं केवल यह नहीं कहूंगा कि यह कब बंद है।

हो सकता है कि यह स्थिति को और खराब कर दे; मुझे पता है कि हमने एक बार --userland-proxy=false को डिफ़ॉल्ट बनाने की कोशिश की थी, लेकिन इसे उलट दिया क्योंकि इसके दुष्प्रभाव थे https://github.com/docker/docker/issues/14856

मैंने कल से एक बार त्रुटि भी देखी है, स्पष्ट रूप से IPv6 को अक्षम करना यह ठीक नहीं है; लेकिन झंडे के बिना मैं सर्वर के सभी कंटेनरों को डॉकटर को ट्रैश किए बिना भी शुरू नहीं कर सकता।

कुबेरनेट्स 1.2.2 और डॉकर 1.10.3 . के साथ CoreOS 1010.1.0 पर इसमें चल रहा है

Kubernetes ने क्यूबलेट में एक ध्वज जोड़ा (मोबाइल पर, इसलिए इसे नहीं देखा जा सकता)
हेयरपिन मोड। इसे "विशाल पुल" या जो भी मान्य हो, में बदलें
मूल्य है। हमने उस परिवर्तन को करने के बाद से यह त्रुटि नहीं देखी है।

@bprashanh

कृपया पुष्टि करें या खंडन करें?
13 अप्रैल 2016 को दोपहर 12:43 बजे, "आरोन क्रिकेनबर्गर" नोटिफिकेशन @github.com
लिखा था:

कोरओएस 1010.1.0 पर कुबेरनेट्स 1.2.2 और डॉकर के साथ इसमें चल रहा है
1.10.3

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/docker/docker/issues/5618#issuecomment -209617342

इसे डॉकर संस्करण 1.9.1 के साथ लिनक्स 4.4.5-15.26.amzn1.x86_64 चलाने वाले AWS पर प्राप्त करना, a34a1d5/1.9.1 का निर्माण करना।

रूबी 2.3.0 अल्पाइन छवि के साथ कंटेनर के अंदर चल रहा है जिससे यह हो रहा है

कर्नेल: [५८५५१.५४८११४] unregister_netdevice: लो के मुक्त होने की प्रतीक्षा में। उपयोग गिनती = 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 बजे, सुने केलर नोटिफिकेशन @github.com
लिखा था:

@MrMMorris https://github.com/MrMMorris जैसा कि आप निश्चित हैं, निश्चित है
समस्या हमेशा के लिए दूर हो गई है, या इसमें कि आप इसे फिर से अनुभव नहीं कर रहे हैं
बस अभी तक? दौड़ की स्थिति हो सकती है ...

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/docker/docker/issues/5618#issuecomment -216444133

हाँ। मैंने कर्नेल 4.5 के साथ CoreOS 1032.0.0 की कोशिश की, और समस्या अभी भी मौजूद है।

मैंने कल कोरओएस 1010.1.0 पर कर्नेल 4.5.0 के साथ इसका सामना किया, यह कई कंटेनरों के शुरू होने और तेजी से उत्तराधिकार में मारे जाने के बाद हुआ था।

मुझे यह त्रुटि मिली है।

डॉकर संस्करण: 1.9.1
कर्नेल संस्करण: 4.4.8-20.46.amzn1.x86_64
ऑपरेटिंग सिस्टम: अमेज़न लिनक्स एएमआई 2016.03

@sirlatrom तय नहीं है। इसे फिर से देखना हल करने के लिए कई रीबूट की आवश्यकता है।

वर्तमान में 3.19.0-18-जेनेरिक चल रहा है। नवीनतम में अपग्रेड करने का प्रयास करेंगे

मेरा भी यही विचार है! रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना रोना: :रोना::रोना::रोना::रोना::रोना::रोना::रोना::रोना::रोना::रोना::रोना::रोना::रोना::रोना::रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना: रोना

@samvignoli आपकी टिप्पणियाँ रचनात्मक नहीं हैं। कृपया पोस्ट करना बंद करें।

क्षमा करें, थम्स अप फंक्शन भूल गए।

फेडोरा सर्वर 23 - 4.2.5-300.fc23.x86_64 में पुन: उत्पादित। डॉकर सेवा को पुनरारंभ नहीं कर सकता - केवल नोड को रीबूट करें।

फेडोरा 24 कर्नेल पर एक ही मुद्दा: 4.5.2-302.fc24.x86_64। कोई हैंग नहीं हुआ, लेकिन एक लॉग फ़ाइल को स्पैम करता है।

@hapylestat क्या आप systemctl restart docker कोशिश कर सकते हैं? इससे यह सब मेरे लिए लटक गया।

धन्यवाद

यह मेरी (CoreOS, EC2) मशीनों के साथ अक्सर हो रहा है। यदि यह बिल्कुल भी मददगार है, तो इस बग के एक उदाहरण में अटके हुए वीथ डिवाइस से संबंधित सभी लॉग यहां दिए गए हैं।

$ 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 करता है।

हो सकता है कि समस्या मिल गई हो (या बस भाग्यशाली हो)। मैंने डॉकर ग्राफ डीआईआर को एक एक्सएफएस विभाजित डिस्क से एक EXT4 विभाजित डिस्क पर स्थानांतरित कर दिया है और मैं इस मुद्दे को पुन: उत्पन्न नहीं कर सकता (साथ ही साथ मुझे प्राप्त होने वाले अन्य एक्सएफएस बग्स का भार हल करना)। मुझे याद है @vbatts कह रहा है कि XFS अभी समर्थित नहीं है।

मैंने विभिन्न छवियों पर एक अनंत लूप में build , run , stop , delete चलाकर उत्तेजित करने की कोशिश की है, प्रत्येक चक्र के लिए लगभग 10 कंटेनर बनाकर, पिछले कुछ घंटों।

@joedborg आप किस ग्राफड्राइवर का उपयोग कर रहे हैं? डिवाइसमैपर? ओवरले?

@thaJeztah अच्छा बिंदु, मुझे इसका उल्लेख करना चाहिए था। मैं (अब) EXT4 बैकिंग FS के साथ ओवरले ड्राइवर का उपयोग कर रहा हूं।

मैं डिवाइमेपर का उपयोग करता था (क्योंकि मैं फेडोरा सर्वर का उपयोग कर रहा हूं), लेकिन मुझे बहुत दर्द था (जैसा कि मेरा मानना ​​​​है कि कई लोग करते हैं), विशेष रूप से लीक के साथ जहां एक बार कंटेनर को हटा दिए जाने के बाद मैपर पूल में जगह नहीं लौटाएगा।

अगर यह मदद करता है, तो मैं डॉकर 1.11.1 और कर्नेल 4.2.5-300.fc23.x86_64 पर हूं।

@joedborg दिलचस्प है, क्योंकि आरएचईएल /सेंटोस 7.1 पर केवल EXT4 समर्थित है, और केवल आरएचईएल/सेंटोस 7.2 पर एक्सएफएस समर्थित है। मुझे उम्मीद है कि XFS तब नए संस्करणों पर काम करेगा

@thaJeztah आह यह अजीब है। मैं अन्य चीजों के बारे में सोचने की कोशिश कर रहा हूं जो यह हो सकता है। मैंने ऊपर से फिर से पढ़ा है और ऐसा लगता है कि कुछ लोग एक ही कॉन्फ़िगरेशन चला रहे हैं। केवल दूसरी चीज जो अलग है वह यह है कि XFS डिस्क स्पिंडल है और EXT4 SSD है। मैं इस बीच सोख परीक्षण करता रहूंगा। मैंने उसी सेटअप का उपयोग करने के लिए उत्पादों को भी स्थानांतरित कर दिया है, इसलिए किसी भी तरह से हमारे पास बहुत पहले उत्तर होगा। हालांकि, यह पहले लगभग हर stop पर कर रहा था, इसलिए यह निश्चित रूप से बेहतर है।

@joedborg ठीक है, यह वास्तव में उपयोगी जानकारी है

यहाँ वही त्रुटि, कर्नेल 4.2 से 4.5 तक, वही docker verion।

बीटीडब्लू, मैं एक ही समय में एक ही बॉक्स पर कई वर्चुअलबॉक्स मशीन चला रहा हूं।

$ 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 के साथ भी मारा। एकमात्र समाधान, मैं वर्तमान में देख रहा हूं, कंटेनर को समवर्ती रूप से रोकना नहीं है।

अगर यह मदद करता है, तो मुझे एडब्ल्यूएस एएमआई द्वारा समर्थित नवीनतम ईसी 2 इंस्टेंस पर एक ही त्रुटि संदेश मिल रहा है। डॉकर संस्करण दिखाता है-

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
स्टोरेज ड्राइवर: डिवाइसमैपर
पूल का नाम: डॉकर-202:1-263705-पूल
पूल ब्लॉक आकार: 65.54 kB
बेस डिवाइस का आकार: 107.4 जीबी
बैकिंग फाइल सिस्टम:
डेटा फ़ाइल: /dev/loop0
मेटाडेटा फ़ाइल: /dev/loop1
प्रयुक्त डेटा स्थान: 1.199 जीबी
डेटा स्पेस कुल: १०७.४ जीबी
डेटा स्थान उपलब्ध: 5.754 जीबी
प्रयुक्त मेटाडेटा स्पेस: 2.335 एमबी
मेटाडेटा स्पेस टोटल: २.१४७ जीबी
मेटाडेटा स्पेस उपलब्ध: २.१४५ जीबी
उदेव सिंक समर्थित: सच
आस्थगित निष्कासन सक्षम: असत्य
आस्थगित विलोपन सक्षम: असत्य
आस्थगित हटाए गए डिवाइस की संख्या: 0
डेटा लूप फ़ाइल: /var/lib/docker/devicemapper/devicemapper/data
मेटाडेटा लूप फ़ाइल: /var/lib/docker/devicemapper/devicemapper/metadata
पुस्तकालय संस्करण: 1.02.93-आरएचईएल7 (2015-01-28)
निष्पादन चालक: देशी-0.2
लॉगिंग ड्राइवर: json-file
कर्नेल संस्करण: 4.4.10-22.54.amzn1.x86_64
ऑपरेटिंग सिस्टम: अमेज़न लिनक्स एएमआई 2016.03
सीपीयू: 1
कुल मेमोरी: 995.4 एमआईबी
नाम: [संशोधित]
आईडी: OB7A:Q6RX: ZRMK:4R5H : ZUQY:BBNK : BJNN:OWKS :FNU4:7NI2: AKRT:5SEP

$ डोकर संस्करण
ग्राहक:
संस्करण: 1.9.1
एपीआई संस्करण: 1.21
गो संस्करण: go1.4.2
गिट प्रतिबद्ध: a34a1d5/1.9.1
बनाया:
ओएस/आर्क: linux/amd64

सर्वर:
संस्करण: 1.9.1
एपीआई संस्करण: 1.21
गो संस्करण: go1.4.2
गिट प्रतिबद्ध: a34a1d5/1.9.1
बनाया:
ओएस/आर्क: linux/amd64

उपरोक्त टिप्पणियों के समान, ईसी 2 पर चलने वाला लोचदार बीनस्टॉक के माध्यम से भी होता है 64bit Amazon Linux 2016.03 v2.1.0 running Docker 1.9.1

इस समय कुछ हद तक वास्तविक, लेकिन मैंने हाल ही में परीक्षण के रूप में लगभग 18 सर्वरों पर 4.2.0 से 4.5.5 कर्नेल को अपग्रेड करने का प्रयास किया, और यह समस्या काफी खराब हो गई (कई दिनों से लेकर मुद्दों के बीच 4 घंटे से अधिक नहीं)।

यह डेबियन 8 . पर था

बिल्कुल वैसा ही सेटअप जैसा @g0ddard

हम यह देखना चाहते हैं कि हम इस बग को कैसे कम कर सकते हैं।
पहली बात (जो काम कर भी सकती है और नहीं भी, यह जोखिम भरा है) एपीआई को ऐसे मामलों में उपलब्ध रखना है जहां ऐसा होता है: #23178

नमस्ते। मुझे भी इस बग ने काट लिया है...

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

मैं CoreOS बीटा, फलालैन पर Kubernetes 1.2.4 का उपयोग कर रहा हूं और Azure पर चल रहा हूं। क्या इस मुद्दे को डीबग करने में मदद करने के लिए कोई है? कर्नेल बग थ्रेड मृत लगता है। कुछ लोग रिपोर्ट करते हैं कि कर्नेल पर IPv6 को अक्षम करना, --userland-proxy=true का उपयोग करना या ओवरले स्टोरेज सहायता के बजाय aufs का उपयोग करना, जबकि अन्य नहीं करते हैं... यह थोड़ा भ्रमित करने वाला है।

@justin8 की तरह मैंने अपने फेडोरा 23 सिस्टम को कर्नेल 4.5.5 में अपग्रेड करने के बाद भी इस पर ध्यान दिया; समस्या कर्नेल 4.5.6 के साथ बनी हुई है।

हमें इस बग का सामना तब हुआ जब कंटेनर अपनी मेमोरी लिमिट को हिट कर रहा था। सुनिश्चित नहीं है कि यह संबंधित है या नहीं।

यहाँ एक ही मुद्दा

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

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

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

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

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

सेंटोस7.2
डोकर 1.10.3
एक ही समस्या

मेरे पास एक "वन लाइनर" है जो अंततः मेरे लिए इस मुद्दे को EC2 (m4.large) पर 4.6.3 कर्नेल (बहुत हाल ही में) के साथ CoreOS 1068.3.0 चला रहा है। मेरे लिए, इसमें लगभग 300 पुनरावृत्तियां होती हैं लेकिन वाईएमएमवी।

Linux ip-172-31-58-11.ec2.internal 4.6.3-coreos #2 SMP शनि जून 25 00:59:14 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz GenuineIntel जीएनयू/लिनक्स
कोरओएस बीटा (1068.3.0)
डॉकर संस्करण 1.10.3, 3cd164c . का निर्माण करें

यहां लूप के कुछ सौ पुनरावृत्तियों को अंततः डॉकर्ड लटका दिया जाएगा और कर्नेल त्रुटि संदेश उत्सर्जित करेगा जैसे

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

पुनरुत्पादक लूप है

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

संपादन

• मैं केवल इसके साथ पुन: पेश करने में सक्षम हूं जब userland-proxy=false
• मैं VirtualBox (केवल ec2 अब तक) का उपयोग करके पुन: पेश करने में सक्षम नहीं हूं, इसलिए शायद यह हाइपरवाइजर से भी संबंधित है

@btalbot की स्क्रिप्ट, ऊपर, कई हज़ार पुनरावृत्तियों के बाद फेडोरा 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)

यह समस्या मेरे कुबेरनेट्स क्लस्टर पर अक्सर होती है, हालाँकि मैं इसे स्ट्रेसर्स या

पहला VM एक Standard_D1_v2 (3.5GB RAM, 1 कोर) था - स्क्रिप्ट ने> 3000 पुनरावृत्तियों को किया।
दूसरा VM एक Standard_DS15_v2 (140GB RAM, 20 कोर) था - स्क्रिप्ट ने> 7600 पुनरावृत्तियों को किया।

मैंने अपनी पिछली टिप्पणी को अपडेट किया है (https://github.com/docker/docker/issues/5618#issuecomment-229545933) यह शामिल करने के लिए कि मैं इसे केवल तभी पुन: पेश कर सकता हूं जब userland-proxy=false।

यह मेरे लिए EC2 t2.micro (सिंगल कोर) VMs के साथ-साथ m4.large (मल्टी कोर) दोनों पर HVM का उपयोग करके पुन: पेश करता है। यह मेरे लैपटॉप पर वर्चुअलबॉक्स का उपयोग करते हुए नहीं देखा है, हालांकि उपयोगकर्तालैंड-प्रॉक्सी की सेटिंग से कोई फर्क नहीं पड़ता।

कुबेरनेट्स क्लस्टर (iptables प्रॉक्सी का उपयोग करके) में सक्षम हेयरपिन-वीथ के साथ फलालैन का उपयोग करते समय हमें इस बग का सामना करना पड़ा है। यह बग तभी हो रहा था जब हम बहुत सारे कंटेनर को रन-स्टॉप कर रहे थे। हम cbr0 ब्रिज नेटवर्क और प्रोमिससियस-ब्रिज हेयरपिन मोड का उपयोग करने के लिए स्विच करते हैं और इसे फिर कभी नहीं देखते हैं।
वास्तव में इस बग को पुन: उत्पन्न करना आसान है यदि आप हेयरपिन-वेथ का उपयोग कर रहे हैं, तो बस इस काम को 100 कंटेनरों के साथ कुबेरनेट्स के साथ शुरू

01/07/2016 08:01 को, manoj0077 ने लिखा:

@btalbot https://github.com/btalbot तो 1.12 के साथ हम पुनः आरंभ कर सकते हैं
डॉकर्ड चल रहे कंटेनरों को प्रभावित किए बिना। तो क्या डॉकर्ड पुनरारंभ होगा
इस मामले में यहाँ मदद करें?

AFAICT, 1.12 के साथ घटना, डॉकटर कंटेनर प्रक्रियाएं अभी भी बच्चे हैं
डॉकर डेमॉन का।

@sercand आपने विशिष्ट-पुल हेयरपिन मोड कैसे सेट किया? मैं इसके बारे में डॉकर से कोई दस्तावेज नहीं देख सकता, या शायद वे एक अलग नाम का उपयोग कर रहे हैं

क्या डॉकर से कुछ आधिकारिक शब्द है जब इसे देखा जा सकता है? यह दूसरा सबसे अधिक टिप्पणी किया गया खुला मुद्दा है ; बहुत गंभीर है (होस्ट पुनरारंभ की आवश्यकता है); प्रतिलिपि प्रस्तुत करने योग्य है; और मुझे मूल कारण का पता लगाने या इसे ठीक करने की दिशा में कोई वास्तविक प्रगति दिखाई नहीं दे रही है।

यह एक कर्नेल समस्या होने की सबसे अधिक संभावना है, लेकिन बगजिला पर टिकट महीनों से स्थिर है। क्या हमारे परीक्षण मामलों को वहां पोस्ट करना सहायक होगा?

@justin8 मुझे लगता है कि वे क्यूबलेट झंडे हैं: --configure-cbr0 और --hairpin-mode

@sercand मैं फलालैन का भी उपयोग करता हूं। क्या --hairpin-mode=promiscuous-bridge का उपयोग करने में कोई नुकसान है?

@obeattie मैं सहमत हूँ। :(

FTR मैं @sercand एक परीक्षण Kubernetes क्लस्टर है कि मैं की स्थापना पर की stresser काम है, यह भी फलालैन और बाल के लिये कांटा-veth का उपयोग करता है का उपयोग कर समस्या को दोहराने में कामयाब रहे।

@sercand क्या आप कृपया promiscuous-bridge का उपयोग शुरू करने के चरणों का विवरण दे सकते हैं? मैंने नोड के क्यूबलेट में ध्वज --configure-cbr0=true जोड़ा लेकिन यह शिकायत करता है:
ConfigureCBR0 requested, but PodCIDR not set. Will not configure CBR0 right now । मैंने सोचा था कि यह पॉडसीआईडीआर मास्टर से आना चाहिए था? धन्यवाद।

संपादित करें: ऐसा लगता है कि मुझे नियंत्रक प्रबंधक कॉन्फ़िगरेशन में --allocate-node-cidrs=true --cluster-cidr=10.2.0.0/16 जोड़ने की आवश्यकता है, लेकिन चूंकि मेरे पास क्लाउड प्रदाता (Azure) नहीं है, इसलिए मार्ग शायद काम नहीं करेंगे।

@justin8 मैंने इस डॉक्टर का अनुसरण किया है।
दस्तावेज़ीकरण हेयरपिन-मोड से @edevil "यह किसी सेवा के एंडपॉइंट्स को स्वयं को वापस लोड करने की अनुमति देता है यदि उन्हें अपनी स्वयं की सेवा तक पहुंचने का प्रयास करना चाहिए"। वैसे मेरा क्लस्टर Azure पर चलता है और इसे हासिल करना आसान काम नहीं था।

@sercand दस्तावेज़ के अनुसार, यदि हम नियंत्रक प्रबंधक पर --allocate-node-cidrs=true का उपयोग करते हैं तो हमें मार्गों को सेट करने के लिए क्लाउड प्रदाता का उपयोग करना चाहिए। चूँकि Azure के लिए कोई Kubernetes क्लाउड प्रदाता नहीं है, क्या आपको समस्या नहीं हुई? क्या आप मैन्युअल रूप से मार्ग सेट करते हैं? धन्यवाद।

@edevil मैं मार्ग बनाने के लिए टेराफॉर्म का उपयोग इस रेपो में पा सकते हैं। मैंने जल्दी से यह कॉन्फ़िगरेशन बनाया है और केवल एक बार परीक्षण किया है। मुझे आशा है कि इसके पीछे बुनियादी तर्क प्रदान करने के लिए पर्याप्त है।

@morvans @btalbot क्या आपको 1.12 ... के साथ प्रयास करने का मौका मिला?

मैं पुष्टि कर सकता हूं कि हेयरपिन-वेथ से दूर जाकर cbr0 ब्रिज का उपयोग करके मैं अब समस्या को पुन: उत्पन्न नहीं कर सकता।

बस के मामले में: किसी को भी नंगे धातु पर यह समस्या है? हमने इसे तब देखा है जब हमारे VMWare लैब पर रैंचर क्लस्टर का परीक्षण किया गया था, लेकिन वास्तविक नंगे धातु परिनियोजन पर कभी नहीं देखा गया।

हाँ, यह समस्या किसी भी कर्नेल>= 4.3 के लिए नंगे धातु पर होती है। इसे कई अलग-अलग मशीनों और हार्डवेयर कॉन्फ़िगरेशन पर देखा है। हमारे लिए एकमात्र समाधान कर्नेल 4.2 का उपयोग करना था।

यह निश्चित रूप से अभी भी 4.2 पर होता है, लेकिन यह किसी भी नई चीज़ पर अधिक बार परिमाण का क्रम है, मैं यह देखने के लिए प्रत्येक प्रमुख रिलीज़ का परीक्षण कर रहा हूं कि क्या यह बेहतर है, और अभी तक कुछ भी नहीं है

CoreOS अल्फा 1097.0.0 पर भी होता है।

कर्नेल: 4.6.3
डॉकर: 1.11.2

मुझे एक ही मुद्दा मिलता है।

डॉकर: 1.11.2
कर्नेल: 4.4.8-boot2docker.

होस्ट: ओएस एक्स पर वीएमवेयर फ्यूजन ड्राइवर के साथ डॉकर-मशीन।

कोई सुझाए गए कामकाज?

वास्तव में मददगार होगा यदि आप में से जो इस मुद्दे को मज़बूती से ऐसे वातावरण में पुन: पेश कर सकते हैं जहाँ एक क्रैशडंप संभव है (उर्फ EC2 नहीं) वास्तव में इस क्रैशडम्प फ़ाइल को साझा कर सकते हैं, 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

क्रैशडंप वास्तव में कर्नेल डेवलपर्स को संदर्भ रिसाव के कारण के बारे में अधिक जानने में मदद कर सकता है, लेकिन ध्यान रखें कि क्रैशडंप में आपके होस्ट का मेमोरी डंप भी शामिल है और इसमें समझदार जानकारी हो सकती है।

...समझदार जानकारी।

:ओ

मैं एक ही मुद्दे में भाग रहा हूँ।

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

(मेरे सभी पीटी + बीपर पर जब ऐसा होता है)
"बस" डेबियन जेसी + बैकपोर्ट:

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

नमस्ते,

जब मैं नष्ट करने वाली नई छवियों को बनाकर नियंत्रित वातावरण पर इस मुद्दे को दोहराने की कोशिश करता हूं तो मैं इसे पुन: उत्पन्न नहीं कर सकता।

यह समस्या डॉकटर 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 कंटेनर लंच करता हूं और इंटरनेट पर ट्रैफिक बढ़ाता हूं, बिना किसी वीथ * इंटरफेस को लीक किए। क्या कोई समस्या को लगातार पुन: उत्पन्न करने के लिए निर्देश पेस्ट कर सकता है?

@pegerto को ट्रिगर करना बहुत आसान होना चाहिए यदि आपके पास --userland-proxy=false और समवर्ती रूप से कंटेनरों का एक गुच्छा स्पिन करें। मैं इसे https://github.com/crosbymichael/docker-stress का उपयोग करके करता हूं

धन्यवाद @cpuguy83

--userland-proxy=false लिए डेमॉन को कॉन्फ़िगर करना मैं आसानी से इस मुद्दे को पुन: उत्पन्न कर सकता हूं, धन्यवाद, हम इस समस्या को उन डेमॉन को प्रभावित करते हुए देख सकते हैं जो इस कॉन्फ़िगरेशन को नहीं चलाते हैं।

मुझे नेटफिल्टर हुक पर एक कर्नेल डंप दिखाई देता है, जो नेट्स सेग्रीगेशन द्वारा> = 4.3 पर पेश किया गया है, कोई विचार है कि जब रूट 127/8 पर होता है तो समस्या क्यों बदतर होती है?

धन्यवाद

इस मामले को भी देख रहे हैं। कोरओएस 1068.8.0, डॉकर 1.10.3, कर्नेल 4.6.3। अगर कोई दिलचस्पी लेता है तो मैंने कुछ सिस्टम लॉग खींचे हैं।

अभी कई मिले...
unregistered_netdevice: waiting for lo to become free. Usage count = 1
... 2 वीएम पर और मेरे बेयरमेटल लैपटॉप पर, सभी उबंटू 16.04 और नवीनतम कर्नेल (4.4.0-3 [456]) चला रहे हैं।

नतीजा यह है कि सब कुछ लटक गया है और एक कठिन रीबूट की आवश्यकता है।
पिछले सप्ताह से पहले इसका अनुभव नहीं किया है और मुझे लगता है कि वीएम में से एक 1.11.3 पर था जबकि अन्य सभी 1.12.0 पर थे।

@RRAlex यह किसी डॉकर संस्करण के लिए विशिष्ट नहीं है।
यदि आप डेमॉन विकल्पों पर --userland-proxy=false का उपयोग कर रहे हैं ... या (जो मैं समझता हूं) आप कुबेरनेट्स का उपयोग कर रहे हैं तो आप इस मुद्दे को हिट करेंगे।

इसका कारण यह है कि --userland-proxy=false विकल्प ब्रिज इंटरफेस पर हेयरपिन NAT को सक्षम बनाता है... यह कुछ ऐसा है जो कुबेरनेट्स अपने कंटेनरों के लिए नेटवर्किंग सेट करते समय भी सेट करता है।

इसे डॉकर क्लाउड (और डॉकर क्लाउड एजेंट) का उपयोग करके BYO नोड पर देखना।

इसे आज देखा, एक बार (लगभग 25 कोशिशों में से) वर्तमान अमेज़ॅन ईसीएस एएमआई पर, वेनिला डेबियन चला रहा है

@edevil
आप में से अधिकांश लोग यहां वर्णन करते हैं कि कंटेनरों को शुरू/रोकने के लिए डॉकर का उपयोग करते समय आप इस स्थिति का सामना करते हैं, लेकिन मुझे डॉकर के बिना डेबियन पर बिल्कुल वही स्थिति मिली:

• डेबियन "जेसी" (= डेबियन संस्करण 8.5), बेयरमेटल पर (कोई वीएम नहीं, कोई क्लाउड नहीं, लेकिन सादा हार्डवेयर)
• कर्नेल 3.16.0-4-amd64
• 4 LXC कंटेनर शुरू करें
• "lxc-stop -n $containerName" के साथ एक LXC कंटेनर बंद करें
• जब यह आदेश पूरा हो जाता है, तो कर्नेल या इंटरफेस शायद पूरी तरह से 'क्लीन अप' नहीं होते हैं, क्योंकि जब मैं पिछले "एलएक्ससी-स्टॉप" के तुरंत बाद एक नया "एलएक्ससी-स्टॉप" लॉन्च करता हूं, तो मुझे कर्नेल समस्या होती है

मशीन के हार्ड रीसेट के अलावा ठीक होने का कोई तरीका नहीं है।

तो कृपया, इस मुद्दे को इंगित करने / हल करने के लिए अपनी जांच में, अकेले डॉकर पर ध्यान केंद्रित न करें। यह स्पष्ट रूप से कंटेनरों के तेज स्टॉप/स्टार्ट के साथ एक सामान्य मुद्दा है, चाहे वह डॉकर के माध्यम से हो, या सादे "एलएक्ससी" कमांड के माध्यम से हो।

मुझे लगता है कि यह लिनक्स कर्नेल की समस्या है।

मैं इस समस्या से तब मिला जब मेरे पास 3 क्रोट (वास्तव में पीबिल्डर) बहुत भारी भार के साथ चल रहे थे।
मेरा हार्डवेयर लूंगसन 3ए (3.16 कर्नेल के साथ एक mips64el मशीन) है।

जब मैं इसमें एसएसएच करने की कोशिश कर रहा हूं, तो मुझे यह समस्या मिली है।

तो यह समस्या केवल docker या lxc के बारे में ही नहीं है, यह chroot के बारे में भी है।

डॉकर संस्करण 1.11.2।

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

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

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

अरक्षित धातु।

कर्नेल 4.6.x और डॉकर 1.11.2 के साथ हाल ही में हमारे पास नंगे धातु (ओवीएच पर समर्पित) पर समस्या थी।
यहां टिप्पणियों को पढ़ने और कई समाधान आजमाने के बाद, हमने अपने कर्नेल को 3.14 शाखा (3.14.74) के नवीनतम संस्करण में डाउनग्रेड किया और https://github.com/docker/libnetwork/issues/1189 से बचने के लिए डॉकर को 1.12.0 में अपग्रेड किया। और ऐसा लगता है कि अभी के लिए सब कुछ ठीक है।

मुझे आशा है कि यह मदद कर सकता है।

सब, मुझे लगता है कि अब आपको डॉकर या चेरोट के बारे में संदेश पोस्ट करने की आवश्यकता नहीं है, यह सब लिनक्स कर्नेल के बारे में है।
तो कृपया, क्या कोई खड़ा हो सकता है जो किसी तरह से कर्नेल को डिबग कर सकता है, उन हिस्सों में जहां यह कंटेनरों के लिए वर्चुअल नेटवर्क इंटरफेस को अक्षम कर रहा है? हो सकता है कि कुछ दौड़ की स्थिति हो रही हो, जब कंटेनर के एक नए स्टॉप का अनुरोध करने से पहले कंटेनर के पिछले स्टॉप ने अपने वर्चुअल इंटरफ़ेस को पूरी तरह से अक्षम/क्लीनअप नहीं किया था।

@rdelangh मुझे नहीं लगता कि यह मुद्दा आवश्यक रूप से कर्नेल से संबंधित है।

फेडोरा 24 पर, मैं फेडोरा रेपो से डॉकर 1.10.3 के साथ समस्या को पुन: पेश नहीं कर सकता, केवल डॉकर 1.12.1 के साथ डॉकर के स्वयं के रेपो से।

दोनों परीक्षण कर्नेल 4.6.7-300.fc24.x86_64 के साथ आयोजित किए गए थे।

इस समस्या को CoreOS 1068.10.0, Docker 1.10.3, कर्नेल 4.6.3 पर भी देख रहे हैं।

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

EC2 पर स्थिर CoreOS 1068.9.0 पर Kubernetes 1.3.4 का उपयोग करना, docker 1.10.3 मुझे यह समस्या दिखाई देती है।

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

इस मुद्दे को उबंटू 16.04, डॉकर 1.12.1, कर्नेल 4.4.0-34-जेनेरिक पर भी देखना
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

कुबेरनेट्स <= 1.3.4 का उपयोग करने वालों के लिए आप इस समस्या का फायदा उठा सकते हैं: https://github.com/kubernetes/kubernetes/issues/30899 इस समस्या को पुन: उत्पन्न करने के लिए। मैंने CoreOS 1068.10 पर 1 कंट्रोलर (m4.large) और 2 वर्कर्स (m4.large) के साथ एक छोटा क्लस्टर चलाया।

वहां से आप 2 प्रतिकृति नियंत्रक बना सकते हैं, मैंने उन्हें इस पर आधारित hello और hello1 : http://pastebin.com/mAtPTrXH । अलग-अलग होने के लिए नाम और लेबल बदलना सुनिश्चित करें।

फिर, इस पर आधारित समान नाम/लेबल से मेल खाते हुए 2 परिनियोजन बनाएं: http://pastebin.com/SAnwLnCw ।

_जैसे ही आप परिनियोजन बनाते हैं, आपको अत्यधिक मात्रा में स्पैम कंटेनर मिल जाएंगे_.

यदि आप इसे थोड़ी देर (कई मिनट) के लिए छोड़ देते हैं, तो आप देखेंगे कि बहुत सारी चीज़ें समाप्त/बनाने की कोशिश कर रही हैं। आप परिनियोजन हटा सकते हैं और चीजों को स्थिर होने दे सकते हैं। आपको एक अच्छा मुट्ठी भर टर्मिनेटिंग और कंटेनर क्रिएटिंग देखना चाहिए। यदि आप नोड्स में ssh करते हैं, तो उपरोक्त लक्षण स्पष्ट हैं या नहीं यह देखने के लिए dmesg और docker ps करें।

मेरे उदाहरण में इस मुद्दे को देखने से पहले इस सनकी को बाहर निकालने में मुझे लगभग 5 मिनट का समय लगा। मैं उन परिवर्तनों को करने की योजना बना रहा हूं जो @sercand और @edevil साथ कर रहे थे और देखें कि यह इस मामले में मेरे लिए काम करता है या नहीं।

@edevil आपकी लिंक की गई प्रतिबद्धता को cbro पुल के पक्ष में अपने वातावरण में फलालैन को पूरी तरह से अक्षम/हटा दिया है?

मैं अपने अंत में देख रहा हूं कि आप उन्हें अग्रानुक्रम में उपयोग नहीं कर पाएंगे क्योंकि फलालैन docker0 का उपयोग करना चाहता है और आपकी आंतरिक नेटवर्किंग cbr0 सही पर काम कर रही होगी?

@ अल्फा 486 यह सही है, मैंने फलालैन का उपयोग करना बंद कर दिया है। मैं ब्रिज का उपयोग करता हूं और पॉड नेटवर्क के लिए रूट सेट करता हूं।

@ अल्फा 486 फलालैन --bridge=cbr0 docker विकल्प से ओवरराइड कर सकते हैं।
CoreOS पर आपको docker systemd यूनिट को ओवरराइड करना होगा।

क्यूबलेट ध्वज --experimental-flannel-overlay फलालैन कॉन्फ़िगरेशन को पढ़ सकता है, और डॉकर ब्रिज cbr0 को फलालैन CIDR के साथ कॉन्फ़िगर कर सकता है।

यह भी सक्षम हो जाएगा promiscuous के बजाय मोड veth-hairpin जो मुद्दा हो रहा है।

इनपुट के लिए धन्यवाद @dadux । यदि K8s cbr0 इंटरफ़ेस को चुनता है जिसे पहले ही ओवरराइड इकाई द्वारा बूटस्ट्रैप किया जा चुका है, तो उस समाधान के साथ व्यवसाय में हो सकता है; मैं इसे आजमाऊंगा।

डॉक्स के अनुसार, promiscuous-bridge क्यूबलेट v1.3.4+ में --hairpin-mode लिए डिफ़ॉल्ट मान प्रतीत होता है। मैं अभी भी इस मुद्दे को देख रहा हूं, इसलिए मुझे पूरा यकीन नहीं है कि यह पूरा समाधान है।

मैं kubenet नेटवर्क प्लगइन (जो --configure-cbr0 को बदलने के लिए सेट है) का उपयोग करने के बाद फिर से समस्या को पुन: उत्पन्न करने में सक्षम नहीं हूं। मैं अपने भविष्य की अनिश्चितता के कारण flannel-overlay विकल्प से बच रहा हूं (ऐसा लगता है कि यह --configure-cbr0 से जुड़ा हुआ है)।

अपने डोकर डेमॉन का उपयोग करता है docker0 पुल, की स्थापना --hairpin-mode=promiscuous-bridge के रूप में kubelet अन-मौजूदा पुल कॉन्फ़िगर करने की कोशिश करेंगे कोई असर नहीं होगा cbr0 ।

CoreOS के लिए, कुबेरनेट्स व्यवहार को प्रतिबिंबित करने के लिए मेरा समाधान लेकिन फिर भी फलालैन का उपयोग करना:

• ब्रिज docker0 इंटरफ़ेस को विशिष्ट मोड में कॉन्फ़िगर करने के लिए docker.service के लिए एक सिस्टमड ड्रॉप-इन जोड़ें। (निश्चित रूप से ऐसा करने के लिए एक और अधिक सुंदर इच्छा है?):

- 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 --hairpin-mode=none

आप जांच सकते हैं कि आपके इंटरफेस के लिए हेयरपिन सक्षम है या नहीं
brctl showstp docker0
या
for f in /sys/devices/virtual/net/*/brport/hairpin_mode; do cat $f; done

मुझे लगता है कि मेरे सहयोगी ने हाल ही में इसे ठीक किया है http://www.spinics.net/lists/netdev/msg393441.html , हमने अपने वातावरण में इस समस्या का सामना किया और फिर हमें यह समस्या मिली, इस फिक्स के साथ, हमें कभी भी इस समस्या का सामना नहीं करना पड़ा अधिक। जिस किसी को भी इस समस्या का सामना करना पड़ा है, क्या आप इस पैच को आजमा सकते हैं और देख सकते हैं कि क्या यह फिर से होता है। और हमारे विश्लेषण से, यह ipv6 से संबंधित है, इसलिए आप docker डेमॉन शुरू करते समय --ipv6=false साथ docker के ipv6 को अक्षम करने का भी प्रयास कर सकते हैं

@ coolljt0725 शायद मैं गलत हूं, लेकिन ipv6

@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

डॉकर/कुबेरनेट्स पर इन परिवर्तनों का इस संबंध में क्या प्रभाव पड़ता है कि ओ/एस कंटेनरों के इंटरफेस को कैसे संभालता है?
मुझे इस बात पर जोर देना चाहिए कि यह गलत ओ/एस व्यवहार के साथ एक मुद्दा है, डॉकर या कुबेरनेट्स नहीं, क्योंकि हम (और इस धागे में कुछ अन्य लोग) डॉकर या कुबेरनेट्स नहीं चला रहे हैं, लेकिन फिर भी एलएक्ससी को रोकते समय वही परिस्थितियों का सामना करना पड़ता है। एक के बाद एक काफी तेजी से कंटेनर।

@rdelangh आप सही हैं। हालाँकि, यह समस्या डॉकर प्रोजेक्ट में व्यवहार को ट्रैक करने के लिए बनाई गई थी क्योंकि यह डॉकर से संबंधित है। इस थ्रेड में OS समस्या, K8s समस्या और CoreOS समस्या के रूप में इसे ट्रैक करने वाले अन्य मुद्दों का उल्लेख किया गया है। यदि आपको एलएक्ससी या कुछ और में समस्या मिली है, तो अत्यधिक अनुशंसा करते हैं कि आप वहां एक धागा शुरू करें और इस मुद्दे के बारे में जागरूकता बढ़ाने के लिए यहां लिंक करें।

जब इस त्रुटि के लिए डॉकर गूगल का उपयोग करने वाले लोग यहां उतरेंगे। इसलिए, यह समझ में आता है कि हम यहां इस मुद्दे पर वर्कअराउंड पोस्ट करते हैं ताकि जब तक अंतर्निहित समस्याएं ठीक न हो जाएं, लोग आगे बढ़ सकें।

डॉकर/कुबेरनेट्स पर इन परिवर्तनों का इस संबंध में क्या प्रभाव पड़ता है कि ओ/एस कंटेनरों के इंटरफेस को कैसे संभालता है?

1. मेरी पोस्ट में डॉकटर परिवर्तन कुबेरनेट्स को डॉकटर से पूछताछ करने और यह सुनिश्चित करने की अनुमति देता है कि समस्या होने पर प्लेटफॉर्म स्वस्थ है।
2. hairpin-mode परिवर्तन अनिवार्य रूप से K8s को docker0 ब्रिज का उपयोग करने के लिए कहता है, और इसलिए "कर्नेल लैंड" नेटवर्किंग और "हेयरपिन वेथ" का उपयोग करने का प्रयास नहीं करेगा, जहां से डॉकर में समस्या शुरू होती है। निष्पादन पथ।

K8s और Docker का उपयोग करके इस समस्या के लिए इसका समाधान।

Coolljt0725 सहकर्मियों के पैच को स्थिर करने के लिए कतारबद्ध किया गया है, इसलिए उम्मीद है कि इसे जल्द ही डिस्ट्रो में वापस भेज दिया जाएगा। (डेविड मिलर की पोस्ट: http://www.spinics.net/lists/netdev/msg393688.html)

सुनिश्चित नहीं है कि वह प्रतिबद्धता कहां है और अगर हमें इसे उबंटू, आरएच, आदि को ट्रैक और बैकपोर्ट करने में मदद करने के लिए भेजना चाहिए?

मुझे लगता है कि किसी बिंदु पर यहां दिखाने जा रहा हूं:
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 और सह (और इस धागे में सभी को) के लिए धन्यवाद। चूंकि कई लोग कुछ समय के लिए ipv6 पैच के साथ कर्नेल को अपडेट करने में असमर्थ होंगे, (हर कोई, वर्तमान में) मैंने इस थ्रेड से कई सुझावों को आजमाने के बाद इस बग को खत्म करने में कामयाबी हासिल की है। मैं उन चीजों पर अनुवर्ती कार्रवाई के लिए एक पूर्ण पोस्ट बनाना चाहता हूं जो काम करती हैं और काम नहीं करती हैं ताकि किसी और को उस परेशानी को न देखना पड़े जो मैंने देखी थी।

TL; DR ipv6 को linux boot params में अक्षम करें, रीबूट करें। कोरोस पर इसका मतलब है कि /usr/share/oem/grub.cfg में सामग्री है: set linux_append="ipv6.disable=1" और फिर एक रिबूट। एक अधिक सामान्य उद्देश्य सुझाव जो सेंटोस/उबंटू/डेबियन/$लिनक्स पर काम करना चाहिए, यहां पाया जा सकता

• कोशिश की 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 हेयरपिन मोड सेट करता है और वास्तव में काम करने की उम्मीद नहीं थी। साथ संयोजन के रूप में इस मैं कुछ उम्मीद थी, लेकिन इस मुद्दे पर, या तो (promisc मोड में docker0 की स्थापना) का समाधान नहीं किया। यहां --userland-proxy=false को ठीक करने का उल्लेख है और यह जल्द ही अपस्ट्रीम हो सकता है और एक और शॉट के लायक हो सकता है, प्रदर्शन के लिए इस मुद्दे में नोट किए गए बग की परवाह किए बिना इसे बंद करना अच्छा होगा लेकिन दुर्भाग्य से यह अभी तक एक और है इस समय बग।

• यहां दस्तावेज के रूप में sysctl सेटिंग्स के माध्यम से ipv6 को अक्षम करने का प्रयास किया गया यहां दस्तावेज के रूप में अक्षम करने का प्रयास किया गया है और यह ipv6 को अक्षम करने के लिए पर्याप्त नहीं था क्योंकि यह अभी भी चालू है, भले ही कोई इंटरफेस न हो उसका इस्तेमाल कर रहे हैं।
• जैसा कि यहां सुझाव दिया गया था, हमने इस समाधान को एक बार में केवल एक कंटेनर को हटाने का प्रयास किया, और हम अभी भी इस बग से मिले थे।

बहुत लंबा; पढ़ा था: अपनी ग्रब सेटिंग में ipv6 को अक्षम करें। रिबूट। फायदा।

CentOS 7.2 (3.10.0-327.28.3.el7.x86_64) और डॉकर 1.12.1 (w/o k8s) पर इस समस्या का सामना करना पड़ा। समस्या तब उत्पन्न होती है जब नेटवर्क ट्रैफिक बढ़ जाता है।
ipv6 अक्षम (पिछली सलाह के अनुसार) के साथ बूटिंग कर्नेल ने मदद नहीं की।
लेकिन docker0 इंटरफ़ेस को प्रॉमिस मोड में बदलने से यह ठीक हो गया है। @dadux द्वारा प्रयुक्त

@rdallman ग्रब के माध्यम से ipv6 को निष्क्रिय करना मेरे लिए ubuntu 16.06 (कर्नेल 4.4.0-36-जेनेरिक) या 14.04 (कर्नेल 3.13.0-95-जेनेरिक) में unregister_netdevice को नहीं रोकता है। --userland-proxy सेटिंग के बावजूद (या तो सही या गलत)।

ओह, यह अच्छा है कि पैच स्थिर के लिए कतारबद्ध था।
समस्या के लिए @aboch पिंग करें कि --ipv6=false कुछ भी नहीं करता है।

@trifle क्षमा करें :( जानकारी पोस्ट करने के लिए धन्यवाद, हम अभी तक कुछ दिनों के परीक्षण के बाद मुद्दों में भाग नहीं ले रहे हैं, लेकिन अगर हम किसी भी समस्या में भाग लेते हैं तो वापस अपडेट करेंगे। हम कोरोस 1122.2 (कर्नेल 4.7.0) चला रहे हैं। docker0 को promisc मोड पर सेट करना कुछ लोगों के लिए इसे ठीक करने लगता है (हमारे लिए कोई भाग्य नहीं)।

@RRAlex क्या आप जानते हैं कि क्या कोई बैकपोर्ट के संबंध में उबंटू कर्नेल टीम तक पहुंचा है? हमारे पास उबंटू क्लस्टर पर एक बड़ा उत्पादन डॉकर परिनियोजन है जो बग से प्रभावित है।

उबंटू कर्नेल टीम मेलिंग सूची:
https://lists.ubuntu.com/archives/kernel-team/2016-September/thread.html

स्थिर कर्नेल के लिए पैच:
https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d

उबंटू कर्नेल प्रतिबद्ध लॉग:
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

सुनिश्चित नहीं है कि यह मुख्य उबंटू कर्नेल ट्री में कब जा रहा है और न ही इस व्यक्ति का उबंटू से क्या संबंध है और अगर इससे मदद मिलेगी ...

मुझे उबंटू कर्नेल कमिट लॉग में उस थ्रेड से उल्लिखित कमिट भी नहीं मिल रहा है।

@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" समाधान का परीक्षण करने में कामयाब रहा। इसके अलावा - मैंने अपने डेबियन 8 पर 4.7.2 कर्नेल में अपग्रेड किया है।
कर्नेल के उन्नयन और कर्नेल मापदंडों में "ipv6.disable=1" को सक्षम करने के बाद, मैंने डॉक डेमॉन के लिए "--userland-proxy=false" ध्वज के बिना भी वास्तविक कार्यभार पर "वेटिंग फॉर लो" समस्या को पकड़ने में कामयाबी हासिल की है। अच्छी खबर यह है कि "--userland-proxy=false" निर्दिष्ट करने और "डॉकर-तनाव" के साथ समस्या को पुन: उत्पन्न करने का प्रयास करने के बाद - मैं अब ऐसा नहीं कर सकता। लेकिन मुझे पूरा यकीन है कि यह "--userland-proxy" मान की परवाह किए बिना फिर से उठेगा।
तो मैं जो देखता हूं - आईपीवी 6 निश्चित रूप से इस मुद्दे में शामिल है, क्योंकि अब डॉकर-तनाव अब इस मुद्दे को पकड़ने में सक्षम नहीं है। बुरी खबर यह है कि यह मुद्दा वास्तव में अभी भी है (यानी: यह केवल आंशिक रूप से तय किया गया है)।

बाद में और अधिक परीक्षण करने के लिए नवीनतम 4.8rc7 संकलित करेंगे।

@twang2218 @cooljt0725

हम्म .. इसलिए मैंने सिर्फ उबंटू xenial 4.4.0-36 कर्नेल को ddstreet के ppa से बैकपोर्ट किए गए पैच के साथ

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

दुर्भाग्य से, यह मेरे लिए समस्या का समाधान नहीं लगता है। ध्यान दें कि मैं "ipv6.disable=1" के साथ भी चल रहा हूं। क्या हम एक ही परिणाम के साथ कई असंबंधित कारणों को देख रहे हैं? इस सूत्र में कई टिप्पणियाँ ऐसा सुझाव देती हैं।

मैं इनके बारे में बहुत अधिक नहीं जानता, लेकिन मुझे पता है कि हमारे पास पहले भी इस तरह के कीड़े थे। जैसा कि मैं इसे समझता हूं, किसी भी नेटवर्क डिवाइस के संदर्भ मायने रखता है जब नेटवर्क नेमस्पेस को साफ किया जा रहा है, तो "लो के मुक्त होने की प्रतीक्षा" का मतलब है कि कुछ नेट डिवाइस के लिए संदर्भ गणना रिसाव है लेकिन जरूरी नहीं कि लो के लिए सीधे। यह इन्हें ट्रैक करने के लिए एक भालू बनाता है, क्योंकि जब तक आप जानते हैं कि एक रिसाव था, आप नहीं जानते कि यह किस डिवाइस से जुड़ा था।

मैंने सभी टिप्पणियों के माध्यम से वापस नहीं पढ़ा है, लेकिन अगर कोई मुझे उबंटू पर एक विश्वसनीय पुनरुत्पादक दे सकता है तो मैं इसे देख लूंगा और देख सकता हूं कि मैं कुछ भी समझ सकता हूं या नहीं।

@sforshee इसे पुन: पेश करना हमेशा आसान नहीं होता है, लेकिन एक पैच बनाया गया था (जो कम से कम यहां रिपोर्ट किए गए कुछ मामलों को ठीक करता है); http://www.spinics.net/lists/netdev/msg393441.html। इसे अपस्ट्रीम https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d स्वीकार किया गया

@thaJeztah आह, मुझे वह प्रश्न दिखाई दे रहा है जो आप मुझे अभी निर्देशित कर रहे थे।

तो पैच अपस्ट्रीम 4.4 स्थिर कतार में है, 16.04 के लिए इसे अगले कर्नेल एसआरयू (जो पहले से ही प्रगति पर है) में शामिल होने की संभावना है, लेकिन उसके बाद एक, अब से लगभग 5-6 सप्ताह। यदि 14.04 में भी इसकी आवश्यकता है तो कृपया मुझे बताएं ताकि इसे बैकपोर्ट किया जा सके।

@sforshee मूल रूप से पहले (उस पैच से पहले) जिसे कर्नेल में ipv6 (आमतौर पर डिफ़ॉल्ट रूप से सक्षम) को सक्षम करके पुन: उत्पन्न किया जा सकता है, "--userland-proxy=false" को docker daemon फ़्लैग में जोड़कर और फिर docker-stress -c 100 चलाकर, के लिए उदाहरण (डॉकर-तनाव यहाँ से है: https://github.com/crosbymichael/docker-stress)

@fxposter धन्यवाद। अगर उस के लिए कोई फिक्स है, हालांकि मुझे वास्तव में चिंता करने की ज़रूरत है कि उबंटू कर्नेल में उस फिक्स को प्राप्त करना है। मैं अन्य लीक को देखने में भी मदद कर सकता हूं जो उस पैच द्वारा तय नहीं की गई हैं।

मुझे भी यह समस्या हो रही है। मैं एडब्ल्यूएस से एक RancherOS बॉक्स के अंदर डोकर चला रहा हूँ। दरअसल, रैंचर क्लस्टर (3 होस्ट) को सेट करने और उसमें एक छोटा एप्लिकेशन चलाने के बाद यह बेतरतीब ढंग से होता है।

वही... फेडोरा 24, बेतरतीब ढंग से होता है, सप्ताह के लिए ठीक हो सकता है, मुझे हर 10 घंटे में एक मिलता है
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

CentOS 7 पर चलने वाले कर्नेल 3.10.0-327.36.1.el7 और docker 1.12.1 . पर अनुभव

डॉकर 1.12.1 पर रहते हुए कर्नेल 3.10.0-327.18.2.el7 में डाउनग्रेड करना, ऐसा लगता है कि सिस्टम को स्थिर कर दिया गया है।

मैं यह भी देख रहा हूँ:
डॉकर संस्करण 1.11.2
उबंटू 16.04.1 4.4.0-38-जेनेरिक

ipv6 अक्षम (ग्रब)

कर्नेल 4.8.0-आरसी7 के साथ सर्वर पर --userland-proxy=false (एसआईसी!) के बिना बस यह समस्या थी, जिसमें आईपीवी 6 पैच (एसआईसी !!) शामिल है। तो शायद यह कुछ समस्याओं को ठीक करता है, लेकिन निश्चित रूप से उन सभी को नहीं।

क्या किसी को पता है कि इसे कैसे डिबग किया जा सकता है?

हमने पाया कि यह केवल हमारे सेटअप पर होता है जब हम (लगभग) फ्री मेमोरी से बाहर हो जाते हैं।

@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 अभी भी निश्चित रूप से टूटा हुआ है ...
मैंने इसका उल्लेख यहां उबंटू के लिए किया है, लेकिन शायद किसी के पास एक बेहतर विचार है:
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1403152

मैं यह भी देख रहा हूं, डॉकर संस्करण 1.11.2, बिल्ड b9f10c9/1.11.2, 64 बिट अमेज़ॅन लिनक्स 2016.03 v2.1.6।

अभी भी हुआ। docker 1.12.2, अर्म्बियन लिनक्स कर्नेल 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
एपीआई संस्करण: 1.23
गो संस्करण: go1.5.3
गिट प्रतिबद्ध: b9f10c9/1.11.2
बनाया:
ओएस/आर्क: linux/amd64

सर्वर:
संस्करण: 1.11.2
एपीआई संस्करण: 1.23
गो संस्करण: go1.5.3
गिट प्रतिबद्ध: b9f10c9/1.11.2
बनाया:
ओएस/आर्क: linux/amd64
```

Centos7 कर्नेल 4.4.30 फिर से~~~~

कोरओएस 1185.3.0, 4.7.3-कोरोस-आर 2, डॉकर 1.11.2
केवल 10..20 डेबियन चलाने के साथ पुनरुत्पादित जेसी कंटेनर।

कोरओएस स्थिर अभी भी हिट है। 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

टीएल; डीआर - इस पोस्ट में कोई समाधान नहीं है, लेकिन मैं अब तक जो कुछ भी पीछा कर चुका हूं और मेरे वर्तमान कामकाजी सिद्धांतों की सूची है। मैं उम्मीद कर रहा हूं कि अन्य लोग जो इसका पीछा कर रहे हैं, उन्हें यहां कुछ जानकारी उपयोगी मिल सकती है क्योंकि हम इस चीज़ को नीचे चलाते हैं।

@koendc 4.7.5 में पेश किए गए पैच को पोस्ट करने के लिए धन्यवाद। मैंने 4e1b3aa898ea93ec10e48c06f0e511de37c35b2d (अपस्ट्रीम 751eb6b6042a596b0080967c1a529a9fe98dac1d) पैच को अपने 4.5.5 सेटअप [1] में वापस पोर्ट किया और अपंजीकृत_नेटडिवाइस समस्या को आसानी से पुन: उत्पन्न करने में सक्षम था। यह संभव है कि 4.7.x कर्नेल में अन्य परिवर्तन इस समस्या को हल करने के लिए प्रदान किए गए पैच के साथ काम करें, लेकिन मैंने अभी तक इसकी पुष्टि नहीं की है, इसलिए हमें अभी तक पूरी उम्मीद नहीं खोनी चाहिए। मैं ४.५.५ के साथ परीक्षण कर रहा हूं क्योंकि मेरे पास समस्या का कारण बनने के लिए एक प्रतिलिपि प्रस्तुत करने योग्य परीक्षण मामला है, [2] में चर्चा की गई है।

अन्य चीजें जिन्हें मैंने परीक्षण के आधार पर पुष्टि की है:

• 4.2 किसी भी बाद के कर्नेल की तुलना में बहुत अधिक स्थिर है
• 4.5.x तुच्छ रूप से प्रतिलिपि प्रस्तुत करने योग्य है। नई गुठली में से मैंने बड़े पैमाने पर परीक्षण किया है (४.८.२ और ४.८.६), समस्या अभी भी मौजूद है, हालांकि पहली घटना का समय ६० से ४८ घंटे तक कहीं भी था
• समस्या नेटवर्क ट्रैफ़िक और कंटेनर के मूल संसाधन (पुण्य सीपीयू) क्षमता के अनुपात दोनों से संबंधित प्रतीत होती है। जैसा कि दूसरों ने कहा है, यह एक लाल हेरिंग हो सकता है यदि यह वास्तव में एक दौड़ की स्थिति है

अगला कदम:

• एक कर्नेल को उपयुक्त प्रिंटक स्टेटमेंट के साथ एक ऐसा मामला खोजने और खोजने के लिए इंस्ट्रूमेंट करें जहां आवंटित संसाधन मुक्त नहीं होते हैं
• उपरोक्त पैच के साथ/बिना 4.7.5 या बाद के कर्नेल का परीक्षण करके देखें कि क्या समस्या होती है
• एक दुर्घटना से ठीक पहले, मैंने IPv6: eth0: IPv6 duplicate address <blah> detected त्रुटियों का एक बहुत ही रोचक सेट देखा। एक और लाल हेरिंग हो सकता है, लेकिन मैं यह देखने के लिए अक्षम करने के लिए आईपीवी 6 अक्षम करने का प्रयास करना चाहता हूं कि कोई सहसंबंध है या नहीं

[१] मेरा पूरा सेटअप एक GCE गुण है जो 4.5.5 आधार पर थोड़ा अनुकूलित डेबियन कर्नेल चला रहा है। Docker version 1.8.3, build f4bf5c7 ऊपर चल रहा है
[२] टेस्ट केस की जानकारी: मेरे पास २० समानांतर प्रक्रियाएं हैं, प्रत्येक एक डॉक कंटेनर के अंदर एक Node.js हैलो वर्ल्ड सर्वर शुरू करता है। hello world लौटने के बजाय, Node.js सर्वर 1 एमबी यादृच्छिक पाठ देता है। मूल प्रक्रिया एक तंग लूप में है जो कंटेनर शुरू करती है, 1 एमबी डेटा पुनर्प्राप्त करने के लिए कर्ल करती है, और कंटेनर को रोकती है। इस सेटअप का उपयोग करके, मैं लगातार 4-90 के दशक में समस्या को पुन: उत्पन्न कर सकता हूं। भौतिक होस्ट पर या वर्चुअलबॉक्स के अंदर इसी सेटअप का उपयोग करने से समस्या का पुनरुत्पादन नहीं होता है, अलग-अलग मदों के बावजूद जो जीसीई बॉक्स पर प्रजनन के लिए औसत समय को बदलते हैं। वेरिएबल जिनके साथ मैं खेल रहा हूं: समवर्ती परीक्षण प्रक्रियाओं की संख्या, स्थानांतरित पेलोड का आकार, और कर्ल कॉल की मात्रा। पहले दो चर निश्चित रूप से सहसंबद्ध हैं, हालांकि मुझे लगता है कि यह गुण के लिए उचित संतृप्ति बिंदु खोजने के लिए चर को समायोजित करने की संभावना है।

मुझे भी यह त्रुटि हो रही है।

मैं कंटेनर को तैनात करने के बाद इसे 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

अतिरिक्त पर्यावरण विवरण (एडब्ल्यूएस, वर्चुअलबॉक्स, भौतिक, आदि):

आभासी मशीन:
फेडोरा 24
Ext3 पर ओवरलेFS2

डोकर के लिए आवंटित अलग ड्राइव 24 gigs का उपयोग करते हैं।
राम के 16 gigs.

डॉकर पीएस

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

डॉकर वॉल्यूम एलएस

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

*डीएफ-एच *

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

रुचि रखने वालों में से किसी के लिए, हम (ट्रैविस सीआई) उबंटू 14.04 पर v4.8.7 अपग्रेड कर रहे हैं। हमारे लोड परीक्षणों ने यहां वर्णित त्रुटि की कोई घटना नहीं दिखाई। पहले, हम Ubuntu 14.04 पर linux-image-generic-lts-xenial चला रहे थे। मैं निकट भविष्य में अधिक विवरणों का वर्णन करते हुए एक ब्लॉग पोस्ट प्रकाशित करने की योजना बना रहा हूं।

अद्यतन : मुझे यह उल्लेख करना चाहिए था कि हम इस डॉकटर स्टैक को चला रहे हैं:

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

अद्यतन : हम _still_ उबंटू ट्रस्टी + कर्नेल 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

मैं पिछले ४ दिनों से बिना रुके ४.८.८ का परीक्षण एक तंग पाश में कर रहा हूं (देखें [2] परीक्षण मामले के लिए मेरी पिछली टिप्पणी से)। अब तक सब ठीक है।

तथ्यों

• पैच 751eb6b6 इस समस्या की घटना को काफी कम करता है, लेकिन इसे पूरी तरह समाप्त नहीं करता है।

अनुमान:
@meatballhat ने बताया कि 4.8.7 चलाते समय उनके उत्पादन सर्वर ने समस्या का अनुभव किया। यह हमें दो संभावनाओं के साथ छोड़ देता है:

• मेरा परीक्षण परीक्षण मामला दोषपूर्ण है (अधिक संभावना है)
• 4.8.8 ने एक सुधार पेश किया। 4.8.8 चैंज को देखते हुए, 5086cadf और 6fff1319 दोनों ने नेटदेव मुद्दों का उल्लेख किया है जिन्हें हल किया गया था। यहां कोई भी स्पष्ट रूप से समस्या का उल्लेख नहीं करता है, लेकिन दोनों ही संदेहास्पद होने के काफी करीब हैं।

क्या हम कुछ लोगों को यह देखने के लिए ४.८.८ का प्रयास करने के लिए कह सकते हैं कि क्या वे इस समस्या को पुन: उत्पन्न करने में सक्षम हैं?

@reshen मैं हमें 4.8.8 पर अपडेट कर दूंगा और वापस रिपोर्ट करूंगा: +1: आपके शोध के लिए बहुत बहुत धन्यवाद!

@reshen उत्कृष्ट शोध। अब तक मैं Xubuntu 16.04 पर Linux 4.8.8 का उपयोग करके समस्या को पुन: उत्पन्न करने में सक्षम नहीं हूं।

मैं उबंटू मेनलाइन कर्नेल बिल्ड का उपयोग कर रहा हूं। मेरे पास एक अच्छी तरह से परिभाषित परीक्षण मामला नहीं है, लेकिन मैं काम करने वाले डॉकटर कंटेनरों के सेट को शुरू करने और रोकने से पहले लगातार समस्या को पुन: उत्पन्न कर सकता हूं।

लिनक्स 4.8.8 का परीक्षण करने के लिए मेरे लिए सबसे आसान था aufs से overlay2 में स्टोरेज ड्राइवर के रूप में स्विच करना क्योंकि मेनलाइन कर्नेल बिल्ड में aufs शामिल नहीं था। मुझे नहीं लगता कि परीक्षण को प्रभावित करेगा, लेकिन यह ध्यान दिया जाना चाहिए।

अतीत में मैंने डैन स्ट्रीटमैन द्वारा बैकपोर्ट किए गए 751eb6b6 के साथ लिनक्स 4.4.4 का परीक्षण किया है, इससे मेरे लिए समस्या कम नहीं हुई। यह देखना दिलचस्प होगा कि क्या आपके द्वारा नोट किए गए दो पैच (5086cadf और 6fff1319) को बैकपोर्ट करने से 4.4.8 के समान परिणाम मिल सकते हैं।

4.4.0-47 के साथ Ubuntu 16.04 अभी भी प्रभावित था... 4.4.0-49 अभी कोशिश कर रहा है, बाद में रिपोर्ट करेगा।

संपादित करें: २०१६-११-२८:-४९ उस लॉग लाइन को dmesg में दिखा रहा है।

फेडोरा 25 (कर्नेल 4.8.8) और डॉकर 1.12.3 . पर इसका अनुभव किया

FYI करें: हम एक ही प्रोडक्शन होस्ट पर Docker v1.12.3 के साथ Linux 4.8.8 चला रहे हैं। अपटाइम वर्तमान में 5.5 दिनों का है और मशीन स्थिर बनी हुई है।

हम कभी-कभी syslog में मुट्ठी भर unregister_netdevice: waiting for lo to become free. Usage count = 1 संदेश देखते हैं, लेकिन पहले के विपरीत, कर्नेल क्रैश नहीं होता है और संदेश चला जाता है। मुझे संदेह है कि कर्नेल या डॉकर में पेश किए गए अन्य परिवर्तनों में से एक इस स्थिति का पता लगाता है और अब इससे उबरता है। हमारे लिए, यह अब इस संदेश को परेशान करता है लेकिन अब एक महत्वपूर्ण बग नहीं है।

मुझे उम्मीद है कि कुछ अन्य लोग अपने उत्पादन बेड़े पर उपरोक्त की पुष्टि कर सकते हैं।

@gtirloni - क्या आप स्पष्ट कर सकते हैं कि आपकी 4.8.8/1.12.3 मशीन क्रैश हो गई है या यदि आपने अभी संदेश देखा है?

अग्रिम रूप से, उन सभी को धन्यवाद जो इस चीज़ को त्रिभुजित करने के लिए उपयोगी जानकारी को पुन: प्रस्तुत करने/प्रदान करने पर काम कर रहे हैं।

हम docker शुरू करने के बाद veth इंटरफ़ेस (docker0) के समकक्ष को हटा देते हैं और जब हम ansible का उपयोग करके होस्ट का प्रावधान करते हैं, तो docker को फिर से शुरू करते हैं। समस्या तब से नहीं हुई।

मुझे रास्पबेरी पीआई 2 पर डोकर के साथ रास्पियन चलाने पर भी यही त्रुटि मिल रही है।

कर्नेल जानकारी
Linux rpi2 4.4.32-v7+ #924 SMP Tue Nov 15 18:11:28 GMT 2016 armv7l GNU/Linux

डॉकर जानकारी

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

यह एक कंटेनर बनाने के बाद हुआ, जिसे लगभग ~ 50Mb डाउनलोड किए गए प्रोग्राम इंस्टॉल करने की आवश्यकता थी।

केवल एक रिबूट मुझे मशीन को फिर से उपयोग करने देगा

मैं वास्तव में इसे ईसीएस क्लस्टर में अमेज़ॅन लिनक्स पर देख रहा हूं - संदेश कभी-कभी फेंकता है लेकिन यह लॉक नहीं होता है, जैसे कि अब रेशेन देख रहा है। डॉकर 1.11.2। संस्करण के रूप में "4.4.14-24.50.amzn1.x86_64" रिपोर्ट का नाम बदलें।

@reshen मैं इस सप्ताह के अंत में अपने लैपटॉप पर 4.8.8 का निर्माण करने जा रहा हूं और देखें कि क्या है
इसे मेरे लिए ठीक करता है!
मैं

गुरु, 1 दिसंबर, 2016 को सुबह 10:29 बजे, अर्नेस्ट म्यूएलर सूचनाएं @github.com
लिखा था:

मैं वास्तव में इसे ईसीएस क्लस्टर में अमेज़ॅन लिनक्स पर देख रहा हूं - संदेश
कभी-कभी फेंकता है लेकिन यह लॉक नहीं होता है, जैसे रेशेन अब देख रहा है।
डॉकर 1.11.2। संस्करण के रूप में "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 का उपयोग करके एक कुबेरनेट्स वर्कर नोड पर कोरओएस स्टेबल 1185.3.0 चलाने में सक्षम था।

रनिंग docker_stress_linux_amd64 -k 3s -c 5 --containers 1000 : कंटेनर बनाने/हटाने वाले 5 समवर्ती कार्यकर्ता, कंटेनरों का अधिकतम जीवनकाल = 3s, एक m4 पर 1000 कंटेनर तक बनाते हैं। AWS पर बड़ा उदाहरण डॉकर डेमॉन को लगभग तीन मिनट के बाद अनुत्तरदायी छोड़ देगा।

कोरओएस बीटा 1235.1.0 में अपग्रेड किया गया और मैं पुन: पेश करने में सक्षम नहीं हूं (दोनों अनुत्तरदायी या कर्नेल लॉग में unregister_netdevice संदेश)। जबकि 5 समवर्ती docker_stress कार्यकर्ता कुछ मिनटों के बाद CoreOS स्थिर को मार देंगे, मैं CoreOS बीटा का उपयोग करके परीक्षण पूरा होने तक 10 और 15 समवर्ती श्रमिकों के साथ चलने में सक्षम था।

CoreOS "चैनल" में रिलीज़ होता है इसलिए कर्नेल को अलगाव में अपग्रेड करना संभव नहीं है। यहाँ स्थिर और बीटा के बीच प्रमुख अंतर हैं:

कोरओएस स्थिर 1185.3.0

कर्नेल: 4.7.3

डोकर: 1.11.2

कोरओएस बीटा 1235.1.0

कर्नेल: 4.8.6

डोकर: 1.12.3

Amazon Elastic Beanstalk 4.4.23-31.54.amzn1.x86_64 पर चल रहे इस मुद्दे को देखकर

CoreOS स्टेबल 1185.5.0, डॉकर 1.12.2 . पर जस्ट हैपन
रिबूट के बाद सब कुछ ठीक है

अद्यतन करें: डॉकर v1.12.3, और लिनक्स कर्नेल v4.8.6 के साथ कोरओएस बीटा 1235.1.0 चलाने वाले होस्ट पर लटका हुआ डॉकर डेमॉन मुद्दा फिर से आ गया है। मैं

१.१२.४ और १.१३, सिद्धांत रूप में, इस कर्नेल समस्या के हिट होने पर स्थिर नहीं होना चाहिए।
डॉकर डेमॉन में फ्रीज होने का कारण यह है कि कंटेनर ऑब्जेक्ट पर लॉक रखते हुए डेमॉन कर्नेल से वापस नेटलिंक संदेश की प्रतीक्षा कर रहा है (जो कभी नहीं आएगा)।

1.12.4 और 1.13 ने इस नेटलिंक अनुरोध पर कम से कम कंटेनर लॉक जारी करने के लिए एक टाइमआउट सेट किया है।
यह __not__ समस्या को ठीक करता है, लेकिन कम से कम (उम्मीद है) पूरे डेमॉन को फ्रीज नहीं करता है।
आप संभवत: नए कंटेनरों को स्पिन करने में सक्षम नहीं होंगे, और इसी तरह संभवत: उन्हें फाड़ने में सक्षम नहीं होंगे क्योंकि ऐसा लगता है कि इस मुद्दे के हिट होने के बाद नेटलिंक स्टॉल के साथ सभी इंटरैक्शन।

@ cpuguy83 FWIW, कोई भी चल रहे कंटेनर बिना किसी समस्या के AFAIK के चलते चलते रहते हैं जब डेमॉन लटका दिया जाता है। वास्तव में, यह कंटेनरों की शुरुआत और रोक है जो ध्यान देने योग्य है (विशेषकर कुबेरनेट्स पर चल रहा है, जैसा कि हम हैं)।

यह इस मुद्दे को ठीक नहीं करता है, लेकिन कम से कम (उम्मीद है) पूरे डेमॉन को फ्रीज नहीं करता है।

पूरे डेमॉन के जमे हुए होने का एक फायदा यह है कि इसका पता लगाना आसान है। कुबेरनेट्स नोड को बेदखल कर सकता है, शायद स्वचालित रूप से रीबूट भी हो सकता है। क्या डेमॉन बस चलते रहना चाहिए, क्या यह अभी भी आसानी से संभव होगा कि कर्नेल समस्या बिल्कुल भी दिखाई दे?

@seanknox मैं आपको पैच किए गए डॉकर (CoreOS Docker 1.12.3 + अपस्ट्रीम 1.12.4-rc1 पैच) के साथ एक कस्टम CoreOS 1248.1.0 AMI प्रदान कर सकता हूं। इसने मेरे CoreOS/K8s क्लस्टर पर हर दो घंटे में हैंगअप तय किया है। बस मुझे Deis Slack पर अपने AWS खाता-आईडी के साथ पिंग करें।

हमारे CoreOS क्लस्टर पर इस मुद्दे के साथ हमें बहुत दर्द हुआ। क्या कोई बता सकता है कि यह आखिरकार कब तय होगा? हम इस पल के बारे में सपने देखते हैं जब हम रात को सो सकते हैं।

@DenisIzmaylov यदि आप --userland-proxy=false सेट नहीं करते हैं, तो आम तौर पर आपको इस मुद्दे में भाग नहीं लेना चाहिए।

लेकिन अन्यथा यह कर्नेल में एक बग है, संभवतः कई कर्नेल बग, कि कुछ कहते हैं 4.8 में हल हो गए हैं और अन्य नहीं कहते हैं। कुछ के लिए, ipv6 को अक्षम करना इसे ठीक करने लगता है, अन्य नहीं (इसलिए यह शायद कई मुद्दे हैं ... या कम से कम कई कारण हैं)।

मैंने इस मुद्दे को --userland-proxy=false साथ और बिना उच्च लोड सिस्टम पर घंटों के भीतर देखा है

पुष्टि की कि हम अभी भी कर्नेल 4.8.12 पर unregister_netdevice त्रुटियाँ देख रहे हैं। ट्रिगर होने में लगभग 5 दिन लगते हैं। ऐसा लगता है कि सिस्टम का केवल एक रीबूट समस्या से ठीक हो रहा है। डॉकर को रोकना अनिश्चित काल के लिए लटका हुआ प्रतीत होता है।

अभी तक कर्नेल बूट के लिए अक्षम ipv6 चाल का प्रयास नहीं किया है।

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

अगर कोई इसे 1.12.5 के साथ आज़मा सकता है, तो यह बहुत अच्छा होगा, जो कि अटके हुए नेटलिंक अनुरोध पर टाइमआउट होना चाहिए , न कि केवल डॉकर को लटकाने के।

@ cpuguy83 हालांकि, उस राज्य में सिस्टम अभी भी अनुपयोगी है :)

@ एलके 4 डी 4 ओह, पूरी तरह से, बस उन टाइमआउट देखना चाहते हैं;)

इस समस्या को Cent OS 7 पर प्राप्त करना:

कर्नेल: unregister_netdevice : लो के मुक्त होने की प्रतीक्षा कर रहा है। उपयोग गिनती = 1

लिनक्स फू 3.10.0-514.2.2.el7.x86_64 #1 एसएमपी मंगल 6 दिसंबर 23:06:41 यूटीसी 2016 x86_64 x86_64 x86_64 जीएनयू/लिनक्स

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

यह मेरे सीआई बिल्ड को प्रभावित कर रहा है जो डॉकर कंटेनरों के अंदर चल रहे हैं और अचानक मरते हुए दिखाई देते हैं जिसके दौरान यह कंसोल संदेश दिखाई देता है। क्या कोई फिक्स या वर्कअराउंड है? धन्यवाद!

@ cpuguy83 जब यह त्रुटि होती है तो डॉकर मेरे लिए

तो मैं बिना किसी समस्या के थोड़ी देर (11 महीने?) के लिए सेंटोस 7 मशीन पर डॉकर चला रहा हूं। आज मैंने tcp लिसनिंग डेमॉन को आज़माने का फैसला किया ( tcp लिसनिंग एड्रेस को /etc/sysconfig/docker में जोड़ा ) और बस यह त्रुटि मिली।

कर्नेल: unregister_netdevice : लो के मुक्त होने की प्रतीक्षा कर रहा है। उपयोग गिनती = 1

इसलिए मेरी उपयोग संख्या 3 नहीं है।

कंटेनर: 4
चल रहा है: 3
रुका हुआ: 0
रुक गया: 1
छवियां: 67
सर्वर संस्करण: 1.10.3
स्टोरेज ड्राइवर: btrfs
बिल्ड संस्करण: Btrfs v4.4.1
पुस्तकालय संस्करण: 101
निष्पादन चालक: देशी-0.2
लॉगिंग ड्राइवर: json-file
प्लगइन्स:
वॉल्यूम: स्थानीय
नेटवर्क: ब्रिज नल होस्ट
कर्नेल संस्करण: 3.10.0-514.2.2.el7.x86_64
ऑपरेटिंग सिस्टम: CentOS Linux 7 (कोर)
ओएस टाइप: लिनक्स
आर्किटेक्चर: x86_64
डॉकर हुक की संख्या: 2
सीपीयू: 24
कुल मेमोरी: 39.12 जीआईबी
नाम: लक्ष्य-वेब-एनकोडर
आईडी: QK5Q: JCMA: ATGR : ND6W: YOT4: PZ7G: DBV5: PR26: YZQL: INRU : HAUC: CQ6B
रजिस्ट्रियां: docker.io (सुरक्षित)

3.10.0-514.2.2.el7.x86_64 #1 एसएमपी मंगल 6 दिसंबर 23:06:41 यूटीसी 2016 x86_64 x86_64 x86_64 जीएनयू/लिनक्स

ग्राहक:
संस्करण: 1.10.3
एपीआई संस्करण: 1.22
पैकेज संस्करण: docker-common-1.10.3-59.el7.centos.x86_64
गो संस्करण: go1.6.3
गिट प्रतिबद्ध: 3999ccb-असमर्थित
निर्मित: गुरु दिसंबर 15 17:24:43 2016
ओएस/आर्क: linux/amd64

सर्वर:
संस्करण: 1.10.3
एपीआई संस्करण: 1.22
पैकेज संस्करण: docker-common-1.10.3-59.el7.centos.x86_64
गो संस्करण: go1.6.3
गिट प्रतिबद्ध: 3999ccb-असमर्थित
निर्मित: गुरु दिसंबर 15 17:24:43 2016
ओएस/आर्क: linux/amd64

मैं @aamerik की पुष्टि कर सकता हूं। मैं उसी कर्नेल संस्करण पर एक ही समस्या देख रहा हूं। आज से इस मुद्दे को देखते हुए, सिस्टम में हाल ही में कोई बड़ा बदलाव नहीं किया गया है।

मैंने अपनी CentOS 7 मशीन पर वही kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1 संदेश देखा जो जेनकिंस की डॉकटर छवि चला रहा था। मैं जिस CentOS 7 मशीन का उपयोग कर रहा था, वह लगभग 20 दिसंबर 2016 तक सभी नवीनतम CentOS 7 पैच के साथ चालू थी।

चूंकि यहां सबसे हालिया संदर्भ सेंटोस आधारित प्रतीत होते हैं, इसलिए मैं अपने निष्पादन होस्ट को उबंटू या डेबियन मशीन में बदल दूंगा।

मैं उस CentOS 7 मशीन पर Docker version 1.12.5, build 7392c3b चला रहा हूं। डॉकर लटका नहीं था, लेकिन जब वह संदेश दिखाई दिया तो जेनकिन्स प्रक्रिया जो मैं डॉकर में चला रहा था, मारा गया था।

डॉकर के लिए बहुत बहुत धन्यवाद! मैं इसे हर समय उपयोग करता हूं, और इस पर आपके काम के लिए बहुत आभारी हूं!

लिनक्स 4.8.15 मशीन पर डॉकर के साथ जेनकिंस का उपयोग करते समय मुझे वही समस्या दिखाई दे रही है।

क्या किसी ने रैंचर ओएस के लिए एक फिक्स प्रक्रिया तक पहुंच गया है?

AFAICT, यह Linux कर्नेल के नेटवर्क नेमस्पेस सबसिस्टम में एक लॉकिंग समस्या है। इस बग की रिपोर्ट एक साल पहले हो चुकी है, जिसका कोई जवाब नहीं है: https://bugzilla.kernel.org/show_bug.cgi?id=97811 इस पर कुछ काम हुआ है (यहां देखें: http://www.spinics. net/lists/netdev/msg351337.html) लेकिन ऐसा लगता है कि यह पूरी तरह ठीक नहीं है।

मैंने बिना किसी प्रतिक्रिया के सीधे नेटवर्क सबसिस्टम अनुरक्षक को पिंग करने का प्रयास किया है। एफडब्ल्यूआईडब्ल्यू, मैं इस मुद्दे को कुछ ही मिनटों में पुन: पेश कर सकता हूं।

इस मुद्दे के समाधान के लिए Smyte $5000 USD का भुगतान करेगा। ऐसा लगता है कि मुझे कर्नेल पर काम करने वाले किसी व्यक्ति से बात करने की ज़रूरत है?

@petehunt मेरा मानना ​​​​है कि इस त्रुटि के कारण खेलने में कई मुद्दे हैं।

जैसा कि @reshen ने सुझाव दिया था, हमने कर्नेल 4.8.8 को तैनात किया था और जब अपटाइम थोड़ा बेहतर लगता है तब भी हम उत्पादन में इस मुद्दे को देखना जारी रखते हैं।

मेसोस्फीयर को बूटस्ट्रैप नोड से परिनियोजित करने का प्रयास कर रहा है। लागू सभी अद्यतनों के साथ सभी नोड्स 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

अनाम-आर:

3.10.0-514.2.2.el7.x86_64

डोकर -वी:

Docker version 1.11.2, build b9f10c9

मैं पुष्टि कर सकता हूं कि रिबूट संदेशों को मौन कर देता है, लेकिन जिस मिनट मैं मेसोस्फीयर को फिर से तैनात करता हूं, संदेश हर बार शुरू होते हैं। मेसोस्फीयर काफी बड़ी तैनाती है। हो सकता है कि त्रुटि को पुन: उत्पन्न करने का प्रयास करने वाले त्रुटि को पुन: उत्पन्न करने के लिए इंस्टॉलर का उपयोग कर सकें। पहले स्क्रिप्ट स्विच ( --genconf जो कि पहला चरण है) का उपयोग करने के बाद त्रुटि दिखाई देने में कुछ मिनट लगते हैं।

हमने यह भी मारा है। हालांकि, हमारे मामले में त्रुटि संदेशों में डिवाइस का उल्लेख है eth0 नहीं lo । मेरी त्रुटि यह है:

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

मैं उल्लेख की तरह है कि त्रुटियों संभालने कर रहा हूँ eth0 के बजाय lo इस मुद्दे के रूप में ही मूल कारण है। यदि नहीं, तो हमें eth0 त्रुटियों के संबंध में एक नया टिकट खोलना चाहिए।

• ओएस: सेंटोस लिनक्स रिलीज 7.3.1611
• कर्नेल: 3.10.0-514.2.2.el7.x86_64
• डॉकर संस्करण 1.12.6, बिल्ड 78d1802
• डॉकर विकल्पों के साथ शुरू हुआ: 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"
• IPsec का उपयोग करते हुए Rancher 1.2.2 (https://bugzilla.kernel.org/show_bug.cgi?id=97811 से इसका उल्लेख करते हुए और अन्य बग IPsec का उल्लेख करते हैं)

हमने यह भी मारा है।
त्रुटि: unregister_netdevice: लो के मुक्त होने की प्रतीक्षा में।
ओएस: सेंटोस लिनक्स रिलीज 7.3.1611 (कोर)
कर्नेल 3.10.0-514.2.2.el7.x86_64
डॉकर संस्करण: 1.13.0-cs1-rc1
डॉकर विकल्प:
{
"अक्षम-विरासत-रजिस्ट्री": सच,
"आईसीसी": सच,
"असुरक्षित-रजिस्ट्रियां":[],
"आईपीवी6": झूठा,
"iptables": सच,
"स्टोरेज-ड्राइवर": "डिवाइसमैपर",
"भंडारण-विकल्प": [
"dm.thinpooldev=/dev/mapper/docker_vg-thinpool",
"dm.use_deferred_removal=true",
"dm.use_deferred_deletion=true"
],
"यूजरलैंड-प्रॉक्सी": झूठा
}

मेरे पास यह दो CentOS सिस्टम पर है, उनमें से कम से कम एक पर नवीनतम अपडेट।

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

अरे, RHEL या CentOS पर इस समस्या से प्रभावित सभी लोगों के लिए, मैंने मेनलाइन कर्नेल (torvalds/linux@751eb6b6042a596b0080967c1a529a9fe98dac1d) से प्रतिबद्धता को बैकपोर्ट किया है जो IPV6 IFP रेफ़काउंट में दौड़ की स्थिति को उद्यम वितरण में उपयोग किए गए 3.10.x कर्नेल में ठीक करता है। यह इस मुद्दे को ठीक

आप वर्किंग पैच के साथ बग रिपोर्ट यहां पा सकते हैं:
यदि आप इसका परीक्षण करने में रुचि रखते हैं और आपके पास RHEL 7 या CentOS 7 सिस्टम है, तो मैंने पैच के साथ नवीनतम CentOS 7.3 3.10.0-514.6.1.el7.x86_64 कर्नेल पहले ही संकलित कर लिया है। CentOS बगट्रैकर थ्रेड का उत्तर दें और मैं आपको बिल्ड का लिंक भेज सकता हूं।

नोट: एक और समस्या हो सकती है जो रीकाउंट लीक का कारण बन सकती है लेकिन इससे आप में से कई लोगों के लिए त्रुटि संदेश ठीक हो जाना चाहिए।

@stefanlasiewski @henryiii @jsoler

मैं इस फिक्स को जोड़ने के लिए एक बिल्ड की कोशिश करूँगा: http://www.spinics.net/lists/netdev/msg351337.html बाद में आज रात।

@iamthebot क्या इसका मतलब यह है कि यदि कोई IPv6 को अक्षम करता है तो उसे समस्या को भी ठीक करना चाहिए, यहां तक ​​कि बिना पैच के भी जिसे आपने अभी बैकपोर्ट किया है?

@redbaron केवल अगर वह मुद्दा है जिसे आप मार रहे हैं। मुझे सच में लगता है कि यहां कई कर्नेल मुद्दे हिट हो रहे हैं।

@redbaron शायद। #20569 ऐसा प्रतीत होता है कि IPV6 को पूरी तरह से अक्षम करना कठिन है।

तो यह स्पष्ट करने के लिए कि इस संदेश को उत्पन्न करने वाले हुड के नीचे क्या हो रहा है, कर्नेल एक चल रही गिनती को बनाए रखता है कि क्या कोई डिवाइस किसी नामस्थान से हटाने से पहले उपयोग में है, इसे अपंजीकृत करना, इसे निष्क्रिय करना, आदि। अगर किसी कारण से कोई लटक रहा है किसी डिवाइस के संदर्भ में, तो आप उस त्रुटि संदेश को देखने जा रहे हैं क्योंकि जब कुछ और इसका उपयोग कर रहा है तो इसे अपंजीकृत नहीं किया जा सकता है।

मैंने अब तक जो सुधार देखे हैं:

1. उस समस्या को ठीक करें जहां IPV6 पता आवंटन के साथ कोई समस्या विफल हो जाती है (जैसे; एक डुप्लिकेट पता) लेकिन हम बाहर निकलने से पहले डिवाइस का संदर्भ जारी नहीं करते हैं।
2. उस समस्या को ठीक करें जहां किसी डिवाइस के नामस्थान को स्थानांतरित करने से डिवाइस के संदर्भों को नए नेटवर्क नामस्थान में सही ढंग से स्थानांतरित कर दिया जाएगा लेकिन पुराने नामस्थान पर एक लटकता हुआ संदर्भ छोड़ दिया जाएगा। डॉकर भारी रूप से नेटवर्क नेमस्पेस का उपयोग करता है (जैसा कि एक अन्य कर्नेल फिक्स द्वारा प्रमाणित है कि मेरे पास 7.3 जेड-स्ट्रीम के लिए रेड हैट बैकपोर्ट था और 7.4 में शामिल करने के लिए स्लेट किया गया है जो डॉकर के मैकवलन ड्राइवर को बॉन्ड या टीम डिवाइस पर काम करने से रोकता है)

मुझे लगता है कि नेमस्पेस स्विच करते समय अभी भी एक और दौड़ की स्थिति है (ऐसा लगता है कि यह नए कंटेनरों का एक गुच्छा बनाने के बाद होता है) लेकिन मुझे इसे खोजने और पैच लिखने के लिए इस मुद्दे को विश्वसनीय रूप से दोहराने की आवश्यकता होगी।

क्या किसी के पास इसे लगातार पुन: पेश करने के लिए न्यूनतम प्रक्रिया है? हमारे सिस्टम पर बेतरतीब ढंग से होने लगा।

@iamthebot यह वास्तव में सीधा नहीं है, लेकिन मुझे लगता है कि हम आपको एक परीक्षण वातावरण प्रदान कर सकते हैं जो इसे विश्वसनीय रूप से पुन: पेश कर सकता है। मुझे ईमेल करें ([email protected]) और हम विवरण की व्यवस्था कर सकते हैं।

अभी भी डॉकर संस्करण 1.12.6 पर भारी भार के तहत इसका अनुभव करें, 4.4.39-34.54.amzn1.x86_64 एडब्ल्यूएस लिनक्स एएमआई पर 7392c3b/1.12.6 का निर्माण करें।

मेरे पास 9 डॉकटर होस्ट हैं जो लगभग समान हैं, और उनमें से कुछ पर केवल इसका अनुभव करते हैं। यह संयोग हो सकता है, लेकिन एक चीज जो मैंने देखी है, वह यह है कि मुझे केवल यह समस्या तब लगती है जब कंटेनर चलाते हैं जो संभाल नहीं पाते हैं SIGINT । जब मैं इन कंटेनरों को docker stop हूं, तो यह 10s के लिए लटका रहता है और फिर कंटेनर को अनजाने में मारता है।

समस्या के स्वयं को प्रस्तुत होने में कई दिन लगते हैं, और docker stop चलाने के तुरंत बाद नहीं, बल्कि बेतरतीब ढंग से दिखाई देने लगता है। यह ज्यादातर किस्सा है, लेकिन शायद यह किसी की मदद करेगा।

मैंने अपने सभी डॉकटर नोड्स को कर्नेल 3.10.0-514.6.1.el7.x86_64 पर CentOS 7.3 पर अपग्रेड किया है जैसा कि
26 जनवरी 13:52:49 XXX कर्नेल: unregister_netdevice: लो के मुक्त होने की प्रतीक्षा में। उपयोग गिनती = 1
syslogd @XXX से जनवरी 26 13:52:49 पर संदेश ...
कर्नेल: unregister_netdevice : लो के मुक्त होने की प्रतीक्षा कर रहा है। उपयोग गिनती = 1

@jsoler बस स्पष्ट होने के लिए, क्या आपने कर्नेल बनाने से पहले बग ट्रैकर थ्रेड में पैच करें (पैच को पुराने कर्नेल पर काम करना चाहिए)।

मुझे एक ईमेल ([email protected]) शूट करें और मैं आपको एक पूर्व-निर्मित कर्नेल का लिंक भेज सकता हूं। @vitherman दुर्भाग्य से मेरे पास इस पर गौर करने के लिए बहुत समय नहीं है (ऐसा लगता है कि इस बग को पकड़ने के लिए कुछ इंस्ट्रूमेंटेशन को संकलित करने की आवश्यकता होगी) लेकिन मैंने इस मुद्दे को Red Hat समर्थन के साथ बढ़ा दिया है, इसलिए उनकी कर्नेल टीम एक ले लेगी देखना।

@ckeeney मैं इस व्यवहार की पुष्टि कर सकता हूं। हमारे पास एक डॉकराइज़्ड नोड एप्लिकेशन है जो बंद होने पर होस्ट सिस्टम पर उक्त त्रुटि का कारण बना। Node.js एप्लिकेशन के भीतर एक फ़ंक्शन को लागू करने के बाद, जो एप्लिकेशन को इनायत से बंद करने के लिए SIGINT और SIGTERM को पकड़ता है, त्रुटि फिर से नहीं हुई है।
किस तरह समझ में आता है; नोड एप्लिकेशन वर्चुअल इंटरफ़ेस का उपयोग करता है जो डॉकर बनाता है। जब नोड ठीक से बंद नहीं होता है, तो डिवाइस हैंग हो जाता है और होस्ट सिस्टम इसे अपंजीकृत नहीं कर सकता, भले ही डॉकर कंटेनर को सफलतापूर्वक रोक दिया गया हो।

यहां एक उदाहरण कोड स्निपेट है:

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

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

    process.exit();
}

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

@ माइकल-नीमैंड क्या एक अलग संकेत है जो एक साफ शटडाउन के लिए डिफ़ॉल्ट रूप से नोड द्वारा ठीक से नियंत्रित किया जाता है? (आप छवि में STOPSIGNAL निर्दिष्ट कर सकते हैं, या docker run पर --stop-signal ध्वज के माध्यम से निर्दिष्ट कर सकते हैं।

@thaJeztah समस्या की अच्छी व्याख्या और समाधान के लिए, देखें nodejs/node-v0.x-archive#9131#issuecomment-72900581

@ckeeney मुझे इसके बारे में पता है (यानी, PID1 रूप में चलने वाली प्रक्रियाएं SIGINT या SIGTERM संभाल नहीं सकती हैं )। उस कारण से, मैं सोच रहा था कि क्या एक अलग स्टॉप-सिग्नल निर्दिष्ट करने से PID1 रूप में चलने पर भी क्लीन-शटडाउन हो जाएगा।

वैकल्पिक रूप से, डॉकर 1.13 एक --init विकल्प जोड़ता है (पुल अनुरोध: https://github.com/docker/docker/pull/26061), जो कंटेनर में एक init सम्मिलित करता है; उस स्थिति में, नोड PID1 रूप में नहीं चल रहा है, जो उन मामलों में मदद कर सकता है जहां आप एप्लिकेशन को अपडेट नहीं कर सकते हैं।

@iamthebot मैंने आपके पैच एकीकृत के साथ कर्नेल संस्करण 3.10.0-514.el7 बनाया है लेकिन मुझे वही त्रुटि मिलती है। ठीक है, मुझे यकीन नहीं है कि मैंने सेंटो के कर्नेल पैकेज को अच्छी तरह से बनाया है। क्या आप इसका परीक्षण करने के लिए मुझे अपना कर्नेल पैकेज साझा कर सकते हैं?

धन्यवाद

मैं लगभग एक साल से इस बग से निपट रहा/रही हूं। मैं PXE बूट के साथ CoreOS का उपयोग करता हूं, मैंने pxeboot config में ipv6 को अक्षम कर दिया है और तब से मैंने इस मुद्दे को एक बार भी नहीं देखा है।

वैसे मेरे पर्यावरण ने इस sysctl कॉन्फ़िगरेशन के साथ ipv6 को अक्षम कर दिया है
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
लेकिन मुझे अभी भी त्रुटि मिलती है
कर्नेल: unregister_netdevice : लो के मुक्त होने की प्रतीक्षा कर रहा है। उपयोग गिनती = 1

@jsoler ठीक है, मैं भी वह कर रहा था, फिर भी हुआ। केवल एक बार जब मैंने इसे पीएक्सई स्तर पर किया तो क्या यह बंद हो गया।

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 की प्रतीक्षा" के बारे में बात हो रही है

कुछ ने उपरोक्त में से किसी के बीच बारी-बारी से लॉग को नोट किया है और अन्य में केवल उपरोक्त में से एक है।

उबंटू पर भी इसी तरह का एक बग

@etlweather मेरा मानना ​​​​है कि वास्तव में एकमात्र आम भाजक है, ठीक है, एक नेट डिवाइस कर्नेल द्वारा अपंजीकृत होने में सक्षम नहीं है जैसा कि त्रुटि संदेश कहता है। हालांकि कारण _why_ कुछ अलग हैं। हमारे लिए यह निश्चित रूप से उल्लिखित डॉकटर / नोड मुद्दा (वीथ) था। एथ के लिए, लो कारण सबसे अधिक संभावना है कि कुछ पूरी तरह से अलग हो।

अभी भी 4.9.0-0.bpo.1-amd64 के साथ डेबियन जेसी पर docker 1.13.1 के साथ होता है। क्या कोई कर्नेल-ओएस संयोजन है जो स्थिर है?

यह पूरी तरह से डॉकटर मुद्दा नहीं हो सकता है - मैं इसे Proxmox सर्वर पर प्राप्त कर रहा हूं जहां मैं केवल वेनिला एलएक्ससी कंटेनर (उबंटू 16.04) चला रहा हूं।

@ डार्थ-वीचर यह एक कर्नेल मुद्दा है

@thaJeztah धन्यवाद सहमत हुए। कोशिश करने जा रहा था और आज रात 4.9.9 मेनलाइन से स्थापित करें और देखें कि क्या यह मामलों को ठीक करता है।

मैं इसे कर्नेल 4.9.9-040909 के साथ डेबियन पर डॉकर 1.13.1 चला रहा हूं।

हाँ Proxmox पर कर्नेल को नवीनतम 4.9.9 में अपग्रेड करने से त्रुटि का समाधान नहीं हुआ। अजीब है क्योंकि यह बिना किसी समस्या के एक साल बाद दिखाई दिया।

पिछले विवरण में कुछ और हो सकता है कि इसे एनएफएस या सीआईएफएस शेयरों से जोड़ा जा रहा है।

मेरे आईफोन से भेजा गया

14 फरवरी 2017 को 07:47 बजे, अल्फोंसो डा सिल्वा नोटिफिकेशन @github.com ने लिखा:

मैं इसे कर्नेल 4.9.9-040909 के साथ डेबियन पर डॉकर 1.13.1 चला रहा हूं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

मेरे पास इस बारे में Redhat के साथ एक बगजिला टिकट खुला है।

कुछ विकास:
Red Hat ने IPV6 रीकाउंट लीक पैच को QA पर मेनलाइन से डाल दिया, ऐसा लगता है कि वे RHEL 7.4 के लिए कतारबद्ध हैं और उन्हें 7.3 पर बैकपोर्ट किया जा सकता है। जल्द ही CentOS-plus पर भी होना चाहिए। नोट: यह पैच केवल कुछ मामलों में समस्याओं को ठीक करता है। यदि आपके पास 4.x कर्नेल है तो यह एक महत्वपूर्ण मुद्दा है क्योंकि वे पहले से ही वहां हैं।

यह निश्चित रूप से कर्नेल में एक दौड़ की स्थिति है जो मैं बता सकता हूं, जो इसे खोजने में वास्तव में परेशान करता है। मैंने वर्तमान मेनलाइन कर्नेल का एक स्नैपशॉट लिया है और IPV6 सबसिस्टम से शुरू होने वाली विभिन्न कॉल्स को इंस्ट्रूमेंट करने पर काम कर रहा हूं। समस्या अब निश्चित रूप से प्रतिलिपि प्रस्तुत करने योग्य है: ऐसा लगता है कि आपको केवल कंटेनरों का एक गुच्छा बनाना है, उनमें से एक टन नेटवर्क ट्रैफ़िक को धक्का देना है, कंटेनरों के अंदर प्रोग्राम को क्रैश करना है, और उन्हें हटा देना है। इसे बार-बार करने से मिनटों में समस्या शुरू हो जाती है, भौतिक 4-कोर वर्कस्टेशन पर सबसे ऊपर।

दुर्भाग्य से, मेरे पास इस पर काम करने के लिए बहुत समय नहीं है: अगर यहां कर्नेल डेवलपर्स हैं जो आवश्यक टुकड़ों को साधने में सहयोग करने के लिए तैयार हैं, तो मुझे लगता है कि हम एक कांटा स्थापित कर सकते हैं और इसे चरण दर चरण शिकार पर काम शुरू कर सकते हैं। .

@iamthebot , क्या यह qemu-kvm सेटअप पर प्रतिलिपि प्रस्तुत करने योग्य है?

@iamthebot मैंने अलग-अलग कर्नेल के साथ इसे कई बार docker-stress -c 100 साथ userland-proxy को गलत पर सेट करने से यह ट्रिगर होगा, लेकिन मुझे कोई भाग्य नहीं था।

यदि आपके पास अधिक विश्वसनीय रेप्रो है (भले ही इसे ट्रिगर करने में लंबा समय लगे) तो मैं कोशिश कर सकता हूं और देख सकता हूं

हम अपने उत्पादन और मंचन के वातावरण में समान कठिनाई का सामना करते हैं। हम जल्द ही डॉकर 1.13 और लिनक्स कर्नेल 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

डॉकर डेमॉन लॉग

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

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

@ r-BenDoan यदि आप एक कंटेनर को रोकने की कोशिश करते हैं, लेकिन यह SIGINT का जवाब नहीं देता है, तो docker 10 सेकंड प्रतीक्षा करेगा और फिर कंटेनर को अनजाने में मार देगा। जब तक मैंने सिग्नल हैंडलिंग नहीं जोड़ा, तब तक मुझे अपने नोडज कंटेनरों में उस व्यवहार का सामना करना पड़ा। यदि आप देखते हैं कि कंटेनर को रुकने में 10 सेकंड का समय लगता है, तो संभवतः यह संकेतों को संभाल नहीं रहा है और इस समस्या को ट्रिगर करने की अधिक संभावना है।

सुनिश्चित करें कि आपके कंटेनर इनायत से रुक सकते हैं।

जबकि मैं वह नहीं हूं जो इस मुद्दे को ठीक कर रहा है, लिनक्स कर्नेल देव में ज्यादा नहीं है, मुझे लगता है कि मैं यह कहने में सही हूं कि "मुझे भी" टिप्पणियां उतनी उपयोगी नहीं हैं। इससे मेरा मतलब है, "मुझे भी यह समस्या है, कर्नेल vx.x और डॉकर 1.x के साथ" कहने से चर्चा में कुछ भी नया नहीं आता है।

हालांकि, मैं सुझाव दूंगा कि "मैं भी" टिप्पणियां जो पर्यावरण और पुनरुत्पादन की विधि का अधिक वर्णन करती हैं, वे बहुत मूल्यवान होंगी।

सभी टिप्पणियों को पढ़ते समय, यह स्पष्ट है कि कुछ समस्याएं हैं - जैसा कि मैंने पहले पोस्ट किया था, कुछ vethXYZ के साथ, कुछ eth0 के साथ और अन्य lo0 के साथ। इससे पता चलता है कि वे विभिन्न समस्याओं के कारण हो सकते हैं। इसलिए त्रुटि और परिवेश के पूर्ण विवरण के बिना केवल "मैं भी" कहना लोगों को गुमराह कर सकता है।

साथ ही, पर्यावरण का वर्णन करते समय, कर्नेल और डॉकर संस्करण देना पर्याप्त नहीं है। प्रति सूत्र, ऐसा लगता है कि कुछ कारक हैं जैसे कि ipv6 सक्षम या नहीं। NodeJS SIGINT (या अन्य कंटेनरों, यहाँ NodeJS पर कोसने नहीं) का जवाब नहीं दे रहा है।

इसलिए यह वर्णन करना कि पर्यावरण पर कितना कार्यभार है, उपयोगी होगा। इसके अलावा, यह तब होता है जब एक कंटेनर को बंद किया जा रहा होता है, इसलिए मैं इस समस्या का सामना करने वाले लोगों को यह भी सुझाव दूंगा कि जब समस्या अपने बदसूरत सिर के पीछे होती है तो किस कंटेनर को रोका जा रहा है।

हालांकि ऐसा लगता है कि समस्या कर्नेल में दौड़ की स्थिति में है - ट्रिगर की पहचान करने से उन लोगों को बहुत मदद मिलेगी जो इस मुद्दे को ठीक करेंगे। और यह प्रभावित उपयोगकर्ताओं को एक तत्काल समाधान भी दे सकता है जैसे कि नोडजेएस एप्लिकेशन में सिग्नल हैंडलर को लागू करना (मैं खुद नहीं जानता कि यह इस मुद्दे को ट्रिगर होने से रोकता है, लेकिन ऐसा लगता है कि दूसरों की पिछली टिप्पणियों के अनुसार)।

FWIW कुबेरनेट्स ने इसे पूरी तरह से "हेयरपिन मोड" और
उस सुविधा का उपयोग पूरी तरह से बंद कर दिया है। हमने इसका अनुभव नहीं किया है
हजारों उत्पादन मशीनों में और व्यापक रूप से समस्या
अधिक परीक्षण चलता है, बदलने के बाद से।

जब तक यह तय न हो जाए, जहाज को छोड़ दें। एक अलग समाधान खोजें :(

बुधवार, १५ फरवरी, २०१७ को सुबह १०:०० बजे, ईटीएल नोटिफिकेशन @github.com ने लिखा:

जबकि मैं वह नहीं हूं जो इस मुद्दे को ठीक कर रहा है, लिनक्स में ज्यादा नहीं है
कर्नेल देव, मुझे लगता है कि मैं यह कहने में सही हूं कि "मैं भी" टिप्पणियां नहीं हैं
वह मददगार। इसके द्वारा मेरा मतलब है, "मुझे भी यह समस्या है, के साथ"
कर्नेल vx.x और Docker 1.x" चर्चा में कुछ भी नया नहीं लाते हैं।

हालांकि, मैं सुझाव दूंगा कि "मैं भी" टिप्पणियां जो अधिक वर्णन करती हैं
पर्यावरण और पुनरुत्पादन की विधि बहुत महत्वपूर्ण होगी।

सभी टिप्पणियों को पढ़ने पर यह स्पष्ट होता है कि कुछ समस्याएं हैं -
जैसा कि मैंने पहले पोस्ट किया था, कुछ vethXYZ के साथ, कुछ eth0 के साथ और अन्य lo0 के साथ।
इससे पता चलता है कि वे विभिन्न समस्याओं के कारण हो सकते हैं। बस ऐसे
त्रुटि और पर्यावरण के पूर्ण विवरण के बिना "मैं भी" कह रहा हो सकता है
लोगों को गुमराह करना।

साथ ही, पर्यावरण का वर्णन करते समय, कर्नेल और डॉकर दे रहे हैं
संस्करण पर्याप्त नहीं है। सूत्र के अनुसार, कुछ कारक प्रतीत होते हैं
जैसे कि ipv6 सक्षम है या नहीं। NodeJS SIGINT (या अन्य) का जवाब नहीं दे रहा है
कंटेनर, यहां NodeJS पर कोसने नहीं)।

इसलिए यह वर्णन करना कि पर्यावरण पर कितना कार्यभार है, उपयोगी होगा।
इसके अलावा, यह तब होता है जब एक कंटेनर बंद किया जा रहा है, इसलिए मैं करूंगा
इस समस्या का सामना करने वाले लोगों को भी सुझाव दें कि वे किस पर ध्यान दें
जब समस्या अपने बदसूरत सिर को पीछे कर देती है तो कंटेनर को रोका जा रहा है।

जबकि ऐसा लगता है कि समस्या कर्नेल में दौड़ की स्थिति है -
ट्रिगर की पहचान करने से उन लोगों को बहुत मदद मिलेगी जो ठीक करेंगे
समस्या। और यह प्रभावित उपयोगकर्ताओं को तत्काल समाधान भी दे सकता है
जैसे कि नोडजेएस एप्लिकेशन में सिग्नल हैंडलर लागू करना (मुझे नहीं पता
मुझे लगता है कि यह इस मुद्दे को ट्रिगर होने से रोकता है, लेकिन ऐसा लगता है कि
दूसरों की पूर्व टिप्पणियाँ)।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/docker/docker/issues/5618#issuecomment-280087293 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AFVgVFmu1SiStZcLKtKuk1W-tjn6wOXlks5rcz0hgaJpZM4B4L4Z
.

हां, हम gke पर जा रहे हैं और अब इस मुद्दे को नहीं देख रहे हैं (इसलिए हमसे कोई और बग बाउंटी नहीं :))

बस फिर से त्रुटि हुई। मैं एक नोड.जेएस एप्लिकेशन को ठीक करने की कोशिश कर रहा था जो सॉकेट का उपयोग करता है और इसलिए एप्लिकेशन को अक्सर बढ़ाया जाता है। Node.js ऐप https://github.com/deployd/deployd के शीर्ष पर बनाया गया था

संपादित करें फिर से हुआ! एक ही नोड.जेएस ऐप पर काम करना। पिछले 3 या 4 दिनों में मैंने सीधे उस नोड.जेएस एप्लिकेशन पर काम नहीं किया है और ऐसा कभी नहीं हुआ।

EDIT2 NodeJS अनुप्रयोग के लिए संकेत हैंडलर जोड़ने की कोशिश करेंगे। आइए देखें कि क्या इससे मदद मिलती है ....

ईसी को एक नया उदाहरण प्रकाशित करने के लिए डॉकर-पीई का उपयोग करने के बाद, मैं अभी इस त्रुटि में भाग गया। हालांकि, मैं ctrl+C के साथ बाहर निकलने में सक्षम था, और तब से इसे नहीं देखा है (अब जबकि अधिकांश छवियां कैश से अधिक तेज़ी से निर्माण कर रही हैं)

```{"स्थिति":"धक्का","प्रगति विवरण":{},"id":"c0962ea0b9bc"}
{"स्थिति":"चरण: डाइजेस्ट: sha256:f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8 आकार: 5737"}
{"progressDetail":{},"aux":{"Tag":"stage","Digest":"sha256:f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8", "Size":5737}}

डॉकर छवि सफलतापूर्वक प्रकाशित हुई

16 फरवरी 19:49:16 पर
कर्नेल: [१६११०८१.९७६०७९] unregister_netdevice: लो के मुक्त होने की प्रतीक्षा में। उपयोग गिनती = 1

16 फरवरी 19:49:27 पर syslogd@ip-172-31-31-68 से संदेश ...
कर्नेल: [१६११०९२.२२००६७] unregister_netdevice: लो के मुक्त होने की प्रतीक्षा में। उपयोग गिनती = 1

[1]+ रुक गया ./image-publish.py
[ root@ip-172-31-xx-xx छवि-प्रकाशन]# ^सी
[ रूट@ip-172-31-xx-xx छवि-प्रकाशित करें]#

@thockin क्या --hairpin-mode=none ?

=कोई भी कंटेनर को तोड़ता नहीं है जो स्वयं को NAT'ed वापस प्राप्त करता है। हम प्रयोग करते हैं
विशिष्ट-पुल डिफ़ॉल्ट रूप से।

गुरु, १६ फरवरी, २०१७ को शाम ७:२६ बजे, कनात बेकt अधिसूचनाएँ @github.com
लिखा था:

@thockin https://github.com/thockin यह सेटिंग है --hairpin-mode=none
क्यूबलेट पर?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/docker/docker/issues/5618#issuecomment-280539673 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AFVgVLNwAH6NWVaIKhJfS147O9w_rtJEks5rdRN8gaJpZM4B4L4Z
.

@thockin कौन से कंटेनर सेवा

यह मेरे विचार से कहीं अधिक सामान्य हो गया है, और जब हमने इसे तोड़ा, बहुत सारे
लोगों की शिकायत की।

17 फरवरी, 2017 को 12:38 पूर्वाह्न पर, "मैक्सिम इवानोव" नोटिफिकेशन @github.com ने लिखा:

@thockin https://github.com/thockin कौन से कंटेनर चाहते हैं
सर्विस क्लस्टरआईपी के माध्यम से स्वयं को एक्सेस करें?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/docker/docker/issues/5618#issuecomment-280588366 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AFVgVLn3uBvUW-dQ72qst5_eYiFUtfSVks5rdVyIgaJpZM4B4L4Z
.

मुझे लगता है कि मुझे पता है कि कुछ डॉक किए गए नोडज ऐप इस समस्या का कारण क्यों बन सकते हैं। नोड डिफ़ॉल्ट रूप से कीप-अलाइव कनेक्शन का उपयोग करता है। जब server.close() का उपयोग किया जाता है, तो सर्वर नए कनेक्शन स्वीकार नहीं करता है। लेकिन वर्तमान सक्रिय कनेक्शन जैसे वेबसोकेट या HTTP कीप-अलाइव कनेक्शन अभी भी बनाए हुए हैं। जब डॉक किए गए ऐप को भी n तक बढ़ाया जाता है, तो इसका परिणाम waiting for lo to become free हो सकता है क्योंकि जब इसे समाप्त करने के लिए मजबूर किया जाता है तो नया मुक्त हो जाता है। जब डॉकटर इस ऐप को दूसरे नोड में पुनर्वितरित करता है या ऐप को छोटा किया जाता है तो डॉकर ऐप को एक संकेत भेजता है कि इसे बंद कर देना चाहिए। ऐप इस सिग्नल को सुनता है और रिएक्ट कर सकता है। जब कुछ सेकंड के बाद ऐप बंद नहीं होता है, तो डॉकर बिना किसी हिचकिचाहट के इसे समाप्त कर देता है। मैंने सिग्नल हैंडलर जोड़े और पाया कि server.close() करते समय सर्वर पूरी तरह से समाप्त नहीं हुआ है, लेकिन "केवल" नए कनेक्शन स्वीकार करना बंद कर देता है (देखें https://github.com/nodejs/node/issues/2642)। इसलिए हमें यह सुनिश्चित करने की आवश्यकता है कि वेबसोकेट या http कीप-अलाइव जैसे खुले कनेक्शन भी बंद हैं।

वेबसोकेट कैसे संभालें:
जब शटडाउन सिग्नल प्राप्त होता है, तो नोडज ऐप सभी वेबसोकेट closeSockets उत्सर्जित होता है। क्लाइंट इस closeSockets ईवेंट को सुनता है और sockets.disconnect() और sockets.connect() तुरंत बाद कॉल करता है। याद रखें कि server.close() को कॉल किया गया था, इसलिए यह इंस्टेंस नए अनुरोध स्वीकार नहीं करता है। जब इस dockerized ऐप के अन्य इंस्टेंसेस docker के अंदर लोडबैलेंसर चला रहे हैं, तो अंततः एक ऐसा इंस्टेंस चुनेंगे जो शटडाउन नहीं है और एक सफल कनेक्शन स्थापित हो गया है। जिस इंस्टेंस को शटडाउन करना चाहिए, उसमें खुले वेबसोकेट-कनेक्शन नहीं होंगे।

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-कलेक्टर स्क्रिप्ट से बनाए गए हैं।
किसी भी मदद के लिए बहुत सराहना की :)

कलेक्ट.ज़िप

मेरे पास समान मुद्दे हैं।
डॉकर संस्करण 1.13.1, निर्माण 092cba3
लिनक्स डेबियन 4.8.6-x86_64-linode78

लिनक्स बैकअप 4.6.0-040600-जेनेरिक #201606100558 एसएमपी शुक्र जून 10 10:01:15 यूटीसी 2016 x86_64 x86_64 x86_64 जीएनयू/लिनक्स
सर्वर संस्करण: 1.13.1

वही मुद्दा। मैं विशेषाधिकार प्राप्त कंटेनर में माउंट का उपयोग कर रहा हूं। 4-5 रन के बाद यह जम जाता है। इसके अलावा मेरे पास 16.04 के लिए नवीनतम मानक कर्नेल के साथ एक ही समस्या है

हर कोई, @etlweather हाजिर है। केवल "मैं भी" पोस्ट करें यदि आपके पास समस्या को पुन: प्रस्तुत करने का एक विश्वसनीय तरीका है। उस स्थिति में, अपनी प्रक्रिया का विवरण दें। एक डॉकटर और कर्नेल संस्करण पर्याप्त नहीं है और हमें इसके बारे में बहुत सारी सूचनाएं मिलती हैं। आपकी प्रजनन प्रक्रिया जितनी सरल होगी, उतना ही अच्छा होगा।

@rneugeba @redbaron दुर्भाग्य से मेरे पास वर्तमान "

हम इसे जीसीई में बहुत बार प्राप्त कर रहे हैं। डॉकर जम जाता है और मशीन रिबूट पर लटक जाती है।

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

कंटेनर एक गो एप्लिकेशन चला रहा है, और इसमें हेयरपिन नेट कॉन्फ़िगर किया गया है।

डोकर:

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

उबंटू 16.04 एलटीएस,

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 सक्षम करने का प्रयास किया और डॉकर थोड़ी देर बाद भी लटक गया। ऐसा प्रतीत होता है कि कुबेरनेट्स के पास @thockin ने ऊपर जो लिखा है, --hairpin-mode=promiscuous-bridge वास्तव में क्या करता है और इसे एक सादे जेन ubuntu 16.x docker install पर कैसे कॉन्फ़िगर किया जाए।

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

यह ध्यान देने योग्य है कि इस सिस्टम पर डॉकर स्थापित नहीं है और न ही कभी किया गया है। मुझे इस समस्या के निवारण के लिए समुदाय द्वारा आवश्यक कोई भी डेटा प्रदान करने में प्रसन्नता हो रही है, बस मुझे बताएं कि कौन से आदेश चलाना है।

मैं इसे सेंटोस 7.3 पर पुन: पेश करने में सक्षम हूं जो एक झुंड कार्यकर्ता नोड के रूप में चल रहा है जो एक माउंटेड एनएफएस वॉल्यूम मैप के साथ चल रहा है

अगर आप यहां आ रहे हैं

यहां जिस मुद्दे पर चर्चा की जा रही है वह एक कर्नेल बग है और इसे अभी तक ठीक नहीं किया गया है। ऐसे कई विकल्प हैं जो _some_ स्थितियों के लिए मदद कर सकते हैं, लेकिन सभी के लिए नहीं (यह उन मुद्दों का एक संयोजन है जो एक ही त्रुटि को ट्रिगर करते हैं)

"मेरे पास यह भी है" टिप्पणी न छोड़ें

"मेरे पास यह भी है" बग को हल करने में मदद नहीं करता है। केवल एक टिप्पणी छोड़ें यदि आपके पास ऐसी जानकारी है जो समस्या को हल करने में मदद कर सकती है (इस मामले में, कर्नेल अपस्ट्रीम को पैच प्रदान करना सबसे अच्छा कदम हो सकता है)।

यदि आप यह बताना चाहते यह समस्या है तो शीर्ष विवरण में "अंगूठे ऊपर" बटन का उपयोग करें:

यदि आप अपडेट के बारे में सूचित रहना चाहते हैं तो _सदस्यता बटन_ का उपयोग करें।

यहां प्रत्येक टिप्पणी ३००० से अधिक लोगों को एक ई-मेल/अधिसूचना भेजती है, मैं इस मुद्दे पर बातचीत को लॉक नहीं करना चाहता, क्योंकि यह अभी तक हल नहीं हुआ है, लेकिन अगर आप इसे अनदेखा करते हैं तो आपको मजबूर होना पड़ सकता है।

धन्यवाद!

यह सब ठीक है और अच्छा है लेकिन कौन से _बिल्कुल_ विकल्प हैं जो मदद करते हैं? यह समस्या हमें उत्पादन में समस्या पैदा कर रही है इसलिए मैं कर्नेल बग के आसपास काम करने के लिए आवश्यक सभी काम करना चाहता हूं।

यदि डॉकर के किसी व्यक्ति के पास कुबेरनेट्स वर्कअराउंड को आजमाने का समय है, तो कृपया
मुझे बताएं और हम आपको इसकी ओर इशारा कर सकते हैं। मैं परिवर्तन निकालने में असमर्थ हूँ
और उन्हें अभी डॉकर में पैच करें।

गुरु, मार्च 9, 2017 में 7:46 AM पर, मैथ्यू Newhook [email protected]
लिखा था:

यह सब ठीक है और अच्छा है लेकिन वास्तव में ऐसे कौन से विकल्प हैं जो मदद करते हैं?
यह समस्या हमें उत्पादन में समस्या पैदा कर रही है इसलिए मैं जो कुछ भी करना चाहता हूं
चारों ओर काम करें जो कर्नेल बग के आसपास काम करने के लिए आवश्यक हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/docker/docker/issues/5618#issuecomment-285388243 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AFVgVGdH5VX_oFWkImyo_TvlIuhmwMepks5rkB7MgaJpZM4B4L4Z
.

@thockin धन्यवाद। मैं कुबेरनेट्स में हेयरपिन-मोड वर्कअराउंड के साथ पीआर/मुद्दे का अनुसरण कर रहा था। लेकिन कई बार आगे-पीछे होने के दौरान, अगर वर्कअराउंड वास्तव में इस मुद्दे से छुटकारा पाता है, तो मैंने ट्रैक खो दिया?
(जैसा कि मैं समझता हूं कि विभिन्न परिदृश्य हैं जो कर्नेल में रेफ-गिनती असंगतता का कारण बनते हैं)।

यदि आप मुझे उस पीआर की ओर इंगित कर सकते हैं जो आपको लगता है कि K8s में समस्या को संबोधित करता है, तो मैं इसे कम से कम उपयोगकर्तालैंड-प्रॉक्सी को डिफ़ॉल्ट रूप से बंद करने के मामले में डॉकटर में पैच करने के लिए काम करूंगा। (और हम डॉकर-तनाव प्रजनन चरणों का उपयोग करके इसका परीक्षण कर सकते हैं)।

मुझे यकीन नहीं है कि मेरे पास एक पीआर है, लेकिन आप वर्तमान स्थिति को देख सकते हैं। शुरू
यहां:

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

शनिवार, 11 मार्च, 2017 को रात 10:49 बजे, मधु वेणुगोपाल सूचनाएं @github.com
लिखा था:

@thockin https://github.com/thockin धन्यवाद। मैं पीछा कर रहा था
कुबेरनेट्स में हेयरपिन-मोड वर्कअराउंड के साथ पीआर/मुद्दा। लेकिन इस दौरान
बहुत से लोग आगे और पीछे, अगर वर्कअराउंड वास्तव में इससे छुटकारा पाता है तो मैंने ट्रैक खो दिया है
मुद्दा ?
(जैसा कि मैं समझता हूं कि विभिन्न परिदृश्य हैं जो रेफ-गिनती का कारण बनते हैं
कर्नेल में असंगति)।

यदि आप मुझे उस पीआर की ओर इंगित कर सकते हैं जो आपको लगता है कि K8s में समस्या का समाधान करता है,
मैं कम से कम टर्निंग के मामले में इसे डॉकटर में पैच करने के लिए काम करूंगा
उपयोगकर्तालैंड-प्रॉक्सी डिफ़ॉल्ट रूप से बंद है। (और हम डॉकर-तनाव का उपयोग करके इसका परीक्षण कर सकते हैं
प्रजनन कदम)।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/docker/docker/issues/5618#issuecomment-285926217 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AFVgVIlGs_QccxS6YYQiLNybddDzB4yUks5rk5VogaJpZM4B4L4Z
.

हे सब, बस स्पष्ट होने के लिए, सभी "कुबेरनेट्स वर्कअराउंड" अंतर्निहित पुल पर विशिष्ट मोड को सक्षम करता है। आप iproute2 का उपयोग करके ip link set <bridgename> promisc on साथ एक ही चीज़ प्राप्त कर सकते हैं। यह बग में चलने की संभावना को कम करता है लेकिन इसे पूरी तरह समाप्त नहीं कर सकता है।

अब, सिद्धांत रूप में यह काम नहीं करना चाहिए ... लेकिन किसी कारण से विशिष्ट मोड डिवाइस को टियरडाउन को इतना धीमा कर देता है कि आपको रेफरी काउंटर को कम करने की दौड़ नहीं मिलती है। अगर वे इस धागे पर हैं तो शायद कुर्बेरनेट्स योगदानकर्ताओं में से एक यहां झंकार कर सकता है।

मैं अपने पर्यावरण-विशिष्ट रेप्रो का उपयोग करके वर्कअराउंड (FIX नहीं) कार्यों को सत्यापित कर सकता हूं। यदि आप IPVLAN या MACVLAN ड्राइवरों का उपयोग कर रहे हैं (हम उत्पादों में macvlan का उपयोग करते हैं) तो मैं वास्तव में यह सत्यापित नहीं कर सकता कि यह मदद करता है क्योंकि इस बग को उत्पन्न करने के लिए उन सेटअपों को प्राप्त करना बहुत मुश्किल लगता है। क्या कोई अन्य व्यक्ति रेपो के साथ वर्कअराउंड को सत्यापित करने का प्रयास कर सकता है?

हाय सब, मैंने कर्नेल मुद्दे को डीबग करने का प्रयास किया, "नेटदेव" मेलिंग सूची पर एक ईमेल श्रृंखला थी, इसलिए यहां कुछ निष्कर्ष पोस्ट करना चाहता था।

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() (1 से वृद्धि dst_entry संदर्भ गणना), और dst_release() (1 से dst_entry संदर्भ गणना में कमी) को लॉग किया, और वास्तव में dst_hold() कॉल अधिक हैं तो dst_release() .

यहाँ संलग्न लॉग हैं: kern.log.zip

सारांश:

• पकड़ने में आसानी के लिए lo इंटरफ़ेस का नाम बदलकर lodebug दिया गया
• dst_entry लिए संदर्भ संख्या 1 . से शुरू होती है
• अंत में dst_entry (जो लो के लिए संदर्भ धारण कर रहा है) के लिए संदर्भ संख्या 19 . है
• 258041 कुल dst_hold() कॉल हैं, और 258023 कुल dst_release() कॉल हैं
• 258041 dst_hold() कॉलों में, 88034 udp_sk_rx_dst_set() (जिसे बाद में dst_hold() ), 152536 inet_sk_rx_dst_set() , और 17471 __sk_add_backlog()
• 258023 dst_release() कॉल में, 240551 inet_sock_destruct() और 17472 refdst_drop()

udp_sk_rx_dst_set() और inet_sk_rx_dst_set() से अधिक कॉल हैं inet_sock_destruct() , इसलिए संदेह है कि कुछ सॉकेट "लिम्बो" स्थिति में हैं, और कुछ उन्हें नष्ट होने से रोक रहे हैं।

अपडेट करें:
टर्न आउट सॉकेट ( struct sock ) सही तरीके से बनाए और नष्ट किए जाते हैं, लेकिन कुछ TCP सॉकेट के लिए inet_sk_rx_dst_set() को एक ही dst पर कई बार कॉल किया जा रहा है, लेकिन केवल एक ही है संबंधित inet_sock_destruct() का संदर्भ जारी करने के लिए dst ।

यहाँ CentOS 7.3 वर्कअराउंड है जिसने इसे मेरे लिए तय किया है:

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

यहाँ वह पैच है जो इसे हल करता है:
https://bugs.centos.org/view.php?id=12711&nbn=1

अद्यतन: यह समस्या को स्थायी रूप से हल नहीं करने के लिए निकला। यह निम्नलिखित दीवार संदेश के साथ कई घंटे बाद फिर से दिखा:
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

@adrianotto - स्पष्ट करने के लिए: क्या CentOS कर्नेल पैच इसे हल करता है? बस जिज्ञासु अगर आपका मतलब है कि आपके वर्कअराउंड और संदर्भ कर्नेल पथ दोनों ने इसे स्थायी रूप से सफलतापूर्वक हल नहीं किया है?

@stayclassychicago @adrianotto वह पैच केवल दौड़ स्थितियों में से एक को संबोधित करता है जो कर्नेल में "उपयोग गणना" समस्या को ट्रिगर कर सकता है। यह पहले से ही 4.x कर्नेल में कुछ से मेरा बैकपोर्टेड फिक्स है। यह आपकी समस्याओं का समाधान कर सकता है इसलिए यह एक शॉट के लायक है।

@stayclassychicago इससे पहले कि मैंने 3.10.0-514.10.2.el7.centos.plus.x86_64 कर्नेल की कोशिश की, मुझे नियमित रूप से kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1 मिल रहा था, लगभग हर बार जब मैं कंटेनर से बाहर निकलता था तो मैं docker run --rm ... साथ एक कंटेनर चलाता था। कर्नेल अपग्रेड और रिबूट के बाद, यह कई घंटों के लिए पूरी तरह से बंद हो गया, और फिर वापस आ गया। अब आधा समय जब मैं कंटेनरों को हटाता हूं तो यह ठीक से काम करता है, जहां यह बहुत समय त्रुटि करता था। मैं निश्चित रूप से नहीं जानता कि क्या नया कर्नेल मदद कर रहा है, लेकिन यह चोट नहीं पहुंचाता है।

ऐसा लगता है कि मशीन पर LACP बॉन्डिंग इंटरफ़ेस होने पर पुन: पेश करना बहुत आसान है। हमारे पास एक 3 नोड झुंड क्लस्टर है, सभी 3 कॉन्फ़िगर किए गए LACP बॉन्डिंग इंटरफ़ेस के साथ हैं, और यह समस्या मूल रूप से हमें क्लस्टर के साथ काम करने की अनुमति नहीं देती है। हमें हर 15-20 मिनट में नोड्स को पुनरारंभ करना होगा।

पुष्टि - जैसे ही मैंने इंटरफेस से एलएसीपी बॉन्डिंग को हटा दिया (जिन्हें मुख्य इंटरफेस के रूप में इस्तेमाल किया गया था), सब कुछ 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 साथ निजीकृत मोड में चलने पर प्रतिलिपि प्रस्तुत करने योग्य है जब हमारे पास सीआईएफ माउंट खुले होते हैं। जब कंटेनर माउंट के साथ बंद हो जाता है, तो डॉकर अनुत्तरदायी हो जाता है और हमें kernel:[ 1129.675495] unregister_netdevice: waiting for lo to become free. Usage count = 1 -error मिलता है।

उबंटू 16.04 (कर्नेल 4.4.0-78-जेनेरिक) में अभी भी समस्या है। और जब ऐसा होता है, तो क्लोन सिस्कल के माध्यम से एक नया नेटवर्क नेमस्पेस बनाने का प्रयास करने वाला कोई भी एप्लिकेशन अटक जाएगा

[ 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

मशीन को हार्ड रीसेट करना ही एकमात्र उपाय है।

मैं इस मुद्दे से मिला जब एक विशेषाधिकार प्राप्त कंटेनर में एनएफएस वॉल्यूम बढ़ाना और फिर कंटेनर को पुनरारंभ करना।
ऐसा लगता है कि यह समस्या आरएचईएल 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 का दावा है कि इस बग का एक उदाहरण कर्नेल-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 "। इस अद्यतन के साथ, अंतर्निहित स्रोत कोड को ठीक कर दिया गया है, और नेटवर्क डिवाइस अब वर्णित स्थिति में अपेक्षित रूप से अपंजीकृत हैं।"

मैंने इस फिक्स को पहले से ही हमारे PaS पूल के सभी सिस्टम में तैनात कर दिया है, और बग हिट किए बिना पहले से ही 2 दिन हो गए हैं। इससे पहले, हमारे पास प्रति दिन कम से कम एक सिस्टम फ़्रीज़ किया जा रहा था। अगर हम फिर से बग मारते हैं तो मैं यहां रिपोर्ट करूंगा।

मेरे पास कर्नेल संस्करण 3.10.0-514.21.1.el7.x86_64 है, और मेरे पास अभी भी वही लक्षण है।

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

@adrianotto जाहिर है, इस मुद्दे को हिट करने के कई तरीके हैं। आपने इस बग के अपने विशेष उदाहरण को कैसे पुन: पेश किया?

@bcdonadio अगर आप https://git.centos.org/commitdiff/rpms!kernel.git/b777aca52781bc9b15328e8798726608933ceded को देखें तो आप देखेंगे कि https://bugzilla.redhat.com/show_bug.cgi?id=1436588 बग है इस परिवर्तन से "निश्चित":

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

जो ४.८ से अपस्ट्रीम कर्नेल में है, मुझे विश्वास है (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

यह स्क्रिप्ट सिर्फ डॉकर रजिस्ट्री में एक छवि का उपयोग करके एक पैकेज सूची तैयार कर रही है, और दूसरा स्थानीय रूप से निर्मित एक का उपयोग कर रहा है ताकि मैं उनकी तुलना कर सकूं। डॉकरफाइल बस यही है:

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

2-4 मिनट बाद syslog को यह संदेश मिलता है:

Message from syslogd<strong i="13">@docker</strong> at May 27 16:51:55 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 0

आखिरी घटना में मैंने स्क्रिप्ट को मैन्युअल रूप से चलाने के कुछ मिनट बाद किया। मेरा अनुमान है कि कंटेनर हटाने का प्रयास करने के बाद कुछ समय समाप्त होने के बाद, त्रुटि स्थिति उठाई जाती है।

मुझे यकीन है कि त्रुटि की स्थिति रुक-रुक कर होती है, क्योंकि ऊपर की स्क्रिप्ट क्रॉन जॉब के रूप में चलती है: 00 प्रत्येक त्रुटि के बाद। यहाँ त्रुटि आउटपुट का एक नमूना है जिसे syslog ने रिकॉर्ड किया है:

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

तो यह कहीं 2 से 4 मिनट की सीमा में होता है जब कंटेनर चलते हैं और बाहर निकलते हैं और --rm ध्वज के कारण docker द्वारा हटा दिए जाते हैं। ऊपर दिए गए लॉग से यह भी ध्यान दें कि चलने/हटाए गए प्रत्येक कंटेनर के लिए कोई त्रुटि नहीं है, लेकिन यह काफी सुसंगत है।

क्या किसी के लिए यह देखना संभव होगा कि क्या यह पैच चीजों में सुधार करता है?

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

@hlrichardson यह वास्तव में ऐसा दिखता है! मैं इसे अपने 3.16 कर्नेल पर बैकपोर्ट करने या विशिष्ट सर्वरों को अपग्रेड करने और कर्नेल 4.9 को कल इस पैच के साथ संकलित करने का प्रयास करूंगा, हम देखेंगे कि यह कैसे जाता है।

हालाँकि, इस पैच संदर्भ की जाँच के बाद (https://github.com/torvalds/linux/commit/0c1d70af924b966cc71e9e48920b2b635441aa50) - यह 4.6 कर्नेल में प्रतिबद्ध था, जबकि समस्या पहले भी थी :(

आह, तो शायद संबंधित नहीं है, जब तक कि कई कारण न हों (दुर्भाग्य से इस प्रकार के बग को ट्रिगर करने के कई तरीके हैं, इसलिए यह एक संभावना है)।

हमने व्यक्तिगत रूप से कम से कम कई मुद्दों को यहां मारा है - उनमें से कुछ में ये
"unregister_netdevice" लॉग कुछ समय के बाद गायब हो जाते हैं और
डॉकटर कंटेनर ठीक काम करने में सक्षम हैं, जबकि अन्य में - सभी कंटेनर
अटक जाते हैं और सर्वर को रिबूट करने की आवश्यकता होती है।

असल में - हम उन सर्वरों पर vxlan का उपयोग नहीं करते हैं जो इन मुद्दों को प्राप्त करते हैं - हम उपयोग करते हैं
सरल पुल और बंदरगाह अग्रेषण (यह उपयोगकर्तालैंड-प्रॉक्सी की परवाह किए बिना होता है
समायोजन)।

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 सुरंगों का उपयोग नहीं कर रहे हैं तो यह निश्चित रूप से मदद नहीं करेगा।

BTW, यदि आप "unregister_netdevice" संदेश का एक भी उदाहरण देखते हैं जब एक नेटवर्क नेमस्पेस हटा दिया जाता है (कंटेनर से बाहर निकलें), तो इसे एक सामान्य स्थिति माना जाना चाहिए जिसमें नेटडिवाइस को संदर्भित करने वाली किसी चीज़ को एक ही समय में कमोबेश साफ किया गया था।
मिटाया जा रहा था।

अधिक गंभीर मामला यह है कि यह संदेश हर 10 सेकंड में दोहराया जाता है और कभी समाप्त नहीं होता...
इस मामले में एक वैश्विक ताला हमेशा के लिए आयोजित किया जाता है, और चूंकि जब भी नेटवर्क होता है तो इस लॉक को हासिल करना पड़ता है
नेमस्पेस जोड़ा या हटाया गया है, नेटवर्क नेमस्पेस बनाने या हटाने का कोई भी प्रयास भी
हमेशा के लिए लटक जाता है।

यदि आपके पास दूसरी प्रकार की समस्या को पुन: उत्पन्न करने का काफी दर्द रहित तरीका है, तो मुझे इसमें दिलचस्पी होगी
ग़ौर करना।

@hlrichardson हम आपके द्वारा ऊपर उल्लिखित दूसरा मामला हमारे सर्वरों के एक समूह पर देख रहे हैं अर्थात संदेश हर 10 सेकंड में दोहराया जाता है। आप मुझसे क्या जानकारी साझा करना चाहते हैं?

फेडोरा 25 पर इसे देखकर सेंटोस का परीक्षण और निर्माण करते समय 7 कंटेनर। यम पैकेज डेटाबेस को डाउनलोड करने में विफल रहा और अनिश्चित काल तक लटका रहा क्योंकि नेटवर्क ने अजीब तरीके से काम करना बंद कर दिया था।

हाय दोस्तों,

लिनक्स नेट-देव मेलिंग सूची में कर्नेल बग (या कम से कम एक बग) के लिए एक संभावित पैच है:

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

इसे नेट ट्री में मिला दिया गया है, स्थिर ट्री के लिए कतारबद्ध है।

https://github.com/torvalds/linux/commit/d747a7a51b00984127a88113cdbbc26f91e9d815 के अनुसार - यह 4.12 में है (जो कल जारी किया गया था)!

@fxposter @kevinxucs मैं कल इसे वर्तमान CentOS कर्नेल में बैकपोर्ट करने का प्रयास करूँगा।

मैं 4.12 चला रहा हूं (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12/ से) और मैं अभी भी इसे हिट करता हूं, इसलिए torvalds /

$ uname -r
4.12.0-041200-generic

रयान, क्या आपके पास पुनरुत्पादन का एक विश्वसनीय तरीका है?

6 जुलाई 2017 को शाम 4:29 बजे, "रयान कैंपबेल" नोटिफिकेशन @github.com ने लिखा:

मैं 4.12 चला रहा हूं (http://kernel.ubuntu.com/~ . से)
कर्नेल-पीपीए/मेनलाइन/v4.12/) और मैं अभी भी इसे हिट करता हूं, इसलिए टोरवाल्ड्स/लिनक्स @
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 syslog में) केवल कुछ पुनरावृत्तियों के बाद।

@campbellr मैं अब इसे तीन बार waiting for lo to become free संदेशों को दो बार प्राप्त करने में कामयाब रहा लेकिन बाद में क्रैश/हैंग किए बिना। मैं केवल नेटवर्क नेमस्पेस और वीथ इंटरफेस बनाकर टेस्ट केस को कम करने की कोशिश कर रहा हूं।

आपके परीक्षण सूट में:

• क्या आपके कंटेनरों में बहुत अधिक नेटवर्क गतिविधि है? यदि हां, तो कौन सी दिशा प्रबल है?
• आप इसे किस प्रकार की मशीन चला रहे हैं (कोर की संख्या, क्या यह एक वीएम है, आदि)
• क्या आप एक साथ बहुत सारे कंटेनर बनाते हैं?
• क्या आपके कंटेनर सामान्य रूप से बाहर निकलते हैं या वे दुर्घटनाग्रस्त हो जाते हैं?

उपरोक्त के आंशिक उत्तर भी इसे कम करने में मदद कर सकते हैं ...
धन्यवाद

@rn डॉकर अब और नहीं लटकता है । लेकिन आप नए कंटेनर शुरू करने में सक्षम नहीं होंगे (या मौजूदा वाले को पुनरारंभ करें), संभावित रूप से स्टॉप पर कंटेनर सफाई भी अजीब होगी।

मुझे अभी तक ४.१२ पर परीक्षण करने का मौका नहीं मिला है, लेकिन मैं vultr पर kvm उदाहरणों पर मज़बूती से पुन: पेश कर सकता हूँ। मैं झुंड में भाग रहा हूं और मेरे बिना सिर वाले क्रोम कार्यकर्ता स्वास्थ्य जांच में विफल होने या नियमित रूप से दुर्घटनाग्रस्त होने पर समस्या का कारण बनते हैं। बेशक इस बिंदु पर मैंने सभी क्रैशर्स को नेटवर्क त्रुटियों को साफ-सुथरा तरीके से ट्रैक किया है, इसलिए मुझे waiting for lo to become free लेकिन अक्सर कुछ हफ्तों के लिए चीजों को लटकाने के लिए पर्याप्त नहीं है।

तो ऐसा लगता है कि पुनरुत्पादन में मदद करने वाली चीजें अधिक जटिल नेटवर्किंग परिदृश्य हैं जो कंटेनरों में बड़ी मात्रा में यातायात, निरंतर कंटेनर रीसाइक्लिंग और केवीएम के साथ मिलती हैं।

@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 है, और प्रतिक्रिया एक बाइनरी ब्लॉब है जो लगभग 10MB है।

आप इसे किस प्रकार की मशीन चला रहे हैं (कोर की संख्या, क्या यह एक वीएम है, आदि)

यह 4-कोर डेस्कटॉप मशीन पर है (कोई VM नहीं)

क्या आप एक साथ बहुत सारे कंटेनर बनाते हैं?

नहीं, सब कुछ क्रमिक रूप से किया जाता है।

क्या आपके कंटेनर सामान्य रूप से बाहर निकलते हैं या वे दुर्घटनाग्रस्त हो जाते हैं?

उन्हें docker stop साथ रोका गया है

1. कंटेनर शुरू करें (एक आंतरिक बवंडर-आधारित वेब सेवा - मैं एक न्यूनतम उदाहरण निकालने की कोशिश कर रहा हूं जो अभी भी इसे हिट करता है)
2. कंटेनर में चल रही वेब सेवा के लिए अनुरोध करें
3. प्रतिक्रिया की प्रतीक्षा करें
4. कंटेनर को मार डालो

मैंने कंटेनर को नीचे उतारने में कुछ समय बिताया और यह पता चला कि वेब सेवा का बग से कोई लेना-देना नहीं था। मेरे मामले में इसे ट्रिगर करने के लिए क्या लगता है एक कंटेनर के अंदर एक एनएफएस शेयर बढ़ रहा है ( --privileged साथ चल रहा है)।

अपने डेस्कटॉप पर, मैं निम्नलिखित को कुछ बार चलाने के लिए मज़बूती से पुन: पेश कर सकता हूँ:

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

Kubernetes उपयोगकर्ता, मैंने कर्नेल संस्करण 4.12 के साथ अगला Kubernetes AMI जारी करने के लिए _kops_ के लिए एक समस्या खोली। इसे देखने के लिए आपका स्वागत है: https://github.com/kubernetes/kops/issues/2901

मैंने इसे होस्ट कर्नेल 3.10.0-514.6.1.el7.x86_64 और docker-ce-17.06.0.ce-1.el7.centos.x86_64 के साथ सेंटोस 7.3 पर भी मारा।

@FrankYu मददगार नहीं है। इस थ्रेड में उपयोगी रूप से भाग लेने के लिए, कृपया इस मुद्दे को पुन: उत्पन्न करने का एक सटीक तरीका प्रदान करें, और कृपया एक आधुनिक कर्नेल पर परीक्षण करें। 3.10 चार साल पहले रिलीज हुई थी, हम इस बारे में चर्चा कर रहे हैं कि यह चार दिन पहले से रिलीज पर तय है या आंशिक रूप से।

@danielgusmao हमारे RancherOS और AWS ECS AMI linux OS में पहले से ही वह 'फिक्स' है (संभवतः डिफ़ॉल्ट था) और यह हमारे लिए समस्या का समाधान नहीं करता है। हम अभी भी संदेश को हर समय लॉग में प्रदर्शित होते देखते हैं। संभवतः केवल आशा है कि कर्नेल पैच व्यापक रूप से बैकपोर्ट हो जाए। हालाँकि मैंने चारों ओर खोज की और अभी तक RedHat/Centos/AWS linux Bugzillas और फ़ोरम में उस ओर गंभीर प्रगति का कोई सबूत नहीं देख सकता।

स्पष्ट होने के लिए, संदेश स्वयं सौम्य है , ओपी द्वारा रिपोर्ट किए गए संदेशों के बाद यह कर्नेल क्रैश है जो नहीं है।

कोड में टिप्पणी , जहां से यह संदेश आ रहा है, बताता है कि क्या हो रहा है। मूल रूप से प्रत्येक उपयोगकर्ता, जैसे कि आईपी स्टैक) एक नेटवर्क डिवाइस का (जैसे कंटेनर के अंदर veth जोड़ी का अंत) नेटवर्क डिवाइस का उपयोग करते समय नेटवर्क डिवाइस संरचना में एक संदर्भ गणना में वृद्धि करता है। जब डिवाइस को हटा दिया जाता है (उदाहरण के लिए, जब कंटेनर को हटा दिया जाता है) तो प्रत्येक उपयोगकर्ता को सूचित किया जाता है ताकि वे संदर्भ संख्या को कम करने से पहले कुछ सफाई (जैसे खुले सॉकेट आदि को बंद करना) कर सकें। क्योंकि इस सफाई में कुछ समय लग सकता है, विशेष रूप से भारी भार (बहुत सारे इंटरफ़ेस, बहुत सारे कनेक्शन आदि) के तहत, कर्नेल संदेश को यहां एक बार में प्रिंट कर सकता है।

यदि संजाल युक्ति का कोई उपयोक्ता संदर्भ संख्या में कभी कमी नहीं करता है, तो कर्नेल का कोई अन्य भाग यह निर्धारित करेगा कि सफाई के लिए प्रतीक्षा कर रहा कार्य अटक गया है और यह दुर्घटनाग्रस्त हो जाएगा। यह केवल यह क्रैश है जो कर्नेल बग को इंगित करता है (कुछ उपयोगकर्ता, कुछ कोड पथ के माध्यम से, संदर्भ संख्या में कमी नहीं करते हैं)। ऐसे कई बग हैं और उन्हें आधुनिक कर्नेल में ठीक किया गया है (और संभवत: पुराने वाले को वापस पोर्ट किया गया है)। मैंने इस तरह के क्रैश को ट्रिगर करने के लिए कुछ तनाव परीक्षण (और उन्हें लिखना जारी रखा) लिखा है, लेकिन आधुनिक कर्नेल पर पुन: पेश करने में सक्षम नहीं हूं (हालांकि मैं उपरोक्त संदेश करता हूं)।

कृपया इस मुद्दे पर केवल तभी रिपोर्ट करें जब आपका कर्नेल वास्तव में क्रैश हो जाए, और तब हमें इसमें बहुत दिलचस्पी होगी:

• कर्नेल संस्करण ( uname -r का आउटपुट)
• लिनक्स वितरण/संस्करण
• क्या आप अपने Linux विक्रेता के नवीनतम कर्नेल संस्करण पर हैं?
• नेटवर्क सेटअप (ब्रिज, ओवरले, IPv4, IPv6, आदि)
• कार्यभार का विवरण (किस प्रकार के कंटेनर, किस प्रकार का नेटवर्क लोड, आदि)
• और आदर्श रूप से एक साधारण प्रजनन

धन्यवाद

[ @thaJeztah क्या आप इसे और अधिक स्पष्ट करने के लिए शीर्षक को kernel crash after "unregister_netdevice: waiting for lo to become free. Usage count = 3" बदल सकते हैं]

कर्नेल 4.12 या देर से तय किया जाना चाहिए। कृपया जांचें। https://access.redhat.com/solutions/3105941
और पैच करने के लिए लिंक https://github.com/torvalds/linux/commit/d747a7a51b00984127a88113cdbbc26f91e9d815

@drweber आपको यह पैच आगामी स्थिर रिलीज़ में भी मिलेगा (अभी के लिए ४.११.१२, ४.९.३९, ४.४.७८, ३.१८.६२)

@rn

यदि संजाल युक्ति का कोई उपयोक्ता संदर्भ संख्या में कभी कमी नहीं करता है, तो कर्नेल का कोई अन्य भाग यह निर्धारित करेगा कि सफाई के लिए प्रतीक्षा कर रहा कार्य अटक गया है और यह दुर्घटनाग्रस्त हो जाएगा। यह केवल यह क्रैश है जो कर्नेल बग को इंगित करता है (कुछ उपयोगकर्ता, कुछ कोड पथ के माध्यम से, संदर्भ संख्या में कमी नहीं करते हैं)। ऐसे कई बग हैं और उन्हें आधुनिक कर्नेल में ठीक किया गया है (और संभवत: पुराने वाले को वापस पोर्ट किया गया है)। मैंने इस तरह के क्रैश को ट्रिगर करने के लिए कुछ तनाव परीक्षण (और उन्हें लिखना जारी रखा) लिखा है, लेकिन आधुनिक कर्नेल पर पुन: पेश करने में सक्षम नहीं हूं (हालांकि मैं उपरोक्त संदेश करता हूं)।

कृपया इस मुद्दे पर केवल तभी रिपोर्ट करें जब आपका कर्नेल वास्तव में क्रैश हो जाए ...

हमारे पर्यावरण में थोड़ा अलग मुद्दा है कि मैं कुछ स्पष्टीकरण प्राप्त करने की उम्मीद कर रहा हूं (कर्नेल 3.16.0-77-जेनेरिक, उबंटू 14.04, डॉकर 1.12.3-0 ~ भरोसेमंद। हमारे पास हजारों होस्ट चल रहे हैं डॉकर, 2 -3 कंटेनर प्रति होस्ट, और हम इसे डॉकटर चलाने वाले कुल होस्ट के <1% पर देख रहे हैं)।

हम वास्तव में कर्नेल क्रैश को कभी नहीं देखते हैं, लेकिन इसके बजाय (मूल पत्रकारों की तरह जहां तक ​​​​मैं बता सकता हूं) dockerd प्रक्रिया समाप्त हो गई है। अपस्टार्ट (अपस्ट्रीम पैकेज से /etc/init/docker.conf जॉब का उपयोग करके) एक नई dockerd प्रक्रिया शुरू नहीं करेगा क्योंकि यह सोचता है कि यह पहले से चल रहा है ( start: Job is already running: docker ), और अपस्टार्ट को रोकने का प्रयास कर रहा है नौकरी भी विफल हो जाती है ( docker start/killed, process <pid of defunct process> )।

$ ps -ely
S   UID   PID  PPID  C PRI  NI   RSS    SZ WCHAN  TTY          TIME CMD
...
Z     0 28107     1  0  80   0     0     0 -      ?        00:18:05 dockerd <defunct>

चूंकि हम अधिकतर dmesg ब्रिज नेटवर्किंग (कस्टम ब्रिज डिवाइस पर) के साथ चलते हैं,

[7895942.484851] unregister_netdevice: waiting for vethb40dfbc to become free. Usage count = 1
[7895952.564852] unregister_netdevice: waiting for vethb40dfbc to become free. Usage count = 1
[7895962.656984] unregister_netdevice: waiting for vethb40dfbc to become free. Usage count = 1

चूंकि अपस्टार्ट डॉकर्ड को पुनरारंभ करने से इंकार कर देता है या यह मानता है कि पहले से चल रही प्रक्रिया एक ज़ोंबी है, हमने पाया है कि एकमात्र समाधान होस्ट को रीबूट करना है।

जबकि हमारा परिणाम अलग लगता है (कर्नेल क्रैश नहीं होता) मूल कारण समान या समान लगता है। तो क्या यह वही मुद्दा नहीं है? क्या ऐसा होने पर docker अपस्टार्ट जॉब को फिर से चलाने योग्य बनाने का कोई ज्ञात समाधान या तरीका है?

@campbellr मैं इस मुद्दे को कर्नेल 4.12.2-1 पर आपके दृष्टिकोण के साथ पुन: पेश कर सकता हूं।
BTW, अगर मैं कंटेनर को रोकने से पहले 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 (आर्क लिनक्स) कर्नेल: मैं कुछ पुनरावृत्तियों (<10) में docker-samba-loop साथ बग उत्पन्न करता हूं। मैं इसे docker-nfs-loop साथ पुन: पेश नहीं कर सकता
• 4.11.9-1-ARCH समान परिणाम ( संस्करण )
• 4.12.3-1-ARCH (परीक्षण रेपो) समान परिणाम
• 4.11.11-coreos: के लिए एक ही परिणाम docker-samba-loop , कोशिश नहीं की docker-nfs-loop

उम्मीद है ये मदद करेगा
चियर्स

मेरे मामले में --net=host का उपयोग करना एक समाधान है। लेकिन यह हमेशा स्वीकार्य समाधान नहीं होता है

@piec , विवरण के लिए बहुत धन्यवाद। इस बहुत लंबी टिप्पणी के अंत में मेरे पास आपके लिए कुछ और प्रश्न हैं।

एसएमबी सेटअप का उपयोग करके मैं विभिन्न कर्नेल के साथ कई चीजें तैयार करने में सक्षम था। मैंने इसे एनएफएस सेटअप के साथ भी आजमाया है लेकिन कोई पासा नहीं है।

हाइपरकिट पर डॉकर 17.06.1-सीई के साथ सभी परीक्षण 2 वीसीपीयू और 2 जीबी मेमोरी के साथ कॉन्फ़िगर किए गए वीएम के साथ चलाए जाते हैं (मैक के लिए डॉकर के माध्यम से, लेकिन इससे कोई फर्क नहीं पड़ता)। मैं LinuxKit कर्नेल का उपयोग कर रहा हूं, क्योंकि मैं उन्हें आसानी से स्वैप कर सकता हूं।

मैंने आपके Dockerfile को संशोधित किया है जिसमें मैंने date में एक कॉल जोड़ा है क्योंकि पहले कमांड को निष्पादित किया गया था और date से पहले और बाद में docker run एक कॉल भी जोड़ा गया था। ग्राहक।

प्रयोग 1 (4.9.39 कर्नेल)

4.9.39 (नवीनतम 4.9.x स्थिर कर्नेल) के साथ मुझे कर्नेल क्रैश मिलता है:

# while true; do  date;    docker run -it --rm --name client-smb --cap-add=SYS_ADMIN --cap-add DAC_READ_SEARCH --link samba:samba client-smb:1;  date;   sleep 1; done
Thu 27 Jul 2017 14:12:51 BST
+ date
Thu Jul 27 13:12:52 UTC 2017
+ mount.cifs //172.17.0.2/public /mnt/ -o vers=3.0,user=nobody,password=
+ date
Thu Jul 27 13:12:52 UTC 2017
+ ls -la /mnt
total 1028
drwxr-xr-x    2 root     root             0 Jul 27 10:11 .
drwxr-xr-x    1 root     root          4096 Jul 27 13:12 ..
-rwxr-xr-x    1 root     root             3 Jul 27 10:11 bla
+ umount /mnt
+ echo umount ok
umount ok
Thu 27 Jul 2017 14:12:52 BST
Thu 27 Jul 2017 14:12:53 BST

---> First iteration suceeds and then hangs on the docker run

और dmesg :

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

कभी-कभी मुझे unregister_netdevice संदेशों (नीचे देखें) सहित ४.११.१२ कर्नेल क्या करता है, इसके कई पुनरावृत्ति दिखाई देते हैं और फिर कर्नेल क्रैश ऊपर मिलता है। कभी-कभी मुझे दुर्घटना के लिए थोड़ी भिन्नता दिखाई देती है, जैसे:

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

क्रैश यूनिक्स डोमेन सॉकेट कोड में हैं और जो है के समान/समान हैं
यहां रिपोर्ट किया गया

प्रयोग २ (४.११.१२ कर्नेल)

४.११.१२ के साथ (जो ४.११ श्रृंखला में नवीनतम स्थिर है) मुझे कोई क्रैश नहीं दिखाई देता है, लेकिन यह वास्तव में धीमा है ( ---> साथ एनोटेशन इनलाइन):

# while true; do  date;    docker run -it --rm --name client-smb --cap-add=SYS_ADMIN --cap-add DAC_READ_SEARCH --link samba:samba client-smb:1;  date;   sleep 1; done
Thu 27 Jul 2017 13:48:04 BST
+ date
Thu Jul 27 12:48:05 UTC 2017
+ mount.cifs //172.17.0.2/public /mnt/ -o vers=3.0,user=nobody,password=
+ date
Thu Jul 27 12:48:05 UTC 2017
+ ls -la /mnt
total 1028
drwxr-xr-x    2 root     root             0 Jul 27 10:11 .
drwxr-xr-x    1 root     root          4096 Jul 27 12:48 ..
-rwxr-xr-x    1 root     root             3 Jul 27 10:11 bla
+ umount /mnt
+ echo umount ok
umount ok
Thu 27 Jul 2017 13:48:05 BST

---> First iteration takes one second

Thu 27 Jul 2017 13:48:06 BST
docker: Error response from daemon: containerd: container did not start before the specified timeout.
Thu 27 Jul 2017 13:50:07 BST

---> Second iteration fails after 2 minutes with dockerd unable to start the container

Thu 27 Jul 2017 13:50:08 BST
+ date
Thu Jul 27 12:51:52 UTC 2017
+ mount.cifs //172.17.0.2/public /mnt/ -o vers=3.0,user=nobody,password=
+ date
Thu Jul 27 12:51:53 UTC 2017
+ ls -la /mnt
total 1028
drwxr-xr-x    2 root     root             0 Jul 27 10:11 .
drwxr-xr-x    1 root     root          4096 Jul 27 12:50 ..
-rwxr-xr-x    1 root     root             3 Jul 27 10:11 bla
+ umount /mnt
+ echo umount ok
umount ok
Thu 27 Jul 2017 13:51:53 BST

---> Third iterations succeeds, BUT it takes almost 2 minutes between docker run and the container running

Thu 27 Jul 2017 13:51:54 BST
docker: Error response from daemon: containerd: container did not start before the specified timeout.
Thu 27 Jul 2017 13:53:55 BST

---> Fourth iteration fails after two minutes

Thu 27 Jul 2017 13:53:56 BST
+ date
Thu Jul 27 12:55:37 UTC 2017
+ mount.cifs //172.17.0.2/public /mnt/ -o vers=3.0,user=nobody,password=
+ date
Thu Jul 27 12:55:37 UTC 2017
+ ls -la /mnt
total 1028
drwxr-xr-x    2 root     root             0 Jul 27 10:11 .
drwxr-xr-x    1 root     root          4096 Jul 27 12:53 ..
-rwxr-xr-x    1 root     root             3 Jul 27 10:11 bla
+ umount /mnt
+ echo umount ok
umount ok
Thu 27 Jul 2017 13:55:38 BST

---> Fifth iteration succeeds, but almost 2 minutes between docker run and the container executing

मेरे पास यह एक या एक घंटे के लिए एक ही पैटर्न को दोहराने के साथ चल रहा था, लेकिन कोई कर्नेल क्रैश नहीं हुआ।

मैं कर्नेल लॉग देखता हूं, बहुत सारे:

[   84.940380] unregister_netdevice: waiting for lo to become free. Usage count = 1
[   95.082151] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  105.253289] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  115.477095] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  125.627059] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  135.789298] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  145.969455] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  156.101126] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  166.303333] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  176.445791] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  186.675958] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  196.870265] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  206.998238] unregister_netdevice: waiting for lo to become free. Usage count = 1
[...]

यह हर दस सेकंड में एक संदेश है।

चूंकि यह एक घंटे के बाद भी हैंग टास्क डिटेक्शन को किक करने का कारण नहीं बनता है, मुझे संदेह है कि 4.11.12 के साथ संदर्भ गणना अंततः घट जाती है और डिवाइस मुक्त हो जाता है, लेकिन, अंतराल को देखते हुए मैं कंटेनर चला सकता हूं, इसमें लग सकता है 4 मिनट तक!

प्रयोग ३ (४.११.१२ कर्नेल)

ओपी में कर्नेल क्रैश ने संकेत दिया कि कर्नेल क्रैश हो गया क्योंकि एक त्रिशंकु कार्य का पता चला था। मैंने अपने परीक्षण में इस दुर्घटना को नहीं देखा है, इसलिए मैंने 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 से पहले लगभग 2 मिनट लगते हैं कि containerd शुरू नहीं हुआ, लटका कार्य का पता लगाने को 60 के दशक तक कम करने से कर्नेल पैनिक को ट्रिगर करना चाहिए यदि कोई एकल कार्य लटका हुआ था। काश, लॉग में कोई दुर्घटना नहीं होती

प्रयोग 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

ऐसा लगता है कि हमें लगभग हर docker run (दूसरे को छोड़कर) पर लगभग 200 सेकंड का मूल्य unregister_netdevice । मुझे संदेह है कि उस समय के दौरान हम नए कंटेनर शुरू नहीं कर सकते हैं (जैसा कि प्रयोग 2 द्वारा इंगित किया गया है। यह उत्सुक है कि लटका हुआ कार्य पता लगाना शुरू नहीं हो रहा है, संभवतः क्योंकि कोई कार्य लटका हुआ नहीं है।

प्रयोग ५ (४.११.१२/४.९.३९ कर्नेल में एक अतिरिक्त डिबगिंग सक्षम के साथ)

यह docker run . के बीच में वापस 1s नींद में वापस आ रहा है

हमारे पास एक और कर्नेल है जिसने अतिरिक्त डिबग का एक गुच्छा सक्षम किया है
विकल्प, जैसे LOCKDEP , RCU_TRACE , LOCKUP_DETECTOR और कुछ
अधिक।

इन डिबग विकल्पों के साथ रेप्रो 4.11.12 कर्नेल चलाने से कुछ भी ट्रिगर नहीं हुआ।

4.9.39 कर्नेल के लिए ठीक वैसा ही, जहां सामान्य कर्नेल क्रैश हो जाता है। डिबग विकल्प समय को थोड़ा बदलते हैं, इसलिए यह एक अतिरिक्त सुराग हो सकता है कि यूनिक्स डोमेन सॉकेट कोड में क्रैश के बारे में एक दौड़ के कारण है।

थोड़ा और गहरा खोदो

strace विभिन्न containerd प्रक्रियाओं पर सहायक नहीं है (यह
आमतौर पर ऐसा नहीं है क्योंकि यह गो में लिखा है)। में बहुत सारे लंबे स्टाल
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 कार्य कतार आगे नहीं बढ़ रही है और इस प्रकार संदेश मुद्रित होता है।
• यह पूरी तरह से स्पष्ट नहीं है कि एसएमबी इसे कैसे/क्यों ट्रिगर कर रहा है। मैंने नेटवर्क नेमस्पेस और विभिन्न वर्कलोड के लिए कुछ 60 विषम तनाव परीक्षण लिखे हैं और किसी भी समस्या को ट्रिगर करने में असमर्थ था। परीक्षण runc पर आधारित थे, शायद मुझे containerd प्रयास करना चाहिए।

मैं थोड़ा और खोदूंगा और फिर सारांश भेजूंगा netdev ।

@piec क्या आपके पास कंसोल एक्सेस है और आप देख सकते हैं कि क्रैश डंप के मामले में कुछ है या क्या आप भी बस बड़ी देरी देखते हैं जैसा कि मैं देख रहा हूं? यदि आपके पास क्रैश डंप है, तो मुझे इसे देखने में बहुत दिलचस्पी होगी। इसके अलावा, क्या आप नंगे धातु या वीएम में चल रहे हैं? CPU और मेमोरी के संदर्भ में आपका कॉन्फ़िगरेशन क्या है?

@rn जांच के लिए धन्यवाद!

मैं एक बेयरमेटल डेस्कटॉप पीसी पर चल रहा हूं इसलिए मेरे पास हर चीज तक पहुंच है। यह एक i7-4790K + 32 GiB है।
वर्तमान में मैं परीक्षण रेपो (4.12.3-1-ARCH) से अप-टू-डेट आर्क लिनक्स + कर्नेल पर चल रहा हूं

मेरे मामले में सब कुछ वैसा ही व्यवहार करता है जैसा आप अपने प्रयोग 2 (4.11.12 कर्नेल) में वर्णित करते हैं:

• क्लाइंट-एसएमबी कंटेनर मौजूद होने के बाद 4+ मिनट के लिए नए कंटेनर चलाना असंभव है।
• मेरे पास कर्नेल क्रैश कभी नहीं है
• unregister_netdevice: waiting for lo to become free. Usage count = 1 संदेश बार-बार प्रकट होता है यदि मैं क्लाइंट-एसएमबी से बाहर निकलने के बाद 4+ मिनट की देरी में कोई नया कंटेनर चलाने का प्रयास करता हूं। और केवल तभी दिखाई देता है जब आप उस 4 मिनट के समय व्यतीत होने पर एक नया कंटेनर चलाते हैं। इन 4 मिनट के बाद नया कंटेनर चलाना "सामान्य" होगा

तो मुझे लगता है कि नेटवर्क इंटरफेस से संबंधित एसएमबी-क्लाइंट कंटेनर की सफाई प्रक्रिया में कहीं न कहीं कोई समस्या है

वास्तव में इस मुद्दे (जो, BTW मूल मुद्दा नहीं है) की एक बहुत सरल रेप्रो है।

यह स्क्रिप्ट सिर्फ मेजबान पर एक एसएमबी सर्वर शुरू होता है और फिर एक के साथ एक नेटवर्क नाम स्थान बनाता है veth जोड़ी, कार्यान्वित mount; ls; unmount नेटवर्क का नाम अंतरिक्ष में और फिर नेटवर्क नाम स्थान को हटा।

apk add --no-cache iproute2 samba samba-common-tools cifs-utils

# SMB server setup
cat <<EOF > /etc/samba/smb.conf
[global]
    workgroup = WORKGROUP
    netbios name = FOO
    passdb backend = tdbsam
    security = user
    guest account = nobody
    strict locking = no
    min protocol = SMB2
[public]
    path = /share
    browsable = yes
    read only = no
    guest ok = yes
    browseable = yes
    create mask = 777
EOF
adduser -D -G nobody nobody && smbpasswd -a -n nobody
mkdir /share && chmod ugo+rwx /share && touch /share/foo
chown -R nobody.nobody /share

# Bring up a veth pair
ip link add hdev type veth peer name nsdev
ip addr add 10.0.0.1/24 dev hdev
ip link set hdev up

# Start SMB server and sleep for it to serve
smbd -D; sleep 5

# Client setup
ip netns add client-ns
ip link set nsdev netns client-ns
ip netns exec client-ns ip addr add 10.0.0.2/24 dev nsdev
ip netns exec client-ns ip link set lo up
ip netns exec client-ns ip link set nsdev up
sleep 1 # wait for the devices to come up

# Execute (mount, ls, unmount) in the network namespace and a new mount namespace
ip netns exec client-ns unshare --mount \
    /bin/sh -c 'mount.cifs //10.0.0.1/public /mnt -o vers=3.0,guest; ls /mnt; umount /mnt'

# Delete the client network namespace.
ip netns del client-ns

# Create a new network namespace
# This will stall for up to 200s
ip netns add new-netns

नोट अनमाउंट के बाद एक साधारण sleep 1 जोड़ने पर ध्यान दें, या तो नेमस्पेस में निष्पादित करते समय या नेटवर्क नेमस्पेस को हटाने से पहले नया नेमस्पेस बनाते समय बिल्कुल भी रुके बिना काम करता है। पुराने नेमस्पेस को हटाने के बाद एक नींद, रुकने को कम नहीं करती है।

@piec मैंने आपके sleep 1 के साथ Dockerfile में अनमाउंट के बाद इसका परीक्षण किया और सब कुछ अपेक्षित रूप से काम करता है, कोई रोक नहीं, कोई unregister_netdev संदेश नहीं।

मैं इसे अभी लिखूंगा और netdev@vger भेजूंगा

उत्कृष्ट
मैं पुष्टि करता हूं कि एक sleep अनमाउंट करने के बाद मेरे सेटअप में रुकने और unregister_netdev संदेशों को भी ठीक करता है

क्या आपको नहीं लगता कि umount अपने netns के सापेक्ष एक अतुल्यकालिक क्रिया उत्पन्न करता है जो उस क्रिया के समाप्त होने से पहले netns को हटा दिए जाने पर अवरुद्ध हो जाएगा और अंततः समय समाप्त हो जाएगा? माउंट के बाद एक नींद नेट्स को हटाने से पहले इस सामान को खत्म कर देगी।
लेकिन यह सिर्फ एक परिकल्पना है

मैंने अनमाउंट के बिना कोशिश की, वही अंतर। यह नेटवर्क नेमस्पेस को हटाना है। वह 9और माउंट नेमस्पेस को हटाने से वैसे भी अनमाउंट ट्रिगर हो जाएगा।

आह अच्छा

वैसे मैंने फिर से smb के साथ दूसरी मशीन पर गलती से (विकास करते समय) इस मुद्दे को पुन: पेश किया। यह एक उबंटू 16.04 पीसी, लिनक्स 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 है ।

@piec हाँ, यह अपेक्षित है।

मैं भी इस बग में चला गया और उफ़ को उबंटू कर्नेल छवियों पर docker -samba-loop विधि के साथ पुन: पेश करने में सक्षम था:

• लिनक्स-छवि-4.4.0-93-जेनेरिक
• लिनक्स-छवि-4.10.0-1004-जीसीपी
• लिनक्स-छवि-4.10.0-32-जेनेरिक
• लिनक्स-छवि-4.11.0-14-जेनेरिक
• linux-image-4.12.10-041210-generic=4.12.10-041210.20170830

मैंने अपने निष्कर्षों को उबंटू बग रिपोर्ट में जोड़ा: 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 जानकारी के लिए धन्यवाद। मैंने अभी तक उस तरह की कोशिश नहीं की है।

यहां और नेटदेव मेलिंगलिस्ट पर हाल की पोस्ट केवल कर्नेल स्टॉल के बारे में प्रतीत होती हैं।
मैं कर्नेल 4.11 और 4.12 के साथ कर्नेल क्रैश भी कर रहा हूं।

मुझे इससे बहुत मिलती-जुलती समस्या दिखाई दे रही है (जैसा कि #35068 में बताया गया है)। हम मूल रूप से दो-नोड झुंड चलाते हैं, जो एक स्प्रेड प्लेसमेंट रणनीति का उपयोग करके 4 प्रतिकृतियों के साथ एकल सेवा चलाता है।

इनमें से प्रत्येक सर्विस कंटेनर में हम होस्ट docker.sock को वॉल्यूम के रूप में माउंट करते हैं, और कंटेनर के भीतर से हम docker run कमांड को निष्पादित करते हैं, जिसमें अधिकतम 4 प्रति कंटेनर होता है। इसके परिणामस्वरूप अधिकतम 4 कंटेनर एक साथ बनाए जाते हैं, और तुरंत बाद -rm माध्यम से हटा दिए जाते हैं।

उपरोक्त संदर्भ में दिखाए गए ARMv7 पर अतिरिक्त कर्नेल लॉग और उदाहरण।

ip6_route_dev_notify घबराहट हमारे लिए एक गंभीर समस्या है।

मुझे लगता है कि इसे थोड़ा और देखकर, यह निश्चित रूप से वही बग नहीं है:

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

मुझे लगता है कि यह कर्नेल में ipv6 परत के साथ एक अपस्ट्रीम मुद्दा है।

यह जानकारी प्रासंगिक हो सकती है।

हम _unregister_netdevice के साथ समस्या को पुन: उत्पन्न करने में सक्षम हैं: लो के मुक्त होने की प्रतीक्षा में। उपयोग गणना = 1_ ४.१४.०-आरसी३ कर्नेल के साथ _CONFIG_PREEMPT_NONE=y_ के साथ और निम्नलिखित बूट कर्नेल विकल्पों के साथ केवल एक सीपीयू पर चल रहा है:

BOOT_IMAGE=/boot/vmlinuz-4.14.0-rc3 root=/dev/mapper/vg0-root ro शांत vssyscall=emulate nosmp

एक बार जब हम इस अवस्था से टकराते हैं, तो यह इसी अवस्था में रहता है और रिबूट की आवश्यकता होती है। कोई और कंटेनर पैदा नहीं किया जा सकता है। हम इसे छवियों को चलाकर ipsec/openvpn कनेक्शन + सुरंगों के अंदर एक छोटी फ़ाइल डाउनलोड करके पुन: पेश करते हैं। तब उदाहरण मौजूद हैं (आमतौर पर वे <10s चलाते हैं)। हम एक मशीन पर एक मिनट में 10 ऐसे कंटेनर चलाते हैं। उपरोक्त सेटिंग्स (केवल 1cpu) के साथ, मशीन इसे ~ 2 घंटे में हिट करती है।

एक ही कर्नेल के साथ एक और पुनरुत्पादक, लेकिन सीपीयू की संख्या को सीमित किए बिना, कंटेनर के अंदर 3 सेकंड के लिए यूडीपी मोड में बस iperf चलाना है (इसलिए कोई टीसीपी संचार बिल्कुल नहीं है)। यदि हम ऐसे 10 कंटेनरों को समानांतर में चलाते हैं, तो उन सभी के खत्म होने की प्रतीक्षा करें और इसे फिर से करें, हम 10 मिनट से भी कम समय में (40 कोर मशीन पर) परेशानी का सामना करते हैं।

हमारे दोनों पुनरुत्पादकों में, हमने "आईपी रूट फ्लश टेबल ऑल; ifconfig . जोड़ानीचे; स्लीप 10" कंटेनर से मौजूद होने से पहले। इसका कोई असर नहीं दिखता है।

नमस्ते,

बस आग में जोड़ने के लिए हम इस समस्या को भी देख रहे हैं, जैसा कि यहां अनुरोध किया गया है निम्नलिखित हैं...

कर्नेल संस्करण: Linux exe-v3-worker 4.9.0-3-amd64 #1 SMP डेबियन 4.9.30-2+deb9u5 (2017-09-19) x86_64 GNU/Linux

Linux वितरण/संस्करण: डेबियन 9.1 (सभी पैकेजों के साथ अद्यतित)

क्या आप अपने Linux विक्रेता के नवीनतम कर्नेल संस्करण पर हैं? हां

नेटवर्क सेटअप (ब्रिज, ओवरले, IPv4, IPv6, आदि): केवल IPv4, डिफ़ॉल्ट डॉकर सेटअप के अनुसार NATed

कार्यभार का विवरण (किस प्रकार के कंटेनर, किस प्रकार का नेटवर्क लोड, आदि): बहुत कम समय तक चलने वाले कंटेनर (कुछ सेकंड से कुछ मिनटों तक) बाहर निकलने से पहले स्क्रिप्ट चलाना।

और आदर्श रूप से एक साधारण प्रजनन:

**कर्नेल:[६१७६२४.४१२१००] unregister_netdevice: लो के मुक्त होने की प्रतीक्षा में। उपयोग गिनती = 1

पुराने कंटेनर को मार नहीं सका या प्रभावित नोड्स पर नए शुरू नहीं कर सका, कार्यक्षमता बहाल करने के लिए रीबूट करना पड़ा।**

उम्मीद है कि हमें जल्द ही एक मूल कारण / पैच मिल जाएगा।

सादर,

रोबपुट७९६

@ कैंपबेलर
सहमत हैं कि ऐसा लगता है कि नेटवर्किंग स्टोरेज के साथ कुछ करना है। मैं Kubernetes में लगातार मात्रा के रूप में ceph krbd का उपयोग कर रहा हूँ।
और मैं लंबे समय से चल रहे कंटेनर दुर्घटना के बाद स्थिति को पुन: उत्पन्न कर सकता हूं।

मुद्दा 10 दिन पहले सौंपा गया था और यह काम प्रगति पर है, आप यहां क्या हो रहा है, इसके बारे में अधिक जानकारी देख सकते हैं https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407

उम्मीद है कि डैन स्ट्रीटमैन को पता चल जाएगा कि इसे कैसे ठीक किया जाए

पता चलता है कि उफ़ एक कर्नेल बग के कारण होता है जिसे 76da0704507bbc51875013f6557877ab308cfd0a द्वारा तय किया गया है:

ipv6: NETDEV_UNREGISTER के लिए केवल एक बार ip6_route_dev_notify() पर कॉल करें

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76da0704507bbc51875013f6557877ab308cfd0a
(यह केवल कर्नेल पैनिक को ठीक करता है, न कि "कर्नेल: unregister_netdevice: लो के मुक्त होने की प्रतीक्षा में। उपयोग गणना = 2" समस्या।)

(इसे यहां दोबारा दोहराएं, क्योंकि गिटहब पुरानी टिप्पणियों को छुपा रहा है)

अगर आप यहां आ रहे हैं

यहां जिस मुद्दे पर चर्चा की जा रही है वह एक कर्नेल बग है और अभी तक पूरी तरह से ठीक नहीं किया गया है। कुछ पैच कर्नेल में चले गए जो इस मुद्दे की _some_ घटनाओं को ठीक करते हैं, लेकिन अन्य अभी तक हल नहीं हुए हैं।

ऐसे कई विकल्प हैं जो _some_ स्थितियों के लिए मदद कर सकते हैं, लेकिन सभी के लिए नहीं (फिर से, यह उन मुद्दों का संयोजन है जो एक ही त्रुटि को ट्रिगर करते हैं)

"मेरे पास यह भी है" टिप्पणी न छोड़ें

"मेरे पास यह भी है" बग को हल करने में मदद नहीं करता है। केवल एक टिप्पणी छोड़ें यदि आपके पास ऐसी जानकारी है जो समस्या को हल करने में मदद कर सकती है (इस मामले में, कर्नेल अपस्ट्रीम को पैच प्रदान करना सबसे अच्छा कदम हो सकता है)।

यदि आप यह बताना चाहते यह समस्या है तो शीर्ष विवरण में "अंगूठे ऊपर" बटन का उपयोग करें:

यदि आप अपडेट के बारे में सूचित रहना चाहते हैं तो _सदस्यता बटन_ का उपयोग करें।

यहां प्रत्येक टिप्पणी ३००० से अधिक लोगों को एक ई-मेल/अधिसूचना भेजती है, मैं इस मुद्दे पर बातचीत को लॉक नहीं करना चाहता, क्योंकि यह अभी तक हल नहीं हुआ है, लेकिन अगर आप इसे अनदेखा करते हैं तो आपको मजबूर होना पड़ सकता है।

मैं उन टिप्पणियों को हटा दूंगा जो (थोड़ा) थ्रेड को छोटा करने के लिए उपयोगी जानकारी नहीं जोड़ती हैं

अगर आप इस समस्या को हल करने में मदद करना चाहते हैं

• पूरा सूत्र पढ़ें; यह लंबा है, और जीथब टिप्पणियों को छुपाता है (इसलिए आपको उन्हें फिर से दृश्यमान बनाने के लिए क्लिक करना होगा)। अगर इस सूत्र में पहले से मौजूद जानकारी है तो बहुत कुछ है जो संभवतः आपकी मदद कर सकता है
• उपयोगी जानकारी के लिए इस टिप्पणी को https://github.com/moby/moby/issues/5618#issuecomment -316297818 (और उस समय के आसपास की टिप्पणियां) पढ़ें।

धन्यवाद!

मेरा मानना ​​है कि मैंने इस मुद्दे को ठीक कर लिया है, कम से कम जब कर्नेल टीसीपी सॉकेट कनेक्शन के कारण होता है। उबंटू के लिए टेस्ट कर्नेल उपलब्ध हैं और अगर वे यहां किसी के लिए मदद/ठीक करते हैं तो मुझे फीडबैक अच्छा लगेगा। पैच अपस्ट्रीम सबमिट किया गया है; अधिक विवरण एलपी बग में हैं:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/comments/46

उत्सव खराब करने के लिए खेद है, लेकिन हम इस मुद्दे को पुन: प्रस्तुत करने में सक्षम थे। अब हम इस पर @ddstreet के साथ https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/ पर काम कर रहे हैं।

क्या कोई उपाय नहीं हैं?

होस्ट नेटवर्किंग का उपयोग करें (जो कंटेनरों के अधिकांश मूल्य को नष्ट कर देता है, लेकिन आप वहां जाते हैं)।

@ pumba-lt हमारे पास यह समस्या लगभग 1.5yrs पहले थी, लगभग 1yr पहले मैंने ipv6 को कर्नेल स्तर (sysctl नहीं) पर अक्षम कर दिया था और एक बार भी समस्या नहीं हुई थी। 48 ब्लेड का क्लस्टर चलाना।

आम तौर पर: /etc/default/grub
GRUB_CMDLINE_LINUX="xxxxx ipv6.disable=1"

हालांकि, मैं पीएक्सई बूट का उपयोग करता हूं, इसलिए मेरी पीएक्सई कॉन्फ़िगरेशन में है:

      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

मैं आपको विश्वास दिलाता हूं, आप इस मुद्दे को दोबारा नहीं देखेंगे।

कृपया सभी लोग समझें कि यह एक सामान्य लक्षण है जिसके कई कारण हैं। इससे बचने के लिए आपने जो काम किया है वह किसी और के लिए काम नहीं कर सकता है।

मैं पुष्टि कर सकता हूं कि बूट पर आईपीवी 6 को अक्षम करने के बाद हमारे मुद्दों को हल किया गया था (फ्रंट ग्रब की कॉन्फ़िगरेशन फ़ाइल)। 7 नोड क्लस्टर में कई समस्याएं थीं, अब सुचारू रूप से चलती हैं।

मुझे याद नहीं है कि मुझे समाधान कहां मिला, या क्या मैंने इसे स्वयं ढूंढ लिया, वैसे भी, धन्यवाद @qrpike दूसरों को यह सुझाव

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

प्रतिबद्ध edaafa805e0f9d09560a4892790b8e19cab8bf09
लेखक: डैन स्ट्रीटमैन [email protected]
दिनांक: गुरु जनवरी १८ १६:१४:२६ 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]>

netns में SCTP का उपयोग करने से भी यह ट्रिगर हो सकता है, 4.16-rc1 में सुधार करता है:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a31a6b19f9ddf498c81f5c9b089742b7472a6f8
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=957d761cf91cdbb175ad7d8f5472336a4d54dbf2

अभी भी खुशी है "unregister_netdevice: eth0 के मुक्त होने की प्रतीक्षा कर रहा है। उपयोग गणना = 1" हालांकि मैंने कर्नेल संस्करण को 4.4.118 में अपग्रेड किया है, और docker संस्करण 17.09.1-ce ，शायद मुझे कर्नेल स्तर पर ipv6 को अक्षम करने का प्रयास करना चाहिए। आशा है कि यह बादल काम करेगा।

@ wuming5569 कृपया मुझे बताएं कि क्या यह आपके लिए linux के उस संस्करण के साथ काम करता है

@ wuming5569 हो सकता है, कर्नेल 4.4.114 को अपग्रेड करें "unregister_netdevice: lo के मुक्त होने की प्रतीक्षा कर रहा है। यूसेज काउंट = 1", "unregister_netdevice: eth0 के फ्री होने की प्रतीक्षा में। यूसेज काउंट = 1" के लिए नहीं।
मैंने उत्पादन में परीक्षण किया।
@ddstreet यह एक प्रतिक्रिया है, कोई मदद?

@ wuming5569 जैसा कि ऊपर उल्लेख किया है, संदेशों उन्हें स्वयं सौम्य हैं, लेकिन वे अंत में गिरी फांसी हो सकती है। क्या आपका कर्नेल हैंग होता है और यदि हां, तो आपका नेटवर्क पैटर्न क्या है, यानी आपके कंटेनर किस प्रकार की नेटवर्किंग करते हैं?

CentOS पर एक ही समस्या का अनुभव किया। मेरा कर्नेल 3.10.0-693.17.1.el7.x86_64 है। लेकिन, मुझे syslog में समान स्टैक ट्रेस नहीं मिला।

Centos7 कर्नेल 3.10.0-514.21.1.el7.x86_64 और docker 18.03.0-ce पर समान

@danielefranceschi मैं आपको नवीनतम CentOS कर्नेल (कम से कम 3.10.0-693) में अपग्रेड करने की सलाह

@alexhexabeam 3.10.0-693 त्रुटिहीन काम करता प्रतीत होता है, tnx :)

CentOS7 कर्नेल 4.16.0-1.el7.elrepo.x86_64 और docker 18.03.0-ce पर समान

इसने दुर्घटना से पहले हफ्तों तक काम किया और जब ऊपर उठने की कोशिश की गई, तो यह पूरी तरह से अटक गया।

समस्या कर्नेल के साथ भी हुई 3.10.0-693.21.1.el7

मैं पुष्टि कर सकता हूं कि यह इस पर भी होता है:

लिनक्स 3.10.0-693.17.1.el7.x86_64
Red Hat Enterprise Linux सर्वर रिलीज 7.4 (Maipo)

मैं एक निश्चित मात्रा में लोड होने पर "सर्विस डॉकर रीस्टार्ट" करके इसे पुन: पेश कर सकता हूं।

@ wuming5569 क्या आपने इस समस्या को ठीक कर दिया है? आपका नेटवर्क प्रकार क्या है? हम हफ्तों से इस मुद्दे से भ्रमित हैं।
क्या आपके पास वीचैट खाता है?

4admin2root, आपके द्वारा बताए गए सुधार को देखते हुए, https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.114 ,

क्या डॉकर डेमॉन के लिए यूजरलैंड प्रॉक्सी को निष्क्रिय करना सुरक्षित है, यदि उचित हाल ही में कर्नेल स्थापित है? यह बहुत स्पष्ट नहीं है कि यह कहाँ से है

https://github.com/moby/moby/issues/8356
https://github.com/moby/moby/issues/11185

चूंकि दोनों कर्नेल फिक्स से पुराने हैं

शुक्रिया

हम हफ्तों से इस मुद्दे से भ्रमित हैं।
लिनक्स 3.10.0-693.17.1.el7.x86_64
CentOS Linux रिलीज़ 7.4.1708 (कोर)

क्या कोई पुष्टि कर सकता है कि नवीनतम 4.14 कर्नेल में यह समस्या है? ऐसा लगता है जैसे नहीं है। इंटरनेट पर किसी ने भी 4.14 कर्नेल के साथ इस समस्या का सामना नहीं किया।

मैं इसे 4.15.15-1 कर्नेल में देखता हूं, Centos7

परिवर्तन लॉग को देखते हुए, https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.15.8 में एससीटीपी के लिए एक फिक्स है, लेकिन टीसीपी नहीं। तो आप नवीनतम 4.14.1 को आज़माना पसंद कर सकते हैं।

• 4.15.18 भी इस बग के साथ मदद नहीं करता है
• ipv6 को अक्षम करने से भी मदद नहीं मिलती है

हमने अब 4.16.13 में अपग्रेड किया है। अवलोकन कर रहा है। यह बग हमें प्रति सप्ताह केवल एक बार एक नोड पर मार रहा था।

क्या आपने ipv6 को ग्रब बूट पैराम्स या sysctl में अक्षम किया है? केवल बूट पैरा काम करेगा। Sysctl इसे ठीक नहीं करेगा।

4 जून, 2018 को दोपहर 12:09:53 बजे, सर्गेई प्रोनिन ( नोटिफिकेशन @github.com (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 को अक्षम करने से आपके मामले में मदद मिली है? कर्नेल संस्करण, k8s संस्करण, CNI, docker संस्करण आदि।

@komljen मैं पिछले 2 वर्षों से एक भी घटना के बिना 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.42-कोरोस पर अभी तक इस समस्या का सामना नहीं करना पड़ा है

Centos 7.5 4.17.3-1 कर्नेल के साथ, अभी भी समस्या है।

पर्यावरण:
कुबेरनेट्स 1.10.4
डॉकर 13.1
फलालैन नेटवर्क प्लगइन के साथ।

लॉग :
[८९.७९०९०७] IPv6: ADDRCONF(NETDEV_UP): eth0: लिंक तैयार नहीं है
[८९.७९८५२३] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: लिंक तैयार हो जाता है
[८९.७९९६२३] cni0: पोर्ट 8(vethb8a93c6f) अवरुद्ध अवस्था में प्रवेश कर गया
[८९.८००५४७] cni0: पोर्ट 8(vethb8a93c6f) अक्षम अवस्था में प्रवेश किया
[८९.८०१४७१] डिवाइस vethb8a93c6f ने विशिष्ट मोड में प्रवेश किया
[८९.८०२३२३] cni0: पोर्ट 8(vethb8a93c6f) अवरुद्ध अवस्था में प्रवेश कर गया
[८९.८०३२००] cni0: पोर्ट 8(vethb8a93c6f) अग्रेषण स्थिति में प्रवेश किया

कर्नेल: unregister_netdevice : लो के मुक्त होने की प्रतीक्षा कर रहा है। उपयोग गणना = 1。

अभी :
नोड आईपी तक पहुंच सकता है, लेकिन एसएसएच जैसी किसी भी नेटवर्क सेवाओं का उपयोग नहीं कर सकता ...

यहां के लक्षण कई अन्य स्थानों की रिपोर्टों के समान हैं। सभी का संबंध नेटवर्क नेमस्पेस से है। क्या इसमें भाग लेने वाले लोग कृपया देख सकते हैं कि क्या unshare -n हैंग होता है, और यदि ऐसा है, तो किसी अन्य टर्मिनल से, cat /proc/$pid/stack अनशेयर प्रक्रिया को यह देखने के लिए करें कि क्या यह copy_net_ns() में हैंग होता है? यह यहां पाए गए कुछ बैकट्रैस सहित कई मुद्दों के लिए एक सामान्य भाजक प्रतीत होता है। ४.१६ और ४.१८ के बीच किरिल तखाई द्वारा संबंधित लॉकिंग को रिफैक्टिंग करते हुए कई पैच किए गए हैं। प्रभावित डिस्ट्रो/कर्नेल पैकेज अनुरक्षकों को शायद उन्हें स्थिर गुठली पर लागू/बैकपोर्ट करने पर ध्यान देना चाहिए और देखें कि क्या इससे मदद मिलती है।
यह भी देखें: 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 का परीक्षण करना अच्छा होगा, खासकर यदि आप इसे कम या ज्यादा मज़बूती से ट्रिगर कर सकते हैं, जैसा कि मैंने देखा है कि ऐसे कई लोग हैं जहाँ कर्नेल संस्करण बदलने से भी ऐसा होने की संभावना बदल गई है। ढेर सारा।

कुबेरनेट्स के साथ मेरे पास यह समस्या थी और नवीनतम कोरओएस स्थिर रिलीज पर स्विच करने के बाद - 1745.7.0 मुद्दा चला गया है:

• कर्नेल: 4.14.48
• डोकर: १८.०३.१

CentOS 7 पर एक ही मुद्दा

• कर्नेल: 4.11.1-1.el7.elrepo.x86_64
• डोकर: १७.१२.०-सीई

@Blub इसे CoreOS 1688.5.3, कर्नेल 4.14.32 पर देख रहा है

ip-10-72-101-86 core # cat /proc/59515/stack
[<ffffffff9a4df14e>] copy_net_ns+0xae/0x200
[<ffffffff9a09519c>] create_new_namespaces+0x11c/0x1b0
[<ffffffff9a0953a9>] unshare_nsproxy_namespaces+0x59/0xb0
[<ffffffff9a07418d>] SyS_unshare+0x1ed/0x3b0
[<ffffffff9a003977>] do_syscall_64+0x67/0x120
[<ffffffff9a800081>] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[<ffffffffffffffff>] 0xffffffffffffffff

सिद्धांत रूप में एक या एक से अधिक अन्य निशान हो सकते हैं जिनमें net_namespace.c के कार्यों में से एक शामिल हो, net_mutex ( cleanup_net , net_ns_barrier , net_ns_init , {,un}register_pernet_{subsys,device} )। स्थिर गुठली के लिए यह निश्चित रूप से बहुत आसान होगा यदि 4.18 से सभी लॉकिंग परिवर्तनों को बैकपोर्ट करने की तुलना में एक विशेष चीज को इस तरह से तय किया जा सकता है जिसे तय किया जा सकता है। लेकिन अभी तक मैंने ऐसा कोई निशान नहीं देखा है जो मूल कारण की ओर ले जाए। मुझे नहीं पता कि यह मदद करेगा, लेकिन हो सकता है कि समस्या के प्रकट होने पर उपरोक्त कार्यों के साथ अन्य /proc/*/stack s दिखाई दें?

वही मुद्दा ! और मेरा env डेबियन है 8

आरएचईएल, झुंड, १८.०३.०-सीई

1. ssh . के माध्यम से प्रबंधक नोड से जुड़ना

2. प्रबंधक नोड पर कंटेनर को मैन्युअल रूप से प्रारंभ करना:

   sudo docker run -it -v /import:/temp/eximport -v /home/myUser:/temp/exhome docker.repo.myHost/ fedora:23 /bin/bash

3. कुछ समय बाद कुछ नहीं करना:

   [ रूट@8 a9857c25919 myDir]#
   syslogd@se1-shub-t002 जुलाई 19
   कर्नेल: unregister_netdevice : लो के मुक्त होने की प्रतीक्षा कर रहा है। उपयोग गिनती = 1

मिनटों के बाद मैं प्रबंधक नोड के कंसोल पर वापस आ गया हूं और प्रारंभ किया गया कंटेनर अब नहीं चल रहा है।

क्या यह एक ही मुद्दे का वर्णन करता है या यह एक और "समस्या सूट" है?

अग्रिम में THX!

अपडेट करें
यह सीधे ssh कंसोल (झुंड प्रबंधक बैश पर) पर भी होता है।

अपडेट करें
मेजबान मशीन (झुंड में एक प्रबंधक नोड):
लिनक्स [MACHINENNAME] 3.10.0-514.2.2.el7.x86_64 #1 एसएमपी बुध नवंबर 16 13:15:13 ईएसटी 2016 x86_64 x86_64 x86_64 जीएनयू/लिनक्स

अगर यह कुछ समय बाद ठीक नहीं होता है, तो यह एक अलग समस्या है।

CentOS7.5 कर्नेल 3.10.0-693.el7.x86_64 और docker 1.13.1 . पर समान

वही समस्या OEL 7.5
अनाम -ए
4.1.12-124.16.1.el7uek.x86_64 #2 एसएमपी सोम जून 11 20:09:51 पीडीटी 2018 x86_64 x86_64 x86_64 जीएनयू/लिनक्स
डॉकटर जानकारी
कंटेनर: 9
चल रहा है: 5
रुका हुआ: 0
रुक गया: 4
छवियां: 6
सर्वर संस्करण: १७.०६.२-ओएल

dmesg
[२२३८३७४.७१८८८९] unregister_netdevice: लो के मुक्त होने की प्रतीक्षा में। उपयोग गिनती = 1
[२२३८३८४.७६२८१३] unregister_netdevice: लो के फ्री होने का इंतजार। उपयोग गिनती = 1
[२२३८३९२.७९२५८५] eth0: vethbed6d59 . से नाम बदला गया

(इसे https://github.com/moby/moby/issues/5618#issuecomment-351942943 यहां फिर से दोहराएं, क्योंकि गिटहब पुरानी टिप्पणियों को छुपा रहा है)

अगर आप यहां आ रहे हैं

यहां जिस मुद्दे पर चर्चा की जा रही है वह एक कर्नेल बग है और अभी तक पूरी तरह से ठीक नहीं किया गया है। कुछ पैच कर्नेल में चले गए जो इस मुद्दे की _some_ घटनाओं को ठीक करते हैं, लेकिन अन्य अभी तक हल नहीं हुए हैं।

ऐसे कई विकल्प हैं जो _some_ स्थितियों के लिए मदद कर सकते हैं, लेकिन सभी के लिए नहीं (फिर से, यह उन मुद्दों का संयोजन है जो एक ही त्रुटि को ट्रिगर करते हैं)

"unregister_netdevice: वेटिंग फॉर लो टु फ्री" एरर अपने आप में बग नहीं है

यदि कर्नेल क्रैश _after_ है तो यह एक बग है (नीचे देखें)

"मेरे पास यह भी है" टिप्पणी न छोड़ें

"मेरे पास यह भी है" बग को हल करने में मदद नहीं करता है। केवल एक टिप्पणी छोड़ें यदि आपके पास ऐसी जानकारी है जो समस्या को हल करने में मदद कर सकती है (इस मामले में, कर्नेल अपस्ट्रीम को पैच प्रदान करना सबसे अच्छा कदम हो सकता है)।

यदि आप यह बताना चाहते यह समस्या है तो शीर्ष विवरण में "अंगूठे ऊपर" बटन का उपयोग करें:

यदि आप अपडेट के बारे में सूचित रहना चाहते हैं तो _सदस्यता बटन_ का उपयोग करें।

यहां प्रत्येक टिप्पणी ३००० से अधिक लोगों को एक ई-मेल/अधिसूचना भेजती है, मैं इस मुद्दे पर बातचीत को लॉक नहीं करना चाहता, क्योंकि यह अभी तक हल नहीं हुआ है, लेकिन अगर आप इसे अनदेखा करते हैं तो आपको मजबूर होना पड़ सकता है।

मैं उन टिप्पणियों को हटा दूंगा जो (थोड़ा) थ्रेड को छोटा करने के लिए उपयोगी जानकारी नहीं जोड़ती हैं

अगर आप इस समस्या को हल करने में मदद करना चाहते हैं

• छिपी हुई टिप्पणियों सहित संपूर्ण सूत्र पढ़ें ; यह लंबा है, और जीथब टिप्पणियों को छुपाता है (इसलिए आपको उन्हें फिर से दृश्यमान बनाने के लिए क्लिक करना होगा)। अगर इस सूत्र में पहले से मौजूद जानकारी है तो बहुत कुछ है जो संभवतः आपकी मदद कर सकता है

• उपयोगी जानकारी के लिए इस टिप्पणी को https://github.com/moby/moby/issues/5618#issuecomment -316297818 (और उस समय के आसपास की टिप्पणियां) पढ़ें:

स्पष्ट होने के लिए, संदेश स्वयं सौम्य है , ओपी द्वारा रिपोर्ट किए गए संदेशों के बाद यह कर्नेल क्रैश है जो नहीं है।

कोड में टिप्पणी , जहां से यह संदेश आ रहा है, बताता है कि क्या हो रहा है। मूल रूप से प्रत्येक उपयोगकर्ता, जैसे कि आईपी स्टैक) एक नेटवर्क डिवाइस का (जैसे कंटेनर के अंदर veth जोड़ी का अंत) नेटवर्क डिवाइस का उपयोग करते समय नेटवर्क डिवाइस संरचना में एक संदर्भ गणना में वृद्धि करता है। जब डिवाइस को हटा दिया जाता है (उदाहरण के लिए, जब कंटेनर को हटा दिया जाता है) तो प्रत्येक उपयोगकर्ता को सूचित किया जाता है ताकि वे संदर्भ संख्या को कम करने से पहले कुछ सफाई (जैसे खुले सॉकेट आदि को बंद करना) कर सकें। क्योंकि इस सफाई में कुछ समय लग सकता है, विशेष रूप से भारी भार (बहुत सारे इंटरफ़ेस, बहुत सारे कनेक्शन आदि) के तहत, कर्नेल संदेश को यहां एक बार में प्रिंट कर सकता है।

यदि संजाल युक्ति का कोई उपयोक्ता संदर्भ संख्या में कभी कमी नहीं करता है, तो कर्नेल का कोई अन्य भाग यह निर्धारित करेगा कि सफाई के लिए प्रतीक्षा कर रहा कार्य अटक गया है और यह दुर्घटनाग्रस्त हो जाएगा। यह केवल यह क्रैश है जो कर्नेल बग को इंगित करता है (कुछ उपयोगकर्ता, कुछ कोड पथ के माध्यम से, संदर्भ संख्या में कमी नहीं करते हैं)। ऐसे कई बग हैं और उन्हें आधुनिक कर्नेल में ठीक किया गया है (और संभवत: पुराने वाले को वापस पोर्ट किया गया है)। मैंने इस तरह के क्रैश को ट्रिगर करने के लिए कुछ तनाव परीक्षण (और उन्हें लिखना जारी रखा) लिखा है, लेकिन आधुनिक कर्नेल पर पुन: पेश करने में सक्षम नहीं हूं (हालांकि मैं उपरोक्त संदेश करता हूं)।

* कृपया इस मुद्दे पर केवल तभी रिपोर्ट करें जब आपका कर्नेल वास्तव में क्रैश हो जाता है *, और तब हमें इसमें बहुत दिलचस्पी होगी:

• कर्नेल संस्करण ( uname -r का आउटपुट)
• लिनक्स वितरण/संस्करण
• क्या आप अपने Linux विक्रेता के नवीनतम कर्नेल संस्करण पर हैं?
• नेटवर्क सेटअप (ब्रिज, ओवरले, IPv4, IPv6, आदि)
• कार्यभार का विवरण (किस प्रकार के कंटेनर, किस प्रकार का नेटवर्क लोड, आदि)
• और आदर्श रूप से एक साधारण प्रजनन

धन्यवाद!

क्या आप लोग किसी भी सीमा के तहत डॉकटर चला रहे हैं? जैसे ulimits, cgroups आदि...

नए सिस्टमड की एक डिफ़ॉल्ट सीमा होती है, भले ही आपने इसे सेट न किया हो। मैंने चीजों को असीमित पर सेट किया है और तब से यह समस्या नहीं हुई है (31 दिनों से देख रहा हूं)।

मेरे पास कई वातावरणों में एक ही समस्या थी और मेरा समाधान फ़ायरवॉल बंद कर दिया गया था। ऐसा दोबारा नहीं हुआ है, अभी के लिए

रेल 7.5 - 3.10.0-862.3.2.el7.x86_64
डॉकर 1.13

@dElogics सिस्टमड के किस संस्करण को "नया" माना जाता है? क्या यह डिफ़ॉल्ट सीमा CentOS 7.5 सिस्टमड में सक्षम है?

साथ ही, जब आप पूछते हैं कि क्या हम किसी भी सीमा के तहत डॉकर चला रहे हैं, तो क्या आपका मतलब डॉकर डिमन या व्यक्तिगत कंटेनर है?

डॉकर डेमन। डेबियन 9 (232-25) के रूप में सिस्टमड।

आरएचईएल के बारे में निश्चित नहीं है, लेकिन मैंने व्यक्तिगत रूप से इस मुद्दे को आरएचईएल पर भी देखा है। मैं LimitNOFILE=1048576, LimitNPROC=infinity, LimitCORE=infinity, TasksMax=infinity सेट करूंगा

कर्नेल: unregister_netdevice: eth0 के मुक्त होने की प्रतीक्षा कर रहा है। उपयोग गणना = ३
कर्नेल 4.4.146-1.el7.elrepo.x86_64
लिनक्स संस्करण सेंटोस लिनक्स रिलीज 7.4.1708 (कोर)
ब्रिज मोड

मेरे पास एक ही समस्या थी, मैं क्या कर सकता हूँ?

वही मुद्दा:

CentOS Linux रिलीज़ 7.5.1804 (कोर)
डॉकर संस्करण 18.06.1-सीई, निर्माण e68fc7a
कर्नेल संस्करण: 3.10.0-693.el7.x86_64

इसी तरह का मुद्दा मैं यहां मिला हूं ...
क्या कोई चाल है जो मैं अभी प्रदर्शन कर सकता हूं? कृपया मेरी मदद करें...

सेंटोस 7.0.1406
[ रूट@zjsm-slavexx आदि]# uname -a
लिनक्स zjsm-slave08 3.10.0-123.el7.x86_64 #1 एसएमपी सोम जून 30 12:09:22 यूटीसी 2014 x86_64 x86_64 x86_64 जीएनयू/लिनक्स
[ रूट@zjsm-slavexx आदि]# बिल्ली/आदि/सेंटोस-रिलीज़
CentOS Linux रिलीज़ 7.0.1406 (कोर)

डॉकर जानकारी:
[ रूट@zjsm-slavexx ~]# डॉकर संस्करण
ग्राहक:
संस्करण: १७.०४.०-सीई
एपीआई संस्करण: 1.28
गो संस्करण: go1.7.5
गिट प्रतिबद्ध: 4845c56
निर्मित: सोम अप्रैल 3 18:01:50 2017
ओएस/आर्क: linux/amd64

सर्वर:
संस्करण: १७.०४.०-सीई
एपीआई संस्करण: 1.28 (न्यूनतम संस्करण 1.12)
गो संस्करण: go1.7.5
गिट प्रतिबद्ध: 4845c56
निर्मित: सोम अप्रैल 3 18:01:50 2017
ओएस/आर्क: linux/amd64
प्रायोगिक: असत्य

CentOS Linux 7.2.1511 कर्नेल जारी करता है: 3.10.0-327.el7.x86_64
समान समस्या

मैंने इस मुद्दे का प्रयोग किया है।

Ubuntu 16.04.3 LTS
Kernel 4.4.0-87-generic #110-Ubuntu SMP Tue Jul 18 12:55:35 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Docker version:
Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:42:18 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:56 2017
 OS/Arch:      linux/amd64
 Experimental: false

@thaJeztah , शायद आपको अपनी टिप्पणी मूल पोस्ट के शीर्ष पर जोड़नी चाहिए, क्योंकि लोग अभी भी इसे अनदेखा कर रहे हैं।

$ docker network ls
NETWORK ID          NAME                     DRIVER              SCOPE
b3fc47abfff2        bridge                   bridge              local
f9474559ede8        dockerfile_cluster_net   bridge              local
ef999de68a96        host                     host                local
e7b41d23674c        none                     null                local
$ docker network rm f9474559ede8 

ठीक कर दिया।

@hzbd आपका मतलब उपयोगकर्ता द्वारा परिभाषित ब्रिज नेटवर्क को हटाना है? क्या आपने यह जानने के लिए और अधिक खुदाई करने की कोशिश की है कि क्यों? कृपया मुझे बताएं कि क्या आपने ऐसा किया है। मैं वास्तव में उसकी सराहना करता हूँ।

ठीक होने की प्रतीक्षा में

क्या आप लोग किसी भी सीमा के तहत डॉकटर चला रहे हैं? जैसे ulimits, cgroups आदि...

नए सिस्टमड की एक डिफ़ॉल्ट सीमा होती है, भले ही आपने इसे सेट न किया हो। मैंने चीजों को असीमित पर सेट किया है और तब से यह समस्या नहीं हुई है (31 दिनों से देख रहा हूं)।

ठीक है, यह बग अभी भी होता है, लेकिन संभावना कम हो गई है।

मुझे लगता है कि यदि कंटेनर इनायत से बंद हो जाते हैं (PID 1 मौजूद है ()), तो यह बग हमें परेशान नहीं करेगा।

@dElogics हमें बताने के लिए धन्यवाद, क्या आप कृपया हमें दिखा सकते हैं कि आपने इस सिस्टमड सीमा को असीमित करने के लिए कौन से आदेश चलाए। मुझे यह भी कोशिश करना पसंद है।

@dElogics हमें बताने के लिए धन्यवाद, क्या आप कृपया हमें दिखा सकते हैं कि आपने इस सिस्टमड सीमा को असीमित करने के लिए कौन से आदेश चलाए। मुझे यह भी कोशिश करना पसंद है।

आपको docker की 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 या नए में यह समस्या है?

यह डैन स्ट्रीटमैन फिक्स (https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d) को पहले 4.15 कर्नेल संस्करण में शामिल किया गया है और ऐसा लगता है कि कम से कम किसी के लिए ऐसा नहीं हो रहा है क्योंकि वे 4.16 (https: /) में अपग्रेड हुए हैं। /github.com/kubernetes/kubernetes/issues/64743#issuecomment-436839647

क्या किसी ने इसे आजमाया?

@victorgp हम अभी भी 4.15 कर्नेल के साथ समस्या का अनुभव करते हैं। हम यहां रिपोर्ट करेंगे जब हमने 4.16 कर्नेल के साथ परीक्षण किया है (उम्मीद है कि कुछ हफ्तों में)।

हमने कर्नेल संस्करण का उपयोग किया

मेरे पिछले प्रस्तावों में जोड़ने के लिए - एक शानदार ढंग से रोकने वाले कंटेनर (जो SIGTERM का जवाब देते हैं) इसे कभी भी ट्रिगर नहीं करते हैं।

होस्ट नामस्थान में कंटेनर चलाने का भी प्रयास करें (यदि यह आपके लिए स्वीकार्य है) जो पूरी तरह से समस्या का समाधान करता है।

@dElogics "होस्ट नेमस्पेस" से --privileged ?

@dElogics "होस्ट नेमस्पेस" से --privileged ?

नहीं, इसका मतलब है --नेटवर्क=होस्ट

कर्नेल 4.4.0 से 4.15.0 और डॉकटर 1.11.2 से 18.09 में अपग्रेड करने के बाद से समस्या गायब हो गई।

डॉक होस्ट के रूप में कार्य करने वाले VMs के एक बड़े बेड़े में हमारे पास यह समस्या दिन में कई बार (हमारे डॉकर उपयोग-मामले के साथ) दिखाई देती थी।
45 दिनों में और हम अब इसे नहीं देख रहे हैं।

भावी पीढ़ी के लिए, हंग डॉकर 1.11.2 w/ प्रिंटक का स्टैक-ट्रेस unregister_netdevice: waiting for vethXXXXX दिखा रहा है (जैसा कि हम हमेशा अपने बेड़े में सैकड़ों वीएम में देख रहे थे) http://paste पर पाया जा सकता है। 0xc820001980 )

goroutine 8809 [syscall, 542 minutes, locked to thread]:
syscall.Syscall6(0x2c, 0xd, 0xc822f3d200, 0x20, 0x0, 0xc822f3d1d4, 0xc, 0x20, 0xc82435fda0, 0x10)
    /usr/local/go/src/syscall/asm_linux_amd64.s:44 +0x5
syscall.sendto(0xd, 0xc822f3d200, 0x20, 0x20, 0x0, 0xc822f3d1d4, 0xc80000000c, 0x0, 0x0)
    /usr/local/go/src/syscall/zsyscall_linux_amd64.go:1729 +0x8c
syscall.Sendto(0xd, 0xc822f3d200, 0x20, 0x20, 0x0, 0x7faba31bded8, 0xc822f3d1c8, 0x0, 0x0)
    /usr/local/go/src/syscall/syscall_unix.go:258 +0xaf
github.com/vishvananda/netlink/nl.(*NetlinkSocket).Send(0xc822f3d1c0, 0xc82435fda0, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go:333 +0xd4
github.com/vishvananda/netlink/nl.(*NetlinkRequest).Execute(0xc82435fda0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go:215 +0x111
github.com/vishvananda/netlink.LinkDel(0x7fab9c2b15d8, 0xc825ef2240, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/vishvananda/netlink/link_linux.go:615 +0x16b
github.com/docker/libnetwork/drivers/bridge.(*driver).DeleteEndpoint(0xc8204aac30, 0xc8203ae780, 0x40, 0xc826e7b800, 0x40, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go:1060 +0x5cf
github.com/docker/libnetwork.(*endpoint).deleteEndpoint(0xc822945b00, 0xc82001ac00, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/endpoint.go:760 +0x261
github.com/docker/libnetwork.(*endpoint).Delete(0xc822945b00, 0x7fab9c2b0a00, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/endpoint.go:735 +0xbcb
github.com/docker/libnetwork.(*sandbox).delete(0xc8226bc780, 0xc8229f0600, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/sandbox.go:217 +0xd3f
github.com/docker/libnetwork.(*sandbox).Delete(0xc8226bc780, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/sandbox.go:175 +0x32
github.com/docker/docker/daemon.(*Daemon).releaseNetwork(0xc820001980, 0xc820e23a40)
    /usr/src/docker/.gopath/src/github.com/docker/docker/daemon/container_operations.go:732 +0x4f1
github.com/docker/docker/daemon.(*Daemon).Cleanup(0xc820001980, 0xc820e23a40)
    /usr/src/docker/.gopath/src/github.com/docker/docker/daemon/start.go:163 +0x62
github.com/docker/docker/daemon.(*Daemon).StateChanged(0xc820001980, 0xc825f9fac0, 0x40, 0xc824155b50, 0x4, 0x8900000000, 0x0, 0x0, 0x0, 0x0, ...)
    /usr/src/docker/.gopath/src/github.com/docker/docker/daemon/monitor.go:39 +0x60a
github.com/docker/docker/libcontainerd.(*container).handleEvent.func2()
    /usr/src/docker/.gopath/src/github.com/docker/docker/libcontainerd/container_linux.go:177 +0xa5
github.com/docker/docker/libcontainerd.(*queue).append.func1(0xc820073c01, 0xc820f9a2a0, 0xc821f3de20, 0xc822ddf9e0)
    /usr/src/docker/.gopath/src/github.com/docker/docker/libcontainerd/queue_linux.go:26 +0x47
created by github.com/docker/docker/libcontainerd.(*queue).append
    /usr/src/docker/.gopath/src/github.com/docker/docker/libcontainerd/queue_linux.go:28 +0x1da

इससे हम देख सकते हैं कि यह https://github.com/moby/moby/blob/v1.11.2/daemon/container_operations.go#L732 में लटका हुआ है।

जो हमें https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/sandbox.go#L175 पर इंगित करता है

और
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/endpoint.go#L760

जो libnetwork ब्रिज ड्राइवर में जाता है (भयानक विवरण देखें)
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go#L1057 -L1061

नेटलिंक पर जाना
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go#L601 -L617
https://github.com/moby/moby/blob/v1.11.2//vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go#L215

और अंततः उस नेटलिंक सॉकेट में, https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go#L333 पर कॉल

हमें लगता है कि कंटेनर को रोकते समय सामान्य रूप से बग होता है और एसकेबी को अभी भी नेटन्स में संदर्भित होने के कारण वीथ जारी नहीं किया जाता है, तो डॉकर 15 के बाद उस कंटेनर को किल जारी करता है। डॉकर डेमॉन इस स्थिति को इनायत से नहीं संभालता है, लेकिन अंततः बग कर्नेल में है। हम मानते हैं कि https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d (4.15 अपस्ट्रीम में स्वीकृत) और इससे जुड़े कमिटमेंट (कई हैं) एक शमन के रूप में कार्य करते हैं।

सामान्य तौर पर, कर्नेल का वह हिस्सा सुंदर जगह नहीं होता है।

इसके लायक क्या है ... हमने आरएचईएल लिनक्स कर्नेल को 3.10.0 से 4.17.11 तक अपग्रेड किया है। (कुबेरनेट्स क्लस्टर चालू)। अपग्रेड करने से पहले यह बग विभिन्न सर्वरों पर दैनिक आधार पर कई बार आ रहा था। अब तीन सप्ताह के लिए उन्नयन के साथ चल रहा है। बग केवल एक बार हुआ। तो मोटे तौर पर कहा जाता है कि 99% कम हो गया है।

@marckamerbeek आपने RHEL कर्नेल को एक समुदाय कर्नेल में अपडेट किया है? फिर यह अब समर्थित नहीं है।

@Beatlor CentOS उपयोगकर्ता ऐसा कर सकता है।

सेंटोस 7.2 में अभी भी यह समस्या है: कर्नेल: unregister_netdevice : लो के मुक्त होने की प्रतीक्षा कर रहा है। उपयोग गिनती = 1

@Beatlor RHEL ने हमारी बिल्कुल भी मदद नहीं की। कुछ बेकार समर्थन अनुबंध की तुलना में एक स्थिर उत्पादन वातावरण अधिक महत्वपूर्ण है। हम अभी भी ४.१७.११ को बहुत स्थिर चल रहे हैं। अब कोई बड़ा मुद्दा नहीं है।

@Beatlor RHEL ने हमारी बिल्कुल भी मदद नहीं की। कुछ बेकार समर्थन अनुबंध की तुलना में एक स्थिर उत्पादन वातावरण अधिक महत्वपूर्ण है। हम अभी भी ४.१७.११ को बहुत स्थिर चल रहे हैं। अब कोई बड़ा मुद्दा नहीं है।

हां, कर्नेल को 4.17.0-1.el7.elrepo.x86_64 में अपग्रेड करने के बाद भी मुझे यह समस्या नहीं हुई। मैंने पहले यह कोशिश की थी (4.4.x, 4.8, 4.14..) और यह असफल रहा है। ऐसा लगता है कि समस्या 4.17+ कर्नेल में दोबारा नहीं होगी।

सेंटोस 7.2 में अभी भी यह समस्या है: कर्नेल: unregister_netdevice : लो के मुक्त होने की प्रतीक्षा कर रहा है। उपयोग गिनती = 1

आप नवीनतम 4.19+ कर्नेल में अपग्रेड करने का प्रयास कर सकते हैं।

बस कुछ महीनों के लिए प्रतीक्षा करें और कोई 4.19 कर्नेल के बारे में भी शिकायत करेगा। बस इतिहास खुद को दोहरा रहा है।

हे सब लोग, अच्छी खबर!

यहां मेरी आखिरी टिप्पणी के बाद से (लेखन के समय, 17 दिन पहले) मुझे ये त्रुटियां दोबारा नहीं मिली हैं। मेरे सर्वर (उनमें से लगभग 30) कुछ पुराने पैकेजों के साथ ubuntu 14.04 चला रहे थे।

डॉकर-इंजन (1.7.1 से 1.8.3 तक) + कर्नेल अपग्रेड सहित पूर्ण सिस्टम अपग्रेड के बाद उबंटू के रेपो पर नवीनतम संभावित संस्करण में, मेरे सर्वर बिना किसी घटना के चल रहे हैं।

मैं

आप किस कर्नेल संस्करण को अपग्रेड कर रहे हैं?

शायद इससे संबंधित 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

इस मुद्दे के साथ देखे गए कर्नेल संस्करण

• आरएचईएल7 3.10.0-862
• 4.15.0
• 4.20.0

कर्नेल संस्करणों ने इस समस्या को ट्रिगर नहीं करने का दावा किया

• आरएचईएल7 3.10.0-957.10.1
• 4.19.12
• ४.१७.०
• 4.17.11

संबंधित कर्नेल करता है

• https://github.com/torvalds/linux/commit/f186ce61bb8235d80068c390dc2aad7ca427a4c2 - 4.12 से
• https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d - 4.15 से
• https://github.com/torvalds/linux/commit/ee60ad219f5c7c4fb2f047f88037770063ef785f - 5.1 से

मैं https://github.com/kubernetes/kubernetes/issues/70427#issuecomment -470681000 को चुनौती देता हूं क्योंकि हम 4.15.0 में इस w/हजारों VMs को नहीं देख रहे हैं, जबकि हम इसे 4.4 पर रोजाना दर्जनों बार देख रहे थे। 0, क्या 4.15.0 में इसकी और रिपोर्टें हैं?

मैं इस समस्या को डेबियन 9 स्ट्रेच ( 4.9.0-8-amd64 ) पर डॉकर चलाने वाली अपनी एक मशीन के साथ देख रहा हूं। मैं इस मुद्दे को डॉकर कंटेनर के भीतर डॉकर जेन के माध्यम से बनाई गई सुरंग के साथ अनुभव करता हूं और यह कर्नेल आतंक उत्पन्न करता है:

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

यहां हमारी डॉकर जानकारी है:

Client:
 Version:           18.09.3
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        774a1f4
 Built:             Thu Feb 28 06:34:04 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.3
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.8
  Git commit:       774a1f4
  Built:            Thu Feb 28 05:59:55 2019
  OS/Arch:          linux/amd64
  Experimental:     false

क्या किसी को पता है कि पूरी मशीन को पुनरारंभ किए बिना इसमें अस्थायी सुधार है या नहीं? जब हम इस समस्या का अनुभव करते हैं तो हम वास्तव में पूरी मशीन को पुनरारंभ नहीं करना पसंद करेंगे।

कुछ हद तक विषय से हटकर, हम टर्मिनल के भीतर भी कर्नेल पैनिक संदेशों को दबा नहीं सकते। मैंने dmesg -D और dmesg -n 1 । हालांकि, कोई भाग्य नहीं। क्या टर्मिनल के भीतर से इस प्रकार के कर्नेल पैनिक संदेशों को दबाने का कोई तरीका है? कमांड टाइप करने की कोशिश करना और उस संदेश को हर 10 सेकंड में पॉप अप करना कष्टप्रद है।

धन्यवाद।

क्या ये वेनिला कर्नेल हैं या बैकपोर्टेड फिक्स के साथ डिस्ट्रोस द्वारा भारी पैच किए गए हैं?

@pmoust मैं इसे सप्ताह में एक बार ubuntu 4.15.0-32 पर देखता हूं। निश्चित रूप से 4.4.0 . के बाद से बहुत बेहतर

@iavael यदि संदर्भ इसे प्रदान करता है तो मैं सारांश में डिस्ट्रो जानकारी सूचीबद्ध करने का प्रयास करूंगा।

किसी ने इस बग को 4.19 के साथ देखा?

किसी ने इस बग को 4.19 के साथ देखा?

https://github.com/kubernetes/kubernetes/issues/64743#issuecomment -451351435
https://github.com/kubernetes/kubernetes/issues/64743#issuecomment -461772385

यह जानकारी आपके काम आ सकती है।

@tankywoo @drpancake @egasimus @csabahenk @spiffytech @ibuildthecloud @sbward @jbalonso @rsampaio @MrMMorris @rsampaio @unclejack @chrisjstevenson @popsikle @fxposter @ scher200 @victorgp @jstangroome @ Xuexiang825 @dElogics @Nowaker @pmoust @marckamerbeek @Beatlor @warmchang @Jovons @ २४७६८७००९ @jwongz @ tao12345666333 @clkao कृपया इसे देखें

@tankywoo @drpancake @egasimus @csabahenk @spiffytech @ibuildthecloud @sbward @jbalonso @rsampaio @MrMMorris @rsampaio @unclejack @chrisjstevenson @popsikle @fxposter @ scher200 @victorgp @jstangroome @ Xuexiang825 @dElogics @Nowaker @pmoust @marckamerbeek @Beatlor @warmchang @Jovons @ 247687009 @jwongz @tao12345666333 @clkao कृपया इसे देखें

मैंने प्रलेखन का पालन किया, लेकिन मुझे अभी भी एक त्रुटि मिलती है।

[root<strong i="39">@node1</strong> ~]# kpatch list
Loaded patch modules:
livepatch_route [enabled]

Installed patch modules:
[root<strong i="40">@node1</strong> ~]#
Message from syslogd<strong i="41">@node1</strong> at May  7 15:59:11 ...
 kernel:unregister_netdevice: waiting for eth0 to become free. Usage count = 1

वह संदेश ही बग नहीं है; यह कर्नेल बाद में दुर्घटनाग्रस्त हो रहा है; https://github.com/moby/moby/issues/5618#issuecomment -407751991

@tankywoo @drpancake @egasimus @csabahenk @spiffytech @ibuildthecloud @sbward @jbalonso @rsampaio @MrMMorris @rsampaio @unclejack @chrisjstevenson @popsikle @fxposter @ scher200 @victorgp @jstangroome @ Xuexiang825 @dElogics @Nowaker @pmoust @marckamerbeek @Beatlor @warmchang @Jovons @ 247687009 @jwongz @tao12345666333 @clkao कृपया इसे देखें

मैंने प्रलेखन का पालन किया, लेकिन मुझे अभी भी एक त्रुटि मिलती है।

[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 ऑटो लोड हो सकता है।

हमें यह हमारी कंपनी में आज अचानक कई कुबेरनेट समूहों में मिला।

• 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 हम भी डेबियन चला रहे हैं। kpatch-build को काम पर लाने की कोशिश में मुझे बहुत सी समस्याओं का सामना करना पड़ा है। अगर मुझे कोई समाधान मिल जाए तो मैं आपको पोस्ट करता रहूंगा। किसी भी मामले में, क्या किसी के पास कोई अन्य समाधान है? क्या यह कर्नेल संस्करण 4.15 या 4.19 है जो समस्या को कम करता है? मैं पिछले एक हफ्ते से इसका जवाब खोजने की कोशिश कर रहा हूं और अभी भी कामयाब नहीं हुआ हूं।

@commixon हमारा अनुभव अभी भी वैसा ही है जैसा कि https://github.com/moby/moby/issues/5618#issuecomment -45580975 में बताया गया है, हजारों VMs के बेड़े में इस मुद्दे की कोई पुन: घटना नहीं w/ 4.15.0 पर कैनोनिकल द्वारा प्रदान किए गए कर्नेल के सामान्य, एडब्ल्यूएस-अनुकूलित और जीसीपी-अनुकूलित स्वाद। वेनिला 4.15.0 पर सीमित परीक्षण ने उनमें से कोई भी समस्या नहीं दिखाई, लेकिन पैमाने पर परीक्षण नहीं किया गया।

बहुत बहुत धन्यवाद @pmoust । उन्हें आजमाएंगे। किसी भी मामले में मैं डेबियन (एक साइड प्रोजेक्ट के रूप में) के साथ काम करने के लिए kpatch को पैच करने का प्रयास करूंगा और रुचि रखने वाले किसी भी व्यक्ति के लिए यहां अपडेट पोस्ट करूंगा।

@ethercflow @2rs2ts हम भी डेबियन चला रहे हैं। kpatch-build को काम पर लाने की कोशिश में मुझे बहुत सी समस्याओं का सामना करना पड़ा है। अगर मुझे कोई समाधान मिल जाए तो मैं आपको पोस्ट करता रहूंगा। किसी भी मामले में, क्या किसी के पास कोई अन्य समाधान है? क्या यह कर्नेल संस्करण 4.15 या 4.19 है जो समस्या को कम करता है? मैं पिछले एक हफ्ते से इसका जवाब खोजने की कोशिश कर रहा हूं और अभी भी कामयाब नहीं हुआ हूं।

आप 4.19 पर अपग्रेड कर सकते हैं। यह बैकपोर्ट में है।

BTW यह हमारे लिए यहाँ एक साल हो गया है। ;)

हमने वास्तव में बैकपोर्ट में 4.19 की कोशिश की, लेकिन अन्य क्षेत्रों में इसके कुछ प्रमुख प्रतिगमन थे (EC2 उदाहरण बस बेतरतीब ढंग से रिबूट होंगे और फिर स्टार्टअप पर नेटवर्किंग टूट जाएगी।) मान लीजिए कि हमें अगले स्थिर होने तक इससे निपटना होगा।

@ 2rs2ts पिछले 4 दिनों से हम बैकपोर्ट से 4.19 का उपयोग कर रहे हैं (ईसी 2 में) और हमने कोई समस्या नहीं देखी है। कर्नेल क्रैश समस्या बिल्कुल भी प्रकट नहीं हुई है और बाकी सब भी ठीक लगता है। मुझे नहीं लगता कि इससे कोई फर्क पड़ता है, लेकिन हमने अपनी डेबियन छवि कोप्स (https://github.com/kubernetes/kops/blob/master/docs/images.md#debian) द्वारा प्रदान की गई छवि पर आधारित है। हमने इस छवि में कर्नेल को अपडेट किया है न कि स्टॉक डेबियन को।

साथियों, मैं पिछले आधे साल से स्थिर संचालन के लिए 4.19 कर्नेल का उपयोग कर रहा हूं। मुझे आशा है कि आप स्थिरता का भी आनंद ले सकते हैं।

मेरे पास एक कंटेनर खुला 80 और 443 पोर्ट है, हर 2 सप्ताह में, एथेर कंप्यूटर एक्सेस कंटेनर 80 और . से
443 इनकार है

Centos7.3 कर्नेल संस्करण है:
लिनक्स ब्राउज़र1 3.10.0-514.el7.x86_64 #1 एसएमपी मंगल नवंबर 22 16:42:41 यूटीसी 2016 x86_64 x86_64 x86_64 जीएनयू/लिनक्स

रूट@ब्राउज़र1 ~]# डॉकर संस्करण
ग्राहक:
संस्करण: १८.०६.३-सीई
एपीआई संस्करण: 1.38
गो संस्करण: go1.10.4
गिट प्रतिबद्ध: d7080c1
निर्मित: बुध फरवरी 20 02:24:22 2019
ओएस/आर्क: linux/amd64
प्रायोगिक: असत्य

सर्वर:
यन्त्र:
संस्करण: १८.०६.३-सीई
एपीआई संस्करण: 1.38 (न्यूनतम संस्करण 1.12)
गो संस्करण: go1.10.3
गिट प्रतिबद्ध: d7080c1
निर्मित: बुध फरवरी 20 02:25:33 2019
ओएस/आर्क: linux/amd64
प्रायोगिक: असत्य
[ रूट@ब्राउज़र1 ~]#

डीएमएसजी:

[१०६३९५९.६३६७८५] unregister_netdevice: लो के मुक्त होने की प्रतीक्षा में। उपयोग गिनती = 1
[१०७१३४०.८८७५१२] br-af29e1edc1b8: पोर्ट ५(vethc2ac4f8) अक्षम अवस्था में प्रवेश किया
[१०७१३४०.८९१७५३] br-af29e1edc1b8: पोर्ट ५(vethc2ac4f8) अक्षम अवस्था में प्रवेश किया
[१०७१३४०.८९५११८] डिवाइस vethc2ac4f8 प्रोमिसस मोड छोड़ दिया
[१०७१३४०.८९५१३८] br-af29e1edc1b8: पोर्ट ५(vethc2ac4f8) अक्षम स्थिति में प्रवेश किया
[१०७१३४०.९९०५०५] डिवाइस veth5e4f161 ने विशिष्ट मोड में प्रवेश किया
[१०७१३४०.९९०८९७] IPv6: ADDRCONF(NETDEV_UP): veth5e4f161: लिंक तैयार नहीं है
[१०७१३४०.९९०९०४] br-af29e1edc1b8: पोर्ट 5(veth5e4f161) अग्रेषण स्थिति में प्रवेश किया
[१०७१३४०.९९०९२४] br-af29e1edc1b8: पोर्ट ५(veth5e4f161) अग्रेषण स्थिति में प्रवेश किया
[१०७१३४१.२३१४०५] IPv6: ADDRCONF(NETDEV_CHANGE): veth5e4f161: लिंक तैयार हो जाता है
[१०७१३५५.९९१७०१] br-af29e1edc1b8: पोर्ट ५(veth5e4f161) अग्रेषण स्थिति में प्रवेश किया
[१०७१५५१.५३३९०७] br-af29e1edc1b8: पोर्ट ५(veth5e4f161) अक्षम अवस्था में प्रवेश किया
[१०७१५५१.५३७५६४] br-af29e1edc1b8: पोर्ट ५(veth5e4f161) अक्षम अवस्था में प्रवेश किया
[१०७१५५१.५४०२९५] डिवाइस veth5e4f161 वाम विशिष्ट मोड
[१०७१५५१.५४०३१३] br-af29e1edc1b8: पोर्ट ५(veth5e4f161) अक्षम अवस्था में प्रवेश किया
[१०७१५५१.५७०९२४] डिवाइस veth8fd3a0a ने विशिष्ट मोड में प्रवेश किया
[1071551.571550] IPv6: ADDRCONF(NETDEV_UP): veth8fd3a0a: लिंक तैयार नहीं है
[1071551.571556] br-af29e1edc1b8: पोर्ट 5(veth8fd3a0a) अग्रेषण स्थिति में प्रवेश किया
[1071551.571582] br-af29e1edc1b8: पोर्ट 5(veth8fd3a0a) अग्रेषण स्थिति में प्रवेश किया
[१०७१५५१.८४१६५६] IPv6: ADDRCONF(NETDEV_CHANGE): veth8fd3a0a: लिंक तैयार हो जाता है
[१०७१५६६.६१३९९८] br-af29e1edc1b8: पोर्ट ५(veth8fd3a0a) अग्रेषण स्थिति में प्रवेश किया
[१०७१९२३.४६५०८२] br-af29e1edc1b8: पोर्ट ५(veth8fd3a0a) अक्षम अवस्था में प्रवेश किया
[१०७१९२३.४७०२१५] br-af29e1edc1b8: पोर्ट ५(veth8fd3a0a) अक्षम अवस्था में प्रवेश किया
[१०७१९२३.४७२८८८] डिवाइस veth8fd3a0a प्रोमिसस मोड छोड़ दिया
[१०७१९२३.४७२९०४] br-af29e1edc1b8: पोर्ट ५(veth8fd3a0a) अक्षम अवस्था में प्रवेश किया
[१०७१९२३.५०५५८०] डिवाइस veth9e693ae ने विशिष्ट मोड में प्रवेश किया
[१०७१९२३.५०५९१९] IPv6: ADDRCONF(NETDEV_UP): veth9e693ae: लिंक तैयार नहीं है
[१०७१९२३.५०९२५] br-af29e1edc1b8: पोर्ट ५(veth9e693ae) अग्रेषण स्थिति में प्रवेश किया
[१०७१९२३.५०५९४४] br-af29e1edc1b8: पोर्ट ५(veth9e693ae) अग्रेषण स्थिति में प्रवेश किया
[१०७१९२३.७८१६५८] IPv6: ADDRCONF(NETDEV_CHANGE): veth9e693ae: लिंक तैयार हो जाता है
[१०७१९३८.५१५०४४] br-af29e1edc1b8: पोर्ट ५(veth9e693ae) अग्रेषण स्थिति में प्रवेश किया

किसी ने इस बग को 4.19 के साथ देखा?

हां। मेरे पास कर्नेल 4.19.4-1.e17.elrep.x86_64 . पर समस्या है

नमस्ते,

मैं भी यह त्रुटि देख रहा हूं। क्या हमारे पास इस समस्या का कोई समाधान है? कर्नेल 3.10.0-514.26.2.el7.x86_64

[username@ip-10-1-4-64 ~]$
Message from syslogd@ip-10-1-4-64 at Jul 19 10:50:01 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Message from syslogd@ip-10-1-4-64 at Jul 19 10:50:48 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

यह समस्या अभी भी हो रही है :( कैसे ठीक करने के बारे में कोई अद्यतन/विचार नहीं है?

डेबियन स्ट्रेच पर हो रहा है। जब ऐसा हुआ तो मैं अपने जेनकींस कंटेनर को 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

इस मुद्दे को इस प्रतिबद्धता द्वारा हल किया गया है:
टोरवाल्ड्स / linux@ee60ad2
kpatch . का उपयोग करना

curl -SOL https://raw.githubusercontent.com/Aleishus/kdt/master/kpatchs/route.patch
kpatch-build -t vmlinux route.patch 
mkdir -p /var/lib/kpatch/${UNAME} 
cp -a livepatch-route.ko /var/lib/kpatch/${UNAME}
systemctl restart kpatch
kpatch list

यह 4.19.30 बजे के बाद होना चाहिए।

मुझे यकीन नहीं है कि torvalds / https://github.com/torvalds/linux/commit/deed49df7390d5239024199e249190328f1651e7 केवल 4.5.0 में जोड़ा गया था।