Я наблюдаю очень похожую проблему для eth0. Ubuntu 12.04 тоже.

Мне нужно выключить и снова включить машину. От /var/log/kern.log :

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

Эй, это только начало происходить и со мной.

Версия докера:

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

Журнал ядра : http://pastebin.com/TubCy1tG

Детали системы :
Запуск Ubuntu 14.04 LTS с исправленным ядром (3.14.3-rt4). Еще предстоит увидеть это с ядром linux-3.13.0-27-generic по умолчанию. Что забавно, когда это происходит, все мои окна терминала замирают, что позволяет мне ввести до этого не более нескольких символов. Та же участь постигает любые новые, которые я открываю, - и в конечном итоге мне нужно перезапустить мой бедный ноутбук, как хороший доктор выше. Для справки, я запускаю fish shell в urxvt или xterm в xmonad. Не проверял, влияет ли это на простой bash.

Это может быть актуально:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065434#yui_3_10_3_1_1401948176063_2050

Копирование довольно большого количества данных по сети внутри контейнера
а затем выход из контейнера может вызвать недостающее уменьшение в per
счетчик ссылок на ЦП на сетевом устройстве.

Конечно, один из случаев, когда это случилось со мной, был сразу после того, как apt-get установил пакет с множеством зависимостей.

Обновление с Ubuntu 12.04.3 до 14.04 устранило это для меня без каких-либо других изменений.

Я испытываю это на RHEL7, 3.10.0-123.4.2.el7.x86_64

Я заметил, что то же самое происходит с моими виртуальными сетевыми интерфейсами VirtualBox, когда я запускаю 3.14-rt4. Это должно быть исправлено в ванильной версии 3.13 или чем-то в этом роде.

@egasimus То же самое - я вытащил сотни МБ данных перед тем, как убить контейнер, а затем получил эту ошибку.

Я обновился до ядра Debian 3.14, и проблема, похоже, исчезла. Похоже, проблема существовала в некоторых ядрах <3.5, была исправлена ​​в 3.5, регрессировала в 3.6 и была исправлена ​​в 3.12–3.14. https://bugzilla.redhat.com/show_bug.cgi?id=880394

@spiffytech У вас есть какие-нибудь идеи, где я могу сообщить об этом по поводу вкуса ядра в реальном времени? Я думаю, что они выпускают только RT-патч для каждой другой версии, и мне бы очень не хотелось, чтобы 3.16-rt вышел с этим все еще сломанным. : /

РЕДАКТИРОВАТЬ: отправил на

Я получаю это на Ubuntu 14.10 под управлением 3.18.1. Журнал ядра показывает

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

Я пришлю docker version/info только система перестанет зависать :)

Мы тоже наблюдаем эту проблему. Ubuntu 14.04, 3.13.0-37-общий

На сервере Ubuntu 14.04 моя команда обнаружила, что переход с 3.13.0-40-generic на 3.13.0-32-generic «решает» проблему. Учитывая наблюдение @sbward , это поместит регрессию после 3.13.0-32-generic и до (или включая) 3.13.0-37-generic.

Я добавлю, что в нашем случае мы иногда видим _негативный_ счетчик использования.

FWIW мы столкнулись с этой ошибкой, запустив lxc на надежном ядре (3.13.0-40-generic # 69-Ubuntu), сообщение появляется в dmesg, за которым следует эта трассировка стека:

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

Зайдите в это на Ubuntu 14.04 и Debian jessie с ядром 3.16.x.

Команда Docker:

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

Это похоже на довольно серьезную проблему ...

@jbalonso даже с 3.13.0-32-generic я получаю ошибку после нескольких успешных запусков: sob:

@MrMMorris не могли бы вы поделиться сценарием репродуктора, используя общедоступные изображения?

Каждый, кто видит эту ошибку в своей системе, запускает пакет ядра Linux в своем дистрибутиве, который слишком старый и не содержит исправлений для этой конкретной проблемы.

Если вы столкнулись с этой проблемой, убедитесь, что вы запустили apt-get update && apt-get dist-upgrade -y и перезагрузили систему. Если вы используете Digital Ocean, вам также необходимо выбрать версию ядра, которая была только что установлена ​​во время обновления, потому что они не используют последнюю версию ядра автоматически (см. Https://digitalocean.uservoice.com/forums/136585-digitalocean / предложения / 2814988-give-option-to-use-the-droplet-s-own-bootloader).

Пользователи CentOS / RHEL / Fedora / Scientific Linux должны обновлять свои системы с помощью yum update и перезагружаться после установки обновлений.

Сообщая об этой проблеме, убедитесь, что ваша система полностью пропатчена и обновлена ​​до последних стабильных обновлений (не устанавливаемых вручную экспериментальных / тестовых / альфа / бета / rc пакетов), предоставленных поставщиком вашего дистрибутива.

@unclejack

Я запустил apt-get update && apt-get dist-upgrade -y

Ubuntu 14.04 3.13.0-46-общий

По-прежнему появляется ошибка после одного docker run

Я могу создать AMI для воспроизведения при необходимости

@MrMMorris Спасибо, что подтвердили, что проблема с последним пакетом ядра в Ubuntu 14.04 все еще существует.

Дайте мне знать, чем я могу помочь! :улыбка:

@MrMMorris, если вы можете предоставить репродуктор, в Ubuntu обнаружена ошибка, и мы будем очень признательны: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152

@rsampaio, если у меня будет время сегодня, я обязательно вам его достану!

Эта проблема также появляется в версии 3.16 (.7) как в Debian 7, так и в Debian 8: https://github.com/docker/docker/issues/9605#issuecomment -85025729. Перезагрузка сервера - единственный способ исправить это на данный момент.

Увидеть эту проблему в RHEL 6.6 с ядром 2.6.32-504.8.1.el6.x86_64 при запуске некоторых контейнеров докеров (не всех контейнеров)
_ ядро: unregister_netdevice : ожидает освобождения lo. Количество использования = -1_

Опять же, перезагрузка сервера кажется единственным решением на данный момент.

Также это наблюдается в CoreOS (647.0.0) с ядром 3.19.3.

Перезагрузка - также единственное решение, которое я нашел.

Протестировал Debian jessie с ядром sid (4.0.2) - проблема осталась.

Кто-нибудь видел эту проблему с контейнерами, отличными от ubuntu?

да. Те, что в Debian.
19 июня 2015 г. 19:01 пользователь "popsikle" [email protected]
написал:

Кто-нибудь видел эту проблему с контейнерами, отличными от ubuntu?

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/docker/issues/5618#issuecomment -113556862.

Это проблема ядра, а не изображения. Замена изображения на другое не улучшит и не усугубит эту проблему.

Возникла проблема с Debian Jessie на BeagleBone Black с ядром 4.1.2-bone12

Испытывает после перехода с 4.1.2 на 4.2-rc2 (с использованием git build 1.8.0).
Удаление / var / lib / docker / * не решает проблемы.
Возврат к 4.1.2 решает проблему.

Кроме того, у VirtualBox есть такая же проблема, и есть патч для v5.0.0 (ретропортированный на v4), который предположительно что-то делает в части драйвера ядра ... стоит попытаться понять проблему.

Это исправление в VirtualBox: https://www.virtualbox.org/attachment/ticket/12264/diff_unregister_netdev
На самом деле они не изменяют ядро, а только модуль ядра.

Также есть эта проблема с 4.2-rc2:

unregister_netdevice: ожидание освобождения vethf1738d3. Количество использования = 1

Только что скомпилировал 4.2-RC3, похоже, снова работает

@ nazar-pc Спасибо за информацию. Просто попал с 4.1.3, сильно расстроился
@techniq то же самое, довольно плохая ошибка ядра. Интересно, должны ли мы сообщать об обратном переносе в дерево 4.1.

Linux docker13 3.19.0-22-generic # 22-Ubuntu SMP Вт 16 июня 17:15:15 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

Ядро из Ubuntu 15.04, та же проблема

Я видел это и с 4.2-rc3. Нет ни одного бага про утечку устройства :) Я могу воспроизвести на любом ядре> = 4.1 под highload.

У меня тоже была эта проблема. Ubuntu 3.13.0-57-generic, предоставляется через tutum. К сожалению, он заполняет kern.log и syslog и приводит к сбою машины. Это происходит на машине с базой данных (dockerized postgres), поэтому вся система падает ...

Присоединяясь к хору «я тоже», я вижу эту проблему на виртуальной машине облачного стека под управлением RancherOS (минимальная ОС) 0.3.3 при извлечении образов докеров из локального частного репозитория докеров. Это происходит каждые десять секунд, не уверен, что это значит что-то или нет.

Также есть эта проблема с 4.2-rc7

Есть новости по этому поводу, какое ядро ​​мы должны использовать? Это происходит даже с полностью обновленным ядром (3.19.0-26 в Ubuntu 14.04).

У нас тоже есть эта проблема. Это произошло после того, как мы настроили userland-proxy = false. Мы используем несколько сценариев монитора, которые порождают новый контейнер докеров для выполнения команды плагинов nagios каждые 1 минуту. В дереве процессов я вижу, что он застрял в команде docker rm и вижу много ошибок в файле kern.log

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

Это наша системная информация

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

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

Обновление: хотя https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152 сказал, что это уже исправлено 17 августа 2015 года. Поэтому я попробовал использовать ядро ​​v3.19.8-ckt6-vivid, созданное от 2 сентября 2015 г., или даже v4.2.1-unstable, созданное 21 сентября 2015 г., но проблема все еще не устранена.

Я только что снова столкнулся с проблемой, используя 3.19.0-28-generic , поэтому последнее ядро ​​Ubuntu небезопасно

Ага, похоже, что --userland-proxy=false сейчас не лучший вариант со старыми ядрами :(

Нет. Я пробовал --userland-proxy = false для всех версий ядра 3.19, 4.0, 4.2, но проблема все еще возникает.

Я использую прокси-сервер пользовательского уровня без iptables (--iptables = false) и вижу его как минимум раз в день. К сожалению, единственным обходным решением был сторожевой таймер, который полностью перезагружал сервер с помощью техники SysRq.

В моих системах работают некоторые контейнеры, которые являются тяжелыми средствами записи stdout / err, поскольку другие сообщали, что это может вызвать ошибку.

`` `` `
информация $ docker
Контейнеров: 15
Изображения: 148
Драйвер хранилища: aufs
Корневой каталог: / var / lib / docker / aufs
Резервная файловая система: extfs
Режиссеры: 178
Dirperm1 Поддерживается: true
Драйвер исполнения: native-0.2
Драйвер логирования: json-файл
Версия ядра: 3.19.0-26-generic
Операционная система: Ubuntu 14.04.3 LTS
Процессоры: 12
Общий объем памяти: 62,89 Гбайт
Имя: * *
ID: 2 ALJ: YTUH : QCNX: FPEO : YBG4: ZTL4: 2 EYK: AV7D : FN7C: IVNU: UWBL : YYZ5

версия $ docker
Версия клиента: 1.7.0
Версия клиентского API: 1.19
Версия Go (клиент): go1.4.2
Git commit (клиент): 0baf609
ОС / Arch (клиент): linux / amd64
Версия сервера: 1.7.0
Версия серверного API: 1.19
Версия Go (сервер): go1.4.2
Git commit (сервер): 0baf609
ОС / Arch (сервер): linux / amd64 ''
`` `` `

К сожалению, я в том же случае, сегодня производственный сервер 3 раза отказывался от этой ошибки, и единственный способ справиться с этим - использовать некоторые волшебные команды SysRq ..

удар

Я все еще вижу это в последней версии debian jessie с использованием ядра 4.2.0

Здесь та же проблема. Внезапно три моих сервера aws вышли из строя, а журналы кричали «unregister_netdevice: ожидание освобождения lo. Usage count = 1»

Ubuntu: 14.04
Версия ядра: 3.13.0-63-generic
Докер: 1.7.1

Системный журнал

Есть ли безопасная версия ядра?

Проблема также возникает с ядром 4.2 Ubuntu 15.10.

случилось в Coreos:

Изображения: 1174
Драйвер хранилища: оверлей
Резервная файловая система: extfs
Драйвер исполнения: native-0.2
Драйвер логирования: json-файл
Версия ядра: 4.1.7-coreos
Операционная система: CoreOS 766.4.0

Ошибка ядра, о которой @ killme2008 сообщил в прошлый раз

Вероятно, вам стоит попробовать установить этот патч поверх вашего ядра http://www.spinics.net/lists/netdev/msg351337.html
пакет: состояние гонки в packet_bind

или дождитесь бэкпорта в стабильном дереве; это произойдет рано или поздно.

: +1: Отличные новости!

Всем привет, хорошие новости!

С момента моего последнего комментария здесь (на момент написания, 17 дней назад) у меня больше не было этих ошибок. Мои серверы (около 30 из них) работали под управлением Ubuntu 14.04 с некоторыми устаревшими пакетами.

После полного обновления системы, включая docker-engine (с 1.7.1 до 1.8.3) + обновление ядра до последней возможной версии в репозитории ubuntu, мои серверы работают без каких-либо проблем.

:8 мяч:

Произошло также сегодня на трех экземплярах AWS:

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

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

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

У меня такая же проблема с Ubuntu 14.04, все пакеты обновлены и последнее ядро linux-generic-lts-vivid :

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

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

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

У меня было это с последним linux-image-generic (3.13.0-67-generic).

Имея те же проблемы здесь, на rancherOS.

Все еще происходит в Fedora 22 (обновлено) ....
Я могу избавиться от сообщений, если перезапущу докер

systemctl перезапустить докер
... сообщение появляется снова примерно 3-4 раза, а затем прекращается

Та же ошибка встречает меня с coreos:

версия coreos:

 ядро @ core-1-94 ~ $ cat / etc / os-release
 ИМЯ = CoreOS
 ID = coreos
 ВЕРСИЯ = 766.5.0
 VERSION_ID = 766.5.0
 BUILD_ID =
 PRETTY_NAME = "CoreOS 766.5.0"
 ANSI_COLOR = "1; 32"
 HOME_URL = "https://coreos.com/"
 BUG_REPORT_URL = "https://github.com/coreos/bugs/issues"

версия докера:

 core @ core-1-94 ~ $ версия докера
 Версия клиента: 1.7.1
 Версия клиентского API: 1.19
 Версия Go (клиент): go1.4.2
 Git commit (клиент): df2f73d-dirty
 ОС / Arch (клиент): linux / amd64
 Версия сервера: 1.7.1
 Версия серверного API: 1.19
 Версия Go (сервер): go1.4.2
 Git commit (сервер): df2f73d-dirty
 ОС / Arch (сервер): linux / amd64

 ядро @ core-1-94 ~ $ uname -a
 Linux core-1-94 4.1.7-coreos-r1 # 2 SMP Чт, 5 ноября 02:10:23 UTC 2015 x86_64 Intel (R) Xeon (R) CPU E5-2660 v3 @ 2,60 ГГц GenuineIntel GNU / Linux

системный журнал:

 07 декабря 16:26:54 core-1-94 ядро: unregister_netdevice: ожидание освобождения veth775ea53. Количество использования = 1
 07 декабря, 16:26:54 core-1-94 ядро: unregister_netdevice: ожидание освобождения lo. Количество использования = 2
 07 декабря, 16:26:55 core-1-94 sdnotify-proxy [1203]: I1207 08: 26: 55.930559 00001 vxlan.go: 340] Не игнорировать промах: 4e: 5c: 47: 2f: 9a: 85, 10.244 .97.10
 07 декабря 16:26:59 core-1-94 dockerd [1269]: time = "2015-12-07T16: 26: 59.448438648 + 08: 00" level = info msg = "GET / version"
 07 дек, 16:27:01 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 01.050588 00001 vxlan.go: 340] Игнорирование не промах: 5a: b1: f7: e9: 7d: d0, 10.244 .34,8
 07 декабря, 16:27:02 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 02.398020120 + 08: 00" level = info msg = "GET / version"
 07 декабря, 16:27:02 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 02.398316249 + 08: 00" level = info msg = "GET / version"
 07 декабря, 16:27:04 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 04.449317389 + 08: 00" level = info msg = "GET / version"
 07 декабря, 16:27:04 core-1-94 ядро: unregister_netdevice: ожидание освобождения veth775ea53. Количество использования = 1
 07 декабря, 16:27:04 core-1-94 ядро: unregister_netdevice: ожидает освобождения lo. Количество использования = 2
 07 дек. 16:27:06 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 06.106573 00001 vxlan.go: 340] Игнорирование не промах: a6: 38: ac: 79: 93: f5, 10.244 0,47,24
 07 декабря, 16:27:09 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 09.449944048 + 08: 00" level = info msg = "GET / version"
 07 дек, 16:27:11 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 11.162578 00001 vxlan.go: 340] Игнорирование не промах: 0e: f0: 6f: f4: 69: 57, 10.244 .71.24
 07 декабря, 16:27:12 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 12.502991197 + 08: 00" level = info msg = "GET / version"
 07 декабря, 16:27:12 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 12.503411160 + 08: 00" level = info msg = "GET / version"
 07 декабря, 16:27:14 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 14.450646841 + 08: 00" level = info msg = "GET / version"
 07 декабря, 16:27:14 core-1-94 ядро: unregister_netdevice: ожидание освобождения veth775ea53. Количество использования = 1
 07 декабря, 16:27:14 core-1-94 ядро: unregister_netdevice: ожидание освобождения lo. Количество использования = 2
 07 дек, 16:27:16 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 16.282556 00001 vxlan.go: 340] Игнорирование не промах: a6: 62: 77: 31: ef: 68, 10.244 .13,6
 07 декабря, 16:27:19 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 19.451486277 + 08: 00" level = info msg = "GET / version"
 07 дек, 16:27:21 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 21.402559 00001 vxlan.go: 340] Игнорирование не промах: 92: c4: 66: 52: cd: bb, 10.244 .24,7
 07 декабря, 16:27:22 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 22.575446889 + 08: 00" level = info msg = "GET / version"
 07 декабря, 16:27:22 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 22.575838302 + 08: 00" level = info msg = "GET / version"
 07 декабря, 16:27:24 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 24.452320364 + 08: 00" level = info msg = "GET / version"
 07 декабря, 16:27:24 core-1-94 ядро: unregister_netdevice: ожидание освобождения veth775ea53. Количество использования = 1
 07 декабря, 16:27:24 core-1-94 ядро: unregister_netdevice: ожидание освобождения lo. Количество использования = 2
 07 дек, 16:27:26 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 26.394569 00001 vxlan.go: 340] Игнорирование не промах: 6a: f7: bf: ec: 03: 50, 10.244 .87,8
 07 декабря, 16:27:29 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 29.453171649 + 08: 00" level = info msg = "GET / version"
 07 декабря, 16:27:29 core-1-94 systemd [1]: Запуск Generate / run / coreos / motd ...
 07 декабря 16:27:29 core-1-94 systemd [1]: Начато создание / run / coreos / motd.
 07 декабря, 16:27:32 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 32.671592437 + 08: 00" level = info msg = "GET / version"
 07 декабря, 16:27:32 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 32.671841436 + 08: 00" level = info msg = "GET / version"
 07 дек, 16:27:33 core-1-94 sdnotify-proxy [1203]: I1207 08: 27: 33.562534 00001 vxlan.go: 340] Игнорирование не промах: 22: b4: 62: d6: 25: b9, 10.244 0,68,8
 07 декабря, 16:27:34 core-1-94 dockerd [1269]: time = "2015-12-07T16: 27: 34.453953162 + 08: 00" level = info msg = "GET / version"
 07 декабря, 16:27:34 core-1-94 ядро: unregister_netdevice: ожидание освобождения veth775ea53. Количество использования = 1
 07 декабря, 16:27:35 core-1-94 ядро: unregister_netdevice: ожидание освобождения lo. Количество использования = 2

с днём рождения, кровавый вопрос =)
6 мая 2014

то же самое и здесь. Просто перезагружаюсь. Последняя версия докера. Ubuntu 14.04.

@samvignoli это было идентифицировано как проблема ядра, поэтому, к сожалению, это не то, что можно исправить в докере.

@thaJeztah У вас есть ссылка на трекер ошибок по проблеме с ядром?
Или, возможно, указатель на то, какое ядро ​​затронуто?

Стремится решить эту проблему в нашей среде.

@Rucknar, извините, я не знаю (возможно, в этом обсуждении есть один, я не прочитал все комментарии)

Linux atlas2 3.19.0-33-generic # 38 ~ 14.04.1-Ubuntu SMP Пт 6 ноября 18:17:28 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

@Rucknar, если немного прокрутить вверх - вы увидите ссылку на патч http://www.spinics.net/lists/netdev/msg351337.html. Теперь он находится в Linux master, я думаю, он перейдет в Linux 4.4, возможно, кто-то уже перенес его в предыдущие версии, но не уверен.

Всем спасибо, посмотрю, что требуется при обновлении.

FWIW Я перенес последний патч, упомянутый здесь, в ubuntu 3.19, и я также тестировал ядро ​​4.2, оба безуспешно. На данный момент проблема все еще присутствует даже в ветке 4.4-rc3 net-next.

@rsampaio Как вы это

@fxposter мы также не можем воспроизвести проблему за пределами производства, поэтому мне пришлось загрузить несколько экземпляров с исправленным ядром в производстве, это происходит так часто, что я могу узнать, затронуто ли ядро ​​в течение 24 часов производственной загрузки.

Иногда мы исправляем это с помощью очень необычного ресурса: мы перемещаем каталоги контейнеров из / var / lib / docker / aufs / mnt

С этим ... МОЖЕТ БЫТЬ, мы можем перезапустить сервисный докер и переместить каталоги назад.

Иначе ... только перезагрузка.

@rsampaio , ты сейчас говоришь о производстве героку? Как избежать этой проблемы, ведь весь ваш бизнес построен на контейнерах и т. д.?

@rsampaio вы используете --userland-proxy=false или просто большое количество созданных контейнеров? Я могу довольно легко воспроизвести это с помощью --userland-proxy=false и с некоторой нагрузкой без :)

@ LK4D4 Я считаю, что это просто большое количество созданных / уничтоженных контейнеров, особенно контейнеров, выполняющих много исходящего трафика, мы также используем LXC вместо докера, но ошибка точно такая же, как описанная здесь, я могу попытаться воспроизвести используя ваш метод, если его легко описать и / или он не связан с производственной нагрузкой, идея состоит в том, чтобы получить аварийный дамп и _могут_ найти больше подсказок о том, что именно вызывает эту ошибку.

@rsampaio Я могу воспроизвести при длительном использовании https://github.com/crosbymichael/docker-stress

Были ли какие-либо обновления / предложения по устранению этой проблемы?

@joshrendek это ошибка ядра. Похоже, что даже недавно выпущенное ядро ​​4.4 не исправляет это, так что где-то есть как минимум еще одно условие гонки :)

ошибка ядра

знак равно

@samvignoli, не могли бы вы оставить свои комментарии конструктивными? Не стесняйтесь открывать PR, если у вас есть способы решить эту проблему.

Сообщалось ли об этой ошибке в апстриме (список рассылки ядра)?

Конечно, было. первый комментарий также ссылается на эту ошибку: https://bugzilla.kernel.org/show_bug.cgi?id=81211

Открыт с 2014 года. Никаких комментариев от тех, кто работает над ним, кроме того, что это скорее всего приложение использует его неправильно.

Спасибо за ссылку, Джастин! Я буду троллить Линуса =)

с уважением. = *: сердце:

@samvignoli, пожалуйста, не делайте этого, это никому не поможет.
Может ли кто-нибудь воспроизвести это в небольшом образе виртуальной машины?
Может быть, я смогу запачкать руки с помощью gdb и большого количества kprintf.

ошибка все еще открыта.

ОС: CentOS 7.2
ядро: 4.4.2 elrepo kernel-ml
докер: 1.10.2
fs: overlayfs с xfs

бревно:

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

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

этот журнал отображается при запуске образа докера sameersbn / docker-gitlab:

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

Возможно, мне просто повезло, но после применения этих настроек sysctl вероятность этого значительно снизилась.

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

@joshrendek Какова мотивация этих настроек?

@kmike, это должно было исправить некоторые другие проблемы conntrack (заполнение таблиц ip), с которыми мы столкнулись - похоже, что-то сделано в отношении моей исходной проблемы, хотя в качестве побочного эффекта

Не могли бы вы показать до и после, чтобы мы могли увидеть, что на самом деле изменилось? Вы готовы выполнить двоичный поиск этих настроек и посмотреть, есть ли меньший набор?

Я использую CoreOS Stable (899.13.0) в виртуальной машине Compute Engine. Эта ошибка возникает каждый раз, когда я запускаю сервер со следующим флагом 0 (по умолчанию). Я тестировал несколько раз вперед и назад, и с отключенным IPv6 я могу запустить все контейнеры в узле без каких-либо ошибок:

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

Я использую контейнер gcloud для загрузки из GCR, поэтому, возможно, проблема в IPv6 + загрузка МБ изображений + быстрое закрытие контейнеров.

Версия Docker для справки:

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

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

Я также протестировал предыдущие флаги sysctl в этом выпуске; но у некоторых уже есть это значение, а остальные, похоже, не изменили ничего, связанного с этой ошибкой:

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

Я все еще вижу проблему, когда устанавливаю net.ipv6.conf.all.disable_ipv6 = 1.

Инструмент стресса Docker может очень легко вызвать проблему.
https://github.com/crosbymichael/docker-stress

Это двоичный файл, который я создал для инструмента, описанного выше.
https://storage.googleapis.com/donny/main
https://storage.googleapis.com/donny/stress.json

Как только мы видим журнал «unregister_netdevice: ожидание освобождения veth6c3b8b0. Счетчик использования», докер зависает. Я думаю, что это проблема ядра, вызванная докером. Это произойдет только тогда, когда docker userland-proxy выключен (--userland-proxy = false).

У меня такое случалось с включенным прокси-сервером пользователя и без него, поэтому я бы не сказал, только когда он выключен.

Возможно, это ухудшит ситуацию; Я знаю, что когда-то мы пытались сделать --userland-proxy=false значением по умолчанию, но вернули это, потому что были побочные эффекты https://github.com/docker/docker/issues/14856

Я тоже видел ошибку один раз со вчерашнего дня, явно отключение IPv6, это не исправление; но без флага я даже не могу запустить все контейнеры сервера, не уничтожив докер.

Запускаем это на CoreOS 1010.1.0 с kubernetes 1.2.2 и docker 1.10.3

Kubernetes добавил флаг в kubelet (на мобильных устройствах, поэтому не могу его найти) для
режим шпильки. Измените его на "неразборчивый мост" или другой допустимый
значение есть. Мы не видели этой ошибки с момента внесения этого изменения.

@bprashanh

Подтвердите или опровергните?
13 апреля 2016 г., 12:43, "Аарон Криккенбергер" [email protected]
написал:

Запускаем это на CoreOS 1010.1.0 с kubernetes 1.2.2 и докером
1.10.3

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/docker/issues/5618#issuecomment -209617342

Получение этого на AWS под управлением Linux 4.4.5-15.26.amzn1.x86_64 с версией Docker 1.9.1, сборка a34a1d5 / 1.9.1.

