Moby: kernel crash setelah "unregister_netdevice: menunggu lo menjadi gratis. Jumlah penggunaan = 3"

Dibuat pada 6 Mei 2014  ·  518Komentar  ·  Sumber: moby/moby

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:
screen shot 2014-05-06 at 11 49 27

arekernel arenetworking

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:
screen shot 2017-03-09 at 16 12 17

Jika Anda ingin tetap mendapat informasi tentang pembaruan, gunakan _tombol berlangganan_.

screen shot 2017-03-09 at 16 11 03

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

  • Baca seluruh utas, termasuk komentar yang disembunyikan ; itu panjang, dan github menyembunyikan komentar (jadi Anda harus mengklik untuk membuatnya terlihat lagi). Ada banyak informasi yang sudah ada di utas ini yang mungkin bisa membantu Anda

screen shot 2018-07-25 at 15 18 14

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!

Semua 518 komentar

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
screenshot from 2015-10-22 11 53 41

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
image

=)

@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

  • Saya hanya dapat mereproduksi dengan ini ketika userland-proxy=false
  • Saya TIDAK dapat mereproduksi menggunakan VirtualBox (hanya EC2 sejauh ini) jadi mungkin ini terkait dengan hypervisor juga

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:

  • Debian "Jessie" (=Debian versi 8.5), pada baremetal (tanpa VM, tanpa cloud, tetapi perangkat keras biasa)
  • kernel 3.16.0-4-amd64
  • sudah mulai 4 kontainer LXC
  • tutup satu wadah LXC dengan "lxc-stop -n $containerName"
  • ketika perintah ini selesai, kernel atau antarmuka mungkin belum sepenuhnya 'dibersihkan', karena ketika saya segera setelah "lxc-stop" meluncurkan "lxc-stop" baru, maka saya memiliki masalah kernel

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 :

  • Tambahkan drop-in systemd untuk docker.service untuk mengonfigurasi antarmuka jembatan 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
  • Beri tahu kubelet untuk tidak menyetel jepit rambut di jembatan buruh pelabuhan:
    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 ?

  1. Perubahan buruh pelabuhan di posting saya memungkinkan tumpukan Kubernetes menginterogasi buruh pelabuhan dan memastikan platform sehat ketika masalah terjadi.
  2. perubahan hairpin-mode pada dasarnya memberi tahu K8 untuk menggunakan jembatan docker0 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

  • mencoba ipvlan(l2,l3)/macvlan(bridge): tidak satu pun dari ini bekerja pada aws, atau setidaknya, saya tidak memilikinya dan saya tidak dapat menemukan pengetahuan untuk menyelesaikan salah satu dari mereka untuk bekerja pada aws. dengan pekerjaan, maksud saya, memulai wadah yang terpasang pada jaringan dengan ipvlan atau macvlan, tidak dapat melakukan ping ke gateway / terhubung ke internet (ya, saya menguji ide dasar bekerja pada lingkungan non-aws). Ini sebenarnya tampaknya menyelesaikan masalah yang dihadapi, tetapi untuk kasus penggunaan kami, kami harus dapat terhubung ke internet -- untuk kasus penggunaan yang tidak, ini mungkin opsi yang layak dan terlihat cukup seksi vs. jembatan .
  • mencoba flag berikut yang diteruskan ke 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.

  • mencoba menonaktifkan ipv6 melalui pengaturan sysctl seperti yang didokumentasikan di sini dan memulai ulang systemd-networkd setelah menerapkan pengaturan sysctl, serta mencoba menonaktifkan ipv6 dari dhcpcd seperti yang didokumentasikan di sini dan ini tidak cukup untuk menonaktifkan ipv6 karena masih dihidupkan, bahkan jika tidak ada antarmuka menggunakannya.
  • seperti yang disarankan di sini, kami mencoba solusi ini, hanya menghapus satu wadah pada satu waktu, dan kami masih menemukan bug 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 :)

