Ini terjadi ketika saya masuk ke wadah, dan tidak bisa keluar dengan Ctrl-c.
Sistem saya adalah Ubuntu 12.04
, kernel adalah 3.8.0-25-generic
.
versi buruh pelabuhan:
root@wutq-docker:~# docker version
Client version: 0.10.0
Client API version: 1.10
Go version (client): go1.2.1
Git commit (client): dc9c28f
Server version: 0.10.0
Server API version: 1.10
Git commit (server): dc9c28f
Go version (server): go1.2.1
Last stable version: 0.10.0
Saya telah menggunakan skrip https://raw.githubusercontent.com/dotcloud/docker/master/contrib/check-config.sh untuk memeriksa, dan baiklah.
Saya menonton syslog dan menemukan pesan ini:
May 6 11:30:33 wutq-docker kernel: [62365.889369] unregister_netdevice: waiting for lo to become free. Usage count = 3
May 6 11:30:44 wutq-docker kernel: [62376.108277] unregister_netdevice: waiting for lo to become free. Usage count = 3
May 6 11:30:54 wutq-docker kernel: [62386.327156] unregister_netdevice: waiting for lo to become free. Usage count = 3
May 6 11:31:02 wutq-docker kernel: [62394.423920] INFO: task docker:1024 blocked for more than 120 seconds.
May 6 11:31:02 wutq-docker kernel: [62394.424175] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 6 11:31:02 wutq-docker kernel: [62394.424505] docker D 0000000000000001 0 1024 1 0x00000004
May 6 11:31:02 wutq-docker kernel: [62394.424511] ffff880077793cb0 0000000000000082 ffffffffffffff04 ffffffff816df509
May 6 11:31:02 wutq-docker kernel: [62394.424517] ffff880077793fd8 ffff880077793fd8 ffff880077793fd8 0000000000013f40
May 6 11:31:02 wutq-docker kernel: [62394.424521] ffff88007c461740 ffff880076b1dd00 000080d081f06880 ffffffff81cbbda0
May 6 11:31:02 wutq-docker kernel: [62394.424526] Call Trace:
May 6 11:31:02 wutq-docker kernel: [62394.424668] [<ffffffff816df509>] ? __slab_alloc+0x28a/0x2b2
May 6 11:31:02 wutq-docker kernel: [62394.424700] [<ffffffff816f1849>] schedule+0x29/0x70
May 6 11:31:02 wutq-docker kernel: [62394.424705] [<ffffffff816f1afe>] schedule_preempt_disabled+0xe/0x10
May 6 11:31:02 wutq-docker kernel: [62394.424710] [<ffffffff816f0777>] __mutex_lock_slowpath+0xd7/0x150
May 6 11:31:02 wutq-docker kernel: [62394.424715] [<ffffffff815dc809>] ? copy_net_ns+0x69/0x130
May 6 11:31:02 wutq-docker kernel: [62394.424719] [<ffffffff815dc0b1>] ? net_alloc_generic+0x21/0x30
May 6 11:31:02 wutq-docker kernel: [62394.424724] [<ffffffff816f038a>] mutex_lock+0x2a/0x50
May 6 11:31:02 wutq-docker kernel: [62394.424727] [<ffffffff815dc82c>] copy_net_ns+0x8c/0x130
May 6 11:31:02 wutq-docker kernel: [62394.424733] [<ffffffff81084851>] create_new_namespaces+0x101/0x1b0
May 6 11:31:02 wutq-docker kernel: [62394.424737] [<ffffffff81084a33>] copy_namespaces+0xa3/0xe0
May 6 11:31:02 wutq-docker kernel: [62394.424742] [<ffffffff81057a60>] ? dup_mm+0x140/0x240
May 6 11:31:02 wutq-docker kernel: [62394.424746] [<ffffffff81058294>] copy_process.part.22+0x6f4/0xe60
May 6 11:31:02 wutq-docker kernel: [62394.424752] [<ffffffff812da406>] ? security_file_alloc+0x16/0x20
May 6 11:31:02 wutq-docker kernel: [62394.424758] [<ffffffff8119d118>] ? get_empty_filp+0x88/0x180
May 6 11:31:02 wutq-docker kernel: [62394.424762] [<ffffffff81058a80>] copy_process+0x80/0x90
May 6 11:31:02 wutq-docker kernel: [62394.424766] [<ffffffff81058b7c>] do_fork+0x9c/0x230
May 6 11:31:02 wutq-docker kernel: [62394.424769] [<ffffffff816f277e>] ? _raw_spin_lock+0xe/0x20
May 6 11:31:02 wutq-docker kernel: [62394.424774] [<ffffffff811b9185>] ? __fd_install+0x55/0x70
May 6 11:31:02 wutq-docker kernel: [62394.424777] [<ffffffff81058d96>] sys_clone+0x16/0x20
May 6 11:31:02 wutq-docker kernel: [62394.424782] [<ffffffff816fb939>] stub_clone+0x69/0x90
May 6 11:31:02 wutq-docker kernel: [62394.424786] [<ffffffff816fb5dd>] ? system_call_fastpath+0x1a/0x1f
May 6 11:31:04 wutq-docker kernel: [62396.466223] unregister_netdevice: waiting for lo to become free. Usage count = 3
May 6 11:31:14 wutq-docker kernel: [62406.689132] unregister_netdevice: waiting for lo to become free. Usage count = 3
May 6 11:31:25 wutq-docker kernel: [62416.908036] unregister_netdevice: waiting for lo to become free. Usage count = 3
May 6 11:31:35 wutq-docker kernel: [62427.126927] unregister_netdevice: waiting for lo to become free. Usage count = 3
May 6 11:31:45 wutq-docker kernel: [62437.345860] unregister_netdevice: waiting for lo to become free. Usage count = 3
Setelah terjadi ini, saya membuka terminal lain dan mematikan proses ini, dan kemudian me-restart buruh pelabuhan, tetapi ini akan digantung.
Saya me-reboot Host, dan masih menampilkan pesan itu selama beberapa menit saat dimatikan:
Saya melihat masalah yang sangat mirip untuk eth0. Ubuntu 12.04 juga.
Saya harus menghidupkan mesin. Dari /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
Hei, ini baru saja mulai terjadi pada saya juga.
Versi buruh pelabuhan:
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
Log kernel : http://Pastebin.com/TubCy1tG
Detail sistem :
Menjalankan Ubuntu 14.04 LTS dengan kernel yang ditambal (3.14.3-rt4). Namun untuk melihatnya terjadi dengan kernel generik linux-3.13.0-27-default. Namun, yang lucu adalah ketika ini terjadi, semua jendela terminal saya membeku, membiarkan saya mengetikkan beberapa karakter paling banyak sebelum itu. Nasib yang sama menimpa semua yang baru saya buka juga - dan saya akhirnya perlu menyalakan laptop saya yang malang seperti dokter yang baik di atas. Sebagai catatan, saya menjalankan cangkang ikan di urxvt atau xterm di xmonad. Belum memeriksa apakah itu memengaruhi bash biasa.
Ini mungkin relevan:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065434#yui_3_10_3_1_1401948176063_2050
Menyalin sejumlah besar data melalui jaringan di dalam wadah
dan kemudian keluar dari penampung dapat memicu penurunan yang hilang dalam per
jumlah referensi cpu pada perangkat jaringan.
Benar saja, salah satu saat ini terjadi pada saya adalah tepat setelah apt-get
ting sebuah paket dengan banyak dependensi.
Memutakhirkan dari Ubuntu 12.04.3 ke 14.04 memperbaiki ini untuk saya tanpa perubahan lain.
Saya mengalami ini di RHEL7, 3.10.0-123.4.2.el7.x86_64
Saya perhatikan hal yang sama terjadi dengan antarmuka jaringan virtual VirtualBox saya ketika saya menjalankan 3.14-rt4. Seharusnya diperbaiki di vanilla 3.13 atau apalah.
@egasimus Sama di sini - Saya menarik ratusan MB data sebelum mematikan wadah, lalu mendapatkan kesalahan ini.
Saya memutakhirkan ke kernel Debian 3.14 dan masalahnya tampaknya telah hilang. Sepertinya masalah ada di beberapa kernel <3.5, diperbaiki di 3.5, mundur di 3.6, dan ditambal di sesuatu 3.12-3.14. https://bugzilla.redhat.com/show_bug.cgi?id=880394
@spiffytech Apakah Anda tahu di mana saya dapat melaporkan ini mengenai rasa kernel waktu nyata? Saya pikir mereka hanya merilis patch RT untuk setiap versi lainnya, dan akan sangat membenci melihat 3.16-rt keluar dengan ini masih rusak. :/
EDIT: Diarsipkan di kernel.org .
Saya mendapatkan ini di Ubuntu 14.10 menjalankan 3.18.1. Log kernel menunjukkan
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
Saya akan mengirim docker version/info
setelah sistem tidak dibekukan lagi :)
Kami juga melihat masalah ini. Ubuntu 14.04, 3.13.0-37-generik
Di server Ubuntu 14.04, tim saya menemukan bahwa penurunan versi dari 3.13.0-40-generic ke 3.13.0-32-generic "menyelesaikan" masalah. Mengingat pengamatan @sbward , itu akan menempatkan regresi setelah 3.13.0-32-generic dan sebelum (atau termasuk) 3.13.0-37-generic.
Saya akan menambahkan bahwa, dalam kasus kami, terkadang kami melihat jumlah penggunaan _negatif_.
FWIW kami menemukan bug ini menjalankan lxc pada kernel terpercaya (3.13.0-40-generic #69-Ubuntu) pesan muncul di dmesg diikuti oleh stacktrace ini:
[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
Menjalankan ini di Ubuntu 14.04 dan Debian jessie w/ kernel 3.16.x.
Perintah buruh pelabuhan:
docker run -t -i -v /data/sitespeed.io:/sitespeed.io/results company/dockerfiles:sitespeed.io-latest --name "Superbrowse"
Ini sepertinya masalah yang sangat buruk ...
@jbalonso bahkan dengan 3.13.0-32-generic saya mendapatkan kesalahan setelah hanya beberapa kali berhasil :sob:
@MrMMorris dapatkah Anda membagikan skrip reproduksi menggunakan gambar yang tersedia untuk umum?
Setiap orang yang melihat kesalahan ini pada sistem mereka menjalankan paket kernel Linux pada distribusi mereka yang terlalu tua dan tidak memiliki perbaikan untuk masalah khusus ini.
Jika Anda mengalami masalah ini, pastikan Anda menjalankan apt-get update && apt-get dist-upgrade -y
dan reboot sistem Anda. Jika Anda menggunakan Digital Ocean, Anda juga perlu memilih versi kernel yang baru saja diinstal selama pembaruan karena mereka tidak menggunakan kernel terbaru secara otomatis (lihat https://digitalocean.uservoice.com/forums/136585-digitalocean /suggestions/2814988-give-option-to-use-the-droplet-s-own-bootloader).
Pengguna CentOS/RHEL/Fedora/Scientific Linux perlu memperbarui sistem mereka menggunakan yum update
dan reboot setelah menginstal pembaruan.
Saat melaporkan masalah ini, pastikan sistem Anda sepenuhnya ditambal dan diperbarui dengan pembaruan stabil terbaru (tidak ada paket eksperimental/pengujian/alfa/beta/rc yang diinstal secara manual) yang disediakan oleh vendor distribusi Anda.
@paman
Saya menjalankan apt-get update && apt-get dist-upgrade -y
ubuntu 14.04 3.13.0-46-generik
Masih mendapatkan kesalahan setelah hanya satu docker run
Saya dapat membuat AMI untuk direproduksi jika diperlukan
@MrMMorris Terima kasih telah mengonfirmasi bahwa masih ada masalah dengan paket kernel terbaru di Ubuntu 14.04.
Ada lagi yang bisa saya lakukan untuk membantu, beri tahu saya! :senyum:
@MrMMorris jika Anda dapat memberikan reproduksi ada bug yang dibuka untuk Ubuntu dan itu akan sangat dihargai: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152
@rsampaio jika saya punya waktu hari ini, saya pasti akan mendapatkannya untuk Anda!
Masalah ini juga muncul pada 3.16(.7) pada Debian 7 dan Debian 8: https://github.com/docker/docker/issues/9605#issuecomment -85025729. Mem-boot ulang server adalah satu-satunya cara untuk memperbaikinya untuk saat ini.
Melihat masalah ini pada RHEL 6.6 dengan kernel 2.6.32-504.8.1.el6.x86_64 saat memulai beberapa wadah buruh pelabuhan (tidak semua wadah)
_ kernel:unregister_netdevice : menunggu lo menjadi gratis. Jumlah penggunaan = -1_
Sekali lagi, me-reboot server tampaknya menjadi satu-satunya solusi saat ini
Juga melihat ini di CoreOS (647.0.0) dengan kernel 3.19.3.
Mem-boot ulang juga merupakan satu-satunya solusi yang saya temukan.
Menguji Debian jessie dengan kernel sid (4.0.2) - masalahnya tetap ada.
Adakah yang melihat masalah ini menjalankan wadah non-ubuntu?
Ya. yang Debian.
19 Juli 2015 . 19:01 oleh pemberitahuan "popsikle"@github.com
аписал:
Adakah yang melihat masalah ini menjalankan wadah non-ubuntu?
—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/5618#issuecomment -113556862.
Ini adalah masalah kernel, bukan masalah terkait gambar. Mengganti gambar ke gambar lain tidak akan memperbaiki atau memperburuk masalah ini.
Mengalami masalah pada Debian Jessie pada BeagleBone Black yang menjalankan kernel 4.1.2-bone12
Mengalami setelah beralih dari 4.1.2 ke 4.2-rc2 (menggunakan git build of 1.8.0).
Menghapus /var/lib/docker/* tidak menyelesaikan masalah.
Beralih kembali ke 4.1.2 memecahkan masalah.
Juga, VirtualBox memiliki masalah yang sama dan ada tambalan untuk v5.0.0 (retro-porting ke v4) yang seharusnya melakukan sesuatu di bagian driver kernel .. layak untuk dipahami masalahnya.
Ini adalah perbaikan di VirtualBox: https://www.virtualbox.org/attachment/ticket/12264/diff_unregister_netdev
Mereka tidak benar-benar memodifikasi kernel, hanya modul kernel mereka.
Juga mengalami masalah ini dengan 4.2-rc2:
unregister_netdevice: menunggu vethf1738d3 menjadi gratis. Jumlah penggunaan = 1
Baru saja dikompilasi 4.2-RC3, sepertinya berfungsi lagi
@nazar-pc Terima kasih atas infonya. Tekan saja dengan 4.1.3, cukup kesal
@techniq sama di sini, bug kernel yang sangat buruk. Saya ingin tahu apakah kita harus melaporkannya untuk di-backport ke 4.1 tree.
Linux docker13 3.19.0-22-generic #22-Ubuntu SMP Sel 16 Jun 17:15:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Kernel dari Ubuntu 15.04, masalah yang sama
Saya melihatnya dengan 4.2-rc3 juga. Tidak ada satu pun bug tentang kebocoran perangkat :) Saya dapat mereproduksi pada kernel apa pun >=4.1 di bawah beban tinggi.
Saya juga baru saja mengalami masalah ini. Ubuntu 3.13.0-57-generik, disediakan melalui tutum. Sayangnya itu mengisi kern.log dan syslog dan membuat mesin crash. Itu terjadi pada mesin database (postgres buruh pelabuhan), sehingga menurunkan seluruh sistem ...
Bergabung dengan paduan suara "saya juga", saya melihat masalah ini pada VM cloudtack yang menjalankan RancherOS (OS minimal) 0.3.3 sambil menarik gambar buruh pelabuhan dari repo buruh pelabuhan pribadi lokal. Itu terjadi setiap sepuluh detik, tidak yakin apakah itu berarti apa-apa atau tidak.
Juga mengalami masalah ini dengan 4.2-rc7
Ada berita tentang ini, kernel mana yang harus kita gunakan? Itu terus terjadi bahkan dengan kernel yang sepenuhnya terbaru (3.19.0-26 di Ubuntu 14.04)
Kami juga mendapat masalah ini. Ini terjadi setelah kami mengonfigurasi userland-proxy=false. Kami menggunakan beberapa skrip monitor yang akan menelurkan wadah buruh pelabuhan baru untuk menjalankan perintah plugin nagios setiap 1 menit. Apa yang saya lihat di pohon proses adalah macet pada perintah docker rm dan melihat banyak kesalahan dalam file 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
Ini adalah informasi sistem kami
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
Pembaruan: Meskipun https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152 mengatakan itu sudah diperbaiki pada 17-08-2015. Jadi saya mencoba dengan kernel v3.19.8-ckt6-vivid yang dibangun pada 02-Sep-2015 atau bahkan v4.2.1-unstable yang dibangun pada 21-Sep-2015 dan masih memiliki masalah.
Saya baru saja menemukan masalah lagi menggunakan 3.19.0-28-generic
, jadi kernel ubuntu terbaru tidak aman
Yup, sepertinya --userland-proxy=false
bukan pilihan terbaik sekarang dengan kernel yang lebih lama :(
Tidak. Saya mencoba --userland-proxy=false untuk semua versi kernel 3.19, 4.0, 4.2 dan masalah masih terjadi.
Saya menggunakan proxy userland tanpa iptables (--iptables=false) dan melihat ini minimal sekali sehari. Sayangnya satu-satunya solusi adalah pengawas yang hard reset server menggunakan teknik SysRq.
Sistem saya menjalankan beberapa wadah yang merupakan penulis stdout/err yang berat, seperti yang dilaporkan orang lain dapat memicu bug.
``````
$ info buruh pelabuhan
Wadah: 15
Gambar: 148
Driver Penyimpanan: aufs
Root Dir: /var/lib/docker/aufs
Sistem File Dukungan: extfs
Sutradara: 178
Dirperm1 Didukung: benar
Driver Eksekusi: asli-0.2
Driver Logging: file json
Versi Kernel: 3.19.0-26-generik
Sistem Operasi: Ubuntu 14.04.3 LTS
CPU: 12
Total Memori: 62,89 GiB
Nama: * *
ID: 2 ALJ:YTUH : QCNX:FPEO :YBG4:ZTL4:2 EYK:AV7D :FN7C: IVNU:UWBL :YYZ5
$ versi buruh pelabuhan
Versi klien: 1.7.0
Versi API klien: 1.19
Versi Go (klien): go1.4.2
Git commit (klien): 0baf609
OS/Arch (klien): linux/amd64
Versi server: 1.7.0
Versi API server: 1.19
Versi Go (server): go1.4.2
Git commit (server): 0baf609
OS/Arch (server): linux/amd64```
``````
Sayangnya, saya dalam kasus yang sama, hari ini server produksi gagal 3 kali pada kesalahan ini, dan satu-satunya cara untuk mengatasinya adalah dengan menggunakan beberapa perintah SysRq ajaib..
menabrak
Saya masih melihat ini di debian jessie terbaru menggunakan kernel 4.2.0
Masalah yang sama disini. Tiba-tiba, tiga server aws saya mati dan log berteriak "unregister_netdevice: menunggu lo menjadi gratis. Jumlah penggunaan = 1"
Ubuntu: 14.04
Versi kernel: 3.13.0-63-generik
Buruh pelabuhan: 1.7.1
syslog
Apakah ada versi kernel yang aman digunakan?
Masalah terjadi juga dengan kernel 4.2 dari Ubuntu 15.10
terjadi di coreos:
Gambar: 1174
Driver Penyimpanan: overlay
Sistem File Dukungan: extfs
Driver Eksekusi: asli-0.2
Driver Logging: file json
Versi Kernel: 4.1.7-coreos
Sistem Operasi: CoreOS 766.4.0
Bug kernel yang dikatakan @killme2008 terakhir kali
Anda mungkin harus mencoba dengan patch ini diterapkan di atas kernel Anda http://www.spinics.net/lists/netdev/msg351337.html
paket: kondisi balapan di packet_bind
atau tunggu backport di -stable tree; itu akan datang cepat atau lambat.
:+1: Berita bagus!
Hai semuanya, kabar baik!
Sejak komentar terakhir saya di sini (pada saat penulisan, 17 hari yang lalu) saya tidak mendapatkan kesalahan ini lagi. Server saya (sekitar 30 di antaranya) menjalankan ubuntu 14.04 dengan beberapa paket usang.
Setelah pemutakhiran sistem penuh termasuk mesin buruh pelabuhan (dari 1.7.1 ke 1.8.3) + pemutakhiran kernel ke versi terbaru yang mungkin di repo ubuntu, server saya berjalan tanpa kejadian apa pun.
:8 bola:
Terjadi pada 3 instance AWS kami hari ini juga:
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
Saya mengalami masalah yang sama dengan Ubuntu 14.04, semua paket terbaru dan kernel 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
Saya memilikinya dengan linux-image-generic
(3.13.0-67-generic) juga.
Memiliki masalah yang sama di sini di rancherOS.
Masih terjadi di Fedora 22 (diperbarui)....
Saya dapat menghilangkan pesan jika saya me-restart buruh pelabuhan
systemctl restart buruh pelabuhan
... pesan muncul lagi sekitar 3-4 kali dan kemudian berhenti
Kesalahan yang sama bertemu saya dengan coreos:
versi coreo:
core@core-1-94 ~ $ cat /etc/os-release NAMA=CoreOS ID=coreo VERSI=766.5.0 VERSION_ID=766.5.0 BUILD_ID= PRETTY_NAME="CoreOS 766.5.0" ANSI_COLOR="1;32" HOME_URL="https://coreos.com/" BUG_REPORT_URL="https://github.com/coreos/bugs/issues"
versi buruh pelabuhan:
core@core-1-94 ~ $ versi buruh pelabuhan Versi klien: 1.7.1 Versi API klien: 1.19 Versi Go (klien): go1.4.2 Git commit (klien): df2f73d-dirty OS/Arch (klien): linux/amd64 Versi server: 1.7.1 Versi API server: 1.19 Versi Go (server): go1.4.2 Git commit (server): df2f73d-dirty OS/Arch (server): linux/amd64
core@core-1-94 ~ $uname -a Linux core-1-94 4.1.7-coreos-r1 #2 SMP Kam 5 Nov 02:10:23 UTC 2015 x86_64 Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz GenuineIntel GNU/Linux
catatan sistem:
07 Des 16:26:54 core-1-94 kernel: unregister_netdevice: menunggu veth775ea53 menjadi gratis. Jumlah penggunaan = 1 07 Des 16:26:54 core-1-94 kernel: unregister_netdevice: menunggu lo menjadi gratis. Jumlah penggunaan = 2 07 Des 16:26:55 core-1-94 sdnotify-proxy[1203]: I1207 08:26:55.930559 00001 vxlan.go:340] Mengabaikan tidak ketinggalan: 4e:5c:47:2f:9a:85, 10.244 .97.10 07 Des 16:26:59 core-1-94 dockerd[1269]: time="2015-12-07T16:26:59.448438648+08:00" level=info msg="GET /version" 07 Des 16:27:01 core-1-94 sdnotify-proxy[1203]: I1207 08:27:01.050588 00001 vxlan.go:340] Mengabaikan tidak ketinggalan: 5a:b1:f7:e9:7d:d0, 10.244 .34.8 07 Des 16:27:02 core-1-94 dockerd[1269]: time="2015-12-07T16:27:02.398020120+08:00" level=info msg="GET /version" 07 Des 16:27:02 core-1-94 dockerd[1269]: time="2015-12-07T16:27:02.398316249+08:00" level=info msg="GET /version" 07 Des 16:27:04 core-1-94 dockerd[1269]: time="2015-12-07T16:27:04.449317389+08:00" level=info msg="GET /version" 07 Des 16:27:04 core-1-94 kernel: unregister_netdevice: menunggu veth775ea53 menjadi gratis. Jumlah penggunaan = 1 07 Des 16:27:04 core-1-94 kernel: unregister_netdevice: menunggu lo menjadi gratis. Jumlah penggunaan = 2 07 Des 16:27:06 core-1-94 sdnotify-proxy[1203]: I1207 08:27:06.106573 00001 vxlan.go:340] Mengabaikan tidak ketinggalan: a6:38:ac:79:93:f5, 10.244 .47.24 07 Des 16:27:09 core-1-94 dockerd[1269]: time="2015-12-07T16:27:09.449944048+08:00" level=info msg="GET /version" 07 Des 16:27:11 core-1-94 sdnotify-proxy[1203]: I1207 08:27:11.162578 00001 vxlan.go:340] Mengabaikan tidak ketinggalan: 0e:f0:6f:f4:69:57, 10.244 .71.24 07 Des 16:27:12 core-1-94 dockerd[1269]: time="2015-12-07T16:27:12.502991197+08:00" level=info msg="GET /version" 07 Des 16:27:12 core-1-94 dockerd[1269]: time="2015-12-07T16:27:12.503411160+08:00" level=info msg="GET /version" 07 Des 16:27:14 core-1-94 dockerd[1269]: time="2015-12-07T16:27:14.450646841+08:00" level=info msg="GET /version" 07 Des 16:27:14 core-1-94 kernel: unregister_netdevice: menunggu veth775ea53 menjadi gratis. Jumlah penggunaan = 1 07 Des 16:27:14 core-1-94 kernel: unregister_netdevice: menunggu lo menjadi gratis. Jumlah penggunaan = 2 07 Des 16:27:16 core-1-94 sdnotify-proxy[1203]: I1207 08:27:16.282556 00001 vxlan.go:340] Mengabaikan tidak ketinggalan: a6:62:77:31:ef:68, 10.244 .13.6 07 Des 16:27:19 core-1-94 dockerd[1269]: time="2015-12-07T16:27:19.451486277+08:00" level=info msg="GET /version" 07 Des 16:27:21 core-1-94 sdnotify-proxy[1203]: I1207 08:27:21.402559 00001 vxlan.go:340] Mengabaikan tidak ketinggalan: 92:c4:66:52:cd:bb, 10.244 .24.7 07 Des 16:27:22 core-1-94 dockerd[1269]: time="2015-12-07T16:27:22.575446889+08:00" level=info msg="GET /version" 07 Des 16:27:22 core-1-94 dockerd[1269]: time="2015-12-07T16:27:22.575838302+08:00" level=info msg="GET /version" 07 Des 16:27:24 core-1-94 dockerd[1269]: time="2015-12-07T16:27:24.452320364+08:00" level=info msg="GET /version" 07 Des 16:27:24 core-1-94 kernel: unregister_netdevice: menunggu veth775ea53 menjadi gratis. Jumlah penggunaan = 1 07 Des 16:27:24 core-1-94 kernel: unregister_netdevice: menunggu lo menjadi gratis. Jumlah penggunaan = 2 07 Des 16:27:26 core-1-94 sdnotify-proxy[1203]: I1207 08:27:26.394569 00001 vxlan.go:340] Mengabaikan tidak ketinggalan: 6a:f7:bf:ec:03:50, 10.244 .87.8 07 Des 16:27:29 core-1-94 dockerd[1269]: time="2015-12-07T16:27:29.453171649+08:00" level=info msg="GET /version" 07 Des 16:27:29 core-1-94 systemd[1]: Memulai Hasilkan /run/coreos/motd... 07 Des 16:27:29 core-1-94 systemd[1]: Mulai Buat /run/coreos/motd. 07 Des 16:27:32 core-1-94 dockerd[1269]: time="2015-12-07T16:27:32.671592437+08:00" level=info msg="GET /version" 07 Des 16:27:32 core-1-94 dockerd[1269]: time="2015-12-07T16:27:32.671841436+08:00" level=info msg="GET /version" 07 Des 16:27:33 core-1-94 sdnotify-proxy[1203]: I1207 08:27:33.562534 00001 vxlan.go:340] Mengabaikan tidak ketinggalan: 22:b4:62:d6:25:b9, 10.244 .68.8 07 Des 16:27:34 core-1-94 dockerd[1269]: time="2015-12-07T16:27:34,453953162+08:00" level=info msg="GET /version" 07 Des 16:27:34 core-1-94 kernel: unregister_netdevice: menunggu veth775ea53 menjadi gratis. Jumlah penggunaan = 1 07 Des 16:27:35 core-1-94 kernel: unregister_netdevice: menunggu lo menjadi gratis. Jumlah penggunaan = 2
selamat ulang tahun, masalah berdarah =)
6 Mei 2014
hal yang sama di sini. Hanya me-reboot. Versi buruh pelabuhan terbaru. Ubuntu 14.04.
@samvignoli ini telah diidentifikasi sebagai masalah kernel, jadi sayangnya bukan sesuatu yang bisa diperbaiki di buruh pelabuhan
@thaJeztah Apakah Anda punya tautan ke pelacak bug untuk masalah kernel?
Atau mungkin pointer ke kernel mana yang terpengaruh?
Ingin menyelesaikan ini di lingkungan kita.
@Rucknar maaf, saya tidak (mungkin ada satu dalam diskusi ini, saya belum membaca kembali semua komentar)
Linux atlas2 3.19.0-33-generic #38~14.04.1-Ubuntu SMP Jum 6 Nov 18:17:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
@Rucknar jika Anda menggulir sedikit ke atas - Anda akan melihat tautan ke tambalan http://www.spinics.net/lists/netdev/msg351337.html. Sekarang di master linux, saya kira itu akan pergi ke Linux 4.4, mungkin seseorang sudah mem-backportnya ke versi sebelumnya, tetapi tidak yakin.
Terima kasih semua, akan melihat apa yang diperlukan dalam peningkatan.
FWIW saya mem-backport patch terakhir yang disebutkan di sini ke ubuntu 3.19 dan saya juga menguji pada kernel 4.2 keduanya tidak berhasil. Masalahnya masih ada bahkan pada cabang 4.4-rc3 net-next saat ini.
@rsampaio Bagaimana Anda mengujinya? Saya tidak dapat dengan andal memicu kesalahan ini menggunakan buruh pelabuhan, sebenarnya, pada kernel apa pun. Itu hanya terjadi kadang-kadang.
@fxposter kami juga tidak dapat mereproduksi masalah di luar produksi jadi saya harus mem-boot beberapa contoh dengan kernel yang ditambal dalam produksi, itu sering terjadi sehingga saya dapat mengetahui apakah kernel terpengaruh dalam 24 jam dari beban produksi.
Terkadang kami memperbaikinya dengan sumber daya yang sangat tidak biasa: kami memindahkan direktori container dari /var/lib/docker/aufs/mnt
Dengan itu... MUNGKIN kita bisa 'service docker restart' dan memindahkan direktori kembali.
Jika tidak... hanya me-reboot.
@rsampaio apakah Anda berbicara tentang produksi heroku sekarang? bagaimana Anda menghindari masalah ini, karena semua bisnis Anda dibangun di sekitar wadah/dll?
@rsampaio apakah Anda menggunakan --userland-proxy=false
atau hanya sejumlah besar wadah yang dibuat? Saya dapat mereproduksinya dengan cukup mudah dengan --userland-proxy=false
dan dengan beberapa beban tanpa :)
@ LK4D4 Saya percaya itu hanya sejumlah besar wadah yang dibuat/dihancurkan, khususnya wadah yang melakukan banyak lalu lintas keluar, kami juga menggunakan LXC alih-alih buruh pelabuhan tetapi bugnya persis sama dengan yang dijelaskan di sini, saya dapat mencoba mereproduksi menggunakan metode Anda jika mudah untuk dijelaskan dan/atau tidak melibatkan beban produksi, idenya adalah untuk mendapatkan crashdump dan _maybe_ menemukan lebih banyak petunjuk tentang apa yang sebenarnya memicu bug ini.
@rsampaio Saya dapat mereproduksi dengan penggunaan https://github.com/crosbymichael/docker-stress yang berkepanjangan
Apakah ada pembaruan / proposal untuk ini diperbaiki?
@joshrendek itu adalah bug kernel. Sepertinya kernel 4.4 yang baru dirilis tidak memperbaikinya, jadi setidaknya ada satu kondisi balapan lagi di suatu tempat :)
bug kernel
=)
@samvignoli bisakah Anda menjaga komentar Anda tetap konstruktif? Jangan ragu untuk membuka PR jika Anda memiliki cara untuk memperbaiki masalah ini.
Apakah bug ini sudah dilaporkan ke hulu (milis kernel)?
Tentu telah. komentar pertama merujuk bug ini juga: https://bugzilla.kernel.org/show_bug.cgi?id=81211
Buka sejak 2014. Tidak ada komentar dari siapa pun yang mengerjakannya selain mengatakan kemungkinan besar aplikasi menggunakannya secara tidak benar.
Terima kasih atas tautannya, Justin! Aku akan menjebak Linus =)
Salam Hormat. =* :hati:
@samvignoli tolong jangan lakukan ini, itu tidak membantu siapa pun.
Adakah yang bisa mereproduksi ini dalam gambar VM kecil?
Mungkin saya bisa mengotori tangan saya dengan gdb dan banyak kprintf.
bug masih terbuka.
OS: CentOS 7.2
kernel: 4.4.2 elrepo kernel-ml
buruh pelabuhan: 1.10.2
fs: overlayf dengan xfs
catatan:
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
log ini ditampilkan saat menjalankan gambar docker sameersbn/docker-gitlab:
wget https://raw.githubusercontent.com/sameersbn/docker-gitlab/master/docker-compose.yml
docker-compose up
Saya mungkin hanya beruntung - tetapi setelah menerapkan pengaturan sysctl ini, kejadian ini telah berkurang.
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 apa motivasi di balik pengaturan ini?
@kmike ini untuk memperbaiki beberapa masalah conntrack lainnya (tabel ip semakin penuh) yang kami alami - tampaknya telah melakukan sesuatu sehubungan dengan masalah asli saya meskipun sebagai efek samping
Bisakah Anda menunjukkan sebelum/sesudahnya sehingga kami dapat melihat apa yang sebenarnya berubah? apakah Anda bersedia melakukan pencarian biner pengaturan ini dan melihat apakah ada set yang lebih kecil?
Saya menggunakan CoreOS Stable (899.13.0) di VM Compute Engine. Kesalahan ini terjadi setiap kali saya memulai server dengan tanda berikut ke 0
(default). Saya telah menguji beberapa kali bolak-balik dan dengan IPv6 dinonaktifkan saya dapat memulai semua wadah di simpul tanpa kesalahan:
$ cat /etc/sysctl.d/10-disable-ipv6.conf
net.ipv6.conf.all.disable_ipv6 = 1
Saya menggunakan wadah gcloud untuk mengunduh dari GCR, jadi mungkin masalahnya adalah IPv6 + unduhan MB gambar + tutup wadah dengan cepat.
Versi buruh pelabuhan untuk referensi:
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
Saya juga telah menguji flag sysctl sebelumnya dalam masalah ini; tetapi beberapa sudah memiliki nilai itu dan sisanya sepertinya tidak mengubah apa pun yang terkait dengan kesalahan ini:
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
Saya masih melihat masalah ketika saya mengatur net.ipv6.conf.all.disable_ipv6=1.
Alat stres buruh pelabuhan dapat menghasilkan masalah dengan sangat mudah.
https://github.com/crosbymichael/docker-stress
Ini adalah biner yang saya buat untuk alat di atas.
https://storage.googleapis.com/donny/main
https://storage.googleapis.com/donny/stress.json
Setelah kita melihat log "unregister_netdevice: waiting for veth6c3b8b0 menjadi free. Usage count", docker hang. Saya pikir ini adalah masalah kernel yang dipicu oleh buruh pelabuhan. Ini hanya akan terjadi ketika docker userland-proxy dimatikan (--userland-proxy=false).
Saya sudah mengalami ini dengan dan tanpa proxy userland diaktifkan, jadi saya tidak akan mengatakan hanya ketika itu mati.
Bisa jadi itu memperburuk situasi; Saya tahu kami pernah mencoba menjadikan --userland-proxy=false
sebagai default, tetapi mengembalikannya karena ada efek samping https://github.com/docker/docker/issues/14856
Saya juga pernah melihat kesalahan satu kali sejak kemarin, jelas menonaktifkan IPv6 itu bukan perbaikan; tetapi tanpa bendera saya bahkan tidak dapat memulai semua wadah server tanpa merusak buruh pelabuhan.
Menjalankan ini di CoreOS 1010.1.0 dengan kubernetes 1.2.2 dan docker 1.10.3
Kubernetes menambahkan tanda ke kubelet (di ponsel, jadi tidak dapat mencarinya) untuk
modus jepit rambut. Ubah ke "jembatan promiscuous" atau apa pun yang valid
nilai adalah. Kami belum melihat kesalahan ini sejak melakukan perubahan itu.
@bprashanh
Mohon konfirmasi atau bantah?
Pada 13 Apr 2016 12:43 PM, "Aaron Crickenberger" [email protected]
menulis:
Menjalankan ini di CoreOS 1010.1.0 dengan kubernetes 1.2.2 dan buruh pelabuhan
1.10.3—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/5618#issuecomment -209617342
Mendapatkan ini di AWS yang menjalankan Linux 4.4.5-15.26.amzn1.x86_64 dengan Docker versi 1.9.1, build a34a1d5/1.9.1.
Ruby 2.3.0 dengan gambar Alpine berjalan di dalam wadah menyebabkan ini
kernel:[58551.548114] unregister_netdevice: menunggu lo menjadi gratis. Jumlah penggunaan = 1
Ada perbaikan untuk ini?
melihat ini untuk pertama kalinya di 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
Beberapa reboot memperbaikinya.
@MrMMorris Diperbaiki karena Anda yakin masalahnya telah hilang untuk selamanya, atau karena Anda belum mengalaminya lagi? Bisa jadi kondisi balapan...
Cukup jelas bahwa ini adalah balapan di kernel, kehilangan refcount
di suatu tempat. Ini adalah bug yang SANGAT sulit dilacak, tetapi sejauh yang kami tahu
masih ada.
Pada Senin, 2 Mei 2016 pukul 22:52, Sune Keller [email protected]
menulis:
@MrMMorris https://github.com/MrMMorris Tetap seperti yang Anda yakini
masalah telah hilang untuk selamanya, atau Anda tidak mengalaminya lagi
baru saja? Bisa jadi kondisi balapan...—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/5618#issuecomment -216444133
Ya. Saya mencoba CoreOS 1032.0.0 dengan kernel 4.5, dan masalahnya masih ada.
Saya menemukan ini lagi di CoreOS 1010.1.0 dengan kernel 4.5.0 kemarin, setelah beberapa kontainer dimulai dan dimatikan secara berurutan.
Aku punya kesalahan ini.
Versi Docker: 1.9.1
Versi Kernel: 4.4.8-20.46.amzn1.x86_64
Sistem Operasi: Amazon Linux AMI 2016.03
@sirlatrom tidak diperbaiki. Melihat ini lagi Diperlukan beberapa reboot untuk menyelesaikannya.
Saat ini menjalankan 3.19.0-18-generic. Akan mencoba memutakhirkan ke yang terbaru
sama disini! :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis : :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: : menangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis : :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: : menangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis : :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: : menangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis : :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis: :nangis:
@samvignoli komentar anda tidak membangun. Tolong berhenti memposting.
maaf, lupa fungsi jempol ke atas.
Direproduksi di Fedora Server 23 - 4.2.5-300.fc23.x86_64. Tidak dapat memulai ulang layanan Docker - hanya reboot node.
Masalah yang sama pada Fedora 24 Kernel: 4.5.2-302.fc24.x86_64. tidak menyebabkan hang, tetapi mengirim spam ke file log.
@hapylestat Bisakah Anda mencoba systemctl restart docker
? Ini menyebabkan semuanya menggantung bagi saya.
Terima kasih
Ini cukup sering terjadi pada mesin (CoreOS, EC2) saya. Jika ini sangat membantu, berikut adalah semua log yang terkait dengan perangkat veth yang macet dalam satu contoh bug ini.
$ 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
Ini sepertinya terjadi ketika saya menghapus banyak wadah sekaligus (dalam kasus saya, ketika saya menghapus k8s pod secara massal).
Bagi mereka yang mengatakan reboot memperbaikinya - apakah Anda mem-boot ulang atau menghentikan/memulai mesin? Pada mesin fisik saya harus menggunakan reset daya jarak jauh untuk membuat mesin hidup kembali.
@joshrendek , saya harus menggunakan boot dingin
@joshrendek Saya memiliki skrip sekarang yang berjalan menonton ini dan melakukan reboot -f
ketika itu terjadi .
Mungkin telah menemukan masalah (atau hanya beruntung). Saya telah memindahkan direktori grafik Docker dari disk yang dipartisi XFS ke disk yang dipartisi EXT4 dan saya tidak dapat mereproduksi masalah (serta menyelesaikan banyak bug XFS lain yang saya dapatkan). Saya ingat @vbatts mengatakan bahwa XFS belum didukung.
Saya telah mencoba memprovokasi dengan menjalankan build
, run
, stop
, delete
dalam infinate loop pada berbagai gambar, membuat sekitar 10 kontainer setiap siklus, untuk beberapa jam terakhir.
@joedborg apa graphdriver yang Anda gunakan? Pemeta perangkat? Hamparan?
@thaJeztah Poin bagus, saya seharusnya menyebutkan itu. Saya menggunakan driver Overlay dengan (sekarang) dukungan EXT4 FS.
Saya dulu menggunakan devicemapper (karena saya menggunakan Fedora Server), tetapi saya mengalami banyak rasa sakit (seperti yang saya yakini banyak orang lakukan), terutama dengan kebocoran di mana mapper tidak akan mengembalikan ruang ke kolam setelah wadah dihapus.
Jika membantu, saya menggunakan Docker 1.11.1 dan Kernel 4.2.5-300.fc23.x86_64.
@joedborg menarik, karena dokumen RHEL menyebutkan bahwa hanya EXT4 yang didukung pada RHEL/CentOS 7.1, dan hanya XFS pada RHEL/CentOS 7.2. Saya berharap XFS berfungsi pada versi yang lebih baru
@thaJeztah ah itu aneh. Saya mencoba memikirkan hal-hal lain yang mungkin terjadi. Saya telah membaca ulang dari atas dan sepertinya beberapa orang menjalankan konfigurasi yang sama. Satu-satunya hal lain yang berbeda adalah bahwa disk XFS adalah spindel dan EXT4 adalah SSD. Saya akan terus merendam pengujian sementara waktu. Saya juga telah memindahkan prod untuk menggunakan pengaturan yang sama, jadi bagaimanapun kita akan memiliki jawaban sebelum lama. Namun, itu dilakukan di hampir setiap stop
sebelumnya, jadi itu pasti lebih baik.
@joedborg yah, ini informasi yang berguna memang
kesalahan yang sama di sini, dari kernel 4.2 hingga 4.5, versi buruh pelabuhan yang sama.
BTW, saya menjalankan beberapa mesin virtualbox pada kotak yang sama secara bersamaan.
$ 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
Saya mengalami masalah ini menggunakan driver grafik overlay
, dengan direktori pada ext4
FS. Jadi menurut saya xfs
bukan masalah
@obeattie Ya, sepertinya orang-orang juga mendapatkannya di devicemapper
. Sentuh kayu, saya tidak memiliki masalah lagi sejak beralih. Seperti yang disebutkan, saya juga menukar disk fisik. Ini akan menjadi salah satu yang menarik!
Masalah ini tidak berkorelasi dengan sistem file dengan cara apa pun. Saya telah melihat masalah ini dengan zfs, overlayfs, devicemapper, btrfs dan aufs. Juga dengan atau tanpa swap. Bahkan tidak terbatas pada buruh pelabuhan, saya juga menemukan bug yang sama dengan lxc. Satu-satunya solusi, yang saat ini saya lihat, adalah tidak menghentikan kontainer secara bersamaan.
jika membantu, saya mendapatkan pesan kesalahan yang sama pada instans EC2 terbaru yang didukung oleh AWS AMI. versi buruh pelabuhan menunjukkan-
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
Hanya melompat di papan. Saya melihat perilaku yang sama pada contoh Amazon ec2 terbaru. Setelah beberapa waktu, wadah hanya terbalik dan menjadi tidak responsif.
$ info buruh pelabuhan
Wadah: 2
Gambar: 31
Versi Server: 1.9.1
Driver Penyimpanan: devicemapper
Nama Pool: docker-202:1-263705-pool
Ukuran Blok Kolam Renang: 65,54 kB
Ukuran Perangkat Dasar: 107,4 GB
Sistem File Pendukung:
File data: /dev/loop0
File metadata: /dev/loop1
Ruang Data yang Digunakan: 1.199 GB
Total Ruang Data: 107,4 GB
Ruang Data Tersedia: 5.754 GB
Ruang Metadata yang Digunakan: 2,335 MB
Ruang Metadata Total: 2.147 GB
Ruang Metadata Tersedia: 2.145 GB
Sinkronisasi Udev Didukung: benar
Penghapusan Ditangguhkan Diaktifkan: false
Penghapusan Ditangguhkan Diaktifkan: false
Jumlah Perangkat yang Dihapus Ditangguhkan: 0
File loop data: /var/lib/docker/devicemapper/devicemapper/data
File loop metadata: /var/lib/docker/devicemapper/devicemapper/metadata
Versi Perpustakaan: 1.02.93-RHEL7 (28-01-2015)
Driver Eksekusi: asli-0.2
Driver Logging: file json
Versi Kernel: 4.4.10-22.54.amzn1.x86_64
Sistem Operasi: Amazon Linux AMI 2016.03
CPU: 1
Total Memori: 995.4 MiB
Nama: [dihapus]
ID: OB7A:Q6RX: ZRMK:4R5H : ZUQY:BBNK : BJNN:OWKS :FNU4:7NI2: AKRT:5SEP
$ versi buruh pelabuhan
Klien:
Versi: 1.9.1
Versi API: 1.21
Pergi versi: go1.4.2
Git commit: a34a1d5/1.9.1
Dibuat:
OS/Arch: linux/amd64
Server:
Versi: 1.9.1
Versi API: 1.21
Pergi versi: go1.4.2
Git commit: a34a1d5/1.9.1
Dibuat:
OS/Arch: linux/amd64
Sama seperti komentar di atas, juga berjalan di EC2 melalui pohon kacang elastis menggunakan 64bit Amazon Linux 2016.03 v2.1.0 running Docker 1.9.1
Agak anekdot saat ini, tetapi saya baru-baru ini mencoba memutakhirkan kernel dari 4.2.0 ke 4.5.5 di sekitar 18 server sebagai pengujian, dan masalah ini menjadi jauh lebih buruk (dari beberapa hari hingga tidak lebih dari 4 jam di antara masalah).
Ini ada di Debian 8
Pengaturan yang sama persis seperti @jonpaul dan @g0ddard
Mencari untuk melihat bagaimana kami dapat mengurangi bug ini.
Hal pertama (yang mungkin berhasil atau tidak, itu berisiko) adalah menjaga agar API tetap tersedia jika hal ini terjadi: #23178
Halo. Saya juga pernah digigit oleh bug ini...
Jun 08 17:30:40 node-0-vm kernel: unregister_netdevice: waiting for veth846b1dc to become free. Usage count = 1
Saya menggunakan Kubernetes 1.2.4 di CoreOS Beta, Flannel dan berjalan di Azure. Apakah ada cara untuk membantu men-debug masalah ini? Utas bug kernel tampaknya mati. Beberapa orang melaporkan bahwa menonaktifkan IPv6 pada kernel, menggunakan --userland-proxy=true
atau menggunakan aufs alih-alih bantuan penyimpanan overlay, sementara yang lain tidak... Ini agak membingungkan.
Seperti @ justin8 saya juga memperhatikan ini setelah memutakhirkan sistem Fedora 23 saya ke kernel 4.5.5; masalahnya tetap pada kernel 4.5.6.
Kami menemukan bug ini saat container mencapai batas memorinya. Tidak yakin apakah itu terkait atau tidak.
masalah yang sama di sini
# docker version
Client:
Version: 1.9.1
API version: 1.21
Go version: go1.4.3
Git commit: a34a1d5
Built: Fri Nov 20 17:56:04 UTC 2015
OS/Arch: linux/amd64
Server:
Version: 1.9.1
API version: 1.21
Go version: go1.4.3
Git commit: a34a1d5
Built: Fri Nov 20 17:56:04 UTC 2015
OS/Arch: linux/amd64
# docker info
Containers: 213
Images: 1232
Server Version: 1.9.1
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 1667
Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.19.0-5-exton
Operating System: Debian GNU/Linux 7 (wheezy)
CPUs: 4
Total Memory: 21.58 GiB
Name: [redacted]
Message from syslogd@[redacted] at Jun 24 10:07:54 ...
kernel:[1716405.486669] unregister_netdevice: waiting for lo to become free. Usage count = 2
Message from syslogd@[redacted] at Jun 24 10:07:56 ...
kernel:[1716407.146691] unregister_netdevice: waiting for veth06216c2 to become free. Usage count = 1
centos7.2
buruh pelabuhan 1.10.3
masalah yang sama
Saya memiliki "satu liner" yang pada akhirnya akan mereproduksi masalah ini untuk saya pada EC2 (m4.large) yang menjalankan CoreOS 1068.3.0 dengan kernel 4.6.3 (sangat baru). Bagi saya, dibutuhkan sekitar 300 iterasi tetapi YMMV.
Linux ip-172-31-58-11.ec2.internal 4.6.3-coreos #2 SMP Sab 25 Jun 00:59:14 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz GenuineIntel GNU/Linux
CoreOS beta (1068.3.0)
Docker versi 1.10.3, membangun 3cd164c
Beberapa ratus iterasi dari loop di sini pada akhirnya akan hang dockerd dan kernel akan memancarkan pesan kesalahan seperti
kernel: unregister_netdevice: waiting for veth8c7d525 to become free. Usage count = 1
Lingkaran reproduksi adalah
i=0; while echo $i && docker run --rm -p 8080 busybox /bin/true && docker ps; do sleep 0.05; ((i+=1)); done
EDIT
userland-proxy=false
Skrip @btalbot , di atas, tidak mereproduksi masalah bagi saya di Fedora 23 setelah beberapa ribu iterasi.
$ 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)
Masalah ini cukup sering terjadi pada cluster Kubernetes saya, namun saya tidak dapat mereproduksinya secara andal dengan stresser atau satu liner
VM pertama adalah Standard_D1_v2 (Ram 3,5GB, 1 inti) - skrip melakukan> 3000 iterasi.
VM kedua adalah Standard_DS15_v2 (140GB Ram, 20 core) - skrip melakukan > 7600 iterasi.
Saya telah memperbarui komentar saya sebelumnya (https://github.com/docker/docker/issues/5618#issuecomment-229545933) untuk memasukkan bahwa saya hanya dapat mereproduksi ini ketika userland-proxy=false.
Ini mereproduksi untuk saya di EC2 t2.micro (single core) VM serta m4.large (multi core) keduanya menggunakan HVM. Belum pernah melihatnya terjadi menggunakan VirtualBox di laptop saya meskipun tidak peduli pengaturan proxy-userland.
Kami menemukan bug ini saat menggunakan Flannel dengan hairpin-veth diaktifkan di kubernetes cluster (menggunakan proxy iptables). Bug ini terjadi hanya ketika kita menjalankan-stop terlalu banyak container. Kami beralih menggunakan jaringan jembatan cbr0 dan mode jepit rambut jembatan promiscuous dan tidak pernah melihatnya lagi.
Sebenarnya mudah untuk mereproduksi bug ini jika Anda menggunakan hairpin-veth, cukup mulai pekerjaan ini dengan 100 container dengan kubernetes.
Pada 01/07/2016 08:01, manoj0077 menulis:
@btalbot https://github.com/btalbot jadi dengan 1.12 kita bisa restart
dockerd tanpa mempengaruhi menjalankan container. Jadi dockerd akan restart
membantu di sini dalam kasus ini?AFAICT, acara dengan 1,12, proses kontainer buruh pelabuhan masih anak-anak
dari daemon buruh pelabuhan.
@sercand bagaimana Anda mengatur mode jepit rambut promiscuous-bridge? Saya tidak dapat melihat dokumentasi apa pun dari buruh pelabuhan tentang itu, atau mungkin mereka menggunakan nama yang berbeda
Apakah ada kata resmi dari Docker tentang kapan ini dapat dilihat? Ini adalah isu terbuka kedua yang paling banyak dikomentari ; sangat parah (memerlukan restart host); dapat direproduksi; dan saya tidak melihat kemajuan nyata untuk menemukan akar masalahnya atau memperbaikinya .
Tampaknya ini adalah masalah kernel, tetapi tiket di Bugzilla telah stagnan selama berbulan-bulan. Apakah akan membantu untuk memposting kasus pengujian kami di sana?
@justin8 Saya pikir itu adalah flag Kubelet: --configure-cbr0
dan --hairpin-mode
@sercand saya juga menggunakan Flanel. Apakah ada kerugian dalam menggunakan --hairpin-mode=promiscuous-bridge
?
@obeattie saya setuju. :(
FTR saya berhasil meniru masalah dengan menggunakan @sercand 's pekerjaan stresser pada tes Kubernetes klaster yang saya set, itu juga menggunakan flanel dan jepit rambut-Veth.
@sercand Bisakah Anda menjelaskan langkah-langkah untuk mulai menggunakan promiscuous-bridge
? Saya menambahkan flag --configure-cbr0=true
ke kubelet node tetapi mengeluh:
ConfigureCBR0 requested, but PodCIDR not set. Will not configure CBR0 right now
. Saya pikir PodCIDR ini seharusnya berasal dari master? Terima kasih.
EDIT: Sepertinya saya perlu menambahkan --allocate-node-cidrs=true --cluster-cidr=10.2.0.0/16
ke konfigurasi manajer pengontrol, tetapi karena saya tidak memiliki penyedia cloud (Azure), rute mungkin tidak akan berfungsi.
@ justin8 Saya telah mengikuti dokumen ini .
@edevil dari mode jepit rambut dokumentasi adalah untuk "Ini memungkinkan titik akhir Layanan untuk menyeimbangkan kembali ke diri mereka sendiri jika mereka harus mencoba mengakses Layanan mereka sendiri". Omong-omong, cluster saya berjalan di Azure dan itu bukan tugas yang mudah untuk dicapai.
@sercand Menurut doc, jika kita menggunakan --allocate-node-cidrs=true
pada controller manager kita harus menggunakan penyedia cloud untuk mengatur rute. Karena tidak ada penyedia cloud Kubernetes untuk Azure, bukankah Anda punya masalah? Apakah Anda mengatur rute secara manual? Terima kasih.
@edevil Saya menggunakan terraform untuk membuat rute. Anda dapat menemukannya di repo ini . Saya dengan cepat membuat konfigurasi ini dan menguji hanya sekali. Saya harap itu cukup untuk memberikan logika dasar di baliknya.
@morvans @btalbot apakah Anda mendapat kesempatan untuk mencoba dengan 1.12 ...?
Saya dapat mengonfirmasi bahwa menjauh dari hairpin-veth dan menggunakan jembatan cbr0 saya tidak dapat mereproduksi masalah lagi.
Untuk jaga-jaga: adakah yang mengalami masalah ini pada bare metal? Kami telah melihat ini saat menguji klaster peternak di lab VMWare kami, tetapi tidak pernah terlihat pada penerapan bare metal yang sebenarnya.
Ya, masalah ini terjadi pada bare metal untuk kernel apa pun >= 4.3. Telah melihat ini di banyak mesin dan konfigurasi perangkat keras yang berbeda. Satu-satunya solusi bagi kami adalah menggunakan kernel 4.2.
Itu pasti masih terjadi pada 4.2, tetapi ini adalah urutan besarnya lebih sering pada apa pun yang lebih baru, saya telah menguji setiap rilis utama untuk melihat apakah itu lebih baik, dan belum ada apa-apa.
Terjadi pada CoreOS alpha 1097.0.0 juga.
Kernel: 4.6.3
buruh pelabuhan: 1.11.2
Saya mendapatkan masalah yang sama.
buruh pelabuhan: 1.11.2
Kernel: 4.4.8-boot2docker.
Host: Mesin Docker dengan driver VMWare Fusion di OS X.
Ada solusi yang disarankan?
Akan sangat membantu jika Anda yang dapat mereproduksi masalah dengan andal di lingkungan di mana crashdump dimungkinkan (alias bukan EC2) sebenarnya dapat membagikan file crashdump ini, informasi lebih lanjut tentang cara mengaktifkan kdump di ubuntu trusty dapat ditemukan di sini dan ini adalah opsi crash yang perlu Anda aktifkan ketika kdump siap untuk menghasilkan crashdump:
echo 1 > /proc/sys/kernel/hung_task_panic # panic when hung task is detected
echo 1 > /proc/sys/kernel/panic_on_io_nmi # panic on NMIs from I/O
echo 1 > /proc/sys/kernel/panic_on_oops # panic on oops or kernel bug detection
echo 1 > /proc/sys/kernel/panic_on_unrecovered_nmi # panic on NMIs from memory or unknown
echo 1 > /proc/sys/kernel/softlockup_panic # panic when soft lockups are detected
echo 1 > /proc/sys/vm/panic_on_oom # panic when out-of-memory happens
Crashdump benar-benar dapat membantu pengembang kernel menemukan lebih banyak tentang apa yang menyebabkan kebocoran referensi tetapi perlu diingat bahwa crashdump juga menyertakan dump memori host Anda dan mungkin berisi informasi yang masuk akal.
... informasi yang masuk akal.
:Hai
Saya mengalami masalah yang sama.
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
Masalah yang sama:
Ubuntu 14.04.4 LTS (GNU/Linux 3.19.0-25-generic x86_64)
Docker version: 1.10.3
Baru saja terjadi langsung di layar terminal:
Message from syslogd<strong i="6">@svn</strong> at Jul 26 21:47:38 ...
kernel:[492821.492101] unregister_netdevice: waiting for lo to become free. Usage count = 2
Message from syslogd<strong i="7">@svn</strong> at Jul 26 21:47:48 ...
kernel:[492831.736107] unregister_netdevice: waiting for lo to become free. Usage count = 2
Message from syslogd<strong i="8">@svn</strong> at Jul 26 21:47:58 ...
kernel:[492841.984110] unregister_netdevice: waiting for lo to become free. Usage count = 2
sistem adalah
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
Permasalahan yang sama
Os: Amazon Linux AMI release 2016.03
Docker: 1.9.1
Disini juga:
Linux 4.4.14-24.50.amzn1.x86_64 x86_64
Docker version 1.11.2, build b9f10c9/1.11.2
Saya melihat masalah yang sama di 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
(pada semua pty + pager saya ketika ini terjadi)
"cukup" Debian Jessie + backport:
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
Halo,
Ketika saya mencoba mereplikasi masalah di lingkungan yang terkendali dengan membuat gambar baru yang menghancurkan, saya tidak dapat mereproduksinya.
Masalahnya telah diangkat di salah satu server yang menjalankan docker 1.9.1
docker info | egrep "Version|Driver"
Server Version: 1.9.1
Storage Driver: devicemapper
Library Version: 1.02.93 (2015-01-30)
Execution Driver: native-0.2
Logging Driver: gelf
Kernel Version: 4.5.0-coreos-r1
Saya secara bersamaan makan siang 17753 kontainer sejauh ini dalam mode bersamaan dan meningkatkan lalu lintas ke internet, tanpa membocorkan antarmuka veth* apa pun. Bisakah seseorang menempelkan instruksi untuk mereproduksi masalah secara konsisten?
@pegerto Seharusnya cukup mudah dipicu jika Anda memiliki --userland-proxy=false
dan memutar banyak wadah secara bersamaan. Saya melakukan ini menggunakan https://github.com/crosbymichael/docker-stress
Terima kasih @cpuguy83
Mengkonfigurasi daemon agar memiliki --userland-proxy=false
Saya dapat dengan mudah mereproduksi masalah, terima kasih, kita dapat melihat masalah ini memengaruhi daemon yang tidak menjalankan konfigurasi ini.
Saya melihat dump kernel di kait netfilter yang diperkenalkan oleh segregasi netns di >=4.3, adakah pemikiran mengapa masalah ini tampak lebih buruk ketika rute terjadi pada 127/8 ?
Terima kasih
Melihat masalah ini juga. CoreOS 1068.8.0, Docker 1.10.3, kernel 4.6.3. Saya menarik beberapa log sistem jika ada yang tertarik.
Baru punya banyak...
unregistered_netdevice: waiting for lo to become free. Usage count = 1
... pada 2 VM dan laptop baremetal saya, semuanya menjalankan Ubuntu 16.04 dan kernel terbaru (4.4.0-3[456]).
Hasilnya adalah semuanya hang dan membutuhkan hard reboot.
Belum pernah mengalami ini sebelumnya minggu lalu dan saya pikir salah satu VM ada di 1.11.3 sementara yang lain semuanya ada di 1.12.0.
@RRAlex Ini tidak spesifik untuk versi buruh pelabuhan mana pun.
Jika Anda menggunakan --userland-proxy=false
pada opsi daemon... ATAU (dari apa yang saya pahami) Anda menggunakan kubernetes, kemungkinan besar Anda akan mengalami masalah ini.
Alasannya adalah opsi --userland-proxy=false
mengaktifkan hairpin NAT pada antarmuka bridge... ini adalah sesuatu yang juga ditetapkan oleh kubernetes ketika menyiapkan jaringan untuk containernya.
Melihat ini di node BYO menggunakan Docker Cloud (dan agen Docker Cloud).
Melihat ini hari ini, sekali (dari sekitar 25 percobaan) pada AMI Amazon ECS saat ini, menjalankan vanilla debian:jessie dengan perintah yang apt-get update, menginstal pbzip2, lalu menjalankannya (tes CPU multithread sederhana).
@edevil
Sebagian besar dari Anda orang di sini menjelaskan bahwa Anda menghadapi situasi ini saat menggunakan Docker untuk memulai/menghentikan wadah, tetapi saya mendapatkan situasi yang persis sama tanpa Docker, di Debian:
Tidak ada cara untuk memulihkan kecuali hard reset mesin.
Jadi tolong, dalam penyelidikan Anda untuk menentukan/menyelesaikan masalah ini, jangan fokus pada Docker saja. Jelas merupakan masalah umum dengan penghentian/permulaan kontainer yang cepat, baik melalui Docker, atau melalui perintah "lxc" biasa.
Saya akan berpikir bahwa ini adalah masalah kernel linux.
Saya menemui masalah ini ketika saya menjalankan 3 chroot (sebenarnya pbuilder) dengan beban yang sangat berat.
Perangkat keras saya adalah Loongson 3A (mesin mips64el dengan kernel 3.16).
Ketika saya mencoba ssh ke dalamnya, saya menemui masalah ini.
Jadi masalah ini mungkin tidak hanya tentang buruh pelabuhan atau lxc, bahkan tentang chroot.
Docker versi 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
logam telanjang.
Kami memiliki masalah akhir-akhir ini pada bare metal (didedikasikan pada ovh) dengan kernel 4.6.x dan buruh pelabuhan 1.11.2.
Setelah membaca komentar di sini dan mencoba beberapa solusi, kami menurunkan versi kernel kami ke versi terbaru dari cabang 3.14 (3.14.74) dan memutakhirkan buruh pelabuhan ke 1.12.0 untuk menghindari https://github.com/docker/libnetwork/issues/1189 dan semuanya tampak baik-baik saja untuk saat ini.
Saya harap ini bisa membantu.
Semua, saya pikir Anda tidak perlu memposting pesan lagi tentang Docker atau chroot, ini semua tentang kernel Linux.
Jadi tolong, dapatkah seseorang berdiri yang dapat men-debug kernel dengan cara tertentu, di bagian yang menonaktifkan antarmuka jaringan virtual untuk wadah? Mungkin ada beberapa kondisi balapan yang terjadi ketika pemberhentian kontainer sebelumnya belum sepenuhnya menonaktifkan/membersihkan antarmuka virtualnya, sebelum pemberhentian baru dari sebuah kontainer diminta.
@rdelangh Saya tidak berpikir masalah itu harus terkait dengan kernel.
Di Fedora 24, saya tidak dapat mereproduksi masalah dengan Docker 1.10.3 dari repo Fedora, hanya dengan Docker 1.12.1 dari repo Docker sendiri.
Kedua pengujian dilakukan dengan kernel 4.6.7-300.fc24.x86_64.
Melihat masalah ini juga pada CoreOS 1068.10.0, Docker 1.10.3, kernel 4.6.3.
kernel: unregister_netdevice: waiting for veth09b49a3 to become free. Usage count = 1
Menggunakan Kubernetes 1.3.4 pada CoreOS 1068.9.0 stable di EC2, buruh pelabuhan 1.10.3 Saya melihat masalah ini.
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
Melihat masalah ini juga di Ubuntu 16.04, Docker 1.12.1, kernel 4.4.0-34-generic
waiting for lo to become free. Usage count = 1
$ time docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
...
real 4m40.943s
user 0m0.012s
sys 0m0.004s
Bagi mereka yang menggunakan Kubernetes <= 1.3.4 Anda dapat mengeksploitasi masalah ini: https://github.com/kubernetes/kubernetes/issues/30899 untuk mereproduksi masalah ini. Saya menjalankan cluster kecil dengan 1 Controller (m4.large) dan 2 Worker (m4.large) di CoreOS 1068.10.
Dari sana Anda dapat membuat 2 ReplicationControllers, saya menyebutnya hello
dan hello1
berdasarkan ini: http://Pastebin.com/mAtPTrXH . Pastikan untuk mengubah nama dan label menjadi berbeda.
Kemudian, buat 2 penerapan yang cocok dengan nama/label yang sama seperti di atas berdasarkan ini: http://Pastebin.com/SAnwLnCw .
_Segera setelah Anda membuat penerapan, Anda akan mendapatkan sejumlah besar penampung spam_.
Jika Anda membiarkannya menyala sebentar (beberapa menit), Anda akan melihat banyak hal yang mencoba untuk dihentikan/dibuat. Anda dapat menghapus penerapan dan membiarkan semuanya stabil. Anda akan melihat beberapa Terminating dan ContainerCreating yang bagus. Jika Anda ssh ke node, periksa dmesg
dan docker ps
untuk melihat apakah gejala di atas terlihat.
Dalam contoh saya, saya butuh sekitar 5 menit untuk membiarkan orang aneh ini keluar sebelum melihat masalahnya. Saya berencana membuat perubahan yang @sercand dan @edevil mainkan dan lihat apakah ini berhasil untuk saya dalam kasus ini.
@edevil Setelah melihat komit tertaut Anda, apakah saya benar bahwa Anda menonaktifkan/menghapus Flannel di lingkungan Anda sepenuhnya demi jembatan cbro
dibuat oleh Kubernetes untuk mengatasi masalah ini?
Saya melihat di pihak saya bahwa Anda tidak akan dapat menggunakannya bersama-sama karena flanel ingin menggunakan docker0
dan jaringan internal Anda akan bekerja pada cbr0
benar?
@alph486 itu benar, saya berhenti menggunakan kain flanel. Saya menggunakan jembatan dan mengatur rute untuk jaringan pod.
@alph486 flanel tidak ingin menggunakan docker0. Ini hanya jembatan default untuk buruh pelabuhan, yang dapat Anda timpa dengan opsi buruh pelabuhan --bridge=cbr0
.
Pada CoreOS Anda harus mengganti unit docker systemd.
Bendera Kubelet --experimental-flannel-overlay
dapat membaca konfigurasi flanel, dan mengkonfigurasi jembatan buruh pelabuhan cbr0
dengan CIDR flanel.
Ini juga akan mengaktifkan mode promiscuous
alih-alih veth-hairpin
yang tampaknya menjadi masalah.
Terima kasih @dadux atas masukannya. Jika K8 akan mengambil antarmuka cbr0
yang telah di-bootstrap oleh unit yang ditimpa, bisa jadi dalam bisnis dengan solusi itu; saya akan mencobanya.
Menurut dokumen, promiscuous-bridge
tampaknya menjadi nilai default untuk --hairpin-mode
di kubelet v1.3.4+. Saya masih melihat masalah dengan ini, jadi saya tidak sepenuhnya yakin itu solusi keseluruhan.
Saya tidak dapat mereproduksi masalah lagi setelah menggunakan plugin jaringan kubenet
(yang diatur untuk menggantikan --configure-cbr0
). Saya agak menghindari opsi flannel-overlay
karena ketidakpastian masa depannya (tampaknya terkait dengan --configure-cbr0
).
Jika daemon buruh pelabuhan Anda menggunakan jembatan docker0
, pengaturan --hairpin-mode=promiscuous-bridge
akan berpengaruh karena kubelet akan mencoba mengonfigurasi jembatan yang tidak ada cbr0
.
Untuk CoreOS, solusi saya untuk mencerminkan perilaku Kubernetes tetapi masih menggunakan flannel :
docker0
ke mode promiscuous. (Pasti ada yang lebih elegan ingin melakukan ini?):- 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
Anda dapat memeriksa apakah jepit rambut diaktifkan untuk antarmuka Anda dengan
brctl showstp docker0
atau
for f in /sys/devices/virtual/net/*/brport/hairpin_mode; do cat $f; done
Saya pikir kolega saya telah memperbaiki ini baru-baru ini http://www.spinics.net/lists/netdev/msg393441.html , kami mengalami masalah ini di lingkungan kami dan kemudian kami menemukan masalah, dengan perbaikan ini, kami tidak pernah mengalami masalah ini lagi. Siapa pun yang mengalami masalah ini, dapatkah Anda mencoba tambalan ini dan melihat apakah itu terjadi lagi. Dan dari analisis kami, ini terkait dengan ipv6, jadi Anda juga dapat mencoba menonaktifkan ipv6 docker dengan --ipv6=false
saat memulai daemon docker
@ coolljt0725 Mungkin saya salah, tetapi ipv6 dinonaktifkan secara default di buruh pelabuhan dan saya baru saja mereproduksi masalah melalui docker-stress dengan opsi "--ipv6=false" (yang tetap merupakan default). Belum mencoba patch Anda.
@dadux Terima kasih atas bantuan Anda. Pada Kubernetes 1.3.4 CoreOS 1068 Stable, Docker 10.3, Flannel sebagai lapisan jaringan, saya telah memperbaiki masalah dengan membuat perubahan berikut di unit CoreOS saya:
- 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
Menambahkan yang berikut ke kubelet.service
:
--hairpin-mode=none
Apa pengaruh perubahan ini pada Docker/Kubernetes sehubungan dengan cara O/S menangani antarmuka untuk container ?
Saya harus menekankan bahwa ini adalah masalah dengan perilaku O/S yang salah, bukan Docker atau Kubernetes, karena kami (dan beberapa orang lain di utas ini) sama sekali tidak menjalankan Docker atau Kubernetes, tetapi masih menghadapi situasi yang persis sama ketika menghentikan LXC kontainer cukup cepat satu demi satu.
@rdelangh Anda benar. Namun, masalah ini dibuat di proyek Docker untuk melacak perilaku yang berkaitan dengan Docker. Ada masalah lain yang disebutkan dalam utas ini yang melacaknya sebagai masalah OS, masalah K8, dan masalah CoreOS. Jika Anda menemukan masalah di LXC atau yang lainnya, sangat disarankan Anda memulai utas di sana dan menautkannya di sini untuk meningkatkan kesadaran seputar masalah tersebut.
Ketika mereka yang menggunakan Docker google untuk kesalahan ini, mereka kemungkinan akan mendarat di sini. Jadi, masuk akal jika kami memposting solusi untuk masalah ini di sini sehingga sampai masalah mendasar diperbaiki, orang dapat bergerak maju.
Apa pengaruh perubahan ini pada Docker/Kubernetes sehubungan dengan cara O/S menangani antarmuka untuk container ?
- Perubahan buruh pelabuhan di posting saya memungkinkan tumpukan Kubernetes menginterogasi buruh pelabuhan dan memastikan platform sehat ketika masalah terjadi.
- perubahan
hairpin-mode
pada dasarnya memberi tahu K8 untuk menggunakan jembatandocker0
apa adanya, dan oleh karena itu tidak akan mencoba menggunakan jaringan "kernel land" dan "hairpin veth" di situlah masalahnya dimulai di Docker jalur eksekusi.
Ini adalah solusi untuk masalah ini menggunakan K8s dan Docker.
patch rekan coolljt0725 telah diantrekan untuk stabil, jadi semoga segera di-backport ke distro. (Posting David Miller: http://www.spinics.net/lists/netdev/msg393688.html )
Tidak yakin di mana komit itu berada dan apakah kita harus mengirimkannya ke Ubuntu, RH, dll. untuk membantu mereka melacak & mem-backportnya?
Akan muncul di sini di beberapa titik saya kira:
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/ipv6/addrconf.c
EDIT: tampaknya ada di sini: https://github.com/torvalds/linux/blob/master/net/ipv6/addrconf.c
Terima kasih kepada coolljt0725 and co (dan semua orang di utas ini). Karena banyak orang tidak akan dapat memperbarui ke kernel dengan patch ipv6 untuk beberapa waktu, (semua orang, saat ini) saya telah berhasil mengatasi bug ini setelah mencoba banyak saran dari utas ini. Saya ingin membuat posting lengkap untuk menindaklanjuti hal-hal yang berhasil dan tidak berhasil sehingga tidak ada orang lain yang melihat masalah yang saya lihat.
TL; DR nonaktifkan ipv6 di params boot linux, reboot. pada coreos ini berarti /usr/share/oem/grub.cfg
memiliki konten: set linux_append="ipv6.disable=1"
dan kemudian reboot. saran tujuan yang lebih umum yang harus bekerja pada centos/ubuntu/debian/$linux dapat ditemukan di sini
dockerd
satu --ipv6=false
—iptables=false
—ip-forward=false
—icc=false
—ip-masq=false
—userland-proxy=false
menariknya, --ipv6=false
tampaknya tidak melakukan apa -
--userland-proxy=false
menyetel mode jepit rambut dan tidak diharapkan benar-benar berfungsi. sehubungan dengan ini saya memiliki beberapa harapan tetapi ini juga tidak menyelesaikan masalah (mengatur docker0 ke mode promisc). Ada penyebutan perbaikan untuk --userland-proxy=false
sini dan ini mungkin akan segera upstream dan layak dicoba lagi, alangkah baiknya untuk mematikan ini terlepas dari bug yang dicatat dalam masalah ini untuk kinerja tetapi sayangnya masih ada lagi bug saat ini.
terlalu panjang; memang membaca: nonaktifkan ipv6 di pengaturan grub Anda. menyalakan ulang. laba.
Menghadapi masalah ini pada CentOS 7.2 (3.10.0-327.28.3.el7.x86_64) dan Docker 1.12.1 (tanpa k8s). Masalah muncul ketika lalu lintas jaringan meningkat.
Boot kernel dengan ipv6 dinonaktifkan (sesuai saran sebelumnya) tidak membantu.
Tetapi mengubah antarmuka docker0 menjadi mode promisc telah memperbaikinya. Sistemd drop-in bekas oleh
@rdallman Menonaktifkan ipv6 melalui grub tidak mencegah unregister_netdevice
bagi saya baik di ubuntu 16.06 (kernel 4.4.0-36-generic) atau 14.04 (kernel 3.13.0-95-generic). Terlepas dari pengaturan --userland-proxy
(baik benar atau salah).
Ooooh, itu keren patch itu antri untuk stabil.
ping @aboch untuk masalah yang --ipv6=false
tidak melakukan apa-apa.
@trifle maaf :( terima kasih telah memposting info, kami belum mengalami masalah setelah beberapa hari pengujian tetapi akan memperbarui kembali jika kami mengalami masalah. kami menjalankan coreos 1122.2 (kernel 4.7.0). pengaturan docker0 ke mode promisc tampaknya memperbaiki ini untuk sebagian orang (tidak beruntung bagi kami).
@RRAlex Apakah Anda tahu jika ada yang menghubungi tim kernel Ubuntu mengenai backport? Kami memiliki penyebaran Docker produksi besar di kluster Ubuntu yang terpengaruh oleh bug.
Milis tim kernel Ubuntu:
https://lists.ubuntu.com/archives/kernel-team/2016-September/thread.html
Patch untuk kernel yang stabil:
https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d
Log komit kernel Ubuntu:
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/?h=master-next
(Patch belum ada)
@leonsp Saya mencoba menghubungi mereka tentang apa yang tampaknya menjadi masalah terkait:
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1403152
Jika Anda melihat balasan terakhir (#79), seseorang membuat kernel untuk Xenial dengan tambalan itu:
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1403152
Tidak yakin kapan itu masuk ke pohon kernel utama Ubuntu atau apa hubungan orang ini dengan Ubuntu dan apakah itu akan membantu ...
Saya juga tidak dapat menemukan komit yang disebutkan dari utas itu di log komit kernel Ubuntu.
@RRAlex Komit yang disebutkan ada di cabang ddstreet ~ddstreet/+git/ linux:lp1403152-xenial , ini lognya: https://code.launchpad.net/~ddstreet/+git/linux/+ref/lp1403152-xenial
Jadi, siapa pun dengan masalah ini di Ubuntu 16.04 dapat mencobanya. https://launchpad.net/~ddstreet/+archive/ubuntu/lp1403152
Mungkin @sforshee tahu (untuk kernel Ubuntu)
Saya akhirnya berhasil menguji solusi "ipv6.disable=1". Selain itu - saya telah memutakhirkan ke kernel 4.7.2 di debian 8 saya.
Setelah pemutakhiran kernel dan mengaktifkan "ipv6.disable=1" dalam parameter kernel, saya telah berhasil menangkap masalah "menunggu lo" pada beban kerja nyata bahkan tanpa tanda "--userland-proxy=false" untuk daemon buruh pelabuhan. Berita baiknya adalah setelah menentukan "--userland-proxy=false" dan mencoba mereproduksi masalah dengan "docker-stress" - saya tidak bisa lagi melakukannya. Tapi saya cukup yakin itu akan muncul lagi terlepas dari nilai "--userland-proxy".
Jadi dari apa yang saya lihat - ipv6 pasti terlibat dalam masalah ini, karena sekarang docker-stress tidak lagi dapat menangkap masalah tersebut. Kabar buruknya adalah bahwa masalahnya sebenarnya masih ada (yaitu: hanya diperbaiki sebagian).
Akan mengkompilasi 4.8rc7 terbaru nanti untuk menguji lebih banyak.
@twang2218 @coolljt0725
Hmmm.. jadi saya baru saja mencoba kernel Ubuntu xenial 4.4.0-36 dengan patch yang di-backport dari ppa ddstreet :
$ uname -a
Linux paul-laptop 4.4.0-36-generic #55hf1403152v20160916b1-Ubuntu SMP Fri Sep 16 19:13:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Sayangnya, ini sepertinya tidak menyelesaikan masalah bagi saya. Perhatikan bahwa saya juga menjalankan dengan "ipv6.disable=1". Apakah kita melihat beberapa penyebab yang tidak terkait dengan hasil yang sama? Banyak komentar di utas ini tampaknya menyarankan demikian.
Saya tidak tahu banyak tentang ini, tetapi saya tahu kami pernah memiliki bug seperti ini sebelumnya. Seperti yang saya pahami, jumlah referensi ke perangkat jaringan apa pun akhirnya ditransfer ke lo ketika ruang nama jaringan sedang dibersihkan, jadi "menunggu lo menjadi gratis" berarti ada kebocoran jumlah referensi untuk beberapa perangkat bersih tetapi tidak harus untuk lo secara langsung. Itu membuat ini beruang untuk dilacak, karena pada saat Anda tahu ada kebocoran, Anda tidak tahu perangkat apa yang terkait dengannya.
Saya belum membaca kembali semua komentar, tetapi jika seseorang dapat memberi saya reproduksi yang andal di Ubuntu, saya akan melihatnya dan melihat apakah saya dapat menemukan sesuatu.
@sforshee tidak selalu mudah untuk direproduksi, tetapi ada tambalan yang dibuat (yang setidaknya memperbaiki beberapa kasus yang dilaporkan di sini); http://www.spinics.net/lists/netdev/msg393441.html. Itu diterima di hulu https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d
@thaJeztah ah, saya melihat pertanyaan yang Anda arahkan kepada saya sekarang.
Jadi tambalan berada dalam antrian stabil 4.4 upstream, untuk 16.04 kemungkinan besar tidak akan dimasukkan ke dalam SRU kernel berikutnya (yang sudah dalam proses) tetapi yang setelah itu, sekitar 5-6 minggu dari sekarang. Jika diperlukan di 14,04 juga, beri tahu saya agar dapat di-backport.
@sforshee pada dasarnya lebih awal (sebelum tambalan itu) yang dapat direproduksi dengan mengaktifkan ipv6 di kernel (biasanya diaktifkan secara default), menambahkan "--userland-proxy=false" ke bendera daemon buruh pelabuhan dan kemudian menjalankan docker-stress -c 100
, untuk contoh (docker-stress berasal dari sini: https://github.com/crosbymichael/docker-stress)
@fxposter terima kasih. Jika ada perbaikan untuk yang itu, yang benar-benar perlu saya khawatirkan adalah memasukkan perbaikan itu ke dalam kernel Ubuntu. Saya juga dapat membantu melihat kebocoran lain yang tidak diperbaiki oleh tambalan itu.
Saya mengalami masalah ini juga. Saya menjalankan buruh pelabuhan di dalam kotak rancherOS dari AWS. Sebenarnya, itu terjadi secara acak setelah menyiapkan cluster peternak (3 host) dan menjalankan aplikasi kecil di dalamnya.
sama ... Fedora 24, terjadi secara acak, bisa baik-baik saja selama seminggu, daripada yang saya dapatkan setiap 10 jam
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1
Mengalami CentOS 7 yang menjalankan kernel 3.10.0-327.36.1.el7 dan buruh pelabuhan 1.12.1
Menurunkan versi ke kernel 3.10.0-327.18.2.el7 sementara tetap menggunakan buruh pelabuhan 1.12.1, tampaknya telah menstabilkan sistem.
Saya juga melihat ini:
Docker versi 1.11.2
Ubuntu 16.04.1 4.4.0-38-generik
ipv6 dinonaktifkan (grub)
Baru saja mengalami masalah ini tanpa --userland-proxy=false
(sic!) di server dengan kernel 4.8.0-rc7, yang mencakup patch ipv6 (sic!!). Jadi mungkin itu memperbaiki beberapa masalah, tetapi tidak semuanya, pasti.
Adakah yang tahu bagaimana ini bisa di-debug sama sekali?
Kami menemukan bahwa ini hanya terjadi pada pengaturan kami ketika kami (hampir) kehabisan memori bebas.
@fxposter Akan berguna untuk menemukan kasus reproduksi minimal, yang agak sulit:/ Kemudian kita bisa menggunakan ftrace untuk setidaknya menemukan jalur kode.
Terjadi pada 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 sayangnya tidak mungkin lagi untuk mereproduksi melalui docker-stress (setidaknya saya tidak bisa). Saya akan mencoba meniru pengaturan kami sebelumnya dengan webkit (yang memicu masalah ini lebih sering daripada yang saya inginkan).
@fxposter Tambalan itu hanya memperbaiki beberapa masalah (tetapi di lingkungan kami, kami tidak pernah menemukannya lagi dengan tambalan itu), tidak semua, saya akan membiarkan rekan saya terus mencari masalah ini. Jika Anda memiliki cara untuk mereproduksi ini, beri tahu saya, terima kasih :)
Perbaikannya ada di 4.4.22 stabil https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.22
Saya memposting permintaan Redhat untuk menerapkan tambalan ini ke Fedora 24.
4.4.0-42 pasti masih rusak...
Saya menyebutkannya di sini untuk Ubuntu, tetapi mungkin seseorang memiliki ide yang lebih baik:
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1403152
Saya juga melihat ini, Docker versi 1.11.2, build b9f10c9/1.11.2, 64bit Amazon Linux 2016.03 v2.1.6.
masih terjadi. buruh pelabuhan 1.12.2, kernel linux armbian 4.8.4, ipv6.disable=1 di bootargs
cara perbaiki bug nya tiap hari ketemu
@woshihaoren Jangan gunakan --userland-proxy=false
Untuk memperjelas - kami menghadapinya dengan proksi userland yang dinonaktifkan juga
Mendapatkan ini di Amazon Linux AMI 2016.9:
$ uname -a
Linux 4.4.23-31.54.amzn1.x86_64 #1 SMP
Versi buruh pelabuhan:
``` Klien:
Versi: 1.11.2
Versi API: 1.23
Pergi versi: go1.5.3
Git commit: b9f10c9/1.11.2
Dibuat:
OS/Arch: linux/amd64
Server:
Versi: 1.11.2
Versi API: 1.23
Pergi versi: go1.5.3
Git commit: b9f10c9/1.11.2
Dibuat:
OS/Arch: linux/amd64
```
centos7 kernel 4.4.30 lagi~~~~
CoreOS 1185.3.0, 4.7.3-coreos-r2, Docker 1.11.2
Dapat direproduksi hanya dengan menjalankan 10..20 debian:jessie container dengan "apt-get update" sebagai perintah.
CoreOS stable saat ini masih hits. Perbaikan untuk seri 4.7 ada di 4.7.5: https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.7.5
commit 4e1b3aa898ea93ec10e48c06f0e511de37c35b2d
Author: Wei Yongjun <[email protected]>
Date: Mon Sep 5 16:06:31 2016 +0800
ipv6: addrconf: fix dev refcont leak when DAD failed
TL; DR - Tidak ada solusi dalam posting ini, tetapi saya membuat daftar apa yang telah saya kejar sejauh ini dan teori kerja saya saat ini. Saya berharap orang lain yang juga mengejar ini mungkin menemukan beberapa info di sini bermanfaat saat kami menjalankannya.
@koendc Terima kasih telah memposting tambalan yang diperkenalkan ke 4.7.5. Aku kembali porting 4e1b3aa898ea93ec10e48c06f0e511de37c35b2d (751eb6b6042a596b0080967c1a529a9fe98dac1d hulu) Patch untuk 4.5.5 setup saya [1] dan dapat dengan mudah mereproduksi masalah unregister_netdevice. Ada kemungkinan bahwa perubahan lain di kernel 4.7.x bekerja sama dengan tambalan yang disediakan untuk mengatasi masalah ini, tetapi saya belum mengonfirmasinya, jadi kita tidak boleh kehilangan semua harapan. Saya menguji dengan 4.5.5 karena saya memiliki kasus uji yang dapat direproduksi untuk menyebabkan masalah, dibahas dalam [2].
Hal-hal lain yang telah saya konfirmasi berdasarkan pengujian:
Langkah selanjutnya:
IPv6: eth0: IPv6 duplicate address <blah> detected
sangat menarik. Mungkin ikan haring merah lainnya, tetapi saya ingin mencoba melakukan penonaktifan ipv6 untuk melihat apakah ada korelasinya[1] Pengaturan lengkap saya adalah virt GCE yang menjalankan kernel debian yang sedikit disesuaikan berdasarkan 4.5.5
. Docker version 1.8.3, build f4bf5c7
berjalan di atas itu
[2] Informasi kasus uji: Saya memiliki 20 proses paralel, masing-masing memulai server hello world Node.js di dalam wadah buruh pelabuhan. Alih-alih mengembalikan hello world
, server Node.js mengembalikan 1 MB teks acak. Proses induk berada dalam loop ketat yang memulai penampung, menggulung untuk mengambil data 1MB, dan menghentikan penampung. Dengan menggunakan pengaturan ini, saya dapat secara konsisten mereproduksi masalah dalam 4-90-an. Menggunakan penyiapan yang sama ini pada host fisik atau di dalam kotak virtual tidak mereproduksi masalah, meskipun berbagai item yang mengubah waktu rata-rata untuk reproduksi pada kotak GCE. Variabel yang saya mainkan: jumlah proses pengujian bersamaan, ukuran payload yang ditransfer, dan jumlah panggilan curl. Dua variabel pertama pasti berkorelasi, meskipun saya pikir itu mungkin hanya menyesuaikan variabel untuk menemukan titik jenuh yang wajar untuk virt.
Saya juga mengalami kesalahan ini.
Saya melihatnya diulang 3 kali setelah menyebarkan wadah.
Keterangan
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1
Langkah-langkah untuk mereproduksi masalah:
docker run -d --network=anetwork --name aname -p 9999:80 aimagename
Jelaskan hasil yang Anda terima:
Hanya mendapatkan kesalahan berulang 3 kali.
Jelaskan hasil yang Anda harapkan:
Tidak ada kesalahan
Informasi tambahan yang Anda anggap penting (misalnya masalah hanya terjadi sesekali):
Baru mulai terjadi setelah akhir pekan ini.
Keluaran dari docker version
:
docker --version
Docker version 1.12.3, build 6b644ec
Keluaran dari 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
Detail lingkungan tambahan (AWS, VirtualBox, fisik, dll.):
Mesin virtual:
Fedora 24
OverlayFS2 pada ext3
Drive terpisah yang dialokasikan untuk penggunaan buruh pelabuhan 24 pertunjukan.
16 gigs ram.
PS Docker
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
Gambar buruh pelabuhan
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
Volume Docker Ls
DRIVER VOLUME NAME
local 3bc848cdd4325c7422284f6898a7d10edf8f0554d6ba8244c75e876ced567261
local 6575dad920ec453ca61bd5052cae1b7e80197475b14955115ba69e8c1752cf18
local bf73a21a2f42ea47ce472e55ab474041d4aeaa7bdb564049858d31b538bad47b
local c1bf0761e8d819075e8e2427c29fec657c9ce26bc9c849548e10d64eec69e76d
local e056bce5ae34f4066d05870365dcf22e84cbde8d5bd49217e3476439d909fe44
* DF -H *
df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 7.9G 0 7.9G 0% /dev
tmpfs 7.9G 0 7.9G 0% /dev/shm
tmpfs 7.9G 1.3M 7.9G 1% /run
tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup
/dev/mapper/fedora-root 11G 1.6G 8.7G 16% /
tmpfs 7.9G 8.0K 7.9G 1% /tmp
/dev/sda1 477M 130M 319M 29% /boot
/dev/sdb1 24G 1.6G 21G 7% /docker
overlay 24G 1.6G 21G 7% /docker/overlay2/5591cfec27842815f5278112edb3197e9d7d5ab508a97c3070fb1a149d28f9f0/merged
shm 64M 0 64M 0% /docker/containers/35ee0c906a03422e1b015c967548582eb5ca3195b3ffdd040bb80df9bb77cd32/shm
overlay 24G 1.6G 21G 7% /docker/overlay2/73e795866566e845f09042d9f7e491e8c3ac59ebd7f5bc0ee4715d0f08a12b7b/merged
shm 64M 4.0K 64M 1% /docker/containers/7ea48b27eb854e769886f3b662c2031cf74f3c6f77320a570d2bfa237aef9d2b/shm
overlay 24G 1.6G 21G 7% /docker/overlay2/fad7f3b483bc48b83c3a729368124aaaf5fdd7751fe0a383171b8966959ac966/merged
shm 64M 0 64M 0% /docker/containers/116ad8850bb1c74d1a33b6416e1b99775ef40aa13fc098790b7e4ea07e3e6075/shm
overlay 24G 1.6G 21G 7% /docker/overlay2/456c40bc86852c9f9c9ac737741b57d30f2167882f15b32ac25f42048648d945/merged
shm 64M 0 64M 0% /docker/containers/a411d09d7f98e1456a454a399fb68472f5129df6c3bd0b73f59236e6f1e55e74/shm
overlay 24G 1.6G 21G 7% /docker/overlay2/3ee2b1b978b048f4d80302eec129e7163a025c7bb8e832a29567b64f5d15baa0/merged
shm 64M 0 64M 0% /docker/containers/32e555609cd2c77a1a8efc45298d55224f15988197ef47411a90904cf3e13910/shm
overlay 24G 1.6G 21G 7% /docker/overlay2/3e1cdabc2ae422a84b1d4106af1dde0cd670392bbe8a9d8f338909a926026b73/merged
shm 64M 0 64M 0% /docker/containers/345eaab3b289794154af864e1d14b774cb8b8beac8864761ac84051416c7761b/shm
overlay 24G 1.6G 21G 7% /docker/overlay2/6bfc33084abe688af9c1a704a0daba496bee7746052103ef975c76d2c74d6455/merged
shm 64M 0 64M 0% /docker/containers/111ad12b877f4d4d8b3ab4b44b06f645acf89b983580e93d441305dcc7926671/shm
overlay 24G 1.6G 21G 7% /docker/overlay2/0b454336447a39d06966adedf4dc4abed6405212107a2f8f326072ae5fb58b3d/merged
shm 64M 0 64M 0% /docker/containers/43cfe7eae9cf310d64c6fe0f133152067d88f8d9242e48289148daebd9cb713d/shm
overlay 24G 1.6G 21G 7% /docker/overlay2/0d8bba910f1f5e928a8c1e5d02cc55b6fe7bd7cd5c4d23d4abc6f361ff5043ac/merged
shm 64M 0 64M 0% /docker/containers/3727b3e57e2f5c3b7879f
DF -i
df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
devtmpfs 2051100 411 2050689 1% /dev
tmpfs 2054171 1 2054170 1% /dev/shm
tmpfs 2054171 735 2053436 1% /run
tmpfs 2054171 16 2054155 1% /sys/fs/cgroup
/dev/mapper/fedora-root 5402624 53183 5349441 1% /
tmpfs 2054171 8 2054163 1% /tmp
/dev/sda1 128016 350 127666 1% /boot
/dev/sdb1 1572864 72477 1500387 5% /docker
overlay 1572864 72477 1500387 5% /docker/overlay2/5591cfec27842815f5278112edb3197e9d7d5ab508a97c3070fb1a149d28f9f0/merged
shm 2054171 1 2054170 1% /docker/containers/35ee0c906a03422e1b015c967548582eb5ca3195b3ffdd040bb80df9bb77cd32/shm
overlay 1572864 72477 1500387 5% /docker/overlay2/73e795866566e845f09042d9f7e491e8c3ac59ebd7f5bc0ee4715d0f08a12b7b/merged
shm 2054171 2 2054169 1% /docker/containers/7ea48b27eb854e769886f3b662c2031cf74f3c6f77320a570d2bfa237aef9d2b/shm
overlay 1572864 72477 1500387 5% /docker/overlay2/fad7f3b483bc48b83c3a729368124aaaf5fdd7751fe0a383171b8966959ac966/merged
shm 2054171 1 2054170 1% /docker/containers/116ad8850bb1c74d1a33b6416e1b99775ef40aa13fc098790b7e4ea07e3e6075/shm
overlay 1572864 72477 1500387 5% /docker/overlay2/456c40bc86852c9f9c9ac737741b57d30f2167882f15b32ac25f42048648d945/merged
shm 2054171 1 2054170 1% /docker/containers/a411d09d7f98e1456a454a399fb68472f5129df6c3bd0b73f59236e6f1e55e74/shm
overlay 1572864 72477 1500387 5% /docker/overlay2/3ee2b1b978b048f4d80302eec129e7163a025c7bb8e832a29567b64f5d15baa0/merged
shm 2054171 1 2054170 1% /docker/containers/32e555609cd2c77a1a8efc45298d55224f15988197ef47411a90904cf3e13910/shm
overlay 1572864 72477 1500387 5% /docker/overlay2/3e1cdabc2ae422a84b1d4106af1dde0cd670392bbe8a9d8f338909a926026b73/merged
shm 2054171 1 2054170 1% /docker/containers/345eaab3b289794154af864e1d14b774cb8b8beac8864761ac84051416c7761b/shm
overlay 1572864 72477 1500387 5% /docker/overlay2/6bfc33084abe688af9c1a704a0daba496bee7746052103ef975c76d2c74d6455/merged
shm 2054171 1 2054170 1% /docker/containers/111ad12b877f4d4d8b3ab4b44b06f645acf89b983580e93d441305dcc7926671/shm
overlay 1572864 72477 1500387 5% /docker/overlay2/0b454336447a39d06966adedf4dc4abed6405212107a2f8f326072ae5fb58b3d/merged
shm 2054171 1 2054170 1% /docker/containers/43cfe7eae9cf310d64c6fe0f133152067d88f8d9242e48289148daebd9cb713d/shm
overlay 1572864 72477 1500387 5% /docker/overlay2/0d8bba910f1f5e928a8c1e5d02cc55b6fe7bd7cd5c4d23d4abc6f361ff5043ac/merged
shm 2054171 1 2054170 1% /docker/containers/3727b3e57e2f5c3b7879f23deb3b023d10c0b766fe83e21dd389c71021af371f/shm
tmpfs 2054171 5 2054166 1% /run/user/0
Gratis -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
Bagi mereka yang tertarik, kami (Travis CI) meluncurkan peningkatan ke v4.8.7
di Ubuntu 14.04. Tes beban kami tidak menunjukkan terjadinya kesalahan yang dijelaskan di sini. Sebelumnya, kami menjalankan linux-image-generic-lts-xenial di Ubuntu 14.04. Saya berencana untuk menerbitkan posting blog dalam waktu dekat yang menjelaskan lebih banyak detail.
PEMBARUAN : Saya seharusnya menyebutkan bahwa kami menjalankan tumpukan buruh pelabuhan ini:
Client:
Version: 1.12.3
API version: 1.24
Go version: go1.6.3
Git commit: 6b644ec
Built: Wed Oct 26 21:44:32 2016
OS/Arch: linux/amd64
Server:
Version: 1.12.3
API version: 1.24
Go version: go1.6.3
Git commit: 6b644ec
Built: Wed Oct 26 21:44:32 2016
OS/Arch: linux/amd64
UPDATE : Kami _still_ melihat kesalahan ini dalam produksi di Ubuntu Trusty + kernel v4.8.7. Kami belum tahu mengapa kesalahan ini hilang dalam uji beban pementasan yang sebelumnya mereproduksi kesalahan, namun tingkat kesalahan dalam produksi secara efektif sama. Ke depan dan ke atas. Kami telah menonaktifkan "ledakan otomatis" berdasarkan kesalahan ini mengingat tingginya tingkat pergantian instans .
juga ditemukan di centos 7
Message from syslogd@c31392666b98e49f6ace8ed65be337210-node1 at Nov 17 17:28:07 ...
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1
Message from syslogd@c31392666b98e49f6ace8ed65be337210-node1 at Nov 17 17:32:47 ...
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1
Message from syslogd@c31392666b98e49f6ace8ed65be337210-node1 at Nov 17 17:37:32 ...
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1
Message from syslogd@c31392666b98e49f6ace8ed65be337210-node1 at Nov 17 17:37:42 ...
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1
[root@c31392666b98e49f6ace8ed65be337210-node1 ~]# docker info
Containers: 19
Running: 15
Paused: 0
Stopped: 4
Images: 23
Server Version: 1.11.2.1
Storage Driver: overlay
Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local nas acd ossfs
Network: vpc bridge null host
Kernel Version: 4.4.6-1.el7.elrepo.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.795 GiB
Name: c31392666b98e49f6ace8ed65be337210-node1
ID: WUWS:FDP5:TNR6:EE5B:I2KI:O4IT:TQWF:4U42:5327:7I5K:ATGT:73KM
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/
WARNING: bridge-nf-call-ip6tables is disabled
Cluster store: etcd://test.com:2379
Cluster advertise: 192.168.0.2:2376
Hal yang sama terjadi di sini dengan VPS DigitalOcean pada pengujian Debian:
# journalctl -p0 | tail -15
Nov 19 12:02:55 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 12:03:05 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 12:17:44 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 12:48:15 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 13:33:08 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 14:03:04 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 14:03:14 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 14:17:59 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 15:03:02 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 15:18:13 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 15:32:44 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 16:03:13 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 16:47:43 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 17:17:46 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Nov 19 17:17:56 hostname kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1
Sistem
$ 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
Saya telah menguji 4.8.8 dalam lingkaran yang ketat (lihat [2] dari komentar saya sebelumnya untuk kasus uji) tanpa henti selama 4 hari terakhir. Sejauh ini baik.
Fakta
pengandaian
@meatballhat menunjukkan bahwa server produksi mereka mengalami masalah saat menjalankan 4.8.7. Ini memberi kita dua kemungkinan:
Bisakah kita meminta beberapa orang untuk mencoba 4.8.8 untuk melihat apakah mereka dapat mereproduksi masalah ini?
@reshen Saya akan membuat kami diperbarui ke 4.8.8 dan melaporkan kembali :+1: Terima kasih banyak atas penelitian Anda!
@reshen Penelitian yang luar biasa. Sejauh ini saya juga belum dapat mereproduksi masalah menggunakan Linux 4.8.8 di Xubuntu 16.04.
Saya telah menggunakan kernel mainline Ubuntu build . Saya tidak memiliki kasus uji yang terdefinisi dengan baik, tetapi saya dapat secara konsisten mereproduksi masalah sebelumnya dengan memulai dan menghentikan set wadah buruh pelabuhan yang saya gunakan.
Untuk menguji Linux 4.8.8, yang paling mudah bagi saya adalah beralih dari aufs ke overlay2 sebagai driver penyimpanan karena pembuatan kernel arus utama tidak menyertakan aufs. Saya tidak berpikir akan mempengaruhi tes, tetapi harus diperhatikan.
Sebelumnya saya telah menguji Linux 4.4.4 dengan 751eb6b6 yang di-backport oleh Dan Streetman, hal ini tampaknya tidak mengurangi masalah bagi saya. Akan menarik untuk melihat apakah mem-backport kedua patch yang Anda catat (5086cadf dan 6fff1319) dapat memberikan hasil yang sama seperti 4.4.8.
Ubuntu 16.04 dengan 4.4.0-47 masih terpengaruh... mencoba 4.4.0-49 sekarang, akan melaporkan nanti.
sunting: 28-11-2016: -49 sedang menunjukkan baris log itu di dmesg.
Mengalami ini di Fedora 25 (kernel 4.8.8) dan Docker 1.12.3
FYI: kami telah menjalankan Linux 4.8.8 bersama dengan Docker v1.12.3 pada satu host produksi. Uptime saat ini adalah 5,5 hari dan mesin tetap stabil.
Terkadang kita melihat beberapa pesan unregister_netdevice: waiting for lo to become free. Usage count = 1
di syslog, tetapi tidak seperti sebelumnya, kernel tidak crash dan pesan tersebut hilang. Saya menduga bahwa salah satu perubahan lain yang diperkenalkan baik di Kernel atau di Docker mendeteksi kondisi ini dan sekarang pulih darinya. Bagi kami, ini sekarang membuat pesan ini mengganggu tetapi tidak lagi menjadi bug kritis.
Saya berharap beberapa orang lain dapat mengkonfirmasi hal di atas pada armada produksi mereka.
@gtirloni - dapatkah Anda mengklarifikasi jika mesin 4.8.8/1.12.3 Anda mogok atau jika Anda baru saja melihat pesannya?
Terima kasih sebelumnya kepada semua orang yang telah bekerja mereproduksi/memberikan informasi yang berguna untuk triangulasi hal ini.
kami menghapus mitra dari antarmuka veth (docker0) setelah memulai docker dan memulai ulang docker setelah itu ketika kami menyediakan Host menggunakan ansible. Masalah tidak terjadi sejak itu.
Saya juga mendapatkan kesalahan yang sama pada Raspberry Pi 2 yang menjalankan Raspbian dengan Docker.
info kernel
Linux rpi2 4.4.32-v7+ #924 SMP Tue Nov 15 18:11:28 GMT 2016 armv7l GNU/Linux
Info buruh pelabuhan
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
Itu terjadi setelah membuat wadah yang membutuhkan sekitar ~ 50Mb program yang diunduh diinstal.
Hanya reboot yang memungkinkan saya menggunakan mesin lagi
Saya sebenarnya melihat ini di Amazon Linux di klaster ECS - pesan terkadang muncul tetapi tidak terkunci, seperti yang dilihat reshen sekarang. Buruh 1.11.2. Uname melaporkan "4.4.14-24.50.amzn1.x86_64" sebagai versi.
@reshen Saya akan membuat 4.8.8 akhir pekan ini di laptop saya dan melihat apakah itu
memperbaikinya untuk saya!
ᐧ
Pada Kam, 1 Des 2016 jam 10:29, Ernest Mueller [email protected]
menulis:
Saya sebenarnya melihat ini di Amazon Linux di klaster ECS - pesannya
sesekali melempar tapi tidak mengunci, seperti yang dilihat reshen sekarang.
Buruh 1.11.2. Uname melaporkan "4.4.14-24.50.amzn1.x86_64" sebagai versi.—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/5618#issuecomment-264220432 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/AKklVRqoBUZDu3HMhGv3b6knnA6j6C_Qks5rDvXRgaJpZM4B4L4Z
.
--
Keifer Furzland
http://kfrz.work
Saya juga dapat mereproduksi masalah ini menggunakan https://github.com/crosbymichael/docker-stress pada node pekerja Kubernetes yang menjalankan CoreOS Stable 1185.3.0.
Menjalankan docker_stress_linux_amd64 -k 3s -c 5 --containers 1000
: 5 pekerja bersamaan membuat/menghapus container, masa pakai maksimum container = 3 detik, membuat hingga 1000 container pada instans m4.large di AWS akan membuat daemon Docker tidak responsif setelah sekitar tiga menit.
Upgrade ke CoreOS Beta 1235.1.0 dan saya belum dapat mereproduksi (baik pesan tidak responsif atau unregister_netdevice
di log kernel). Sedangkan menjalankan 5 pekerja docker_stress bersamaan akan membunuh CoreOS Stable setelah beberapa menit, saya dapat menjalankan dengan 10 dan 15 pekerja bersamaan hingga pengujian selesai menggunakan CoreOS Beta.
CoreOS dirilis dalam "saluran" sehingga tidak mungkin untuk memutakhirkan kernel secara terpisah. Berikut adalah perbedaan utama antara stabil dan beta:
Melihat masalah ini di Amazon Elastic Beanstalk yang menjalankan 4.4.23-31.54.amzn1.x86_64
Hanya Terjadi di CoreOS Stable 1185.5.0, Docker 1.12.2
Setelah reboot semuanya baik-baik saja
Pembaruan: masalah daemon Docker yang macet telah menyerang lagi pada host yang menjalankan CoreOS Beta 1235.1.0 dengan Docker v1.12.3, dan kernel Linux v4.8.6. 😢
1.12.4 dan 1.13 seharusnya, secara teori, tidak berhenti ketika masalah kernel ini terjadi.
Alasan terjadinya freeze di daemon docker adalah karena daemon sedang menunggu pesan netlink kembali dari kernel (yang tidak akan pernah datang) sambil menahan kunci pada objek container.
1.12.4 dan 1.13 menetapkan batas waktu pada permintaan netlink ini untuk setidaknya melepaskan kunci kontainer.
Ini __not__ memperbaiki masalah, tetapi setidaknya (semoga) tidak membekukan seluruh daemon.
Anda mungkin tidak akan dapat memutar wadah baru, dan mungkin juga tidak akan dapat meruntuhkannya karena sepertinya semua interaksi dengan netlink terhenti setelah masalah ini terjadi.
@cpuguy83 FWIW, semua container yang berjalan terus berjalan tanpa masalah AFAIK saat daemon digantung. Memang, ini adalah awal dan penghentian kontainer yang terlihat (terutama yang berjalan di Kubernetes, seperti kita).
Ini tidak memperbaiki masalah, tetapi setidaknya (semoga) tidak membekukan seluruh daemon.
Satu-satunya keuntungan dari seluruh daemon yang dibekukan adalah mudah untuk diketahui. Kubernetes dapat mengusir node, bahkan mungkin reboot secara otomatis. Haruskah daemon terus berjalan, apakah masih mungkin untuk menemukan masalah kernel yang muncul dengan mudah?
@seanknox Saya dapat memberi Anda AMI CoreOS 1248.1.0 khusus dengan Docker yang ditambal (CoreOS Docker 1.12.3 + Patch 1.12.4-rc1 Upstream). Ini telah memperbaiki hangup setiap beberapa jam di cluster CoreOS/K8s saya. Cukup ping saya dengan ID Akun AWS Anda di Deis Slack.
Kami mendapat masalah besar dengan masalah ini di klaster CoreOS kami. Adakah yang bisa memberi tahu kapan akhirnya akan diperbaiki? Kami bermimpi tentang saat ini ketika kami bisa tidur di malam hari.
@DenisIzmaylov Jika Anda tidak menetapkan --userland-proxy=false
, maka secara umum Anda seharusnya tidak mengalami masalah ini.
Tetapi selain itu, ini adalah bug di kernel, mungkin beberapa bug kernel, yang beberapa orang katakan diselesaikan di 4.8 dan yang lain mengatakan tidak. Bagi sebagian orang, menonaktifkan ipv6 tampaknya memperbaikinya, yang lain tidak (karenanya mungkin banyak masalah ... atau setidaknya beberapa penyebab).
Saya telah melihat masalah ini dalam beberapa jam pada sistem beban tinggi dengan dan tanpa --userland-proxy=false
Dikonfirmasi bahwa kita masih melihat kesalahan unregister_netdevice
pada kernel 4.8.12 . Dibutuhkan sekitar 5 hari untuk memicu. Hanya reboot sistem yang tampaknya pulih dari masalah. Menghentikan Docker tampaknya hang tanpa batas.
Belum mencoba trik menonaktifkan ipv6 untuk boot kernel.
Containers: 17
Running: 14
Paused: 0
Stopped: 3
Images: 121
Server Version: 1.10.3
Storage Driver: overlay
Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
Volume: local
Network: bridge null host
Kernel Version: 4.8.12-1.el7.elrepo.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 24
Total Memory: 62.86 GiB
Name: **REDACTED***
ID: **REDACTED***
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Akan luar biasa jika seseorang dapat mencoba ini dengan 1.12.5, yang seharusnya habis pada permintaan netlink yang macet sekarang alih-alih hanya menggantung Docker.
@ cpuguy83 namun, sistem masih tidak dapat digunakan dalam keadaan itu :)
@LK4D4 Oh, benar-benar, hanya ingin melihat batas waktu itu ;)
Mendapatkan masalah ini di Cent OS 7:
kernel:unregister_netdevice : menunggu lo menjadi gratis. Jumlah penggunaan = 1
Linux foo 3.10.0-514.2.2.el7.x86_64 #1 SMP Sel 6 Des 23:06:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
docker-engine-1.12.5-1.el7.centos.x86_64
Ini memengaruhi build CI saya yang berjalan di dalam wadah Docker dan tampaknya tiba-tiba mati saat pesan konsol ini muncul. Apakah ada perbaikan atau solusi? Terima kasih!
@ cpuguy83 Docker tidak menggantung untuk saya ketika kesalahan ini terjadi tetapi wadah terbunuh yang dalam situasi saya merusak pekerjaan Jenkins/CI saya.
Jadi saya telah menjalankan buruh pelabuhan pada mesin centos 7 untuk sementara waktu (11 bulan?) Tanpa masalah. Hari ini saya memutuskan untuk mencoba daemon mendengarkan tcp ( menambahkan alamat mendengarkan tcp ke /etc/sysconfig/docker ) dan baru saja mendapatkan kesalahan ini.
kernel:unregister_netdevice : menunggu lo menjadi gratis. Jumlah penggunaan = 1
jadi hitungan pemakaian saya bukan 3.
Wadah: 4
Lari: 3
Dijeda: 0
Berhenti: 1
Gambar: 67
Versi Server: 1.10.3
Driver Penyimpanan: btrfs
Versi Bangun: Btrfs v4.4.1
Versi Perpustakaan: 101
Driver Eksekusi: asli-0.2
Driver Logging: file json
Plugin:
Volume: lokal
Jaringan: menjembatani null host
Versi Kernel: 3.10.0-514.2.2.el7.x86_64
Sistem Operasi: CentOS Linux 7 (Inti)
Tipe OS: linux
Arsitektur: x86_64
Jumlah Kait Docker: 2
CPU: 24
Total Memori: 39,12 GiB
Nama: aimes-web-encoder
ID: QK5Q: JCMA:ATGR :ND6W:YOT4:PZ7G:DBV5:PR26: YZQL:INRU : HAUC:CQ6B
Registri: docker.io (aman)
3.10.0-514.2.2.el7.x86_64 #1 SMP Sel 6 Des 23:06:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Klien:
Versi: 1.10.3
Versi API: 1.22
Versi paket: docker-common-1.10.3-59.el7.centos.x86_64
Pergi versi: go1.6.3
Git commit: 3999ccb-tidak didukung
Dibangun: Kam 15 Des 17:24:43 2016
OS/Arch: linux/amd64
Server:
Versi: 1.10.3
Versi API: 1.22
Versi paket: docker-common-1.10.3-59.el7.centos.x86_64
Pergi versi: go1.6.3
Git commit: 3999ccb-tidak didukung
Dibangun: Kam 15 Des 17:24:43 2016
OS/Arch: linux/amd64
Saya dapat mengkonfirmasi @aamerik. Saya melihat masalah yang sama pada versi kernel yang sama. Tidak ada perubahan besar baru-baru ini pada sistem, melihat masalah ini sejak hari ini.
Saya melihat pesan kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1
pada mesin CentOS 7 saya yang menjalankan gambar buruh pelabuhan Jenkins. Mesin CentOS 7 yang saya gunakan adalah yang terbaru dengan semua patch CentOS 7 terbaru sekitar 20 Des 2016.
Karena referensi terbaru di sini tampaknya berbasis CentOS, saya akan mengalihkan Host eksekusi saya ke Ubuntu atau mesin Debian.
Saya menjalankan Docker version 1.12.5, build 7392c3b
pada mesin CentOS 7 itu. Docker tidak hang, tetapi proses Jenkins yang saya jalankan di Docker terbunuh ketika pesan itu muncul.
Terima kasih banyak untuk Docker! Saya menggunakannya sepanjang waktu, dan saya sangat berterima kasih atas pekerjaan Anda di dalamnya!
Saya melihat masalah yang sama saat menggunakan Jenkins dengan Docker di mesin Linux 4.8.15.
Apakah ada , mencapai prosedur perbaikan untuk peternak os ?
AFAICT, ini adalah masalah penguncian di subsistem ruang nama jaringan kernel Linux. Bug ini telah dilaporkan lebih dari setahun yang lalu, tanpa balasan: https://bugzilla.kernel.org/show_bug.cgi?id=97811 Ada beberapa pekerjaan untuk ini (lihat di sini: http://www.spinics. net/lists/netdev/msg351337.html) tetapi tampaknya ini bukan perbaikan yang lengkap.
Saya sudah mencoba melakukan ping ke pengelola subsistem jaringan secara langsung, tanpa tanggapan. FWIW, saya dapat mereproduksi masalah dalam hitungan menit.
Smyte akan membayar $5000 USD untuk penyelesaian masalah ini. Sepertinya saya perlu berbicara dengan seseorang yang bekerja di kernel?
@petehunt Saya percaya ada beberapa masalah yang menyebabkan kesalahan ini.
Kami menerapkan kernel 4.8.8
seperti yang disarankan @reshen dan sementara waktu aktif tampaknya sedikit lebih baik, kami masih terus melihat masalah ini dalam produksi.
Mencoba menyebarkan Mesosphere dari node bootstrap. Semua node minimal CentOS 7.2 dengan semua pembaruan diterapkan. Node bootstrap menunjukkan kesalahan seperti yang disebutkan di atas oleh orang lain:
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
nama -r:
3.10.0-514.2.2.el7.x86_64
buruh pelabuhan -v:
Docker version 1.11.2, build b9f10c9
Saya dapat mengkonfirmasi reboot membungkam pesan, tetapi begitu saya menyebarkan mesosphere lagi, pesan mulai sesekali. Mesosphere adalah penyebaran yang cukup besar. Mungkin mereka yang mencoba membuat ulang kesalahan dapat menggunakan penginstal untuk mereproduksi kesalahan. Diperlukan beberapa menit sebelum kesalahan muncul setelah menggunakan sakelar skrip pertama ( --genconf yang merupakan langkah pertama ).
Kami telah memukul ini juga. Namun, pesan kesalahan dalam kasus kami menyebutkan perangkat eth0
bukan lo
. Kesalahan saya adalah ini:
kernel:unregister_netdevice: waiting for eth0 to become free. Usage count = 1
Saya berasumsi bahwa kesalahan seperti menyebutkan eth0
alih-alih lo
memiliki akar penyebab yang sama dengan masalah ini. Jika tidak, kita harus membuka tiket baru tentang kesalahan eth0.
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"
Kami telah memukul ini juga.
Kesalahan: unregister_netdevice: menunggu lo menjadi gratis.
OS: CentOS Linux rilis 7.3.1611 (Inti)
Kernel 3.10.0-514.2.2.el7.x86_64
Versi buruh pelabuhan: 1.13.0-cs1-rc1
Opsi buruh pelabuhan:
{
"disable-legacy-registry": benar,
"icc":benar,
"registri tidak aman":[],
"ipv6":salah,
"iptables":benar,
"storage-driver": "devicemapper",
"pilihan penyimpanan": [
"dm.thinpooldev=/dev/mapper/docker_vg-thinpool",
"dm.use_deferred_removal=true",
"dm.use_deferred_deletion=true"
],
"userland-proxy": salah
}
Saya memiliki ini di dua sistem CentOS, pembaruan terbaru setidaknya pada salah satunya.
$ uname -r
3.10.0-514.2.2.el7.x86_64
$ docker -v
Docker version 1.12.6, build 78d1802
Hai, untuk semua orang yang terpengaruh oleh masalah ini di RHEL atau CentOS, saya telah mem-backport komit dari kernel arus utama (torvalds/linux@751eb6b6042a596b0080967c1a529a9fe98dac1d) yang memperbaiki kondisi balapan di IPV6 IFP refcount ke kernel 3.10.x yang digunakan dalam distribusi perusahaan. Ini harus memperbaiki masalah ini.
Anda dapat menemukan laporan bug dengan tambalan yang berfungsi di sini :
Jika Anda tertarik untuk mengujinya dan memiliki sistem RHEL 7 atau CentOS 7, saya telah mengkompilasi kernel CentOS 7.3 3.10.0-514.6.1.el7.x86_64 terbaru dengan patch. Balas ke utas pelacak bug CentOS dan saya dapat mengirimi Anda tautan ke build.
Catatan: mungkin ada masalah lain yang menyebabkan kebocoran penghitungan ulang tetapi ini akan memperbaiki pesan kesalahan untuk banyak dari Anda.
@stefanlasiewski @henryiii @jsler
Saya akan mencoba build yang juga menambahkan perbaikan ini: http://www.spinics.net/lists/netdev/msg351337.html nanti malam.
@iamthebot apakah itu berarti bahwa jika seseorang menonaktifkan IPv6, itu juga harus memperbaiki masalah, bahkan tanpa tambalan yang baru saja Anda backport?
@redbaron hanya jika itu adalah masalah yang Anda hadapi. Saya benar-benar berpikir ada beberapa masalah kernel yang dipukul di sini.
@redbaron mungkin. #20569 tampaknya menunjukkan bahwa menonaktifkan IPV6 sepenuhnya sulit.
Jadi untuk memperjelas sedikit apa yang terjadi di balik kap mesin yang menghasilkan pesan ini, kernel mempertahankan hitungan berjalan jika perangkat sedang digunakan sebelum menghapusnya dari namespace, membatalkan pendaftarannya, menonaktifkannya, dll. Jika karena alasan tertentu ada yang menggantung referensi ke perangkat, maka Anda akan melihat pesan kesalahan itu karena tidak dapat dibatalkan pendaftarannya saat ada orang lain yang menggunakannya.
Perbaikan yang saya lihat sejauh ini:
Saya pikir masih ada kondisi balapan lain ketika mengganti ruang nama (ini tampaknya terjadi setelah membuat banyak wadah baru) tetapi saya harus mereplikasi masalah dengan andal untuk memburunya dan menulis tambalan.
Adakah yang punya prosedur minimal untuk mereproduksi ini secara konsisten? Tampaknya terjadi secara acak pada sistem kami.
@iamthebot itu tidak terlalu mudah, tapi saya pikir kami dapat memberi Anda lingkungan pengujian yang dapat mereproduksi ini dengan andal. Email saya ([email protected]) dan kami dapat mengatur detailnya.
Masih mengalami ini di bawah beban berat pada Docker versi 1.12.6, build 7392c3b/1.12.6 pada 4.4.39-34.54.amzn1.x86_64 AWS Linux AMI.
Saya memiliki 9 host buruh pelabuhan yang semuanya hampir identik, dan hanya mengalami ini pada beberapa di antaranya. Ini mungkin kebetulan, tetapi satu kesamaan yang saya perhatikan adalah bahwa saya sepertinya hanya memiliki masalah ini ketika menjalankan wadah yang tidak menangani SIGINT
. Ketika saya docker stop
wadah ini, itu hang selama 10 detik dan kemudian mematikan wadah itu dengan tidak sopan.
Dibutuhkan beberapa hari sebelum masalah muncul dengan sendirinya, dan tampaknya muncul secara acak, tidak hanya segera setelah menjalankan docker stop
. Ini sebagian besar bersifat anekdot, tetapi mungkin itu akan membantu seseorang.
Saya telah memutakhirkan semua node buruh pelabuhan saya ke kernel 3.10.0-514.6.1.el7.x86_64 pada CentOS 7.3 seperti yang disebutkan @iamthebot tetapi saya masih mendapatkan kesalahan yang sama:
26 Jan 13:52:49 Kernel XXX: unregister_netdevice: menunggu lo menjadi gratis. Jumlah penggunaan = 1
Pesan dari syslogd@XXX pada 26 Jan 13:52:49 ...
kernel:unregister_netdevice : menunggu lo menjadi gratis. Jumlah penggunaan = 1
@jsler hanya untuk memperjelas, apakah Anda menerapkan tambalan di utas pelacak bug sebelum membangun kernel? Atau apakah Anda menggunakan kernel saham? Coba juga terapkan yang ini (tambalan harus berfungsi pada kernel yang lebih lama).
Kirimi saya email ([email protected]) dan saya dapat mengirimi Anda tautan ke kernel yang sudah dibuat sebelumnya. @vitherman Sayangnya saya tidak punya banyak waktu untuk memeriksa ini (sepertinya beberapa instrumentasi perlu dikompilasi untuk menangkap bug ini) tetapi saya telah meningkatkan masalah dengan dukungan Red Hat sehingga tim kernel mereka akan mengambil Lihat.
@ckeeney saya dapat mengkonfirmasi perilaku ini. Kami memiliki aplikasi Node buruh pelabuhan yang menyebabkan kesalahan tersebut pada sistem host saat dimatikan. Setelah mengimplementasikan fungsi dalam aplikasi Node.js, yang menangkap SIGINT dan SIGTERM untuk mematikan aplikasi dengan anggun, kesalahan tidak terjadi lagi.
Yang agak masuk akal; aplikasi Node menggunakan antarmuka virtual yang dibuat Docker. Ketika Node tidak dimatikan dengan benar, perangkat hang dan sistem host tidak dapat membatalkan pendaftarannya, meskipun wadah Docker telah berhasil dihentikan.
berikut adalah contoh cuplikan kode:
function shutdown() {
logger.log('info', 'Graceful shutdown.');
httpServer.close();
if (httpsServer) {
httpsServer.close();
}
process.exit();
}
process.on('SIGINT', shutdown);
process.on('SIGTERM', shutdown);
@michael-niemand apakah ada sinyal berbeda yang ditangani dengan benar oleh Node secara default untuk shutdown bersih? (Anda dapat menentukan STOPSIGNAL
pada gambar, atau pada docker run
melalui flag --stop-signal
.
@thaJeztah untuk penjelasan masalah yang baik, dan solusinya, lihat nodejs/node-v0.x-archive#9131#issuecomment-72900581
@ckeeney Saya mengetahui hal itu (yaitu, proses yang berjalan sebagai PID1
mungkin tidak menangani SIGINT
atau SIGTERM
). Karena alasan itu, saya bertanya-tanya apakah menentukan sinyal stop yang berbeda akan melakukan shutdown bersih bahkan jika dijalankan sebagai PID1
.
Atau, buruh pelabuhan 1.13 menambahkan opsi --init
(permintaan tarik: https://github.com/docker/docker/pull/26061), yang memasukkan init ke dalam wadah; dalam hal ini, Node tidak berjalan sebagai PID1
, yang dapat membantu jika Anda tidak dapat memperbarui aplikasi.
@iamthebot Saya telah membangun kernel versi 3.10.0-514.el7 dengan tambalan Anda terintegrasi tetapi saya mendapatkan kesalahan yang sama. Yah saya tidak yakin apakah saya telah membangun dengan baik paket kernel centos. Bisakah Anda membagikan kepada saya paket kernel Anda untuk mengujinya?
Terima kasih
Saya telah/telah berurusan dengan bug ini selama hampir satu tahun sekarang. Saya menggunakan CoreOS dengan boot PXE, saya menonaktifkan ipv6 di konfigurasi pxeboot dan saya belum pernah melihat masalah ini sejak saat itu.
Nah lingkungan saya telah menonaktifkan ipv6 dengan konfigurasi sysctl ini
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
tapi saya masih mendapatkan kesalahan
kernel:unregister_netdevice : menunggu lo menjadi gratis. Jumlah penggunaan = 1
@jsler benar, saya juga melakukan itu, masih terjadi. Hanya sekali saya melakukannya, level pxe berhenti.
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://...
Hanya sebuah pengamatan - sepertinya ada masalah yang berbeda yang sedang bermain (yang telah dikatakan sebelumnya).
Beberapa telah mencatat log bergantian antara yang di atas dan yang lain hanya memiliki salah satu di atas saja.
Ada juga bug serupa yang dicatat di Ubuntu . Yang satu ini, mereka tampaknya menemukan bahwa NFS adalah masalahnya.
@etlweather Saya percaya bahwa sebenarnya satu-satunya denominator umum adalah, perangkat bersih yang tidak dapat
Masih terjadi dengan 4.9.0-0.bpo.1-amd64 di debian jessie dengan buruh pelabuhan 1.13.1. Apakah ada kombinasi kernel - os yang stabil?
Ini mungkin bukan masalah buruh pelabuhan murni - saya mendapatkannya di server Proxmox tempat saya hanya menjalankan wadah Vanilla LXC (ubuntu 16.04).
@darth-veitcher ini masalah kernel
@thaJeztah setuju terima kasih. Akan mencoba dan menginstal 4.9.9 malam ini dari jalur utama dan melihat apakah itu penting.
Saya menjalankannya Docker 1.13.1 pada Debian dengan kernel 4.9.9-040909.
Ya, memutakhirkan kernel di Proxmox ke 4.9.9 terbaru tidak menyelesaikan kesalahan. Aneh karena baru muncul setelah setahun tanpa masalah.
Mungkin ada sesuatu dalam pernyataan sebelumnya lebih lanjut di utas tentang itu yang ditautkan ke NFS atau CIFS yang dipasang.
dikirim dari iPhone saya
Pada 14 Februari 2017, pukul 07:47, Alfonso da Silva [email protected] menulis:
Saya menjalankannya Docker 1.13.1 pada Debian dengan kernel 4.9.9-040909.
—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.
Saya memiliki tiket bugzilla terbuka dengan Redhat tentang ini.
Beberapa perkembangan:
Red Hat menempatkan tambalan kebocoran penghitungan ulang IPV6 dari jalur utama di QA, sepertinya mereka mengantre untuk RHEL 7.4 dan mungkin di-backport ke 7.3. Harus segera di CentOS-plus juga. Catatan: Patch ini hanya memperbaiki masalah dalam BEBERAPA kasus. Jika Anda memiliki kernel 4.x, ini adalah poin yang dapat diperdebatkan karena mereka sudah ada di sana.
Ini jelas merupakan kondisi balapan di kernel dari apa yang saya tahu, yang membuatnya sangat menjengkelkan untuk ditemukan. Saya telah mengambil snapshot dari kernel arus utama saat ini dan sedang mengerjakan instrumentasi berbagai panggilan yang dimulai dengan subsistem IPV6. Masalahnya pasti dapat direproduksi sekarang: sepertinya yang harus Anda lakukan hanyalah membuat banyak wadah, mendorong banyak lalu lintas jaringan darinya, merusak program di dalam wadah, dan menghapusnya. Melakukan hal ini berulang kali akan memicu masalah dalam hitungan menit, berada di puncak pada workstation 4-inti fisik.
Sayangnya, saya tidak punya banyak waktu untuk mengerjakan ini: jika ada pengembang kernel di sini yang bersedia bekerja sama untuk melengkapi bagian-bagian yang diperlukan, saya pikir kita dapat menyiapkan garpu dan mulai bekerja untuk memburu ini selangkah demi selangkah. .
@iamthebot , apakah ini dapat direproduksi pada pengaturan qemu-kvm?
@iamthebot Saya telah mencoba docker-stress -c 100
dengan userland-proxy
disetel ke false akan memicunya, tetapi saya tidak beruntung.
Jika Anda memiliki repro yang lebih andal (walaupun membutuhkan waktu lama untuk memicu), saya dapat mencoba dan melihatnya
Kami menghadapi kesulitan yang sama dalam lingkungan produksi dan pementasan kami. Kami akan segera memutakhirkan ke Docker 1.13 dan kernel Linux 4.9 tetapi seperti yang telah disebutkan lainnya; versi ini juga terpengaruh.
$ 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
Saya mengalami masalah ini secara teratur di sistem dev saya, selalu saat mematikan wadah.
Informasi Umum
→ 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
Log daemon Docker
DEBU[70855] Calling DELETE /v1.22/containers/9b3d01076f3b6a1373729e770a9b1b4e878c2e4be5e27376d24f21ffead6792f?force=False&link=False&v=False
DEBU[70855] Calling DELETE /v1.22/containers/38446ddb58bc1148ea2fd394c5c14618198bcfca114dae5998a5026152da7848?force=False&link=False&v=False
DEBU[70855] Calling DELETE /v1.22/containers/e0d31b24ea4d4649aec766c7ceb5270e79f5a74d60976e5894d767c0fb2af47a?force=False&link=False&v=False
DEBU[70855] Calling DELETE /v1.22/networks/test_default
DEBU[70855] Firewalld passthrough: ipv4, [-t nat -C POSTROUTING -s 172.19.0.0/16 ! -o br-ee4e6fb1c772 -j MASQUERADE]
DEBU[70855] Firewalld passthrough: ipv4, [-t nat -D POSTROUTING -s 172.19.0.0/16 ! -o br-ee4e6fb1c772 -j MASQUERADE]
DEBU[70855] Firewalld passthrough: ipv4, [-t nat -C DOCKER -i br-ee4e6fb1c772 -j RETURN]
DEBU[70855] Firewalld passthrough: ipv4, [-t nat -D DOCKER -i br-ee4e6fb1c772 -j RETURN]
DEBU[70855] Firewalld passthrough: ipv4, [-t filter -C FORWARD -i br-ee4e6fb1c772 -o br-ee4e6fb1c772 -j ACCEPT]
DEBU[70855] Firewalld passthrough: ipv4, [-D FORWARD -i br-ee4e6fb1c772 -o br-ee4e6fb1c772 -j ACCEPT]
DEBU[70855] Firewalld passthrough: ipv4, [-t filter -C FORWARD -i br-ee4e6fb1c772 ! -o br-ee4e6fb1c772 -j ACCEPT]
DEBU[70855] Firewalld passthrough: ipv4, [-D FORWARD -i br-ee4e6fb1c772 ! -o br-ee4e6fb1c772 -j ACCEPT]
DEBU[70855] Firewalld passthrough: ipv4, [-t filter -C FORWARD -o br-ee4e6fb1c772 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT]
DEBU[70855] Firewalld passthrough: ipv4, [-D FORWARD -o br-ee4e6fb1c772 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT]
DEBU[70856] Firewalld passthrough: ipv4, [-t filter -C FORWARD -o br-ee4e6fb1c772 -j DOCKER]
DEBU[70856] Firewalld passthrough: ipv4, [-t filter -C FORWARD -o br-ee4e6fb1c772 -j DOCKER]
DEBU[70856] Firewalld passthrough: ipv4, [-D FORWARD -o br-ee4e6fb1c772 -j DOCKER]
DEBU[70856] Firewalld passthrough: ipv4, [-t filter -C DOCKER-ISOLATION -i br-ee4e6fb1c772 -o docker0 -j DROP]
DEBU[70856] Firewalld passthrough: ipv4, [-D DOCKER-ISOLATION -i br-ee4e6fb1c772 -o docker0 -j DROP]
DEBU[70856] Firewalld passthrough: ipv4, [-t filter -C DOCKER-ISOLATION -i docker0 -o br-ee4e6fb1c772 -j DROP]
DEBU[70856] Firewalld passthrough: ipv4, [-D DOCKER-ISOLATION -i docker0 -o br-ee4e6fb1c772 -j DROP]
DEBU[70856] Firewalld passthrough: ipv4, [-t filter -C DOCKER-ISOLATION -i br-ee4e6fb1c772 -o br-b2210b5a8b9e -j DROP]
DEBU[70856] Firewalld passthrough: ipv4, [-D DOCKER-ISOLATION -i br-ee4e6fb1c772 -o br-b2210b5a8b9e -j DROP]
DEBU[70856] Firewalld passthrough: ipv4, [-t filter -C DOCKER-ISOLATION -i br-b2210b5a8b9e -o br-ee4e6fb1c772 -j DROP]
DEBU[70856] Firewalld passthrough: ipv4, [-D DOCKER-ISOLATION -i br-b2210b5a8b9e -o br-ee4e6fb1c772 -j DROP]
DEBU[70856] releasing IPv4 pools from network test_default (ee4e6fb1c772154fa35ad8d2c032299375bc2d7756b595200f089c2fbcc39834)
DEBU[70856] ReleaseAddress(LocalDefault/172.19.0.0/16, 172.19.0.1)
DEBU[70856] ReleasePool(LocalDefault/172.19.0.0/16)
Message from syslogd<strong i="10">@miriam</strong> at Feb 15 10:20:52 ...
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1
@r-BenDoan jika Anda mencoba menghentikan wadah tetapi tidak menanggapi SIGINT, buruh pelabuhan akan menunggu 10 detik dan kemudian mematikan wadah dengan tidak sopan. Saya menemukan perilaku itu di wadah nodejs saya sampai saya menambahkan penanganan sinyal. Jika Anda melihat penampung membutuhkan waktu 10 detik untuk berhenti, kemungkinan itu tidak menangani sinyal dan lebih cenderung memicu masalah ini.
Pastikan wadah Anda dapat berhenti dengan anggun.
Meskipun saya bukan orang yang memperbaiki masalah ini, tidak terlalu tertarik dengan pengembangan Kernel Linux, saya rasa saya benar dengan mengatakan bahwa komentar "saya juga" tidak begitu membantu. Maksud saya, hanya mengatakan "Saya memiliki masalah ini juga, dengan Kernel vx.x dan Docker 1.x" tidak membawa sesuatu yang baru ke dalam diskusi.
Namun, saya akan menyarankan bahwa komentar "saya juga" yang lebih menggambarkan lingkungan dan metode untuk mereproduksi akan sangat berharga.
Saat membaca semua komentar, jelas ada beberapa masalah - seperti yang saya posting sebelumnya, beberapa dengan vethXYZ, beberapa dengan eth0 dan lainnya dengan lo0. Ini menunjukkan bahwa mereka dapat disebabkan oleh masalah yang berbeda. Jadi hanya mengatakan "saya juga" tanpa deskripsi lengkap tentang kesalahan dan lingkungan dapat menyesatkan orang.
Juga, saat menjelaskan lingkungan, memberikan versi Kernel dan Docker tidak cukup. Per utas, tampaknya ada beberapa faktor seperti ipv6 diaktifkan atau tidak. NodeJS tidak menanggapi SIGINT (atau wadah lain, tidak melakukan bashing pada NodeJS di sini).
Jadi menggambarkan apa beban kerja pada lingkungan akan berguna. Juga, ini terjadi ketika sebuah wadah sedang dimatikan, oleh karena itu saya juga menyarankan kepada orang-orang yang mengalami masalah ini untuk memperhatikan wadah apa yang sedang dihentikan ketika masalah muncul di belakang kepalanya yang jelek.
Meskipun tampaknya masalahnya ada di Kernel yang memiliki kondisi balapan - mengidentifikasi pemicunya akan sangat membantu bagi mereka yang akan memperbaiki masalah tersebut. Dan itu bahkan dapat memberikan solusi langsung kepada pengguna yang terpengaruh seperti mengimplementasikan penangan sinyal dalam aplikasi NodeJS (saya sendiri tidak tahu bahwa ini mencegah masalah agar tidak memicu, tetapi tampaknya demikian per komentar sebelumnya dari orang lain).
Kubernetes FWIW telah menghubungkan ini sepenuhnya dengan "mode jepit rambut" dan
telah berhenti menggunakan fitur tersebut sepenuhnya. Kami belum mengalami ini
masalah sama sekali, di puluhan ribu mesin produksi dan sangat
lebih banyak tes berjalan, sejak berubah.
Sampai ini diperbaiki, tinggalkan kapal. Cari solusi lain :(
Pada Rabu, 15 Februari 2017 pukul 10:00 pagi, ETL [email protected] menulis:
Meskipun saya bukan orang yang memperbaiki masalah ini, tidak terlalu menyukai Linux
Pengembang kernel, saya pikir saya benar mengatakan bahwa komentar "saya juga" tidak
yang membantu. Maksud saya, hanya mengatakan, "Saya juga punya masalah ini, dengan
Kernel vx.x dan Docker 1.x" tidak membawa hal baru dalam diskusi.Namun, saya akan menyarankan komentar "saya juga" yang lebih menggambarkan
lingkungan dan metode untuk mereproduksi akan sangat berharga.Saat membaca semua komentar, jelas ada beberapa masalah -
seperti yang saya posting sebelumnya, beberapa dengan vethXYZ, beberapa dengan eth0 dan lainnya dengan lo0.
Ini menunjukkan bahwa mereka dapat disebabkan oleh masalah yang berbeda. Jadi hanya
mengatakan "saya juga" tanpa deskripsi lengkap tentang kesalahan dan lingkungan mungkin
menyesatkan orang.Juga, ketika menggambarkan lingkungan, memberikan Kernel dan Docker
versi tidak cukup. Per utasnya, sepertinya ada beberapa faktor
seperti ipv6 diaktifkan atau tidak. NodeJS tidak menanggapi SIGINT (atau lainnya
wadah, bukan bashing pada NodeJS di sini).Jadi menggambarkan apa beban kerja pada lingkungan akan berguna.
Juga, ini terjadi ketika sebuah wadah sedang dimatikan, oleh karena itu saya akan
juga menyarankan kepada orang-orang yang mengalami masalah ini untuk memperhatikan apa
wadah sedang dihentikan ketika masalah muncul di belakang kepalanya yang jelek.Meskipun sepertinya masalahnya ada di Kernel yang memiliki kondisi balapan -
mengidentifikasi pemicunya akan sangat membantu bagi mereka yang akan memperbaikinya
masalah. Dan bahkan dapat memberikan solusi langsung kepada pengguna yang terpengaruh
seperti menerapkan penangan sinyal dalam aplikasi NodeJS (saya tidak tahu
saya sendiri bahwa ini mencegah masalah dari memicu, tetapi tampaknya begitu per
komentar orang lain sebelumnya).—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/5618#issuecomment-280087293 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/AFVgVFmu1SiStZcLKtKuk1W-tjn6wOXlks5rcz0hgaJpZM4B4L4Z
.
Yap, kami pindah ke gke dan tidak lagi melihat masalah ini (jadi tidak ada lagi hadiah bug dari kami :))
Barusan error lagi. Saya mencoba memperbaiki aplikasi node.js yang menggunakan soket dan karenanya sering menskalakan aplikasi. Aplikasi node.js dibangun di atas https://github.com/deployd/deployd. Saya harap ini memberikan lebih banyak info. Yang juga menarik adalah bahwa kedua server di dalam kawanan saya menampilkan kesalahan unregister_netdevice secara bersamaan setelah saya menghapus layanan melalui layanan buruh pelabuhan rm. Wadah diskalakan menjadi 4 sehingga dua wadah berjalan di setiap mesin.
edit Terjadi lagi! Bekerja pada aplikasi node.js yang sama. 3 atau 4 hari terakhir saya tidak langsung mengerjakan aplikasi node.js itu dan itu tidak pernah terjadi.
edit2 akan mencoba menambahkan penangan sinyal ke aplikasi nodejs. Mari kita lihat apakah itu membantu....
Saya baru saja mengalami kesalahan ini, setelah menggunakan docker-py untuk menerbitkan instance baru ke EC. Namun, saya dapat keluar dengan ctrl+C, dan belum melihatnya sejak (sekarang sebagian besar gambar dibuat lebih cepat dari cache)
```{"status":"Didorong","progressDetail":{},"id":"c0962ea0b9bc"}
{"status":"tahap: intisari: sha256:f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8 ukuran: 5737"}
{"progressDetail":{},"aux":{"Tag":"stage","Digest":"sha256:f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8","Size":5737}}
Gambar buruh pelabuhan berhasil diterbitkan
Pesan dari syslogd@ip-172-31-31-68 pada 16 Februari 19:49:16 ...
kernel:[1611081.976079] unregister_netdevice: menunggu lo menjadi gratis. Jumlah penggunaan = 1
Pesan dari syslogd@ip-172-31-31-68 pada 16 Februari 19:49:27 ...
kernel:[1611092.220067] unregister_netdevice: menunggu lo menjadi gratis. Jumlah penggunaan = 1
[1]+ Berhenti ./image-publish.py
[ root@ip-172-31-xx-xx image-publish]# ^C
[ root@ip-172-31-xx-xx image-publish]#
@thockin apakah ini pengaturan --hairpin-mode=none
di kubelet?
=none merusak wadah yang mengembalikan NAT ke dirinya sendiri. Kita gunakan
promiscuous-bridge secara default.
Pada Kam, 16 Februari 2017 jam 19:26, Kanat Bekt [email protected]
menulis:
@thockin https://github.com/thockin apakah pengaturan ini --hairpin-mode=none
di kubelet?—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/5618#issuecomment-280539673 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/AFVgVLNwAH6NWVaIKhJfS147O9w_rtJEks5rdRN8gaJpZM4B4L4Z
.
@thockin wadah mana yang mungkin ingin mengakses sendiri melalui Service ClusterIP ?
Ternyata lebih umum daripada yang saya kira, dan ketika kami memecahkannya, banyak
dari orang yang mengeluh.
Pada 17 Februari 2017 12:38, "Maxim Ivanov" [email protected] menulis:
@thockin https://github.com/thockin wadah mana yang mungkin ingin
mengakses sendiri melalui Service ClusterIP ?—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/5618#issuecomment-280588366 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/AFVgVLn3uBvUW-dQ72qst5_eYiFUtfSVks5rdVyIgaJpZM4B4L4Z
.
Saya pikir saya tahu mengapa beberapa aplikasi nodejs buruh pelabuhan dapat menyebabkan masalah ini. Node menggunakan koneksi keep-alive per default. Ketika server.close()
digunakan, server tidak menerima koneksi baru. Tetapi koneksi aktif saat ini seperti soket web atau koneksi HTTP keep-alive masih dipertahankan. Ketika aplikasi dockerized juga diskalakan ke n ini dapat mengakibatkan waiting for lo to become free
karena ketika dipaksa untuk penghentian lo yang lebih baru dibebaskan. Saat buruh pelabuhan mendistribusikan ulang aplikasi ini ke simpul lain atau aplikasi diperkecil, buruh pelabuhan mengirimkan sinyal ke aplikasi bahwa itu harus dimatikan. Aplikasi mendengarkan sinyal ini dan dapat bereaksi. Ketika aplikasi tidak dimatikan setelah beberapa detik, buruh pelabuhan menghentikannya tanpa ragu-ragu. Saya menambahkan penangan sinyal dan menemukan bahwa ketika menggunakan server.close()
server tidak dihentikan dengan sempurna tetapi "hanya" berhenti menerima koneksi baru (lihat https://github.com/nodejs/node/issues/2642) . Jadi kita perlu memastikan bahwa koneksi terbuka seperti soket web atau http keep-alive juga ditutup.
Cara menangani soket web:
Aplikasi nodejs memancarkan ke semua websockets closeSockets
ketika sinyal shutdown diterima. Klien mendengarkan acara closeSockets
ini dan memanggil sockets.disconnect()
dan segera setelah sockets.connect()
. Ingat bahwa server.close()
dipanggil sehingga instance ini tidak menerima permintaan baru. Ketika instance lain dari aplikasi dockerized ini menjalankan loadbalancer di dalam docker pada akhirnya akan memilih instance yang tidak dimatikan dan koneksi yang berhasil dibuat. Instance yang harus dimatikan tidak akan memiliki koneksi soket web terbuka.
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();
});
...
Cara menangani koneksi HTTP keep-alive:
Saat ini saya tidak tahu bagaimana ini bisa dilakukan dengan sempurna. Cara termudah adalah menonaktifkan keep-alive.
app.use(function (req, res, next) {
res.setHeader('Connection', 'close');
next();
}
Kemungkinan lain adalah mengatur batas waktu keep-alive ke angka yang sangat rendah. Misalnya 0,5 detik.
app.use(function (req, res, next) {
res.setTimeout(500);
next();
}
Semoga ini bisa membantu orang lain :)
Aku punya masalah yang sama. Lampiran adalah semua log yang dibuat dari skrip ecs-logs-collector.
Sangat dihargai untuk bantuan apa pun :)
Aku punya masalah yang sama.
Docker versi 1.13.1, build 092cba3
Linux debian 4.8.6-x86_64-linode78
Pencadangan Linux 4.6.0-040600-generic #201606100558 SMP Jum 10 Jun 10:01:15 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Versi Server: 1.13.1
Masalah yang sama. Saya menggunakan mount dalam wadah istimewa. Setelah 4-5 berjalan itu membeku. Saya juga memiliki masalah yang sama dengan kernel standar terbaru untuk 16,04
Semuanya, @etlweather sangat tepat. Hanya posting "saya juga" jika Anda memiliki cara yang dapat diandalkan untuk mereproduksi masalah. Dalam hal ini, detailkan prosedur Anda. Versi buruh pelabuhan dan kernel tidak cukup dan kami mendapatkan banyak pemberitahuan tentangnya. Semakin sederhana prosedur reproduksi Anda, semakin baik.
@rneugeba @redbaron Sayangnya "repro" yang saya miliki saat ini sangat spesifik untuk perangkat keras (semua kecuali membuktikan ini adalah kondisi balapan). Saya belum mencoba mendapatkan repro QEMU tetapi itu jelas merupakan langkah selanjutnya sehingga banyak orang dapat benar-benar mengerjakan ini dan mendapatkan hasil yang diharapkan (idealnya dalam 1 pengaturan inti CPU). Jika seseorang sudah memilikinya, tolong kirimi saya email (ada di profil saya). Saya akan benar-benar mengujinya dan mempostingnya di sini.
Kami cukup sering mendapatkan ini di GCE. Docker membeku dan mesin hang saat reboot.
[782935.982038] unregister_netdevice: waiting for vethecf4912 to become free. Usage count = 17
Kontainer menjalankan aplikasi go, dan memiliki hairpin nat yang dikonfigurasi.
Buruh pelabuhan:
matthew@worker-1:~$ docker version
Client:
Version: 1.12.6
API version: 1.24
Go version: go1.6.4
Git commit: 78d1802
Built: Tue Jan 10 20:38:45 2017
OS/Arch: linux/amd64
Server:
Version: 1.12.6
API version: 1.24
Go version: go1.6.4
Git commit: 78d1802
Built: Tue Jan 10 20:38:45 2017
OS/Arch: linux/amd64
Ubuntu 16.04 LTS,
matthew@worker-1:~$ uname -a
Linux worker-1 4.4.0-64-generic #85-Ubuntu SMP Mon Feb 20 11:50:30 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Adakah yang punya saran kerja untuk ini? Saya mencoba mengaktifkan --userland-proxy=true
dan buruh pelabuhan masih hang setelah beberapa saat. Tampaknya Kubernates memiliki solusi dari apa yang @thockin tulis di atas, tetapi tidak jelas apa yang sebenarnya dilakukan --hairpin-mode=promiscuous-bridge
dan bagaimana mengonfigurasinya pada instalasi docker jane ubuntu 16.x biasa.
Saya dapat mewujudkannya dengan andal saat menjalankan Proxmox dan menggunakan wadah. Secara khusus, jika saya telah memindahkan sejumlah besar data atau benar-benar memindahkan sejumlah data baru-baru ini, mematikan atau menghentikan wadah dengan keras akan menghasilkan kesalahan ini. Saya paling sering melihatnya ketika saya menggunakan wadah yang memasang NAS saya di dalamnya, tetapi itu mungkin kebetulan.
# 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
Dan dari dalam 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
Perlu dicatat bahwa Docker tidak diinstal pada sistem ini dan belum pernah diinstal. Saya senang memberikan data apa pun yang dibutuhkan komunitas untuk memecahkan masalah ini, cukup beri tahu saya perintah apa yang harus dijalankan.
Saya dapat mereproduksi ini pada centos 7.3 yang berjalan sebagai simpul pekerja swarm yang menjalankan dtr dengan volume nfs terpasang yang dipetakan
Masalah yang dibahas di sini adalah bug kernel dan belum diperbaiki. Ada sejumlah opsi yang dapat membantu untuk _beberapa_ situasi, tetapi tidak untuk semua (kemungkinan besar kombinasi masalah yang memicu kesalahan yang sama)
"Saya juga punya ini" tidak membantu menyelesaikan bug. hanya tinggalkan komentar jika Anda memiliki informasi yang dapat membantu menyelesaikan masalah (dalam hal ini; memberikan tambalan ke hulu kernel mungkin merupakan langkah terbaik).
Jika Anda ingin memberi tahu bahwa Anda juga mengalami masalah ini, gunakan tombol "jempol" di deskripsi atas:
Setiap komentar di sini mengirimkan email / pemberitahuan ke lebih dari 3000 orang Saya tidak ingin mengunci percakapan tentang masalah ini, karena belum terselesaikan, tetapi mungkin terpaksa jika Anda mengabaikannya.
Terima kasih!
Itu semua baik dan bagus tapi apa _tepatnya_ opsi yang membantu? Masalah ini menyebabkan kami mengalami masalah dalam produksi, jadi saya ingin melakukan pekerjaan apa pun yang diperlukan untuk mengatasi bug kernel.
Jika seseorang dari Docker punya waktu untuk mencoba solusi Kubernetes, silakan
beri tahu saya dan kami dapat mengarahkan Anda ke sana. Saya tidak dapat mengekstrak perubahan
dan menambalnya sendiri ke Docker, sekarang juga.
Pada Kam, 9 Mar 2017 jam 07:46, Matthew Newhook [email protected]
menulis:
Itu semua baik dan bagus tapi apa sebenarnya pilihan yang membantu?
Masalah ini menyebabkan kami bermasalah dalam produksi jadi saya ingin melakukan apa pun
bekerja di sekitar yang diperlukan untuk mengatasi bug kernel.—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/5618#issuecomment-285388243 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/AFVgVGdH5VX_oFWkImyo_TvlIuhmwMepks5rkB7MgaJpZM4B4L4Z
.
@thockin terima kasih. Saya mengikuti PR/masalah di Kubernetes dengan solusi mode jepit rambut. Tetapi selama banyak bolak-balik, saya kehilangan jejak jika solusi sebenarnya menghilangkan masalah ini?
(Seperti yang saya pahami ada skenario berbeda yang menyebabkan inkonsistensi penghitungan ref di kernel).
Jika Anda dapat mengarahkan saya ke PR yang Anda yakini mengatasi masalah di K8s, saya akan berusaha untuk mendapatkan patch ini di buruh pelabuhan setidaknya untuk kasus mematikan proksi userland secara default. (Dan kita dapat mengujinya menggunakan langkah-langkah reproduksi docker-stress).
Saya tidak yakin saya memiliki satu PR, tetapi Anda dapat melihat keadaan saat ini. Awal
di sini:
Pada Sabtu, 11 Mar 2017 jam 22:49, Madhu Venugopal [email protected]
menulis:
@thockin https://github.com/thockin terima kasih. Saya mengikuti
PR/masalah di Kubernetes dengan solusi mode jepit rambut. Tapi selama
banyak bolak-balik, saya kehilangan jejak jika solusi sebenarnya menghilangkan ini
isu ?
(Seperti yang saya pahami, ada skenario berbeda yang menyebabkan penghitungan ulang
inkonsistensi dalam kernel).Jika Anda dapat mengarahkan saya ke PR yang Anda yakini mengatasi masalah di K8,
Saya akan bekerja untuk mendapatkan ini ditambal di buruh pelabuhan setidaknya untuk kasus balik
userland-proxy nonaktif secara default. (Dan kita bisa mengujinya menggunakan docker-stress
langkah reproduksi).—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/5618#issuecomment-285926217 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/AFVgVIlGs_QccxS6YYQiLNybddDzB4yUks5rk5VogaJpZM4B4L4Z
.
Hai semua, untuk memperjelas, semua "solusi kubernetes" yang dilakukan adalah mengaktifkan mode promiscuous di jembatan yang mendasarinya. Anda dapat mencapai hal yang sama dengan ip link set <bridgename> promisc on
menggunakan iproute2. Ini mengurangi kemungkinan mengalami bug tetapi mungkin tidak menghilangkannya sama sekali.
Sekarang, secara teori ini seharusnya tidak berfungsi ... tetapi untuk beberapa alasan mode promiscuous tampaknya membuat perangkat teardown cukup lambat sehingga Anda tidak berlomba untuk mengurangi penghitung ref. Mungkin salah satu kontributor Kurbernetes dapat bergabung di sini jika mereka ada di utas ini.
Saya dapat memverifikasi solusi (BUKAN MEMPERBAIKI) berfungsi menggunakan repro khusus lingkungan saya. Saya tidak dapat memverifikasi bahwa itu membantu jika Anda menggunakan driver IPVLAN atau MACVLAN (kami menggunakan macvlan di prod) karena tampaknya sangat sulit untuk mendapatkan pengaturan tersebut untuk menghasilkan bug ini. Adakah yang bisa mencoba repro untuk memverifikasi solusinya?
Hai semua, saya mencoba men-debug masalah kernel, memiliki rantai email di milis "netdev", jadi hanya ingin memposting beberapa temuan di sini.
https://www.spinics.net/lists/netdev/msg416310.html
Masalah yang kita lihat adalah bahwa
unregister_netdevice: waiting for lo to become free. Usage count = 1
selama kontainer ditutup. Ketika saya memeriksa ruang nama jaringan kontainer, sepertinya perangkat eth0
telah dihapus, tetapi hanya perangkat lo
yang tersisa di sana. Dan ada struktur lain yang memegang referensi untuk perangkat itu.
Setelah beberapa penggalian, ternyata "benda" yang memegang referensi, adalah salah satu dari "cache perutean" ( struct dst_entry
). Dan ada sesuatu yang mencegah dst_entry
untuk di-gc'ed (jumlah referensi untuk dst_entry
lebih besar dari 0). Jadi saya mencatat setiap dst_hold()
(menambah jumlah referensi dst_entry sebanyak 1), dan dst_release()
(mengurangi jumlah referensi dst_entry sebanyak 1), dan memang ada lebih banyak panggilan dst_hold()
kemudian dst_release()
.
Berikut adalah log terlampir: kern.log.zip
Ringkasan:
lo
diubah namanya menjadi lodebug
untuk kemudahan memahamidst_entry
dimulai dengan 1dst_entry
(yang memegang referensi untuk lo) pada akhirnya adalah 19dst_hold()
panggilan, dan 258023 total dst_release()
panggilandst_hold()
panggilan, ada 88034 udp_sk_rx_dst_set()
(yang kemudian disebut dst_hold()
), 152536 inet_sk_rx_dst_set()
, dan 17471 __sk_add_backlog()
dst_release()
panggilan, ada 240551 inet_sock_destruct()
dan 17472 refdst_drop()
Ada lebih banyak udp_sk_rx_dst_set()
dan inet_sk_rx_dst_set()
panggilan total dari inet_sock_destruct()
, jadi mencurigai ada beberapa soket dalam keadaan "limbo", dan sesuatu mencegahnya untuk dihancurkan.
MEMPERBARUI:
Ternyata soket ( struct sock
) dibuat dan dihancurkan dengan benar, tetapi untuk beberapa soket TCP inet_sk_rx_dst_set()
dipanggil beberapa kali pada dst
, tetapi hanya ada satu sesuai inet_sock_destruct()
untuk melepaskan referensi ke dst
.
Ini adalah solusi CentOS 7.3 yang memperbaikinya untuk saya:
yum --enablerepo=centosplus install kernel-plus
egrep ^menuentry /etc/grub2.cfg | cut -f 2 -d \’
grub2-set-default 0
reboot
Inilah tambalan yang menyelesaikannya:
https://bugs.centos.org/view.php?id=12711&nbn=1
UPDATE: Ini ternyata tidak menyelesaikan masalah secara permanen. Itu muncul lagi beberapa jam kemudian dengan pesan dinding berikut:
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1
@adrianotto - untuk memperjelas: Apakah patch kernel CentOS menyelesaikan ini? Hanya ingin tahu apakah maksud Anda solusi dan jalur kernel referensi Anda keduanya tidak berhasil menyelesaikan ini secara permanen?
@stayclassychicago @adrianotto Patch itu hanya membahas salah satu kondisi balapan yang dapat memicu masalah "jumlah penggunaan" di kernel. Ini hanya perbaikan saya yang di-backport dari sesuatu di kernel 4.x. Ini dapat memecahkan masalah Anda sehingga layak dicoba.
@stayclassychicago sebelum saya mencoba kernel 3.10.0-514.10.2.el7.centos.plus.x86_64
saya mendapatkan kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1
secara teratur, hampir setiap kali saya menjalankan container dengan docker run --rm ...
ketika container keluar. Setelah upgrade kernel dan reboot, itu benar-benar berhenti selama berjam-jam, dan kemudian kembali lagi. Sekarang separuh waktu saya menghapus wadah itu berfungsi dengan baik, di mana dulu sering terjadi kesalahan. Saya tidak tahu pasti apakah kernel baru membantu, tetapi tidak ada salahnya.
Sepertinya sangat mudah untuk mereproduksi ketika ada antarmuka ikatan LACP pada mesin. Kami memiliki 3 node swarm cluster, ketiganya dengan antarmuka ikatan LACP yang dikonfigurasi, dan masalah ini pada dasarnya tidak memungkinkan kami untuk bekerja dengan cluster. Kita harus me-restart node setiap 15-20 menit.
Dikonfirmasi - segera setelah saya menghapus ikatan LACP dari antarmuka (yang digunakan sebagai antarmuka utama), semuanya berfungsi dengan baik selama lebih dari 12 jam. Digunakan untuk istirahat setiap ~ 30 menit.
Ini dapat direproduksi pada 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
dengan Docker version 17.04.0-ce, build 4845c56
berjalan dalam mode priviliged ketika mount cifs kita terbuka. Ketika wadah berhenti dengan mount terbuka, Docker menjadi tidak responsif dan kami mendapatkan kernel:[ 1129.675495] unregister_netdevice: waiting for lo to become free. Usage count = 1
-error.
ubuntu 16.04 (kernel 4.4.0-78-generic) masih memiliki masalah. Dan ketika itu terjadi, aplikasi apa pun yang mencoba membuat namespace jaringan baru melalui clone syscall akan macet
[ 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
Satu-satunya solusi adalah hard reset mesin.
Saya menemui masalah ini ketika memasang volume NFS dalam wadah istimewa lalu memulai kembali wadah.
Sepertinya saya masalah ini tidak pernah terjadi pada RHEL 7 dengan prosedur yang sama.
$ 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 mengklaim bahwa bug ini telah diperbaiki pada rilis kernel-3.10.0-514.21.1.el7. Saya kira mereka akan memperbaiki perbaikan sesegera mungkin dan rebase ke 4.12. Paket ini sudah tersedia di CentOS 7 juga.
Dokumentasi yang terkait dengan perbaikan (diperlukan akses RHN):
https://access.redhat.com/articles/3034221
https://bugzilla.redhat.com/show_bug.cgi?id=1436588
Dari artikel:
"Dalam kasus alamat IPv6 duplikat atau masalah dengan pengaturan alamat, kondisi balapan terjadi. Kondisi balapan ini terkadang menyebabkan kebocoran penghitungan referensi alamat. Akibatnya, upaya untuk membatalkan pendaftaran perangkat jaringan gagal dengan pesan kesalahan berikut: "unregister_netdevice: waiting untuk menjadi bebas. Jumlah penggunaan = 1". Dengan pembaruan ini, kode sumber yang mendasari telah diperbaiki, dan perangkat jaringan sekarang membatalkan pendaftaran seperti yang diharapkan dalam situasi yang dijelaskan."
Saya sudah menerapkan perbaikan ini di semua sistem kumpulan PaaS kami, dan sudah 2 hari tanpa bug. Sebelumnya, kami memiliki setidaknya satu sistem yang dibekukan per hari. Saya akan melaporkan di sini jika kami menemukan bug lagi.
Saya memiliki kernel versi 3.10.0-514.21.1.el7.x86_64, dan saya masih memiliki gejala yang sama.
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 Rupanya, ada beberapa cara untuk
@bcdonadio Jika Anda melihat https://git.centos.org/commitdiff/rpms!kernel.git/b777aca52781bc9b15328e8798726608933ceded - Anda akan melihat bahwa https://bugzilla.redhat.com/show_bug.cgi?id=1436588 bug adalah "diperbaiki" oleh perubahan ini:
+- [net] ipv6: addrconf: fix dev refcont leak when DAD failed (Hangbin Liu) [1436588 1416105]
Yang ada di kernel hulu sejak 4.8, saya percaya (https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d). Dan 4.9 dan 4.10 memiliki bug ini, jadi RedHat baru saja mem-backport beberapa perbaikan dari upstream, yang mungkin memperbaiki beberapa masalah, tapi jelas tidak semuanya.
@bcdonadio Saya dapat mereproduksi bug di sistem saya dengan menjalankan skrip pengujian ini sekali per jam dari cron:
#!/bin/sh
TAG=`date +%F_%H_%M_%S_UTC`
docker pull centos:centos6
docker run --rm adrianotto/centos6 yum check-update -q > package_updates.txt
LINES=`wc -l < package_updates.txt`
if [ $LINES -eq 0 ] ; then
rm -f package_updates.txt
echo "No packages need to be updated"
exit 0
fi
docker run --rm adrianotto/centos6 rpm -a -q > old_packages.txt
docker build -t temp:$TAG .
docker run --rm temp:$TAG rpm -a -q > new_packages.txt
docker rmi temp:$TAG
Skrip ini hanya menghasilkan daftar paket menggunakan gambar di registri Docker, dan yang lain menggunakan yang dibuat secara lokal sehingga saya dapat membandingkannya. Dockerfile hanya ini:
FROM centos:centos6
MAINTAINER Adrian Otto
RUN yum clean all && yum update -y && yum clean all
2-4 menit kemudian syslog mendapat pesan ini:
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
Pada kejadian terakhir terjadi beberapa menit setelah saya menjalankan script secara manual. Dugaan saya adalah bahwa setelah beberapa waktu habis setelah penghapusan wadah dicoba, kondisi kesalahan dinaikkan.
Saya yakin kondisi error tersebut terputus-putus, karena script di atas berjalan sebagai cron job pada :00 melewati setiap error. Berikut adalah contoh output kesalahan yang direkam 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
Jadi itu terjadi di suatu tempat dalam kisaran 2 hingga 4 menit setelah wadah berjalan dan keluar dan dihapus oleh buruh pelabuhan karena flag --rm. Perhatikan juga dari log di atas bahwa tidak ada kesalahan untuk setiap container yang dijalankan/dihapus, tetapi cukup konsisten.
Apakah mungkin bagi seseorang untuk melihat apakah tambalan ini memperbaiki keadaan?
https://patchwork.ozlabs.org/patch/768291/
@hlrichardson Ini sebenarnya terlihat seperti itu! Saya akan mencoba mem-backportnya ke kernel 3.16 kami atau memutakhirkan server tertentu dan mengkompilasi kernel 4.9 dengan tambalan ini besok, kita akan lihat bagaimana kelanjutannya.
Padahal, setelah memeriksa komit referensi tambalan ini (https://github.com/torvalds/linux/commit/0c1d70af924b966cc71e9e48920b2b635441aa50) - itu dilakukan di kernel 4.6, sementara masalahnya sudah ada sebelumnya :(
Ah, jadi mungkin tidak terkait, kecuali ada banyak penyebab (sayangnya ada banyak cara untuk memicu jenis bug ini, jadi itu kemungkinan).
Kami secara pribadi menemukan setidaknya beberapa masalah di sini - beberapa di antaranya adalah
Log "unregister_netdevice" hilang begitu saja setelah beberapa waktu dan
wadah buruh pelabuhan dapat berfungsi dengan baik, sementara di wadah lain - semua wadah
macet dan server perlu di-boot ulang.
Sebenarnya - kami tidak menggunakan vxlan di server yang mengalami masalah ini - kami menggunakan
jembatan sederhana dan penerusan port (ini terjadi terlepas dari proxy-userland
pengaturan).
Pada 30 Mei 2017 22:54, "hlrichardson" [email protected] menulis:
Ah, jadi mungkin tidak terkait, kecuali ada banyak penyebab
(sayangnya ada banyak cara untuk memicu jenis bug ini, jadi
itu kemungkinan).—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/5618#issuecomment-304989068 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAGqoDHe1n3h9_eJ2kmeWcbhKRCX6rZoks5r_HPbgaJpZM4B4L4Z
.
OK, jika Anda tidak menggunakan terowongan vxlan itu pasti tidak akan membantu.
BTW, jika Anda melihat satu contoh pesan "unregister_netdevice" ketika ruang nama jaringan dihapus (keluar wadah), itu harus dianggap sebagai situasi normal di mana sesuatu yang merujuk perangkat net dibersihkan kurang lebih pada saat yang sama ruang nama
sedang dihapus.
Kasus yang lebih serius adalah di mana pesan ini diulang setiap 10 detik dan tidak pernah berhenti...
dalam hal ini kunci global ditahan selamanya, dan karena kunci ini harus diperoleh setiap kali jaringan
namespace ditambahkan atau dihapus, setiap upaya untuk membuat atau menghapus namespace jaringan juga
hang selamanya.
Jika Anda memiliki cara yang cukup mudah untuk mereproduksi jenis masalah kedua, saya akan tertarik
melihat-lihat.
@hlrichardson Kami melihat kasus ke-2 yang Anda sebutkan di atas pada sekelompok server kami yaitu pesan diulang setiap 10 detik. Info apa yang Anda ingin saya bagikan?
Melihat ini di Fedora 25 saat menguji dan membuat centos:7 container saat menggunakan yum. Yum gagal menyelesaikan pengunduhan basis data paket dan macet tanpa batas karena jaringan berhenti bekerja dengan cara yang aneh.
Halo kawan-kawan,
Ada tambalan potensial untuk bug kernel (atau setidaknya salah satu bug) di milis net-dev Linux:
https://www.spinics.net/lists/netdev/msg442211.html
Itu digabungkan di pohon bersih, diantrekan untuk pohon stabil.
Menurut https://github.com/torvalds/linux/commit/d747a7a51b00984127a88113cdbbc26f91e9d815 - itu ada di 4.12 (yang dirilis kemarin)!
@fxposter @kevinxucs Saya akan mencoba
Saya menjalankan 4.12 (dari http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12/) dan saya masih menekan ini, jadi torvalds/ linux@d747a7a tidak boleh menjadi perbaikan yang lengkap.
$ uname -r
4.12.0-041200-generic
Ryan, apakah Anda memiliki cara yang dapat diandalkan untuk mereproduksi?
Pada 6 Juli 2017 16:29, "Ryan Campbell" [email protected] menulis:
Saya menjalankan 4.12 (dari http://kernel.ubuntu.com/~
kernel-ppa/mainline/v4.12/) dan saya masih menekan ini, jadi torvalds/linux@
d747a7a https://github.com/torvalds/linux/commit/d747a7a tidak boleh
perbaikan lengkap.$ uname -r
4.12.0-041200-generik—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/5618#issuecomment-313413120 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAdcPCbVPDjPw6va-N5dM7CjYn2W4Bodks5sLO9ZgaJpZM4B4L4Z
.
@justincormack Sayangnya saya tidak memiliki contoh minimal yang dapat saya bagikan, tetapi kami memiliki rangkaian pengujian yang membuat dan menghancurkan banyak wadah dan saya biasanya mengalami masalah ini (menggantung perintah buruh pelabuhan, banyak waiting for lo to become free
di syslog) setelah hanya beberapa iterasi.
@campbellr Saya sudah mencoba mengulangi ini sekarang tiga kali dan menghabiskan sebagian besar minggu ini dengan sedikit keberuntungan. Saya berhasil mendapatkan pesan waiting for lo to become free
beberapa kali tetapi tanpa crash/hang sesudahnya. Saya mencoba mengurangi kasus uji hanya dengan membuat namespace jaringan dan antarmuka veth.
Di rangkaian pengujian Anda:
Bahkan sebagian jawaban di atas dapat membantu mempersempitnya ...
Terima kasih
@rn Docker tidak akan hang lagi karena menetapkan batas waktu pada permintaan netlink yang biasanya hang. Tetapi Anda tidak akan dapat memulai wadah baru (atau memulai ulang wadah yang sudah ada), kemungkinan pembersihan wadah saat berhenti akan menjadi aneh juga.
Saya belum memiliki kesempatan untuk menguji pada 4.12, tetapi saya dapat mereproduksi dengan andal pada instance kvm di vultr. Saya menjalankan swarm dan pekerja chrome tanpa kepala saya menyebabkan masalah ketika mereka gagal dalam pemeriksaan kesehatan atau crash secara teratur. Tentu saja pada titik ini saya telah melacak semua crasher menangani kesalahan jaringan dengan bersih dll jadi saya melihat waiting for lo to become free
tetapi tidak cukup sering untuk menggantung sesuatu selama beberapa minggu.
Jadi sepertinya hal-hal yang membantu mereproduksi adalah skenario jaringan yang lebih kompleks yang dikombinasikan dengan sejumlah besar lalu lintas ke dalam wadah, daur ulang wadah yang konstan, dan kvm.
@rn Saya berhasil mempersempit ini ke wadah tertentu di suite pengujian kami, dan dapat mereproduksi dengan langkah-langkah berikut:
Setelah 3 atau 4 iterasi ini saya akhirnya mendapatkan waiting for lo to become free
dan pada iterasi berikutnya docker run
gagal dengan docker: Error response from daemon: containerd: container did not start before the specified timeout.
apakah wadah Anda memiliki banyak aktivitas jaringan? Jika demikian, arah mana yang dominan?
Jumlah yang cukup kecil. Dalam langkah-langkah yang disebutkan di atas, permintaan http adalah sejumlah kecil json, dan responsnya adalah gumpalan biner sekitar 10MB.
Jenis mesin apa yang Anda jalankan yang ini (jumlah inti, apakah itu VM, dll)
Ini ada di mesin desktop 4-inti (tanpa VM)
Apakah Anda membuat banyak wadah secara bersamaan?
Tidak, semuanya dilakukan secara berurutan.
Apakah kontainer Anda keluar secara normal atau rusak?
Mereka dihentikan dengan docker stop
- start container (layanan web berbasis tornado internal - saya mencoba mengekstrak contoh minimal yang masih mengenai ini)
- buat permintaan ke layanan web yang berjalan dalam wadah
- ditunggu responnya
- membunuh wadah
Saya menghabiskan beberapa waktu untuk membongkar wadah dan ternyata layanan web tidak ada hubungannya dengan bug. Apa yang tampaknya memicu ini dalam kasus saya adalah memasang bagian NFS di dalam wadah (berjalan dengan --privileged
).
Di desktop saya, saya dapat dengan andal mereproduksi hanya dengan menjalankan yang berikut ini beberapa kali:
$ docker run -it --rm --privileged alpine:latest /bin/mount -o nolock -o async -o vers=3 <my-nfs-server>:/export/foo /mnt
Pengguna Kubernetes, saya membuka masalah ke _kops_ untuk merilis AMI Kubernetes berikutnya dengan Kernel versi 4.12. Selamat datang untuk memeriksanya: https://github.com/kubernetes/kops/issues/2901
Saya juga menekan ini pada centos 7.3 dengan kernel Host 3.10.0-514.6.1.el7.x86_64 dan docker-ce-17.06.0.ce-1.el7.centos.x86_64.
@FrankYu itu tidak membantu. Untuk berpartisipasi secara bermanfaat dalam utas ini, berikan cara yang tepat untuk mereproduksi masalah ini, dan harap uji pada kernel modern. 3.10 dirilis empat tahun lalu, kami sedang mendiskusikan apakah itu diperbaiki atau sebagian pada rilis dari empat hari lalu.
@danielgusmao RancherOS kami dan OS linux AWS ECS AMI sudah memiliki 'perbaikan' (kemungkinan adalah default) dan itu tidak menyelesaikan masalah bagi kami. Kami masih melihat pesan muncul di log sepanjang waktu. Kemungkinan satu-satunya harapan adalah patch kernel di-backport secara luas. Meskipun saya mencari di sekitar dan tidak dapat melihat bukti kemajuan serius ke arah itu di bugzilla dan forum linux RedHat/Centos/AWS.
Untuk lebih jelasnya, pesan itu sendiri jinak , itu adalah kernel crash setelah pesan yang dilaporkan oleh OP yang tidak.
Komentar dalam kode, dari mana pesan ini berasal, menjelaskan apa yang terjadi. Pada dasarnya setiap pengguna, seperti tumpukan IP) dari perangkat jaringan (seperti akhir dari pasangan veth
di dalam wadah) menambah jumlah referensi dalam struktur perangkat jaringan saat menggunakan perangkat jaringan. Saat perangkat dilepas (mis. saat wadah dilepas) setiap pengguna diberi tahu sehingga mereka dapat melakukan pembersihan (mis. menutup soket terbuka, dll.) sebelum mengurangi jumlah referensi. Karena pembersihan ini dapat memakan waktu, terutama di bawah beban berat (banyak antarmuka, banyak koneksi dll), kernel dapat mencetak pesan di sini sesekali .
Jika pengguna perangkat jaringan tidak pernah mengurangi jumlah referensi, beberapa bagian lain dari kernel akan menentukan bahwa tugas yang menunggu pembersihan macet dan akan macet. Hanya crash ini yang menunjukkan bug kernel (beberapa pengguna, melalui beberapa jalur kode, tidak mengurangi jumlah referensi). Ada beberapa bug seperti itu dan telah diperbaiki di kernel modern (dan mungkin di-porting kembali ke yang lebih lama). Saya telah menulis beberapa tes stres (dan terus menulisnya) untuk memicu crash seperti itu tetapi belum dapat mereproduksi pada kernel modern (namun saya melakukan pesan di atas).
Harap laporkan masalah ini hanya jika kernel Anda benar-benar mogok, dan kami akan sangat tertarik pada:
uname -r
)Terima kasih
[ @thaJeztah bisakah Anda mengubah judul menjadi sesuatu seperti kernel crash after "unregister_netdevice: waiting for lo to become free. Usage count = 3"
untuk membuatnya lebih eksplisit]
Harus diperbaiki di kernel 4.12 atau yang lebih baru. Silakan periksa. https://access.redhat.com/solutions/3105941
dan tautan ke tambalan https://github.com/torvalds/linux/commit/d747a7a51b00984127a88113cdbbc26f91e9d815
@drweber Anda juga akan menemukan tambalan ini di rilis stabil yang akan datang (untuk saat ini 4.11.12, 4.9.39, 4.4.78, 3.18.62)
@rn
Jika pengguna perangkat jaringan tidak pernah mengurangi jumlah referensi, beberapa bagian lain dari kernel akan menentukan bahwa tugas yang menunggu pembersihan macet dan akan macet. Hanya crash ini yang menunjukkan bug kernel (beberapa pengguna, melalui beberapa jalur kode, tidak mengurangi jumlah referensi). Ada beberapa bug seperti itu dan telah diperbaiki di kernel modern (dan mungkin di-porting kembali ke yang lebih lama). Saya telah menulis beberapa tes stres (dan terus menulisnya) untuk memicu crash seperti itu tetapi belum dapat mereproduksi pada kernel modern (namun saya melakukan pesan di atas).
Harap laporkan masalah ini hanya jika kernel Anda benar-benar mogok ...
Kami mengalami masalah yang sedikit berbeda di lingkungan kami yang saya harap mendapat klarifikasi (kernel 3.16.0-77-generic, Ubuntu 14.04, docker 1.12.3-0~trusty. Kami memiliki ribuan host yang menjalankan docker, 2 -3 kontainer per Host, dan kami melihat ini di <1% dari total host yang menjalankan buruh pelabuhan).
Kami sebenarnya tidak pernah melihat kernel crash, tetapi sebaliknya (seperti reporter asli sejauh yang saya tahu) proses dockerd
tidak berfungsi. Pemula (menggunakan pekerjaan /etc/init/docker.conf
dari paket upstream) tidak akan memulai proses dockerd
karena dianggap sudah berjalan ( start: Job is already running: docker
), dan mencoba menghentikan pemula pekerjaan juga gagal ( 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>
Karena kami kebanyakan menjalankan dengan jaringan jembatan (pada perangkat jembatan khusus) di dmesg
kami melihat pesan yang sedikit berbeda mengacu pada antarmuka virtual:
[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
Karena pemula tampaknya menolak untuk me-restart dockerd atau mengenali bahwa proses yang berjalan sebelumnya adalah zombie, satu-satunya solusi yang kami temukan adalah me-reboot host.
Meskipun hasil kami tampak berbeda (kernel tidak mogok), akar penyebabnya terdengar sama atau mirip. Bukankah ini masalah yang sama? Apakah ada solusi atau cara yang diketahui agar pekerjaan pemula docker
dijalankan kembali ketika ini terjadi?
@campbellr Saya dapat mereproduksi masalah ini dengan pendekatan Anda pada kernel 4.12.2-1.
BTW, jika saya melepas penyimpanan NFS sebelum wadah dihentikan, masalah ini tidak akan terjadi.
permasalahan yang sama.
[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
Hai,
Saya baru saja membuat 2 repo https://github.com/piec/docker-samba-loop dan https://github.com/piec/docker-nfs-loop yang berisi pengaturan yang diperlukan untuk mereproduksi bug ini
Hasil saya:
docker-samba-loop
dalam beberapa iterasi (<10). Saya tidak dapat mereproduksinya dengan docker-nfs-loop
docker-samba-loop
, tidak mencoba docker-nfs-loop
Semoga ini membantu
Bersulang
Solusinya adalah menggunakan --net=host
dalam kasus saya. Tapi itu tidak selalu merupakan solusi yang dapat diterima
@piec , terima kasih banyak atas detailnya. Saya punya beberapa pertanyaan lagi untuk Anda di akhir komentar yang sangat panjang ini.
Dengan menggunakan pengaturan SMB, saya dapat menghasilkan beberapa hal dengan kernel yang berbeda. Saya sudah mencoba ini dengan pengaturan NFS juga tetapi tidak ada dadu.
Semua pengujian dijalankan dengan docker 17.06.1-ce di HyperKit dengan VM yang dikonfigurasi dengan 2 vCPU dan memori 2GB (melalui Docker untuk Mac, tetapi itu tidak masalah). Saya menggunakan kernel LinuxKit, karena saya dapat dengan mudah menukarnya.
Saya memodifikasi Dockerfile
karena saya menambahkan panggilan ke date
sebagai perintah pertama yang dijalankan dan juga menambahkan panggilan ke date
sebelum dan sesudah docker run
untuk klien.
Dengan 4.9.39 (kernel stabil 4.9.x terbaru) saya mengalami crash kernel:
# while true; do date; docker run -it --rm --name client-smb --cap-add=SYS_ADMIN --cap-add DAC_READ_SEARCH --link samba:samba client-smb:1; date; sleep 1; done
Thu 27 Jul 2017 14:12:51 BST
+ date
Thu Jul 27 13:12:52 UTC 2017
+ mount.cifs //172.17.0.2/public /mnt/ -o vers=3.0,user=nobody,password=
+ date
Thu Jul 27 13:12:52 UTC 2017
+ ls -la /mnt
total 1028
drwxr-xr-x 2 root root 0 Jul 27 10:11 .
drwxr-xr-x 1 root root 4096 Jul 27 13:12 ..
-rwxr-xr-x 1 root root 3 Jul 27 10:11 bla
+ umount /mnt
+ echo umount ok
umount ok
Thu 27 Jul 2017 14:12:52 BST
Thu 27 Jul 2017 14:12:53 BST
---> First iteration suceeds and then hangs on the docker run
dan di 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..
Beberapa kali saya melihat beberapa iterasi dari apa yang dilakukan kernel 4.11.12, termasuk pesan unregister_netdevice
(lihat di bawah) dan kemudian mendapatkan kernel crash di atas. Terkadang saya melihat sedikit variasi untuk crash, seperti:
[ 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..
Kerusakan ada dalam kode soket domain unix dan serupa/identik dengan apa yang ada
dilaporkan di sini , meskipun dengan kasus uji baru ini jauh lebih mudah untuk direproduksi.
Dengan 4.11.12 (yang merupakan stabil terbaru dalam seri 4.11) saya tidak melihat crash, tetapi sangat lambat (anotasi sejalan dengan --->
):
# 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
Saya menjalankan ini selama satu jam atau lebih dengan pola yang sama berulang, tetapi tidak ada kernel yang crash.
Saya melihat log kernel, banyak dari:
[ 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
[...]
Itu adalah pesan setiap sepuluh detik.
Karena ini tidak menyebabkan deteksi tugas yang digantung muncul bahkan setelah satu jam, saya menduga bahwa dengan 4.11.12 jumlah referensi akhirnya berkurang dan perangkat dibebaskan, tetapi, dilihat dari interval saya dapat menjalankan wadah, mungkin perlu hingga 4 menit!
Kernel mogok di OP menunjukkan bahwa kernel macet karena tugas yang digantung terdeteksi. Saya belum melihat kerusakan ini dalam pengujian saya, jadi saya mengubah pengaturan sysctl
terkait dengan deteksi tugas yang digantung:
# 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
Ini mengurangi waktu tunggu hingga 60 detik dan membuat kernel panik jika tugas yang digantung terdeteksi. Karena dibutuhkan sekitar 2 menit sebelum dockerd
mengeluh bahwa containerd
tidak dimulai, mengurangi deteksi tugas yang digantung ke 60-an seharusnya memicu kepanikan kernel jika satu tugas digantung. Sayangnya tidak ada kerusakan di log
Selanjutnya, saya meningkatkan sleep
setelah setiap docker run
menjadi 5 menit untuk melihat apakah pesan terus berlanjut. Dalam hal ini semua docker run
s tampaknya berfungsi, yang agak diharapkan karena dari percobaan sebelumnya docker run
akan bekerja setiap 4 menit atau lebih
---> 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
Sepertinya kita mendapatkan unregister_netdevice
senilai sekitar 200 detik di hampir setiap docker run
(kecuali untuk yang kedua). Saya menduga selama waktu itu kami tidak dapat memulai wadah baru (seperti yang ditunjukkan oleh Eksperimen 2. Sangat aneh bahwa deteksi tugas yang digantung tidak dimulai, mungkin karena tidak ada tugas yang digantung.
Ini kembali ke tidur 1 detik di antara docker run
Kami memiliki kernel lain yang memungkinkan banyak debug tambahan
pilihan, seperti LOCKDEP
, RCU_TRACE
, LOCKUP_DETECTOR
dan beberapa
lagi.
Menjalankan kernel repro 4.11.12 dengan opsi debug ini diaktifkan tidak memicu apa pun.
Begitu pula untuk kernel 4.9.39, di mana kernel normal mogok. Opsi debug sedikit mengubah waktu, jadi ini mungkin petunjuk tambahan bahwa kerusakan pada kode soket domain unix disebabkan oleh balapan.
strace
pada berbagai proses containerd
tidak membantu (itu
biasanya bukan karena ditulis dalam Go). Banyak kios panjang di
futex(...FUTEX_WAIT...)
dengan informasi tentang di mana/mengapa.
Beberapa mencari-cari dengan sysrq
:
Meningkatkan verbositas:
echo 9 > /proc/sysrq-trigger
Jejak tumpukan dari semua 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
Tidak ada apa-apa di sini, CPU1 menganggur, CPU0 menangani sysrq.
Tampilkan tugas yang diblokir (dua kali)
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
Ini menunjukkan bahwa antrian kerja netns
dan cleanup_net
sedang sibuk. Saya menemukan masalah yang agak terkait beberapa waktu lalu di sini , tetapi kali ini antrian kerja cleanup_net
berada dalam keadaan yang berbeda.
unregister_netdev
tampaknya tidak terkait dengan perbaikan terbaru (yang ada di 4.9.39 dan 4.11.12). Ini mungkin karena antrian kerja cleanup_net
tidak berjalan dan dengan demikian pesan dicetak.runc
, mungkin saya harus mencoba containerd
.Saya akan menggali lebih dalam dan kemudian mengirim ringkasan ke netdev
.
@piec apakah Anda memiliki akses konsol dan dapat melihat apakah ada sesuatu dalam hal crash dump atau apakah Anda juga hanya melihat penundaan besar seperti yang saya lihat? Jika Anda memiliki crash dump, saya akan sangat tertarik untuk melihatnya. Juga, apakah Anda menjalankan bare metal atau di VM? Apa konfigurasi Anda dalam hal CPU dan memori?
@rn terima kasih atas penyelidikannya!
Saya menjalankan PC desktop baremetal jadi saya memiliki akses ke semuanya. Ini adalah i7-4790K + 32 GiB.
Saat ini saya menjalankan kernel Arch Linux + terbaru dari repo pengujian (4.12.3-1-ARCH)
Dalam kasus saya, semuanya berperilaku seperti yang Anda jelaskan dalam Eksperimen 2 Anda (kernel 4.11.12):
unregister_netdevice: waiting for lo to become free. Usage count = 1
muncul berulang kali jika saya mencoba menjalankan wadah baru apa pun dalam penundaan 4+ menit setelah klien-smb keluar. Dan hanya muncul jika Anda menjalankan wadah baru dalam selang waktu 4 menit itu. Menjalankan wadah baru setelah 4 menit ini akan menjadi "normal"Jadi saya kira ada masalah di suatu tempat dalam proses pembersihan wadah klien-smb yang terkait dengan antarmuka jaringan
Sebenarnya ada repro yang lebih sederhana dari masalah ini (yang, BTW bukan masalah aslinya).
Skrip ini baru saja memulai server SMB di host dan kemudian membuat ruang nama jaringan dengan pasangan veth
, mengeksekusi mount; ls; unmount
di ruang nama jaringan dan kemudian menghapus ruang nama jaringan.
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
Catatan menambahkan sleep 1
setelah unmount, baik saat mengeksekusi di namespace atau sebelum menghapus namespace jaringan berfungsi tanpa mengulur sama sekali saat membuat namespace baru. Tidur setelah namespace lama dihapus, tidak mengurangi penundaan.
@piec Saya juga menguji ini dengan repro Anda dan sleep 1
di Dockerfile setelah unmount dan semuanya berfungsi seperti yang diharapkan, tidak ada penundaan, tidak ada pesan unregister_netdev
.
Saya akan menulis ini sekarang dan mengirim ke netdev@vger
Bagus sekali
Saya mengonfirmasi bahwa sleep
setelah melepas pemasangan, perbaikan yang terhenti dan pesan unregister_netdev
di pengaturan saya juga
Tidakkah menurut Anda umount
menghasilkan tindakan asinkron relatif terhadap netn-nya yang akan memblokir dan akhirnya timeout jika netns dihapus sebelum tindakan itu selesai? Tidur setelah pemasangan akan membiarkan hal ini selesai sebelum jaring dilepas.
Tapi itu hanya hipotesis
Saya mencoba tanpa unmount, perbedaan yang sama. Ini adalah penghapusan namespace jaringan. Itu 9dan penghapusan namespace mount akan tetap memicu unmount.
Ah baiklah
Omong-omong, saya mereproduksi masalah secara tidak sengaja (saat mengembangkan) di komputer lain dengan seseorang lagi. Ini adalah PC Ubuntu 16.04, Linux 4.4.0-77-generik. Dan ada backtrace tugas yang digantung yang mungkin menarik. Tidak ada crash dan delay yang sama ~4 menit.
[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
Utas netdev@vger ada di sini https://www.mail-archive.com/[email protected]/msg179703.html jika ada yang ingin mengikuti perkembangannya.
@piec ya, itu yang diharapkan.
Saya juga mengalami bug ini dan dapat mereproduksi Ups dengan metode docker-samba-loop dari @piec pada gambar kernel Ubuntu:
Saya menambahkan temuan saya ke laporan bug Ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407 dan https://github.com/fho/docker-samba-loop
@fho terima kasih. Anda sebenarnya tidak perlu buruh pelabuhan sama sekali untuk repro, hanya menjalankan klien samba di namespace jaringan akan melakukan trik sesuai https://github.com/moby/moby/issues/5618#issuecomment -318681443
@rn terima kasih atas infonya. Saya belum mencoba cara itu.
Posting terbaru di sini dan dan di milis netdev tampaknya hanya tentang kios kernel.
Saya juga mengalami crash kernel dengan kernel 4.11 dan 4.12.
Saya melihat masalah yang sangat mirip dengan ini (seperti yang dijelaskan di #35068). Kami pada dasarnya menjalankan gerombolan dua simpul, yang menjalankan layanan tunggal dengan 4 replika menggunakan strategi penempatan tersebar.
Di setiap wadah layanan ini, kami memasang host docker.sock sebagai volume, dan dari dalam wadah kami menjalankan perintah docker run
, dengan konkurensi maksimum 4 per wadah. Ini menghasilkan hingga 4 wadah yang dibuat secara bersamaan, dan segera dihapus setelah melalui -rm
.
Log kernel tambahan dan contoh pada ARMv7 ditunjukkan pada referensi di atas.
ip6_route_dev_notify panic adalah masalah serius bagi kami.
Saya pikir melihat ini sedikit lagi, ini jelas BUKAN bug yang sama dengan:
Saya pikir ini adalah masalah hulu di kernel dengan lapisan ipv6.
Informasi ini mungkin relevan.
Kami dapat mereproduksi masalah dengan _unregister_netdevice: menunggu lo menjadi gratis. Jumlah penggunaan = 1_ dengan kernel 4.14.0-rc3 dengan _CONFIG_PREEMPT_NONE=y_ dan hanya berjalan pada satu CPU dengan opsi kernel boot berikut:
BOOT_IMAGE=/boot/vmlinuz-4.14.0-rc3 root=/dev/mapper/vg0-root ro quiet vsyscall=emulate nosmp
Setelah kami mencapai status ini, itu tetap dalam status ini dan reboot diperlukan. Tidak ada lagi wadah yang bisa dimunculkan. Kami mereproduksinya dengan menjalankan gambar melakukan koneksi ipsec/openvpn + mengunduh file kecil di dalam terowongan. Kemudian instance ada (biasanya dijalankan <10 detik). Kami menjalankan 10 kontainer seperti itu dalam satu menit di satu mesin. Dengan pengaturan yang disebutkan di atas (hanya 1cpu), mesin mencapainya dalam ~2 jam.
Reproduksi lain dengan kernel yang sama, tetapi tanpa membatasi jumlah CPU, adalah menjalankan iperf dalam mode UDP selama 3 detik di dalam wadah (jadi tidak ada komunikasi TCP sama sekali). Jika kita menjalankan 10 kontainer tersebut secara paralel, menunggu semuanya selesai dan melakukannya lagi, kita mendapatkan masalah dalam waktu kurang dari 10 menit (pada mesin 40 core).
Di kedua reproduksi kami, kami menambahkan "ip route flush table all; ifconfig
Hai,
Sekedar menambah api kita juga melihat masalah ini, seperti yang diminta berikut ini...
Versi Kernel: Linux exe-v3-worker 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) x86_64 GNU/Linux
Distribusi/versi Linux: Debian 9.1 (dengan semua paket terbaru)
Apakah Anda menggunakan versi kernel terbaru dari vendor Linux Anda? Ya
Pengaturan jaringan (jembatan, hamparan, IPv4, IPv6, dll): Hanya IPv4, NATed sesuai pengaturan Docker default
Deskripsi beban kerja (jenis wadah apa, jenis beban jaringan apa, dll): Wadah yang berumur sangat pendek (dari beberapa detik hingga beberapa menit) menjalankan skrip sebelum keluar.
Dan idealnya reproduksi sederhana:
**kernel:[617624.412100] unregister_netdevice: menunggu lo menjadi gratis. Jumlah penggunaan = 1
Tidak dapat mematikan penampung lama atau memulai penampung baru pada node yang terpengaruh, harus melakukan boot ulang untuk memulihkan fungsionalitas.**
Semoga kita segera menemukan root cause/patchnya.
Salam Hormat,
robputt796
@campbellr
setuju bahwa tampaknya ada hubungannya dengan penyimpanan jaringan. Saya menggunakan ceph krbd sebagai volume persisten di kubernetes.
Dan saya dapat mereproduksi situasi setelah lama menjalankan container crash.
Masalah ini ditetapkan 10 hari yang lalu dan sedang dalam proses, Anda dapat melihat lebih banyak wawasan tentang apa yang terjadi di sini https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407
Semoga Dan Streetman tahu cara memperbaikinya
Ternyata Ups disebabkan oleh bug kernel yang telah diperbaiki oleh komit 76da0704507bbc51875013f6557877ab308cfd0a:
ipv6: hanya panggil ip6_route_dev_notify() sekali untuk NETDEV_UNREGISTER
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76da0704507bbc51875013f6557877ab308cfd0a
(Ini hanya memperbaiki kepanikan kernel, bukan masalah "kernel:unregister_netdevice: menunggu lo menjadi gratis. Jumlah penggunaan = 2".)
(mengulangi ini di sini lagi, karena GitHub menyembunyikan komentar lama)
Masalah yang dibahas di sini adalah bug kernel dan belum sepenuhnya diperbaiki. Beberapa tambalan masuk ke kernel yang memperbaiki _beberapa_ kemunculan masalah ini, tetapi yang lain belum diselesaikan.
Ada sejumlah opsi yang dapat membantu untuk _beberapa_ situasi, tetapi tidak untuk semua (sekali lagi; kemungkinan besar kombinasi masalah yang memicu kesalahan yang sama)
"Saya juga punya ini" tidak membantu menyelesaikan bug. hanya tinggalkan komentar jika Anda memiliki informasi yang dapat membantu menyelesaikan masalah (dalam hal ini; memberikan tambalan ke hulu kernel mungkin merupakan langkah terbaik).
Jika Anda ingin memberi tahu bahwa Anda juga mengalami masalah ini, gunakan tombol "jempol" di deskripsi atas:
Setiap komentar di sini mengirimkan email / pemberitahuan ke lebih dari 3000 orang Saya tidak ingin mengunci percakapan tentang masalah ini, karena belum terselesaikan, tetapi mungkin terpaksa jika Anda mengabaikannya.
Saya akan menghapus komentar yang tidak menambahkan informasi yang berguna untuk (sedikit) mempersingkat utas
Terima kasih!
Saya yakin saya telah memperbaiki masalah ini, setidaknya ketika disebabkan oleh koneksi soket TCP kernel. Kernel uji untuk Ubuntu tersedia dan saya akan senang menerima umpan balik jika mereka membantu/memperbaiki ini untuk siapa pun di sini. Patch dikirimkan ke hulu; lebih detail ada di bug LP:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/comments/46
Maaf merusak perayaan, tetapi kami dapat mereproduksi masalah tersebut. Kami sekarang bekerja dengan @ddstreet di https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/ .
Apakah tidak ada solusi?
Gunakan jaringan host (yang menghancurkan sebagian besar nilai wadah, tetapi begitulah).
@pumba-lt Kami memiliki masalah ini sekitar 1,5 tahun yang lalu, sekitar 1 tahun yang lalu saya menonaktifkan ipv6 di tingkat kernel (bukan sysctl) dan belum pernah mengalami masalah. Menjalankan sekelompok 48 bilah.
Biasanya di: /etc/default/grub
GRUB_CMDLINE_LINUX="xxxxx ipv6.disable=1"
Namun, saya menggunakan boot PXE, jadi konfigurasi PXE saya memiliki:
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
Saya jamin, Anda tidak akan melihat masalah ini lagi.
Semua orang harap dipahami ini adalah GEJALA umum yang memiliki banyak penyebab. Apa yang berhasil bagi Anda untuk menghindari ini mungkin tidak berhasil untuk orang lain.
Saya dapat mengonfirmasi bahwa masalah kami telah terpecahkan setelah menonaktifkan IPv6 saat boot (file konfigurasi fron grub). Punya banyak masalah di cluster 7 node, berjalan lancar sekarang.
Saya tidak ingat di mana saya menemukan solusinya, atau apakah saya menemukannya sendiri, terima kasih @qrpike telah menyarankan ini kepada orang lain :) !!
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.114
komit edaafa805e0f9d09560a4892790b8e19cab8bf09
Penulis: Dan Streetman [email protected]
Tanggal: Kam 18 Jan 16:14:26 2018 -0500
net: tcp: close sock if net namespace is exiting
[ Upstream commit 4ee806d51176ba7b8ff1efd81f271d7252e03a1d ]
When a tcp socket is closed, if it detects that its net namespace is
exiting, close immediately and do not wait for FIN sequence.
For normal sockets, a reference is taken to their net namespace, so it will
never exit while the socket is open. However, kernel sockets do not take a
reference to their net namespace, so it may begin exiting while the kernel
socket is still open. In this case if the kernel socket is a tcp socket,
it will stay open trying to complete its close sequence. The sock's dst(s)
hold a reference to their interface, which are all transferred to the
namespace's loopback interface when the real interfaces are taken down.
When the namespace tries to take down its loopback interface, it hangs
waiting for all references to the loopback interface to release, which
results in messages like:
unregister_netdevice: waiting for lo to become free. Usage count = 1
These messages continue until the socket finally times out and closes.
Since the net namespace cleanup holds the net_mutex while calling its
registered pernet callbacks, any new net namespace initialization is
blocked until the current net namespace finishes exiting.
After this change, the tcp socket notices the exiting net namespace, and
closes immediately, releasing its dst(s) and their reference to the
loopback interface, which lets the net namespace continue exiting.
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=97811
Signed-off-by: Dan Streetman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Menggunakan SCTP di netns juga dapat memicu ini, perbaikan di 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
masih terjadi "unregister_netdevice: menunggu eth0 menjadi gratis. Jumlah penggunaan = 1" meskipun saya telah memutakhirkan versi kernel ke 4.4.118, dan versi buruh pelabuhan 17.09.1-ce mungkin saya harus mencoba menonaktifkan ipv6 di tingkat kernel. Semoga cloud berfungsi.
@ wuming5569 tolong beri tahu saya jika itu berhasil untuk Anda dengan versi linux itu
@wuming5569 mungkin, upgrade kernel 4.4.114 perbaiki "unregister_netdevice: menunggu lo menjadi gratis. Jumlah penggunaan = 1", bukan untuk "unregister_netdevice: menunggu eth0 menjadi gratis. Jumlah penggunaan = 1".
Saya menguji dalam produksi.
@ddstreet ini adalah umpan balik, ada bantuan?
@ wuming5569 seperti yang disebutkan di atas, pesan itu sendiri tidak berbahaya tetapi pada akhirnya dapat menyebabkan kernel hang. Apakah kernel Anda hang dan jika demikian, apa pola jaringan Anda, yaitu jenis jaringan apa yang dilakukan container Anda?
Mengalami masalah yang sama pada CentOS. Kernel saya adalah 3.10.0-693.17.1.el7.x86_64. Tapi, saya tidak mendapatkan jejak tumpukan serupa di syslog.
Sama pada kernel Centos7 3.10.0-514.21.1.el7.x86_64 dan buruh pelabuhan 18.03.0-ce
@danielefranceschi Saya sarankan Anda meningkatkan ke kernel CentOS terbaru (setidaknya 3.10.0-693). Itu tidak akan menyelesaikan masalah, tetapi tampaknya jauh lebih jarang. Di kernel 3.10.0-327 dan 3.10.0-514, kami melihat jejak tumpukan, tetapi menurut ingatan saya, saya rasa kami belum pernah melihatnya di 3.10.0-693.
@alexhexabeam 3.10.0-693 tampaknya berfungsi dengan sempurna, tnx :)
Sama pada kernel CentOS7 4.16.0-1.el7.elrepo.x86_64 dan buruh pelabuhan 18.03.0-ce
Ini bekerja selama berminggu-minggu sebelum crash dan ketika mencoba untuk naik, itu benar-benar macet.
Masalahnya juga terjadi dengan kernel 3.10.0-693.21.1.el7
Saya dapat mengkonfirmasi itu juga terjadi pada:
Linux 3.10.0-693.17.1.el7.x86_64
Red Hat Enterprise Linux Server rilis 7.4 (Maipo)
Saya dapat mereproduksinya dengan melakukan "service docker restart" sambil memuat sejumlah tertentu.
@ wuming5569 sudahkah Anda memperbaiki masalah ini? apa jenis jaringan Anda? kami telah dibingungkan oleh masalah ini selama berminggu-minggu.
Apakah Anda memiliki akun wechat?
4admin2root, dengan perbaikan yang Anda sebutkan, https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.114 ,
apakah aman untuk menonaktifkan proxy userland untuk daemon buruh pelabuhan, jika kernel terbaru yang tepat diinstal? Tidak terlalu jelas apakah itu dari
https://github.com/moby/moby/issues/8356
https://github.com/moby/moby/issues/11185
Karena keduanya lebih tua dari perbaikan kernel
Terima kasih
kami telah dibingungkan oleh masalah ini selama berminggu-minggu.
Linux 3.10.0-693.17.1.el7.x86_64
CentOS Linux rilis 7.4.1708 (Inti)
Adakah yang bisa mengkonfirmasi jika kernel 4.14 terbaru memiliki masalah ini? Sepertinya tidak. Tidak ada seorang pun di Internet yang menghadapi masalah ini dengan kernel 4.14.
Saya melihat ini di kernel 4.15.15-1, Centos7
Melihat log perubahan, https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.15.8 memiliki perbaikan untuk SCTP, tetapi tidak untuk TCP. Jadi, Anda mungkin ingin mencoba versi 4.14.
kami sekarang telah meningkatkan ke 4.16.13. Mengamati. Bug ini menyerang kami pada satu node hanya kira-kira sekali per minggu.
Apakah Anda menonaktifkan ipv6 di grub boot params atau sysctl? Hanya params boot yang akan berfungsi. Sysctl tidak akan memperbaikinya.
Pada tanggal 4 Juni 2018 pukul 12:09:53, Sergey Pronin ( [email protected] (mailto:[email protected])) menulis:
bahkan 4.15.18 tidak membantu dengan bug ini
menonaktifkan ipv6 juga tidak membantukami sekarang telah meningkatkan ke 4.16.13. Mengamati. Bug ini menyerang kami pada satu node hanya kira-kira sekali per minggu.
—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub(https://github.com/moby/moby/issues/5618#issuecomment-394410321), atau nonaktifkan utasnya(https://github.com/notifications/unsubscribe-auth /AAo3HLYI_jnwjgtQ0ce-E4mc6Em5yeISks5t5VvRgaJpZM4B4L4Z).
bagi saya, sebagian besar waktu bug muncul setelah menyebarkan kembali proyek/jaringan yang sama
@qrpike Anda benar, kami hanya mencoba sysctl. Biarkan saya mencoba dengan grub. Terima kasih!
4.9.88 Kernel Debian. Dapat direproduksi.
@qrpike Anda benar, kami hanya mencoba sysctl. Biarkan saya mencoba dengan grub. Terima kasih!
Dalam kasus saya, menonaktifkan ipv6 tidak ada bedanya.
@spronin-aurea Apakah menonaktifkan ipv6 saat boot loader membantu?
@qrpike dapatkah Anda memberi tahu kami tentang node yang Anda gunakan jika menonaktifkan ipv6 membantu dalam kasus Anda? Versi kernel, versi k8s, CNI, versi buruh pelabuhan dll.
@komljen Saya telah menggunakan CoreOS selama 2 tahun terakhir tanpa insiden tunggal. Sejak ~ver 1000. Saya belum mencobanya baru-baru ini tetapi jika saya tidak menonaktifkan ipv6, bug terjadi.
Di pihak saya, saya juga menggunakan CoreOS, ipv6 dinonaktifkan dengan grub dan masih mendapatkan masalah
@deimosfr Saat ini saya menggunakan boot PXE untuk semua node saya:
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
Namun, simpul utama saya yaitu Host PXE juga CoreOS dan boot dari disk, dan juga tidak memiliki masalah.
Versi kernel apa yang kalian jalankan?
Masalah yang saya dapatkan adalah pada 4.14.32-coreos dan sebelumnya. Saya belum menemukan masalah ini pada 4.14.42-coreos
Centos 7.5 dengan kernel 4.17.3-1, masih mengalami masalah.
lingkungan :
kubernet 1.10.4
buruh pelabuhan 13.1
dengan plugin jaringan Flanel.
Catatan :
[ 89.790907] IPv6: ADDRCONF(NETDEV_UP): eth0: tautan belum siap
[ 89.798523] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: tautan menjadi siap
[ 89.799623] cni0: port 8(vethb8a93c6f) memasuki status pemblokiran
[ 89.800547] cni0: port 8(vethb8a93c6f) memasuki status nonaktif
[ 89.801471] perangkat vethb8a93c6f memasuki mode promiscuous
[ 89.802323] cni0: port 8(vethb8a93c6f) memasuki status pemblokiran
[ 89.803200] cni0: port 8(vethb8a93c6f) memasuki status penerusan
kernel:unregister_netdevice : menunggu lo menjadi gratis. Jumlah penggunaan = 1。
Sekarang :
Node IP dapat dijangkau, tetapi tidak dapat menggunakan layanan jaringan apa pun, seperti ssh...
Gejala di sini mirip dengan banyak laporan di berbagai tempat lain. Semua berkaitan dengan ruang nama jaringan. Bisakah orang-orang yang mengalami ini tolong lihat apakah unshare -n
hang, dan jika demikian, dari terminal lain, lakukan cat /proc/$pid/stack
dari proses unshare untuk melihat apakah hang copy_net_ns()
? Ini tampaknya menjadi penyebut umum untuk banyak masalah termasuk beberapa jejak mundur yang ditemukan di sini. Antara 4.16 dan 4.18 ada sejumlah tambalan oleh Kirill Tkhai yang banyak memfaktorkan ulang penguncian yang terlibat. Pengelola paket distro/kernel yang terpengaruh mungkin harus melihat untuk menerapkan/mendukungnya ke kernel yang stabil dan melihat apakah itu membantu.
Lihat juga: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779678
@Blub
sudo cat /proc/122355/stack
[<ffffffff8157f6e2>] copy_net_ns+0xa2/0x180
[<ffffffff810b7519>] create_new_namespaces+0xf9/0x180
[<ffffffff810b775a>] unshare_nsproxy_namespaces+0x5a/0xc0
[<ffffffff81088983>] SyS_unshare+0x193/0x300
[<ffffffff816b8c6b>] tracesys+0x97/0xbd
[<ffffffffffffffff>] 0xffffffffffffffff
Mengingat perubahan penguncian di 4.18, akan lebih baik untuk menguji 4.18rc saat ini, terutama jika Anda dapat memicunya lebih atau kurang andal, karena dari apa yang saya lihat ada banyak orang di mana mengubah versi kernel juga mengubah kemungkinan hal ini terjadi banyak.
Saya mengalami masalah ini dengan Kubernetes dan setelah beralih ke rilis stabil CoreOS terbaru - 1745.7.0 masalahnya hilang:
masalah yang sama pada CentOS 7
@ Blub Melihat hal yang sama pada CoreOS 1688.5.3, kernel 4.14.32
ip-10-72-101-86 core # cat /proc/59515/stack
[<ffffffff9a4df14e>] copy_net_ns+0xae/0x200
[<ffffffff9a09519c>] create_new_namespaces+0x11c/0x1b0
[<ffffffff9a0953a9>] unshare_nsproxy_namespaces+0x59/0xb0
[<ffffffff9a07418d>] SyS_unshare+0x1ed/0x3b0
[<ffffffff9a003977>] do_syscall_64+0x67/0x120
[<ffffffff9a800081>] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[<ffffffffffffffff>] 0xffffffffffffffff
Secara teori mungkin ada satu atau lebih jejak lain di suatu tempat yang berisi salah satu fungsi dari net_namespace.c mengunci net_mutex
( cleanup_net
, net_ns_barrier
, net_ns_init
, {,un}register_pernet_{subsys,device}
). Untuk kernel yang stabil tentu saja akan jauh lebih mudah jika ada satu hal tertentu yang menemui jalan buntu dengan cara yang dapat diperbaiki, daripada mem-backport semua perubahan penguncian dari 4.18. Tapi sejauh ini saya belum melihat jejak yang mengarah ke akar penyebabnya. Saya tidak tahu apakah itu akan membantu, tetapi mungkin /proc/*/stack
s lain dengan fungsi di atas terlihat ketika masalah muncul?
masalah yang sama! dan env saya adalah debian 8
RHEL, SWARM, 18.03.0-ce
Memulai container secara manual pada node manager:
sudo docker run -it -v /import:/temp/eximport -v /home/myUser:/temp/exhome docker.repo.myHost/ fedora:23 /bin/bash
Setelah beberapa waktu tidak melakukan apa-apa:
[ root@8a9857c25919 myDir]#
Pesan dari syslogd@se1-shub-t002 pada 19 Juli 11:56:03 ...
kernel:unregister_netdevice : menunggu lo menjadi gratis. Jumlah penggunaan = 1
Setelah beberapa menit saya kembali ke konsol node manajer dan wadah yang dimulai tidak berjalan lagi.
Apakah ini menggambarkan masalah yang sama atau ini "problem suite" yang lain?
THX sebelumnya!
MEMPERBARUI
Ini juga terjadi langsung di konsol ssh (di swarm manager bash).
MEMPERBARUI
Mesin host (satu node manajer di swarm):
Linux [MACHINENNAME] 3.10.0-514.2.2.el7.x86_64 #1 SMP Rab 16 Nov 13:15:13 EST 2016 x86_64 x86_64 x86_64 GNU/Linux
Jika ini tidak diperbaiki setelah beberapa waktu, maka ini masalah yang berbeda.
Sama pada kernel CentOS7.5 3.10.0-693.el7.x86_64 dan buruh pelabuhan 1.13.1
Masalah yang sama OEL 7.5
uname -a
4.1.12-124.16.1.el7uek.x86_64 #2 SMP Sen 11 Jun 20:09:51 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
info buruh pelabuhan
Wadah: 9
Lari: 5
Dijeda: 0
Berhenti: 4
Gambar: 6
Versi Server: 17.06.2-ol
dmesg
[2238374.718889] unregister_netdevice: menunggu lo menjadi gratis. Jumlah penggunaan = 1
[2238384.762813] unregister_netdevice: menunggu lo menjadi gratis. Jumlah penggunaan = 1
[2238392.792585] eth0: diganti namanya dari vethbed6d59
(mengulangi ini https://github.com/moby/moby/issues/5618#issuecomment-351942943 di sini lagi, karena GitHub menyembunyikan komentar lama)
Masalah yang dibahas di sini adalah bug kernel dan belum sepenuhnya diperbaiki. Beberapa tambalan masuk ke kernel yang memperbaiki _beberapa_ kemunculan masalah ini, tetapi yang lain belum diselesaikan.
Ada sejumlah opsi yang dapat membantu untuk _beberapa_ situasi, tetapi tidak untuk semua (sekali lagi; kemungkinan besar kombinasi masalah yang memicu kesalahan yang sama)
Jika kernel crash _after_ itu bug (lihat di bawah)
"Saya juga punya ini" tidak membantu menyelesaikan bug. hanya tinggalkan komentar jika Anda memiliki informasi yang dapat membantu menyelesaikan masalah (dalam hal ini; memberikan tambalan ke hulu kernel mungkin merupakan langkah terbaik).
Jika Anda ingin memberi tahu bahwa Anda juga mengalami masalah ini, gunakan tombol "jempol" di deskripsi atas:
Setiap komentar di sini mengirimkan email / pemberitahuan ke lebih dari 3000 orang Saya tidak ingin mengunci percakapan tentang masalah ini, karena belum terselesaikan, tetapi mungkin terpaksa jika Anda mengabaikannya.
Saya akan menghapus komentar yang tidak menambahkan informasi yang berguna untuk (sedikit) mempersingkat utas
Untuk lebih jelasnya, pesan itu sendiri jinak , itu adalah kernel crash setelah pesan yang dilaporkan oleh OP yang tidak.
Komentar dalam kode, dari mana pesan ini berasal, menjelaskan apa yang terjadi. Pada dasarnya setiap pengguna, seperti tumpukan IP) dari perangkat jaringan (seperti akhir dari pasangan
veth
di dalam wadah) menambah jumlah referensi dalam struktur perangkat jaringan saat menggunakan perangkat jaringan. Saat perangkat dilepas (mis. saat wadah dilepas) setiap pengguna diberi tahu sehingga mereka dapat melakukan pembersihan (mis. menutup soket terbuka, dll.) sebelum mengurangi jumlah referensi. Karena pembersihan ini dapat memakan waktu, terutama di bawah beban berat (banyak antarmuka, banyak koneksi dll), kernel dapat mencetak pesan di sini sesekali .Jika pengguna perangkat jaringan tidak pernah mengurangi jumlah referensi, beberapa bagian lain dari kernel akan menentukan bahwa tugas yang menunggu pembersihan macet dan akan macet. Hanya crash ini yang menunjukkan bug kernel (beberapa pengguna, melalui beberapa jalur kode, tidak mengurangi jumlah referensi). Ada beberapa bug seperti itu dan telah diperbaiki di kernel modern (dan mungkin di-porting kembali ke yang lebih lama). Saya telah menulis beberapa tes stres (dan terus menulisnya) untuk memicu crash seperti itu tetapi belum dapat mereproduksi pada kernel modern (namun saya melakukan pesan di atas).
* Harap laporkan masalah ini hanya jika kernel Anda benar-benar mogok *, dan kami akan sangat tertarik pada:
- versi kernel (keluaran dari
uname -r
)- Distribusi/versi Linux
- Apakah Anda menggunakan versi kernel terbaru dari vendor Linux Anda?
- Pengaturan jaringan (jembatan, overlay, IPv4, IPv6, dll)
- Deskripsi beban kerja (jenis wadah apa, jenis beban jaringan apa, dll)
- Dan idealnya reproduksi sederhana
Terima kasih!
Apakah kalian menjalankan buruh pelabuhan di bawah batasan apa pun? Seperti ulimits, cgroups dll ...
systemd yang lebih baru memiliki batas default bahkan jika Anda tidak mengaturnya. Saya mengatur semuanya menjadi tidak terbatas dan masalah belum terjadi sejak itu (menonton sejak 31 hari).
Saya memiliki masalah yang sama di banyak lingkungan dan solusi saya adalah menghentikan firewall. Itu tidak terjadi lagi, untuk saat ini
Rhel 7.5 - 3.10.0-862.3.2.el7.x86_64
buruh pelabuhan 1.13
@dElogics Apa versi systemd yang dianggap "lebih baru"? Apakah batas default ini diaktifkan di sistem CentOS 7.5?
Juga, ketika Anda bertanya apakah kami menjalankan buruh pelabuhan di bawah batasan apa pun, maksud Anda daemon buruh pelabuhan, atau wadah individu?
Daemon buruh pelabuhan. Systemd seperti pada Debian 9 (232-25).
Tidak yakin tentang RHEL, tetapi saya pribadi juga melihat masalah ini di RHEL. Saya akan mengatur LimitNOFILE=1048576, LimitNPROC=infinity, LimitCORE=infinity, TasksMax=infinity
kernel: unregister_netdevice: menunggu eth0 menjadi gratis. Jumlah penggunaan = 3
kernel 4.4.146-1.el7.elrepo.x86_64
versi linux CentOS rilis Linux 7.4.1708 (Inti)
modus jembatan
Saya memiliki masalah yang sama, apa yang bisa saya lakukan?
Masalah yang sama:
CentOS Linux merilis 7.5.1804 (Inti)
Versi Docker 18.06.1-ce, build e68fc7a
Versi Kernel: 3.10.0-693.el7.x86_64
Masalah serupa yang saya temui di sini ...
Apakah ada gerakan yang bisa saya lakukan sekarang? Tolong bantu saya...
CentOS 7.0.1406
[ root@zjsm-slavexx dll]# uname -a
Linux zjsm-slave08 3.10.0-123.el7.x86_64 #1 SMP Sen 30 Jun 12:09:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[ root@zjsm-slavexx dll]# cat /etc/centos-release
CentOS Linux rilis 7.0.1406 (Inti)
Informasi buruh pelabuhan:
[ root@zjsm-slavexx ~]# versi buruh pelabuhan
Klien:
Versi: 17.04.0-ce
Versi API: 1.28
Pergi versi: go1.7.5
Git komit: 4845c56
Dibangun: Sen 3 Apr 18:01:50 2017
OS/Arch: linux/amd64
Server:
Versi: 17.04.0-ce
Versi API: 1.28 (versi minimum 1.12)
Pergi versi: go1.7.5
Git komit: 4845c56
Dibangun: Sen 3 Apr 18:01:50 2017
OS/Arch: linux/amd64
Eksperimental: salah
CentOS Linux merilis kernel 7.2.1511: 3.10.0-327.el7.x86_64
permasalahan yang sama
Saya telah bereksperimen dengan masalah ini.
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 , mungkin Anda harus menambahkan komentar Anda ke atas posting asli, karena orang masih mengabaikannya.
$ 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
memperbaikinya.
@hzbd Maksud Anda menghapus jaringan jembatan yang ditentukan pengguna? Sudahkah Anda mencoba menggali lebih jauh untuk mencari tahu alasannya? Tolong beri tahu saya jika Anda melakukannya. Saya sangat menghargainya.
Menunggu untuk diperbaiki
Apakah kalian menjalankan buruh pelabuhan di bawah batasan apa pun? Seperti ulimits, cgroups dll ...
systemd yang lebih baru memiliki batas default bahkan jika Anda tidak mengaturnya. Saya mengatur semuanya menjadi tidak terbatas dan masalah belum terjadi sejak itu (menonton sejak 31 hari).
Oke, bug ini masih terjadi, tetapi kemungkinannya telah berkurang.
Saya pikir jika wadah dihentikan dengan anggun (PID 1 ada), maka bug ini tidak akan mengganggu kita.
@dElogics terima kasih telah memberi tahu kami, bisakah Anda menunjukkan kepada kami perintah apa yang Anda jalankan untuk mengatur batas systemd ini menjadi tidak terbatas. Saya juga suka mencobanya.
@dElogics terima kasih telah memberi tahu kami, bisakah Anda menunjukkan kepada kami perintah apa yang Anda jalankan untuk mengatur batas systemd ini menjadi tidak terbatas. Saya juga suka mencobanya.
Anda harus memodifikasi unit systemd dari buruh pelabuhan. Unit systemd yang saya gunakan (hanya bagian yang relevan) --
[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
Apakah seseorang memiliki masalah ini di kernel 4.15 atau yang lebih baru?
Perbaikan Dan Streetman ini (https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d) pertama kali disertakan dalam versi kernel 4.15 dan tampaknya setidaknya untuk seseorang itu tidak terjadi lagi sejak mereka memutakhirkan ke 4.16 (https:/ /github.com/kubernetes/kubernetes/issues/64743#issuecomment-436839647)
Apakah seseorang mencobanya?
@victorgp Kami masih mengalami masalah dengan kernel 4.15. Kami akan melaporkan di sini ketika kami telah menguji dengan kernel 4.16 (semoga dalam beberapa minggu).
Kami menggunakan versi kernel
Untuk menambah resolusi saya sebelumnya -- wadah yang berhenti dengan anggun (yang merespons SIGTERM) tidak pernah memicu ini.
Coba juga jalankan wadah di namespace Host (jika dapat diterima untuk Anda) yang sepenuhnya menyelesaikan masalah.
@dElogics Apa yang Anda maksud dengan "host namespace"? Apakah hanya --privileged
?
@dElogics Apa yang Anda maksud dengan "host namespace"? Apakah hanya
--privileged
?
Tidak, itu berarti --network=host
Sejak memutakhirkan dari kernel 4.4.0 ke 4.15.0 dan buruh pelabuhan 1.11.2 ke 18.09 masalahnya hilang.
Dalam armada VM yang cukup besar yang bertindak sebagai host buruh pelabuhan, kami mengalami masalah ini muncul beberapa kali sehari (dengan kasus penggunaan Docker kami).
45 hari dan kami tidak lagi melihat ini.
Untuk anak cucu, jejak tumpukan Docker 1.11.2 yang digantung dengan printk menunjukkan unregister_netdevice: waiting for vethXXXXX
(mirip dengan apa yang selalu kami lihat di armada kami, dalam ratusan VM) dapat ditemukan di http://paste .ubuntu.com/p/6RgkpX352J/ ( 0xc820001980
)
goroutine 8809 [syscall, 542 minutes, locked to thread]:
syscall.Syscall6(0x2c, 0xd, 0xc822f3d200, 0x20, 0x0, 0xc822f3d1d4, 0xc, 0x20, 0xc82435fda0, 0x10)
/usr/local/go/src/syscall/asm_linux_amd64.s:44 +0x5
syscall.sendto(0xd, 0xc822f3d200, 0x20, 0x20, 0x0, 0xc822f3d1d4, 0xc80000000c, 0x0, 0x0)
/usr/local/go/src/syscall/zsyscall_linux_amd64.go:1729 +0x8c
syscall.Sendto(0xd, 0xc822f3d200, 0x20, 0x20, 0x0, 0x7faba31bded8, 0xc822f3d1c8, 0x0, 0x0)
/usr/local/go/src/syscall/syscall_unix.go:258 +0xaf
github.com/vishvananda/netlink/nl.(*NetlinkSocket).Send(0xc822f3d1c0, 0xc82435fda0, 0x0, 0x0)
/usr/src/docker/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go:333 +0xd4
github.com/vishvananda/netlink/nl.(*NetlinkRequest).Execute(0xc82435fda0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
/usr/src/docker/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go:215 +0x111
github.com/vishvananda/netlink.LinkDel(0x7fab9c2b15d8, 0xc825ef2240, 0x0, 0x0)
/usr/src/docker/vendor/src/github.com/vishvananda/netlink/link_linux.go:615 +0x16b
github.com/docker/libnetwork/drivers/bridge.(*driver).DeleteEndpoint(0xc8204aac30, 0xc8203ae780, 0x40, 0xc826e7b800, 0x40, 0x0, 0x0)
/usr/src/docker/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go:1060 +0x5cf
github.com/docker/libnetwork.(*endpoint).deleteEndpoint(0xc822945b00, 0xc82001ac00, 0x0, 0x0)
/usr/src/docker/vendor/src/github.com/docker/libnetwork/endpoint.go:760 +0x261
github.com/docker/libnetwork.(*endpoint).Delete(0xc822945b00, 0x7fab9c2b0a00, 0x0, 0x0)
/usr/src/docker/vendor/src/github.com/docker/libnetwork/endpoint.go:735 +0xbcb
github.com/docker/libnetwork.(*sandbox).delete(0xc8226bc780, 0xc8229f0600, 0x0, 0x0)
/usr/src/docker/vendor/src/github.com/docker/libnetwork/sandbox.go:217 +0xd3f
github.com/docker/libnetwork.(*sandbox).Delete(0xc8226bc780, 0x0, 0x0)
/usr/src/docker/vendor/src/github.com/docker/libnetwork/sandbox.go:175 +0x32
github.com/docker/docker/daemon.(*Daemon).releaseNetwork(0xc820001980, 0xc820e23a40)
/usr/src/docker/.gopath/src/github.com/docker/docker/daemon/container_operations.go:732 +0x4f1
github.com/docker/docker/daemon.(*Daemon).Cleanup(0xc820001980, 0xc820e23a40)
/usr/src/docker/.gopath/src/github.com/docker/docker/daemon/start.go:163 +0x62
github.com/docker/docker/daemon.(*Daemon).StateChanged(0xc820001980, 0xc825f9fac0, 0x40, 0xc824155b50, 0x4, 0x8900000000, 0x0, 0x0, 0x0, 0x0, ...)
/usr/src/docker/.gopath/src/github.com/docker/docker/daemon/monitor.go:39 +0x60a
github.com/docker/docker/libcontainerd.(*container).handleEvent.func2()
/usr/src/docker/.gopath/src/github.com/docker/docker/libcontainerd/container_linux.go:177 +0xa5
github.com/docker/docker/libcontainerd.(*queue).append.func1(0xc820073c01, 0xc820f9a2a0, 0xc821f3de20, 0xc822ddf9e0)
/usr/src/docker/.gopath/src/github.com/docker/docker/libcontainerd/queue_linux.go:26 +0x47
created by github.com/docker/docker/libcontainerd.(*queue).append
/usr/src/docker/.gopath/src/github.com/docker/docker/libcontainerd/queue_linux.go:28 +0x1da
Dari situ kita dapat mengamati bahwa itu digantung di https://github.com/moby/moby/blob/v1.11.2/daemon/container_operations.go#L732
yang mengarahkan kami ke https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/sandbox.go#L175
Dan
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/endpoint.go#L760
Yang masuk ke driver jembatan libnetwork (periksa deskripsi yang luar biasa)
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go#L1057 -L1061
Pindah ke netlink
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go#L601 -L617
https://github.com/moby/moby/blob/v1.11.2//vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go#L215
Dan akhirnya di soket netlink itu, panggil https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go#L333
Kami merasa bahwa bug secara umum terjadi ketika menghentikan sebuah wadah dan karena SKB masih direferensikan di jaringan, veth tidak dirilis, maka Docker mengeluarkan Kill ke wadah itu setelah 15 detik. Daemon Docker tidak menangani situasi ini dengan baik, tetapi pada akhirnya bug ada di kernel. Kami percaya bahwa https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d (diterima di 4.15 hulu) dan komit yang terkait dengannya (ada beberapa) bertindak sebagai mitigasi.
Secara umum, bagian kernel itu bukanlah tempat yang bagus.
Untuk apa nilainya...kami memutakhirkan kernel RHEL Linux dari 3.10.0 ke 4.17.11. (Menjalankan cluster Kubernetes aktif). Sebelum memutakhirkan, bug ini terjadi setiap hari beberapa kali di server yang berbeda. Berjalan dengan upgrade selama tiga minggu sekarang. Bug hanya terjadi sekali. Jadi secara kasar dikatakan berkurang 99%.
@marckamerbeek Anda memperbarui Kernel RHEL ke Kernel komunitas? Kemudian tidak lagi didukung.
Pengguna @Beatlor CentOS dapat melakukan seperti ini.
centos 7.2 masih memiliki masalah ini: kernel:unregister_netdevice : menunggu lo menjadi gratis. Jumlah penggunaan = 1
@Beatlor RHEL tidak membantu kami sama sekali. Lingkungan produksi yang stabil lebih penting daripada beberapa kontrak dukungan yang tidak berharga. Kami masih berjalan sangat stabil sekarang pada 4.17.11. Tidak ada masalah besar lagi.
@Beatlor RHEL tidak membantu kami sama sekali. Lingkungan produksi yang stabil lebih penting daripada beberapa kontrak dukungan yang tidak berharga. Kami masih berjalan sangat stabil sekarang pada 4.17.11. Tidak ada masalah besar lagi.
Ya, saya juga tidak mengalami masalah ini setelah memutakhirkan kernel ke 4.17.0-1.el7.elrepo.x86_64. Saya mencoba ini sebelumnya (4.4.x, 4.8, 4.14..) dan gagal. Tampaknya masalah tidak akan terjadi lagi di kernel 4.17+.
centos 7.2 masih memiliki masalah ini: kernel:unregister_netdevice : menunggu lo menjadi gratis. Jumlah penggunaan = 1
Anda dapat mencoba memutakhirkan ke kernel 4.19+ terbaru.
Tunggu beberapa bulan dan seseorang akan datang mengeluh tentang kernel 4.19 juga. Hanya sejarah yang berulang.
Hai semuanya, kabar baik!
Sejak komentar terakhir saya di sini (pada saat penulisan, 17 hari yang lalu) saya tidak mendapatkan kesalahan ini lagi. Server saya (sekitar 30 di antaranya) menjalankan ubuntu 14.04 dengan beberapa paket usang.
Setelah pemutakhiran sistem penuh termasuk mesin buruh pelabuhan (dari 1.7.1 ke 1.8.3) + pemutakhiran kernel ke versi terbaru yang mungkin di repo ubuntu, server saya berjalan tanpa kejadian apa pun.
🎱
versi kernel mana yang Anda tingkatkan?
mungkin terkait dengan ini https://github.com/torvalds/linux/commit/f186ce61bb8235d80068c390dc2aad7ca427a4c2
Berikut adalah upaya untuk meringkas masalah ini, dari komentar masalah ini, https://github.com/kubernetes/kubernetes/issues/70427 , https://github.com/kubernetes/kubernetes/issues/64743 , dan https: //access.redhat.com/solutions/3659011
Saya menantang https://github.com/kubernetes/kubernetes/issues/70427#issuecomment -470681000 karena kami belum pernah melihat ini dengan ribuan VM di 4.15.0 sementara kami melihatnya puluhan kali setiap hari di 4.4. 0, apakah ada lebih banyak laporan di 4.15.0?
Saya melihat masalah ini dengan salah satu mesin saya yang menjalankan Docker di Debian 9 Stretch ( 4.9.0-8-amd64
). Saya mengalami masalah ini dengan terowongan yang dibuat di dalam wadah Docker melalui Docker Gen dan itu menghasilkan kepanikan kernel:
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
Berikut informasi Docker kami:
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
Adakah yang tahu jika ada perbaikan sementara untuk ini tanpa me-restart seluruh mesin? Kami benar-benar lebih suka tidak harus me-restart seluruh mesin ketika kami mengalami masalah ini.
Agak di luar topik, kami juga tidak dapat menekan pesan panik kernel di dalam terminal. Saya sudah mencoba dmesg -D
dan dmesg -n 1
. Namun, tidak beruntung. Apakah ada cara untuk menekan jenis pesan panik kernel ini dari dalam terminal? Sangat menjengkelkan mencoba mengetik perintah dan pesan itu muncul setiap 10 detik atau lebih.
Terima kasih.
Apakah kernel vanilla ini atau banyak ditambal oleh distro dengan perbaikan yang di-backport?
@pmoust Saya melihat ini di ubuntu 4.15.0-32 seminggu sekali atau lebih. pasti jauh lebih baik sejak 4.4.0
@iavael saya akan mencoba membuat daftar info distro dalam ringkasan jika referensi menyediakannya.
Adakah yang melihat bug ini dengan 4.19?
Adakah yang melihat bug ini dengan 4.19?
https://github.com/kubernetes/kubernetes/issues/64743#issuecomment -451351435
https://github.com/kubernetes/kubernetes/issues/64743#issuecomment -461772385
Informasi ini mungkin berguna untuk Anda.
@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 Silakan lihat ini https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs-while-testing-tidb-operator-in-k8s/
@tankywoo @drpancake @egasimus @csabahenk @spiffytech @ibuildthecloud @sbward @jbalonso @rsampaio @MrMMorris @rsampaio @unclejack @chrisjstevenson @popsikle @fxposter @ scher200 @victorgp @jstangroome @ Xuexiang825 @dElogics @Nowaker @pmoust @marckamerbeek @Beatlor @warmchang @Jovons @247687009 @jwongz @tao12345666333 @clkao Silakan lihat ini https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs-while-testing-tidb-operator-in-k8s/
Saya mengikuti dokumentasi, tetapi saya masih mendapatkan kesalahan.
[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
Pesan itu sendiri bukanlah bug; itu kernel yang mogok sesudahnya; 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 Silakan lihat ini https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs-while-testing-tidb-operator-in-k8s/
Saya mengikuti dokumentasi, tetapi saya masih mendapatkan kesalahan.
[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
Setelah reboot, ok···
@vincent927 BTW,Anda harus meletakkan livepatch_route.ko ke /var/lib/kpatch/$(uname -r), ketika mengaktifkan kpatch.service, ko dapat dimuat secara otomatis setelah reboot.
Kami mendapatkan ini di perusahaan kami tiba-tiba hari ini di beberapa kluster kubernetes.
uname -a
:
Linux ip-10-47-17-58 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux
docker version
:
Client:
Version: 18.09.5
API version: 1.39
Go version: go1.10.8
Git commit: e8ff056dbc
Built: Thu Apr 11 04:44:28 2019
OS/Arch: linux/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 18.09.2
API version: 1.39 (minimum version 1.12)
Go version: go1.10.6
Git commit: 6247962
Built: Sun Feb 10 03:42:13 2019
OS/Arch: linux/amd64
Experimental: false
kubectl version
(server):
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"}
Kami belum tahu penyebabnya; kami telah menjalankan versi perangkat lunak di atas selama beberapa bulan tanpa masalah. Saya hanya berkomentar untuk menambah daftar "versi perangkat lunak yang mengalami bug ini" untuk saat ini.
@2rs2ts Sudahkah Anda mencoba https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs-while-testing-tidb-operator-in-k8s/?
@ethercflow Saya telah membacanya, tetapi karena kami menjalankan Debian di perusahaan saya, tidak mudah bagi kami untuk menerapkan perbaikan di pos itu.
@ethercflow @2rs2ts kami juga menjalankan debian. Saya telah mengalami banyak masalah saat mencoba membuat kpatch-build berfungsi. Jika saya berhasil menemukan solusi, saya akan terus mengabari Anda. Dalam hal apapun, apakah ada yang punya solusi lain? Apakah kernel versi 4.15 atau 4.19 yang mengurangi masalah? Saya telah mencoba menemukan jawabannya selama seminggu terakhir dan masih belum berhasil.
@commixon pengalaman kami masih sama seperti yang dilaporkan di https://github.com/moby/moby/issues/5618#issuecomment -455800975, di ribuan VM, tidak ada masalah yang muncul kembali dengan 4.15.0 pada rasa kernel generik, dioptimalkan AWS, dan dioptimalkan GCP yang disediakan oleh Canonical. Tes terbatas pada vanilla 4.15.0 juga tidak menunjukkan masalah tersebut, tetapi tidak diuji pada skala.
Terima kasih banyak @pmoust . Akan mencobanya. Bagaimanapun saya juga akan mencoba menambal kpatch untuk bekerja dengan Debian (sebagai proyek sampingan) dan memposting pembaruan di sini untuk siapa saja yang tertarik.
@ethercflow @2rs2ts kami juga menjalankan debian. Saya telah mengalami banyak masalah saat mencoba membuat kpatch-build berfungsi. Jika saya berhasil menemukan solusi, saya akan terus mengabari Anda. Dalam hal apapun, apakah ada yang punya solusi lain? Apakah kernel versi 4.15 atau 4.19 yang mengurangi masalah? Saya telah mencoba menemukan jawabannya selama seminggu terakhir dan masih belum berhasil.
Anda dapat meningkatkan ke 4.19. Ada di backport.
BTW sudah setahun bagi kami di sini. ;)
Kami benar-benar mencoba 4.19 di backports tetapi memiliki beberapa regresi besar di area lain (instance EC2 hanya akan reboot secara acak dan kemudian jaringan akan rusak saat startup.) Kurasa kita harus menghadapi ini sampai stable berikutnya.
@2rs2ts Selama 4 hari terakhir kami menggunakan 4.19 dari backports (di EC2) dan kami tidak melihat masalah sama sekali. Masalah crash kernel belum muncul sama sekali dan yang lainnya juga tampak baik-baik saja. Saya tidak percaya itu ada bedanya tetapi kami mendasarkan gambar Debian kami dengan yang disediakan oleh kops (https://github.com/kubernetes/kops/blob/master/docs/images.md#debian). Kami memperbarui kernel pada gambar ini dan bukan debian stok.
Teman-teman, saya telah menggunakan kernel 4.19 untuk operasi yang stabil selama setengah tahun. Saya harap Anda juga dapat menikmati stabilitas.
Saya memiliki wadah terbuka 80 dan 443 port, setiap 2 minggu, dari komputer lain mengakses wadah 80 dan
443 ditolak
versi kernel centos7.3 adalah:
Browser Linux1 3.10.0-514.el7.x86_64 #1 SMP Sel 22 Nov 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
root@browser1 ~]# versi buruh pelabuhan
Klien:
Versi: 18.06.3-ce
Versi API: 1.38
Pergi versi: go1.10.4
Git komit: d7080c1
Dibangun: Rabu 20 Februari 02:24:22 2019
OS/Arch: linux/amd64
Eksperimental: salah
Server:
Mesin:
Versi: 18.06.3-ce
Versi API: 1.38 (versi minimum 1.12)
Pergi versi: go1.10.3
Git komit: d7080c1
Dibangun: Rabu 20 Februari 02:25:33 2019
OS/Arch: linux/amd64
Eksperimental: salah
[ root@browser1 ~]#
pesan:
[1063959.636785] unregister_netdevice: menunggu lo menjadi gratis. Jumlah penggunaan = 1
[1071340.887512] br-af29e1edc1b8: port 5(vethc2ac4f8) memasuki status nonaktif
[1071340.891753] br-af29e1edc1b8: port 5(vethc2ac4f8) memasuki status nonaktif
[1071340.895118] perangkat vethc2ac4f8 meninggalkan mode promiscuous
[1071340.895138] br-af29e1edc1b8: port 5(vethc2ac4f8) memasuki status nonaktif
[1071340.990505] perangkat veth5e4f161 memasuki mode promiscuous
[1071340.990897] IPv6: ADDRCONF(NETDEV_UP): veth5e4f161: tautan belum siap
[1071340.990904] br-af29e1edc1b8: port 5(veth5e4f161) memasuki status penerusan
[1071340.990924] br-af29e1edc1b8: port 5(veth5e4f161) memasuki status penerusan
[1071341.231405] IPv6: ADDRCONF(NETDEV_CHANGE): veth5e4f161: tautan menjadi siap
[1071355.991701] br-af29e1edc1b8: port 5(veth5e4f161) memasuki status penerusan
[1071551.533907] br-af29e1edc1b8: port 5(veth5e4f161) memasuki status nonaktif
[1071551.537564] br-af29e1edc1b8: port 5(veth5e4f161) memasuki status nonaktif
[1071551.540295] perangkat veth5e4f161 meninggalkan mode promiscuous
[1071551.540313] br-af29e1edc1b8: port 5(veth5e4f161) memasuki status nonaktif
[1071551.570924] perangkat veth8fd3a0a memasuki mode promiscuous
[1071551.571550] IPv6: ADDRCONF(NETDEV_UP): veth8fd3a0a: tautan belum siap
[1071551.571556] br-af29e1edc1b8: port 5(veth8fd3a0a) memasuki status penerusan
[1071551.571582] br-af29e1edc1b8: port 5(veth8fd3a0a) memasuki status penerusan
[1071551.841656] IPv6: ADDRCONF(NETDEV_CHANGE): veth8fd3a0a: tautan menjadi siap
[1071566.613998] br-af29e1edc1b8: port 5(veth8fd3a0a) memasuki status penerusan
[1071923.465082] br-af29e1edc1b8: port 5(veth8fd3a0a) memasuki status nonaktif
[1071923.470215] br-af29e1edc1b8: port 5(veth8fd3a0a) memasuki status nonaktif
[1071923.472888] perangkat veth8fd3a0a meninggalkan mode promiscuous
[1071923.472904] br-af29e1edc1b8: port 5(veth8fd3a0a) memasuki status nonaktif
[1071923.505580] perangkat veth9e693ae memasuki mode promiscuous
[1071923.505919] IPv6: ADDRCONF(NETDEV_UP): veth9e693ae: tautan belum siap
[1071923.505925] br-af29e1edc1b8: port 5(veth9e693ae) memasuki status penerusan
[1071923.505944] br-af29e1edc1b8: port 5(veth9e693ae) memasuki status penerusan
[1071923.781658] IPv6: ADDRCONF(NETDEV_CHANGE): veth9e693ae: tautan menjadi siap
[1071938.515044] br-af29e1edc1b8: port 5(veth9e693ae) memasuki status penerusan
Adakah yang melihat bug ini dengan 4.19?
Ya. Saya memiliki masalah pada kernel 4.19.4-1.e17.elrep.x86_64
Halo,
Saya juga melihat kesalahan ini. Apakah kita punya solusi untuk masalah ini? Kernel 3.10.0-514.26.2.el7.x86_64
[username@ip-10-1-4-64 ~]$
Message from syslogd@ip-10-1-4-64 at Jul 19 10:50:01 ...
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1
Message from syslogd@ip-10-1-4-64 at Jul 19 10:50:48 ...
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1
Masalah ini masih terjadi :( tidak ada pembaruan/ide tentang cara memperbaikinya?
Terjadi di Debian Stretch. Saya mencoba memperbarui wadah Jenkins saya melalui Ansible ketika ini terjadi.
Masalah ini telah diselesaikan oleh komit ini:
https://github.com/torvalds/linux/commit/ee60ad219f5c7c4fb2f047f88037770063ef785f
Menggunakan 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
Masalah ini telah diselesaikan oleh komit ini:
torvalds/ linux@ee60ad2
Menggunakan kpatchcurl -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
Ini harus di 4.19.30 dan seterusnya.
Saya tidak yakin torvalds/ linux@ee60ad2 adalah perbaikan definitif untuk itu - kami telah melihat ini di 4.4.0 AFAR, sedangkan https://github.com/torvalds/linux/commit/deed49df7390d5239024199e249190328f1651e7 hanya ditambahkan di 4.5.0
Kami telah mereproduksi bug yang sama menggunakan kernel diagnostik yang memiliki penundaan yang dimasukkan secara artifisial untuk membuat rute pengecualian penemuan PMTU mencapai jendela ini.
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index a0163c5..6b9e7ee 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -133,6 +133,8 @@
static int ip_min_valid_pmtu __read_mostly = IPV4_MIN_MTU;
+static int ref_leak_test;
+
/*
* Interface to generic destination cache.
*/
@@ -1599,6 +1601,9 @@ static void ip_del_fnhe(struct fib_nh *nh, __be32 daddr)
fnhe = rcu_dereference_protected(*fnhe_p, lockdep_is_held(&fnhe_lock));
while (fnhe) {
if (fnhe->fnhe_daddr == daddr) {
+ if (ref_leak_test)
+ pr_info("XXX pid: %d, %s: fib_nh:%p, fnhe:%p, daddr:%x\n",
+ current->pid, __func__, nh, fnhe, daddr);
rcu_assign_pointer(*fnhe_p, rcu_dereference_protected(
fnhe->fnhe_next, lockdep_is_held(&fnhe_lock)));
fnhe_flush_routes(fnhe);
@@ -2145,10 +2150,14 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
fnhe = find_exception(nh, fl4->daddr);
if (fnhe) {
+ if (ref_leak_test)
+ pr_info("XXX pid: %d, found fnhe :%p\n", current->pid, fnhe);
prth = &fnhe->fnhe_rth_output;
rth = rcu_dereference(*prth);
if (rth && rth->dst.expires &&
` time_after(jiffies, rth->dst.expires)) {
+ if (ref_leak_test)
+ pr_info("eXX pid: %d, del fnhe :%p\n", current->pid, fnhe);
ip_del_fnhe(nh, fl4->daddr);
fnhe = NULL;
} else {
@@ -2204,6 +2213,14 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
#endif
}
+ if (fnhe && ref_leak_test) {
+ unsigned long time_out;
+
+ time_out = jiffies + ref_leak_test;
+ while (time_before(jiffies, time_out))
+ cpu_relax();
+ pr_info("XXX pid: %d, reuse fnhe :%p\n", current->pid, fnhe);
+ }
rt_set_nexthop(rth, fl4->daddr, res, fnhe, fi, type, 0);
if (lwtunnel_output_redirect(rth->dst.lwtstate))
rth->dst.output = lwtunnel_output;
@@ -2733,6 +2750,13 @@ static int ipv4_sysctl_rtcache_flush(struct ctl_table *__ctl, int write,
.proc_handler = proc_dointvec,
},
{
+ .procname = "ref_leak_test",
+ .data = &ref_leak_test,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
.procname = "max_size",
.data = &ip_rt_max_size,
.maxlen = sizeof(int),
ref_leak_test_begin.sh:
#!/bin/bash
# constructing a basic network with netns
# client <-->gateway <--> server
ip netns add svr
ip netns add gw
ip netns add cli
ip netns exec gw sysctl net.ipv4.ip_forward=1
ip link add svr-veth type veth peer name svrgw-veth
ip link add cli-veth type veth peer name cligw-veth
ip link set svr-veth netns svr
ip link set svrgw-veth netns gw
ip link set cligw-veth netns gw
ip link set cli-veth netns cli
ip netns exec svr ifconfig svr-veth 192.168.123.1
ip netns exec gw ifconfig svrgw-veth 192.168.123.254
ip netns exec gw ifconfig cligw-veth 10.0.123.254
ip netns exec cli ifconfig cli-veth 10.0.123.1
ip netns exec cli route add default gw 10.0.123.254
ip netns exec svr route add default gw 192.168.123.254
# constructing concurrently accessed scenes with nerperf
nohup ip netns exec svr netserver -L 192.168.123.1
nohup ip netns exec cli netperf -H 192.168.123.1 -l 300 &
nohup ip netns exec cli netperf -H 192.168.123.1 -l 300 &
nohup ip netns exec cli netperf -H 192.168.123.1 -l 300 &
nohup ip netns exec cli netperf -H 192.168.123.1 -l 300 &
# Add delay
echo 3000 > /proc/sys/net/ipv4/route/ref_leak_test
# making PMTU discovery exception routes
echo 1 > /proc/sys/net/ipv4/route/mtu_expires
for((i=1;i<=60;i++));
do
for j in 1400 1300 1100 1000
do
echo "set mtu to "$j;
ip netns exec svr ifconfig svr-veth mtu $j;
ip netns exec cli ifconfig cli-veth mtu $j;
ip netns exec gw ifconfig svrgw-veth mtu $j;
ip netns exec gw ifconfig cligw-veth mtu $j;
sleep 2;
done
done
ref_leak_test_end.sh:
#!/bin/bash
echo 0 > /proc/sys/net/ipv4/route/ref_leak_test
pkill netserver
pkill netperf
ip netns exec cli ifconfig cli-veth down
ip netns exec gw ifconfig svrgw-veth down
ip netns exec gw ifconfig cligw-veth down
ip netns exec svr ifconfig svr-veth down
ip netns del svr
ip netns del gw
ip netns del cli
Proses tes
ref_leak_test_begin.sh
,ref_leak_test_end.sh
,[root<strong i="13">@iZuf6h1kfgutxc3el68z2lZ</strong> test]# bash ref_leak_test_begin.sh
net.ipv4.ip_forward = 1
nohup: ignoring input and appending output to ‘nohup.out’
nohup: set mtu to 1400
appending output to ‘nohup.out’
nohup: appending output to ‘nohup.out’
nohup: appending output to ‘nohup.out’
nohup: appending output to ‘nohup.out’
set mtu to 1300
set mtu to 1100
set mtu to 1000
set mtu to 1400
set mtu to 1300
set mtu to 1100
^C
[root<strong i="14">@iZuf6h1kfgutxc3el68z2lZ</strong> test]# bash ref_leak_test_end.sh
[root<strong i="15">@iZuf6h1kfgutxc3el68z2lZ</strong> test]#
Message from syslogd<strong i="16">@iZuf6h1kfgutxc3el68z2lZ</strong> at Nov 4 20:29:43 ...
kernel:unregister_netdevice: waiting for cli-veth to become free. Usage count = 1
Setelah beberapa pengujian, torvalds/ linux@ee60ad2 memang dapat memperbaiki bug ini.
Adakah yang melihat bug ini dengan 4.19?
sama
Ya, di Debian! Apakah ada cara untuk menekannya?
Menemukan log Docker saya juga sedang di-spam. Kernel 5.4.0, Docker 19.03.8:
Mar 21 18:46:14 host.mysite.com dockerd[16544]: time="2020-03-21T18:46:14.127275161Z" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Mar 21 18:45:13 host.mysite.com dockerd[16544]: time="2020-03-21T18:45:13.642050333Z" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Mar 21 18:44:13 host.mysite.com dockerd[16544]: time="2020-03-21T18:44:13.161364216Z" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Mar 21 18:43:12 host.mysite.com dockerd[16544]: time="2020-03-21T18:43:12.714725302Z" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
Saya akhirnya menemukan cara untuk menekan pesan-pesan ini btw. Dari pertanyaan ini di StackExchange , saya mengomentari baris ini di /etc/rsyslog.conf
:
# Everybody gets emergency messages
#*.emerg :omusrmsg:*
Opsi yang sangat nuklir, tetapi setidaknya sekarang sistem saya dapat digunakan kembali!
@steelcowboy Anda dapat mengonfigurasi rsyslog untuk hanya membatalkan pesan-pesan yang mengganggu itu alih-alih semua keadaan darurat yang lebih diinginkan.
Saya menulis yang berikut ini ke /etc/rsyslog.d/40-unreigster-netdevice.conf
dan memulai kembali rsyslog systemctl restart rsyslog
.
# match frequent not relevant emergency messages generated by Docker when transfering large amounts of data through the network
:msg,contains,"unregister_netdevice: waiting for lo to become free. Usage count = 1" /dev/null
# discard matching messages
& stop
Ada berita di sini?
Komentar yang paling membantu
(mengulangi ini https://github.com/moby/moby/issues/5618#issuecomment-351942943 di sini lagi, karena GitHub menyembunyikan komentar lama)
Jika Anda tiba di sini
Masalah yang dibahas di sini adalah bug kernel dan belum sepenuhnya diperbaiki. Beberapa tambalan masuk ke kernel yang memperbaiki _beberapa_ kemunculan masalah ini, tetapi yang lain belum diselesaikan.
Ada sejumlah opsi yang dapat membantu untuk _beberapa_ situasi, tetapi tidak untuk semua (sekali lagi; kemungkinan besar kombinasi masalah yang memicu kesalahan yang sama)
Kesalahan "unregister_netdevice: waiting for lo to be free" itu sendiri bukan bug
Jika kernel crash _after_ itu bug (lihat di bawah)
Jangan tinggalkan komentar "Saya juga punya ini"
"Saya juga punya ini" tidak membantu menyelesaikan bug. hanya tinggalkan komentar jika Anda memiliki informasi yang dapat membantu menyelesaikan masalah (dalam hal ini; memberikan tambalan ke hulu kernel mungkin merupakan langkah terbaik).
Jika Anda ingin memberi tahu bahwa Anda juga mengalami masalah ini, gunakan tombol "jempol" di deskripsi atas:
Jika Anda ingin tetap mendapat informasi tentang pembaruan, gunakan _tombol berlangganan_.
Setiap komentar di sini mengirimkan email / pemberitahuan ke lebih dari 3000 orang Saya tidak ingin mengunci percakapan tentang masalah ini, karena belum terselesaikan, tetapi mungkin terpaksa jika Anda mengabaikannya.
Saya akan menghapus komentar yang tidak menambahkan informasi yang berguna untuk (sedikit) mempersingkat utas
Jika Anda ingin membantu menyelesaikan masalah ini
Terima kasih!