Ruby 2.3.0 с образом Alpine работает внутри контейнера, вызывая это

ядро: [58551.548114] unregister_netdevice: ожидание освобождения lo. Количество использования = 1

Что-нибудь исправить?

впервые увидел это на Linux 3.19.0-18-generic #18~14.04.1-Ubuntu SMP Wed May 20 09:38:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Пару перезагрузок исправили.

@MrMMorris Исправлено, так как вы уверены, что проблема исчезла навсегда, или в том, что вы еще не испытываете ее снова? Может быть состояние гонки ...

Совершенно ясно, что это гонка в ядре, потеря счетчика ссылок
где-то. Эту ошибку ДЕЙСТВИТЕЛЬНО сложно отследить, но, насколько мы можем судить,
все еще существует.

В пн, 2 мая 2016 г., в 22:52, Сьюн Келлер [email protected]
написал:

@MrMMorris https://github.com/MrMMorris Исправлено, поскольку вы уверены, что
проблема исчезла навсегда, или в том, что вы больше не сталкиваетесь с ней
только пока? Может быть состояние гонки ...

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/docker/issues/5618#issuecomment -216444133

Ага. Я попробовал CoreOS 1032.0.0 с ядром 4.5, но проблема все еще существует.

Я снова столкнулся с этим в CoreOS 1010.1.0 с ядром 4.5.0 вчера, это произошло после того, как несколько контейнеров были запущены и быстро уничтожены.

У меня такая ошибка.

Версия докера: 1.9.1
Версия ядра: 4.4.8-20.46.amzn1.x86_64
Операционная система: Amazon Linux AMI 2016.03

@sirlatrom не исправлено. Увидеть это снова 😭 Для решения потребовалось несколько перезагрузок.

В настоящее время используется версия 3.19.0-18-generic. Попробую обновить до последней

то же самое! : cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry :: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry: : cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry :: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry: : cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry :: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry: : cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry :: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:: cry:

@samvignoli ваши комментарии

извините, забыл функцию большого пальца вверх.

Воспроизводится в Fedora Server 23 - 4.2.5-300.fc23.x86_64. Невозможно перезапустить службу Docker - перезагрузите только узел.

Та же проблема с ядром Fedora 24: 4.5.2-302.fc24.x86_64. не вызывал зависаний, но спамил файл журнала.

@hapylestat Можете ли вы попробовать systemctl restart docker ? Это заставило меня все зависнуть.

Спасибо

Это происходит с моими машинами (CoreOS, EC2) довольно часто. Если это вообще поможет, вот все журналы, связанные с зависшим устройством veth в одном случае этой ошибки.

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

Похоже, это происходит, когда я удаляю сразу много контейнеров (в моем случае, когда я удаляю поды k8s массово).

Для тех, кто говорит, что перезагрузка исправила это - вы перезагружали или останавливали / запускали машины? На физических машинах мне пришлось использовать удаленный сброс питания, чтобы вернуть машину в рабочее состояние.

@joshrendek , мне пришлось использовать холодную перезагрузку iLO (т.е. физический цикл питания).

@joshrendek Теперь у меня есть сценарий, который reboot -f когда это происходит 😢.

Возможно, нашел проблему (или просто повезло). Я переместил каталог графа Docker с диска с разделами XFS на диск с разделами EXT4, и я не могу воспроизвести проблему (а также решить множество других ошибок XFS, которые я получал). Я помню, как @vbatts говорил, что XFS еще не поддерживается.

Я попытался спровоцировать, запустив build , run , stop , delete в бесконечном цикле на различных изображениях, создавая около 10 контейнеров в каждом цикле для последние несколько часов.

@joedborg, какой у вас

@thaJeztah Хорошее замечание, я должен был упомянуть об этом. Я использую драйвер Overlay с (сейчас) EXT4 с поддержкой FS.

Раньше я использовал devicemapper (потому что я использую Fedora Server), но у меня было много боли (как я думаю, многие делают), особенно с утечками, когда сопоставитель не возвращал пространство в пул после удаления контейнера.

Если это поможет, я использую Docker 1.11.1 и Kernel 4.2.5-300.fc23.x86_64.

@joedborg интересно, потому что в документации RHEL упоминается, что только EXT4 поддерживается в RHEL / CentOS 7.1 и только XFS в RHEL / CentOS 7.2. Тогда я ожидал, что XFS будет работать с более новыми версиями.

@thaJeztah ах, это странно. Я пытаюсь думать о других вещах, которые могли бы быть. Я перечитал сверху, и кажется, что некоторые люди используют ту же конфигурацию. Единственное отличие состоит в том, что диск XFS является шпинделем, а EXT4 - SSD. А пока я буду продолжать тесты на выдержку. Я также перешел на использование той же настройки, так что в любом случае у нас будет ответ в ближайшее время. Однако раньше это происходило почти на каждом stop , так что это определенно лучше.

@joedborg ну это действительно полезная информация

та же ошибка здесь, от ядра 4.2 до 4.5, та же версия докера.

Кстати, я одновременно запускаю несколько виртуальных машин на одном компьютере.

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

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

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

Я столкнулся с этой проблемой при использовании драйвера графа overlay с каталогом в ext4 FS. Так что я не думаю, что проблема в xfs 😢

@obeattie Да, похоже, люди тоже получают это от devicemapper . Прикоснитесь к дереву, у меня больше не было проблем с момента переключения. Как уже упоминалось, я также поменял местами физический диск. Это будет интересно!

Эта проблема никак не связана с файловой системой. Я видел эту проблему с zfs, overlayfs, devicemapper, btrfs и aufs. Также со свопом или без него. Это даже не ограничивается докером, я тоже столкнулся с той же ошибкой с lxc. Единственный обходной путь, который я сейчас вижу, - это не останавливать контейнер одновременно.

если это поможет, я получаю то же сообщение об ошибке на последнем экземпляре ec2, поддерживаемом AWS AMI. версия докера показывает-

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

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

Просто прыгаю на борт. Я наблюдаю такое же поведение на последнем экземпляре Amazon ec2. Через некоторое время контейнер просто опрокидывается и перестает отвечать.

информация $ docker
Контейнеры: 2
Фото: 31
Версия сервера: 1.9.1
Драйвер хранилища: devicemapper
Имя пула: docker-202: 1-263705-pool
Размер блока пула: 65,54 kB
Размер базового устройства: 107,4 ГБ
Резервная файловая система:
Файл данных: / dev / loop0
Файл метаданных: / dev / loop1
Используемое пространство данных: 1,199 ГБ
Всего дискового пространства: 107,4 ГБ
Доступное пространство для данных: 5,754 ГБ
Используемое пространство метаданных: 2,335 МБ
Всего метаданных: 2,147 ГБ
Доступное пространство для метаданных: 2,145 ГБ
Поддерживается синхронизация Udev: true
Включено отложенное удаление: false
Включено отложенное удаление: false
Количество отложенных удаленных устройств: 0
Файл цикла данных: / var / lib / docker / devicemapper / devicemapper / data
Файл цикла метаданных: / var / lib / docker / devicemapper / devicemapper / metadata
Версия библиотеки: 1.02.93-RHEL7 (2015-01-28)
Драйвер исполнения: native-0.2
Драйвер логирования: json-файл
Версия ядра: 4.4.10-22.54.amzn1.x86_64
Операционная система: Amazon Linux AMI 2016.03
Процессоры: 1
Общий объем памяти: 995,4 МБ
Имя: [отредактировано]
ID: OB7A: Q6RX: ZRMK: 4R5H : ZUQY: BBNK : BJNN: OWKS : FNU4: 7NI2: AKRT: 5SEP

версия $ docker
Клиент:
Версия: 1.9.1
Версия API: 1.21
Версия Go: go1.4.2
Git commit: a34a1d5 / 1.9.1
Построен:
ОС / Arch: Linux / amd64

Сервер:
Версия: 1.9.1
Версия API: 1.21
Версия Go: go1.4.2
Git commit: a34a1d5 / 1.9.1
Построен:
ОС / Arch: Linux / amd64

Как и в приведенных выше комментариях, запуск на EC2 также происходит через эластичный beanstalk с использованием 64bit Amazon Linux 2016.03 v2.1.0 running Docker 1.9.1

В настоящее время это несколько анекдотично, но я недавно попытался обновить ядро ​​с 4.2.0 до 4.5.5 примерно на 18 серверах в качестве тестов, и эта проблема стала значительно хуже (с нескольких дней до не более 4 часов между проблемами).

Это было в Debian 8

Точно такая же настройка, как у @ g0ddard

Хотите увидеть, как мы могли бы исправить эту ошибку.
Первое (что может сработать, а может и не сработать, это рискованно) - сохранить доступность API в тех случаях, когда это происходит: # 23178

Привет. Меня тоже укусил этот жучок ...

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

Я использую Kubernetes 1.2.4 на бета-версии CoreOS, Flannel и работаю в Azure. Есть ли способ помочь отладить эту проблему? Поток ошибок ядра кажется мертвым. Некоторые люди сообщают, что отключение IPv6 в ядре, использование --userland-proxy=true или использование aufs вместо справки по оверлейному хранилищу, в то время как другие этого не делают ... Это немного сбивает с толку.

Как и @ justin8, я заметил это после обновления моей системы Fedora 23 до ядра 4.5.5; проблема остается с ядром 4.5.6.

Мы столкнулись с этой ошибкой, когда контейнер достиг предела памяти. Не уверен, связано ли это или нет.

такая же проблема здесь

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

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

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

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

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

centos7.2
докер 1.10.3
та же проблема

У меня есть «один лайнер», который в конечном итоге воспроизведет эту проблему для меня на EC2 (m4.large) под управлением CoreOS 1068.3.0 с ядром 4.6.3 (совсем недавно). Для меня требуется около 300 итераций, кроме YMMV.

Linux ip-172-31-58-11.ec2.internal 4.6.3-coreos # 2 SMP Сб, 25 июня, 00:59:14 UTC, 2016 x86_64 Intel (R) Xeon (R) CPU E5-2676 v3 @ 2,40 ГГц GenuineIntel GNU / Linux
Бета-версия CoreOS (1068.3.0)
Докер версии 1.10.3, сборка 3cd164c

Несколько сотен итераций цикла в конечном итоге приведут к зависанию dockerd, и ядро ​​будет выдавать сообщения об ошибках, например

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

Цикл репродуктора

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

РЕДАКТИРОВАТЬ

• Я смог воспроизвести это только тогда, когда userland-proxy=false
• Я НЕ смог воспроизвести с помощью VirtualBox (пока только ec2), так что, возможно, это тоже связано с гипервизором

Сценарий @btalbot , приведенный выше, не воспроизводит для меня проблему в Fedora 23 после нескольких тысяч итераций.

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

Эта проблема возникает довольно часто в моем кластере Kubernetes, однако я не могу надежно воспроизвести ее с помощью stressers или одного лайнера @btalbot . Я пробовал запустить его на двух виртуальных машинах Azure с CoreOS 1068.3.0.

Первой виртуальной машиной была Standard_D1_v2 (3,5 ГБ ОЗУ, 1 ядро) - сценарий выполнял> 3000 итераций.
Вторая виртуальная машина была Standard_DS15_v2 (140 ГБ ОЗУ, 20 ядер) - сценарий выполнял> 7600 итераций.