Saya memposting permintaan Redhat untuk menerapkan tambalan ini ke Fedora 24.

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

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:

  • 4.2 jauh lebih stabil daripada kernel yang lebih baru
  • 4.5.x dapat direproduksi secara sepele. Dari kernel yang lebih baru yang telah saya uji secara ekstensif (4.8.2 dan 4.8.6), masalahnya masih ada, meskipun waktu kemunculan pertama berkisar antara 60-an hingga 48 jam
  • Masalahnya tampaknya berkorelasi dengan lalu lintas jaringan dan rasio wadah dengan kapasitas sumber daya induk (virt cpu). Seperti yang orang lain hindari, ini bisa menjadi ikan haring merah jika ini memang kondisi balapan

Langkah selanjutnya:

  • Instrumen kernel dengan pernyataan printk yang sesuai untuk mencoba dan menemukan kasus di mana sumber daya yang dialokasikan tidak dibebaskan
  • Uji kernel 4.7.5 atau lebih baru dengan/tanpa patch yang disebutkan di atas untuk melihat apakah masalah terjadi
  • Tepat sebelum salah satu crash, saya melihat serangkaian kesalahan 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:

  1. ssh ke host buruh pelabuhan
  2. menjalankan wadah
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

  • Patch 751eb6b6 secara signifikan mengurangi terjadinya masalah ini, tetapi tidak sepenuhnya menghilangkannya.

pengandaian
@meatballhat menunjukkan bahwa server produksi mereka mengalami masalah saat menjalankan 4.8.7. Ini memberi kita dua kemungkinan:

  • Test case saya rusak (kemungkinan lebih besar)
  • 4.8.8 memperkenalkan perbaikan. Melihat 4.8.8 changelog , commit 5086cadf dan 6fff1319 keduanya menyebutkan masalah netdev yang telah diselesaikan. Tidak ada yang secara eksplisit menyebutkan masalah di sini, tetapi keduanya cukup dekat untuk dicurigai.

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:

CoreOS Stabil 1185.3.0

inti: 4.7.3

buruh pelabuhan: 1.11.2

CoreOS Beta 1235.1.0

inti: 4.8.6

buruh pelabuhan: 1.12.3

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.

  • OS: CentOS Linux rilis 7.3.1611
  • Kernel: 3.10.0-514.2.2.el7.x86_64
  • Docker versi 1.12.6, build 78d1802
  • Docker memulai dengan opsi: OPTIONS=" -H unix:///var/run/docker.sock --ip-forward=true --iptables=true --ip-masq=true --log-driver json-file --log-opt max-size=25m --log-opt max-file=2"
  • Rancher 1.2.2 menggunakan IPsec (Menyebutkan ini sejak https://bugzilla.kernel.org/show_bug.cgi?id=97811 dan bug lain menyebutkan IPsec)

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:

  1. Perbaiki masalah di mana masalah dengan alokasi alamat IPv6 gagal (misalnya; alamat duplikat) tetapi kami tidak merilis referensi ke perangkat sebelum keluar.
  2. Perbaiki masalah saat memindahkan namespace perangkat dengan benar akan memindahkan referensi ke perangkat ke namespace jaringan baru tetapi meninggalkan referensi menggantung di namespace lama. Docker sangat memanfaatkan ruang nama jaringan (sebagaimana dibuktikan oleh perbaikan kernel lain bahwa saya memiliki backport Red Hat ke 7.3 Z-Stream dan dijadwalkan untuk dimasukkan dalam 7.4 yang mencegah driver macvlan buruh pelabuhan bekerja pada perangkat bond atau tim)

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 orang mencatat "menunggu lo..."
  • beberapa telah mencatat "menunggu eth0"
  • beberapa telah mencatat "menunggu dokter hewan?????"
  • Pada pelacakan bug RedHat , ada pembicaraan tentang "menunggu ppp0"

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

kumpulkan.zip

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

Jika Anda tiba di sini

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)

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:
screen shot 2017-03-09 at 16 12 17

Jika Anda ingin tetap mendapat informasi tentang pembaruan, gunakan _tombol berlangganan_.