Я обновил свой предыдущий комментарий (https://github.com/docker/docker/issues/5618#issuecomment-229545933), добавив, что я могу воспроизвести его только тогда, когда userland-proxy = false.

Он воспроизводится для меня на виртуальных машинах EC2 t2.micro (одноядерные), а также на m4.large (многоядерные) с использованием HVM. Я еще не видел, чтобы это происходило с использованием VirtualBox на моем ноутбуке, хотя независимо от настройки прокси-сервера пользователя.

Мы столкнулись с этой ошибкой при использовании Flannel с включенным hairpin-veth в кластере kubernetes (с использованием прокси iptables). Эта ошибка возникала только тогда, когда мы запускали слишком много контейнеров. Мы переключаемся на использование сети моста cbr0 и режим шпильки неразборчивого моста и больше никогда его не увидим.
На самом деле, эту ошибку легко воспроизвести, если вы используете шпильку-veth, просто начните эту работу со 100 контейнерами с кубернетами.

07.01.2016 08:01 manoj0077 писал:

@btalbot https://github.com/btalbot, поэтому с 1.12 мы можем перезапустить
dockerd, не влияя на запущенные контейнеры. Так что dockerd restart
помочь здесь в этом случае?

AFAICT, событие с 1.12, процессы контейнеров докеров все еще являются дочерними
демона докеров.

@serc, а как ты установил режим шпильки с неразборчивым мостом? Я не вижу никакой документации от докера по этому поводу, или, возможно, они используют другое имя

Есть ли официальное сообщение от Docker 🐳 о том, когда на это можно будет взглянуть? Это вторая по популярности открытая проблема ; очень серьезный (требует перезапуска хоста); воспроизводится; и я не вижу никакого реального прогресса в выявлении первопричины или ее устранении 😞.

Скорее всего, это проблема ядра, но билет на Bugzilla не работал в течение нескольких месяцев. Было бы полезно разместить там наши тестовые примеры?

@ justin8 Я думаю, это флаги Kubelet: --configure-cbr0 и --hairpin-mode

@sercand Я тоже использую Flannel. Есть ли недостатки в использовании --hairpin-mode=promiscuous-bridge ?

@obeattie Я согласен. :(

FTR Мне удалось воспроизвести проблему с помощью задания stresser @sercand на тестовом кластере Kubernetes, который я настроил, он также использует фланель и шпильку-veth.

@sercand Не могли бы вы подробно рассказать, как начать использовать promiscuous-bridge ? Я добавил флаг --configure-cbr0=true к кубелету узла, но он жалуется:
ConfigureCBR0 requested, but PodCIDR not set. Will not configure CBR0 right now . Я думал, что этот PodCIDR должен исходить от мастера? Спасибо.

РЕДАКТИРОВАТЬ: Кажется, мне нужно было добавить --allocate-node-cidrs=true --cluster-cidr=10.2.0.0/16 в конфигурацию диспетчера контроллеров, но поскольку у меня нет облачного провайдера (Azure), маршруты, вероятно, не будут работать.

@ justin8 Я этот документ .
@edevil из документации hairpin-mode означает «Это позволяет конечным точкам Сервиса возвращать

@sercand Согласно документу, если мы используем --allocate-node-cidrs=true в диспетчере контроллеров, мы должны использовать облачного провайдера для настройки маршрутов. Поскольку для Azure нет облачного провайдера Kubernetes, у вас не было проблем? Вы настраиваете маршруты вручную? Спасибо.

@edevil Я использую terraform для создания маршрутов. Вы можете найти его на этом репо . Я быстро создал эту конфигурацию и протестировал только один раз. Я надеюсь, что этого достаточно, чтобы изложить основную логику этого.

@morvans @btalbot у вас была возможность попробовать с 1.12 ...?

Я могу подтвердить, что отойдя от шпильки-вэта и используя мост cbr0, я больше не могу воспроизвести проблему.

На всякий случай: у кого-нибудь есть эта проблема на голом металле? Мы видели это при тестировании кластера ранчеров в нашей лаборатории VMWare, но никогда не видели при реальном развертывании на «голом железе».

Да, эта проблема возникает на голом железе для любого ядра> = 4.3. Вы видели это на множестве разных машин и аппаратных конфигураций. Единственным решением для нас было использовать ядро ​​4.2.

Это определенно все еще происходит с 4.2, но на порядок чаще с чем-то новым, я тестировал каждый основной выпуск, чтобы увидеть, лучше ли он, и пока ничего

Также происходит на CoreOS alpha 1097.0.0.

Ядро: 4.6.3
Докер: 1.11.2

У меня такая же проблема.

Докер: 1.11.2
Ядро: 4.4.8-boot2docker.

Хост: Docker-машина с драйвером VMWare Fusion на OS X.

Какие-нибудь предлагаемые обходные пути?

Было бы очень полезно, если бы те из вас, кто может надежно воспроизвести проблему в среде, где возможен аварийный дамп (иначе, чем EC2), могли бы на самом деле поделиться этим файлом аварийного дампа, дополнительную информацию о том, как включить kdump в надежном Ubuntu, можно найти здесь и это параметры сбоя, которые вам нужно включить, когда kdump готов сгенерировать аварийный дамп:

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

Аварийный дамп действительно может помочь разработчикам ядра узнать больше о том, что вызывает утечку ссылок, но имейте в виду, что аварийный дамп также включает дамп памяти вашего хоста и может содержать полезную информацию.

... дельная информация.

: o

Я столкнулся с той же проблемой.

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

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

Та же проблема:

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

Docker version: 1.10.3

Просто произошло прямо на экране терминала:

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

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

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

система

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

Та же проблема

Os: Amazon Linux AMI release 2016.03
Docker: 1.9.1

Здесь также:

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

Я вижу ту же проблему на EC2:

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

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

(на всех моих pty + beeper, когда это происходит)
"просто" Debian Jessie + backports:

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

Привет,

Когда я пытаюсь воспроизвести проблему в контролируемой среде, создав разрушающие новые изображения, я не могу ее воспроизвести.

Проблема возникла на одном из серверов, на которых работает докер 1.9.1.

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

Я одновременно обедаю контейнер 17753 в параллельном режиме и увеличиваю трафик в Интернет, без утечки какого-либо интерфейса veth *. Может ли кто-нибудь вставить инструкции, чтобы постоянно воспроизводить проблему?

@pegerto Должно быть довольно легко запустить, если у вас есть --userland-proxy=false и вы одновременно запускаете кучу контейнеров. Я делаю это с помощью https://github.com/crosbymichael/docker-stress

Спасибо @ cpuguy83

Настройка демона на --userland-proxy=false Я могу легко воспроизвести проблему, спасибо, мы видим, что эта проблема затрагивает демонов, которые не запускают эту конфигурацию.

Я вижу дамп ядра на хуке netfilter, введенный сегрегацией netns в> = 4.3, есть какие-либо мысли, почему проблема кажется хуже, когда маршрут происходит на 127/8?

Спасибо

Также вижу эту проблему. CoreOS 1068.8.0, Docker 1.10.3, ядро ​​4.6.3. Я вытащил некоторые системные журналы, если кому-то интересно.

Всего несколько ...
unregistered_netdevice: waiting for lo to become free. Usage count = 1
... на двух виртуальных машинах и на моем ноутбуке без операционной системы, все они работают под управлением Ubuntu 16.04 и новейших ядер (4.4.0-3 [456]).

В результате все зависает и требует жесткой перезагрузки.
Я не испытывал этого до прошлой недели, и я думаю, что одна из виртуальных машин была на 1.11.3, а остальные - на 1.12.0.

@RRAlex Это не относится к какой-либо версии
Если вы используете --userland-proxy=false в параметрах демона ... ИЛИ (насколько я понимаю) вы используете кубернеты, вы, вероятно, столкнетесь с этой проблемой.

Причина в том, что опция --userland-proxy=false включает закрепляющий NAT на интерфейсе моста ... это то, что kubernetes также устанавливает при настройке сети для своих контейнеров.

Увидеть это на узле BYO с помощью Docker Cloud (и агента Docker Cloud).

Сегодня видел это однажды (из примерно 25 попыток) на текущих AMI Amazon ECS, запустив ванильный debian: jessie с командой, которая apt-get updates, устанавливает pbzip2, а затем запускает его (простой многопоточный тест ЦП).

@edevil
Большинство из вас здесь описывают, что вы сталкиваетесь с этой ситуацией при использовании Docker для запуска / остановки контейнеров, но у меня была точно такая же ситуация без Docker в Debian:

• Debian "Jessie" (= Debian версии 8.5), на baremetal (без виртуальной машины, без облака, но с обычным оборудованием)
• ядро 3.16.0-4-amd64
• запустить 4 контейнера LXC
• закройте один контейнер LXC с помощью "lxc-stop -n $ containerName"
• когда эта команда завершается, ядро ​​или интерфейсы, вероятно, еще не полностью «очищены», потому что когда я сразу после предыдущего «lxc-stop» запускаю новый «lxc-stop», тогда у меня проблема с ядром

Невозможно восстановить кроме полной перезагрузки машины.

Поэтому, пожалуйста, в своих исследованиях по выявлению / решению этой проблемы не сосредотачивайтесь только на Docker. Это очевидная общая проблема с быстрой остановкой / запуском контейнеров, будь то через Docker или через простые команды «lxc».

Я бы подумал, что это проблема ядра linux.

Я столкнулся с этой проблемой, когда у меня было 3 chroot (фактически pbuilder), работающих с очень большой нагрузкой.
Мое оборудование - Loongson 3A (машина mips64el с ядром 3.16).

Когда я пытаюсь использовать ssh, я столкнулся с этой проблемой.

Так что проблема может быть не только в docker или lxc, но даже в chroot.

Докер версии 1.11.2.

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

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

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

Оголенный метал.

В последнее время у нас была проблема на голом железе (посвященном ovh) с ядром 4.6.x и докером 1.11.2.
Прочитав здесь комментарии и попробовав несколько обходных путей, мы понизили версию ядра до последней версии ветки 3.14 (3.14.74) и обновили докер до 1.12.0, чтобы избежать https://github.com/docker/libnetwork/issues/1189 и пока вроде все в порядке.

Надеюсь, это поможет.

Все, я думаю, вам больше не нужно публиковать сообщения о Docker или chroot, все дело в ядре Linux.
Так что, пожалуйста, может ли кто-нибудь встать, кто может каким-то образом отлаживать ядро ​​в тех частях, где оно отключает виртуальные сетевые интерфейсы для контейнеров? Возможно, возникают какие-то состояния гонки, когда предыдущая остановка контейнера еще не полностью отключила / не очистила его виртуальный интерфейс до того, как будет запрошена новая остановка контейнера.

@rdelangh Я не думаю, что эта проблема обязательно связана с ядром.

В Fedora 24 я не могу воспроизвести проблему с Docker 1.10.3 из репозиториев Fedora, только с Docker 1.12.1 из собственных репозиториев Docker.

Оба теста проводились с ядром 4.6.7-300.fc24.x86_64.

Эта проблема также наблюдается в CoreOS 1068.10.0, Docker 1.10.3, ядре 4.6.3.

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

Используя Kubernetes 1.3.4 на стабильной CoreOS 1068.9.0 на EC2, docker 1.10.3, я вижу эту проблему.

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

Эта проблема также наблюдается в Ubuntu 16.04, Docker 1.12.1, kernel 4.4.0-34-generic
waiting for lo to become free. Usage count = 1

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

...

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

Для тех, кто использует Kubernetes <= 1.3.4, вы можете воспользоваться этой проблемой: https://github.com/kubernetes/kubernetes/issues/30899, чтобы воспроизвести эту проблему. Я запустил небольшой кластер с 1 контроллером (m4.large) и 2 рабочими (m4.large) на CoreOS 1068.10.

Оттуда вы можете создать 2 ReplicationController, я назвал их hello и hello1 на основе этого: http://pastebin.com/mAtPTrXH . Обязательно измените имена и метки, чтобы они были другими.

Затем создайте 2 развертывания с такими же именами / метками, как указано выше, на основе этого: http://pastebin.com/SAnwLnCw .

_Как только вы создадите развертывание, вы получите сумасшедшее количество спам-контейнеров_.

Если вы оставите его включенным на некоторое время (несколько минут), вы увидите множество вещей, пытающихся завершить / создать. Вы можете удалить развертывания и подождать, пока ситуация стабилизируется. Вы должны увидеть несколько примеров Terminating и ContainerCreating. Если вы подключаетесь к узлам по ssh, проверьте dmesg и docker ps чтобы увидеть, очевидны ли вышеуказанные симптомы.

В моем случае мне потребовалось около 5 минут, чтобы отпустить этот урод, прежде чем я увидел проблему. Я планирую внести изменения, которые играли @sercand и @edevil , и посмотреть, сработает ли это для меня в данном случае.

@edevil Посмотрев на ваш связанный коммит, правильно ли я отключил / удалил Flannel в своей среде в пользу моста cbro созданного Kubernetes для решения этой проблемы?

Я вижу со своей стороны, что вы не сможете использовать их в тандеме, потому что фланель хочет использовать docker0 а ваша внутренняя сеть будет работать на cbr0 правильно?

@ alph486 , правильно, фланель использовать перестал. Я использую мост и настраиваю маршруты для сети подов.

@ alph486 flannel не хочет использовать docker0. Это просто мост по умолчанию для докера, который вы можете переопределить с помощью опции --bridge=cbr0 docker.
В CoreOS вам придется переопределить модуль docker systemd.

Флаг Kubelet --experimental-flannel-overlay может считывать конфигурацию фланели и настраивать мост докеров cbr0 с помощью фланелевого CIDR.

Это также включит режим promiscuous вместо veth-hairpin который, кажется, является проблемой.

Спасибо @dadux за вклад. Если K8s получит интерфейс cbr0 , который уже был загружен переопределенным модулем, может иметь дело с этим решением; я попытаюсь.

Согласно документации, promiscuous-bridge является значением по умолчанию для --hairpin-mode в kubelet v1.3.4 +. Я все еще вижу проблему с этим, поэтому я не совсем уверен, что это все решение.

Мне не удалось воспроизвести проблему снова после использования сетевого плагина kubenet (который заменяет --configure-cbr0 ). Я как бы избегаю варианта flannel-overlay из-за неопределенности его будущего (похоже, он привязан к --configure-cbr0 ).

Если ваш демон docker использует мост docker0 , установка --hairpin-mode=promiscuous-bridge будет иметь никакого эффекта, поскольку kubelet попытается настроить несуществующий мост cbr0 .

Для CoreOS мой обходной путь для отражения поведения Kubernetes, но по-прежнему с использованием фланели:

• Добавьте компонент systemd для docker.service, чтобы настроить интерфейс моста docker0 на неразборчивый режим. (Наверняка есть более элегантное желание сделать это?):

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

• Скажите кубелету, чтобы он не вставлял шпильку в докер-бридж:
  kubelet --hairpin-mode=none

Вы можете проверить, включена ли шпилька для ваших интерфейсов с помощью
brctl showstp docker0
или
for f in /sys/devices/virtual/net/*/brport/hairpin_mode; do cat $f; done

Я думаю, что мой коллега исправил это недавно http://www.spinics.net/lists/netdev/msg393441.html , мы столкнулись с этой проблемой в нашей среде, а затем мы обнаружили проблему, с этим исправлением мы никогда не сталкиваемся с этой проблемой. более. Любой, кто столкнулся с этой проблемой, может попробовать этот патч и посмотреть, повторится ли это снова. И из нашего анализа, это относится к ipv6, поэтому вы также можете попробовать отключить ipv6 докера с помощью --ipv6=false при запуске демона докера.

@ coolljt0725 Возможно, я ошибаюсь, но ipv6 по умолчанию отключен в докере, и я только что воспроизвел проблему с помощью docker-stress с параметром «--ipv6 = false» (который в любом случае используется по умолчанию). Еще не пробовал свой патч.

@dadux Спасибо за вашу помощь. В Kubernetes 1.3.4 CoreOS 1068 Stable, Docker 10.3, Flannel в качестве сетевого уровня я решил проблему, внеся следующие изменения в мои модули CoreOS:

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

В kubelet.service добавлено следующее:

        --hairpin-mode=none

Как эти изменения влияют на Docker / Kubernetes в отношении того, как операционная система обрабатывает интерфейсы для контейнеров?
Я должен подчеркнуть, что это проблема с неправильным поведением O / S, а не с Docker или Kubernetes, потому что мы (и некоторые другие люди в этом потоке) вообще не запускаем Docker или Kubernetes, но все равно сталкиваемся с точно такими же ситуациями при остановке LXC. контейнеры довольно быстро один за другим.

@rdelangh Вы правы. Однако эта проблема была создана в проекте Docker для отслеживания поведения в отношении Docker. В этом потоке упоминаются и другие проблемы, отслеживающие это как проблему ОС, проблему K8s и проблему CoreOS. Если вы обнаружили проблему в LXC или в чем-то еще, настоятельно рекомендую вам начать там обсуждение и сделать ссылку здесь, чтобы повысить осведомленность о проблеме.

Когда те, кто использует Docker google для этой ошибки, скорее всего, попадут сюда. Поэтому имеет смысл публиковать здесь обходные пути для этой проблемы, чтобы люди могли двигаться дальше, пока не будут устранены основные проблемы.

Как эти изменения влияют на Docker / Kubernetes в отношении того, как операционная система обрабатывает интерфейсы для контейнеров?

1. Изменение докера в моем сообщении позволяет стеку Kubernetes опрашивать докер и проверять работоспособность платформы при возникновении проблемы.
2. изменение hairpin-mode существу указывает K8s использовать мост docker0 как есть, и, следовательно, не будет пытаться использовать сеть "ядра" и "шпильку", где проблема начинается в Docker. путь исполнения.

Это обходной путь для этой проблемы с использованием K8s и Docker.

Патч коллег coolljt0725 поставлен в очередь на выпуск стабильной версии, так что, надеюсь, он скоро будет перенесен в дистрибутивы. (Сообщение Дэвида Миллера: http://www.spinics.net/lists/netdev/msg393688.html)

Не уверены, где находится этот коммит, и следует ли нам отправить его в Ubuntu, RH и т. Д., Чтобы помочь им отслеживать и переносить его?

Я думаю, что в какой-то момент здесь появится:
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/ipv6/addrconf.c

РЕДАКТИРОВАТЬ: похоже, здесь присутствует: https://github.com/torvalds/linux/blob/master/net/ipv6/addrconf.c

Спасибо coolljt0725 и компании (и всем участникам этой темы). Поскольку многие люди не смогут обновить ядро ​​с помощью патча ipv6 в течение некоторого времени, (все, в настоящее время) мне удалось устранить эту ошибку, попробовав многие предложения из этого потока. Я хочу сделать полный пост, чтобы следить за вещами, которые работали и не работали, чтобы никто больше не видел проблемы, которые я видел.

TL; DR отключить ipv6 в параметрах загрузки linux, перезагрузиться. на coreos это означает, что /usr/share/oem/grub.cfg имеет содержимое: set linux_append="ipv6.disable=1" а затем перезагрузка. цель предложение более общее , что должно работать на CentOS / Ubuntu / Debian / $ дистрибутивов Linux можно найти здесь

• попробовал ipvlan (l2, l3) / macvlan (bridge): ни один из них не работает на aws, или, по крайней мере, у меня нет и я не мог найти знания, чтобы заставить кого-либо из них работать на aws. по работе, я имею в виду, что запуск контейнера, подключенного к сети с помощью ipvlan или macvlan, не смог проверить связь со шлюзом / подключиться к Интернету (да, я тестировал основную идею, работая в среде, отличной от aws). На самом деле это, похоже, решило проблему, но для нашего случая использования нам нужно иметь возможность подключиться к Интернету - для случаев использования, которые этого не делают, это может быть жизнеспособным вариантом и выглядит довольно привлекательно по сравнению с мостом. .
• попробовал следующие флаги, переданные в dockerd отдельности и с определенными комбинациями (поскольку ни один из них, похоже, не работал, я не был слишком научен пробовать любые комбинации):

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

интересно, что --ipv6=false самом деле ничего не делает - это было довольно запутанным, контейнеры по-прежнему получали адреса inet6 с этим флагом.

--userland-proxy=false устанавливает режим шпильки и не ожидал, что он действительно сработает. в связи с этим у меня была некоторая надежда, но это тоже не решило проблему (установка docker0 в режим promisc). Существует упоминание о затруднительном до --userland-proxy=false здесь , и это может быть выше по потоку в ближайшее время и стоит еще один выстрел, было бы неплохо , чтобы отключить это независимо от ошибки отметил в этом вопросе для исполнения , но , к сожалению , у него есть еще один ошибка на данный момент.

• попытался отключить ipv6 с помощью настроек sysctl, как описано здесь, и перезапустить systemd-networkd после применения настроек sysctl, а также попытаться отключить ipv6 из dhcpcd, как описано здесь, и этого было недостаточно для отключения ipv6, поскольку он все еще включен, даже если интерфейсы отсутствуют используй это.
• как было предложено здесь, мы попробовали это решение, удаляя только один контейнер за раз, и мы все еще встречались с этой ошибкой.

слишком долго; прочитал: отключите ipv6 в настройках grub. перезагружать. выгода.

Столкнулся с этой проблемой в CentOS 7.2 (3.10.0-327.28.3.el7.x86_64) и Docker 1.12.1 (без k8s). Проблема возникает при увеличении сетевого трафика.
Загрузка ядра с отключенным ipv6 (согласно предыдущему совету) не помогла.
Но перевод интерфейса docker0 в режим promisc устранил это. Использовал systemd drop-in от @dadux (спасибо!) - похоже, сейчас работает хорошо.

@rdallman Деактивация ipv6 через grub не мешает мне unregister_netdevice в ubuntu 16.06 (ядро 4.4.0-36-generic) или 14.04 (ядро 3.13.0-95-generic). Независимо от настройки --userland-proxy (true или false).

Ооооо, круто, что патч поставили в очередь на стабильную.
ping @aboch, чтобы --ipv6=false ничего не делает.

@trifle, извините :( спасибо за публикацию информации, у нас еще не

@RRAlex Знаете ли вы, резервного копирования ? У нас есть большое производственное развертывание Docker в кластере Ubuntu, на котором обнаружена ошибка.

Список рассылки команды разработчиков ядра Ubuntu:
https://lists.ubuntu.com/archives/kernel-team/2016-September/thread.html

Патч для стабильного ядра:
https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d

Журнал фиксации ядра Ubuntu:
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/?h=master-next
(Патча пока нет)

@leonsp Я попытался связаться с ними по тому, что кажется связанным с этим вопросом:
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1403152

Если вы посмотрите на последний (# 79) ответ, кто-то построил ядро ​​для Xenial с этим патчем:
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1403152

Не уверен, когда это происходит в основном дереве ядра Ubuntu, и каково отношение этого человека к Ubuntu, и поможет ли это ...

Я также не могу найти упомянутые коммиты из этого потока в журнале коммитов ядра Ubuntu.

@RRAlex Упомянутые коммиты находятся в ветке ddstreet ~ ddstreet / + git / linux: lp1403152-xenial , вот журнал: https://code.launchpad.net/~ddstreet/+git/linux/+ref/lp1403152-xenial
Итак, любой, у кого есть эта проблема в Ubuntu 16.04, может попробовать. https://launchpad.net/~ddstreet/+archive/ubuntu/lp1403152

Возможно, @sforshee знает (для ядра Ubuntu)

Наконец-то мне удалось протестировать решение "ipv6.disable = 1". В дополнение к этому - я обновил ядро ​​до 4.7.2 на моем debian 8.
После обновления ядра и включения «ipv6.disable = 1» в параметрах ядра мне удалось отловить проблему «ожидание lo» на реальной рабочей нагрузке даже без флага «--userland-proxy = false» для демона docker. Хорошая новость заключается в том, что после указания «--userland-proxy = false» и попытки воспроизвести проблему с помощью «docker-stress» я больше не могу этого делать. Но я почти уверен, что он возникнет снова, независимо от значения "--userland-proxy".
Итак, из того, что я вижу - ipv6 определенно вовлечен в эту проблему, потому что теперь docker-stress больше не может выявить проблему. Плохая новость в том, что проблема все еще существует (то есть исправлена ​​только частично).

Позже скомпилируем последнюю версию 4.8rc7, чтобы протестировать больше.

@ twang2218 @ coolljt0725

Хммм .. так что я просто попробовал ядро ​​Ubuntu xenial 4.4.0-36 с патчем, перенесенным из

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

К сожалению, это не решает проблему для меня. Обратите внимание, что я также использую «ipv6.disable = 1». Смотрим ли мы на несколько не связанных между собой причин с одним и тем же результатом? Многие комментарии в этой ветке, кажется, предполагают это.

Я не слишком много знаю об этом, но я знаю, что у нас раньше были подобные ошибки. Насколько я понимаю, счетчики ссылок на любое сетевое устройство в конечном итоге передаются в lo при очистке сетевого пространства имен, поэтому «ожидание, пока lo станет свободным» означает, что существует утечка счетчика ссылок для некоторого сетевого устройства, но не обязательно для lo. напрямую. Это заставляет их искать, потому что к тому времени, когда вы узнаете, что произошла утечка, вы не знаете, с каким устройством она была связана.

Я не прочитал все комментарии, но если кто-то может дать мне надежный репродуктор на Ubuntu, я посмотрю на него и посмотрю, смогу ли я что-нибудь понять.

@sforshee не всегда легко воспроизвести, но был создан патч (который, по крайней мере, исправляет некоторые из описанных здесь случаев); http://www.spinics.net/lists/netdev/msg393441.html. Это было принято вверх по течению https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d

@thaJeztah а, я вижу вопрос, на который вы меня сейчас задавали.

Таким образом, патч находится в очереди стабильной работы апстрима 4.4, для 16.04 он, вероятно, будет включен не в следующий SRU ядра (который уже выполняется), а в следующий, примерно через 5-6 недель. Если он понадобится и в 14.04, дайте мне знать, чтобы его можно было перенести.

@sforshee в основном раньше (до этого патча), который можно было воспроизвести, включив ipv6 в ядре (обычно включен по умолчанию), добавив "--userland-proxy = false" к флагам демона докеров и затем запустив docker-stress -c 100 , для пример (docker-stress отсюда: https://github.com/crosbymichael/docker-stress)

@fxposter спасибо. Если для этого есть исправление, все, о чем мне действительно нужно беспокоиться, - это добавить это исправление в ядро ​​Ubuntu. Я также могу помочь разобраться с другими утечками, которые не исправлены этим патчем.

У меня тоже есть эта проблема. Я запускаю докер внутри окна rancherOS от AWS. На самом деле, это происходит случайным образом после настройки кластера ранчо (3 хоста) и запуска в нем небольшого приложения.

то же самое ... Fedora 24, случается случайно, может быть хорошо в течение недели, чем я получаю каждые 10 часов
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Опыт работы с CentOS 7 с ядром 3.10.0-327.36.1.el7 и докером 1.12.1

Переход на ядро ​​3.10.0-327.18.2.el7, оставаясь на докере 1.12.1, похоже, стабилизировал систему.

Я тоже это вижу:
Докер версии 1.11.2
Ubuntu 16.04.1 4.4.0-38-общий

ipv6 отключен (grub)

Просто возникла эта проблема без --userland-proxy=false (sic!) На сервере с ядром 4.8.0-rc7, которое включает патч ipv6 (sic !!). Так что, возможно, это решит некоторые проблемы, но определенно не все.

Кто-нибудь знает, как это вообще можно отладить?

Мы обнаружили, что это происходит только при нашей установке, когда у нас (почти) заканчивается свободная память.

@fxposter Было бы полезно найти минимальный вариант воспроизведения, что довольно сложно: / Тогда мы могли бы использовать ftrace, по крайней мере, для поиска путей кода.

Происходит на CoreOS 1081.5.0 (4.6.3-coreos)

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

@ LK4D4, к сожалению, уже невозможно воспроизвести через docker-stress (по крайней мере, я не смог). Я попытаюсь имитировать нашу предыдущую настройку с помощью веб-наборов (которые вызывали эту проблему гораздо чаще, чем хотелось бы).

@fxposter Этот патч исправляет только некоторые проблемы (но в нашей среде мы больше никогда не сталкиваемся с этим с этим патчем), но не все, я позволю моему коллеге продолжить изучение этой проблемы. Если у вас есть способ воспроизвести это, дайте мне знать, спасибо :)

Исправление находится в стабильной версии 4.4.22 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.22.

Я отправил Redhat запрос на применение этого патча к Fedora 24.

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

4.4.0-42 еще точно битая ...
Я упомянул об этом здесь для Ubuntu, но, возможно, у кого-то есть идея получше:
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1403152

Я также вижу это, Docker версии 1.11.2, сборка b9f10c9 / 1.11.2, 64-битный Amazon Linux 2016.03 v2.1.6.

все еще случилось. docker 1.12.2, ядро ​​armbian linux 4.8.4, ipv6.disable = 1 в bootargs

как исправить ошибку я встречаюсь с ней каждый день

@woshihaoren Не используйте --userland-proxy=false

Для уточнения - мы тоже столкнулись с отключенным userland-proxy

Получение этого в Amazon Linux AMI 2016.9:

$ uname -a

Linux 4.4.23-31.54.amzn1.x86_64 #1 SMP

Версия докера:

Клиент:
Версия: 1.11.2
Версия API: 1.23
Версия Go: go1.5.3
Git commit: b9f10c9 / 1.11.2
Построен:
ОС / Arch: Linux / amd64

Сервер:
Версия: 1.11.2
Версия API: 1.23
Версия Go: go1.5.3
Git commit: b9f10c9 / 1.11.2
Построен:
ОС / Arch: Linux / amd64
`` ''

ядро centos7 4.4.30 снова ~~~~

CoreOS 1185.3.0, 4.7.3-coreos-r2, Докер 1.11.2
Воспроизводится при запуске 10..20 контейнеров debian: jessie с

Стабильная версия CoreOS в настоящее время все еще популярна. Исправление для серии 4.7 находится в 4.7.5: https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.7.5

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

    ipv6: addrconf: fix dev refcont leak when DAD failed

TL; DR - В этом посте нет решений, но я перечисляю то, за чем гнался до сих пор, и свои текущие рабочие теории. Я надеюсь, что другие люди, которые также ищут это, могут найти здесь некоторую информацию, которая будет полезна, когда мы опустим эту штуку.

@koendc Спасибо, что разместили патч, представленный в 4.7.5. Я снова перенес 4e1b3aa898ea93ec10e48c06f0e511de37c35b2d (вверх по течению) 751eb6b6042a596b0080967c1a529a9fe98dac1d патч к моему 4.5.5 установки [1] и был в состоянии легко воспроизвести проблему unregister_netdevice. Возможно, что другие изменения в ядре 4.7.x работают вместе с предоставленным патчем для решения этой проблемы, но я еще не подтвердил это, так что пока не стоит терять всякую надежду. Я тестирую 4.5.5, потому что у меня есть воспроизводимый тестовый пример, вызывающий проблему, описанную в [2].

Другие вещи, которые я подтвердил на основании тестирования:

• 4.2 намного стабильнее, чем любое более позднее ядро
• 4.5.x воспроизводимо тривиально. Из новых ядер, которые я тщательно тестировал (4.8.2 и 4.8.6), проблема все еще существует, хотя время до первого появления колебалось от 60 до 48 часов.
• Проблема, похоже, коррелирует как с сетевым трафиком, так и с отношением контейнеров к емкости родительского ресурса (virt cpu). Поскольку другие ускользнули, это может быть отвлекающим маневром, если это действительно состояние гонки.

Следующие шаги:

• Настройте ядро ​​соответствующими операторами printk, чтобы попытаться найти случай, когда выделенные ресурсы не освобождаются.
• Протестируйте ядро ​​4.7.5 или новее с / без вышеупомянутого патча, чтобы увидеть, возникает ли проблема.
• Незадолго до одного из сбоев я увидел очень интересный набор ошибок IPv6: eth0: IPv6 duplicate address <blah> detected . Возможно, это еще один отвлекающий маневр, но я хочу попробовать отключить ipv6, чтобы увидеть, есть ли корреляция

[1] Моя полная установка - это GCE virt с слегка настроенным ядром Debian, основанным на 4.5.5 . Docker version 1.8.3, build f4bf5c7 работает поверх этого
[2] Информация о тестовом примере: у меня есть 20 параллельных процессов, каждый из которых запускает сервер приветствия Node.js внутри контейнера докеров. Вместо того, чтобы возвращать hello world , сервер Node.js возвращает 1 МБ случайного текста. Родительский процесс находится в замкнутом цикле, который запускает контейнер, извлекает 1 МБ данных и останавливает контейнер. Используя эту настройку, я могу последовательно воспроизвести проблему в 4-90-х годах. Использование этой же настройки на физическом хосте или внутри виртуального бокса не воспроизводит проблему, несмотря на различные элементы, которые изменяют среднее время воспроизведения в блоке GCE. Переменные, с которыми я играл: количество одновременных тестовых процессов, размер передаваемой полезной нагрузки и количество вызовов curl. Первые две переменные определенно коррелированы, хотя я думаю, что это, вероятно, просто корректировка переменных, чтобы найти разумную точку насыщения для virt.

У меня тоже такая ошибка.

Я вижу, что это повторяется 3 раза после развертывания контейнера.

Описание

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

Действия по воспроизведению проблемы:

1. ssh на хост-докер
2. запустить контейнер

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

Опишите полученные результаты:

Просто повторите ошибку 3 раза.

Опишите ожидаемые результаты:
Нет ошибки

Дополнительная информация, которую вы считаете важной (например, проблема возникает только изредка):
Просто началось после этих выходных.

Вывод docker version :

 docker --version
Docker version 1.12.3, build 6b644ec

Вывод docker info :

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

Дополнительные сведения о среде (AWS, VirtualBox, физическая и т. Д.):

Виртуальная машина:
Fedora 24
OverlayFS2 на ext3

Отдельный накопитель выделен под докер использовать 24 гига.
16 гигов барана.

Докер PS

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

Образы докеров

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

Объем Докера Ls

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

* DF -H *

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

DF -i

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

Бесплатно -lmh

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

Для всех желающих мы (Travis CI) выпускаем обновление до v4.8.7 на Ubuntu 14.04. Наши нагрузочные тесты не выявили описанной здесь ошибки. Раньше мы запускали linux-image-generic-lts-xenial в Ubuntu 14.04. Я планирую в ближайшем будущем опубликовать сообщение в блоге, в котором будут описаны более подробные сведения.

ОБНОВЛЕНИЕ : я должен был упомянуть, что мы запускаем этот стек докеров:

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

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

ОБНОВЛЕНИЕ : Мы все еще наблюдаем эту ошибку в процессе производства на ядре Ubuntu Trusty + v4.8.7. Мы еще не знаем, почему эти ошибки исчезли при промежуточных нагрузочных тестах, которые ранее воспроизводили ошибку, но частота ошибок в производственной среде практически такая же. Вперед и вверх. Мы отключили «автоматическое сжатие» на основе этой ошибки, учитывая высокую скорость оборота экземпляров .

также найдено в 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

То же самое происходит и с VPS DigitalOcean при тестировании 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

Система

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

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

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

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

$ docker info

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

$ docker ps -a

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

$ ip link show

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

# ifconfig

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

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

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

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

Я тестировал 4.8.8 в тесном цикле (см. [2] из моего предыдущего комментария для тестового примера) без перерыва в течение последних 4 дней. Все идет нормально.

Факты

• Патч 751eb6b6 значительно снижает

Предположения
@meatballhat указали, что на их производственных серверах возникла проблема при запуске 4.8.7. Это оставляет нам две возможности:

• Мой тестовый пример неисправен (более вероятная вероятность)
• 4.8.8 внесено исправление. В журнале изменений 4.8.8 коммиты 5086cadf и 6fff1319 упоминают о проблемах netdev, которые были решены. Ни один из них явно не называет проблему здесь, но оба достаточно близки, чтобы вызывать подозрения.

Можем ли мы заставить нескольких людей попробовать 4.8.8, чтобы увидеть, смогут ли они воспроизвести эту проблему?

@reshen Я

@reshen Отличное исследование. До сих пор мне также не удалось воспроизвести проблему с помощью Linux 4.8.8 на Xubuntu 16.04.

Я использовал основные сборки ядра Ubuntu . У меня нет четко определенного тестового примера, но я мог бы последовательно воспроизвести проблему раньше, запустив и остановив набор контейнеров докеров, с которыми я работаю.

Для тестирования Linux 4.8.8 самым простым для меня было переключиться с aufs на overlay2 в качестве драйвера хранилища, поскольку основные сборки ядра не включали aufs. Не думаю, что повлияет на тест, но стоит отметить.

Раньше я тестировал Linux 4.4.4 с 751eb6b6, портированным Дэном Стритманом, это, похоже, не уменьшило проблему для меня. Будет интересно посмотреть, может ли обратное портирование двух отмеченных вами патчей (5086cadf и 6fff1319) дать тот же результат, что и 4.4.8.

Ubuntu 16.04 с 4.4.0-47 все еще пострадала ... попробую 4.4.0-49 сейчас, сообщу позже.

изменить: 2016-11-28: -49 - это sitll, показывающий эту строку журнала в dmesg.

Испытал это на Fedora 25 (ядро 4.8.8) и Docker 1.12.3

К вашему сведению: мы использовали Linux 4.8.8 в сочетании с Docker v1.12.3 на одном рабочем хосте. Время безотказной работы в настоящее время составляет 5,5 дней, и машина остается стабильной.

Иногда мы видим несколько сообщений unregister_netdevice: waiting for lo to become free. Usage count = 1 в системном журнале, но, в отличие от предыдущего, ядро ​​не дает сбоев и сообщение исчезает. Я подозреваю, что одно из других изменений, внесенных либо в ядро, либо в Docker, обнаруживает это состояние и теперь восстанавливается после него. Теперь это сообщение раздражает нас, но больше не является критической ошибкой.

Я надеюсь, что некоторые другие люди смогут подтвердить вышесказанное на своих производственных флотах.

@gtirloni - не могли бы вы уточнить, разбился ли ваш компьютер 4.8.8 / 1.12.3 или вы только что увидели сообщение?

Заранее благодарю всех, кто работал над воспроизведением / предоставлением полезной информации для триангуляции этой вещи.

мы удаляем аналог интерфейса veth (docker0) после запуска докера и перезапускаем докер после этого, когда мы предоставляем хост с помощью ansible. С тех пор проблем не возникало.

Я также получаю ту же ошибку на Raspberry Pi 2, работающем с Raspbian с Docker.

Информация о ядре
Linux rpi2 4.4.32-v7+ #924 SMP Tue Nov 15 18:11:28 GMT 2016 armv7l GNU/Linux

Информация о докере

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

Произошло это после создания контейнера, на который было установлено около 50 Мб скачанных программ.

Только перезагрузка позволит мне снова использовать машину

Я действительно вижу это в Amazon Linux в кластере ECS - сообщение иногда выдает, но оно не блокируется, как сейчас видит Решен. Докер 1.11.2. Uname сообщает о версии "4.4.14-24.50.amzn1.x86_64".

@reshen Я собираюсь собрать 4.8.8 в эти выходные на своем ноутбуке и посмотреть,
исправляет это для меня!
ᐧ

1 декабря 2016 г., в 10:29, Эрнест Мюллер [email protected]
написал:

Я действительно вижу это в Amazon Linux в кластере ECS - сообщение
изредка кидает, но не блокируется, как сейчас видит решен.
Докер 1.11.2. Uname сообщает о версии "4.4.14-24.50.amzn1.x86_64".

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/docker/issues/5618#issuecomment-264220432 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AKklVRqoBUZDu3HMhGv3b6knnA6j6C_Qks5rDvXRgaJpZM4B4L4Z
.

-
Кейфер Фурзланд
http://kfrz.work

Мне также удалось воспроизвести эту проблему с помощью https://github.com/crosbymichael/docker-stress на рабочем узле Kubernetes под управлением CoreOS Stable 1185.3.0.

Запуск docker_stress_linux_amd64 -k 3s -c 5 --containers 1000 : 5 параллельных рабочих процессов, создающих / удаляющих контейнеры, максимальное время жизни контейнеров = 3 с, создание до 1000 контейнеров на экземпляре m4.large на AWS, оставит демон Docker без ответа примерно через три минуты.

Обновился до CoreOS Beta 1235.1.0, и я не смог воспроизвести (как отсутствие ответа, так и сообщение unregister_netdevice в журналах ядра). В то время как запуск 5 одновременных рабочих процессов docker_stress убил бы CoreOS Stable через несколько минут, я смог работать с 10 и 15 параллельными рабочими процессами до завершения теста с использованием бета-версии CoreOS.

CoreOS выпускается в «каналах», поэтому изолированное обновление ядра невозможно. Вот основные различия между стабильной версией и бета-версией:

CoreOS стабильная 1185.3.0

ядро: 4.7.3

докер: 1.11.2

CoreOS бета 1235.1.0

ядро: 4.8.6

докер: 1.12.3

Эта проблема видна в Amazon Elastic Beanstalk под управлением 4.4.23-31.54.amzn1.x86_64

Просто произойдет на CoreOS Stable 1185.5.0, Docker 1.12.2
После перезагрузки все нормально

Обновление: проблема с зависшим демоном Docker снова возникла на хосте с CoreOS Beta 1235.1.0 с Docker v1.12.3 и ядром Linux v4.8.6. 😢

Теоретически 1.12.4 и 1.13 не должны зависать при обнаружении этой проблемы с ядром.
Причина зависания демона docker заключается в том, что демон ожидает ответного сообщения netlink от ядра (которое никогда не поступит), удерживая блокировку на объекте-контейнере.

1.12.4 и 1.13 устанавливают тайм-аут для этого запроса netlink, по крайней мере, для снятия блокировки контейнера.
Это __not__ устраняет проблему, но, по крайней мере (надеюсь), не останавливает весь демон.
Скорее всего, вы не сможете запускать новые контейнеры, и точно так же, вероятно, не сможете их снести, поскольку кажется, что все взаимодействия с netlink останавливаются после того, как эта проблема будет устранена.

@ cpuguy83 FWIW, любые запущенные контейнеры продолжают работать без проблем AFAIK, когда демон завис. Действительно, бросается в глаза запуск и остановка контейнеров (особенно работающих на Kubernetes, как и мы).

Это не решает проблему, но, по крайней мере (надеюсь), не останавливает весь демон.

Плюс всего этого демона в том, что его легко понять. Kubernetes может выселить узел, возможно, даже автоматически перезагрузиться. Если демон просто продолжит работу, можно ли будет легко обнаружить, что проблема с ядром вообще возникла?

@seanknox Я мог бы предоставить вам пользовательский AMI CoreOS 1248.1.0 с исправленным Docker (CoreOS Docker 1.12.3 + Upstream 1.12.4-rc1 Patches). Каждые пару часов он исправлял зависание на моих кластерах CoreOS / K8s. Просто свяжитесь со мной, указав свой идентификатор учетной записи AWS в Deis Slack.

У нас возникла большая проблема с этой проблемой в нашем кластере CoreOS. Может ли кто-нибудь сказать, когда это будет окончательно исправлено? Нам снится этот момент, когда мы можем спать по ночам.

@DenisIzmaylov Если вы не установите --userland-proxy=false , то, как правило, вы не должны сталкиваться с этой проблемой.

Но в остальном это ошибка ядра, возможно, несколько ошибок ядра, которые, по мнению одних, устранены в версии 4.8, а другие - нет. Некоторым кажется, что отключение ipv6 исправляет это, другие - нет (следовательно, это, вероятно, несколько проблем ... или, по крайней мере, несколько причин).

Я заметил эту проблему в течение нескольких часов в системах с высокой нагрузкой с и без --userland-proxy=false

Подтверждено, что мы все еще наблюдаем ошибки unregister_netdevice в ядре 4.8.12 . Для срабатывания требуется около 5 дней. Кажется, что проблема решена только перезагрузкой системы. Остановка Docker зависает на неопределенный срок.

Еще не пробовал трюк с отключением ipv6 для загрузки ядра.

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

Было бы здорово, если бы кто-нибудь мог попробовать это с 1.12.5, которая теперь должна тайм-аут для зависшего запроса netlink, а не просто зависания Docker.

@ cpuguy83 однако в этом состоянии система по-прежнему не работает :)

@ LK4D4 О,

Получение этой проблемы в Cent OS 7:

ядро: unregister_netdevice : ждет, пока lo станет свободным. Количество использования = 1

Linux foo 3.10.0-514.2.2.el7.x86_64 # 1 SMP Вт, 6 декабря 23:06:41 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux

докер-двигатель-1.12.5-1.el7.centos.x86_64

Это влияет на мои сборки CI, которые работают внутри контейнеров Docker и, кажется, внезапно умирают, во время чего появляется это консольное сообщение. Есть ли исправление или обходной путь? Благодарность!

@ cpuguy83 Docker не зависает у меня, когда возникает эта ошибка, но контейнеры убиваются, что в моей ситуации нарушает мои задания Jenkins / CI.

Итак, я некоторое время (11 месяцев?) Без проблем запускал докер на машине centos 7. Сегодня я решил попробовать демон прослушивания tcp ( добавил адрес прослушивания tcp в / etc / sysconfig / docker ) и только что получил эту ошибку.

ядро: unregister_netdevice : ждет, пока lo станет свободным. Количество использования = 1

поэтому мой счетчик использования не 3.

Контейнеры: 4
Бег: 3
Приостановлено: 0
Остановлено: 1
Фото: 67
Версия сервера: 1.10.3
Драйвер хранилища: btrfs
Версия сборки: Btrfs v4.4.1
Версия библиотеки: 101
Драйвер исполнения: native-0.2
Драйвер логирования: json-файл
Плагины:
Объем: местный
Сеть: мост нулевого хоста
Версия ядра: 3.10.0-514.2.2.el7.x86_64
Операционная система: CentOS Linux 7 (Core)
OSType: linux
Архитектура: x86_64
Количество Docker Hooks: 2
Процессоры: 24
Общий объем памяти: 39,12 Гбайт
Имя: aimes-web-encoder
ID: QK5Q: JCMA: ATGR : ND6W: YOT4: PZ7G: DBV5: PR26: YZQL: INRU : HAUC: CQ6B
Реестры: docker.io (безопасный)

3.10.0-514.2.2.el7.x86_64 # 1 SMP Вт, 6 декабря 23:06:41 UTC, 2016 x86_64 x86_64 x86_64 GNU / Linux

Клиент:
Версия: 1.10.3
Версия API: 1.22
Версия пакета: docker-common-1.10.3-59.el7.centos.x86_64
Версия Go: go1.6.3
Git commit: 3999ccb-неподдерживаемый
Построен: Чт 15 Дек, 17:24:43 2016
ОС / Arch: Linux / amd64

Сервер:
Версия: 1.10.3
Версия API: 1.22
Версия пакета: docker-common-1.10.3-59.el7.centos.x86_64
Версия Go: go1.6.3
Git commit: 3999ccb-неподдерживаемый
Построен: Чт 15 Дек, 17:24:43 2016
ОС / Arch: Linux / amd64

Могу подтвердить @aamerik. Я наблюдаю ту же проблему с той же версией ядра. В системе нет недавних серьезных изменений, эта проблема наблюдается с сегодняшнего дня.

Я видел то же сообщение kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1 на моем компьютере с CentOS 7, на котором запущен образ докера Jenkins. Машина CentOS 7, которую я использовал, была актуальна со всеми последними патчами CentOS 7 примерно на 20 декабря 2016 года.

Поскольку самые последние ссылки здесь, похоже, основаны на CentOS, я переключу свой исполнительный хост на машину Ubuntu или Debian.

Я использую Docker version 1.12.5, build 7392c3b на этой машине CentOS 7. Docker не завис, но процесс Jenkins, который я запускал в Docker, был убит, когда появилось это сообщение.

Большое спасибо за Docker! Я постоянно им пользуюсь и глубоко благодарен вам за работу над ним!

Я вижу ту же проблему при использовании Jenkins с Docker на машине Linux 4.8.15.

Кто-нибудь достиг процедуры исправления для ОС ранчо?

AFAICT, это проблема блокировки в подсистеме сетевых пространств имен ядра Linux. Об этой ошибке сообщили больше года назад, но без ответа: https://bugzilla.kernel.org/show_bug.cgi?id=97811 Над этим уже работали (см. Здесь: http: //www.spinics. net / lists / netdev / msg351337.html), но, похоже, это не полное исправление.

Я попытался напрямую связаться с обслуживающим персоналом сетевой подсистемы, но ответа не получил. FWIW, я могу воспроизвести проблему за считанные минуты.

Smyte заплатит 5000 долларов США за решение этой проблемы. Похоже, мне нужно поговорить с кем-нибудь, кто работает с ядром?

@petehunt Я считаю, что существует несколько проблем, вызывающих эту ошибку.

Мы развернули ядро 4.8.8 как предложил @reshen, и, хотя время безотказной работы кажется немного лучше, мы по-прежнему

Попытка развернуть Mesosphere из узла начальной загрузки. Все узлы имеют минимальную версию CentOS 7.2 со всеми примененными обновлениями. Узел начальной загрузки показывает ошибку, как указано выше другими:

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

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

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

uname -r:

3.10.0-514.2.2.el7.x86_64

докер -v:

Docker version 1.11.2, build b9f10c9

Я могу подтвердить, что перезагрузка отключает сообщения, но как только я снова развертываю мезосферу, сообщения запускаются то и дело. Мезосфера - это довольно крупное развертывание. Возможно, те, кто пытается воссоздать ошибку, могут использовать установщик для воспроизведения ошибки. После использования первого переключателя сценария (--genconf, который является первым шагом) проходит несколько минут, прежде чем ошибка появится.

Мы тоже это достигли. Однако в сообщениях об ошибках в нашем случае упоминается устройство eth0 не lo . Моя ошибка такова:

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

Я предполагаю, что такие ошибки, как упоминание eth0 вместо lo имеют ту же основную причину, что и эта проблема. Если нет, мы должны открыть новый тикет относительно ошибок eth0.

• ОС: CentOS Linux версии 7.3.1611
• Ядро: 3.10.0-514.2.2.el7.x86_64
• Докер версии 1.12.6, сборка 78d1802
• Докер запустился с опциями: OPTIONS=" -H unix:///var/run/docker.sock --ip-forward=true --iptables=true --ip-masq=true --log-driver json-file --log-opt max-size=25m --log-opt max-file=2"
• Rancher 1.2.2 с использованием IPsec (упоминание об этом с https://bugzilla.kernel.org/show_bug.cgi?id=97811 и других ошибок упоминается IPsec)

Мы тоже это достигли.
Ошибка: unregister_netdevice: ожидание освобождения lo.
ОС: CentOS Linux версии 7.3.1611 (Core)
Ядро 3.10.0-514.2.2.el7.x86_64
Версия докера: 1.13.0-cs1-rc1
Параметры Docker:
{
"disable-legacy-registry": правда,
"icc": правда,
"небезопасные реестры": [],
"ipv6": ложь,
"iptables": правда,
"драйвер-накопитель": "devicemapper",
"storage-opts": [
"dm.thinpooldev = / dev / mapper / docker_vg-thinpool",
"dm.use_deferred_removal = true",
"dm.use_deferred_deletion = true"
],
"userland-proxy": false
}

У меня это есть в двух системах CentOS, последние обновления по крайней мере на одной из них.

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

Привет, для всех, кто затронут этой проблемой в RHEL или CentOS, я перенес фиксацию из основных ядер (torvalds / linux @ 751eb6b6042a596b0080967c1a529a9fe98dac1d), которая исправляет состояние гонки в IPV6 IFP refcount для ядер 3.10.x, используемых в корпоративных дистрибутивах. Это должно решить эту проблему.

Вы можете найти отчет об ошибке с рабочим патчем здесь :
Если вы заинтересованы в его тестировании и у вас есть система RHEL 7 или CentOS 7, я уже скомпилировал последнюю версию ядра CentOS 7.3 3.10.0-514.6.1.el7.x86_64 с патчем. Ответьте на ветку отслеживания ошибок CentOS, и я могу отправить вам ссылку на сборку.

Примечание: может быть другая проблема, вызывающая утечку refcount, но это должно исправить сообщение об ошибке для многих из вас.

@stefanlasiewski @henryiii @jsoler

Я буду опробовать сборку, также добавив это исправление: http://www.spinics.net/lists/netdev/msg351337.html позже сегодня вечером.

@iamthebot означает ли это, что если кто-то отключит IPv6, это тоже должно решить проблему, даже без патча, который вы только что перенесли?

@redbaron, только если это проблема, с которой вы

@redbaron может быть. # 20569, похоже, указывает на то, что полностью отключить IPV6 сложно.

Итак, чтобы немного прояснить, что происходит под капотом, генерирующим это сообщение, ядро ​​поддерживает текущий счетчик того, используется ли устройство, прежде чем удалять его из пространства имен, отменять его регистрацию, деактивировать и т. Д. ссылку на устройство, то вы увидите это сообщение об ошибке, поскольку его нельзя отменить, когда его использует что-то еще.

Исправления, которые я видел до сих пор:

1. Устранение проблемы, при которой не удается выделить IPV6-адрес (например, дублированный адрес), но мы не освобождаем ссылку на устройство перед выходом.
2. Устранена проблема, из-за которой при перемещении пространства имен устройства ссылки на устройство будут правильно перемещены в новое сетевое пространство имен, но в старом пространстве имен останется висящая ссылка. Docker активно использует сетевые пространства имен (о чем свидетельствует другое исправление ядра: у меня был резервный порт Red Hat для Z-Stream 7.3 и который планируется включить в 7.4, что не позволяет драйверу docker macvlan работать на устройствах связи или групповых устройствах)

Я думаю, что есть еще одно условие гонки при переключении пространств имен (похоже, это происходит после создания кучи новых контейнеров), но мне нужно надежно воспроизвести проблему, чтобы выследить ее и написать патч.

У кого-нибудь есть минимальная процедура для последовательного воспроизведения этого? Похоже, это происходило случайным образом в наших системах.

@iamthebot, это не совсем просто, но я думаю, что мы можем предоставить вам тестовую среду, которая может надежно воспроизвести это. Напишите мне ([email protected]), и мы обсудим детали.

Это все еще наблюдается при большой нагрузке на Docker версии 1.12.6, сборка 7392c3b / 1.12.6 на 4.4.39-34.54.amzn1.x86_64 AWS Linux AMI.

У меня 9 хостов докеров, все почти одинаковые, и я испытываю это только на некоторых из них. Это может быть совпадение, но я заметил одну общую черту: эта проблема возникает только при запуске контейнеров, которые не обрабатывают SIGINT . Когда я docker stop эти контейнеры, он зависает на 10 секунд, а затем некорректно убивает контейнер.

Проблема проявляется в течение нескольких дней, и кажется, что она проявляется случайным образом, а не сразу после запуска docker stop . В основном это анекдотично, но, возможно, это кому-то поможет.

Я обновил все свои узлы докеров до ядра 3.10.0-514.6.1.el7.x86_64 на CentOS 7.3, как упоминал @iamthebot, но все равно получаю те же ошибки:
26 января, 13:52:49 ХХХ ядро: unregister_netdevice: ждем, пока Ло освободится. Количество использования = 1
Сообщение от syslogd @ XXX от 26 января 13:52:49 ...
ядро: unregister_netdevice : ждет, пока lo станет свободным. Количество использования = 1

@jsoler для ясности, вы применили патч в ветке отслеживания ошибок перед этот (патч должен работать на старых ядрах).

Напишите мне письмо ([email protected]), и я могу отправить вам ссылку на готовое ядро. @vitherman У меня, к сожалению, не так много времени, чтобы разобраться в этом (похоже, что для обнаружения этой ошибки потребуется скомпилировать некоторые инструменты), но я обострил проблему с поддержкой Red Hat, поэтому их команда разработчиков ядра примет меры. Смотреть.

@ckeeney Я могу подтвердить такое поведение. У нас есть докеризованное приложение Node, которое вызвало указанную ошибку в хост-системе при ее завершении. После реализации в приложении Node.js функции, которая улавливает SIGINT и SIGTERM, чтобы корректно завершить работу приложения, ошибка больше не возникала.
Что вроде бы имеет смысл; приложение Node использует виртуальный интерфейс, созданный Docker. Когда Node не завершается должным образом, устройство зависает, и хост-система не может отменить его регистрацию, даже если контейнер Docker был успешно остановлен.

вот пример фрагмента кода:

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

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

    process.exit();
}

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

@ michael-niemand есть ли другой сигнал, который по умолчанию правильно обрабатывается Node для чистого завершения работы? (вы можете указать STOPSIGNAL в изображении или docker run помощью флага --stop-signal .

@thaJeztah для хорошего объяснения проблемы и решения, см. nodejs / node-v0.x-archive # 9131 # issuecomment-72900581

@ckeeney Я знаю об этом (т.е. процессы, работающие как PID1 могут не обрабатывать SIGINT или SIGTERM ). По этой причине мне было интересно, приведет ли указание другого стоп-сигнала к чистому завершению работы, даже если он работает как PID1 .

В качестве альтернативы docker 1.13 добавляет параметр --init (запрос на вытягивание: https://github.com/docker/docker/pull/26061), который вставляет init в контейнер; в этом случае Node не работает как PID1 , что может помочь в тех случаях, когда вы не можете обновить приложение.

@iamthebot Я

Спасибо

Я имел дело с этой ошибкой почти год. Я использую CoreOS с загрузкой PXE, я отключил ipv6 в конфигурации pxeboot и с тех пор ни разу не видел этой проблемы.

Ну, моя среда отключила ipv6 с этой конфигурацией sysctl
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
но я все равно получаю сообщение об ошибке
ядро: unregister_netdevice : ждет, пока lo станет свободным. Количество использования = 1

@jsoler, верно, я тоже так делал, все равно случилось. Только как только я сделал это на уровне pxe, он остановился.

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

Просто наблюдение - похоже, что в игре есть разные проблемы (о чем уже говорилось ранее).

• Некоторые отмечают «жду вот ...»
• некоторые отметили "ожидание eth0"
• некоторые отметили "ожидание veth ?????"
• При отслеживании ошибок RedHat говорят о "ожидании ppp0"

Некоторые отметили, что журналы чередуются между любыми из вышеперечисленных, а в других имеется только один из них.

Аналогичная ошибка зарегистрирована и в Ubuntu . На этом они, кажется, обнаруживают, что проблема в NFS.

@etlweather Я считаю, что на самом деле единственным общим знаменателем является то, что сетевое устройство не может быть разрегистрировано ядром, как говорится в сообщении об ошибке. Однако причины _why_ несколько разные. Для нас это определенно была упомянутая проблема с докером / узлом (veth). Для eth, скорее всего, причина в чем-то совершенно другом.

По-прежнему происходит с 4.9.0-0.bpo.1-amd64 на debian jessie с docker 1.13.1. Есть ли стабильная комбинация ядра и ОС?

Это может быть не чисто проблема с докером - я получаю ее на сервере Proxmox, где я использую только ванильные контейнеры LXC (ubuntu 16.04).

@ darth-veitcher, это проблема ядра

@thaJeztah согласился, спасибо. Собирался сегодня вечером попробовать установить 4.9.9 из основной ветки и посмотреть, решит ли это проблему.

Я запускаю Docker 1.13.1 на Debian с ядром 4.9.9-040909.

Да, обновление ядра Proxmox до последней версии 4.9.9 не устранило ошибку. Странно, как это только появилось через год без проблем.

Возможно, что-то в предыдущем заявлении выше в потоке было связано с подключенными общими ресурсами NFS или CIFS.

отправлено из моего Айфона

14 февраля 2017 года в 07:47 Альфонсо да Силва [email protected] написал:

Я запускаю Docker 1.13.1 на Debian с ядром 4.9.9-040909.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите обсуждение.

У меня есть запрос на bugzilla по этому поводу в Redhat.

Некоторые разработки:
Red Hat поместила исправления утечки IPV6 из основной ветки в QA, похоже, они поставлены в очередь для RHEL 7.4 и могут быть перенесены на 7.3. Скоро появится и на CentOS-plus. Примечание. Этот патч исправляет проблемы только в НЕКОТОРЫХ случаях. Если у вас ядро ​​4.x, это спорный вопрос, так как они уже там.

Насколько я могу судить, это определенно состояние гонки в ядре, поэтому найти его действительно раздражает. Я сделал снимок текущего основного ядра и работаю над инструментаризацией различных вызовов, начиная с подсистемы IPV6. Теперь проблема определенно воспроизводима: похоже, все, что вам нужно сделать, это создать кучу контейнеров, вытолкнуть из них тонну сетевого трафика, вывести программу изнутри контейнеров и удалить их. Повторение этого снова и снова вызывает проблему в считанные минуты, максимум на физической 4-ядерной рабочей станции.

К сожалению, у меня не так много времени, чтобы работать над этим: если здесь есть разработчики ядра, которые готовы сотрудничать в инструментарии необходимых частей, я думаю, мы можем настроить форк и начать работу над поиском этого шаг за шагом. .

@iamthebot , воспроизводится ли он на установке qemu-kvm?

@iamthebot Я пытался воспроизвести это несколько раз с разными ядрами. Где-то выше упоминалось, что использование docker-stress -c 100 с userland-proxy установленным в false, вызовет его, но мне не повезло.

Если у вас есть более надежное воспроизведение (даже если на его срабатывание уходит много времени), я могу попробовать взглянуть

Мы сталкиваемся с такими же трудностями в нашей производственной и постановочной среде. Мы собираемся перейти на Docker 1.13 и ядро ​​Linux 4.9 в ближайшее время, но, как уже упоминалось, другие; эти версии также затронуты.

$ docker -v
Docker version 1.12.3, build 6b644ec

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

Я довольно часто сталкиваюсь с этой проблемой в своей системе разработки, всегда при выключении контейнеров.

Главная информация

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

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

→ docker -v 
Docker version 1.13.0, build 49bf474

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

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

Журнал демона докера

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

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

@ r-BenDoan, если вы попытаетесь остановить контейнер, но он не ответит на SIGINT, докер подождет 10 секунд, а затем некрасиво убьет контейнер. Я столкнулся с таким поведением в своих контейнерах nodejs, пока не добавил обработку сигналов. Если вы видите, что контейнеру требуется 10 секунд для остановки, вероятно, он не обрабатывает сигналы и, скорее всего, вызовет эту проблему.

Убедитесь, что ваши контейнеры могут плавно останавливаться.

Хотя я не тот, кто исправляет эту проблему, не особо увлекаюсь разработкой ядра Linux, я думаю, что прав, говоря, что комментарии «я тоже» не так уж и полезны. Под этим я подразумеваю, что если просто сказать «У меня тоже есть эта проблема с Kernel vx.x и Docker 1.x», это не принесет ничего нового в обсуждение.

Тем не менее, я бы предположил, что комментарии «я тоже», которые больше описывают окружающую среду и способ воспроизведения, были бы очень ценными.

При чтении всех комментариев становится ясно, что есть несколько проблем - как я писал ранее, некоторые с vethXYZ, некоторые с eth0 и другие с lo0. Это говорит о том, что они могли быть вызваны разными проблемами. Поэтому просто произнесение «я тоже» без полного описания ошибки и окружения может ввести людей в заблуждение.

Кроме того, при описании среды недостаточно указать версию ядра и Docker. В потоке, похоже, есть несколько факторов, таких как ipv6 включен или нет. NodeJS не отвечает на SIGINT (или другие контейнеры, а не на NodeJS здесь).

Так что описание рабочей нагрузки на среду было бы полезно. Кроме того, это происходит, когда контейнер выключается, поэтому я также предлагаю людям, столкнувшимся с этой проблемой, обратить внимание на то, какой контейнер останавливается, когда проблема поднимает свою уродливую голову.

Хотя кажется, что проблема заключается в том, что ядро ​​имеет состояние гонки, определение триггера будет огромной помощью для тех, кто исправит проблему. И это может даже дать затронутым пользователям немедленное решение, такое как реализация обработчика сигналов в приложении NodeJS (я сам не знаю, предотвращает ли это срабатывание проблемы, но это кажется так, согласно более ранним комментариям других).

FWIW kubernetes полностью соотносит это с «режимом шпильки» и
полностью прекратил использовать эту функцию. Мы не испытали этого
проблема вообще, на десятках тысяч производственных машин и
больше тестовых прогонов, с тех пор как изменилось.

Пока это не будет исправлено, оставьте корабль. Найдите другое решение :(

В среду, 15 февраля 2017 г., в 10:00 утра ETL [email protected] написал:

Хотя я не тот, кто решает эту проблему, не особо разбираюсь в Linux
Разработчик ядра, думаю, я прав, говоря, что комментарии "я тоже" не
это полезно. Под этим я подразумеваю, просто говоря "У меня тоже есть эта проблема с
Kernel vx.x и Docker 1.x »ничего нового в обсуждение не вносит.

Тем не менее, я бы посоветовал комментарии «я тоже», которые больше описывают
окружающая среда и метод воспроизводства будут иметь большое значение.

При чтении всех комментариев становится ясно, что есть несколько проблем -
как я писал ранее, некоторые с vethXYZ, некоторые с eth0 и другие с lo0.
Это говорит о том, что они могли быть вызваны разными проблемами. Так что просто
говоря "я тоже" без полного описания ошибки и среды, может
вводить людей в заблуждение.

Также при описании окружения, давая Kernel и Docker
версии недостаточно. Согласно ветке, похоже, есть несколько факторов
например включен ipv6 или нет. NodeJS не отвечает на SIGINT (или другой
контейнеры, а не на NodeJS здесь).

Так что описание рабочей нагрузки на среду было бы полезно.
Кроме того, это происходит, когда контейнер закрывается, поэтому я бы
также предложите людям, испытывающим эту проблему, обратить внимание на то, что
контейнер останавливается, когда проблема поднимает свою уродливую голову.

Хотя кажется, что проблема в том, что ядро ​​имеет состояние гонки -
определение триггера будет огромным подспорьем для тех, кто исправит
проблема. И это может даже дать пострадавшим пользователям немедленное решение
например, реализация обработчика сигнала в приложении NodeJS (я не знаю
я считаю, что это предотвращает запуск проблемы, но кажется, что так
более ранние комментарии других).

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/docker/issues/5618#issuecomment-280087293 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AFVgVFmu1SiStZcLKtKuk1W-tjn6wOXlks5rcz0hgaJpZM4B4L4Z
.

Да, мы переходим на gke и больше не видим этой проблемы (так что от нас больше не будет награды за ошибку :))

Только что снова произошла ошибка. Я пытался исправить приложение node.js, которое использует сокеты и поэтому часто масштабирует приложение. Приложение node.js было создано поверх https://github.com/deployd/deployd. Я надеюсь, что здесь есть дополнительная информация. Также было интересно то, что оба сервера внутри моего роя отображали ошибку unregister_netdevice одновременно после того, как я удалил службу через docker service rm. Контейнер был увеличен до 4, поэтому на каждой машине работало два контейнера.

edit Случилось снова! Работаем над тем же приложением node.js. Последние 3 или 4 дня я напрямую не работал над этим приложением node.js, и этого никогда не происходило.

edit2 попытается добавить обработчик сигнала в приложение nodejs. Посмотрим, поможет ли это ....

Я просто столкнулся с этой ошибкой после использования docker-py для публикации нового экземпляра в EC. Однако я смог выйти с помощью ctrl + C и с тех пор не видел этого (теперь, когда большинство изображений строятся из кеша быстрее)

`` `{" status ":" Push "," progressDetail ": {}," id ":" c0962ea0b9bc "}
{"status": "stage: digest: sha256: f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8 размер: 5737"}
{"progressDetail": {}, "aux": {"Tag": "stage", "Digest": "sha256: f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8", "Size": 5737}}

Образ Docker успешно опубликован

Сообщение от syslogd @ ip-172-31-31-68, 16 февраля, 19:49:16 ...
ядро: [1611081.976079] unregister_netdevice: ожидание освобождения lo. Количество использования = 1

Сообщение от syslogd @ ip-172-31-31-68 16 февраля, 19:49:27 ...
ядро: [1611092.220067] unregister_netdevice: ожидание освобождения lo. Количество использования = 1

[1] + Остановлено ./image-publish.py
[ root @ ip-172-31-xx-xx image-publish] # ^ C
[ root @ ip-172-31-xx-xx image-publish] #

@thockin это настройка --hairpin-mode=none на кубелец?

= никто не ломает контейнеры, которые возвращаются через NAT. Мы используем
неразборчивый мост по умолчанию.

В чт, 16 февраля 2017 г., в 19:26, Канат Бект [email protected]
написал:

@thockin https://github.com/thockin это настройка --hairpin-mode = none
на кубелец?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/docker/issues/5618#issuecomment-280539673 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AFVgVLNwAH6NWVaIKhJfS147O9w_rtJEks5rdRN8gaJpZM4B4L4Z
.

@thockin какие контейнеры могут захотеть получить доступ к себе через Service ClusterIP?

Оказалось, что это встречается чаще, чем я думал, и когда мы его сломали, много
людей жаловались.

17 февраля 2017 г., 00:38, «Максим Иванов» [email protected] написал:

@thockin https://github.com/thockin, какие контейнеры могут захотеть
получить доступ через Service ClusterIP?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/docker/issues/5618#issuecomment-280588366 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AFVgVLn3uBvUW-dQ72qst5_eYiFUtfSVks5rdVyIgaJpZM4B4L4Z
.

Думаю, я знаю, почему некоторые докеризованные приложения nodejs могут вызвать эту проблему. Узел по умолчанию использует поддерживающие соединения. Когда используется server.close() , сервер не принимает новые соединения. Но текущие активные соединения, такие как веб-сокеты или поддерживающие HTTP-соединения, по-прежнему поддерживаются. Когда докеризованное приложение также масштабируется до n, это может привести к waiting for lo to become free потому что, когда оно принудительно завершается, более новое было освобождено. Когда докер перераспределяет это приложение на другой узел или приложение уменьшается, докер отправляет сигнал приложению, что оно должно выключиться. Приложение слушает этот сигнал и может реагировать. Когда приложение не закрывается через несколько секунд, докер без колебаний завершает его работу. Я добавил обработчики сигналов и обнаружил, что при использовании server.close() сервер не завершается полностью, а «только» перестает принимать новые соединения (см. Https://github.com/nodejs/node/issues/2642). Поэтому нам нужно убедиться, что открытые соединения, такие как веб-сокеты или http keep-alive, также закрыты.

Как работать с веб-сокетами:
Приложение nodejs отправляет всем веб-сокетам closeSockets при получении сигнала выключения. Клиент прослушивает это событие closeSockets и вызывает sockets.disconnect() и вскоре после этого sockets.connect() . Помните, что был вызван server.close() поэтому этот экземпляр не принимает новые запросы. Когда другие экземпляры этого докеризованного приложения работают, балансировщик нагрузки внутри докера в конечном итоге выберет экземпляр, который не завершается, и устанавливается успешное соединение. Экземпляр, который должен отключиться, не будет иметь открытых веб-соединений.

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

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

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

Как обрабатывать HTTP-соединения keep-alive:
В настоящее время я не знаю, как это можно сделать идеально. Самый простой способ - отключить keep-alive.

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

Другая возможность - установить очень низкое значение для тайм-аута проверки активности. Например 0,5 секунды.

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

Надеюсь, это поможет другим :)

У меня такие же проблемы. Вложения - это все журналы, созданные с помощью сценария ecs-logs-collector.
Большое спасибо за любую помощь :)

collect.zip

У меня такие же проблемы.
Докер версии 1.13.1, сборка 092cba3
Linux debian 4.8.6-x86_64-linode78

Резервное копирование Linux 4.6.0-040600-generic # 201606100558 SMP Пт, 10 июня, 10:01:15 UTC, 2016 x86_64 x86_64 x86_64 GNU / Linux
Версия сервера: 1.13.1

Та же проблема. Я использую монтирование в привилегированном контейнере. После 4-5 прогонов зависает. Также у меня такая же проблема с последним стандартным ядром для 16.04.

Всем, @etlweather на высоте . Пишите «я тоже», только если у вас есть надежный способ воспроизвести проблему. В этом случае подробно опишите вашу процедуру. Версии докера и ядра недостаточно, и мы получаем много уведомлений об этом. Чем проще ваша процедура воспроизведения, тем лучше.

@rneugeba @redbaron К сожалению, текущая "реплика", которая у меня есть, очень специфична для оборудования (почти доказывает, что это состояние гонки). Я не пробовал получить репро QEMU, но это определенно следующий шаг, так что несколько человек могут действительно поработать над этим и получить ожидаемый результат (в идеале при настройке с одним ядром ЦП). Если у кого-то он уже есть, напишите мне письмо (оно в моем профиле). Я его тщательно протестирую и выложу здесь.

Мы довольно часто получаем это в GCE. Докер зависает, и машина зависает при перезагрузке.

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

Контейнер запускает приложение go и настроен для шпильки nat.

Докер:

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

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

Ubuntu 16.04 LTS,

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

Есть ли у кого-нибудь предлагаемое решение для этого? Я попытался включить --userland-proxy=true но через некоторое время докер все еще зависает. Похоже, что у Kubernates есть решение из того, что @thockin написал выше, но неясно, что именно делает --hairpin-mode=promiscuous-bridge и как настроить это при установке простого докера jane ubuntu 16.x.

Я могу сделать это надежно, запустив Proxmox и используя контейнеры. В частности, если я переместил значительный объем данных или действительно переместил какой-либо объем данных совсем недавно, завершение работы или жесткая остановка контейнера вызовет эту ошибку. Я видел это чаще всего, когда использую контейнеры, в которые монтируется мой NAS, но это может быть совпадением.

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

# cat /etc/debian_version
8.7

И изнутри Proxmox:

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

Стоит отметить, что Docker не установлен в этой системе и никогда не устанавливался. Я с радостью предоставлю любые данные, необходимые сообществу для устранения этой проблемы, просто скажите мне, какие команды нужно выполнить.

Я могу воспроизвести это на centos 7.3, работающем как рабочий узел роя, на котором запущен dtr с подключенным томом nfs, сопоставленным

Если вы приедете сюда

Обсуждаемая здесь проблема является ошибкой ядра и еще не исправлена. Есть несколько вариантов, которые могут помочь _в некоторых_ ситуациях, но не для всех (скорее всего, это комбинация проблем, вызывающих одну и ту же ошибку).

Не оставляйте комментарии типа «У меня тоже это есть»

«У меня тоже есть это» не помогает устранить ошибку. оставляйте комментарий только в том случае, если у вас есть информация, которая может помочь решить проблему (в этом случае; предоставление патча для ядра может быть лучшим шагом).

Если вы хотите сообщить, что у вас тоже есть эта проблема, используйте кнопку «палец вверх» в верхнем описании:

Если вы хотите быть в курсе обновлений, используйте кнопку _подписаться_.

Каждый комментарий здесь отправляет электронное письмо / уведомление более чем 3000 человек. Я не хочу блокировать разговор по этому вопросу, потому что он еще не решен, но может быть вынужден, если вы проигнорируете это.

Спасибо!

Это все хорошо, но какие именно варианты помогают? Эта проблема вызывает у нас проблемы в производственной среде, поэтому я хотел бы предпринять любые действия, необходимые для обхода ошибки ядра.

Если у кого-то из Docker есть время попробовать обходной путь Kubernetes, пожалуйста,
дайте мне знать, и мы можем указать вам на это. Я не могу извлечь изменения
и пропатчу их в Docker прямо сейчас.

В четверг, 9 марта 2017 г., в 7:46, Мэтью Ньюхук [email protected]
написал:

Это все хорошо, но какие именно варианты помогают?
Эта проблема вызывает у нас проблемы в производстве, поэтому я хотел бы сделать что угодно
обходные пути, необходимые для обхода ошибки ядра.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/docker/issues/5618#issuecomment-285388243 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AFVgVGdH5VX_oFWkImyo_TvlIuhmwMepks5rkB7MgaJpZM4B4L4Z
.

@thockin спасибо. Я следил за PR / проблемой в Kubernetes с обходным путем в режиме шпильки. Но во время множества перемоток я потерял счет, избавит ли факт обходного пути от этой проблемы?
(Насколько я понимаю, существуют разные сценарии, которые вызывают несоответствие количества ссылок в ядре).

Если вы можете указать мне на PR, который, по вашему мнению, решает проблему в K8s, я буду работать, чтобы исправить это в докере, по крайней мере, на случай отключения userland-proxy по умолчанию. (И мы можем протестировать это, используя шаги воспроизведения докеровского стресса).

Не уверен, что у меня есть единый PR, но вы можете посмотреть текущее состояние. Начинать
здесь:

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

В сб, 11 марта 2017 г., 22:49, Мадху Венугопал [email protected]
написал:

@thockin https://github.com/thockin спасибо. Я следил за
PR / проблема в Kubernetes с обходным путем в режиме шпильки. Но во время
много назад и вперед, я потерял счет, если обходной путь избавится от этого
проблема ?
(Насколько я понимаю, существуют разные сценарии, которые вызывают счетчик ссылок
несогласованность в ядре).

Если вы можете указать мне на PR, который, по вашему мнению, решает проблему в K8s,
Я буду работать, чтобы исправить это в докере, по крайней мере, на случай поворота
userland-proxy по умолчанию отключен. (И мы можем проверить это с помощью docker-stress
шаги воспроизведения).

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/docker/issues/5618#issuecomment-285926217 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AFVgVIlGs_QccxS6YYQiLNybddDzB4yUks5rk5VogaJpZM4B4L4Z
.

Привет всем, просто для ясности, все "обходные пути kubernetes" - это включение неразборчивого режима на нижележащем мосте. Вы можете добиться того же с помощью ip link set <bridgename> promisc on используя iproute2. Это снижает вероятность столкновения с ошибкой, но не может полностью устранить ее.

Теоретически это не должно работать ... но по какой-то причине беспорядочный режим, кажется, делает разборку устройства достаточно медленной, чтобы у вас не было гонки по уменьшению счетчика ссылок. Возможно, кто-то из участников Kurbernetes сможет вмешаться, если они в этой теме.

Я могу проверить, работает ли обходной путь (НЕ ИСПРАВЛЕНИЕ), используя мою репродукцию для конкретной среды. Я действительно не могу убедиться, что это помогает, если вы используете драйверы IPVLAN или MACVLAN (мы используем macvlan в продукте), потому что кажется очень сложным настроить эти настройки для создания этой ошибки. Может ли кто-нибудь еще с повторной попыткой проверить обходной путь?

Привет всем, я попытался отладить проблему с ядром, у меня была цепочка адресов электронной почты в списке рассылки netdev, поэтому я просто хотел опубликовать здесь некоторые выводы.

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

Проблема, которую мы наблюдаем, заключается в том, что

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

при остановке контейнера. Когда я проверяю пространство имен сети контейнера, кажется, что устройство eth0 уже удалено, но там осталось только устройство lo . И есть еще одна структура, содержащая ссылку на это устройство.

После некоторого покопания выясняется, что "вещь", содержащая ссылку, является одним из "кешей маршрутизации" ( struct dst_entry ). И что-то мешает этому конкретному dst_entry быть gc'ed (счетчик ссылок для dst_entry больше 0). Таким образом, я регистрировал каждый dst_hold() (увеличить счетчик ссылок dst_entry на 1) и dst_release() (уменьшить счетчик ссылок dst_entry на 1), и действительно было больше вызовов dst_hold() чем dst_release() .

Вот приложенные логи: kern.log.zip

Резюме:

• интерфейс lo был переименован в lodebug для упрощения поиска.
• счетчик ссылок для dst_entry начинается с 1
• счетчик ссылок для dst_entry (который содержит ссылку для lo) в конце равен 19
• всего 258041 dst_hold() вызовов и 258023 всего dst_release() вызовов
• в вызовах 258041 dst_hold() есть 88034 udp_sk_rx_dst_set() (который затем вызывает dst_hold() ), 152536 inet_sk_rx_dst_set() и 17471 __sk_add_backlog()
• в вызовах 258023 dst_release() есть 240551 inet_sock_destruct() и 17472 refdst_drop()

Всего вызовов udp_sk_rx_dst_set() и inet_sk_rx_dst_set() больше, чем inet_sock_destruct() , поэтому есть подозрение, что некоторые сокеты находятся в состоянии «неопределенности» и что-то мешает их уничтожению.

ОБНОВИТЬ:
Оказывается, сокеты ( struct sock ) создаются и уничтожаются правильно, но для некоторых сокетов TCP inet_sk_rx_dst_set() вызываются несколько раз на одном и том же dst , но есть только один соответствующий inet_sock_destruct() чтобы освободить ссылку на dst .

Вот обходной путь CentOS 7.3, который исправил это для меня:

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

Вот патч, который решает эту проблему:
https://bugs.centos.org/view.php?id=12711&nbn=1

ОБНОВЛЕНИЕ: Оказалось, что это не решает проблему навсегда. Через несколько часов он снова появился со следующим сообщением на стене:
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

@adrianotto - чтобы уточнить: исправляет ли это исправление ядра CentOS? Просто любопытно, имели ли вы в виду как обходной путь, так и ссылочный путь к ядру, и оба они не разрешили это навсегда?

@stayclassychicago @adrianotto Этот патч устраняет только одно из условий гонки, которые могут вызвать проблему «подсчета использования» в ядре. Это просто мое исправление из чего-то, что уже есть в ядрах 4.x. Это может решить ваши проблемы, поэтому стоит попробовать.

@stayclassychicago, прежде чем я попробовал ядро 3.10.0-514.10.2.el7.centos.plus.x86_64 я получал kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1 очень регулярно, почти каждый раз, когда я запускал контейнер с docker run --rm ... при выходе из контейнера. После обновления ядра и перезагрузки оно полностью остановилось на много часов, а затем снова вернулось. Теперь половину времени, когда я удаляю контейнеры, он работает правильно, хотя раньше очень часто возникали ошибки. Точно не знаю, помогает ли новое ядро, но не повредит.

Похоже, что это очень легко воспроизвести, когда на машине есть интерфейс связывания LACP. У нас есть ройный кластер с 3 узлами, все 3 с настроенным интерфейсом связывания LACP, и эта проблема в основном не позволяет нам работать с кластером. Мы должны перезапускать узлы каждые 15-20 минут.

Подтверждено - как только я удалил привязку LACP с интерфейсов (которые использовались в качестве основных), все работает нормально более 12 часов. Используется для прерывания каждые ~ 30 минут.

Это воспроизводится на Linux containerhost1 4.9.0-0.bpo.2-amd64 #1 SMP Debian 4.9.18-1~bpo8+1 (2017-04-10) x86_64 GNU/Linux с Docker version 17.04.0-ce, build 4845c56 запущенным в привилегированном режиме, когда у нас открыты монтирования cifs. Когда контейнер останавливается с открытыми монтировками, Docker перестает отвечать, и мы получаем kernel:[ 1129.675495] unregister_netdevice: waiting for lo to become free. Usage count = 1 -error.

ubuntu 16.04 (ядро 4.4.0-78-generic) по-прежнему имеет проблему. И когда это произойдет, любое приложение, которое попытается создать новое сетевое пространство имен с помощью системного вызова clone, застрянет.

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

Единственное решение - выполнить полную перезагрузку машины.

Я столкнулся с этой проблемой при монтировании тома NFS в привилегированном контейнере и его перезапуске.
Мне кажется, что эта проблема никогда не возникала в RHEL 7 с той же процедурой.

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

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

Red Hat утверждает, что экземпляр этой ошибки исправлен в версии kernel-3.10.0-514.21.1.el7. Я предполагаю, что они как можно скорее выложат исправление и переустановят его на 4.12. Этот пакет уже доступен и в CentOS 7.

Документация по исправлению (необходим доступ к RHN):
https://access.redhat.com/articles/3034221
https://bugzilla.redhat.com/show_bug.cgi?id=1436588

Из статьи:
«В случае дублирования адреса IPv6 или проблемы с установкой адреса возникла гонка. Это состояние гонки иногда приводило к утечке подсчета ссылок на адреса. Следовательно, попытки отменить регистрацию сетевого устройства не удались со следующим сообщением об ошибке:« unregister_netdevice: ожидание чтобы стать свободным. Счетчик использования = 1 ". В этом обновлении основной исходный код был исправлен, и сетевые устройства теперь отменяют регистрацию, как ожидалось в описанной ситуации".

Я уже развернул это исправление во всех системах нашего пула PaaS, и прошло уже 2 дня без исправления ошибки. Раньше у нас замораживалась как минимум одна система в день. Я сообщу здесь, если мы снова столкнемся с ошибкой.

У меня версия ядра 3.10.0-514.21.1.el7.x86_64, и у меня все тот же симптом.

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

@adrianotto По-видимому, есть несколько способов

@bcdonadio Если вы посмотрите https://git.centos.org/commitdiff/rpms!kernel.git/b777aca52781bc9b15328e8798726608933ceded - вы увидите, что https://bugzilla.redhat.com/show_bug.cgi?id=1436588 "исправлено" этим изменением:

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

Я считаю, что это находится в восходящем ядре с 4.8 (https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d). И в 4.9 и 4.10 есть эта ошибка, поэтому RedHat просто перенес некоторые исправления из апстрима, которые, вероятно, исправят некоторые проблемы, но определенно не все из них.

@bcdonadio Я могу воспроизвести ошибку в своей системе, запустив этот тестовый скрипт один раз в час из 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

Этот сценарий просто создает список пакетов с использованием образа в реестре Docker, а другой - с использованием образа, созданного локально, чтобы я мог их сравнить. Dockerfile выглядит так:

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

Через 2-4 минуты системный журнал получает это сообщение:

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

В последнем случае это произошло через несколько минут после того, как я запустил скрипт вручную. Я предполагаю, что по истечении некоторого времени ожидания после попытки удаления контейнера возникает состояние ошибки.

Я уверен, что состояние ошибки является прерывистым, потому что приведенный выше сценарий запускается как задание cron в: 00 после каждой ошибки. Вот пример вывода ошибок, записанных системным журналом:

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

Таким образом, это происходит где-то в диапазоне от 2 до 4 минут после запуска и выхода контейнеров и удаляется докером из-за флага --rm. Также обратите внимание на приведенный выше журнал, что нет ошибки для каждого запущенного / удаленного контейнера, но она довольно последовательна.

Может ли кто-нибудь увидеть, улучшит ли этот патч ситуацию?

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

@hlrichardson Это действительно похоже! Я постараюсь перенести его на наше ядро ​​3.16 или обновить определенные серверы и скомпилировать ядро ​​4.9 с этим патчем завтра, посмотрим, как это пойдет.

Хотя после проверки фиксации этот патч ссылается на (https://github.com/torvalds/linux/commit/0c1d70af924b966cc71e9e48920b2b635441aa50) - он был зафиксирован в ядре 4.6, а проблема была еще раньше :(

Ах, так что, возможно, не связано, если нет нескольких причин (к сожалению, есть много способов, которыми этот тип ошибки может быть вызван, так что это вероятность).

Мы лично затронули здесь как минимум несколько проблем - в некоторых из них эти
Журналы "unregister_netdevice" просто исчезают через некоторое время и
Docker контейнеры умеют нормально работать, а в других - все контейнеры
застряли, и сервер необходимо перезагрузить.

На самом деле - мы не используем vxlan на серверах, на которых возникают эти проблемы - мы используем
простые мосты и переадресация портов (происходит независимо от userland-proxy
настройки).

30 мая 2017 г. в 22:54 "hlrichardson" [email protected] написал:

Ах, так что, возможно, не связаны, если нет нескольких причин
(к сожалению, есть много способов вызвать этот тип ошибки, поэтому
это возможность).

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/5618#issuecomment-304989068 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAGqoDHe1n3h9_eJ2kmeWcbhKRCX6rZoks5r_HPbgaJpZM4B4L4Z
.

Хорошо, если вы не используете туннели vxlan, это точно не поможет.

Кстати, если вы видите единственный экземпляр сообщения «unregister_netdevice» при удалении сетевого пространства имен (выход из контейнера), это следует рассматривать как нормальную ситуацию, когда что-то, ссылающееся на сетевое устройство, было очищено более или менее одновременно с пространством имен
удаляется.

Более серьезный случай, когда это сообщение повторяется каждые 10 секунд и никогда не прекращается ...
в этом случае глобальная блокировка сохраняется навсегда, и поскольку эта блокировка должна быть получена всякий раз, когда сеть
пространство имен добавляется или удаляется, любая попытка создать или удалить сетевое пространство имен также
висит навсегда.

Если у вас есть довольно безболезненный способ воспроизвести второй тип проблемы, мне было бы интересно
смотреть.

@hlrichardson Мы наблюдаем второй случай, о котором вы упомянули выше, на нескольких наших серверах, т.е. сообщение повторяется каждые 10 секунд. Какой информацией вы хотите, чтобы я поделился?

Наблюдая это в Fedora 25 при тестировании и сборке centos: 7 контейнеров при использовании yum. Yum не смог завершить загрузку базы данных пакетов и завис на неопределенное время, потому что сеть перестала работать странным образом.

Привет, народ,

В списке рассылки Linux net-dev есть потенциальный патч для ошибки ядра (или, по крайней мере, одной из ошибок):

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

Он объединен в сетевое дерево и поставлен в очередь на стабильное дерево.

Согласно https://github.com/torvalds/linux/commit/d747a7a51b00984127a88113cdbbc26f91e9d815 - это версия 4.12 (которая была выпущена вчера)!

@fxposter @kevinxucs Я попробую перенести это на текущее ядро ​​CentOS.

Я использую 4.12 (из http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12/), и я все еще использую это, поэтому torvalds / linux @ d747a7a не должно быть полным исправлением.

$ uname -r
4.12.0-041200-generic

Райан, у тебя есть надежный способ размножения?

6 июля 2017 года в 16:29 "Райан Кэмпбелл" [email protected] написал:

Я использую 4.12 (с http://kernel.ubuntu.com/~
kernel-ppa / mainline / v4.12 /), и я все еще нажимаю на него, поэтому torvalds / linux @
d747a7a https://github.com/torvalds/linux/commit/d747a7a не должно быть
полное исправление.

$ uname -r
4.12.0-041200-общий

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/5618#issuecomment-313413120 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAdcPCbVPDjPw6va-N5dM7CjYn2W4Bodks5sLO9ZgaJpZM4B4L4Z
.

@justincormack К сожалению, у меня нет минимального примера, которым я мог бы поделиться, но у нас есть набор тестов, который создает и уничтожает множество контейнеров, и я обычно сталкиваюсь с этой проблемой (зависание команд докеров, много waiting for lo to become free в системном журнале) после нескольких итераций.

@campbellr Я пытался воспроизвести это уже три раза и потратил на это большую часть этой недели без особой удачи. Пару раз мне удавалось получать сообщения waiting for lo to become free но потом без сбоев / зависаний. Я пытаюсь сократить тестовый пример, просто создав сетевое пространство имен и интерфейсы veth.

В вашем наборе тестов:

• у ваших контейнеров много сетевой активности? Если да, то какое направление преобладает?
• На какой машине вы работаете (количество ядер, это виртуальная машина и т. Д.)
• Вы одновременно создаете много контейнеров?
• Ваши контейнеры выходят нормально или они разбиваются?

Даже частичные ответы на вышеперечисленное могут помочь сузить круг вопросов ...
Благодарность

@rn Docker больше не будет зависать, поскольку он устанавливает тайм-аут для запроса netlink, который обычно зависает. Но вы не сможете запускать новые контейнеры (или перезапускать существующие), вероятно, очистка контейнера при остановке также будет странной.

У меня еще не было возможности протестировать 4.12, но я мог надежно воспроизвести на экземплярах kvm в vultr. Я использую рой, и мои хромированные рабочие без головы вызывают проблемы, когда они не проходят проверки работоспособности или регулярно выходят из строя. Конечно, на данный момент я отследил всех сбойников, которые аккуратно обрабатывают сетевые ошибки и т. Д., Поэтому я вижу waiting for lo to become free но недостаточно часто, чтобы что-то повесить на пару недель.

Таким образом, похоже, что вещи, которые помогают воспроизвести, - это более сложные сетевые сценарии в сочетании с большим объемом трафика в контейнерах, постоянной переработкой контейнеров и kvm.

@rn Мне удалось сузить это до определенного контейнера в нашем наборе тестов, и я смог воспроизвести его, выполнив следующие шаги:

1. стартовый контейнер (внутренняя веб-служба на основе торнадо - я пытаюсь извлечь минимальный пример, который все еще попадает в это)
2. сделать запрос к веб-сервису, работающему в контейнере
3. ждать ответа
4. убить контейнер

После 3 или 4 итераций этого я получаю waiting for lo to become free а на следующей итерации docker run терпит неудачу с docker: Error response from daemon: containerd: container did not start before the specified timeout.

у ваших контейнеров много сетевой активности? Если да, то какое направление преобладает?

Довольно небольшая сумма. На шагах, упомянутых выше, HTTP-запрос представляет собой небольшое количество json, а ответ представляет собой двоичный BLOB-объект размером около 10 МБ.

На какой машине вы работаете (количество ядер, это виртуальная машина и т. Д.)

Это на 4-ядерном настольном компьютере (без виртуальной машины)

Вы одновременно создаете много контейнеров?

Нет, все делается серийно.

Ваши контейнеры выходят нормально или они разбиваются?

Их останавливают docker stop

1. стартовый контейнер (внутренняя веб-служба на основе торнадо - я пытаюсь извлечь минимальный пример, который все еще попадает в это)
2. сделать запрос к веб-сервису, работающему в контейнере
3. ждать ответа
4. убить контейнер

Я потратил некоторое время на то, чтобы разобрать контейнер, и оказалось, что веб-сервис не имел ничего общего с ошибкой. Что, кажется, вызывает это в моем случае, - это установка общего ресурса NFS внутри контейнера (работающего с --privileged ).

На своем рабочем столе я могу надежно воспроизвести, просто выполнив несколько раз следующее:

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

Пользователи Kubernetes, я обратился к _kops_ с вопросом о выпуске следующего Kubernetes AMI с версией ядра 4.12. Добро пожаловать, чтобы проверить это: https://github.com/kubernetes/kops/issues/2901

Я также использовал это на centos 7.3 с ядром хоста 3.10.0-514.6.1.el7.x86_64 и docker-ce-17.06.0.ce-1.el7.centos.x86_64.

@FrankYu это бесполезно. Чтобы с пользой участвовать в этой теме, укажите точный способ воспроизвести эту проблему и протестируйте на современном ядре. 3.10 была выпущена четыре года назад, мы обсуждаем, будет ли она исправлена ​​или частично в версии, выпущенной четыре дня назад.

@danielgusmao в наших ОС RancherOS и AWS ECS AMI linux уже есть это «исправление» (вероятно, оно было по умолчанию), и это не решает проблему для нас. Мы по-прежнему видим, что сообщение постоянно отображается в журналах. Скорее всего, единственная надежда на то, что патч ядра получит широкое распространение. Хотя я искал вокруг и не вижу никаких доказательств серьезного прогресса в этом направлении в багзиллах и форумах RedHat / Centos / AWS linux.

Чтобы быть ясным, само сообщение является доброкачественным , это сбой ядра после сообщений, сообщенных OP, а это не так.

Комментарий в коде, откуда пришло это сообщение, объясняет, что происходит. Практически каждый пользователь, например IP-стек) сетевого устройства (например, конец пары veth внутри контейнера) увеличивает счетчик ссылок в структуре сетевого устройства, когда он использует сетевое устройство. Когда устройство удаляется (например, когда удаляется контейнер), каждый пользователь уведомляется, чтобы он мог выполнить некоторую очистку (например, закрыть открытые сокеты и т. Д.) Перед уменьшением счетчика ссылок. Поскольку эта очистка может занять некоторое время, особенно при больших нагрузках (Лот интерфейса, много соединений и т.д.), ядро может напечатать сообщение здесь раз в то время.

Если пользователь сетевого устройства никогда не уменьшает счетчик ссылок, какая-то другая часть ядра определит, что задача, ожидающая очистки, зависла, и произойдет сбой. Только этот сбой указывает на ошибку ядра (какой-то пользователь с помощью некоторого пути кода не уменьшил счетчик ссылок). Было несколько таких ошибок, и они были исправлены в современном ядре (и, возможно, были перенесены обратно на более старые). Я написал довольно много стресс-тестов (и продолжаю их писать), чтобы вызвать такие сбои, но не смог воспроизвести их на современных ядрах (тем не менее, это сообщение выше).

Пожалуйста, сообщайте об этой проблеме только в том случае, если ваше ядро ​​действительно дает сбой, и тогда мы будем очень заинтересованы в следующем:

• версия ядра (вывод uname -r )
• Дистрибутив / версия Linux
• Вы используете последнюю версию ядра от вашего поставщика Linux?
• Настройка сети (мост, оверлей, IPv4, IPv6 и т. Д.)
• Описание нагрузки (какой тип контейнеров, какой тип сетевой нагрузки и т. Д.)
• А в идеале простое воспроизведение

Спасибо

[ @thaJeztah, не могли бы вы изменить заголовок на что-то вроде kernel crash after "unregister_netdevice: waiting for lo to become free. Usage count = 3" чтобы сделать его более явным]

Должен быть исправлен в ядре 4.12 или позже. Пожалуйста, проверьте. https://access.redhat.com/solutions/3105941
и ссылка на патч https://github.com/torvalds/linux/commit/d747a7a51b00984127a88113cdbbc26f91e9d815

@drweber вы также найдете этот патч в следующих стабильных выпусках (на данный момент 4.11.12, 4.9.39, 4.4.78, 3.18.62)

@rn

Если пользователь сетевого устройства никогда не уменьшает счетчик ссылок, какая-то другая часть ядра определит, что задача, ожидающая очистки, зависла, и произойдет сбой. Только этот сбой указывает на ошибку ядра (какой-то пользователь с помощью некоторого пути кода не уменьшил счетчик ссылок). Было несколько таких ошибок, и они были исправлены в современном ядре (и, возможно, были перенесены обратно на более старые). Я написал довольно много стресс-тестов (и продолжаю их писать), чтобы вызвать такие сбои, но не смог воспроизвести их на современных ядрах (тем не менее, это сообщение выше).

Пожалуйста, сообщайте об этой проблеме только в том случае, если ваше ядро ​​действительно дает сбой ...

У нас немного другая проблема в нашей среде, по которой я надеюсь получить некоторые разъяснения (ядро 3.16.0-77-generic, Ubuntu 14.04, docker 1.12.3-0 ~ trusty. У нас есть тысячи хостов, на которых запущено docker, 2 -3 контейнера на хост, и мы наблюдаем это на <1% от общего числа хостов, на которых работает докер).

На самом деле мы никогда не видим сбоя ядра, но вместо этого (как и в случае с исходными репортерами, насколько я могу судить) процесс dockerd не работает. Upstart (с использованием задания /etc/init/docker.conf из вышестоящего пакета) не запустит новый процесс dockerd потому что он считает, что он уже запущен ( start: Job is already running: docker ), и пытается остановить выскочку задание также не выполняется ( docker start/killed, process <pid of defunct process> ).

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

Поскольку мы в основном работаем с мостовой сетью (на настраиваемом мостовом устройстве) в dmesg мы видим немного другое сообщение, относящееся к виртуальному интерфейсу:

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

Поскольку кажется, что выскочка отказывается перезапускать dockerd или распознает, что ранее запущенный процесс является зомби, единственное решение, которое мы нашли, - это перезагрузить хост.

Хотя наш результат кажется другим (ядро не падает), основная причина звучит одинаково или похоже. Значит, это не та же проблема? Есть ли какой-либо известный обходной путь или способ снова запустить задание docker upstart, когда это произойдет?

@campbellr Я могу воспроизвести эту проблему с вашим подходом к ядру 4.12.2-1.
Кстати, если я отключу хранилище NFS до остановки контейнера, этой проблемы не возникнет.

та же проблема.

[root<strong i="6">@docker1</strong> ~]# cat /etc/redhat-release 
CentOS Linux release 7.3.1611 (Core) 
[root<strong i="7">@docker1</strong> ~]# uname  -r
3.10.0-514.26.2.el7.x86_64
[root<strong i="8">@docker1</strong> ~]# docker version
Client:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-1.12.6-32.git88a4867.el7.centos.x86_64
 Go version:      go1.7.4
 Git commit:      88a4867/1.12.6
 Built:           Mon Jul  3 16:02:02 2017
 OS/Arch:         linux/amd64

Server:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-1.12.6-32.git88a4867.el7.centos.x86_64
 Go version:      go1.7.4
 Git commit:      88a4867/1.12.6
 Built:           Mon Jul  3 16:02:02 2017
 OS/Arch:         linux/amd64

Привет,

Я только что создал 2 репозитория https://github.com/piec/docker-samba-loop и https://github.com/piec/docker-nfs-loop, которые содержат необходимые настройки для воспроизведения этой ошибки.

Мои результаты:

• 4.11.3-1-ARCH (Arch Linux) ядро: я генерирую ошибку с docker-samba-loop за несколько итераций (<10). Я не могу воспроизвести это с помощью docker-nfs-loop
• 4.11.9-1-ARCH те же результаты ( версии )
• 4.12.3-1-ARCH (тестирование репо) те же результаты
• 4.11.11-coreos: те же результаты для docker-samba-loop , не пробовал docker-nfs-loop

Надеюсь это поможет
Ваше здоровье

Обходной путь - использовать в моем случае --net=host . Но это не всегда приемлемое решение

@piec , большое спасибо за подробности. В конце этого очень длинного комментария у меня есть к вам еще несколько вопросов.

Используя настройку SMB, я смог произвести ряд вещей с разными ядрами. Я пробовал это с настройкой NFS, но без кубиков.

Все тесты выполняются с помощью docker 17.06.1-ce на HyperKit с виртуальной машиной, настроенной с 2 ​​виртуальными ЦП и 2 ГБ памяти (через Docker для Mac, но это не имеет значения). Я использую ядра LinuxKit, потому что могу легко их заменить.

Я изменил ваш Dockerfile , добавив вызов date в качестве первой выполненной команды, а также добавил вызов date перед и после docker run для клиент.

Эксперимент 1 (ядро 4.9.39)

В версии 4.9.39 (последнее стабильное ядро ​​4.9.x) происходит сбой ядра:

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

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

и в dmesg :

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

Иногда я вижу несколько итераций того, что делает ядро ​​4.11.12, включая сообщения unregister_netdevice (см. Ниже), а затем получаю сбой ядра выше. Иногда я вижу небольшие вариации сбоя, например:

[  715.926694] BUG: unable to handle kernel paging request at 00000000fffffdc9
[  715.927380] IP: [<ffffffff8664ea95>] sk_filter_uncharge+0x5/0x31
[  715.927868] PGD 0 [  715.928022]
[  715.928174] Oops: 0000 [#1] SMP
[  715.928424] Modules linked in:
[  715.928703] CPU: 0 PID: 2665 Comm: runc:[0:PARENT] Not tainted 4.9.39-linuxkit #1
[  715.929321] Hardware name:   BHYVE, BIOS 1.00 03/14/2014
[  715.929765] task: ffff931538ef4140 task.stack: ffffbcbbc0214000
[  715.930279] RIP: 0010:[<ffffffff8664ea95>]  [<ffffffff8664ea95>] sk_filter_uncharge+0x5/0x31
[  715.931043] RSP: 0018:ffffbcbbc0217be0  EFLAGS: 00010206
[  715.931487] RAX: 0000000000000000 RBX: ffff931532a662a8 RCX: 0000000000000006
[  715.932043] RDX: 00000000ffffffff RSI: 00000000fffffdb1 RDI: ffff931532a66000
[  715.932612] RBP: ffff931532a66000 R08: 0000000000000000 R09: 0000000000000000
[  715.933181] R10: ffff9315394f2990 R11: 000000000001bb68 R12: ffff931532a66000
[  715.933725] R13: ffff9315328060a8 R14: ffff931532a66340 R15: 0000000000000000
[  715.934258] FS:  0000000000000000(0000) GS:ffff93153c600000(0000) knlGS:0000000000000000
[  715.934857] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  715.935286] CR2: 00000000fffffdc9 CR3: 0000000052c09000 CR4: 00000000000406b0
[  715.935822] Stack:
[  715.935974]  ffffffff86625054 ffff931532806000 ffffbcbbc0217c58 ffff931532a66000
[  715.936560]  ffffffff8674ed37 0100000800000282 0000000000000000 0000000000000000
[  715.937173]  5de0b9a3a313c00b ffff9315346f5080 ffff9315394f2990 ffff9315346f50b0
[  715.937751] Call Trace:
[  715.937982]  [<ffffffff86625054>] ? __sk_destruct+0x35/0x133
[  715.938608]  [<ffffffff8674ed37>] ? unix_release_sock+0x180/0x212
[  715.939130]  [<ffffffff8674ede2>] ? unix_release+0x19/0x25
[  715.939517]  [<ffffffff8662034c>] ? sock_release+0x1a/0x6c
[  715.939907]  [<ffffffff866203ac>] ? sock_close+0xe/0x11
[  715.940277]  [<ffffffff861f8710>] ? __fput+0xdd/0x17b
[  715.940635]  [<ffffffff860f604d>] ? task_work_run+0x64/0x7a
[  715.941072]  [<ffffffff860e148a>] ? do_exit+0x42a/0x8e0
[  715.941472]  [<ffffffff8674edfa>] ? scm_destroy+0xc/0x25
[  715.941880]  [<ffffffff867504e0>] ? unix_stream_sendmsg+0x2dd/0x30b
[  715.942357]  [<ffffffff860e19aa>] ? do_group_exit+0x3c/0x9d
[  715.942780]  [<ffffffff860eac41>] ? get_signal+0x45d/0x4e2
[  715.943210]  [<ffffffff86621640>] ? sock_sendmsg+0x2d/0x3c
[  715.943618]  [<ffffffff8602055a>] ? do_signal+0x36/0x4c9
[  715.944017]  [<ffffffff861f64c7>] ? __vfs_write+0x8f/0xcc
[  715.944416]  [<ffffffff861f7100>] ? vfs_write+0xbb/0xc7
[  715.944809]  [<ffffffff8600326c>] ? prepare_exit_to_usermode+0x64/0xa4
[  715.945295]  [<ffffffff867d2884>] ? entry_SYSCALL_64_fastpath+0xa7/0xa9
[  715.945789] Code: 08 4c 89 e7 e8 fb f8 ff ff 48 3d 00 f0 ff ff 77 06 48 89 45 00 31 c0 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 1f 44 00 00 <48> 8b 46 18 8b 40 04 48 8d 04 c5 28 00 00 00 f0 29 87 24 01 00
[  715.947701] RIP  [<ffffffff8664ea95>] sk_filter_uncharge+0x5/0x31
[  715.948112]  RSP <ffffbcbbc0217be0>
[  715.948292] CR2: 00000000fffffdc9
[  715.948467] ---[ end trace 2d69bea56725fd5f ]---
[  715.948722] Kernel panic - not syncing: Fatal exception
[  715.949059] Kernel Offset: 0x5000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[  715.949595] Rebooting in 120 seconds..

Сбои в коде сокета домена unix и аналогичны / идентичны тому, что
сообщается здесь , хотя с этим новым тестовым примером его намного легче воспроизвести.

Эксперимент 2 (ядро 4.11.12)

В версии 4.11.12 (которая является последней стабильной версией серии 4.11) я не вижу сбоев, но она очень медленная (аннотации встроены в ---> ):

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

---> First iteration takes one second

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

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

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

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

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

---> Fourth iteration fails after two minutes

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

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

У меня это работало около часа с повторением того же шаблона, но без сбоев ядра.

В журналах ядра я вижу много:

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

Это сообщение каждые десять секунд.

Поскольку это не приводит к срабатыванию обнаружения зависшей задачи даже через час, я подозреваю, что с 4.11.12 счетчик ссылок в конечном итоге уменьшается, и устройство освобождается, но, судя по интервалам, которые я могу запускать контейнеры, это может занять до 4 минут!

Эксперимент 3 (ядро 4.11.12)

Сбой ядра в OP указывал, что ядро ​​разбилось из-за обнаружения зависшей задачи. Я не видел этого сбоя при тестировании, поэтому я изменил параметр sysctl связанный с обнаружением зависшей задачи:

# sysctl -a | grep kernel.hung_task
kernel.hung_task_check_count = 4194304
kernel.hung_task_panic = 0
kernel.hung_task_timeout_secs = 120
kernel.hung_task_warnings = 10
# sysctl -w kernel.hung_task_timeout_secs = 60
# sysctl -w kernel.hung_task_panic=1

Это сокращает время ожидания до 60 секунд и вызывает панику ядра при обнаружении зависшей задачи. Поскольку до того, как dockerd пожаловался, что containerd не запустился, требуется около 2 минут, уменьшение обнаружения зависшей задачи до 60 секунд должно вызвать панику ядра, если одна задача зависла. Увы в логах вылета не было

Эксперимент 4 (ядро 4.11.12)

Затем я увеличиваю sleep после каждого docker run до 5 минут, чтобы проверить, непрерывны ли сообщения. В этом случае все docker run похоже, работают, что вполне ожидаемо, поскольку из предыдущих экспериментов docker run будет работать каждые 4 минуты или около того.

---> This is after the first run
[  281.406660] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  291.455945] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  301.721340] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  311.988572] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  322.258805] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  332.527383] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  342.796511] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  353.059499] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  363.327472] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  373.365562] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  383.635923] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  393.684949] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  403.950186] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  414.221779] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  424.490110] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  434.754925] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  445.022243] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  455.292106] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  465.557462] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  475.826946] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  486.097833] unregister_netdevice: waiting for lo to become free. Usage count = 1

---> 200+ seconds of messages and then nothing for almost 400 seconds

[  883.924399] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  893.975810] unregister_netdevice: waiting for lo to become free. Usage count = 1
...
[ 1088.624065] unregister_netdevice: waiting for lo to become free. Usage count = 1
[ 1098.891297] unregister_netdevice: waiting for lo to become free. Usage count = 1

---> 200+ seconds of messages and then a gap of 90 seconds

[ 1185.119327] unregister_netdevice: waiting for lo to become free. Usage count = 1
[ 1195.387962] unregister_netdevice: waiting for lo to become free. Usage count = 1
...
[ 1390.040035] unregister_netdevice: waiting for lo to become free. Usage count = 1
[ 1400.307359] unregister_netdevice: waiting for lo to become free. Usage count = 1

---> 200+ seconds of messages and then a gap of 80+ seconds

[ 1486.325724] unregister_netdevice: waiting for lo to become free. Usage count = 1
[ 1496.591715] unregister_netdevice: waiting for lo to become free. Usage count = 1
...
[ 1680.987216] unregister_netdevice: waiting for lo to become free. Usage count = 1
[ 1691.255068] unregister_netdevice: waiting for lo to become free. Usage count = 1

---> 200+ seconds of messages and then a gap of 90+ seconds

[ 1787.547334] unregister_netdevice: waiting for lo to become free. Usage count = 1
[ 1797.819703] unregister_netdevice: waiting for lo to become free. Usage count = 1

Похоже, что почти на каждые docker run (кроме второго) мы получаем unregister_netdevice около 200 секунд. Я подозреваю, что в это время мы не можем запускать новые контейнеры (как показывает эксперимент 2. Любопытно, что обнаружение зависшей задачи не срабатывает, предположительно потому, что ни одна задача не зависла.

Эксперимент 5 (4.11.12 / 4.9.39 с дополнительным включением отладки в ядре)

Это возвращается к 1 секунде сна между docker run

У нас есть еще одно ядро, которое включило кучу дополнительных отладок.
параметры, такие как LOCKDEP , RCU_TRACE , LOCKUP_DETECTOR и несколько
более.

Запуск ядер repro 4.11.12 с включенными параметрами отладки ничего не вызвал.

То же самое для ядра 4.9.39, где нормальное ядро ​​вылетает. Параметры отладки немного изменяют время, так что это может быть дополнительным признаком того, что сбой в коде сокета домена unix вызван гонкой.

Копаем немного глубже

strace в различных процессах containerd бесполезен (это
обычно нет, потому что он написан на Go). Много длинных киосков в
futex(...FUTEX_WAIT...) с любой информацией о том, где / почему.

Некоторые ковыряются с sysrq :

Повышение многословности:

echo 9 > /proc/sysrq-trigger

Трассировка стека со всех процессоров:

echo l > /proc/sysrq-trigger
[ 1034.298202] sysrq: SysRq : Show backtrace of all active CPUs
[ 1034.298738] NMI backtrace for cpu 1
[ 1034.299073] CPU: 1 PID: 2235 Comm: sh Tainted: G    B           4.11.12-linuxkit #1
[ 1034.299818] Hardware name:   BHYVE, BIOS 1.00 03/14/2014
[ 1034.300286] Call Trace:
[ 1034.300517]  dump_stack+0x82/0xb8
[ 1034.300827]  nmi_cpu_backtrace+0x75/0x87
[ 1034.301200]  ? irq_force_complete_move+0xf1/0xf1
[ 1034.301633]  nmi_trigger_cpumask_backtrace+0x6e/0xfd
[ 1034.302097]  arch_trigger_cpumask_backtrace+0x19/0x1b
[ 1034.302560]  ? arch_trigger_cpumask_backtrace+0x19/0x1b
[ 1034.302989]  sysrq_handle_showallcpus+0x17/0x19
[ 1034.303438]  __handle_sysrq+0xe4/0x172
[ 1034.303826]  write_sysrq_trigger+0x47/0x4f
[ 1034.304210]  proc_reg_write+0x5d/0x76
[ 1034.304507]  __vfs_write+0x35/0xc8
[ 1034.304773]  ? rcu_sync_lockdep_assert+0x12/0x52
[ 1034.305132]  ? __sb_start_write+0x152/0x189
[ 1034.305458]  ? file_start_write+0x27/0x29
[ 1034.305770]  vfs_write+0xda/0x100
[ 1034.306029]  SyS_write+0x5f/0xa3
[ 1034.306283]  entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 1034.306638] RIP: 0033:0x7fa4810488a9
[ 1034.306976] RSP: 002b:00007fffd3a29828 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 1034.307567] RAX: ffffffffffffffda RBX: 000000c6b523a020 RCX: 00007fa4810488a9
[ 1034.308101] RDX: 0000000000000002 RSI: 000000c6b5239d00 RDI: 0000000000000001
[ 1034.308635] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 1034.309169] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[ 1034.309700] R13: 0000000000000000 R14: 00007fffd3a29988 R15: 00007fa481280ee0
[ 1034.310334] Sending NMI from CPU 1 to CPUs 0:
[ 1034.310710] NMI backtrace for cpu 0 skipped: idling at pc 0xffffffffa0922756

Здесь ничего нет, CPU1 простаивает, CPU0 обрабатывает sysrq.

Показать заблокированные задачи (дважды)

echo w > /proc/sysrq-trigger
[  467.167062] sysrq: SysRq : Show Blocked State
[  467.167731]   task                        PC stack   pid father
[  467.168580] kworker/u4:6    D    0   293      2 0x00000000
[  467.169096] Workqueue: netns cleanup_net
[  467.169487] Call Trace:
[  467.169732]  __schedule+0x582/0x701
[  467.170073]  schedule+0x89/0x9a
[  467.170338]  schedule_timeout+0xbf/0xff
[  467.170666]  ? del_timer_sync+0xc1/0xc1
[  467.171011]  schedule_timeout_uninterruptible+0x2a/0x2c
[  467.171422]  ? schedule_timeout_uninterruptible+0x2a/0x2c
[  467.171866]  msleep+0x1e/0x22
[  467.172155]  netdev_run_todo+0x173/0x2c4
[  467.172499]  rtnl_unlock+0xe/0x10
[  467.172770]  default_device_exit_batch+0x13c/0x15f
[  467.173226]  ? __wake_up_sync+0x12/0x12
[  467.173550]  ops_exit_list+0x29/0x53
[  467.173850]  cleanup_net+0x1a8/0x261
[  467.174153]  process_one_work+0x276/0x4fb
[  467.174487]  worker_thread+0x1eb/0x2ca
[  467.174800]  ? rescuer_thread+0x2d9/0x2d9
[  467.175136]  kthread+0x106/0x10e
[  467.175406]  ? __list_del_entry+0x22/0x22
[  467.175737]  ret_from_fork+0x2a/0x40
[  467.176167] runc:[1:CHILD]  D    0  2609   2606 0x00000000
[  467.176636] Call Trace:
[  467.176849]  __schedule+0x582/0x701
[  467.177152]  schedule+0x89/0x9a
[  467.177451]  schedule_preempt_disabled+0x15/0x1e
[  467.177827]  __mutex_lock+0x2a0/0x3ef
[  467.178133]  ? copy_net_ns+0xbb/0x17c
[  467.178456]  mutex_lock_killable_nested+0x1b/0x1d
[  467.179068]  ? mutex_lock_killable_nested+0x1b/0x1d
[  467.179489]  copy_net_ns+0xbb/0x17c
[  467.179798]  create_new_namespaces+0x12b/0x19b
[  467.180151]  unshare_nsproxy_namespaces+0x8f/0xaf
[  467.180569]  SyS_unshare+0x17b/0x302
[  467.180925]  entry_SYSCALL_64_fastpath+0x1f/0xc2
[  467.181303] RIP: 0033:0x737b97
[  467.181559] RSP: 002b:00007fff1965ab18 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
[  467.182182] RAX: ffffffffffffffda RBX: 0000000002277bd8 RCX: 0000000000737b97
[  467.182805] RDX: 0000000000000000 RSI: 0000000000867a0f RDI: 000000006c020000
[  467.183368] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[  467.184014] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[  467.184639] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[  477.286653] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  487.457828] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  497.659654] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  507.831614] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  518.030241] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  528.232963] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  538.412263] unregister_netdevice: waiting for lo to become free. Usage count = 1
[  548.583610] unregister_netdevice: waiting for lo to become free. Usage count = 1
echo w > /proc/sysrq-trigger
[  553.969592] sysrq: SysRq : Show Blocked State
[  553.970411]   task                        PC stack   pid father
[  553.971208] kworker/u4:6    D    0   293      2 0x00000000
[  553.971686] Workqueue: netns cleanup_net
[  553.972058] Call Trace:
[  553.972305]  __schedule+0x582/0x701
[  553.972690]  schedule+0x89/0x9a
[  553.973039]  schedule_timeout+0xbf/0xff
[  553.973462]  ? del_timer_sync+0xc1/0xc1
[  553.973890]  schedule_timeout_uninterruptible+0x2a/0x2c
[  553.974706]  ? schedule_timeout_uninterruptible+0x2a/0x2c
[  553.975244]  msleep+0x1e/0x22
[  553.975539]  netdev_run_todo+0x173/0x2c4
[  553.975950]  rtnl_unlock+0xe/0x10
[  553.976303]  default_device_exit_batch+0x13c/0x15f
[  553.976725]  ? __wake_up_sync+0x12/0x12
[  553.977121]  ops_exit_list+0x29/0x53
[  553.977501]  cleanup_net+0x1a8/0x261
[  553.977869]  process_one_work+0x276/0x4fb
[  553.978245]  worker_thread+0x1eb/0x2ca
[  553.978578]  ? rescuer_thread+0x2d9/0x2d9
[  553.978933]  kthread+0x106/0x10e
[  553.979283]  ? __list_del_entry+0x22/0x22
[  553.979774]  ret_from_fork+0x2a/0x40
[  553.980244] runc:[1:CHILD]  D    0  2609   2606 0x00000000
[  553.980728] Call Trace:
[  553.980949]  __schedule+0x582/0x701
[  553.981254]  schedule+0x89/0x9a
[  553.981533]  schedule_preempt_disabled+0x15/0x1e
[  553.981917]  __mutex_lock+0x2a0/0x3ef
[  553.982220]  ? copy_net_ns+0xbb/0x17c
[  553.982524]  mutex_lock_killable_nested+0x1b/0x1d
[  553.982909]  ? mutex_lock_killable_nested+0x1b/0x1d
[  553.983311]  copy_net_ns+0xbb/0x17c
[  553.983606]  create_new_namespaces+0x12b/0x19b
[  553.983977]  unshare_nsproxy_namespaces+0x8f/0xaf
[  553.984363]  SyS_unshare+0x17b/0x302
[  553.984663]  entry_SYSCALL_64_fastpath+0x1f/0xc2
[  553.985080] RIP: 0033:0x737b97
[  553.985306] RSP: 002b:00007fff1965ab18 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
[  553.985861] RAX: ffffffffffffffda RBX: 0000000002277bd8 RCX: 0000000000737b97
[  553.986383] RDX: 0000000000000000 RSI: 0000000000867a0f RDI: 000000006c020000
[  553.986811] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[  553.987182] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[  553.987551] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
/ # [  558.844761] unregister_netdevice: waiting for lo to become free. Usage count = 1

Это показывает, что рабочие очереди netns и cleanup_net заняты. Я нашел несколько связанный с этим вопрос в довольно некоторое время назад здесь , но на этот раз cleanup_net workqueue находится в другом состоянии.

Резюме

• Я думаю, что сбой в ядрах 4.9.x не связан, но, похоже, исправлен в 4.11.x. Это требует немного большей сортировки.
• В отличие от некоторых предыдущих отчетов, о зависших задачах не сообщается, но об этом трудно сказать, потому что по этой проблеме очень мало трассировок стека.
• Что-то заблокировано очень долго (2-4 минуты). Вероятно, это связано с состоянием очереди работ
• Дамп рабочей очереди требует дополнительного анализа, в частности, почему рабочая очередь остается в этом состоянии так долго.
• Сообщения unregister_netdev кажутся не связанными с недавним исправлением (которое есть как в 4.9.39, так и в 4.11.12). Это может быть связано с тем, что рабочая очередь cleanup_net обрабатывается, и поэтому сообщение печатается.
• Совершенно неясно, как и почему SMB запускает это. Я написал около 60 с лишним стресс-тестов для сетевых пространств имен и различных рабочих нагрузок и не смог вызвать никаких проблем. Тесты основывались на runc , может, стоит попробовать containerd .

Я покопаюсь еще немного, а затем отправлю сводку на netdev .

@piec, у вас есть доступ к консоли и вы можете видеть, есть ли что-нибудь с точки зрения аварийного дампа, или вы также просто видите огромные задержки, как я вижу? Если у вас есть аварийный дамп, мне было бы очень интересно его увидеть. Кроме того, вы работаете на голом железе или в виртуальной машине? Какая у вас конфигурация с точки зрения процессоров и памяти?

@rn спасибо за исследования!

Я использую металлический настольный компьютер, поэтому у меня есть доступ ко всему. Это i7-4790K + 32 ГиБ.
В настоящее время я использую обновленное ядро ​​Arch Linux + из тестового репозитория (4.12.3-1-ARCH).

В моем случае все работает так, как вы описали в своем эксперименте 2 (ядро 4.11.12):

• После того, как контейнер client-smb существует, запуск новых контейнеров невозможен в течение 4+ минут.
• У меня никогда не было сбоев ядра
• Сообщение unregister_netdevice: waiting for lo to become free. Usage count = 1 появляется повторно, если я пытаюсь запустить любой новый контейнер с задержкой более 4 минут после выхода client-smb. И появляется только в том случае, если вы запускаете новый контейнер за эти 4 минуты. Запуск нового контейнера по истечении этих 4 минут будет "нормальным".

Итак, я полагаю, что где-то в процессе очистки контейнера smb-client возникла проблема, связанная с сетевыми интерфейсами.

На самом деле существует гораздо более простая копия этой проблемы (которая, кстати, не является исходной проблемой).

Этот сценарий просто запускает SMB-сервер на хосте, а затем создает сетевое пространство имен с парой veth , выполняет mount; ls; unmount в сетевом пространстве имен, а затем удаляет сетевое пространство имен.

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

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

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

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

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

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

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

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

Обратите внимание, что добавление простого sleep 1 после размонтирования либо при выполнении в пространстве имен, либо перед удалением сетевого пространства имен работает без остановки при создании нового пространства имен. Сон после удаления старого пространства имен не уменьшает задержки.

@piec Я также проверил это с вашим воспроизведением и sleep 1 в Dockerfile после размонтирования, и все работает, как ожидалось, без остановок, без сообщений unregister_netdev .

Я напишу это сейчас и отправлю на netdev@vger

Превосходно
Я подтверждаю, что сообщение sleep после размонтирования останавливается, а также сообщения unregister_netdev в моей настройке

Вам не кажется, что umount генерирует асинхронное действие относительно своих netns, которое блокирует и, в конечном итоге, истекает время ожидания, если netns удаляется до завершения этого действия? Сон после монтирования позволит этому материалу закончить до того, как netns будет удален.
Но это всего лишь гипотеза

Пробовал без размонтирования, разница такая же. Это удаление сетевого пространства имен. Это 9 и удаление пространства имен mount все равно вызовет размонтирование.

Ах хорошо

Кстати, я по ошибке воспроизвел проблему (при разработке) на другой машине с кем-л. Это ПК с Ubuntu 16.04, Linux 4.4.0-77-generic. И есть обратная трассировка зависшей задачи, которая может быть интересна. Никакого сбоя и такая же задержка ~ 4 минуты.

[6409720.564230] device vethff6396b entered promiscuous mode
[6409720.564415] IPv6: ADDRCONF(NETDEV_UP): vethff6396b: link is not ready
[6409723.844595] unregister_netdevice: waiting for lo to become free. Usage count = 1
[6409726.812872] INFO: task exe:17732 blocked for more than 120 seconds.
[6409726.812918]       Tainted: P           O    4.4.0-77-generic #98-Ubuntu
[6409726.812959] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[6409726.813007] exe             D ffff8809952bbcb8     0 17732      1 0x00000000
[6409726.813013]  ffff8809952bbcb8 ffffffff821d9a20 ffff88103856c600 ffff880ffae2d400
[6409726.813018]  ffff8809952bc000 ffffffff81ef7724 ffff880ffae2d400 00000000ffffffff
[6409726.813021]  ffffffff81ef7728 ffff8809952bbcd0 ffffffff81837845 ffffffff81ef7720
[6409726.813025] Call Trace:
[6409726.813036]  [<ffffffff81837845>] schedule+0x35/0x80
[6409726.813040]  [<ffffffff81837aee>] schedule_preempt_disabled+0xe/0x10
[6409726.813044]  [<ffffffff81839729>] __mutex_lock_slowpath+0xb9/0x130
[6409726.813048]  [<ffffffff818397bf>] mutex_lock+0x1f/0x30
[6409726.813053]  [<ffffffff81726a2e>] copy_net_ns+0x6e/0x120
[6409726.813059]  [<ffffffff810a168b>] create_new_namespaces+0x11b/0x1d0
[6409726.813062]  [<ffffffff810a17ad>] copy_namespaces+0x6d/0xa0
[6409726.813068]  [<ffffffff8107f1d5>] copy_process+0x905/0x1b70
[6409726.813073]  [<ffffffff810805d0>] _do_fork+0x80/0x360
[6409726.813077]  [<ffffffff81080959>] SyS_clone+0x19/0x20
[6409726.813081]  [<ffffffff8183b972>] entry_SYSCALL_64_fastpath+0x16/0x71
[6409733.941041] unregister_netdevice: waiting for lo to become free. Usage count = 1
[6409744.021494] unregister_netdevice: waiting for lo to become free. Usage count = 1

Тема netdev @ vger находится здесь https://www.mail-archive.com/[email protected]/msg179703.html, если кто-то хочет следить за прогрессом.

@piec да, это ожидалось.

Я также столкнулся с этой ошибкой и смог воспроизвести Oopses с помощью метода docker-samba-loop из @piec в образах ядра Ubuntu:

• Linux-образ-4.4.0-93-общий
• Linux-образ-4.10.0-1004-gcp
• Linux-образ-4.10.0-32-общий
• Linux-образ-4.11.0-14-общий
• Linux-образ-4.12.10-041210-generic = 4.12.10-041210.20170830

Я добавил свои выводы в отчет об ошибке Ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407 и https://github.com/fho/docker-samba-loop

@fho спасибо. На самом деле вам вообще не нужен докер для воспроизведения, просто запуск клиента samba в сетевом пространстве имен сделает трюк в соответствии с https://github.com/moby/moby/issues/5618#issuecomment -318681443

@rn спасибо за информацию. Я еще не пробовал.

Последние сообщения здесь и в списке рассылки netdev, похоже, касаются только зависаний ядра.
У меня также происходят сбои ядра с ядром 4.11 и 4.12.

Я вижу проблему, очень похожую на эту (как подробно описано в №35068). Мы в основном запускаем рой из двух узлов, который запускает одну службу с 4 репликами, используя стратегию размещения спреда.

В каждом из этих сервисных контейнеров мы монтируем хост docker.sock как том, а изнутри контейнера выполняем команды docker run с максимальным параллелизмом 4 на контейнер. Это приводит к одновременному созданию до 4 контейнеров, которые сразу же удаляются через -rm .

Дополнительные журналы ядра и примеры на ARMv7 показаны в приведенной выше ссылке.

ip6_route_dev_notify паника - серьезная проблема для нас.

Я думаю, что если посмотреть на это немного подробнее, это определенно НЕ та же ошибка, что и:

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

Я думаю, что это проблема в ядре со слоем ipv6.

Эта информация может быть актуальной.

Мы можем воспроизвести проблему с _unregister_netdevice: ожидание освобождения lo. Счетчик использования = 1_ с ядром 4.14.0-rc3 с _CONFIG_PREEMPT_NONE = y_ и запущенным только на одном процессоре со следующими параметрами загрузки ядра:

BOOT_IMAGE = / boot / vmlinuz-4.14.0-rc3 root = / dev / mapper / vg0-root ro quiet vsyscall = эмулировать nosmp

Как только мы попадаем в это состояние, оно остается в этом состоянии, и требуется перезагрузка. Больше контейнеров не может быть создано. Мы воспроизводим это, запуская изображения, выполняя соединения ipsec / openvpn + загружая небольшой файл внутри туннелей. Тогда экземпляры существуют (обычно они работают <10 секунд). Мы запускаем 10 таких контейнеров в минуту на одной машине. С вышеупомянутыми настройками (только 1 ЦП) машина работает примерно за 2 часа.

Другой репродуктор с тем же ядром, но без ограничения количества процессоров, должен запустить iperf в режиме UDP в течение 3 секунд внутри контейнера (так что TCP-связь отсутствует вообще). Если мы запустим 10 таких контейнеров параллельно, дождемся их завершения и сделаем это снова, мы столкнемся с проблемой менее чем за 10 минут (на машине с 40 ядрами).

В обоих наших репродукторах мы добавили "ip route flush table all; ifconfigвниз; спать 10 дюймов до выхода из контейнеров. Похоже, это не имеет никакого эффекта.

Привет,

Просто чтобы добавить к огню, мы также наблюдаем эту проблему, как и запрошено здесь следующее ...

Версия ядра: Linux exe-v3-worker 4.9.0-3-amd64 # 1 SMP Debian 4.9.30-2 + ​​deb9u5 (2017-09-19) x86_64 GNU / Linux

Дистрибутив / версия Linux: Debian 9.1 (со всеми обновленными пакетами)

Вы используете последнюю версию ядра от вашего поставщика Linux? да

Настройка сети (мост, оверлей, IPv4, IPv6 и т. Д.): Только IPv4, NAT с настройкой Docker по умолчанию

Описание рабочей нагрузки (какой тип контейнеров, какой тип сетевой нагрузки и т. Д.): Контейнеры с очень коротким сроком службы

А в идеале простое воспроизведение:

** ядро: [617624.412100] unregister_netdevice: ожидание освобождения lo. Количество использования = 1

Не удалось убить старый контейнер или запустить новые на затронутых узлах, пришлось перезагрузить для восстановления работоспособности. **

Надеюсь, мы скоро найдем первопричину / исправление.

С уважением,

robputt796

@campbellr
согласился, что это как-то связано с сетевым хранилищем. Я использую ceph krbd в качестве постоянного тома в кубернетах.
И я могу воспроизвести ситуацию после длительного краха контейнера.

Проблема была назначена 10 дней назад, и работа над ней продолжается, вы можете увидеть больше информации о том, что происходит здесь https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407

Надеюсь, Дэн Стритман узнает, как это исправить.

Оказалось, что ошибка вызвана ошибкой ядра, которая была исправлена ​​фиксацией 76da0704507bbc51875013f6557877ab308cfd0a:

ipv6: вызовите ip6_route_dev_notify () только один раз для NETDEV_UNREGISTER

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76da0704507bbc51875013f6557877ab308cfd0a
(Это просто устраняет панику ядра, а не проблему "kernel: unregister_netdevice: ожидание освобождения lo. Usage count = 2".)

(повторяя это здесь снова, потому что GitHub скрывает старые комментарии)

Если вы приедете сюда

Обсуждаемая здесь проблема является ошибкой ядра и еще не устранена полностью. Некоторые исправления вошли в ядро, которые исправляют _некоторые_ вхождения этой проблемы, но другие еще не решены.

Есть несколько вариантов, которые могут помочь _в некоторых_ ситуациях, но не для всех (опять же, это, скорее всего, комбинация проблем, вызывающих одну и ту же ошибку)

Не оставляйте комментарии типа «У меня тоже это есть»

«У меня тоже есть это» не помогает устранить ошибку. оставляйте комментарий только в том случае, если у вас есть информация, которая может помочь решить проблему (в этом случае; предоставление патча для ядра может быть лучшим шагом).

Если вы хотите сообщить, что у вас тоже есть эта проблема, используйте кнопку «палец вверх» в верхнем описании:

Если вы хотите быть в курсе обновлений, используйте кнопку _подписаться_.

Каждый комментарий здесь отправляет электронное письмо / уведомление более чем 3000 человек. Я не хочу блокировать разговор по этому вопросу, потому что он еще не решен, но может быть вынужден, если вы проигнорируете это.

Я буду удалять комментарии, которые не добавляют полезной информации, чтобы (немного) сократить цепочку.

Если вы хотите помочь в решении этой проблемы

• Прочтите всю ветку; он длинный, а github скрывает комментарии (так что вам придется щелкнуть, чтобы они снова стали видимыми). В этой цепочке уже есть много информации, которая могла бы вам помочь.
• Прочтите этот комментарий https://github.com/moby/moby/issues/5618#issuecomment -316297818 (и комментарии того времени) для получения информации, которая может быть полезной.

Спасибо!

Я считаю, что исправил эту проблему, по крайней мере, когда она вызвана подключением к TCP-сокету ядра. Доступны тестовые ядра для Ubuntu, и я хотел бы получить отзывы, если они помогут / исправят это кому-нибудь здесь. Патч отправлен в апстрим; подробности в баге LP:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/comments/46

Извините, что испортил праздник, но нам удалось воспроизвести проблему. Сейчас мы работаем с @ddstreet по адресу https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/ .

Нет ли обходных путей?

Используйте сеть хостов (которая сильно снижает ценность контейнеров, но готово).

@ pumba-lt У нас была эта проблема около 1,5 года назад, около года назад я отключил ipv6 на уровне ядра (не sysctl) и ни разу не столкнулся с этой проблемой. Запуск кластера из 48 лопастей.

Обычно в: /etc/default/grub
GRUB_CMDLINE_LINUX="xxxxx ipv6.disable=1"

Однако я использую загрузку PXE, поэтому моя конфигурация PXE имеет:

      DEFAULT menu.c32
      prompt 0
      timeout 50
      MENU TITLE PXE Boot
      label coreos
              menu label CoreOS
              kernel mykernel
              append initrd=myimage ipv6.disable=1 elevator=deadline cloud-config-url=myurl

Уверяю вас, вы больше не увидите эту проблему.

Всем, пожалуйста, поймите, что это общий СИМПТОМ, имеющий множество причин. То, что помогло вам избежать этого, может не сработать для кого-то другого.

Я могу подтвердить, что наши проблемы были решены после отключения IPv6 при загрузке (конфигурационный файл fron grub). Были многочисленные проблемы в кластере из 7 узлов, теперь работает без сбоев.

Я не помню, где я нашел решение, или я нашел его сам, в любом случае, спасибо @qrpike за то, что предложили это другим :) !!

https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.114

совершить edaafa805e0f9d09560a4892790b8e19cab8bf09
Автор: Дэн Стритмен [email protected]
Дата: 18 января, 16:14:26 2018 -0500

net: tcp: close sock if net namespace is exiting


[ Upstream commit 4ee806d51176ba7b8ff1efd81f271d7252e03a1d ]

When a tcp socket is closed, if it detects that its net namespace is
exiting, close immediately and do not wait for FIN sequence.

For normal sockets, a reference is taken to their net namespace, so it will
never exit while the socket is open.  However, kernel sockets do not take a
reference to their net namespace, so it may begin exiting while the kernel
socket is still open.  In this case if the kernel socket is a tcp socket,
it will stay open trying to complete its close sequence.  The sock's dst(s)
hold a reference to their interface, which are all transferred to the
namespace's loopback interface when the real interfaces are taken down.
When the namespace tries to take down its loopback interface, it hangs
waiting for all references to the loopback interface to release, which
results in messages like:

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

These messages continue until the socket finally times out and closes.
Since the net namespace cleanup holds the net_mutex while calling its
registered pernet callbacks, any new net namespace initialization is
blocked until the current net namespace finishes exiting.

After this change, the tcp socket notices the exiting net namespace, and
closes immediately, releasing its dst(s) and their reference to the
loopback interface, which lets the net namespace continue exiting.

Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=97811
Signed-off-by: Dan Streetman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

Использование SCTP в netns также могло вызвать это, исправления в 4.16-rc1:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a31a6b19f9ddf498c81f5c9b089742b7472a6f8
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=957d761cf91cdbb175ad7d8f5472336a4d54dbf2

все еще происходит «unregister_netdevice: ожидание освобождения eth0. Usage count = 1», хотя я обновил версию ядра до 4.4.118 и версию docker 17.09.1-ce ， может мне стоит попробовать отключить ipv6 на уровне ядра. Надеюсь, это облако сработает.

@ wuming5569, пожалуйста, дайте мне знать, сработало ли это для вас с этой версией Linux

@ wuming5569, возможно, обновите ядро ​​4.4.114, исправьте «unregister_netdevice: ожидание освобождения lo. Usage count = 1», а не «unregister_netdevice: ожидание освобождения eth0. Usage count = 1».
Я тестировал в продакшене.
@ddstreet, это отзыв, помощь?

@ wuming5569, как упоминалось выше, сообщения сами по себе неопасны, но в конечном итоге могут привести к зависанию ядра. Ваше ядро ​​зависает, и если да, то какова ваша модель сети, то есть какой тип сети используют ваши контейнеры?

Возникла такая же проблема с CentOS. У меня ядро ​​3.10.0-693.17.1.el7.x86_64. Но я не получил подобной трассировки стека в системном журнале.

То же самое с ядром Centos7 3.10.0-514.21.1.el7.x86_64 и docker 18.03.0-ce

@danielefranceschi Я рекомендую вам обновить ядро ​​CentOS до последней версии (как минимум 3.10.0-693). Это не решит проблему, но кажется, что это происходит гораздо реже. В ядрах 3.10.0-327 и 3.10.0-514 мы видели трассировку стека, но, насколько мне известно, я не думаю, что мы видели хоть одну из них в 3.10.0-693.

@alexhexabeam 3.10.0-693 вроде работает безупречно, спасибо :)

То же самое с ядром CentOS7 4.16.0-1.el7.elrepo.x86_64 и docker 18.03.0-ce

Он работал несколько недель до сбоя, а когда попытался подняться, он полностью завис.

Проблема также возникла с ядром 3.10.0-693.21.1.el7

Я могу подтвердить, что это также происходит:

Linux 3.10.0-693.17.1.el7.x86_64
Red Hat Enterprise Linux Server версии 7.4 (Maipo)

Я могу воспроизвести это, выполнив «перезапуск докера службы» при определенной нагрузке.

@ wuming5569 вы
У вас есть учетная запись в чате?

4admin2root, с учетом упомянутого вами исправления https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.114 ,

Безопасно ли отключать прокси-сервер пользователя для демона докеров, если установлено правильное последнее ядро? Не очень понятно, откуда это

https://github.com/moby/moby/issues/8356
https://github.com/moby/moby/issues/11185

Поскольку оба старше исправления ядра

Спасибо

нас несколько недель смущала эта проблема.
Linux 3.10.0-693.17.1.el7.x86_64
CentOS Linux версии 7.4.1708 (Core)

Может ли кто-нибудь подтвердить, есть ли эта проблема в последнем ядре 4.14? Похоже, это не так. Никто в Интернете не сталкивался с этой проблемой с ядром 4.14.

Я вижу это в ядре 4.15.15-1, Centos7

Из журналов изменений видно, что https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.15.8 содержит исправление для SCTP, но не для TCP. Так что вы можете попробовать последнюю версию 4.14.

• даже 4.15.18 не помогает с этим багом
• отключение ipv6 тоже не помогает

мы обновились до 4.16.13. Наблюдая. Эта ошибка поражала нас на одном узле примерно раз в неделю.

Вы отключили ipv6 в параметрах загрузки grub или sysctl? Только параметры загрузки будут работать. Sysctl не исправит.

4 июня 2018 года в 12:09:53 Сергей Пронин ( [email protected] (mailto: [email protected])) написал:

даже 4.15.18 не помогает с этим багом
отключение ipv6 тоже не помогает

мы обновились до 4.16.13. Наблюдая. Эта ошибка поражала нас на одном узле примерно раз в неделю.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub (https://github.com/moby/moby/issues/5618#issuecomment-394410321) или отключите поток (https://github.com/notifications/unsubscribe-auth / AAo3HLYI_jnwjgtQ0ce-E4mc6Em5yeISks5t5VvRgaJpZM4B4L4Z).

для меня в большинстве случаев ошибка появляется после повторного развертывания того же проекта / сети

@qrpike вы правы, мы пробовали только sysctl. Позвольте мне попробовать с grub. Спасибо!

4.9.88 Ядро Debian. Воспроизводимый.

@qrpike вы правы, мы пробовали только sysctl. Позвольте мне попробовать с grub. Спасибо!

В моем случае отключение ipv6 не имело никакого значения.

@ spronin-aurea Помогло ли отключение ipv6 при загрузчике?

@qrpike, можете ли вы рассказать нам об используемых вами узлах, если отключение ipv6 помогло в вашем случае? Версия ядра, версия k8s, CNI, версия докера и т. Д.

@komljen Я использую CoreOS последние 2 года без единого инцидента. Начиная с ~ ver 1000. Я не пробовал это в последнее время, но если я не отключу ipv6, произойдет ошибка.

Со своей стороны, я тоже использую CoreOS, ipv6 отключен с помощью grub, но проблема все еще возникает.

@deimosfr В настоящее время я использую загрузку PXE для всех своих узлов:

      DEFAULT menu.c32
      prompt 0
      timeout 50
      MENU TITLE PXE Boot Blade 1
      label coreos
              menu label CoreOS ( blade 1 )
              kernel coreos/coreos_production_pxe.vmlinuz
              append initrd=coreos/coreos_production_pxe_image.cpio.gz ipv6.disable=1 net.ifnames=1 biosdevname=0 elevator=deadline cloud-config-url=http://HOST_PRIV_IP:8888/coreos-cloud-config.yml?host=1 root=LABEL=ROOT rootflags=noatime,discard,rw,seclabel,nodiratime

Однако мой основной узел, который является хостом PXE, также является CoreOS и загружается с диска, и это тоже не проблема.

Какие версии ядра вы используете?

Те, которые у меня возникли, были на 4.14.32-coreos и ранее. Я пока не сталкиваюсь с этой проблемой на 4.14.42-coreos

Centos 7.5 с ядром 4.17.3-1, проблема все еще не устранена.

Env:
кубернетес 1.10.4
Докер 13.1
с плагином Flannel network.

Бревно :
[89.790907] IPv6: ADDRCONF (NETDEV_UP): eth0: ссылка не готова
[89.798523] IPv6: ADDRCONF (NETDEV_CHANGE): eth0: ссылка становится готовой
[89.799623] cni0: порт 8 (vethb8a93c6f) вошел в состояние блокировки
[89.800547] cni0: порт 8 (vethb8a93c6f) перешел в отключенное состояние
[89.801471] устройство vethb8a93c6f перешло в неразборчивый режим
[89.802323] cni0: порт 8 (vethb8a93c6f) вошел в состояние блокировки
[89.803200] cni0: порт 8 (vethb8a93c6f) вошел в состояние пересылки

ядро: unregister_netdevice : ждет, пока lo станет свободным. Количество использований = 1。

Теперь :
IP-адрес узла может достигать, но не может использовать какие-либо сетевые службы, такие как ssh ...

Симптомы здесь аналогичны множеству сообщений в различных других местах. Все связано с сетевыми пространствами имен. Могут ли люди, столкнувшиеся с этим, посмотреть, зависает ли unshare -n , и если да, то с другого терминала выполните cat /proc/$pid/stack процесса отмены общего доступа, чтобы увидеть, зависает ли он в copy_net_ns() ? Кажется, это общий знаменатель для многих проблем, в том числе для некоторых найденных здесь следов. Между 4.16 и 4.18 было выпущено несколько патчей Кирилла Тхая, в значительной степени реорганизовавших блокировку. Сопровождающие затронутых пакетов дистрибутива / ядра, вероятно, должны изучить возможность их применения / обратного переноса в стабильные ядра и посмотреть, поможет ли это.
См. Также: 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

Учитывая изменения блокировки в 4.18, было бы хорошо протестировать текущую версию 4.18rc, особенно если вы можете запускать ее более или менее надежно, поскольку из того, что я видел, есть много людей, у которых изменение версии ядра также изменило вероятность этого. много.

У меня были проблемы с Kubernetes, и после перехода на последнюю стабильную версию CoreOS - 1745.7.0 проблема исчезла:

• ядро: 4.14.48
• докер: 18.03.1

такая же проблема на CentOS 7

• ядро: 4.11.1-1.el7.elrepo.x86_64
• докер: 17.12.0-ce

@Blub То же самое на CoreOS 1688.5.3, ядре 4.14.32

ip-10-72-101-86 core # cat /proc/59515/stack
[<ffffffff9a4df14e>] copy_net_ns+0xae/0x200
[<ffffffff9a09519c>] create_new_namespaces+0x11c/0x1b0
[<ffffffff9a0953a9>] unshare_nsproxy_namespaces+0x59/0xb0
[<ffffffff9a07418d>] SyS_unshare+0x1ed/0x3b0
[<ffffffff9a003977>] do_syscall_64+0x67/0x120
[<ffffffff9a800081>] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[<ffffffffffffffff>] 0xffffffffffffffff

Теоретически где-то может быть одна или несколько других трассировок, содержащих одну из функций из net_namespace.c, блокирующих net_mutex ( cleanup_net , net_ns_barrier , net_ns_init , {,un}register_pernet_{subsys,device} ). Для стабильных ядер, конечно, было бы намного проще, если бы была одна конкретная проблема, которая могла бы быть исправлена, чем перенос всех изменений блокировок из 4.18. Но пока я не видел следов, ведущих к первопричине. Не знаю, поможет ли это, но, может быть, при появлении проблемы будут видны другие /proc/*/stack с указанными выше функциями?

такая же проблема! а мой env - debian 8

RHEL, SWARM, 18.03.0-в.

1. Подключение к управляющему узлу через ssh

2. Запуск контейнера на управляющем узле вручную:

   sudo docker run -it -v / import: / temp / eximport -v / home / myUser: / temp / exhome docker.repo.myHost / fedora: 23 / bin / bash

3. Через некоторое время бездействие:

   [ root @ 8a9857c25919 myDir] #
   Сообщение от syslogd @ se1-shub-t002 в 19 ​​июля, 11:56:03 ...
   ядро: unregister_netdevice : ждет, пока lo станет свободным. Количество использования = 1

Через несколько минут я снова нахожусь на консоли узла менеджера, и запущенный контейнер больше не работает.

Это описывает ту же проблему или это еще один «набор проблем»?

THX заранее!

ОБНОВИТЬ
Это также происходит непосредственно в консоли ssh (в диспетчере роя bash).

ОБНОВИТЬ
Хост-машина (один управляющий узел в рое):
Linux [MACHINENNAME] 3.10.0-514.2.2.el7.x86_64 # 1 SMP среда, 16 ноября 13:15:13 EST 2016 x86_64 x86_64 x86_64 GNU / Linux

Если через некоторое время это не решится, значит, это другая проблема.

То же самое с ядром CentOS7.5 3.10.0-693.el7.x86_64 и docker 1.13.1

Та же проблема OEL 7.5
uname -a
4.1.12-124.16.1.el7uek.x86_64 # 2 SMP Mon Jun 11 20:09:51 PDT 2018 x86_64 x86_64 x86_64 GNU / Linux
информация о докере
Контейнеров: 9
Бег: 5
Приостановлено: 0
Остановлено: 4
Фото: 6
Версия сервера: 17.06.2-ol

dmesg
[2238374.718889] unregister_netdevice: ожидание освобождения Ло. Количество использования = 1
[2238384.762813] unregister_netdevice: ожидание освобождения Ло. Количество использования = 1
[2238392.792585] eth0: переименован в vethbed6d59

(повторяя это https://github.com/moby/moby/issues/5618#issuecomment-351942943 здесь снова, потому что GitHub скрывает старые комментарии)

Если вы приедете сюда

Обсуждаемая здесь проблема является ошибкой ядра и еще не устранена полностью. Некоторые исправления вошли в ядро, которые исправляют _некоторые_ вхождения этой проблемы, но другие еще не решены.

Есть несколько вариантов, которые могут помочь _в некоторых_ ситуациях, но не для всех (опять же, это, скорее всего, комбинация проблем, вызывающих одну и ту же ошибку)

Ошибка "unregister_netdevice: ожидание освобождения lo" не является ошибкой.

Если происходит сбой ядра _ после_, это ошибка (см. Ниже)

Не оставляйте комментарии типа «У меня тоже это есть»

«У меня тоже есть это» не помогает устранить ошибку. оставляйте комментарий только в том случае, если у вас есть информация, которая может помочь решить проблему (в этом случае; предоставление патча для ядра может быть лучшим шагом).

Если вы хотите сообщить, что у вас тоже есть эта проблема, используйте кнопку «палец вверх» в верхнем описании:

Если вы хотите быть в курсе обновлений, используйте кнопку _подписаться_.

Каждый комментарий здесь отправляет электронное письмо / уведомление более чем 3000 человек. Я не хочу блокировать разговор по этому вопросу, потому что он еще не решен, но может быть вынужден, если вы проигнорируете это.

Я буду удалять комментарии, которые не добавляют полезной информации, чтобы (немного) сократить цепочку.

Если вы хотите помочь в решении этой проблемы

• Прочтите всю ветку, включая те комментарии, которые скрыты ; он длинный, а github скрывает комментарии (так что вам придется щелкнуть, чтобы они снова стали видимыми). В этой цепочке уже есть много информации, которая могла бы вам помочь.

• Прочтите этот комментарий https://github.com/moby/moby/issues/5618#issuecomment -316297818 (и комментарии того времени) для получения информации, которая может быть полезной:

Чтобы быть ясным, само сообщение является доброкачественным , это сбой ядра после сообщений, сообщенных OP, а это не так.

Комментарий в коде, откуда пришло это сообщение, объясняет, что происходит. Практически каждый пользователь, например IP-стек) сетевого устройства (например, конец пары veth внутри контейнера) увеличивает счетчик ссылок в структуре сетевого устройства, когда он использует сетевое устройство. Когда устройство удаляется (например, когда удаляется контейнер), каждый пользователь уведомляется, чтобы он мог выполнить некоторую очистку (например, закрыть открытые сокеты и т. Д.) Перед уменьшением счетчика ссылок. Поскольку эта очистка может занять некоторое время, особенно при больших нагрузках (Лот интерфейса, много соединений и т.д.), ядро может напечатать сообщение здесь раз в то время.

Если пользователь сетевого устройства никогда не уменьшает счетчик ссылок, какая-то другая часть ядра определит, что задача, ожидающая очистки, зависла, и произойдет сбой. Только этот сбой указывает на ошибку ядра (какой-то пользователь с помощью некоторого пути кода не уменьшил счетчик ссылок). Было несколько таких ошибок, и они были исправлены в современном ядре (и, возможно, были перенесены обратно на более старые). Я написал довольно много стресс-тестов (и продолжаю их писать), чтобы вызвать такие сбои, но не смог воспроизвести их на современных ядрах (тем не менее, это сообщение выше).

* Пожалуйста, сообщайте об этой проблеме только в том случае, если ваше ядро ​​действительно дает сбой *, и тогда нам будет очень интересно:

• версия ядра (вывод uname -r )
• Дистрибутив / версия Linux
• Вы используете последнюю версию ядра от вашего поставщика Linux?
• Настройка сети (мост, оверлей, IPv4, IPv6 и т. Д.)
• Описание нагрузки (какой тип контейнеров, какой тип сетевой нагрузки и т. Д.)
• А в идеале простое воспроизведение

Спасибо!

Ребята, вы работаете с докером без каких-либо ограничений? Например, ulimits, cgroups и т. Д.

более новая systemd имеет ограничение по умолчанию, даже если вы его не устанавливали. Я установил неограниченный доступ, и с тех пор проблемы не возникало (смотрю с 31 дня).

У меня была такая же проблема во многих средах, и моим решением было остановить брандмауэр. Этого больше не случилось, пока

Rhel 7.5 - 3.10.0-862.3.2.el7.x86_64
Докер 1.13

@dElogics Какая версия systemd считается «более новой»? Включено ли это ограничение по умолчанию в системе CentOS 7.5?

Кроме того, когда вы спрашиваете, запускаем ли мы docker с какими-либо ограничениями, вы имеете в виду демон docker или отдельные контейнеры?

Демон докера. Система как в Debian 9 (232-25).

Не уверен насчет RHEL, но я лично видел эту проблему и в RHEL. Я бы установил LimitNOFILE = 1048576, LimitNPROC = infinity, LimitCORE = infinity, TasksMax = infinity

ядро: unregister_netdevice: ожидание освобождения eth0. Количество использования = 3
ядро 4.4.146-1.el7.elrepo.x86_64
версия linux CentOS Linux выпуск 7.4.1708 (Core)
мостовой режим

У меня была такая же проблема, что мне делать?

Та же проблема:

CentOS Linux версии 7.5.1804 (Core)
Докер версии 18.06.1-ce, сборка e68fc7a
Версия ядра: 3.10.0-693.el7.x86_64

Похожая проблема, с которой я столкнулся здесь ...
Могу ли я выполнить какие-нибудь движения прямо сейчас? Пожалуйста, помогите мне ...

CentOS 7.0.1406
[ root @ zjsm-slavexx и т. д.] # uname -a
Linux zjsm-slave08 3.10.0-123.el7.x86_64 # 1 SMP Понедельник, 30 июня, 12:09:22 UTC 2014 x86_64 x86_64 x86_64 GNU / Linux
[ root @ zjsm-slavexx и т. д.] # cat / etc / centos-release
CentOS Linux, выпуск 7.0.1406 (Core)

Информация о докере:
[ root @ zjsm-slavexx ~] # версия докера
Клиент:
Версия: 17.04.0-ce
Версия API: 1.28
Версия Go: go1.7.5
Git commit: 4845c56
Построен: 3 апр, пн, 18:01:50, 2017
ОС / Arch: Linux / amd64

Сервер:
Версия: 17.04.0-ce
Версия API: 1.28 (минимальная версия 1.12)
Версия Go: go1.7.5
Git commit: 4845c56
Построен: 3 апр, пн, 18:01:50, 2017
ОС / Arch: Linux / amd64
Экспериментальный: ложь

CentOS Linux, выпуск 7.2.1511, ядро: 3.10.0-327.el7.x86_64
та же проблема

Я экспериментировал с этой проблемой.

Ubuntu 16.04.3 LTS
Kernel 4.4.0-87-generic #110-Ubuntu SMP Tue Jul 18 12:55:35 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Docker version:
Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:42:18 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:56 2017
 OS/Arch:      linux/amd64
 Experimental: false

@thaJeztah , возможно, вам стоит добавить свой комментарий в начало исходного сообщения, поскольку люди все еще игнорируют его.

$ docker network ls
NETWORK ID          NAME                     DRIVER              SCOPE
b3fc47abfff2        bridge                   bridge              local
f9474559ede8        dockerfile_cluster_net   bridge              local
ef999de68a96        host                     host                local
e7b41d23674c        none                     null                local
$ docker network rm f9474559ede8 

починил это.

@hzbd Вы имеете в виду удалить определяемую пользователем мостовую сеть? Пытались ли вы копать дальше, чтобы узнать, почему? Пожалуйста, дайте мне знать, если вы это сделали. Я действительно ценю это.

В ожидании исправления

Ребята, вы работаете с докером без каких-либо ограничений? Например, ulimits, cgroups и т. Д.

более новая systemd имеет ограничение по умолчанию, даже если вы его не устанавливали. Я установил неограниченный доступ, и с тех пор проблемы не возникало (смотрю с 31 дня).

Хорошо, эта ошибка все еще возникает, но вероятность уменьшилась.

Думаю, если контейнеры изящно останавливаются (PID 1 exists () s), то эта ошибка нас не побеспокоит.

@dElogics, спасибо, что

@dElogics, спасибо, что

Вам нужно изменить модуль docker systemd. Модуль systemd, который я использую (только соответствующие части) -

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target docker.socket firewalld.service flannel.service
Wants=network-online.target
Requires=docker.socket

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker

ExecReload=/bin/kill -s HUP $MAINPID
LimitNOFILE=1048576
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNPROC=infinity
LimitCORE=infinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this version.
TasksMax=infinity
TimeoutStartSec=0
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
# kill only the docker process, not all processes in the cgroup
KillMode=process
# restart the docker process if it exits prematurely
Restart=on-failure
StartLimitBurst=3
StartLimitInterval=60s

[Install]
WantedBy=multi-user.target

Была ли у кого-нибудь эта проблема в ядре 4.15 или новее?

Это исправление Дэна Стритмена (https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d) сначала включено в версию ядра 4.15, и кажется, что по крайней мере для кого-то этого больше не происходит с момента обновления до 4.16 (https: / /github.com/kubernetes/kubernetes/issues/64743#issuecomment-436839647)

Кто-нибудь пробовал?

@victorgp У нас все еще есть проблема с ядром 4.15. Мы сообщим здесь, когда будем тестировать ядро ​​4.16 (надеюсь, через несколько недель).

Несколько месяцев мы использовали версию ядра

Чтобы добавить к моим предыдущим решениям - изящная остановка контейнеров (которые реагируют на SIGTERM) никогда не запускает это.

Также попробуйте запустить контейнеры в пространстве имен хоста (если это приемлемо для вас), что полностью решит проблему.

@dElogics Что вы подразумеваете под «пространством имен хоста»? Это просто --privileged ?

@dElogics Что вы подразумеваете под «пространством имен хоста»? Это просто --privileged ?

Нет, это означает --network = host

После обновления ядра 4.4.0 до 4.15.0 и докера 1.11.2 до 18.09 проблема исчезла.

В большом парке виртуальных машин, выступающих в качестве хостов докеров, эта проблема возникала несколько раз в день (с нашим вариантом использования Docker).
Прошло 45 дней, а мы этого больше не видим.

Для потомков трассировку стека зависшего Docker 1.11.2 с printk, показывающего unregister_netdevice: waiting for vethXXXXX (аналогично тому, что мы всегда видели в нашем парке, в сотнях виртуальных машин), можно найти по адресу 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

Из этого мы можем заметить, что он завис в https://github.com/moby/moby/blob/v1.11.2/daemon/container_operations.go#L732

что указывает на https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/sandbox.go#L175

А также
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/endpoint.go#L760

Что входит в драйвер моста libnetwork (проверьте потрясающее описание)
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go#L1057 -L1061

Переход на netlink
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go#L601 -L617
https://github.com/moby/moby/blob/v1.11.2//vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go#L215

И в конечном итоге в этом сокете netlink вызывает https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go#L333

Мы считаем, что ошибка обычно возникает при остановке контейнера, и из-за того, что SKB все еще упоминаются в netns, veth не выпускается, а затем Docker выдает Kill этому контейнеру через 15 секунд. Демон Docker не справляется с этой ситуацией должным образом, но в конечном итоге ошибка находится в ядре. Мы считаем, что https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d (принимается в апстриме 4.15) и связанные с ним коммиты (их несколько) действуют как смягчение.

В общем, эта часть ядра - не самое приятное место.

Как бы то ни было ... мы обновили ядро ​​RHEL Linux с 3.10.0 до 4.17.11. (Запуск кластера Kubernetes). До обновления эта ошибка возникала ежедневно несколько раз на разных серверах. Работает с обновлением уже три недели. Ошибка произошла только один раз. Так примерно на 99% меньше.

@marckamerbeek Вы обновили ядро ​​RHEL до ядра сообщества? Тогда это больше не поддерживается.

Пользователь @Beatlor CentOS может это сделать.

В centos 7.2 все еще есть эта проблема: kernel: unregister_netdevice : ждет, пока lo освободится. Количество использования = 1

@Beatlor RHEL нам совсем не помог. Стабильная производственная среда важнее бесполезного контракта на поддержку. Мы все еще работаем очень стабильно на 4.17.11. Больше нет больших проблем.

@Beatlor RHEL нам совсем не помог. Стабильная производственная среда важнее бесполезного контракта на поддержку. Мы все еще работаем очень стабильно на 4.17.11. Больше нет больших проблем.

Да, у меня тоже не было этой проблемы после обновления ядра до 4.17.0-1.el7.elrepo.x86_64. Я пробовал это раньше (4.4.x, 4.8, 4.14 ..), и это не удалось. Похоже, в ядре 4.17+ проблема больше не возникнет.

В centos 7.2 все еще есть эта проблема: kernel: unregister_netdevice : ждет, пока lo освободится. Количество использования = 1

Вы можете попробовать обновить ядро ​​до последней версии 4.19+.

Просто подождите несколько месяцев, и кто-нибудь придет и пожалуется на ядро ​​4.19. Просто история повторяется.

Всем привет, хорошие новости!

С момента моего последнего комментария здесь (на момент написания, 17 дней назад) у меня больше не было этих ошибок. Мои серверы (около 30 из них) работали под управлением Ubuntu 14.04 с некоторыми устаревшими пакетами.

После полного обновления системы, включая docker-engine (с 1.7.1 до 1.8.3) + обновление ядра до последней возможной версии в репозитории ubuntu, мои серверы работают без каких-либо проблем.

🎱

какую версию ядра вы обновляете?

может быть связано с этим https://github.com/torvalds/linux/commit/f186ce61bb8235d80068c390dc2aad7ca427a4c2

Вот попытка резюмировать эту проблему из комментариев к этой проблеме, https://github.com/kubernetes/kubernetes/issues/70427 , https://github.com/kubernetes/kubernetes/issues/64743 и https: //access.redhat.com/solutions/3659011

Наблюдаемые версии ядра с этой проблемой

• RHEL7 3.10.0-862
• 4.15.0
• 4.20.0

Заявленные версии ядра не вызывают этой проблемы

• RHEL7 3.10.0-957.10.1
• 4.19.12
• 4.17.0
• 4.17.11

Связанные коммиты ядра

• https://github.com/torvalds/linux/commit/f186ce61bb8235d80068c390dc2aad7ca427a4c2 - с 4.12
• https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d - с 4.15
• https://github.com/torvalds/linux/commit/ee60ad219f5c7c4fb2f047f88037770063ef785f - начиная с версии 5.1

Я бросаю вызов https://github.com/kubernetes/kubernetes/issues/70427#issuecomment -470681000, поскольку мы не видели это с тысячами виртуальных машин в версии 4.15.0, в то время как в версии 4.4 мы наблюдали ее десятки раз в день. 0, в 4.15.0 есть еще сообщения об этом?

Я наблюдаю эту проблему с одной из моих машин, на которой работает Docker на Debian 9 Stretch ( 4.9.0-8-amd64 ). У меня возникла эта проблема с туннелем, созданным в контейнере Docker через Docker Gen, и он вызывает панику ядра:

Message from syslogd<strong i="7">@xxxx</strong> at Apr 29 15:55:41 ...
 kernel:[719739.507961] unregister_netdevice: waiting for tf-xxxxxxxx to become free. Usage count = 1

Вот наша информация о Docker:

Client:
 Version:           18.09.3
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        774a1f4
 Built:             Thu Feb 28 06:34:04 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.3
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.8
  Git commit:       774a1f4
  Built:            Thu Feb 28 05:59:55 2019
  OS/Arch:          linux/amd64
  Experimental:     false

Кто-нибудь знает, есть ли временное исправление этого без перезапуска всей машины? Мы действительно предпочли бы не перезагружать всю машину, когда у нас возникнет эта проблема.

В некоторой степени не по теме, мы также не можем подавить сообщения о панике ядра в терминале. Я пробовал dmesg -D и dmesg -n 1 . Однако не повезло. Есть ли способ подавить этот тип сообщений о панике ядра из терминала? Досадно пытаться вводить команды, и это сообщение появляется каждые 10 секунд или около того.

Спасибо.

Это ванильные ядра или сильно пропатчены дистрибутивами с исправлениями с обратным переносом?

@pmoust Я вижу это в ubuntu 4.15.0-32 примерно раз в неделю. определенно намного лучше по сравнению с 4.4.0

@iavael, я

Кто-нибудь видел этот баг с 4.19?

Кто-нибудь видел этот баг с 4.19?

https://github.com/kubernetes/kubernetes/issues/64743#issuecomment -451351435
https://github.com/kubernetes/kubernetes/issues/64743#issuecomment -461772385

Эта информация может быть вам полезна.

@tankywoo @drpancake @egasimus @csabahenk @spiffytech @ibuildthecloud @sbward @jbalonso @rsampaio @MrMMorris @rsampaio @unclejack @chrisjstevenson @popsikle @fxposter @ scher200 @victorgp @jstangroome @ Xuexiang825 @dElogics @Nowaker @pmoust @marckamerbeek @Beatlor @warmchang @Jovons @ 247687009 @jwongz @ tao12345666333 @clkao Пожалуйста, посмотрите это 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 Пожалуйста, посмотрите это https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs- while- testing- tidb- operator- in- k8s/

Я выполнил документацию, но все равно получаю сообщение об ошибке.

[root<strong i="39">@node1</strong> ~]# kpatch list
Loaded patch modules:
livepatch_route [enabled]

Installed patch modules:
[root<strong i="40">@node1</strong> ~]#
Message from syslogd<strong i="41">@node1</strong> at May  7 15:59:11 ...
 kernel:unregister_netdevice: waiting for eth0 to become free. Usage count = 1

Само по себе это сообщение не является ошибкой; после этого происходит сбой ядра; https://github.com/moby/moby/issues/5618#issuecomment -407751991

@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 Пожалуйста, посмотрите это https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs- while- testing- tidb- operator- in- k8s/

Я выполнил документацию, но все равно получаю сообщение об ошибке.

[root<strong i="40">@node1</strong> ~]# kpatch list
Loaded patch modules:
livepatch_route [enabled]

Installed patch modules:
[root<strong i="41">@node1</strong> ~]#
Message from syslogd<strong i="42">@node1</strong> at May  7 15:59:11 ...
 kernel:unregister_netdevice: waiting for eth0 to become free. Usage count = 1

После перезагрузки ок ···

@ vincent927 Кстати ， Вы должны поместить livepatch_route.ko в / var / lib / kpatch / $ (uname -r), при включении kpatch.service, ko может автоматически загружаться после перезагрузки.

Мы внезапно получили это в нашей компании сегодня в нескольких кластерах кубернетов.

• uname -a :
  Linux ip-10-47-17-58 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux

• docker version :

  Client:
   Version:           18.09.5
   API version:       1.39
   Go version:        go1.10.8
   Git commit:        e8ff056dbc
   Built:             Thu Apr 11 04:44:28 2019
   OS/Arch:           linux/amd64
   Experimental:      false
  
  Server: Docker Engine - Community
   Engine:
    Version:          18.09.2
    API version:      1.39 (minimum version 1.12)
    Go version:       go1.10.6
    Git commit:       6247962
    Built:            Sun Feb 10 03:42:13 2019
    OS/Arch:          linux/amd64
    Experimental:     false
  

• kubectl version (сервер):
  Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.2", GitCommit:"cff46ab41ff0bb44d8584413b598ad8360ec1def", GitTreeState:"clean", BuildDate:"2019-01-10T23:28:14Z", GoVersion:"go1.11.4", Compiler:"gc", Platform:"linux/amd64"}

Мы еще не знаем причины; мы использовали эти версии вышеуказанного программного обеспечения в течение нескольких месяцев без каких-либо проблем. Я просто комментирую, чтобы добавить на данный момент список «версий программного обеспечения, в которых наблюдается эта ошибка».

@ 2rs2ts Вы пробовали https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs- while-testing-tidb-operator-in-k8s/ ?

@ethercflow Я читал это, но, поскольку мы запускаем Debian в моей компании, для нас

@ethercflow @ 2rs2ts мы также используем debian. Я столкнулся с множеством проблем, пытаясь заставить kpatch-build работать. Если мне удастся найти обходной путь, я буду держать вас в курсе. В любом случае, есть ли у кого-нибудь другое решение? Версия ядра 4.15 или 4.19 решает проблему? Я пытался найти ответ на протяжении прошлой недели и до сих пор не смог.

@commixon, наш опыт остается таким же, как описано в https://github.com/moby/moby/issues/5618#issuecomment -455800975, для парка из тысяч виртуальных машин повторного возникновения проблемы с 4.15.0 на общие, оптимизированные для AWS и GCP разновидности ядер, предоставляемые Canonical. Ограниченный тест на vanilla 4.15.0 также не выявил ни одной из этих проблем, но не тестировался в масштабе.

Большое спасибо @pmoust . Попробую их. В любом случае я также попытаюсь исправить kpatch для работы с Debian (в качестве побочного проекта) и публиковать здесь обновления для всех, кого это интересует.

@ethercflow @ 2rs2ts мы также используем debian. Я столкнулся с множеством проблем, пытаясь заставить kpatch-build работать. Если мне удастся найти обходной путь, я буду держать вас в курсе. В любом случае, есть ли у кого-нибудь другое решение? Версия ядра 4.15 или 4.19 решает проблему? Я пытался найти ответ на протяжении прошлой недели и до сих пор не смог.

Вы можете перейти на версию 4.19. Это в бэкпорте.

Кстати, для нас это был год. ;)

На самом деле мы пробовали 4.19 в бэкпортах, но у него были некоторые серьезные регрессы в других областях (экземпляры EC2 просто случайным образом перезагружались, а затем сеть при запуске ломалась). Думаю, нам придется иметь дело с этим до следующей стабильной версии.

@ 2rs2ts Последние 4 дня мы используем 4.19 из бэкпортов (в EC2), и мы не наблюдали никаких проблем. Проблема с аварийным завершением работы ядра не возникла вообще, и все остальное тоже в порядке. Я не верю, что это имеет значение, но мы основали наш образ Debian на образе, предоставленном kops (https://github.com/kubernetes/kops/blob/master/docs/images.md#debian). Мы обновили ядро ​​в этом образе, а не стандартный debian.

Друзья, уже пол года использую ядро ​​4.19 для стабильной работы. Надеюсь, вам тоже понравится стабильность.

У меня есть контейнер, открывающий порт 80 и 443, каждые 2 недели из другого контейнера доступа к компьютеру 80 и
443 - это отрицать

Версия ядра centos7.3:
Браузер Linux1 3.10.0-514.el7.x86_64 # 1 SMP Вт 22 ноября 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux

root @ browser1 ~] # версия докера
Клиент:
Версия: 18.06.3-ce
Версия API: 1.38
Версия Go: go1.10.4
Git commit: d7080c1
Построен: 20 фев, среда, 02:24:22 2019
ОС / Arch: Linux / amd64
Экспериментальный: ложь

Сервер:
Двигатель:
Версия: 18.06.3-ce
Версия API: 1.38 (минимальная версия 1.12)
Версия Go: go1.10.3
Git commit: d7080c1
Построен: Ср 20 фев, 02:25:33 2019
ОС / Arch: Linux / amd64
Экспериментальный: ложь
[ root @ browser1 ~] #

dmesg:

[1063959.636785] unregister_netdevice: ожидание освобождения Ло. Количество использования = 1
[1071340.887512] br-af29e1edc1b8: порт 5 (vethc2ac4f8) перешел в отключенное состояние
[1071340.891753] br-af29e1edc1b8: порт 5 (vethc2ac4f8) перешел в отключенное состояние
[1071340.895118] устройство vethc2ac4f8 вышло из неразборчивого режима
[1071340.895138] br-af29e1edc1b8: порт 5 (vethc2ac4f8) перешел в отключенное состояние
[1071340.990505] Устройство veth5e4f161 перешло в неразборчивый режим
[1071340.990897] IPv6: ADDRCONF (NETDEV_UP): veth5e4f161: ссылка не готова
[1071340.990904] br-af29e1edc1b8: порт 5 (veth5e4f161) вошел в состояние пересылки
[1071340.990924] br-af29e1edc1b8: порт 5 (veth5e4f161) вошел в состояние пересылки
[1071341.231405] IPv6: ADDRCONF (NETDEV_CHANGE): veth5e4f161: ссылка становится готовой
[1071355.991701] br-af29e1edc1b8: порт 5 (veth5e4f161) вошел в состояние пересылки
[1071551.533907] br-af29e1edc1b8: порт 5 (veth5e4f161) перешел в отключенное состояние
[1071551.537564] br-af29e1edc1b8: порт 5 (veth5e4f161) перешел в отключенное состояние
[1071551.540295] устройство veth5e4f161 вышло из неразборчивого режима
[1071551.540313] br-af29e1edc1b8: порт 5 (veth5e4f161) перешел в отключенное состояние
[1071551.570924] устройство veth8fd3a0a перешло в неразборчивый режим
[1071551.571550] IPv6: ADDRCONF (NETDEV_UP): veth8fd3a0a: ссылка не готова
[1071551.571556] br-af29e1edc1b8: порт 5 (veth8fd3a0a) вошел в состояние пересылки
[1071551.571582] br-af29e1edc1b8: порт 5 (veth8fd3a0a) вошел в состояние пересылки
[1071551.841656] IPv6: ADDRCONF (NETDEV_CHANGE): veth8fd3a0a: ссылка становится готовой
[1071566.613998] br-af29e1edc1b8: порт 5 (veth8fd3a0a) вошел в состояние пересылки
[1071923.465082] br-af29e1edc1b8: порт 5 (veth8fd3a0a) перешел в отключенное состояние
[1071923.470215] br-af29e1edc1b8: порт 5 (veth8fd3a0a) перешел в отключенное состояние
[1071923.472888] устройство veth8fd3a0a вышло из неразборчивого режима
[1071923.472904] br-af29e1edc1b8: порт 5 (veth8fd3a0a) перешел в отключенное состояние
[1071923.505580] устройство veth9e693ae перешло в беспорядочный режим
[1071923.505919] IPv6: ADDRCONF (NETDEV_UP): veth9e693ae: ссылка не готова
[1071923.505925] br-af29e1edc1b8: порт 5 (veth9e693ae) вошел в состояние пересылки
[1071923.505944] br-af29e1edc1b8: порт 5 (veth9e693ae) вошел в состояние пересылки
[1071923.781658] IPv6: ADDRCONF (NETDEV_CHANGE): veth9e693ae: ссылка становится готовой
[1071938.515044] br-af29e1edc1b8: порт 5 (veth9e693ae) вошел в состояние пересылки

Кто-нибудь видел этот баг с 4.19?

да. У меня проблема с ядром 4.19.4-1.e17.elrep.x86_64

Привет,

Я тоже вижу эту ошибку. Есть ли у нас решение этой проблемы? Ядро 3.10.0-514.26.2.el7.x86_64

[username@ip-10-1-4-64 ~]$
Message from syslogd@ip-10-1-4-64 at Jul 19 10:50:01 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Message from syslogd@ip-10-1-4-64 at Jul 19 10:50:48 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Эта проблема все еще возникает :( Нет обновлений / идей, как исправить?

Происходит на Debian Stretch. Я пытался обновить свой контейнер Jenkins через Ansible, когда это произошло.

Эта проблема была решена этим коммитом:
https://github.com/torvalds/linux/commit/ee60ad219f5c7c4fb2f047f88037770063ef785f
Использование kpatch

curl -SOL https://raw.githubusercontent.com/Aleishus/kdt/master/kpatchs/route.patch
kpatch-build -t vmlinux route.patch 
mkdir -p /var/lib/kpatch/${UNAME} 
cp -a livepatch-route.ko /var/lib/kpatch/${UNAME}
systemctl restart kpatch
kpatch list

Эта проблема была решена этим коммитом:
torvalds / linux @ ee60ad2
Использование kpatch

curl -SOL https://raw.githubusercontent.com/Aleishus/kdt/master/kpatchs/route.patch
kpatch-build -t vmlinux route.patch 
mkdir -p /var/lib/kpatch/${UNAME} 
cp -a livepatch-route.ko /var/lib/kpatch/${UNAME}
systemctl restart kpatch
kpatch list