screen shot 2017-03-09 at 16 11 03

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:

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

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:

  • antarmuka lo diubah namanya menjadi lodebug untuk kemudahan memahami
  • jumlah referensi untuk dst_entry dimulai dengan 1
  • jumlah referensi untuk dst_entry (yang memegang referensi untuk lo) pada akhirnya adalah 19
  • ada 258041 total dst_hold() panggilan, dan 258023 total dst_release() panggilan
  • dalam 258041 dst_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()
  • dalam 258023 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.

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

  • apakah wadah Anda memiliki banyak aktivitas jaringan? Jika demikian, arah mana yang dominan?
  • Jenis mesin apa yang Anda jalankan yang ini (jumlah inti, apakah itu VM, dll)
  • Apakah Anda membuat banyak wadah secara bersamaan?
  • Apakah kontainer Anda keluar secara normal atau rusak?

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:

  1. start container (layanan web berbasis tornado internal - saya mencoba mengekstrak contoh minimal yang masih mengenai ini)
  2. buat permintaan ke layanan web yang berjalan dalam wadah
  3. ditunggu responnya
  4. membunuh wadah

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

  1. start container (layanan web berbasis tornado internal - saya mencoba mengekstrak contoh minimal yang masih mengenai ini)
  2. buat permintaan ke layanan web yang berjalan dalam wadah
  3. ditunggu responnya
  4. 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:

  • 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

[ @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:

  • 4.11.3-1-ARCH (Arch Linux) kernel: Saya membuat bug dengan docker-samba-loop dalam beberapa iterasi (<10). Saya tidak dapat mereproduksinya dengan docker-nfs-loop
  • 4.11.9-1-ARCH hasil yang sama ( versi )
  • 4.12.3-1-ARCH (pengujian repo) hasil yang sama
  • 4.11.11-coreos: hasil yang sama untuk 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.

Percobaan 1 (4.9.39 kernel)

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.

Percobaan 2 (kernel 4.11.12)

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!

Percobaan 3 (4.11.12 kernel)

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

Percobaan 4 (4.11.12 kernel)

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.

Eksperimen 5 (4.11.12/4.9.39 dengan mengaktifkan debugging tambahan di kernel)

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.

Menggali sedikit lebih dalam

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.

Ringkasan

  • Saya pikir kerusakan pada kernel 4.9.x tidak terkait tetapi tampaknya telah diperbaiki di 4.11.x. Ini membutuhkan sedikit lebih banyak triase.
  • Tidak seperti beberapa laporan sebelumnya, tidak ada tugas yang digantung yang dilaporkan, tetapi sulit untuk mengetahuinya karena hanya ada sedikit jejak tumpukan pada masalah ini.
  • Sesuatu diblokir untuk waktu yang sangat lama (2-4 menit). Ini kemungkinan terkait dengan status antrian kerja
  • Dump dari antrian kerja membutuhkan lebih banyak analisis, khususnya mengapa antrian kerja tetap dalam keadaan itu selama itu.
  • Pesan 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.
  • Sama sekali tidak jelas bagaimana/mengapa SMB memicu ini. Saya telah menulis sekitar 60 tes stres aneh untuk ruang nama jaringan dan beban kerja yang berbeda dan tidak dapat memicu masalah apa pun. Tes didasarkan pada 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):

  • Setelah wadah klien-smb ada menjalankan wadah baru tidak mungkin selama 4+ menit.
  • Saya tidak pernah mengalami crash kernel
  • Pesan 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:

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

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; ifconfigturun; sleep 10" sebelum ada dari container. Sepertinya tidak ada efeknya.

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)

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)

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:
screen shot 2017-03-09 at 16 12 17

Jika Anda ingin tetap mendapat informasi tentang pembaruan, gunakan _tombol berlangganan_.

screen shot 2017-03-09 at 16 11 03

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

  • Baca seluruh utas; itu panjang, dan github menyembunyikan komentar (jadi Anda harus mengklik untuk membuatnya terlihat lagi). Ada banyak informasi yang sudah ada di utas ini yang mungkin bisa membantu Anda
  • Baca komentar ini https://github.com/moby/moby/issues/5618#issuecomment -316297818 (dan komentar sekitar waktu itu) untuk informasi yang dapat membantu.

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

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.

  • bahkan 4.15.18 tidak membantu dengan bug ini
  • menonaktifkan ipv6 juga tidak membantu

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 membantu

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

  • kernel: 4.14.48
  • buruh pelabuhan: 18.03.1

masalah yang sama pada CentOS 7

  • kernel: 4.11.1-1.el7.elrepo.x86_64
  • buruh pelabuhan: 17.12.0-ce

@ 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
debian-docker
docker

RHEL, SWARM, 18.03.0-ce

  1. Menghubungkan ke node manajer melalui ssh
  2. 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

  3. 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)

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:
screen shot 2017-03-09 at 16 12 17

Jika Anda ingin tetap mendapat informasi tentang pembaruan, gunakan _tombol berlangganan_.

screen shot 2017-03-09 at 16 11 03

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

  • Baca seluruh utas, termasuk komentar yang disembunyikan ; itu panjang, dan github menyembunyikan komentar (jadi Anda harus mengklik untuk membuatnya terlihat lagi). Ada banyak informasi yang sudah ada di utas ini yang mungkin bisa membantu Anda

screen shot 2018-07-25 at 15 18 14

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?

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.

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

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.

  1. Men-debug patch kernel:
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index a0163c5..6b9e7ee 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -133,6 +133,8 @@

 static int ip_min_valid_pmtu __read_mostly = IPV4_MIN_MTU;

+static int ref_leak_test;
+
/*
  * Interface to generic destination cache.
  */
@@ -1599,6 +1601,9 @@ static void ip_del_fnhe(struct fib_nh *nh, __be32 daddr)
    fnhe = rcu_dereference_protected(*fnhe_p, lockdep_is_held(&fnhe_lock));
    while (fnhe) {
        if (fnhe->fnhe_daddr == daddr) {
+           if (ref_leak_test)
+               pr_info("XXX pid: %d, %s: fib_nh:%p, fnhe:%p, daddr:%x\n",
+                   current->pid,  __func__, nh, fnhe, daddr);
            rcu_assign_pointer(*fnhe_p, rcu_dereference_protected(
                fnhe->fnhe_next, lockdep_is_held(&fnhe_lock)));
            fnhe_flush_routes(fnhe);
@@ -2145,10 +2150,14 @@ static struct rtable *__mkroute_output(const struct fib_result *res,

        fnhe = find_exception(nh, fl4->daddr);
        if (fnhe) {
+           if (ref_leak_test)
+               pr_info("XXX pid: %d, found fnhe :%p\n", current->pid, fnhe);
            prth = &fnhe->fnhe_rth_output;
            rth = rcu_dereference(*prth);
            if (rth && rth->dst.expires &&
`               time_after(jiffies, rth->dst.expires)) {
+               if (ref_leak_test)
+                   pr_info("eXX pid: %d, del fnhe :%p\n", current->pid, fnhe);
                ip_del_fnhe(nh, fl4->daddr);
                fnhe = NULL;
            } else {
@@ -2204,6 +2213,14 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
 #endif
    }

+   if (fnhe && ref_leak_test) {
+       unsigned long  time_out;
+
+       time_out = jiffies + ref_leak_test;
+       while (time_before(jiffies, time_out))
+           cpu_relax();
+       pr_info("XXX pid: %d, reuse fnhe :%p\n", current->pid, fnhe);
+   }
    rt_set_nexthop(rth, fl4->daddr, res, fnhe, fi, type, 0);
    if (lwtunnel_output_redirect(rth->dst.lwtstate))
        rth->dst.output = lwtunnel_output;
@@ -2733,6 +2750,13 @@ static int ipv4_sysctl_rtcache_flush(struct ctl_table *__ctl, int write,
        .proc_handler   = proc_dointvec,
    },
    {
+       .procname   = "ref_leak_test",
+       .data       = &ref_leak_test,
+       .maxlen     = sizeof(int),
+       .mode       = 0644,
+       .proc_handler   = proc_dointvec,
+   },
+   {
        .procname   = "max_size",
        .data       = &ip_rt_max_size,
        .maxlen     = sizeof(int),
  1. Skrip mode pengguna:

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

  • pertama-tama muat kernel debug,
  • lalu jalankan ref_leak_test_begin.sh ,
  • tunggu beberapa detik, jalankan ref_leak_test_end.sh ,
  • dan akhirnya Anda dapat mengamati kesalahannya.
[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?

Apakah halaman ini membantu?
0 / 5 - 0 peringkat