eth0에 대해 매우 유사한 문제가 있습니다. 우분투 12.04도.

기계의 전원을 껐다 켜야 합니다. /var/log/kern.log :

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

이봐, 이것은 나에게도 일어나기 시작했다.

도커 버전:

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

커널 로그 : http://pastebin.com/TubCy1tG

시스템 세부 정보 :
패치된 커널(3.14.3-rt4)로 Ubuntu 14.04 LTS를 실행합니다. 그러나 기본 linux-3.13.0-27-generic 커널에서 이런 일이 발생하는지 확인하지 못했습니다. 하지만 재미있는 점은 이런 일이 발생하면 모든 터미널 창이 멈추고 그 전에 기껏해야 몇 글자만 입력할 수 있다는 것입니다. 내가 여는 모든 새 제품에도 같은 운명이 닥칩니다. 결국 위의 좋은 의사처럼 가난한 노트북의 전원을 껐다 켜야 합니다. 기록을 위해 저는 urxvt에서 fish shell을 실행하거나 xmonad에서 xterm을 실행하고 있습니다. 일반 bash에 영향을 미치는지 확인하지 않았습니다.

이것은 관련이 있을 수 있습니다.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065434#yui_3_10_3_1_1401948176063_2050

컨테이너 내부의 네트워크를 통해 상당히 많은 양의 데이터 복사
그런 다음 컨테이너를 종료하면 per
네트워크 장치의 CPU 참조 카운트.

물론 나에게 이런 일이 발생한 경우 중 하나는 apt-get 패키지에 수많은 종속성을 가진 직후

Ubuntu 12.04.3에서 14.04로 업그레이드하면 다른 변경 사항 없이 이 문제가 해결되었습니다.

RHEL7, 3.10.0-123.4.2.el7.x86_64에서 이것을 경험합니다.

3.14-rt4를 실행할 때 VirtualBox 가상 네트워크 인터페이스에서 동일한 일이 발생하는 것을 확인했습니다. 그것은 바닐라 3.13이나 뭔가에서 수정되어야합니다.

@egasimus 동일 - 컨테이너를 종료하기 전에 수백 MB의 데이터를 가져온 다음이 오류가 발생했습니다.

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가 여전히 깨진 상태로 나오는 것을 보고 싶지 않을 것입니다. :/

편집: kernel.org에 제출했습니다.

3.18.1을 실행하는 Ubuntu 14.10에서 이것을 얻고 있습니다. 커널 로그 표시

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

시스템이 더 이상 고정되지 않으면 docker version/info 보내드리겠습니다. :)

이 문제도 보고 있습니다. 우분투 14.04, 3.13.0-37-일반

Ubuntu 14.04 서버에서 우리 팀은 3.13.0-40-generic에서 3.13.0-32-generic으로 다운그레이드하면 문제가 "해결"된다는 것을 발견했습니다. @sbward 의 관찰을 감안할 때 회귀는 3.13.0-32-generic 이후와 3.13.0-37-generic 이전(또는 포함)에 놓이게 됩니다.

우리의 경우 때때로 _negative_ 사용 횟수가 표시된다는 점을 추가하겠습니다.

FWIW 우리는 신뢰할 수 있는 커널(3.13.0-40-generic #69-Ubuntu)에서 lxc를 실행하는 이 버그에 부딪쳤습니다. 메시지는 dmesg 다음에 이 스택 추적이 뒤따릅니다.

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

Ubuntu 14.04 및 Debian jessie w/ kernel 3.16.x에서 이 문제가 발생했습니다.

도커 명령:

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

이건 좀 별로인 문제 같네요...

@jbalonso 3.13.0-32-generic에서도 몇 번의 성공적인 실행 후에 오류가 발생합니다.sob:

@MrMMorris 공개된 이미지를 사용하여 재생산 스크립트를 공유할 수 있습니까?

시스템에서 이 오류를 보는 모든 사람은 배포판에서 너무 오래되고 이 특정 문제에 대한 수정 사항이 없는 Linux 커널 패키지를 실행하고 있습니다.

이 문제가 발생하면 apt-get update && apt-get dist-upgrade -y 를 실행하고 시스템을 재부팅하십시오. Digital Ocean을 사용하는 경우 최신 커널을 자동으로 사용하지 않기 때문에 업데이트 중에 방금 설치된 커널 버전도 선택해야 합니다(https://digitalocean.uservoice.com/forums/136585-digitalocean 참조). /suggestions/2814988-give-option-to-use-the-droplet-s-own-bootloader).

CentOS/RHEL/Fedora/Scientific Linux 사용자는 yum update 사용하여 시스템을 업데이트된 상태로 유지하고 업데이트를 설치한 후 재부팅해야 합니다.

이 문제를 보고할 때 시스템이 완전히 패치되었고 배포 공급업체에서 제공한 최신 안정 업데이트(수동으로 설치된 실험/테스트/알파/베타/rc 패키지 없음)로 최신 상태인지 확인하십시오.

@삼촌

apt-get update && apt-get dist-upgrade -y

우분투 14.04 3.13.0-46-일반

docker run 한 번만 실행해도 여전히 오류가 발생합니다.

필요한 경우 재생산을 위한 AMI를 생성할 수 있습니다.

@MrMMorris Ubuntu 14.04의 최신 커널 패키지에 여전히 문제가 있음을 확인해 주셔서 감사합니다.

내가 도울 수 있는 다른 방법이 있으면 알려주세요! :웃다:

@MrMMorris 재생산자를 제공할 수 있는 경우 Ubuntu에 대해 열린 버그가 있으며 매우 감사할 것입니다. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152

@rsampaio 오늘 시간이 된다면 꼭

이 문제는 Debian 7과 Debian 8의 3.16(.7)에도 나타납니다: https://github.com/docker/docker/issues/9605#issuecomment -85025729. 서버를 재부팅하는 것이 현재로서는 이 문제를 해결할 수 있는 유일한 방법입니다.

일부 도커 컨테이너(모든 컨테이너가 아님)를 시작할 때 커널 2.6.32-504.8.1.el6.x86_64가 있는 RHEL 6.6에서 이 문제가 표시됨
_ kernel:unregister_netdevice : lo가

이번에도 서버를 재부팅하는 것이 유일한 해결책인 것 같습니다.

커널 3.19.3이 있는 CoreOS(647.0.0)에서도 이를 볼 수 있습니다.

재부팅도 내가 찾은 유일한 솔루션입니다.

sid 커널(4.0.2)로 Debian jessie를 테스트했습니다. 문제가 남아 있습니다.

우분투가 아닌 컨테이너를 실행하는 이 문제를 본 사람이 있습니까?

예. 데비안.
2015년 19월 19일 г. 19:01 "팝시클" 알림 @github.com
예:

우분투가 아닌 컨테이너를 실행하는 이 문제를 본 사람이 있습니까?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/5618#issuecomment -113556862.

이것은 이미지 관련 문제가 아니라 커널 문제입니다. 이미지를 다른 것으로 전환해도 이 문제가 개선되거나 악화되지 않습니다.

4.1.2-bone12 커널을 실행하는 BeagleBone Black의 Debian Jessie에서 문제 발생

4.1.2에서 4.2-rc2로 전환한 후 경험했습니다(1.8.0의 git 빌드 사용).
/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 Tue Jun 16 17:15:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Ubuntu 15.04의 커널, 동일한 문제

4.2-rc3에서도 보았습니다. 장치 누출에 대한 버그는 한 가지도 없습니다. :) 나는 고부하 상태에서 4.1보다 큰 모든 커널에서 재현할 수 있습니다.

나도 방금이 문제가 있었다. tutum을 통해 프로비저닝된 Ubuntu 3.13.0-57-generic. 불행히도 kern.log와 syslog를 채우고 시스템을 충돌시킵니다. 데이터베이스 시스템(도커화된 포스트그레스)에서 발생하므로 전체 시스템이 다운됩니다...

"me too"의 합창에 합류하여 RancherOS(최소 OS) 0.3.3을 실행하는 cloudstack VM에서 로컬 개인 도커 저장소에서 도커 이미지를 가져오는 동안 이 문제를 보고 있습니다. 그것은 10초마다 발생하며 그것이 의미가 있는지 없는지 확실하지 않습니다.

4.2-rc7에서도 이 문제가 발생합니다.

어떤 커널을 사용해야 합니까? 최신 커널(Ubuntu 14.04의 경우 3.19.0-26)에서도 계속 발생합니다.

우리도 이 문제를 겪었습니다. 이것은 userland-proxy=false를 구성한 후에 발생합니다. 1분마다 nagios 플러그인 명령을 실행하기 위해 새 도커 컨테이너를 생성하는 일부 모니터 스크립트를 사용하고 있습니다. 프로세스 트리에서 보고 있는 것은 docker rm 명령에 붙어 있고 kern.log 파일에 많은 오류가 있다는 것입니다.

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

이것은 우리의 시스템 정보입니다

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

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

업데이트: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1403152 에서 이미 2015-08-17에 수정되었다고 밝혔습니다. 그래서 2015년 9월 2일에 빌드된 커널 v3.19.8-ckt6-vivid 또는 2015년 9월 21일에 빌드된 v4.2.1-unstable로 시도했지만 여전히 문제가 있습니다.

방금 3.19.0-28-generic 사용하여 문제를 다시 쳤으므로 최신 우분투 커널이 안전하지 않습니다.

예, --userland-proxy=false 는 이전 커널에서 현재 최상의 옵션이 아닌 것 같습니다.

아니요. 모든 3.19, 4.0, 4.2 커널 버전에 대해 --userland-proxy=false를 시도했지만 문제가 계속 발생합니다.

나는 iptables(--iptables=false) 없이 userland 프록시를 사용하고 있으며 이것을 최소한 하루에 한 번 봅니다. 슬프게도 유일한 해결 방법은 SysRq 기술을 사용하여 서버를 하드 리셋하는 워치독이었습니다.

내 시스템은 stdout/err 작성자가 많은 일부 컨테이너를 실행합니다. 다른 사람들은 버그를 유발할 수 있다고 보고했습니다.

``````
$ 도커 정보
컨테이너: 15
이미지: 148
저장 드라이버: aufs
루트 디렉토리: /var/lib/docker/aufs
백업 파일 시스템: extfs
디렉토리: 178
Dirperm1 지원: true
실행 드라이버: native-0.2
로깅 드라이버: json-file
커널 버전: 3.19.0-26-일반
운영 체제: 우분투 14.04.3 LTS
CPU: 12
총 메모리: 62.89GiB
이름: * *
ID: 2 ALJ:YTUH : QCNX:FPEO :YBG4:ZTL4:2 EYK:AV7D :FN7C: IVNU:UWBL :YYZ5

$ 도커 버전
클라이언트 버전: 1.7.0
클라이언트 API 버전: 1.19
Go 버전(클라이언트): go1.4.2
Git 커밋(클라이언트): 0baf609
OS/아치(클라이언트): linux/amd64
서버 버전: 1.7.0
서버 API 버전: 1.19
Go 버전(서버): go1.4.2
Git 커밋(서버): 0baf609
OS/아치(서버): linux/amd64```
``````

불행히도 저는 같은 경우입니다. 오늘날 프로덕션 서버가 이 오류로 3번 실패했으며 이를 처리하는 유일한 방법은 일부 마법의 SysRq 명령을 사용하는 것입니다.

충돌

커널 4.2.0을 사용하는 최신 데비안 jessie에서 여전히 이것을 보고 있습니다.

동일한 문제가 있습니다. 갑자기 내 aws 서버 중 3대가 다운되었고 로그에서 "unregister_netdevice: lo가 해제되기를 기다리고 있습니다. 사용 횟수 = 1"이라고 소리쳤습니다.

우분투: 14.04
커널 버전: 3.13.0-63-일반
도커: 1.7.1

시스템 로그

사용하기에 안전한 커널 버전이 있습니까?

Ubuntu 15.10의 커널 4.2에서도 문제가 발생합니다.

코어로스에서 일어난 일:

이미지: 1174
스토리지 드라이버: 오버레이
백업 파일 시스템: extfs
실행 드라이버: native-0.2
로깅 드라이버: json-file
커널 버전: 4.1.7-coreos
운영 체제: CoreOS 766.4.0

@killme2008이 지난번에 말한 커널 버그

커널 위에 적용된 이 패치를 사용해 보십시오. http://www.spinics.net/lists/netdev/msg351337.html
패킷: packet_bind의 경쟁 조건

또는 -stable 트리에서 백포트를 기다립니다. 조만간 올 것입니다.

:+1: 좋은 소식입니다!

안녕하세요 여러분, 좋은 소식입니다!

여기에 내 마지막 댓글(작성 당시, 17일 전) 이후로 이러한 오류가 다시 발생하지 않았습니다. 내 서버(약 30개)는 일부 오래된 패키지와 함께 우분투 14.04를 실행하고 있었습니다.

docker-engine(1.7.1에서 1.8.3으로)을 포함한 전체 시스템 업그레이드 + 우분투 저장소에서 가능한 최신 버전으로 커널 업그레이드 후, 내 서버는 아무 문제 없이 실행되고 있습니다.

:8볼:

오늘 AWS 인스턴스 중 3개에서도 발생했습니다.

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

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

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

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에서 저를 만났습니다.

코어로스 버전:

 core@core-1-94 ~ $ cat /etc/os-release
 NAME=코어OS
 아이디=코어로스
 버전=766.5.0
 버전_ID=766.5.0
 빌드_ID=
 PRETTY_NAME="코어OS 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 커밋(클라이언트): df2f73d-dirty
 OS/아치(클라이언트): linux/amd64
 서버 버전: 1.7.1
 서버 API 버전: 1.19
 Go 버전(서버): go1.4.2
 Git 커밋(서버): df2f73d-dirty
 OS/아치(서버): linux/amd64

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

시스템 로그:

 Dec 07 16:26:54 core-1-94 커널: unregister_netdevice: veth775ea53이 해제되기를 기다립니다. 사용 횟수 = 1
 Dec 07 16:26:54 core-1-94 커널: unregister_netdevice: lo가 해제되기를 기다립니다. 사용 횟수 = 2
 Dec 07 16:26:55 core-1-94 sdnotify-proxy[1203]: I1207 08:26:55.930559 00001 vxlan.go:340] 무시하지 않음: 4e:5c:47:2f:9a.24,4 .97.10
 Dec 07 16:26:59 core-1-94 dockerd[1269]: time="2015-12-07T16:26:59.448438648+08:00" level=info msg="/버전 가져오기"
 Dec 07 16:27:01 core-1-94 sdnotify-proxy[1203]: I1207 08:27:01.050588 00001 vxlan.go:340] 무시하지 않음: 5a:b1:f7:e9:10d.d24, .34.8
 Dec 07 16:27:02 core-1-94 dockerd[1269]: time="2015-12-07T16:27:02.398020120+08:00" level=info msg="/버전 가져오기"
 Dec 07 16:27:02 core-1-94 dockerd[1269]: time="2015-12-07T16:27:02.398316249+08:00" level=info msg="/버전 가져오기"
 Dec 07 16:27:04 core-1-94 dockerd[1269]: time="2015-12-07T16:27:04.449317389+08:00" level=info msg="/버전 가져오기"
 Dec 07 16:27:04 core-1-94 커널: unregister_netdevice: veth775ea53이 해제되기를 기다립니다. 사용 횟수 = 1
 Dec 07 16:27:04 core-1-94 커널: unregister_netdevice: lo가 해제되기를 기다립니다. 사용 횟수 = 2
 Dec 07 16:27:06 core-1-94 sdnotify-proxy[1203]: I1207 08:27:06.106573 00001 vxlan.go:340] 무시하지 않음: a6:38:ac:749:903.f5,41 .47.24
 Dec 07 16:27:09 core-1-94 dockerd[1269]: time="2015-12-07T16:27:09.449944048+08:00" level=info msg="/버전 가져오기"
 Dec 07 16:27:11 core-1-94 sdnotify-proxy[1203]: I1207 08:27:11.162578 00001 vxlan.go:340] 무시하지 않음: 0e:f0:6f:f4:10.57, .71.24
 Dec 07 16:27:12 core-1-94 dockerd[1269]: time="2015-12-07T16:27:12.502991197+08:00" level=info msg="/버전 가져오기"
 Dec 07 16:27:12 core-1-94 dockerd[1269]: time="2015-12-07T16:27:12.503411160+08:00" level=info msg="/버전 가져오기"
 Dec 07 16:27:14 core-1-94 dockerd[1269]: time="2015-12-07T16:27:14.450646841+08:00" level=info msg="/버전 가져오기"
 Dec 07 16:27:14 core-1-94 커널: unregister_netdevice: veth775ea53이 해제되기를 기다립니다. 사용 횟수 = 1
 Dec 07 16:27:14 core-1-94 커널: unregister_netdevice: lo가 해제되기를 기다립니다. 사용 횟수 = 2
 Dec 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,1 .13.6
 Dec 07 16:27:19 core-1-94 dockerd[1269]: time="2015-12-07T16:27:19.451486277+08:00" level=info msg="/버전 가져오기"
 Dec 07 16:27:21 core-1-94 sdnotify-proxy[1203]: I1207 08:27:21.402559 00001 vxlan.go:340] 무시하지 않음: 92:c4:66:52:cd:bb,41 .24.7
 Dec 07 16:27:22 core-1-94 dockerd[1269]: time="2015-12-07T16:27:22.575446889+08:00" level=info msg="/버전 가져오기"
 Dec 07 16:27:22 core-1-94 dockerd[1269]: time="2015-12-07T16:27:22.575838302+08:00" level=info msg="/버전 가져오기"
 Dec 07 16:27:24 core-1-94 dockerd[1269]: time="2015-12-07T16:27:24.452320364+08:00" level=info msg="/버전 가져오기"
 Dec 07 16:27:24 core-1-94 커널: unregister_netdevice: veth775ea53이 해제되기를 기다립니다. 사용 횟수 = 1
 Dec 07 16:27:24 core-1-94 커널: unregister_netdevice: lo가 해제되기를 기다립니다. 사용 횟수 = 2
 Dec 07 16:27:26 core-1-94 sdnotify-proxy[1203]: I1207 08:27:26.394569 00001 vxlan.go:340] 무시하지 않음: 6a:f7:bf:ec:03.244, .87.8
 Dec 07 16:27:29 core-1-94 dockerd[1269]: time="2015-12-07T16:27:29.453171649+08:00" level=info msg="/버전 가져오기"
 Dec 07 16:27:29 core-1-94 systemd[1]: /run/coreos/motd 생성 시작 중...
 Dec 07 16:27:29 core-1-94 systemd[1]: /run/coreos/motd 생성을 시작했습니다.
 Dec 07 16:27:32 core-1-94 dockerd[1269]: time="2015-12-07T16:27:32.671592437+08:00" level=info msg="/버전 가져오기"
 Dec 07 16:27:32 core-1-94 dockerd[1269]: time="2015-12-07T16:27:32.671841436+08:00" level=info msg="/버전 가져오기"
 Dec 07 16:27:33 core-1-94 sdnotify-proxy[1203]: I1207 08:27:33.562534 00001 vxlan.go:340] 무시하지 않음: 22:b4:62:d6:25.b24, .68.8
 Dec 07 16:27:34 core-1-94 dockerd[1269]: time="2015-12-07T16:27:34.453953162+08:00" level=info msg="/버전 가져오기"
 Dec 07 16:27:34 core-1-94 커널: unregister_netdevice: veth775ea53이 해제되기를 기다립니다. 사용 횟수 = 1
 Dec 07 16:27:35 core-1-94 커널: unregister_netdevice: lo가 해제되기를 기다립니다. 사용 횟수 = 2

생일 축하해, 유혈 문제 =)
2014년 5월 6일

여기도 마찬가지입니다. 재부팅 중입니다. 최신 도커 버전. 우분투 14.04.

@samvignoli 이것은 커널 문제로 식별되었으므로 불행히도 docker에서 수정할 수 있는 것은 아닙니다.

@thaJeztah 커널 문제에 대한 버그 추적기에 대한 링크가 있습니까?
아니면 영향을 받는 커널에 대한 포인터입니까?

우리 환경에서 이 문제를 해결하고자 합니다.

@Rucknar 죄송합니다, 아닙니다(아마도 이 토론에 하나가 있을 것입니다. 모든 의견을 다시 읽지 않았습니다)

Linux atlas2 3.19.0-33-generic #38~14.04.1-Ubuntu SMP Fri 11월 6일 18:17:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

@Rucknar 위로 조금 스크롤하면 패치 링크가 표시됩니다 . http://www.spinics.net/lists/netdev/msg351337.html. 이제 Linux 마스터에 있습니다. Linux 4.4로 갈 것 같습니다. 누군가 이미 이전 버전으로 백포트했을 수도 있지만 확실하지 않습니다.

모두 감사합니다. 업그레이드에 필요한 사항을 살펴보겠습니다.

FWIW 여기에서 언급한 마지막 패치를 우분투 3.19로 백포트했으며 4.2 커널에서도 테스트했지만 둘 다 실패했습니다. 문제는 이 시점에서 4.4-rc3 net-next 브랜치에도 여전히 존재합니다.

@rsampaio 어떻게 테스트 했습니까? 실제로 모든 커널에서 docker를 사용하여 이 오류를 안정적으로 트리거할 수 없습니다. 그것은 때때로 발생합니다.

@fxposter 우리는 또한 프로덕션 외부에서 문제를 재현할 수 없으므로 프로덕션에서 패치된 커널로 몇 개의 인스턴스를 부팅해야 했습니다. 커널이 프로덕션 로드의 24시간 이내에 영향을 받는지 확인할 수 있을 정도로 자주 발생합니다.

때로는 매우 특이한 리소스로 문제를 수정합니다. 컨테이너 디렉토리를 /var/lib/docker/aufs/mnt에서 멀리 이동합니다.

그것으로 ... 아마도 우리는 '서비스 도커 재시작'을 할 수 있고 디렉토리를 다시 이동할 수 있습니다.

그렇지 않으면... 재부팅만 됩니다.

@rsampaio 지금 heroku 제작을 말씀하시는 건가요? 모든 비즈니스가 컨테이너 등을 중심으로 구축되기 때문에 이 문제를 어떻게 피합니까?

@rsampaio --userland-proxy=false 또는 많은 양의 생성된 컨테이너를 사용합니까? --userland-proxy=false 를 사용하고 로드 없이도 꽤 쉽게 재현할 수 있습니다. :)

@LK4D4 컨테이너, 특히 많은 아웃바운드 트래픽을 수행하는 컨테이너가 생성/파괴되는 경우가

@rsampaio https://github.com/crosbymichael/docker-stress 를 장기간 사용하면 재현할 수 있습니다.

이에 대한 업데이트/제안이 수정되었습니까?

@joshrendek 커널 버그입니다. 새로 출시된 커널 4.4에서도 고쳐지지 않는 것 같아서 어딘가에 적어도 하나의 경쟁 조건이 더 있습니다. :)

커널 버그

=)

@samvignoli 귀하의 의견을 건설적으로 유지할 수 있습니까? 이 문제를 해결할 수 있는 방법이 있으면 자유롭게 PR을 여십시오.

이 버그가 이미 업스트림(커널 메일링리스트)에 보고되었습니까?

확실히 되었습니다. 첫 번째 주석은 이 버그도 참조합니다: https://bugzilla.kernel.org/show_bug.cgi?id=81211

2014년부터 열었습니다. 작업하는 사람의 의견은 없지만 응용 프로그램이 잘못 사용했을 가능성이 높다는 것 외에는 아무 의견도 없습니다.

링크 주셔서 감사합니다, 저스틴! 나는 Linus를 트롤할 것이다 =)

좋은 안부. =* :하트:

@samvignoli 제발 이렇게 하지 마세요. 아무에게도 도움이 되지 않습니다.
누군가 작은 VM 이미지에서 이것을 재현할 수 있습니까?
아마도 gdb와 많은 kprintf로 손을 더럽힐 수 있습니다.

버그가 아직 열려 있습니다.

운영 체제: CentOS 7.2
커널: 4.4.2 elrepo kernel-ml
도커: 1.10.2
fs: xfs가 있는 오버레이fs

통나무:

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 테이블이 가득 찼음)를 수정하기 위한 것입니다. 부작용으로 내 원래 문제와 관련하여 뭔가를 한 것 같습니다.

실제로 변경된 것을 볼 수 있도록 전/후를 보여줄 수 있습니까? 이 설정을 이진 검색하고 더 작은 집합이 있는지 확인하시겠습니까?

Compute Engine VM에서 CoreOS Stable(899.13.0)을 사용하고 있습니다. 이 오류는 0 (기본값)에 대한 다음 플래그로 서버를 시작할 때마다 발생합니다. 나는 여러 번 앞뒤로 테스트했으며 IPv6을 비활성화한 상태에서 오류 없이 노드의 모든 컨테이너를 시작할 수 있습니다.

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

gcloud 컨테이너를 사용하여 GCR에서 다운로드하므로 IPv6 + MB 이미지 다운로드 + 컨테이너를 빠르게 닫는 것이 문제일 수 있습니다.

참고용 Docker 버전:

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

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

이 문제에서 이전 sysctl 플래그도 테스트했습니다. 그러나 일부는 이미 해당 값을 갖고 나머지는 이 오류와 관련된 아무 것도 변경하지 않는 것 같습니다.

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

net.ipv6.conf.all.disable_ipv6=1로 설정해도 문제가 계속 발생합니다.

도커 스트레스 도구는 문제를 매우 쉽게 생성할 수 있습니다.
https://github.com/crosbymichael/docker-stress

이것은 위의 도구를 위해 만든 바이너리입니다.
https://storage.googleapis.com/donny/main
https://storage.googleapis.com/donny/stress.json

"unregister_netdevice: veth6c3b8b0이 해제되기를 기다리고 있습니다. 사용 횟수" 로그가 표시되면 도커가 정지된 것입니다. 나는 이것이 도커에 의해 유발된 커널 문제라고 생각한다. 이것은 도커 userland-proxy가 꺼져 있을 때만 발생합니다(--userland-proxy=false).

나는 userland 프록시를 활성화하거나 활성화하지 않은 상태에서 이런 일이 발생했기 때문에 꺼져있을 때만 말하지 않을 것입니다.

상황을 악화시킬 수도 있습니다. 우리가 한때 --userland-proxy=false 를 기본값으로 만들려고 했지만 부작용이 있었기 때문에 되돌렸습니다. https://github.com/docker/docker/issues/14856

나는 어제 이후로 한 번 오류를 보았습니다. 분명히 IPv6을 비활성화하는 것은 수정 사항이 아닙니다. 그러나 플래그가 없으면 도커를 폐기하지 않고 서버의 모든 컨테이너를 시작할 수도 없습니다.

kubernetes 1.2.2 및 docker 1.10.3이 있는 CoreOS 1010.1.0에서 실행

Kubernetes는 kubelet에 플래그를 추가했습니다(모바일에서는 찾을 수 없음).
머리핀 모드. "promiscuous bridge" 또는 유효한 것으로 변경하십시오.
값입니다. 변경한 이후로 이 오류가 발생하지 않았습니다.

@bprashanh

확인하거나 반박하시겠습니까?
2016년 4월 13일 오후 12시 43분, "Aaron Crickenberger" [email protected]
썼다:

kubernetes 1.2.2 및 docker가 있는 CoreOS 1010.1.0에서 실행
1.10.3

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/5618#issuecomment -209617342

Docker 버전 1.9.1과 함께 Linux 4.4.5-15.26.amzn1.x86_64를 실행하는 AWS에서 이것을 얻으려면 a34a1d5/1.9.1을 빌드하십시오.

알파인 이미지가 포함된 Ruby 2.3.0이 컨테이너 내부에서 실행되고 있어 이 문제가 발생합니다.

커널:[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 문제가 완전히 사라졌다고 확신하거나 아직 문제가 다시 발생하지 않는다는 점에서 수정되었습니까? 경쟁 조건이 될 수 있습니다 ...

이것은 커널의 경쟁이며 참조 카운트를 잃는 것이 분명합니다.
어딘가에. 이것은 버그를 추적하기가 정말 어렵지만 우리가 말할 수 있는 한
여전히 존재합니다.

2016년 5월 2일 월요일 오후 10시 52분, Sune Keller [email protected]
썼다:

@MrMMorris https://github.com/MrMMorris 당신이 확신하는 것처럼 고정
문제가 완전히 사라졌거나 다시 발생하지 않습니다.
바로 지금? 경쟁 조건이 될 수 있습니다 ...

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/5618#issuecomment -216444133

예. 커널 4.5에서 CoreOS 1032.0.0을 시도했지만 문제가 여전히 존재합니다.

나는 어제 커널 4.5.0이 있는 CoreOS 1010.1.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 : : 외침 : : 외침 : : 외침 : : 외침 : : 외침 : : 외침 : : 외침 : : 외침 : : 외침 :

@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 좋은 지적, 나는 그것을 언급했어야 했다. (현재) EXT4 백업 FS와 함께 오버레이 드라이버를 사용하고 있습니다.

저는 devicemapper를 사용했지만(Fedora Server를 사용하기 때문에) 많은 고통을 겪었습니다. 특히 컨테이너가 삭제된 후 매퍼가 풀에 공간을 반환하지 않는 누수로 인해 많은 고통을 겪었습니다.

도움이된다면 Docker 1.11.1 및 Kernel 4.2.5-300.fc23.x86_64를 사용하고 있습니다.

@joedborg 흥미롭습니다. RHEL 문서에서 RHEL/CentOS 7.1에서는 EXT4만 지원하고 RHEL/CentOS 7.2에서는 XFS만 지원한다고 언급했기 때문입니다. 그런 다음 XFS가 최신 버전에서 작동할 것으로 예상했습니다.

@thaJeztah 아 이상 stop 에서 수행되었으므로 확실히 더 좋습니다.

@joedborg 그렇군요 유익한 정보

커널 4.2에서 4.5, 동일한 도커 버전에서 동일한 오류가 발생합니다.

BTW, 같은 상자에서 동시에 여러 가상 상자 컴퓨터를 실행하고 있습니다.

$ 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

ext4 FS의 디렉토리와 함께 overlay 그래프 드라이버를 사용하여 이 문제를 겪고 있습니다. 그래서 xfs 가 문제가 아닌 것 같아요 😢

@obeattie 예, 사람들이 devicemapper 에도 받는 것 같습니다. 터치 우드, 전환 후 다시 문제가 발생하지 않았습니다. 언급했듯이 물리적 디스크도 교체했습니다. 이것은 흥미로운 일이 될 것입니다!

이 문제는 어떤 식으로든 파일 시스템과 관련이 없습니다. zfs, overlayfs, devicemapper, btrfs 및 aufs에서 이 문제가 발생했습니다. 또한 스왑 유무에 관계없이. 도커에 국한되지 않고 lxc에서도 같은 버그가 발생했습니다. 현재 내가 볼 수 있는 유일한 해결 방법은 컨테이너를 동시에 중지하지 않는 것입니다.

도움이 된다면 AWS AMI에서 지원하는 최신 ec2 인스턴스에서 동일한 오류 메시지가 표시됩니다. 도커 버전 쇼-

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

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

그냥 탑승합니다. 최신 Amazon ec2 인스턴스에서 동일한 동작을 보고 있습니다. 일정 시간이 지나면 컨테이너가 뒤집혀서 응답하지 않게 됩니다.

$ 도커 정보
컨테이너: 2
이미지: 31
서버 버전: 1.9.1
스토리지 드라이버: devicemapper
풀 이름: docker-202:1-263705-pool
풀 블록 크기: 65.54kB
기본 장치 크기: 107.4GB
백업 파일 시스템:
데이터 파일: /dev/loop0
메타데이터 파일: /dev/loop1
사용된 데이터 공간: 1.199GB
총 데이터 공간: 107.4GB
사용 가능한 데이터 공간: 5.754GB
사용된 메타데이터 공간: 2.335MB
메타데이터 공간 총계: 2.147GB
사용 가능한 메타데이터 공간: 2.145GB
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-file
커널 버전: 4.4.10-22.54.amzn1.x86_64
운영 체제: Amazon Linux AMI 2016.03
CPU: 1
총 메모리: 995.4MiB
이름: [편집됨]
ID: OB7A:Q6RX: ZRMK:4R5H : ZUQY:BBNK : BJNN:OWKS :FNU4:7NI2: AKRT:5SEP

$ 도커 버전
고객:
버전: 1.9.1
API 버전: 1.21
이동 버전: go1.4.2
힘내 커밋: a34a1d5/1.9.1
세워짐:
OS/아치: linux/amd64

섬기는 사람:
버전: 1.9.1
API 버전: 1.21
이동 버전: go1.4.2
힘내 커밋: a34a1d5/1.9.1
세워짐:
OS/아치: linux/amd64

위의 설명과 마찬가지로 EC2에서도 64bit Amazon Linux 2016.03 v2.1.0 running Docker 1.9.1 사용하여 Elastic beanstalk를 통해 실행됩니다.

현재로서는 다소 일화적인 이야기지만 최근에 테스트로 약 18개의 서버에서 4.2.0에서 4.5.5 커널로 업그레이드를 시도했고 이 문제는 상당히 악화되었습니다(여러 날에서 문제 사이에 4시간 이내로).

이것은 데비안 8에 있었다

@jonpaul 및 @g0ddard 와 정확히 동일한 설정

이 버그를 완화할 수 있는 방법을 찾고 있습니다.
가장 먼저(잘 될 수도 있고 안 될 수도 있고, 위험할 수 있음) 다음과 같은 경우에 API를 계속 사용할 수 있도록 하는 것입니다. #23178

안녕하세요. 저도 이 버그에 걸렸습니다...

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

CoreOS Beta, Flannel에서 Kubernetes 1.2.4를 사용하고 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

센토스7.2
도커 1.10.3
같은 문제

4.6.3 커널(최근)과 함께 CoreOS 1068.3.0을 실행하는 EC2(m4.large)에서 결국 이 문제를 재현할 "하나의 라이너"가 있습니다. 저에게는 YMMV가 아닌 약 300번의 반복이 필요합니다.

Linux ip-172-31-58-11.ec2.internal 4.6.3-coreos #2 SMP Sat Jun 25 00:59:14 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz GenuineIntel GNU/리눅스
CoreOS 베타(1068.3.0)
Docker 버전 1.10.3, 빌드 3cd164c

여기서 루프를 수백 번 반복하면 결국 dockerd가 중단되고 커널은 다음과 같은 오류 메시지를 내보냅니다.

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

재생기 루프는

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

편집

• userland-proxy=false 때만 이것을 재현할 수 있었습니다.
• VirtualBox(지금까지는 ec2만)를 사용하여 재현할 수 없었으므로 하이퍼바이저와도 관련이 있을 수 있습니다.

위의 @btalbot 스크립트는 수천 번 반복한 후에도 Fedora 23에서 문제를 재현하지 않습니다.

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

이 문제는 내 Kubernetes 클러스터에서 매우 자주 발생하지만 스트레스 요인이나 @btalbot 의 한 라이너로는 안정적으로 재현할 수 없습니다. CoreOS 1068.3.0이 설치된 두 개의 Azure VM에서 실행해 보았습니다.

첫 번째 VM은 Standard_D1_v2(3.5GB RAM, 1코어)였습니다. 스크립트는 3000회 이상 반복했습니다.
두 번째 VM은 Standard_DS15_v2(140GB RAM, 20코어)였습니다. 스크립트는 > 7600번의 반복을 수행했습니다.

userland-proxy=false일 때만 이를 재현할 수 있다는 내용을 포함하도록 이전 의견(https://github.com/docker/docker/issues/5618#issuecomment-229545933)을 업데이트했습니다.

HVM을 사용하는 EC2 t2.micro(단일 코어) VM과 m4.large(멀티 코어)에서 재생산됩니다. userland-proxy 설정에 관계없이 아직 랩톱에서 VirtualBox를 사용하여 발생하는 것을 본 적이 없습니다.

kubernetes 클러스터에서 활성화된 hairpin-veth와 함께 Flannel을 사용하는 동안 이 버그가 발생했습니다(iptables 프록시 사용). 이 버그는 너무 많은 컨테이너를 실행할 때만 발생했습니다. 우리는 cbr0 브리지 네트워크와 promiscuous-bridge 헤어핀 모드를 사용하도록 전환하고 다시는 볼 수 없습니다.
실제로 hairpin-veth를 사용하는 경우 이 버그를 재현하는 것은 쉽습니다. kubernetes가 포함된 100개의 컨테이너로 이 작업 을 시작

2016년 1월 7일 08:01에 manoj0077은 다음과 같이 썼습니다.

@btalbot https://github.com/btalbot 1.12에서 다시 시작할 수 있습니다.
실행 중인 컨테이너에 영향을 주지 않고 dockerd. 그래서 dockerd가 다시 시작됩니다
이 경우 여기에 도움이 되십니까?

AFAICT, 1.12의 이벤트, 도커 컨테이너 프로세스는 여전히 자식입니다.
도커 데몬의.

@sercand 난잡한 다리 머리핀 모드는 어떻게 설정하셨나요? 나는 그것에 대해 docker의 문서를 볼 수 없거나 아마도 다른 이름을 사용하고 있을 것입니다.

Docker 🐳에서 언제 이것을 볼 수 있는지에 대한 공식적인 언급이 있습니까? 이것은 두 번째로 많은 댓글이 달린 공개 문제입니다 . 매우 심각합니다(호스트를 다시 시작해야 함). 재현 가능합니다. 근본 원인을 찾아내거나 수정하는 데 실질적인 진전이 보이지 않습니다 😞.

이것은 커널 문제일 가능성이 가장 높지만 Bugzilla 의

@justin8 나는 이것이 Kubelet 플래그라고 생각합니다: --configure-cbr0 및 --hairpin-mode

@sercand 저도 Flannel을 사용합니다. --hairpin-mode=promiscuous-bridge 사용 시 불이익이 있나요?

@obeattie 동의합니다. :(

FTR 내가 설정한 테스트 Kubernetes 클러스터에서 @sercand 의 stresser 작업을 사용하여 문제를 복제할 수 있었고 flannel 및 hairpin-veth도 사용합니다.

@sercand promiscuous-bridge 사용을 시작하는 단계를 자세히 설명해 주시겠습니까? 노드의 kubelet에 --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 이 문서를 따랐습니다.
문서 hairpin-mode의 @edevil 은 "이를 통해 서비스의 엔드포인트가 자체 서비스에 액세스를 시도해야 하는 경우 다시 로드

@sercand 문서에 따르면 컨트롤러 관리자에서 --allocate-node-cidrs=true 를 사용하는 경우 경로를 설정하기 위해 클라우드 공급자를 사용해야 합니다. Azure용 Kubernetes 클라우드 공급자가 없기 때문에 문제가 없었습니까? 경로를 수동으로 설정합니까? 감사 해요.

@edevil 저는 terraform을 사용하여 경로를 생성합니다. 이 리포지토리 에서 찾을 수 있습니다. 이 구성을 빠르게 만들고 한 번만 테스트했습니다. 기본 논리를 제공하기에 충분하기를 바랍니다.

@morvans @btalbot 혹시 1.12로 해볼 기회가 있었나요...?

나는 hairpin-veth에서 멀어지고 cbr0 브리지를 사용하여 더 이상 문제를 재현할 수 없음을 확인할 수 있습니다.

만일을 대비하여: 베어 메탈에서 이 문제가 있는 사람이 있습니까? 우리는 VMWare 랩에서 rancher 클러스터를 테스트했을 때 이것을 보았지만 실제 베어메탈 배포에서는 본 적이 없습니다.

예, 이 문제는 4.3 이상의 커널에 대해 베어메탈에서 발생합니다. 많은 다른 기계와 하드웨어 구성에서 이것을 보았습니다. 우리를 위한 유일한 해결책은 커널 4.2를 사용하는 것이었습니다.

확실히 여전히 4.2에서 발생하지만 새로운 버전에서 더 자주 발생합니다. 각 주요 릴리스를 테스트하여 더 나은지 확인하고 아직 아무것도 없습니다.

CoreOS 알파 1097.0.0에서도 발생합니다.

커널: 4.6.3
도커: 1.11.2

같은 문제가 발생합니다.

도커: 1.11.2
커널: 4.4.8-boot2docker.

호스트: OS X에서 VMWare Fusion 드라이버가 있는 Docker 머신.

제안된 해결 방법이 있습니까?

crashdump가 가능한 환경(EC2 아님)에서 문제를 안정적으로 재현할 수 있는 사용자가 실제로 이 crashdump 파일을 공유할 수 있다면 정말 도움이 될 것입니다. 우분투에서 kdump를 활성화하는 방법에 대한 자세한 정보는 여기 에서 찾을 수 있습니다. 다음은 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

crashdump는 커널 개발자가 참조 누출의 원인에 대해 더 많이 찾는 데 실제로 도움이 될 수 있지만 crashdump에는 호스트의 메모리 덤프도 포함되어 있으며 합리적인 정보가 포함될 수 있습니다.

...합리적인 정보.

:영형

나는 같은 문제에 직면 해있다.

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

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

같은 문제:

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

Docker version: 1.10.3

터미널 화면에서 직접 발생했습니다.

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

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

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

시스템은

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

같은 문제

Os: Amazon Linux AMI release 2016.03
Docker: 1.9.1

여기에도:

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

EC2에서 동일한 문제가 발생합니다.

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

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

(이 일이 발생하면 모든 내 pty + 신호음에서)
"단순히" Debian Jessie + 백포트:

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

안녕하십니까,

새로운 파괴 이미지를 생성하여 통제된 환경에서 문제를 복제하려고 하면 재현할 수 없습니다.

문제는 docker 1.9.1을 실행하는 서버 중 하나에서 발생했습니다.

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

나는 동시 모드에서 지금까지 17753 컨테이너를 동시에 점심을 먹고 veth* 인터페이스를 누출하지 않고 인터넷으로 트래픽을 올립니다. 누군가가 문제를 일관되게 재현하기 위해 지침을 붙여넣을 수 있습니까?

@pegerto --userland-proxy=false 있고 여러 컨테이너를 동시에 스핀업하면 트리거하기가 매우 쉬워야 합니다. https://github.com/crosbymichael/docker-stress를 사용하여 이 작업을 수행합니다.

@cpuguy83 감사합니다

--userland-proxy=false 를 갖도록 데몬 구성 문제를 쉽게 재현할 수 있습니다. 감사합니다. 이 구성을 실행하지 않는 데몬에 영향을 미치는 이 문제를 볼 수 있습니다.

>=4.3에서 netns 분리에 의해 도입된 netfilter 후크에서 커널 덤프가 표시됩니다. 경로가 127/8에서 발생할 때 문제가 더 악화되는 이유는 무엇입니까?

감사 해요

이 문제도 봅니다. CoreOS 1068.8.0, Docker 1.10.3, 커널 4.6.3. 관심이 있는 사람이 있으면 시스템 로그 중 일부를 가져왔습니다.

그냥 여러 ...
unregistered_netdevice: waiting for lo to become free. Usage count = 1
... 2개의 VM과 내 베어메탈 랩톱에서 모두 Ubuntu 16.04와 최신 커널(4.4.0-3[456])을 실행합니다.

결과적으로 모든 것이 중단되고 하드 재부팅이 필요합니다.
지난 주 전에 이것을 경험한 적이 없으며 VM 중 하나는 1.11.3에 있었고 다른 하나는 모두 1.12.0에 있었다고 생각합니다.

@RRAlex 이것은 도커 버전에만 해당되지 않습니다.
데몬 옵션에서 --userland-proxy=false 를 사용하는 경우... 또는 (내가 이해한 바에 따르면) kubernetes를 사용하는 경우 이 문제가 발생할 가능성이 높습니다.

그 이유는 --userland-proxy=false 옵션이 브리지 인터페이스에서 hairpin NAT를 활성화하기 때문입니다. 이는 컨테이너에 대한 네트워킹을 설정할 때 kubernetes도 설정하는 것입니다.

Docker Cloud(및 Docker Cloud 에이전트)를 사용하여 BYO 노드에서 이를 확인합니다.

오늘(약 25회 시도 중) 현재 Amazon ECS AMI에서 apt-get이 업데이트하는 명령으로 바닐라 debian:jessie 를 실행하고 pbzip2를 설치한 다음 실행하는 것을 보았습니다(간단한 다중 스레드 CPU 테스트).

@에데블
여기 있는 대부분의 사람들은 Docker를 사용하여 컨테이너를 시작/중지할 때 이러한 상황이 발생한다고 설명하지만, Debian에서 Docker 없이도 똑같은 상황이 발생했습니다.

• Debian "Jessie"(=Debian 버전 8.5), 베어메탈(VM 없음, 클라우드 없음, 하지만 일반 하드웨어)
• 커널 3.16.0-4-amd64
• 4개의 LXC 컨테이너 시작
• "lxc-stop -n $containerName"으로 하나의 LXC 컨테이너 종료
• 이 명령이 완료되면 커널 또는 인터페이스가 아직 완전히 '정리'되지 않았을 수 있습니다. 이전 "lxc-stop" 직후에 새 "lxc-stop"을 실행하면 커널 문제가 발생하기 때문입니다.

시스템을 하드 리셋하는 것 외에는 복구할 방법이 없습니다.

따라서 이 문제를 정확히 찾아내고 해결하기 위한 조사에서 Docker에만 집중하지 마십시오. Docker를 통해 또는 일반 "lxc" 명령을 통해 컨테이너의 빠른 중지/시작과 관련된 일반적인 문제는 분명합니다.

이것은 리눅스 커널의 문제라고 생각합니다.

나는 3개의 chroot(실제로는 pbuilder)가 매우 무거운 부하로 실행될 때 이 문제를 만났습니다.
내 하드웨어는 Loongson 3A(3.16 커널이 있는 mips64el 머신)입니다.

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

베어 메탈.

최근 커널 4.6.x 및 docker 1.11.2가 있는 베어 메탈(ovh 전용)에서 문제가 발생했습니다.
여기에서 댓글을 읽고 여러 해결 방법을 시도한 후 커널을 최신 버전의 3.14 분기(3.14.74)로 다운그레이드하고 https://github.com/docker/libnetwork/issues/1189 를 피하기 위해 도커를 1.12.0으로 업그레이드했습니다. 지금은 모든 것이 괜찮은 것 같습니다.

도움이 될 수 있기를 바랍니다.

모두, 더 이상 Docker 또는 chroot에 대한 메시지를 게시할 필요가 없다고 생각합니다. 모두 Linux 커널에 관한 것입니다.
따라서 컨테이너에 대한 가상 네트워크 인터페이스를 비활성화하는 부분에서 커널을 디버깅할 수 있는 사람이 있습니까? 컨테이너의 새 중지가 요청되기 전에 컨테이너의 이전 중지가 가상 인터페이스를 완전히 비활성화/정리하지 않은 경우 몇 가지 경쟁 조건이 발생할 수 있습니다.

@rdelangh 나는 그 문제가 반드시 커널과 관련이 있다고 생각하지 않습니다.

Fedora 24에서는 Fedora 리포지토리의 Docker 1.10.3 문제를 재현할 수 없으며 Docker 자체 리포지토리의 Docker 1.12.1에서만 문제를 재현할 수 있습니다.

두 테스트 모두 커널 4.6.7-300.fc24.x86_64로 수행되었습니다.

이 문제는 CoreOS 1068.10.0, Docker 1.10.3, 커널 4.6.3에서도 나타납니다.

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

EC2, docker 1.10.3의 안정적인 CoreOS 1068.9.0에서 Kubernetes 1.3.4를 사용하면 이 문제가 표시됩니다.

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, 커널 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 에서 이 문제를 악용하여 이 문제를 재현할 수 있습니다. CoreOS 1068.10에서 1개의 컨트롤러(m4.large)와 2개의 작업자(m4.large)로 작은 클러스터를 실행했습니다.

거기에서 2개의 ReplicationController를 만들 수 있습니다. 저는 http://pastebin.com/mAtPTrXH를 기반으로 hello 및 hello1 라고 불렀습니다. 이름과 레이블을 다르게 변경해야 합니다.

그런 다음 http://pastebin.com/SAnwLnCw를 기반으로 위와 동일한 이름/레이블과 일치하는 2개의 배포를 만듭니다.

_배포를 생성하는 즉시 엄청난 양의 스팸 컨테이너를 받게 됩니다_.

잠시 동안(몇 분) 그대로 두면 종료/생성을 시도하는 많은 항목을 볼 수 있습니다. 배포를 삭제하고 상황을 안정화할 수 있습니다. 좋은 소수의 Terminating 및 ContainerCreating이 표시되어야 합니다. 노드에 ssh를 연결하면 dmesg 및 docker ps 를 확인하여 위의 증상이 분명한지 확인하십시오.

제 경우에는 문제를 보기 전에 이 문제를 해결하는 데 약 5분이 걸렸습니다. @sercand 와 @edevil 이 가지고 놀던 변경 사항을 이것이 이 경우에 효과가 있는지 확인할 계획입니다.

@edevil 연결된 커밋을 cbro 브리지를 위해 환경에서 Flannel을 비활성화/제거한 것이 맞습니까?

플란넬이 docker0 를 사용하기를 원하고 내부 네트워킹이 cbr0 에서 작동하고 있기 때문에 함께 사용할 수 없을 것이라고 생각합니다. 맞습니까?

@alph486 맞습니다 . 플란넬 사용을 중단했습니다. 브리지를 사용하고 포드 네트워크의 경로를 설정합니다.

@ alph486 flannel은 --bridge=cbr0 docker 옵션으로 재정의할 수 있는 docker의 기본 브리지입니다.
CoreOS에서는 도커 시스템 단위를 재정의해야 합니다.

Kubelet 플래그 --experimental-flannel-overlay 는 flannel 구성을 읽고 flannel CIDR로 docker bridge cbr0 를 구성할 수 있습니다.

또한 문제로 보이는 veth-hairpin 대신 promiscuous 모드를 활성화합니다.

입력에 대해 @dadux 에게 감사드립니다. K8이 재정의된 장치에 의해 이미 부트스트랩된 cbr0 인터페이스를 선택하면 해당 솔루션과 함께 일할 수 있습니다. 시도해 볼게.

문서에 따르면 promiscuous-bridge --hairpin-mode 는 kubelet v1.3.4+에서

kubenet 네트워크 플러그인( --configure-cbr0 을 대체하도록 설정됨)을 사용한 후 문제를 다시 재현할 수 없었습니다. 나는 미래의 불확실성 때문에 flannel-overlay 옵션을 피하고 있습니다( --configure-cbr0 묶여 있는 것 같습니다).

도커 데몬이 docker0 브리지를 사용하는 경우 kubelet이 존재하지 않는 브리지 cbr0 구성을 시도하므로 --hairpin-mode=promiscuous-bridge 은 효과가 없습니다.

CoreOS의 경우 Kubernetes 동작을 미러링하지만 여전히 flannel을 사용하는 해결 방법은 다음과 같습니다.

• docker.service용 시스템 드롭인을 추가하여 브리지 docker0 인터페이스를 무차별 모드로 구성합니다. (확실히 이것을 하고 싶은 더 우아한 것이 있습니까?) :

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

• kubelet에 도커 브리지에 머리핀을 설정하지 않도록 지시합니다.
  kubelet --hairpin-mode=none

인터페이스에 헤어핀이 활성화되어 있는지 확인할 수 있습니다.
brctl showstp docker0
또는
for f in /sys/devices/virtual/net/*/brport/hairpin_mode; do cat $f; done

내 동료가 최근에 이 문제를 해결했다고 생각합니다. http://www.spinics.net/lists/netdev/msg393441.html , 우리 환경에서 이 문제가 발생했으며 문제를 발견했습니다. 이 수정 프로그램을 사용하면 이 문제가 발생하지 않습니다. 더. 이 문제가 발생한 사람은 이 패치를 시도하고 다시 발생하는지 확인할 수 있습니다. 그리고 우리 분석에서 ipv6과 관련이 있으므로 docker 데몬을 시작할 때 --ipv6=false 로 docker의 ipv6을 비활성화할 수도 있습니다.

@coolljt0725 어쩌면 내가

@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가 아닌 잘못된 O/S 동작의 문제라는 점을 강조해야 합니다. 왜냐하면 우리(및 이 스레드의 일부 다른 사람들)는 Docker 또는 Kubernetes를 전혀 실행하고 있지 않지만 LXC를 중지할 때 여전히 똑같은 상황이 발생하기 때문입니다. 컨테이너를 차례로 매우 빠르게 처리합니다.

@rdelangh 당신이 맞습니다. 그러나 이 문제는 Docker와 관련된 동작을 추적하기 위해 Docker 프로젝트에서 생성되었습니다. 이 스레드에서 OS 문제, K8s 문제 및 CoreOS 문제로 추적하는 다른 문제가 언급되었습니다. LXC 또는 다른 문제에서 문제를 발견한 경우 해당 스레드를 시작하고 여기에 링크하여 문제에 대한 인식을 높이는 것이 좋습니다.

이 오류에 대해 Docker google을 사용하는 사람들은 여기에 착륙할 것입니다. 따라서 근본적인 문제가 해결될 때까지 사람들이 앞으로 나아갈 수 있도록 이 문제에 대한 해결 방법을 여기에 게시하는 것이 좋습니다.

Docker/Kubernetes에 대한 이러한 변경은 O/S가 컨테이너의 인터페이스를 처리하는 방식과 관련하여 어떤 영향을 줍니까?

1. 내 게시물의 도커 변경을 통해 Kubernetes 스택이 도커를 조사하고 문제가 발생할 때 플랫폼이 정상인지 확인합니다.
2. hairpin-mode 변경은 기본적으로 K8이 docker0 브리지를 그대로 사용하도록 지시하므로 Docker에서 문제가 시작되는 "커널 랜드" 네트워킹 및 "헤어핀 veth"를 사용하지 않습니다. 실행 경로.

K8 및 Docker를 사용하여 이 문제에 대한 해결 방법입니다.

coolljt0725 동료의 패치가 안정을 위해 대기 중이므로 곧 배포판으로 백포트되기를 바랍니다. (David Miller의 게시물: 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와 co(및 이 스레드의 모든 사람)에게 감사합니다. 많은 사람들이 한동안 ipv6 패치로 커널을 업데이트할 수 없기 때문에 (현재 모두) 이 스레드의 제안을 많이 시도한 후 이 버그를 해결했습니다. 내가 본 문제를 다른 사람이 볼 수 없도록 효과가 있었던 것과 작동하지 않은 것에 대한 후속 조치로 전체 게시물을 작성하고 싶습니다.

TL;DR은 Linux 부팅 매개변수에서 ipv6을 비활성화하고 재부팅합니다. coreos에서 이것은 /usr/share/oem/grub.cfg set linux_append="ipv6.disable=1" 있고 그런 다음 재부팅됨을 의미합니다. centos/ubuntu/debian/$linuxes에서 작동해야 하는 보다 일반적인 목적의 제안은 여기 에서 찾을 수

• ipvlan(l2,l3)/macvlan(bridge) 시도: 이 중 어느 것도 aws에서 작동하지 않거나 최소한 aws에서 작동하도록 둘 중 하나를 결정하는 지식을 소유하지도 찾을 수도 없습니다. ipvlan 또는 macvlan으로 네트워크에 연결된 컨테이너를 시작하면 게이트웨이를 ping할 수 없거나 인터넷에 연결할 수 없습니다(예, 비 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 이곳은 이 곧 상류을 할 수 있고, 가치가 또 다른 기회, 그것은 성능이 문제에서 언급 한 버그에 관계없이이 해제 좋을 것이다하지만 불행히도 그것은 또 다른이 이때 버그.

• 문서화의 sysctl 설정을 통해 IPv6를 해제하려고 여기에 설명 된대로와의 sysctl 설정을 적용한 후 systemd-networkd를 다시 시작뿐만 아니라 dhcpcd를에서 IPv6을 비활성화를 시도 여기 그리고 여전히 인터페이스가없는 경우에도,에 켜져으로이 비활성화 IPv6로 충분하지 않았다 그것을 사용.
• 여기 에서 제안한 대로 한 번에 하나의 컨테이너만 제거하는 이 솔루션을 시도했지만 여전히 이 버그가 발생했습니다.

너무 오래; 읽었습니다 : grub 설정에서 ipv6을 비활성화하십시오. 재부팅. 이익.

CentOS 7.2(3.10.0-327.28.3.el7.x86_64) 및 Docker 1.12.1(k8 없음)에서 이 문제에 직면했습니다. 문제는 네트워크 트래픽이 증가할 때 발생합니다.
이전 조언에 따라 ipv6이 비활성화된 커널 부팅은 도움이 되지 않았습니다.
그러나 docker0 인터페이스를 promisc 모드로 전환하면 이 문제가 해결되었습니다. @dadux의 systemd drop-in 사용(고마워요!) - 지금 잘 작동하는 것 같습니다.

@rdallman grub을 통해 ipv6을 비활성화해도 우분투 16.06(커널 4.4.0-36-일반) 또는 14.04(커널 3.13.0-95-일반)에서 unregister_netdevice 를 방지하지 못합니다. --userland-proxy 설정에 관계없이(true 또는 false).

오오오, 패치가 안정을 위해 대기열에 있다는 것이 멋지군요.
--ipv6=false 가 아무 작업도 수행하지 않는 문제에 대해 @aboch 를 핑

@trifle 죄송합니다 :( 정보를 게시해 주셔서 감사합니다. 며칠 테스트 후 문제가 발생하지 않았지만 문제가 발생하면 다시 업데이트하겠습니다. coreos 1122.2(커널 4.7.0)를 실행 중입니다. docker0을 promisc 모드로 설정 일부 사람들을 위해 이것을 수정하는 것 같습니다 (우리에게는 운이 없습니다).

@RRAlex 백포트와 관련하여 Ubuntu 커널 팀에 연락한 사람이 있는지 알고 있습니까? 버그의 영향을 받는 Ubuntu 클러스터에 대규모 프로덕션 Docker 배포가 있습니다.

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" 솔루션을 테스트할 수 있었습니다. 그 외에도 - 내 데비안 8에서 4.7.2 커널로 업그레이드했습니다.
커널을 업그레이드하고 커널 매개변수에서 "ipv6.disable=1"을 활성화한 후 docker 데몬에 대한 "--userland-proxy=false" 플래그가 없어도 실제 워크로드에서 "waiting for lo" 문제를 잡을 수 있었습니다. 좋은 소식은 "--userland-proxy=false"를 지정하고 "docker-stress"로 문제를 재현하려고 시도한 후 더 이상 그렇게 할 수 없다는 것입니다. 그러나 "--userland-proxy" 값에 관계없이 다시 발생할 것이라고 확신합니다.
그래서 내가 본 바에 따르면 ipv6은 확실히 이 문제와 관련이 있습니다. 왜냐하면 이제 docker-stress가 더 이상 문제를 잡을 수 없기 때문입니다. 나쁜 소식은 문제가 실제로 여전히 존재한다는 것입니다(즉, 부분적으로만 수정됨).

나중에 더 테스트하기 위해 최신 4.8rc7을 컴파일합니다.

@twang2218 @coolljt0725

흠.. 그래서 방금 ddstreet의 ppa 에서 백포트된 패치로 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에 대한 것은 아닙니다. 곧장. 누출이 있다는 것을 알게 될 때까지는 그것이 어떤 장치와 연관되었는지 알지 못하기 때문에 추적해야 할 곰이 있습니다.

모든 댓글을 다 읽어보지는 않았지만 누군가가 우분투에서 신뢰할 수 있는 재생기를 제공할 수 있다면 그것을 살펴보고 뭔가를 알아낼 수 있는지 확인할 것입니다.

@sforshee 항상 재현하기 쉬운 것은 아니지만 패치가 생성되었습니다(적어도 여기에 보고된 일부 사례를 수정함). http://www.spinics.net/lists/netdev/msg393441.html. 그것은 업스트림 https://github.com/torvalds/linux/commit/751eb6b6042a596b0080967c1a529a9fe98dac1d 에서 허용되었습니다.

@thaJeztah 아, 지금 저에게 지시하신 질문이 보입니다.

따라서 패치는 업스트림 4.4 안정 대기열에 있습니다. 16.04의 경우 다음 커널 SRU(이미 진행 중임)가 아니라 지금부터 약 5-6주 후에 다음 커널 SRU에 포함될 가능성이 높습니다. 14.04에서도 필요한 경우 백포팅할 수 있도록 알려주십시오.

@sforshee는 기본적으로 커널에서 ipv6을 활성화하고(보통 기본적으로 활성화됨) 도커 데몬 플래그에 "--userland-proxy=false"를 추가한 다음 docker-stress -c 100 를 실행하여 재현할 수 있는 이전(패치 이전)입니다. 예(docker-stress는 여기에서 가져옵니다: https://github.com/crosbymichael/docker-stress)

@fxposter 감사합니다. 그 문제에 대한 수정 사항이 있다면 내가 정말로 걱정해야 할 것은 그 수정 사항을 Ubuntu 커널에 가져오는 것뿐입니다. 또한 해당 패치로 수정되지 않은 다른 누수를 조사하는 데 도움을 드릴 수 있습니다.

저도 이 문제가 있습니다. AWS의 rancherOS 상자에서 docker를 실행하고 있습니다. 실제로는 랜처 클러스터(호스트 3개)를 설정하고 그 안에서 작은 애플리케이션을 실행한 후 무작위로 발생합니다.

동일... Fedora 24, 무작위로 발생, 일주일 동안 괜찮을 수 있습니다. 10시간마다 하나씩 받는 것보다
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

커널 3.10.0-327.36.1.el7 및 docker 1.12.1을 실행하는 CentOS 7에서 경험

docker 1.12.1에 남아 있는 동안 커널 3.10.0-327.18.2.el7로 다운그레이드하면 시스템이 안정화된 것 같습니다.

나는 또한 이것을보고있다 :
도커 버전 1.11.2
우분투 16.04.1 4.4.0-38-일반

IPv6 비활성화(그럽)

ipv6 패치(sic!!)가 포함된 커널 4.8.0-rc7이 있는 서버에서 --userland-proxy=false (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는 확실히 깨졌습니다...
우분투에 대해 여기에서 언급했지만 누군가 더 나은 아이디어를 가지고 있을 수 있습니다.
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도 보고 있습니다.

여전히 일어났다. 도커 1.12.2, armbian Linux 커널 4.8.4, bootargs의 ipv6.disable=1

버그 수정 방법, 매일 만나요

@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
이동 버전: go1.5.3
힘내 커밋: b9f10c9/1.11.2
세워짐:
OS/아치: linux/amd64

섬기는 사람:
버전: 1.11.2
API 버전: 1.23
이동 버전: go1.5.3
힘내 커밋: b9f10c9/1.11.2
세워짐:
OS/아치: linux/amd64
```

다시 centos7 커널 4.4.30~~~~

CoreOS 1185.3.0, 4.7.3-coreos-r2, 도커 1.11.2
명령으로 "apt-get update"를 사용하여 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 설정에 등록 취소할 수 있었습니다. 이 문제를 해결하기 위해 4.7.x 커널의 다른 변경 사항이 제공된 패치와 함께 작동할 수 있지만 아직 확인하지 않았으므로 아직 모든 희망을 잃지 않아야 합니다. [2]에서 논의된 문제를 일으키는 재현 가능한 테스트 케이스가 있기 때문에 4.5.5로 테스트하고 있습니다.

테스트를 기반으로 확인한 기타 사항:

• 4.2는 이후 커널보다 훨씬 안정적입니다.
• 4.5.x는 거의 재현할 수 없습니다. 내가 광범위하게 테스트한 최신 커널(4.8.2 및 4.8.6) 중에서 처음 발생하는 시간이 60초에서 48시간 사이였지만 문제는 여전히 존재합니다.
• 문제는 네트워크 트래픽과 상위 리소스(가상 CPU) 용량에 대한 컨테이너 비율 모두와 상관 관계가 있는 것 같습니다. 다른 사람들이 피한 것처럼 이것이 실제로 경쟁 조건이라면 이것은 청어 일 수 있습니다.

다음 단계:

• 할당된 리소스가 해제되지 않는 경우를 찾기 위해 적절한 printk 문으로 커널을 계측합니다.
• 앞서 언급한 패치가 있거나 없는 4.7.5 이상의 커널을 테스트하여 문제가 발생하는지 확인하십시오.
• 충돌이 발생하기 직전에 매우 흥미로운 IPv6: eth0: IPv6 duplicate address <blah> detected 오류 집합을 보았습니다. 또 다른 청어 일 수도 있지만 상관 관계가 있는지 확인하기 위해 ipv6 비활성화 운동을 시도하고 싶습니다.

[1] 내 전체 설정은 4.5.5 기반으로 약간 맞춤화된 데비안 커널을 실행하는 GCE virt입니다. Docker version 1.8.3, build f4bf5c7 가 그 위에서 실행 중입니다.
[2] 테스트 사례 정보: 20개의 병렬 프로세스가 있으며, 각 프로세스는 도커 컨테이너 내부에서 Node.js hello world 서버를 시작합니다. hello world 를 반환하는 대신 Node.js 서버는 1MB의 임의 텍스트를 반환합니다. 상위 프로세스는 컨테이너를 시작하고 컬링하여 1MB의 데이터를 검색하고 컨테이너를 중지하는 긴밀한 루프에 있습니다. 이 설정을 사용하면 4-90초 동안 문제를 일관되게 재현할 수 있습니다. GCE 상자에서 평균 재생 시간을 변경하는 다양한 항목에도 불구하고 물리적 호스트 또는 가상 상자 내부에서 이와 동일한 설정을 사용하면 문제가 재현되지 않습니다. 내가 가지고 놀았던 변수: 동시 테스트 프로세스의 수, 전송된 페이로드의 크기, 컬 호출의 양. 처음 두 변수는 확실히 상관 관계가 있지만 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, 물리적 등):

가상 기기:
페도라 24
ext3의 오버레이FS2

도커에 할당된 별도의 드라이브는 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

도커 볼륨 L

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)는 Ubuntu 14.04에서 v4.8.7 로의 업그레이드 를 출시합니다. 부하 테스트에서는 여기에 설명된 오류가 발생하지 않는 것으로 나타났습니다. 이전에는 Ubuntu 14.04에서 linux-image-generic-lts-xenial을 실행 했습니다. 나는 가까운 장래에 더 많은 세부 사항을 설명하는 블로그 게시물을 게시할 계획입니다.

업데이트 : 나는 우리가 이 도커 스택을 실행하고 있다고 언급했어야 했습니다.

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

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

업데이트 : 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

데비안 테스트의 DigitalOcean VPS에서도 동일한 일이 발생합니다.

# journalctl -p0 | tail -15

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

체계

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

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

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

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

$ docker info

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

$ docker ps -a

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

$ ip link show

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

# ifconfig

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

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

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

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

나는 지난 4일 동안 4.8.8 을 빡빡한 루프(테스트 케이스에 대한 이전 주석의 [2] 참조)에서 논스톱으로 테스트했습니다. 여태까지는 그런대로 잘됐다.

사리

• 패치 751eb6b6 은 이 문제의 발생을 크게 줄이지만 완전히 제거하지는 않습니다.

가정
@meatballhat 은 프로덕션 서버가 4.8.7을 실행하는 동안 문제가 발생

• 내 테스트 테스트 케이스에 결함이 있습니다(가능성이 더 높음)
• 4.8.8에 수정 사항이 도입되었습니다. 4.8.8 changelog 를 보면 커밋 5086cadf 및 6fff1319 모두 해결된 netdev 문제를 언급합니다. 어느 누구도 여기서 문제를 명시적으로 언급하지 않지만 둘 다 의심스러울 만큼 가깝습니다.

이 문제를 재현할 수 있는지 알아보기 위해 몇 사람에게 4.8.8을 시도하게 할 수 있습니까?

@reshen 4.8.8로 업데이트하고 다시 보고하겠습니다 :+1: 조사해 주셔서 감사합니다!

@reshen 우수한 연구입니다. 지금까지 Xubuntu 16.04에서 Linux 4.8.8을 사용하여 문제를 재현할 수 없었습니다.

Ubuntu 메인라인 커널 빌드를 사용하고 있습니다. 잘 정의된 테스트 케이스는 없지만 작업하는 도커 컨테이너 세트를 시작하고 중지하여 이전에 일관되게 문제를 재현할 수 있었습니다.

Linux 4.8.8을 테스트하는 가장 쉬운 방법은 메인라인 커널 빌드에 aufs가 포함되지 않았기 때문에 스토리지 드라이버로 aufs에서 overlay2로 전환하는 것이었습니다. 테스트에 영향을 줄 것이라고 생각하지 않지만 주목해야 합니다.

과거에 나는 Dan Streetman이 백포트한 751eb6b6을 사용하여 Linux 4.4.4를 테스트했지만 이것이 문제를 줄이는 것 같지 않았습니다. 귀하가 언급한 두 패치(5086cadf 및 6fff1319)를 백포팅해도 4.4.8과 동일한 결과를 얻을 수 있는지 확인하는 것은 흥미로울 것입니다.

4.4.0-47이 포함된 Ubuntu 16.04는 여전히 영향을 받았습니다... 지금 4.4.0-49를 시도하면 나중에 보고됩니다.

편집: 2016-11-28: -49는 dmesg에 해당 로그 행을 표시하는 sitll입니다.

Fedora 25(커널 4.8.8) 및 Docker 1.12.3에서 이것을 경험했습니다.

참고: 단일 프로덕션 호스트에서 Linux 4.8.8을 Docker v1.12.3과 함께 실행했습니다. 가동 시간은 현재 5.5일이며 기계는 안정적입니다.

때때로 syslog에서 소수의 unregister_netdevice: waiting for lo to become free. Usage count = 1 메시지를 볼 수 있지만 이전과 달리 커널이 충돌하지 않고 메시지가 사라집니다. 커널이나 도커에 도입된 다른 변경 사항 중 하나가 이 조건을 감지하고 이제 복구한다고 생각합니다. 이것은 이제 이 메시지를 성가시게 만들지만 더 이상 중요한 버그는 아닙니다.

나는 다른 사람들이 자신의 생산 함대에서 위의 내용을 확인할 수 있기를 바랍니다.

@gtirloni - 4.8.8/1.12.3 컴퓨터가 충돌했는지 또는 방금 메시지를 본 것인지 명확히 할 수 있습니까?

삼각측량을 위한 유용한 정보의 재생산/제공에 애써주신 모든 분들께 미리 감사드립니다.

docker를 시작한 후 veth 인터페이스(docker0)에 해당하는 부분을 삭제하고, 가능을 사용하여 호스트를 프로비저닝할 때 나중에 docker를 다시 시작합니다. 이후 문제가 발생하지 않았습니다.

Docker와 함께 Raspbian을 실행하는 Raspberry Pi 2에서도 동일한 오류가 발생합니다.

커널 정보
Linux rpi2 4.4.32-v7+ #924 SMP Tue Nov 15 18:11:28 GMT 2016 armv7l GNU/Linux

도커 정보

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

약 50Mb의 다운로드된 프로그램을 설치해야 하는 컨테이너를 만든 후에 발생했습니다.

재부팅만 하면 기기를 다시 사용할 수 있습니다.

ECS 클러스터의 Amazon Linux에서 실제로 이것을 보고 있습니다. 메시지가 가끔 발생하지만 지금 reshen이 보고 있는 것처럼 잠기지 않습니다. 도커 1.11.2. Uname은 버전으로 "4.4.14-24.50.amzn1.x86_64"를 보고합니다.

@reshen 이번 주말에 랩톱에서 4.8.8을 빌드하고 확인하겠습니다.
나를 위해 그것을 고친다!
ᐧ

2016년 12월 1일 목요일 오전 10시 29분, Ernest Mueller [email protected]
썼다:

ECS 클러스터의 Amazon Linux에서 실제로 이것을 보고 있습니다 - 메시지
가끔 던지지만 지금 리셴이 보고 있는 것처럼 잠그지 않습니다.
도커 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

CoreOS Stable 1185.3.0을 실행하는 Kubernetes 작업자 노드에서 https://github.com/crosbymichael/docker-stress 를 사용하여 이 문제를 재현할 수도 있었습니다.

docker_stress_linux_amd64 -k 3s -c 5 --containers 1000 : 5명의 동시 작업자가 컨테이너 생성/삭제, 컨테이너의 최대 수명 = 3초, AWS의 m4.large 인스턴스에서 최대 1000개의 컨테이너를 생성하면 약 3분 후에 Docker 데몬이 응답하지 않게 됩니다.

CoreOS Beta 1235.1.0으로 업그레이드했는데 재현할 수 없었습니다(무응답 또는 커널 로그의 unregister_netdevice 메시지 모두). 5명의 동시 docker_stress 작업자를 실행하면 몇 분 후에 CoreOS Stable이 종료되지만 CoreOS 베타를 사용하여 테스트가 완료될 때까지 10개 및 15개의 동시 작업자로 실행할 수 있었습니다.

CoreOS는 "채널"에서 릴리스되므로 커널을 단독으로 업그레이드할 수 없습니다. 안정 버전과 베타 버전의 주요 차이점은 다음과 같습니다.

CoreOS 안정 1185.3.0

커널: 4.7.3

도커: 1.11.2

코어OS 베타 1235.1.0

커널: 4.8.6

도커: 1.12.3

4.4.23-31.54.amzn1.x86_64를 실행하는 Amazon Elastic Beanstalk에서 이 문제 보기

CoreOS Stable 1185.5.0, Docker 1.12.2에서 발생
재부팅 후 모든 것이 정상입니다

업데이트: 중단된 Docker 데몬 문제는 Docker v1.12.3 및 Linux 커널 v4.8.6이 포함된 CoreOS Beta 1235.1.0을 실행하는 호스트에서 다시 발생했습니다. 😢

1.12.4 및 1.13은 이론상 이 커널 문제가 발생했을 때 중단되지 않아야 합니다.
도커 데몬에서 멈춤이 발생하는 이유는 데몬이 컨테이너 개체에 대한 잠금을 유지하는 동안 커널에서 돌아오는 넷링크 메시지(절대 오지 않을)를 기다리고 있기 때문입니다.

1.12.4 및 1.13은 최소한 컨테이너 잠금을 해제하기 위해 이 넷링크 요청에 시간 초과를 설정합니다.
이것은 문제를 해결하지 __ 않지만
이 문제가 발생하면 넷링크와의 모든 상호 작용이 중단되는 것처럼 보이기 때문에 새 컨테이너를 가동할 수 없고 마찬가지로 분해할 수 없습니다.

@cpuguy83 FWIW, 실행 중인 컨테이너는 데몬이 중단될 때 AFAIK 문제 없이 계속 실행됩니다. 실제로 눈에 띄는 것은 컨테이너의 시작과 중지입니다(특히 우리와 같이 Kubernetes에서 실행).

이것은 문제를 해결하지 못하지만 적어도 (바라건대) 전체 데몬을 정지시키지는 않습니다.

전체 데몬이 동결되는 장점 중 하나는 파악하기 쉽다는 것입니다. Kubernetes는 노드를 제거할 수 있으며 자동으로 재부팅될 수도 있습니다. 데몬이 계속 실행되기만 하면 여전히 커널 문제가 발생한 것을 쉽게 찾을 수 있습니까?

@seanknox 패치가 적용된 Docker(CoreOS Docker 1.12.3 + Upstream 1.12.4-rc1 패치)가 포함된 사용자 지정 CoreOS 1248.1.0 AMI를 제공할 수 있습니다. CoreOS/K8s 클러스터에서 몇 시간마다 중단되는 문제를 수정했습니다. Deis Slack에서 AWS 계정 ID로 ping을 보내주십시오.

CoreOS 클러스터에서 이 문제로 큰 어려움을 겪었습니다. 언제 최종적으로 수정될지 누가 알 수 있습니까? 우리는 밤에 잠을 잘 수 있는 이 순간을 꿈꿉니다.

@DenisIzmaylov --userland-proxy=false 설정하지 않으면 일반적으로 이 문제가 발생하지 않아야 합니다.

그러나 그렇지 않으면 이것은 커널의 버그입니다. 아마도 여러 커널 버그일 수 있습니다. 어떤 사람은 4.8에서 해결되었다고 말하고 다른 사람은 그렇지 않다고 말합니다. 어떤 사람들에게는 ipv6을 비활성화하면 문제가 해결되는 것처럼 보이지만 다른 사람들은 그렇지 않습니다.

--userland-proxy=false 없는 고부하 시스템에서 몇 시간 이내에 이 문제를 확인했습니다.

커널 4.8.12 에서 unregister_netdevice 오류가 계속 표시되는 것을 확인했습니다. 발동까지 약 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에서 이것을 시도할 수 있다면 굉장할 것입니다. 1.12.5 는 Docker를 중단하는 대신 지금 멈춘 넷링크 요청에서 시간 초과

@cpuguy83 그러나 시스템은 여전히 ​​그 상태에서 사용할 수 없습니다 :)

@LK4D4 오, 완전히, 그 시간 초과를 보고 싶습니다 ;)

Cent OS 7에서 이 문제 발생:

kernel:unregister_netdevice : lo가

Linux foo 3.10.0-514.2.2.el7.x86_64 #1 SMP Tue Dec 6 23:06:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

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

이것은 Docker 컨테이너 내에서 실행되고 이 콘솔 메시지가 나타나는 동안 갑자기 죽어가는 것처럼 보이는 내 CI 빌드에 영향을 미칩니다. 수정 사항이나 해결 방법이 있습니까? 감사 해요!

@cpuguy83 이 오류가 발생하면 Docker가 중단되지 않지만 내 상황에서는 Jenkins/CI 작업이 중단되는 컨테이너가 종료됩니다.

그래서 나는 문제 없이 잠시(11개월?) centos 7 시스템에서 도커를 실행했습니다. 오늘 나는 tcp 수신 데몬을 시도하기로 결정했고( tcp 수신 주소를 /etc/sysconfig/docker에 추가함 ) 이 오류가 발생했습니다.

kernel:unregister_netdevice : lo가

그래서 내 사용 횟수는 3이 아닙니다.

컨테이너: 4
실행: 3
일시중지: 0
중지됨: 1
이미지: 67
서버 버전: 1.10.3
스토리지 드라이버: btrfs
빌드 버전: Btrfs v4.4.1
라이브러리 버전: 101
실행 드라이버: native-0.2
로깅 드라이버: json-file
플러그인:
볼륨: 로컬
네트워크: 브리지 널 호스트
커널 버전: 3.10.0-514.2.2.el7.x86_64
운영 체제: CentOS Linux 7(코어)
OS 유형: 리눅스
아키텍처: x86_64
Docker 후크 수: 2
CPU: 24
총 메모리: 39.12GiB
이름: 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 화요일 12월 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
이동 버전: go1.6.3
Git 커밋: 3999ccb-지원되지 않음
작성일: 2016년 12월 15일 목 17:24:43
OS/아치: linux/amd64

섬기는 사람:
버전: 1.10.3
API 버전: 1.22
패키지 버전: docker-common-1.10.3-59.el7.centos.x86_64
이동 버전: go1.6.3
Git 커밋: 3999ccb-지원되지 않음
작성일: 2016년 12월 15일 목 17:24:43
OS/아치: linux/amd64

@aamerik를 확인할 수 있습니다. 동일한 커널 버전에서 동일한 문제가 발생합니다. 시스템에 최근 큰 변경 사항이 없으며 오늘 이후로 이 문제가 표시됩니다.

Jenkins의 도커 이미지를 실행하는 CentOS 7 컴퓨터에서 동일한 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1 메시지를 보았습니다. 내가 사용하고 있던 CentOS 7 시스템은 약 2016년 12월 20일 현재 모든 최신 CentOS 7 패치를 사용하고 있었습니다.

여기에서 가장 최근 참조는 CentOS 기반인 것 같으므로 실행 호스트를 Ubuntu 또는 Debian 시스템으로 전환하겠습니다.

CentOS 7 시스템에서 Docker version 1.12.5, build 7392c3b 를 실행 중입니다. Docker는 중단되지 않았지만 Docker에서 실행 중인 Jenkins 프로세스는 해당 메시지가 표시되었을 때 종료되었습니다.

Docker에 정말 감사드립니다! 나는 항상 그것을 사용하고 그것에 대해 당신의 노고에 깊이 감사드립니다!

Linux 4.8.15 시스템에서 Docker와 함께 Jenkins를 사용할 때 동일한 문제가 표시됩니다.

누군가 , rancher os 에 대한 수정 절차 에 도달 했습니까 ?

AFAICT, 이것은 Linux 커널의 네트워크 네임스페이스 하위 시스템의 잠금 문제입니다. 이 버그는 1년 전에 보고되었으며 응답이 없습니다. https://bugzilla.kernel.org/show_bug.cgi?id=97811 이에 대한 작업이 있었습니다(여기 참조: http://www.spinics. net/lists/netdev/msg351337.html) 그러나 완전한 수정은 아닌 것 같습니다.

응답 없이 네트워크 하위 시스템 유지 관리자에 직접 ping을 시도했습니다. FWIW, 몇 분 안에 문제를 재현할 수 있습니다.

Smyte는 이 문제를 해결하기 위해 미화 5000달러를 지불합니다. 커널에서 일하는 사람과 이야기해야 할 것 같습니까?

@petehunt 이 오류를 일으키는 여러 문제가 있다고 생각합니다.

@reshen이 제안한 대로 커널 4.8.8 를 배포 했으며 가동 시간이 조금 더 좋아 보이지만 프로덕션에서 이 문제를 계속 볼 수 있습니다.

부트스트랩 노드에서 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

우나메 -r:

3.10.0-514.2.2.el7.x86_64

도커 -v:

Docker version 1.11.2, build b9f10c9

재부팅하면 메시지가 사라지는 것을 확인할 수 있지만 mesosphere를 다시 배포하는 순간 메시지가 때때로 시작됩니다. Mesosphere는 상당히 대규모 배포입니다. 오류를 재현하려는 사람들은 설치 프로그램을 사용하여 오류를 재현할 수 있습니다. 첫 번째 스크립트 스위치( 첫 번째 단계인 --genconf )를 사용한 후 오류가 표시되기까지 몇 분이 걸립니다.

우리는 이것 또한 쳤다. 그러나 이 경우의 오류 메시지에는 eth0 아니라 lo eth0 장치가 언급되어 있습니다. 내 오류는 다음과 같습니다.

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

내가 언급처럼 그 오류 겠지 eth0 대신 lo 이 문제와 같은 근본 원인이 있습니다. 그렇지 않은 경우 eth0 오류와 관련된 새 티켓을 열어야 합니다.

• OS: CentOS Linux 릴리스 7.3.1611
• 커널: 3.10.0-514.2.2.el7.x86_64
• Docker 버전 1.12.6, 빌드 78d1802
• Docker는 OPTIONS=" -H unix:///var/run/docker.sock --ip-forward=true --iptables=true --ip-masq=true --log-driver json-file --log-opt max-size=25m --log-opt max-file=2" 옵션으로 시작했습니다.
• Rancher 1.2.2, IPsec 사용

우리는 이것 또한 쳤다.
오류: unregister_netdevice: lo가 사용 가능해질 때까지 대기 중입니다.
OS: CentOS Linux 릴리스 7.3.1611(코어)
커널 3.10.0-514.2.2.el7.x86_64
도커 버전: 1.13.0-cs1-rc1
도커 옵션:
{
"레거시 레지스트리 비활성화": true,
"icc": 사실,
"안전하지 않은 레지스트리":[],
"ipv6": 거짓,
"iptables": 참,
"스토리지 드라이버": "장치 매퍼",
"스토리지 옵션": [
"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)에서 커밋을 백포트했습니다. 이 커밋은 엔터프라이즈 배포판 0.xs. 이렇게 하면 이 문제가 해결됩니다.

여기 에서 작동하는 패치가 있는 버그 보고서를 찾을 수 있습니다.
테스트에 관심이 있고 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이 7.3 Z-Stream으로 백포트했으며 docker의 macvlan 드라이버가 본드 또는 팀 장치에서 작동하는 것을 방지하는 7.4에 포함될 예정인 다른 커널 수정에서 입증됨)

네임스페이스를 전환할 때 아직 다른 경쟁 조건이 있다고 생각하지만(이는 많은 새 컨테이너를 만든 후에 발생하는 것 같습니다) 문제를 추적하고 패치를 작성하려면 문제를 안정적으로 복제해야 합니다.

누구든지 이것을 지속적으로 재현하기 위한 최소한의 절차를 가지고 있습니까? 우리 시스템에서 무작위로 발생하는 것 같습니다.

@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 실행 직후가 아니라 무작위로 나타나는 것 같습니다. 이것은 대부분 일화이지만 누군가에게 도움이 될 수 있습니다.

@iamthebot이 언급한 대로 CentOS 7.3의 모든 도커 노드를 커널 3.10.0-514.6.1.el7.x86_64로
Jan 26 13:52:49 XXX 커널: unregister_netdevice: lo가 해제되기를 기다립니다. 사용 횟수 = 1
1월 26일 13:52:49에 syslogd@XXX의 메시지 ...
kernel:unregister_netdevice : lo가

@jsoler 는 커널을 빌드하기 전에 버그 추적기 스레드에 패치를 적용했습니까? 아니면 스톡 커널을 사용하고 있습니까? 또한 이것을 적용

저에게 이메일([email protected])을 보내주시면 미리 빌드된 커널에 대한 링크를 보내드릴 수 있습니다. @vitherman 불행히도 이것에 대해 조사할 시간이 많지 않습니다(이 버그를 잡기 위해 일부 도구를 컴파일해야 할 것 같습니다). 하지만 Red Hat 지원 문제를 에스컬레이션하여 커널 팀이 바라보다.

@ckeeney 이 동작을 확인할 수 있습니다. 호스트 시스템이 종료될 때 호스트 시스템에서 해당 오류를 일으킨 Docker화된 Node 애플리케이션이 있습니다. Node.js 애플리케이션 내에서 함수를 구현한 후 SIGINT 및 SIGTERM을 포착하여 애플리케이션을 정상적으로 종료하면 오류가 다시 발생하지 않습니다.
어느 정도 의미가 있습니다. 노드 애플리케이션은 Docker가 생성하는 가상 인터페이스를 사용합니다. 노드가 제대로 종료되지 않으면 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 를 지정하거나 --stop-signal 플래그를 통해 docker run 지정할 수 있습니다.

@thaJeztah 문제에 대한 좋은 설명과 해결 방법은 nodejs/node-v0.x-archive#9131#issuecomment-72900581을 참조하세요.

@ckeeney 나는 그것을 알고 있습니다(즉, PID1 로 실행되는 프로세스 는 SIGINT 또는 SIGTERM 처리하지 못할 수 있습니다 ). 그런 이유로 PID1 로 실행하더라도 다른 stop-signal을 지정하면 완전히 종료되는지 궁금합니다.

또는 docker 1.13은 컨테이너에 초기화를 삽입하는 --init 옵션 (풀 요청: https://github.com/docker/docker/pull/26061)을 추가합니다. 이 경우 Node는 PID1 로 실행되지 않습니다. 이는 애플리케이션을 업데이트할 수 없는 경우에 도움이 될 수 있습니다.

@iamthebot 패치가 통합된 커널 버전 3.10.0-514.el7을 빌드했지만 동일한 오류가 발생합니다. 내가 centos의 커널 패키지를 잘 구축했는지 확실하지 않습니다. 테스트할 커널 패키지를 공유해 주시겠습니까?

감사 해요

저는 거의 1년 동안 이 버그를 처리해 왔습니다. PXE 부팅과 함께 CoreOS를 사용하고 pxeboot 구성에서 ipv6을 비활성화했으며 그 이후로 이 문제를 한 번도 본 적이 없습니다.

내 환경은 이 sysctl 구성으로 ipv6을 비활성화했습니다.
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
하지만 여전히 오류가 발생합니다.
kernel:unregister_netdevice : lo가

@jsoler 맞아, 나도 그렇게 하고 있었는데, 여전히 일어났다. 한 번만 px 수준에서 중지했습니다.

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://...

단지 관찰 - 다른 문제가 있는 것 같습니다(이전에 언급됨).

• 어떤 사람들은 "lo...를 기다리는 중"이라고 언급합니다.
• 일부는 "eth0을 기다리는 중"이라고 언급했습니다.
• 일부는 "베스를 기다리는 중?????"에 주목했습니다.
• RedHat 버그 추적 에서 "ppp0을 기다리는 중"에 대한 이야기가 있습니다.

일부는 위의 항목 중 하나와 위의 항목 중 하나만 있는 다른 항목 간에 번갈아 가며 로그를 기록했습니다.

Ubuntu 에도 유사한 버그가

@etlweather 사실 유일한 공통 분모는 네트 장치가 오류 메시지에 표시된 대로 커널에서 등록을 취소할 수 없다는 것입니다. 그러나 이유는 _왜_ 약간 다릅니다. 우리에게는 분명히 언급된 도커/노드 문제(veth)였습니다. eth의 경우 원인은 완전히 다른 것일 가능성이 큽니다.

docker 1.13.1이 있는 데비안 jessie의 4.9.0-0.bpo.1-amd64에서도 여전히 발생합니다. 안정적인 커널 - os 조합이 있습니까?

이것은 순전히 도커 문제가 아닐 수도 있습니다. 저는 바닐라 LXC 컨테이너(우분투 16.04)만 실행 중인 Proxmox 서버에서 이 문제를 겪고 있습니다.

@darth-veitcher 커널 문제입니다

@thaJeztah가 감사에 동의했습니다. 오늘 밤 메인 라인에서 4.9.9를 설치하고 문제가 해결되는지 확인하려고 했습니다.

커널 4.9.9-040909가 있는 데비안에서 Docker 1.13.1을 실행하고 있습니다.

예, Proxmox의 커널을 최신 4.9.9로 업그레이드해도 오류가 해결되지 않았습니다. 문제 없이 1년 만에 등장한 것이 이상합니다.

스레드에서 마운트된 NFS 또는 CIFS 공유에 연결된다는 내용이 이전 설명에 있을 수 있습니다.

내 iPhone에서 보낸

2017년 2월 14일 07:47에 Alfonso da Silva [email protected] 은 다음과 같이 썼습니다.

커널 4.9.9-040909가 있는 데비안에서 Docker 1.13.1을 실행하고 있습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

이에 대해 Redhat에 버그질라 티켓이 열려 있습니다.

일부 개발:
Red Hat은 메인라인의 IPV6 refcount 누수 패치를 QA에 올렸습니다. RHEL 7.4를 위해 대기 중인 것으로 보이며 7.3으로 백포트될 수 있습니다. 곧 CentOS-plus에도 있어야 합니다. 참고: 이 패치는 일부 경우에만 문제를 수정합니다. 4.x 커널이 있다면 이미 거기에 있기 때문에 무의미합니다.

이것은 확실히 내가 말할 수 있는 커널의 경쟁 조건이므로 찾기가 정말 짜증납니다. 현재 메인라인 커널의 스냅샷을 찍고 IPV6 하위 시스템으로 시작하는 다양한 호출을 계측하는 작업을 하고 있습니다. 문제는 이제 확실히 재현할 수 있습니다. 여러 개의 컨테이너를 생성하고, 컨테이너에서 엄청난 양의 네트워크 트래픽을 푸시하고, 컨테이너 내부의 프로그램을 충돌시키고, 제거하기만 하면 됩니다. 이 작업을 반복하면 물리적 4코어 워크스테이션에서 몇 분 만에 문제가 트리거됩니다.

불행히도 이 작업을 할 시간이 많지 않습니다. 여기에 필요한 부분을 계측하는 데 기꺼이 협력할 커널 개발자가 있다면 포크를 설정하고 이 문제를 단계별로 찾기 위한 작업을 시작할 수 있습니다. .

@iamthebot , qemu-kvm 설정에서 재현할 수 있습니까?

@iamthebot 나는 이것을 다른 커널로 여러 번 재현하려고 시도했습니다. 위의 어딘가에서 userland-proxy 를 false로 설정한 상태에서 docker-stress -c 100 사용하면 트리거된다고 언급했지만 운이 없었습니다.

좀 더 믿을 수 있는 재현이 있다면(트리거 시간이 오래 걸리더라도) 시도해볼 수 있어요

우리는 프로덕션 및 스테이징 환경에서 동일한 어려움에 직면합니다. 우리는 곧 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 dev에 많이 관여하지 않지만 "me too" 댓글이 그다지 도움이 되지 않는다고 말하는 것이 옳다고 생각합니다. 즉, "커널 vx.x 및 Docker 1.x에도 이 문제가 있습니다."라고 말하는 것만으로는 토론에 새로운 내용을 가져올 수 없습니다.

그러나 나는 더 많은 환경과 번식 방법을 설명하는 "me too" 댓글이 큰 가치가 있다고 제안합니다.

모든 주석을 읽을 때 몇 가지 문제가 있음이 분명합니다. 이전에 게시한 것처럼 일부는 vethXYZ, 일부는 eth0, 다른 일부는 lo0입니다. 이것은 그들이 다른 문제를 일으킬 수 있음을 시사합니다. 따라서 오류 및 환경에 대한 자세한 설명 없이 "나도"라고 말하면 사람들을 오도할 수 있습니다.

또한 환경을 설명할 때 Kernel 및 Docker 버전을 제공하는 것만으로는 충분하지 않습니다. 스레드별로 ipv6 활성화 여부와 같은 몇 가지 요소가 있는 것 같습니다. NodeJS가 SIGINT에 응답하지 않습니다(또는 여기에서 NodeJS를 공격하지 않는 다른 컨테이너).

따라서 환경의 워크로드를 설명하는 것이 유용할 것입니다. 또한 이것은 컨테이너가 종료될 때 발생합니다. 따라서 이 문제를 겪고 있는 사람들에게 문제가 추악한 헤드를 뒤로 할 때 어떤 컨테이너가 중지되고 있는지 주의를 기울이는 것이 좋습니다.

문제가 경합 상태가 있는 커널에 있는 것처럼 보이지만 트리거를 식별하는 것은 문제를 해결할 사람들에게 엄청난 도움이 될 것입니다. 그리고 영향을 받는 사용자에게 NodeJS 응용 프로그램에서 신호 처리기를 구현하는 것과 같은 즉각적인 솔루션을 제공할 수도 있습니다.

FWIW kubernetes는 이것을 "헤어핀 모드"와 완전히 연관시켰습니다.
은(는) 해당 기능의 사용을 완전히 중단했습니다. 우리는 이것을 경험하지 못했습니다
수만 대의 생산 기계와
변경 이후 더 많은 테스트 실행.

이 문제가 해결될 때까지 배를 포기하십시오. 다른 솔루션 찾기 :(

2017년 2월 15일 수요일 오전 10시에 ETL [email protected]에서 다음과 같이 썼습니다.

이 문제를 해결하는 사람은 아니지만 Linux를 많이 사용하지 않습니다.
Kernel dev, 나는 "me too"댓글이 아니라고 말하는 것이 옳다고 생각합니다.
도움이됩니다. 이 말은 "나도 이 문제가 있습니다.
Kernel vx.x 및 Docker 1.x"는 논의에 새로운 것을 가져오지 않습니다.

그러나 나는 더 많은 것을 설명하는 "me too"댓글을 제안합니다.
환경과 번식 방법은 큰 가치가 있습니다.

모든 의견을 읽을 때 몇 가지 문제가 있음이 분명합니다.
이전에 게시한 것처럼 일부는 vethXYZ, 일부는 eth0, 일부는 lo0입니다.
이것은 그들이 다른 문제를 일으킬 수 있음을 시사합니다. 그래서 그냥
오류 및 환경에 대한 자세한 설명 없이 "me too"라고 말하면
사람들을 오도합니다.

또한 환경을 설명할 때 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 위에 빌드되었습니다

편집 또 발생했습니다! 동일한 node.js 앱에서 작업합니다. 지난 3~4일 동안 해당 node.js 응용 프로그램에서 직접 작업하지 않았고 발생하지 않았습니다.

edit2 는 nodejs 앱에 신호 처리기를 추가하려고 시도합니다. 도움이 되는지 보자....

docker-py를 사용하여 새 인스턴스를 EC에 게시한 후 방금 이 오류가 발생했습니다. 그러나 ctrl+C로 종료할 수 있었고 그 이후로 보지 못했습니다(이제 대부분의 이미지가 캐시에서 더 빠르게 빌드됨).

```{"status":"푸시됨","progressDetail":{},"id":"c0962ea0b9bc"}
{"상태":"단계: 다이제스트: sha256:f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de8 크기: 5737"}
{"progressDetail":{},"aux":{"태그":"stage","다이제스트":"sha256:f5c476a306f5c2558cb7c4a2fd252b5b186b65da22c8286208e496b3ce685de}

Docker 이미지가 성공적으로 게시되었습니다.

2월 16일 19:49:16에 syslogd@ip-172-31-31-68의 메시지 ...
커널:[1611081.976079] unregister_netdevice: lo가 해제되기를 기다립니다. 사용 횟수 = 1

2월 16일 19:49:27에 syslogd@ip-172-31-31-68의 메시지 ...
kernel:[1611092.220067] unregister_netdevice: lo가 해제되기를 기다립니다. 사용 횟수 = 1

[1]+ 중지됨 ./image-publish.py
[ root@ip-172-31-xx-xx 이미지 게시]# ^C
[ root@ip-172-31-xx-xx 이미지 게시]#

@thockin 이 --hairpin-mode=none 설정입니까?

=none은 NAT를 자체적으로 받는 컨테이너를 중단합니다. 우리는 사용
기본적으로 promiscuous-bridge.

2017년 2월 16일 목요일 오후 7시 26분, Kanat Bekt [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를 통해 자체적으로 액세스하기를 원합니까?

생각보다 흔하게 나왔는데, 깨고 보니
사람들의 불평.

2017년 2월 17일 오전 12시 38분에 "Maxim Ivanov" [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
.

일부 dockerized nodejs 앱이 이 문제를 일으킬 수 있는 이유를 알 것 같습니다. 노드는 기본적으로 연결 유지 연결을 사용합니다. server.close() 를 사용하면 서버가 새 연결을 수락하지 않습니다. 그러나 웹 소켓 또는 HTTP 연결 유지 연결과 같은 현재 활성 연결은 계속 유지됩니다. dockerized 앱도 n으로 확장되면 waiting for lo to become free 될 수 있습니다. 강제 종료될 때 최신 버전이 해제되었기 때문입니다. 도커가 이 앱을 다른 노드에 재배포하거나 앱이 축소되면 도커는 앱을 종료해야 한다는 신호를 보냅니다. 앱은 이 신호를 수신하고 반응할 수 있습니다. 몇 초 후에도 앱이 종료되지 않으면 docker는 망설임 없이 앱을 종료합니다. 신호 처리기를 추가하고 server.close() 때 서버가 완벽하게 종료되지 않았지만 "만"이 새 연결 수락을 중지한다는 것을 알았습니다(https://github.com/nodejs/node/issues/2642 참조). 따라서 웹 소켓 또는 http 연결 유지와 같은 열린 연결도 닫혀 있는지 확인해야 합니다.

웹 소켓을 처리하는 방법:
nodejs 앱은 종료 신호가 수신되면 모든 웹 소켓 closeSockets 방출합니다. 클라이언트는 이 closeSockets 이벤트를 수신하고 sockets.disconnect() 및 sockets.connect() 직후에 호출합니다. 이 인스턴스가 새 요청을 수락하지 않도록 server.close() 가 호출되었음을 기억하십시오. dockerized 앱의 다른 인스턴스가 docker 내부에서 로드 밸런서를 실행하면 결국 종료되지 않은 인스턴스를 선택하고 성공적인 연결이 설정됩니다. 종료해야 하는 인스턴스에는 열린 websockets-connections가 없습니다.

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

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

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

연결 유지 HTTP 연결을 처리하는 방법:
현재로서는 이것이 어떻게 완벽하게 수행될 수 있는지 모르겠습니다. 가장 쉬운 방법은 연결 유지를 비활성화하는 것입니다.

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

또 다른 가능성은 연결 유지 시간 제한을 매우 낮은 숫자로 설정하는 것입니다. 예를 들어 0.5초.

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

이것이 다른 사람들을 도울 수 있기를 바랍니다. :)

같은 문제가 있습니다. 첨부 파일은 ecs-logs-collector 스크립트에서 생성된 모든 로그입니다.
어떤 도움을 주셔서 대단히 감사합니다 :)

수집.zip

같은 문제가 있습니다.
Docker 버전 1.13.1, 빌드 092cba3
리눅스 데비안 4.8.6-x86_64-linode78

Linux 백업 4.6.0-040600-일반 #201606100558 SMP Fri 6월 10일 10:01:15 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
서버 버전: 1.13.1

같은 문제입니다. 권한 있는 컨테이너에서 마운트를 사용하고 있습니다. 4-5번 실행하면 멈춥니다. 또한 16.04의 최신 표준 커널과 동일한 문제가 있습니다.

여러분, @etlweather 가

@rneugeba @redbaron 불행히도 현재 내가 가지고 있는 "repro"는 매우 하드웨어에 따라 다릅니다(이것이 경쟁 조건임을 증명하는 것을 제외하고는 모두). QEMU 재현을 시도하지는 않았지만 확실히 다음 단계이므로 여러 사람이 실제로 이 작업을 수행하고 예상 결과를 얻을 수 있습니다(이상적으로는 1 CPU 코어 설정에서). 누군가 이미 가지고 있다면 이메일을 보내주세요(내 프로필에 있음). 철저히 테스트하여 여기에 게시하겠습니다.

우리는 이것을 GCE에서 꽤 자주 얻습니다. Docker가 멈추고 재부팅 시 시스템이 멈춥니다.

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

컨테이너는 go 애플리케이션을 실행 중이며 hairpin 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

우분투 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 는 위에서 --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가 이 시스템에 설치되지 않았으며 한 번도 설치되지 않았다는 점은 주목할 가치가 있습니다. 커뮤니티에서 이 문제를 해결하는 데 필요한 모든 데이터를 제공하게 되어 기쁩니다. 실행할 명령만 알려주세요.

마운트된 nfs 볼륨이 매핑된 dtr을 실행하는 swarm 작업자 노드로 실행되는 centos 7.3에서 이것을 재현할 수 있습니다.

여기에 도착하는 경우

여기서 논의되는 문제는 커널 버그 이며 아직 수정되지 않았습니다. _일부_ 상황에 도움이 될 수 있는 여러 옵션이 있지만 모든 상황에는 도움이 되지 않습니다(동일한 오류를 유발하는 문제의 조합일 가능성이 높음).

"나도 이거 있어요" 댓글을 남기지 마세요

"나도 있습니다"는 버그를 해결하는 데 도움이 되지 않습니다. 문제를 해결하는 데 도움이 될 수 있는 정보가 있는 경우 에만 의견을 남겨주세요(이 경우 커널 업스트림에 패치를 제공하는 것이 가장 좋은 단계일 수 있음).

이 문제가 있음 을 알리려면 상단 설명에 있는 "좋아요" 버튼을 사용하세요.

업데이트에 대한 정보를 받고 싶다면 _구독 버튼_을 사용하세요.

여기의 모든 댓글은 3000명 이상의 사람들에게 이메일/알림을 보냅니다. 아직 해결되지 않았기 때문에 이 문제에 대한 대화를 잠그고 싶지 않지만 무시할 경우 강제될 수 있습니다.

감사 해요!

그게 다 좋은데 도움이 되는 옵션이 _정확히_ 무엇입니까? 이 문제로 인해 프로덕션에서 문제가 발생하므로 커널 버그를 해결하는 데 필요한 해결 방법은 무엇이든 하고 싶습니다.

Docker의 누군가가 Kubernetes 해결 방법을 시도할 시간이 있는 경우
알려주시면 알려드리겠습니다. 변경 사항을 추출할 수 없습니다.
지금 당장 Docker에 직접 패치하십시오.

2017년 3월 9일 목요일 오전 7:46, Matthew Newhook [email protected]
썼다:

그게 다 좋고 좋은데 도움이 되는 옵션은 정확히 무엇입니까?
이 문제로 인해 프로덕션에 문제가 발생하므로 무엇이든 하고 싶습니다.
커널 버그를 해결하는 데 필요한 해결 방법.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/5618#issuecomment-285388243 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AFVgVGdH5VX_oFWkImyo_TvlIuhmwMepks5rkB7MgaJpZM4B4L4Z
.

@thockin 감사합니다. 헤어핀 모드 해결 방법으로 Kubernetes의 PR/문제를 따르고 있었습니다. 그러나 많은 앞뒤로 이동하는 동안 해결 방법이 실제로이 문제를 제거하면 경로를 잃었습니까?
(내가 알기로는 커널에서 ref-count 불일치를 유발하는 다양한 시나리오가 있음을 이해합니다).

K8의 문제를 해결한다고 생각하는 PR을 알려주시면 최소한 기본적으로 userland-proxy를 끄는 경우에 대해 docker에서 이 패치를 적용하도록 노력하겠습니다. (그리고 도커 스트레스 재생산 단계를 사용하여 테스트할 수 있습니다.)

PR이 하나 있는지는 모르겠지만 현재 상태를 볼 수 있습니다. 시작
여기:

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

2017년 3월 11일 토요일 오후 10시 49분, Madhu Venugopal [email protected]
썼다:

@thockin https://github.com/thockin 감사합니다. 나는 따라가고 있었다
헤어핀 모드 해결 방법으로 Kubernetes의 PR/문제. 그러나 동안
많은 앞뒤로, 해결 방법 사실이 이것을 제거하면 나는 길을 잃었습니다.
문제 ?
(내가 이해하는 바와 같이 ref-count를 유발하는 다양한 시나리오가 있습니다.
커널의 불일치).

K8의 문제를 해결한다고 생각하는 PR을 알려주시면
나는 적어도 회전하는 경우에 대해 도커에서 이것을 패치하도록 노력할 것입니다.
userland-proxy는 기본적으로 꺼져 있습니다. (그리고 docker-stress를 사용하여 테스트할 수 있습니다.
재생산 단계).

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/5618#issuecomment-285926217 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AFVgVIlGs_QccxS6YYQiLNybddDzB4yUks5rk5VogaJpZM4B4L4Z
.

모두, 명확하게 말하면 "kubernetes 해결 방법"이 수행하는 모든 것은 기본 브리지에서 무차별 모드를 활성화하는 것입니다. iproute2를 사용하여 ip link set <bridgename> promisc on 동일한 결과를 얻을 수 있습니다. 버그에 걸릴 확률은 감소 하지만 완전히 제거하지는 못할 수도 있습니다.

이제 이론상 이것은 작동하지 않아야 합니다... 하지만 어떤 이유에서인지 무차별 모드는 장치 분해 속도를 충분히 느리게 만들어 참조 카운터를 줄이려는 경쟁을 하지 않는 것 같습니다. 아마도 Kurbernetes 기고자 중 한 명이 이 스레드에 있다면 여기에 끼어들 수 있습니다.

내 환경별 재현을 사용하여 해결 방법(NOT FIX)이 작동하는지 확인할 수 있습니다. IPVLAN 또는 MACVLAN 드라이버(우리는 prod에서 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 인터페이스는 쉽게 greping할 수 있도록 lodebug 로 이름이 변경되었습니다.
• dst_entry 대한 참조 카운트는 1로 시작합니다.
• 끝에 있는 dst_entry (lo에 대한 참조를 보유하고 있음)에 대한 참조 횟수는 19입니다.
• 총 dst_hold() 통화는 258041건이고 총 dst_release() 통화는 258023건입니다.
• 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()

inet_sock_destruct() 보다 총 udp_sk_rx_dst_set() 및 inet_sk_rx_dst_set() 호출이 더 많으므로 일부 소켓이 "림보" 상태에 있고 이를 방해하는 무언가가 있다고 의심됩니다.

업데이트:
소켓( struct sock )이 올바르게 생성되고 소멸되지만 일부 TCP 소켓의 경우 inet_sk_rx_dst_set() 가 동일한 dst 에서 여러 번 호출되지만 하나만 있습니다. 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 본딩 인터페이스가 있을 때 재현하기가 매우 쉬운 것 같습니다. LACP 본딩 인터페이스가 구성된 3개 노드 스웜 클러스터가 있으며 이 문제는 기본적으로 클러스터 작업을 허용하지 않습니다. 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 에서 cifs 마운트가 열려 있을 때 Docker version 17.04.0-ce, build 4845c56 가 특권 모드에서 실행되는 것을 재현할 수 있습니다. 마운트가 열린 상태에서 컨테이너가 중지되면 Docker가 응답하지 않고 kernel:[ 1129.675495] unregister_netdevice: waiting for lo to become free. Usage count = 1 -error가 발생합니다.

우분투 16.04(커널 4.4.0-78-generic)에는 여전히 문제가 있습니다. 그리고 이런 일이 발생하면 복제 시스템 호출을 통해 새 네트워크 네임스페이스를 만들려고 하는 모든 응용 프로그램이 중단됩니다.

[ 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=143658 버그가 있음을 알 수 있습니다. 이 변경으로 "수정됨":

+- [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분 후 syslog에 다음 메시지가 표시됩니다.

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

마지막으로 스크립트를 수동으로 실행한 후 몇 분 후에 발생했습니다. 내 생각에 컨테이너 삭제가 시도된 후 시간 초과가 경과하면 오류 조건이 발생합니다.

위의 스크립트가 각 오류 이후:00에 cron 작업으로 실행되기 때문에 오류 조건이 간헐적이라고 확신합니다. 다음은 syslog가 기록한 오류 출력의 샘플입니다.

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

따라서 컨테이너가 실행 및 종료된 후 2~4분 범위에서 발생하고 --rm 플래그로 인해 도커에 의해 삭제됩니다. 또한 위의 로그에서 실행/삭제된 모든 컨테이너에 오류가 없지만 꽤 일관성이 있음을 알 수 있습니다.

누군가가 이 패치가 개선되는지 확인할 수 있습니까?

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

@hlrichardson 실제로는 이렇게 생겼어요! 나는 그것을 우리의 3.16 커널로 백포트하거나 특정 서버를 업그레이드하고 내일 이 패치로 커널 4.9를 컴파일하려고 노력할 것입니다. 어떻게 진행되는지 볼 것입니다.

커밋을 확인한 후 이 패치는 참조(https://github.com/torvalds/linux/commit/0c1d70af924b966cc71e9e48920b2b635441aa50) - 4.6 커널에서 커밋되었지만 이전에도 문제가 있었습니다 :(

아, 여러 원인이 없는 한 관련이 없을 수도 있습니다(불행히도 이러한 유형의 버그가 트리거될 수 있는 방법이 여러 가지이므로 가능성이 있음).

우리는 개인적으로 여기에서 적어도 여러 문제를 해결했습니다. 그 중 일부는 다음과 같습니다.
"unregister_netdevice" 로그는 일정 시간이 지나면 사라지고
도커 컨테이너는 잘 작동하지만 다른 컨테이너에서는 모든 컨테이너가 잘 작동합니다.
멈추고 서버를 재부팅해야 합니다.

실제로 - 우리는 이러한 문제가 발생하는 서버에서 vxlan을 사용하지 않습니다.
단순 브리지 및 포트 포워딩(userland-proxy에 관계없이 발생
설정).

2017년 5월 30일 22시 54분에 "hlrichardson" [email protected]이 다음과 같이 썼습니다.

아, 그래서 여러 원인이 있지 않는 한 관련이 없을 수도 있습니다.
(불행히도 이러한 유형의 버그가 트리거될 수 있는 많은 방법이 있으므로
그것은 가능성).

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/moby/moby/issues/5618#issuecomment-304989068 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAGqoDHe1n3h9_eJ2kmeWcbhKRCX6rZoks5r_HPbgaJpZM4B4L4Z
.

네, vxlan 터널을 사용하지 않는다면 확실히 도움이 되지 않을 것입니다.

BTW, 네트워크 네임스페이스가 삭제될 때(컨테이너 종료) "unregister_netdevice" 메시지의 단일 인스턴스가 표시되면 netdevice를 참조하는 무언가가 네임스페이스와 거의 동시에 정리된 정상적인 상황으로 간주되어야 합니다.
삭제되고 있었습니다.

더 심각한 경우는 이 메시지가 10초마다 반복되고 멈추지 않는 경우입니다...
이 경우 전역 잠금은 영원히 유지되며 이 잠금은 네트워크가
네임스페이스가 추가 또는 삭제되면 네트워크 네임스페이스를 생성하거나 삭제하려는 모든 시도도
영원히 매달려 있습니다.

두 번째 유형의 문제를 쉽게 재현할 수 있는 방법이 있다면
살펴보다.

@hlrichardson 우리는 우리 서버의 무리에서 위에서 언급한 두 번째 경우, 즉 10초마다 반복되는 메시지를 보고 있습니다. 어떤 정보를 공유하시겠습니까?

yum을 사용하는 동안 centos:7 컨테이너를 테스트하고 빌드하는 동안 Fedora 25에서 이것을 봅니다. 네트워크가 이상한 방식으로 작동을 멈췄기 때문에 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

Ryan, 신뢰할 수 있는 번식 방법이 있습니까?

2017년 7월 6일 오후 4시 29분에 "Ryan Campbell" [email protected]이 다음과 같이 썼습니다.

4.12를 실행 중입니다(http://kernel.ubuntu.com/~에서).
kernel-ppa/mainline/v4.12/) 그리고 나는 여전히 이것을 쳤다. 그래서 torvalds/linux@
d747a7a https://github.com/torvalds/linux/commit/d747a7a 는 다음이 아니어야 합니다.
완전한 수정.

$ uname -r
4.12.0-041200-일반

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/moby/moby/issues/5618#issuecomment-313413120 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAdcPCbVPDjPw6va-N5dM7CjYn2W4Bodks5sLO9ZgaJpZM4B4L4Z
.

@justincormack 불행히도 공유할 수 있는 최소한의 예제는 없지만 많은 컨테이너를 생성하고 파괴하는 테스트 제품군이 있으며 일반적으로 이 문제에 waiting for lo to become free in syslog) 몇 번만 반복하면 됩니다.

@campbellr 나는 이것을 지금 세 번 재현하려고 시도했으며 이번 주에 약간의 운으로 그것에 대해 많은 시간을 보냈습니다. 나는 그럭저럭 waiting for lo to become free 메시지를 몇 번 받았지만 이후에 충돌/중단 없이 받았습니다. 네트워크 네임스페이스와 veth 인터페이스를 생성하여 테스트 케이스를 줄이려고 합니다.

테스트 스위트에서:

• 컨테이너에 많은 네트워크 활동이 있습니까? 그렇다면 어느 방향이 우세합니까?
• 어떤 종류의 머신을 실행하고 있습니까(코어 수, VM인지 등)
• 동시에 많은 컨테이너를 생성합니까?
• 컨테이너가 정상적으로 종료되거나 충돌합니까?

위의 부분적인 답변이라도 범위를 좁히는 데 도움이 될 수 있습니다...
감사 해요

@rn Docker는 일반적으로 중단되는 netlink 요청에 시간 초과를 설정하므로 더 이상 중단되지 않습니다. 그러나 새 컨테이너를 시작하거나 기존 컨테이너를 다시 시작할 수 없으며 중지 시 컨테이너 정리도 이상할 것입니다.

아직 4.12에서 테스트할 기회가 없었지만 vultr의 kvm 인스턴스에서 안정적으로 재현할 수 있었습니다. Swarm을 실행 중이고 헤드리스 크롬 작업자가 상태 확인에 실패하거나 정기적으로 충돌하면 문제가 발생합니다. 물론 이 시점에서 나는 모든 크래셔가 네트워크 오류를 깔끔하게 처리하는 등을 추적하여 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이고 응답은 약 10MB의 바이너리 blob입니다.

어떤 종류의 머신을 실행하고 있습니까(코어 수, VM인지 등)

이것은 4코어 데스크탑 머신에 있습니다(VM 없음).

동시에 많은 컨테이너를 생성합니까?

아니요, 모든 것이 순차적으로 수행됩니다.

컨테이너가 정상적으로 종료되거나 충돌합니까?

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 사용자 여러분, 커널 버전 4.12가 포함된 다음 Kubernetes AMI를 출시하기 위해 _kops_에 문제를 제기했습니다. 확인을 환영합니다: https://github.com/kubernetes/kops/issues/2901

나는 또한 호스트 커널 3.10.0-514.6.1.el7.x86_64 및 docker-ce-17.06.0.ce-1.el7.centos.x86_64가 있는 centos 7.3에서 이것을 쳤습니다.

@FrankYu 도움이되지 않습니다. 이 스레드에 유용하게 참여하려면 이 문제를 재현하는 정확한 방법을 제공하고 최신 커널에서 테스트하십시오. 3.10이 4년 전에 출시되었는데, 4일 전에 출시된 버전에서 수정되었는지 부분적으로 논의 중입니다.

@danielgusmao 우리 RancherOS 및 AWS ECS AMI Linux OS에는 이미 해당 '수정'이 있으며(기본값일 수 있음) 문제가 해결되지 않습니다. 우리는 여전히 메시지가 항상 로그에 표시되는 것을 봅니다. 아마도 유일한 희망은 커널 패치가 널리 백포트되는 것입니다. 주변을 검색했지만 RedHat/Centos/AWS Linux 버그질라 및 포럼에서 아직 심각한 진전의 증거를 볼 수 없습니다.

분명히 하자면, 메시지 자체는 양성 이고 OP가 보고한 메시지 이후의 커널 충돌입니다.

이 메시지가 나오는 코드의 주석은 무슨 일이 일어나고 있는지 설명합니다. 기본적으로 네트워크 장치의 모든 사용자(예: 컨테이너 내부의 veth 쌍 끝)는 네트워크 장치를 사용할 때 네트워크 장치 구조에서 참조 카운트를 증가시킵니다. 장치가 제거되면(예: 컨테이너가 제거될 때) 참조 카운트를 감소시키기 전에 일부 정리(예: 열린 소켓 닫기 등)를 수행할 수 있도록 각 사용자에게 알림이 표시됩니다. 이 정리는 특히 과부하(많은 인터페이스, 많은 연결 등)에서 시간이 걸릴 수 있기 때문에 커널은 때때로 메시지를 여기에 인쇄할 수 있습니다.

네트워크 장치의 사용자가 참조 카운트를 감소시키지 않으면 커널의 다른 부분이 정리를 기다리는 작업이 중단되어 충돌한다고 판단합니다. 커널 버그를 나타내는 것은 이 충돌뿐입니다(일부 사용자는 일부 코드 경로를 통해 참조 카운트를 감소시키지 않았습니다). 그런 버그가 몇 가지 있었고 현대 커널에서 수정되었습니다(그리고 아마도 이전 커널로 다시 포팅될 수 있음). 나는 그러한 충돌을 유발하기 위해 꽤 많은 스트레스 테스트를 작성했지만(그리고 계속 작성하고 있습니다) 현대 커널에서 재현할 수 없었습니다(그러나 위의 메시지는 수행함).

커널이 실제로 충돌하는 경우에만 이 문제에 대해 보고하십시오. 그러면 다음 사항에 매우 관심이 있을 것입니다.

• 커널 버전( uname -r )
• 리눅스 배포판/버전
• Linux 공급업체의 최신 커널 버전을 사용 중입니까?
• 네트워크 설정(브리지, 오버레이, IPv4, IPv6 등)
• 워크로드에 대한 설명(컨테이너 유형, 네트워크 로드 유형 등)
• 그리고 이상적으로는 단순한 재생산

감사 해요

[ @thaJeztah 제목을 kernel crash after "unregister_netdevice: waiting for lo to become free. Usage count = 3" 와 같이 변경하여 더 명확하게 만들 수 있습니까?]

커널 4.12 이상에서 수정되어야 합니다. 확인해주십시오. https://access.redhat.com/solutions/3105941
및 패치 링크 https://github.com/torvalds/linux/commit/d747a7a51b00984127a88113cdbbc26f91e9d815

@drweber 당신은 또한 곧 출시될 안정 버전(현재 4.11.12, 4.9.39, 4.4.78, 3.18.62)에서 이 패치를 찾을 수 있습니다.

@rn

네트워크 장치의 사용자가 참조 카운트를 감소시키지 않으면 커널의 다른 부분이 정리를 기다리는 작업이 중단되어 충돌한다고 판단합니다. 커널 버그를 나타내는 것은 이 충돌뿐입니다(일부 사용자는 일부 코드 경로를 통해 참조 카운트를 감소시키지 않았습니다). 그런 버그가 몇 가지 있었고 현대 커널에서 수정되었습니다(그리고 아마도 이전 커널로 다시 포팅될 수 있음). 나는 그러한 충돌을 유발하기 위해 꽤 많은 스트레스 테스트를 작성했지만(그리고 계속 작성하고 있습니다) 현대 커널에서 재현할 수 없었습니다(그러나 위의 메시지는 수행함).

커널이 실제로 충돌하는 경우에만 이 문제에 대해 보고하십시오...

우리 환경에는 약간 다른 문제가 있습니다. 이에 대한 설명이 필요합니다. (kernel 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 ) upstart를 중지하려고 시도하기 때문에 새 dockerd 프로세스를 시작하지 않습니다. 작업도 실패합니다( 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

upstart가 dockerd 재시작을 거부하거나 이전에 실행 중인 프로세스가 좀비임을 인식하는 것처럼 보이기 때문에 우리가 찾은 유일한 해결책은 호스트를 재부팅하는 것입니다.

결과는 다르게 보이지만(커널이 충돌하지 않음) 근본 원인은 같거나 비슷합니다. 그렇다면 이것은 같은 문제가 아닙니까? 이 문제가 발생할 때 docker upstart 작업을 다시 실행할 수 있게 하는 알려진 해결 방법이나 방법이 있습니까?

@campbellr 커널 4.12.2-1에 대한 접근 방식으로 이 문제를 재현할 수 있습니다.
BTW, 컨테이너가 중지되기 전에 NFS 스토리지를 마운트 해제하면 이 문제가 발생하지 않습니다.

같은 문제.

[root<strong i="6">@docker1</strong> ~]# cat /etc/redhat-release 
CentOS Linux release 7.3.1611 (Core) 
[root<strong i="7">@docker1</strong> ~]# uname  -r
3.10.0-514.26.2.el7.x86_64
[root<strong i="8">@docker1</strong> ~]# docker version
Client:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-1.12.6-32.git88a4867.el7.centos.x86_64
 Go version:      go1.7.4
 Git commit:      88a4867/1.12.6
 Built:           Mon Jul  3 16:02:02 2017
 OS/Arch:         linux/amd64

Server:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-1.12.6-32.git88a4867.el7.centos.x86_64
 Go version:      go1.7.4
 Git commit:      88a4867/1.12.6
 Built:           Mon Jul  3 16:02:02 2017
 OS/Arch:         linux/amd64

안녕하세요,

이 버그를 재현하는 데 필요한 설정이 포함된 https://github.com/piec/docker-samba-loop 및 https://github.com/piec/docker-nfs-loop 2개의 저장소를 방금 만들었습니다.

내 결과:

• 4.11.3-1-ARCH(Arch Linux) 커널: 몇 번의 반복(<10)으로 docker-samba-loop 로 버그를 생성합니다. docker-nfs-loop 재현할 수 없습니다.
• 4.11.9-1-ARCH 동일한 결과( 버전 )
• 4.12.3-1-ARCH(테스트 저장소) 동일한 결과
• 4.11.11-coreos: docker-samba-loop 대한 동일한 결과, docker-nfs-loop 시도하지 않음

도움이 되었기를 바랍니다
건배

해결 방법은 제 경우에는 --net=host 를 사용하는 것입니다. 하지만 항상 받아들일 수 있는 해결책은 아닙니다

@piec , 자세한 내용에 감사드립니다. 이 긴 댓글 끝에 몇 가지 질문이 더 있습니다.

SMB 설정을 사용하여 다른 커널로 많은 것을 생성할 수 있었습니다. NFS 설정에서도 이것을 시도했지만 주사위는 없습니다.

모든 테스트는 2개의 vCPU와 2GB의 메모리로 구성된 VM이 있는 HyperKit에서 docker 17.06.1-ce로 실행됩니다(Mac용 Docker를 사용하지만 중요하지 않음). 저는 LinuxKit 커널을 사용하고 있습니다. 쉽게 교체할 수 있기 때문입니다.

나는 수정 된 Dockerfile 나는에 대한 호출에 추가한다는 점에서 date 에 첫 번째 명령이 실행도 추가로 전화를 date 전에 andeafter docker run 에 대한 고객.

실험 1(4.9.39 커널)

4.9.39(최신 4.9.x 안정 커널)에서 커널 충돌이 발생합니다.

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

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

그리고 dmesg :

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

unregister_netdevice 메시지(아래 참조)를 포함하여 4.11.12 커널이 수행하는 작업을 여러 번 반복한 다음 위의 커널 충돌이 발생하는 경우가 있습니다. 때때로 다음과 같이 충돌에 대한 약간의 변형을 볼 수 있습니다.

[  715.926694] BUG: unable to handle kernel paging request at 00000000fffffdc9
[  715.927380] IP: [<ffffffff8664ea95>] sk_filter_uncharge+0x5/0x31
[  715.927868] PGD 0 [  715.928022]
[  715.928174] Oops: 0000 [#1] SMP
[  715.928424] Modules linked in:
[  715.928703] CPU: 0 PID: 2665 Comm: runc:[0:PARENT] Not tainted 4.9.39-linuxkit #1
[  715.929321] Hardware name:   BHYVE, BIOS 1.00 03/14/2014
[  715.929765] task: ffff931538ef4140 task.stack: ffffbcbbc0214000
[  715.930279] RIP: 0010:[<ffffffff8664ea95>]  [<ffffffff8664ea95>] sk_filter_uncharge+0x5/0x31
[  715.931043] RSP: 0018:ffffbcbbc0217be0  EFLAGS: 00010206
[  715.931487] RAX: 0000000000000000 RBX: ffff931532a662a8 RCX: 0000000000000006
[  715.932043] RDX: 00000000ffffffff RSI: 00000000fffffdb1 RDI: ffff931532a66000
[  715.932612] RBP: ffff931532a66000 R08: 0000000000000000 R09: 0000000000000000
[  715.933181] R10: ffff9315394f2990 R11: 000000000001bb68 R12: ffff931532a66000
[  715.933725] R13: ffff9315328060a8 R14: ffff931532a66340 R15: 0000000000000000
[  715.934258] FS:  0000000000000000(0000) GS:ffff93153c600000(0000) knlGS:0000000000000000
[  715.934857] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  715.935286] CR2: 00000000fffffdc9 CR3: 0000000052c09000 CR4: 00000000000406b0
[  715.935822] Stack:
[  715.935974]  ffffffff86625054 ffff931532806000 ffffbcbbc0217c58 ffff931532a66000
[  715.936560]  ffffffff8674ed37 0100000800000282 0000000000000000 0000000000000000
[  715.937173]  5de0b9a3a313c00b ffff9315346f5080 ffff9315394f2990 ffff9315346f50b0
[  715.937751] Call Trace:
[  715.937982]  [<ffffffff86625054>] ? __sk_destruct+0x35/0x133
[  715.938608]  [<ffffffff8674ed37>] ? unix_release_sock+0x180/0x212
[  715.939130]  [<ffffffff8674ede2>] ? unix_release+0x19/0x25
[  715.939517]  [<ffffffff8662034c>] ? sock_release+0x1a/0x6c
[  715.939907]  [<ffffffff866203ac>] ? sock_close+0xe/0x11
[  715.940277]  [<ffffffff861f8710>] ? __fput+0xdd/0x17b
[  715.940635]  [<ffffffff860f604d>] ? task_work_run+0x64/0x7a
[  715.941072]  [<ffffffff860e148a>] ? do_exit+0x42a/0x8e0
[  715.941472]  [<ffffffff8674edfa>] ? scm_destroy+0xc/0x25
[  715.941880]  [<ffffffff867504e0>] ? unix_stream_sendmsg+0x2dd/0x30b
[  715.942357]  [<ffffffff860e19aa>] ? do_group_exit+0x3c/0x9d
[  715.942780]  [<ffffffff860eac41>] ? get_signal+0x45d/0x4e2
[  715.943210]  [<ffffffff86621640>] ? sock_sendmsg+0x2d/0x3c
[  715.943618]  [<ffffffff8602055a>] ? do_signal+0x36/0x4c9
[  715.944017]  [<ffffffff861f64c7>] ? __vfs_write+0x8f/0xcc
[  715.944416]  [<ffffffff861f7100>] ? vfs_write+0xbb/0xc7
[  715.944809]  [<ffffffff8600326c>] ? prepare_exit_to_usermode+0x64/0xa4
[  715.945295]  [<ffffffff867d2884>] ? entry_SYSCALL_64_fastpath+0xa7/0xa9
[  715.945789] Code: 08 4c 89 e7 e8 fb f8 ff ff 48 3d 00 f0 ff ff 77 06 48 89 45 00 31 c0 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 1f 44 00 00 <48> 8b 46 18 8b 40 04 48 8d 04 c5 28 00 00 00 f0 29 87 24 01 00
[  715.947701] RIP  [<ffffffff8664ea95>] sk_filter_uncharge+0x5/0x31
[  715.948112]  RSP <ffffbcbbc0217be0>
[  715.948292] CR2: 00000000fffffdc9
[  715.948467] ---[ end trace 2d69bea56725fd5f ]---
[  715.948722] Kernel panic - not syncing: Fatal exception
[  715.949059] Kernel Offset: 0x5000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[  715.949595] Rebooting in 120 seconds..

충돌은 유닉스 도메인 소켓 코드에 있으며 다음과 유사/동일합니다.
여기 에 보고되었지만 이 새로운 테스트 케이스를 사용하면 재현하기가 훨씬 쉽습니다.

실험 2(4.11.12 커널)

4.11.12(4.11 시리즈의 최신 안정 버전)에서는 충돌이 없지만 정말 느립니다( ---> 인라인 주석).

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

---> First iteration takes one second

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

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

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

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

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

---> Fourth iteration fails after two minutes

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

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

나는 같은 패턴이 반복되는 한 시간 정도 이것을 실행 했지만 커널 충돌은 없었습니다.

내가 보는 커널 로그는 다음과 같습니다.

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

10초마다 하는 메시지입니다.

이로 인해 한 시간 후에도 중단된 작업 감지가 시작되지 않기 때문에 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 커널)

다음으로 각 docker run 다음에 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 에서 약 200초 분량의 unregister_netdevice 를 얻는 것 같습니다(두 번째 제외). 나는 그 시간 동안 새로운 컨테이너를 시작할 수 없다고 생각합니다(실험 2에서 알 수 있듯이. 중단된 작업 감지가 시작되지 않는 것이 궁금합니다. 아마도 중단된 작업이 없기 때문일 것입니다.

실험 5(커널에서 추가 디버깅을 활성화한 4.11.12/4.9.39)

docker run 사이에 1초 절전 모드로 되돌아갑니다.

추가 디버그를 가능하게 하는 또 다른 커널이 있습니다.
LOCKDEP , RCU_TRACE , LOCKUP_DETECTOR 및 몇 가지 옵션과 같은
더.

이러한 디버그 옵션이 활성화된 상태에서 repro 4.11.12 커널을 실행해도 아무 것도 트리거되지 않았습니다.

일반 커널이 충돌하는 4.9.39 커널도 마찬가지입니다. 디버그 옵션은 타이밍을 약간 변경하므로 유닉스 도메인 소켓 코드의 충돌이 경쟁으로 인한 것임을 보여주는 추가 단서일 수 있습니다.

조금 더 깊이 파고들어

strace 다양한에서 containerd 프로세스는 (그것을 도움이되지 않습니다
일반적으로 Go로 작성되었기 때문이 아닙니다. 긴 포장마차가 많다
futex(...FUTEX_WAIT...) 위치/이유에 대한 정보 포함).

sysrq :

자세한 정보 증가:

echo 9 > /proc/sysrq-trigger

모든 CPU의 스택 추적:

echo l > /proc/sysrq-trigger
[ 1034.298202] sysrq: SysRq : Show backtrace of all active CPUs
[ 1034.298738] NMI backtrace for cpu 1
[ 1034.299073] CPU: 1 PID: 2235 Comm: sh Tainted: G    B           4.11.12-linuxkit #1
[ 1034.299818] Hardware name:   BHYVE, BIOS 1.00 03/14/2014
[ 1034.300286] Call Trace:
[ 1034.300517]  dump_stack+0x82/0xb8
[ 1034.300827]  nmi_cpu_backtrace+0x75/0x87
[ 1034.301200]  ? irq_force_complete_move+0xf1/0xf1
[ 1034.301633]  nmi_trigger_cpumask_backtrace+0x6e/0xfd
[ 1034.302097]  arch_trigger_cpumask_backtrace+0x19/0x1b
[ 1034.302560]  ? arch_trigger_cpumask_backtrace+0x19/0x1b
[ 1034.302989]  sysrq_handle_showallcpus+0x17/0x19
[ 1034.303438]  __handle_sysrq+0xe4/0x172
[ 1034.303826]  write_sysrq_trigger+0x47/0x4f
[ 1034.304210]  proc_reg_write+0x5d/0x76
[ 1034.304507]  __vfs_write+0x35/0xc8
[ 1034.304773]  ? rcu_sync_lockdep_assert+0x12/0x52
[ 1034.305132]  ? __sb_start_write+0x152/0x189
[ 1034.305458]  ? file_start_write+0x27/0x29
[ 1034.305770]  vfs_write+0xda/0x100
[ 1034.306029]  SyS_write+0x5f/0xa3
[ 1034.306283]  entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 1034.306638] RIP: 0033:0x7fa4810488a9
[ 1034.306976] RSP: 002b:00007fffd3a29828 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 1034.307567] RAX: ffffffffffffffda RBX: 000000c6b523a020 RCX: 00007fa4810488a9
[ 1034.308101] RDX: 0000000000000002 RSI: 000000c6b5239d00 RDI: 0000000000000001
[ 1034.308635] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 1034.309169] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[ 1034.309700] R13: 0000000000000000 R14: 00007fffd3a29988 R15: 00007fa481280ee0
[ 1034.310334] Sending NMI from CPU 1 to CPUs 0:
[ 1034.310710] NMI backtrace for cpu 0 skipped: idling at pc 0xffffffffa0922756

여기에는 아무것도 없습니다. CPU1은 유휴 상태이고 CPU0은 sysrq를 처리하고 있습니다.

차단된 작업 표시(2회)

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 콘솔 액세스 권한이 있고 크래시 덤프와 관련하여 뭔가가 있는지 볼 수 있습니까? 아니면 내가 보는 것처럼 엄청난 지연이 보입니까? 크래시 덤프가 있다면 보고 싶습니다. 또한 베어 메탈 또는 VM에서 실행 중입니까? CPU 및 메모리 측면에서 구성은 무엇입니까?

@rn 조사에 감사드립니다!

저는 베어메탈 데스크탑 PC에서 실행 중이므로 모든 것에 액세스할 수 있습니다. i7-4790K + 32GiB입니다.
현재 저는 최신 Arch Linux + 테스트 저장소(4.12.3-1-ARCH)의 커널에서 실행 중입니다.

제 경우에는 실험 2(4.11.12 커널)에서 설명한 대로 모든 것이 작동합니다.

• client-smb 컨테이너가 존재하면 4분 이상 동안 새 컨테이너를 실행하는 것이 불가능합니다.
• 커널 충돌이 발생하지 않습니다.
• client-smb가 종료된 후 4분 이상 지연된 후 새 컨테이너를 실행하려고 하면 unregister_netdevice: waiting for lo to become free. Usage count = 1 메시지가 반복적으로 나타납니다. 그리고 4분의 시간 경과에 새 컨테이너를 실행하는 경우에만 나타납니다. 이 4분 후에 새 컨테이너를 실행하는 것은 "정상"입니다.

그래서 네트워크 인터페이스와 관련된 smb-client 컨테이너의 정리 프로세스 어딘가에 문제가 있다고 가정합니다.

실제로 이 문제에 대한 훨씬 간단한 재현이 있습니다(BTW는 원래 문제가 아님 ).

이 스크립트는 호스트에서 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 또한 마운트 해제 후 Dockerfile에서 귀하의 repro 및 sleep 1 로 이것을 테스트했으며 모든 것이 지연 없이 unregister_netdev 메시지 없이 예상대로 작동합니다.

지금 이것을 작성하여 netdev@vger 보내겠습니다.

훌륭한
마운트 해제 후 sleep 가 내 설정에서 지연 및 unregister_netdev 메시지를 수정했음을 확인합니다.

umount 는 netns에 상대적인 비동기 작업을 생성하여 해당 작업이 완료되기 전에 netns가 제거되면 차단되고 결국 시간 초과된다고 생각하지 않습니까? 마운트 후 절전 모드에서는 netns가 제거되기 전에 이 작업이 완료됩니다.
하지만 그건 가설일 뿐이야

나는 마운트를 해제하지 않고 시도했지만 동일한 차이점이 있습니다. 네트워크 네임스페이스를 삭제하는 것입니다. 9그리고 마운트 네임스페이스를 제거하면 어쨌든 마운트 해제가 트리거됩니다.

그래

그건 그렇고, smb를 사용하여 다른 컴퓨터에서 실수로 (개발 중) 문제를 다시 재현했습니다. Ubuntu 16.04 PC, 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 예, 예상됩니다.

또한 이 버그가 발생하여 Ubuntu 커널 이미지의 @piec 에서 docker-samba-loop 메서드를 사용하여 Oopses를 재현할 수 있었습니다.

• linux-image-4.4.0-93-generic
• linux-image-4.10.0-1004-gcp
• linux-image-4.10.0-32-generic
• linux-image-4.11.0-14-일반
• linux-image-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 감사합니다. 실제로 재현하는 데 도커가 전혀 필요하지 않습니다. 네트워크 네임스페이스에서 삼바 클라이언트를 실행하면 https://github.com/moby/moby/issues/5618#issuecomment -318681443에 따라 트릭을 수행할 수

@rn 정보 감사합니다. 나는 아직 그렇게 시도하지 않았습니다.

여기와 netdev 메일링리스트의 최근 게시물은 커널 중단에 관한 것 같습니다.
커널 4.11 및 4.12에서도 커널 충돌이 발생합니다.

이와 매우 유사한 문제가 있습니다(#35068에 자세히 설명됨). 기본적으로 분산 배치 전략을 사용하여 4개의 복제본으로 단일 서비스를 실행하는 2노드 스웜을 실행합니다.

이러한 각 서비스 컨테이너에서 호스트 docker.sock을 볼륨으로 마운트하고 컨테이너 내에서 컨테이너당 최대 4개의 동시성을 사용하여 docker run 명령을 실행합니다. 그 결과 최대 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_ 포함) 및 다음 부팅 커널 옵션을 사용하여 하나의 CPU에서만 실행:

BOOT_IMAGE=/boot/vmlinuz-4.14.0-rc3 root=/dev/mapper/vg0-root ro 조용한 vsyscall=nosmp 에뮬레이트

이 상태에 도달하면 이 상태를 유지하고 재부팅이 필요합니다. 더 이상 컨테이너를 생성할 수 없습니다. ipsec/openvpn 연결을 수행하는 이미지를 실행하고 터널 내부에 작은 파일을 다운로드하여 재생산합니다. 그런 다음 인스턴스가 존재합니다(일반적으로 10초 미만으로 실행됨). 우리는 한 기계에서 분당 10개의 이러한 컨테이너를 실행합니다. 위에서 언급한 설정(1cpu만)을 사용하면 기기가 ~2시간 안에 작동합니다.

동일한 커널을 사용하지만 CPU 수를 제한하지 않는 또 다른 재생기는 컨테이너 내에서 UDP 모드에서 iperf를 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 전용, 기본 Docker 설정에 따라 NAT됨

워크로드에 대한 설명(컨테이너 유형, 네트워크 로드 유형 등): 종료하기 전에 스크립트를 실행하는 매우 짧은 수명의 컨테이너(몇 초에서 몇 분까지).

그리고 이상적으로는 단순한 재생산:

**커널:[617624.412100] unregister_netdevice: lo가 해제되기를 기다립니다. 사용 횟수 = 1

영향을 받는 노드에서 이전 컨테이너를 종료하거나 새 컨테이너를 시작할 수 없습니다. 기능을 복원하려면 재부팅해야 했습니다.**

곧 근본 원인/패치를 찾을 수 있기를 바랍니다.

친애하는,

롭풋796

@campbellr
네트워킹 스토리지와 관련이 있는 것으로 보입니다. kubernetes에서 영구 볼륨으로 ceph krbd를 사용하고 있습니다.
그리고 장기간 컨테이너 크래시를 실행한 후 상황을 재현할 수 있습니다.

이 문제는 10일 전에 할당되었으며 현재 진행 중입니다. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407 에서 진행 중인 일에 대한 자세한 정보를 볼 수 있습니다.

Dan Streetman이 이 문제를 해결하는 방법을 찾길 바랍니다.

Oops는 커밋 76da0704507bbc51875013f6557877ab308cfd0a에 의해 수정된 커널 버그로 인해 발생합니다.

ipv6: NETDEV_UNREGISTER에 대해 ip6_route_dev_notify()를 한 번만 호출합니다.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76da0704507bbc51875013f6557877ab308cfd0a
("kernel:unregister_netdevice: lo가 해제되기를 기다리는 중입니다. Usage count = 2" 문제가 아니라 커널 패닉을 고칠 뿐입니다.)

(GitHub가 오래된 주석을 숨기고 있기 때문에 여기에서 다시 반복)

여기에 도착하는 경우

여기서 논의되는 문제는 커널 버그 이며 아직 완전히 수정되지 않았습니다. 이 문제의 _some_ 발생을 수정하는 일부 패치가 커널에 포함되었지만 다른 패치는 아직 해결되지 않았습니다.

_일부_ 상황에 도움이 될 수 있는 여러 옵션이 있지만 모든 상황에 도움이 되는 것은 아닙니다(다시 말하지만, 동일한 오류를 유발하는 문제의 조합일 가능성이 큽니다)

"나도 이거 있어요" 댓글을 남기지 마세요

"나도 있습니다"는 버그를 해결하는 데 도움이 되지 않습니다. 문제를 해결하는 데 도움이 될 수 있는 정보가 있는 경우 에만 의견을 남겨주세요(이 경우 커널 업스트림에 패치를 제공하는 것이 가장 좋은 단계일 수 있음).

이 문제가 있음 을 알리려면 상단 설명에 있는 "좋아요" 버튼을 사용하세요.

업데이트에 대한 정보를 받고 싶다면 _구독 버튼_을 사용하세요.

여기의 모든 댓글은 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

축하를 망치게 해서 미안하지만 문제를 재현할 수 있었습니다. 우리는 지금 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/ 에서 @ddstreet 와 함께 작업하고 있습니다 .

해결 방법이 없나요?

호스트 네트워킹을 사용하십시오(컨테이너 가치의 많은 부분을 파괴하지만 거기에 있습니다).

@pumba-lt 약 1.5년 전에 이 문제가 있었고 약 1년 전에 커널 수준(sysctl 아님)에서 ipv6을 비활성화했으며 한 번도 문제가 발생하지 않았습니다. 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을 비활성화한 후 문제가 해결되었음을 확인할 수 있습니다(grub의 구성 파일에서). 7노드 클러스터에서 수많은 문제가 있었지만 이제 원활하게 실행됩니다.

솔루션을 어디에서 찾았는지 기억이 나지 않거나 스스로 찾았습니다. 어쨌든 다른 사람들에게 이것을 제안해 준 @qrpike 에게 감사드립니다 :) !!

https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.114

커밋 edaafa805e0f9d09560a4892790b8e19cab8bf09
저자: Dan Streetman [email protected]
날짜: 2018년 1월 18일 목요일 16:14:26 -0500

net: tcp: close sock if net namespace is exiting


[ Upstream commit 4ee806d51176ba7b8ff1efd81f271d7252e03a1d ]

When a tcp socket is closed, if it detects that its net namespace is
exiting, close immediately and do not wait for FIN sequence.

For normal sockets, a reference is taken to their net namespace, so it will
never exit while the socket is open.  However, kernel sockets do not take a
reference to their net namespace, so it may begin exiting while the kernel
socket is still open.  In this case if the kernel socket is a tcp socket,
it will stay open trying to complete its close sequence.  The sock's dst(s)
hold a reference to their interface, which are all transferred to the
namespace's loopback interface when the real interfaces are taken down.
When the namespace tries to take down its loopback interface, it hangs
waiting for all references to the loopback interface to release, which
results in messages like:

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

These messages continue until the socket finally times out and closes.
Since the net namespace cleanup holds the net_mutex while calling its
registered pernet callbacks, any new net namespace initialization is
blocked until the current net namespace finishes exiting.

After this change, the tcp socket notices the exiting net namespace, and
closes immediately, releasing its dst(s) and their reference to the
loopback interface, which lets the net namespace continue exiting.

Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=97811
Signed-off-by: Dan Streetman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

netns에서 SCTP를 사용하면 4.16-rc1의 수정 사항도 트리거될 수 있습니다.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a31a6b19f9ddf498c81f5c9b089742b7472a6f8
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=957d761cf91cdbb175ad7d8f5472336a4d54dbf2

커널 버전을 4.4.118로, 도커 버전을 17.09.1-ce로 업그레이드했지만 "unregister_netdevice: eth0이 해제되기를 기다리고 있습니다. Usage count = 1"이 여전히 발생했습니다. 커널 수준에서 ipv6을 비활성화해야 할 수도 있습니다. 클라우드 작업을 바랍니다.

@ wuming5569 해당 버전의 Linux에서 작동하는지 알려주십시오.

@ wuming5569 아마도 커널 4.4.114 수정 "unregister_netdevice: lo가 해제되기를 기다리고 있습니다. 사용 횟수 = 1"이 아니라 "unregister_netdevice: eth0이 해제되기를 기다리고 있습니다. 사용 횟수 = 1"을 수정하십시오.
프로덕션에서 테스트했습니다.
@ddstreet 피드백입니다. 도움이

@wuming5569 위에서 언급한 것처럼 메시지 자체는 수 있습니다 . 커널이 멈추나요? 그렇다면 네트워크 패턴은 무엇입니까, 즉 컨테이너가 수행하는 네트워킹 유형은 무엇입니까?

CentOS에서 동일한 문제가 발생했습니다. 내 커널은 3.10.0-693.17.1.el7.x86_64입니다. 그러나 syslog에서 비슷한 스택 추적을 얻지 못했습니다.

Centos7 커널 3.10.0-514.21.1.el7.x86_64 및 docker 18.03.0-ce에서 동일

@danielefranceschi 최신 CentOS 커널(최소 3.10.0-693)로 업그레이드하는 것이 좋습니다. 문제가 해결되지는 않지만 훨씬 덜 자주 발생하는 것 같습니다. 커널 3.10.0-327 및 3.10.0-514에서 스택 추적을 보았지만 제 기억으로는 3.10.0-693에서 스택 추적을 본 적이 없는 것 같습니다.

@alexhexabeam 3.10.0-693은 완벽하게 작동하는 것 같습니다, tnx :)

CentOS7 커널 4.16.0-1.el7.elrepo.x86_64 및 docker 18.03.0-ce에서 동일

충돌이 발생하기 몇 주 전에 작동했으며 최대로 시도할 때 완전히 멈췄습니다.

커널 3.10.0-693.21.1.el7에서도 문제가 발생했습니다.

다음에서도 발생함을 확인할 수 있습니다.

리눅스 3.10.0-693.17.1.el7.x86_64
Red Hat Enterprise Linux Server 릴리스 7.4(Maipo)

일정량의 부하가 걸린 상태에서 "서비스 도커 재시작"을 하면 재현할 수 있습니다.

@wuming5569 이 문제를 해결하셨습니까? 네트워크 유형이 무엇입니까? 우리는 몇 주 동안 이 문제로 혼란스러워했습니다.
위챗 계정이 있습니까?

4admin2root, 언급한 수정 사항을 감안할 때 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.114 ,

적절한 최신 커널이 설치된 경우 docker 데몬에 대한 userland 프록시를 비활성화하는 것이 안전합니까? 에서 유래한 것인지는 명확하지 않다.

https://github.com/moby/moby/issues/8356
https://github.com/moby/moby/issues/11185

둘 다 커널 수정보다 오래되었으므로

감사합니다

우리는 몇 주 동안 이 문제로 혼란스러워했습니다.
리눅스 3.10.0-693.17.1.el7.x86_64
CentOS Linux 릴리스 7.4.1708(코어)

최신 4.14 커널에 이 문제가 있는지 확인할 수 있는 사람이 있습니까? 그렇지 않은 것 같습니다. 인터넷에서 4.14 커널에서 이 문제에 직면한 사람은 아무도 없었습니다.

4.15.15-1 커널, Centos7에서 이것을 봅니다.

변경 로그를 보면 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.15.8 에 SCTP에 대한 수정 사항이 있지만 TCP에는 수정 사항이 없습니다. 따라서 최신 4.14를 사용해 보는 것이 좋습니다.

• 4.15.18도 이 버그에 도움이 되지 않습니다.
• ipv6을 비활성화해도 도움이되지 않습니다.

이제 4.16.13으로 업그레이드되었습니다. 관찰. 이 버그는 한 노드에서 일주일에 한 번 정도만 발생했습니다.

grub 부트 매개변수 또는 sysctl에서 ipv6을 비활성화했습니까? 부팅 매개변수만 작동합니다. Sysctl이 수정하지 않습니다.

2018년 6월 4일 오후 12시 99분 53초에 Sergey Pronin( [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 데비안 커널. 재생할 수 있는.

@qrpike 당신이 맞습니다. 우리는 sysctl만 시도했습니다. grub을 사용해 보겠습니다. 감사 해요!

제 경우에는 ipv6을 비활성화해도 아무런 차이가 없었습니다.

@spronin-aurea 부트 로더에서 ipv6을 비활성화하는 것이 도움이 되었습니까?

@qrpike ipv6 비활성화가 귀하의 경우에 도움이 되었다면 사용 중인 노드에 대해 알려주실 수 있습니까? 커널 버전, k8s 버전, CNI, 도커 버전 등

@komljen 저는 지난 2년 동안 단 한 건의 사고도 없이 CoreOS를 사용해 왔습니다. ~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에서 아직 이 문제가 발생하지 않습니다.

4.17.3-1 커널이 있는 Centos 7.5에도 여전히 문제가 있습니다.

환경:
쿠버네티스 1.10.4
도커 13.1
Flannel 네트워크 플러그인으로.

통나무 :
[ 89.790907] IPv6: ADDRCONF(NETDEV_UP): eth0: 링크가 준비되지 않았습니다.
[ 89.798523] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: 링크가 준비됨
[ 89.799623] cni0: 포트 8(vethb8a93c6f)이 차단 상태에 들어갔습니다.
[ 89.800547] cni0: 포트 8(vethb8a93c6f)이 비활성화 상태가 됨
[ 89.801471] 장치 vethb8a93c6f가 무차별 모드에 들어갔습니다.
[ 89.802323] cni0: 포트 8(vethb8a93c6f)이 차단 상태에 들어갔습니다.
[ 89.803200] cni0: 8번 포트(vethb8a93c6f)가 포워딩 상태가 됨

kernel:unregister_netdevice : lo가

지금 :
노드 IP는 도달할 수 있지만 ssh와 같은 네트워크 서비스를 사용할 수 없습니다...

여기의 증상은 다른 여러 곳에서 보고된 많은 내용과 유사합니다. 모두 네트워크 네임스페이스와 관련이 있습니다. unshare -n 가 중단되는지 확인하고, 그렇다면 다른 터미널에서 공유 해제 프로세스의 cat /proc/$pid/stack 를 수행하여 copy_net_ns() 에서 중단되는지 확인할 수 있습니까? 이것은 여기에서 발견된 일부 역추적을 포함하여 많은 문제에 대한 공통 분모인 것 같습니다. 4.16과 4.18 사이에 Kirill Tkhai가 관련 잠금을 리팩토링한 많은 패치가 있었습니다. 영향을 받는 배포판/커널 패키지 관리자는 안정적인 커널에 적용/백포팅하는 방법을 살펴보고 도움이 되는지 확인해야 합니다.
참조: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779678

@블럽

sudo cat /proc/122355/stack
[<ffffffff8157f6e2>] copy_net_ns+0xa2/0x180
[<ffffffff810b7519>] create_new_namespaces+0xf9/0x180
[<ffffffff810b775a>] unshare_nsproxy_namespaces+0x5a/0xc0
[<ffffffff81088983>] SyS_unshare+0x193/0x300
[<ffffffff816b8c6b>] tracesys+0x97/0xbd
[<ffffffffffffffff>] 0xffffffffffffffff

4.18의 잠금 변경 사항을 감안할 때 현재 4.18rc를 테스트하는 것이 좋습니다. 특히 더 또는 덜 안정적으로 트리거할 수 있는 경우 커널 버전을 변경하면 이러한 일이 발생할 가능성도 변경된 많은 사람들이 있습니다. 많이.

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_mutex ( cleanup_net , net_ns_barrier , net_ns_init , {,un}register_pernet_{subsys,device} ). 안정적인 커널의 경우 4.18의 모든 잠금 변경 사항을 백포팅하는 것보다 고정될 수 있는 방식으로 교착 상태가 한 가지만 있다면 훨씬 더 쉬울 것입니다. 그러나 지금까지 나는 근본 원인으로 이어지는 흔적을 보지 못했습니다. 도움이 될지 모르겠지만 문제가 나타날 때 위의 기능이 있는 다른 /proc/*/stack 가 표시될 수 있습니까?

같은 문제! 내 환경은 데비안 8입니다.

RHEL, SWARM, 18.03.0-ce

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]#
   7월 19일 11:56:03에 syslogd@se1-shub-t002의 메시지 ...
   kernel:unregister_netdevice : lo가

몇 분 후에 관리자 노드의 콘솔로 돌아가서 시작된 컨테이너가 더 이상 실행되지 않습니다.

이것은 동일한 문제를 설명합니까 아니면 다른 "문제 모음"입니까?

미리 THX!

업데이트
이것은 ssh 콘솔(swarm manager bash에서)에서도 직접 발생합니다.

업데이트
호스트 시스템(군집에 있는 하나의 관리자 노드):
Linux [MACHINENNAME] 3.10.0-514.2.2.el7.x86_64 #1 SMP 수 11월 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
우나메 -a
4.1.12-124.16.1.el7uek.x86_64 #2 SMP 월요일 6월 11일 20:09:51 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux
도커 정보
컨테이너: 9
달리기: 5
일시중지: 0
중지됨: 4
이미지: 6
서버 버전: 17.06.2-ol

dmesg
[2238374.718889] unregister_netdevice: lo가 해제되기를 기다립니다. 사용 횟수 = 1
[2238384.762813] unregister_netdevice: lo가 해제되기를 기다립니다. 사용 횟수 = 1
[2238392.792585] eth0: vethbed6d59에서 이름 변경

(GitHub가 오래된 주석을 숨기고 있기 때문에 https://github.com/moby/moby/issues/5618#issuecomment-351942943 여기에서 다시 반복)

여기에 도착하는 경우

여기서 논의되는 문제는 커널 버그 이며 아직 완전히 수정되지 않았습니다. 이 문제의 _some_ 발생을 수정하는 일부 패치가 커널에 포함되었지만 다른 패치는 아직 해결되지 않았습니다.

_일부_ 상황에 도움이 될 수 있는 여러 옵션이 있지만 모든 상황에 도움이 되는 것은 아닙니다(다시 말하지만, 동일한 오류를 유발하는 문제의 조합일 가능성이 큽니다)

"unregister_netdevice: lo가 해제되기를 기다리는 중" 오류 자체는 버그가 아닙니다.

커널 충돌 _after_이면 버그입니다(아래 참조).

"나도 이거 있어요" 댓글을 남기지 마세요

"나도 있습니다"는 버그를 해결하는 데 도움이 되지 않습니다. 문제를 해결하는 데 도움이 될 수 있는 정보가 있는 경우 에만 의견을 남겨주세요(이 경우 커널 업스트림에 패치를 제공하는 것이 가장 좋은 단계일 수 있음).

이 문제가 있음 을 알리려면 상단 설명에 있는 "좋아요" 버튼을 사용하세요.

업데이트에 대한 정보를 받고 싶다면 _구독 버튼_을 사용하세요.

여기의 모든 댓글은 3000명 이상의 사람들에게 이메일/알림을 보냅니다. 아직 해결되지 않았기 때문에 이 문제에 대한 대화를 잠그고 싶지 않지만 무시할 경우 강제될 수 있습니다.

스레드를 (약간) 단축하기 위해 유용한 정보를 추가하지 않은 주석은 제거합니다.

이 문제를 해결하는 데 도움이 되고 싶다면

• 숨겨진 주석을 포함하여 전체 스레드를 읽으십시오 . 길고 github는 주석을 숨깁니다(따라서 주석을 다시 표시하려면 클릭해야 함). 이 스레드에 이미 도움이 될 수 있는 정보가 많이 있습니다.

• 도움이 될 수 있는 정보는 https://github.com/moby/moby/issues/5618#issuecomment -316297818(및 당시의 댓글) 댓글을 읽어보세요.

분명히 하자면, 메시지 자체는 양성 이고 OP가 보고한 메시지 이후의 커널 충돌입니다.

이 메시지가 나오는 코드의 주석은 무슨 일이 일어나고 있는지 설명합니다. 기본적으로 네트워크 장치의 모든 사용자(예: 컨테이너 내부의 veth 쌍 끝)는 네트워크 장치를 사용할 때 네트워크 장치 구조에서 참조 카운트를 증가시킵니다. 장치가 제거되면(예: 컨테이너가 제거될 때) 참조 카운트를 감소시키기 전에 일부 정리(예: 열린 소켓 닫기 등)를 수행할 수 있도록 각 사용자에게 알림이 표시됩니다. 이 정리는 특히 과부하(많은 인터페이스, 많은 연결 등)에서 시간이 걸릴 수 있기 때문에 커널은 때때로 메시지를 여기에 인쇄할 수 있습니다.

네트워크 장치의 사용자가 참조 카운트를 감소시키지 않으면 커널의 다른 부분이 정리를 기다리는 작업이 중단되어 충돌한다고 판단합니다. 커널 버그를 나타내는 것은 이 충돌뿐입니다(일부 사용자는 일부 코드 경로를 통해 참조 카운트를 감소시키지 않았습니다). 그런 버그가 몇 가지 있었고 현대 커널에서 수정되었습니다(그리고 아마도 이전 커널로 다시 포팅될 수 있음). 나는 그러한 충돌을 유발하기 위해 꽤 많은 스트레스 테스트를 작성했지만(그리고 계속 작성하고 있습니다) 현대 커널에서 재현할 수 없었습니다(그러나 위의 메시지는 수행함).

* 커널이 실제로 충돌하는 경우에만 이 문제에 대해 보고하십시오. * 그러면 다음 사항에 매우 관심이 있습니다.

• 커널 버전( uname -r )
• 리눅스 배포판/버전
• Linux 공급업체의 최신 커널 버전을 사용 중입니까?
• 네트워크 설정(브리지, 오버레이, IPv4, IPv6 등)
• 워크로드에 대한 설명(컨테이너 유형, 네트워크 로드 유형 등)
• 그리고 이상적으로는 단순한 재생산

감사 해요!

여러분은 제한 없이 docker를 실행하고 있습니까? ulimits, cgroups 등...

newer systemd에는 설정하지 않은 경우에도 기본 제한이 있습니다. 나는 물건을 무제한으로 설정했고 그 이후로 문제가 발생하지 않았습니다(31일 이후로 보고 있음).

많은 환경에서 동일한 문제가 있었고 내 솔루션은 방화벽을 중지하는 것이었습니다. 다시는 그런 일이 일어나지 않았어, 지금은

렐 7.5 - 3.10.0-862.3.2.el7.x86_64
도커 1.13

@dElogics "최신"으로 간주되는 systemd 버전은 무엇입니까? CentOS 7.5 systemd에서 이 기본 제한이 활성화되어 있습니까?

또한 도커를 어떤 제한 아래에서 실행하고 있는지 물을 때 도커 데몬을 의미합니까, 아니면 개별 컨테이너를 의미합니까?

도커 데몬. Debian 9(232-25)에서와 같이 systemd.

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(코어)
브리지 모드

나는 같은 문제가 있었다, 내가 무엇을 할 수 있습니까?

같은 문제:

CentOS Linux 릴리스 7.5.1804(코어)
Docker 버전 18.06.1-ce, 빌드 e68fc7a
커널 버전: 3.10.0-693.el7.x86_64

여기에서 만난 비슷한 문제 ...
지금 수행할 수 있는 동작이 있습니까? 도와주세요...

센트OS 7.0.1406
[ root@zjsm-slavexx 등]# uname -a
Linux zjsm-slave08 3.10.0-123.el7.x86_64 #1 SMP 월요일 6월 30일 12:09:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[ root@zjsm-slavexx 등]# 고양이 /etc/centos-release
CentOS Linux 릴리스 7.0.1406(코어)

도커 정보:
[ root@zjsm-slavexx ~]# 도커 버전
고객:
버전: 17.04.0-ce
API 버전: 1.28
이동 버전: go1.7.5
힘내 커밋: 4845c56
작성일: 2017년 4월 3일 월 18:01:50
OS/아치: linux/amd64

섬기는 사람:
버전: 17.04.0-ce
API 버전: 1.28(최소 버전 1.12)
이동 버전: go1.7.5
힘내 커밋: 4845c56
작성일: 2017년 4월 3일 월요일 18:01:50
OS/아치: 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 사용자 정의 브리지 네트워크를 삭제하는 것입니까? 그 이유를 알아보기 위해 더 파헤쳐 보셨습니까? 그렇게 하셨다면 알려주세요. 정말 감사합니다.

수정 대기 중

여러분은 제한 없이 docker를 실행하고 있습니까? ulimits, cgroups 등...

newer systemd에는 설정하지 않은 경우에도 기본 제한이 있습니다. 나는 물건을 무제한으로 설정했고 그 이후로 문제가 발생하지 않았습니다(31일 이후로 보고 있음).

좋아, 이 버그는 여전히 발생하지만 확률이 감소했습니다.

컨테이너가 정상적으로 중지되면(PID 1이 존재()) 이 버그가 우리를 괴롭히지 않을 것이라고 생각합니다.

@dElogics 알려 주셔서 감사합니다. 이 시스템 제한을 무제한으로 설정하기 위해 실행한 명령을 알려주시겠습니까? 나는 그것을 시도하는 것을 좋아합니다.

@dElogics 알려 주셔서 감사합니다. 이 시스템 제한을 무제한으로 설정하기 위해 실행한 명령을 알려주시겠습니까? 나는 그것을 시도하는 것을 좋아합니다.

docker의 systemd unit을 수정해야 합니다. 내가 사용하는 시스템 단위(관련 부품만) --

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target docker.socket firewalld.service flannel.service
Wants=network-online.target
Requires=docker.socket

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker

ExecReload=/bin/kill -s HUP $MAINPID
LimitNOFILE=1048576
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNPROC=infinity
LimitCORE=infinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this version.
TasksMax=infinity
TimeoutStartSec=0
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
# kill only the docker process, not all processes in the cgroup
KillMode=process
# restart the docker process if it exits prematurely
Restart=on-failure
StartLimitBurst=3
StartLimitInterval=60s

[Install]
WantedBy=multi-user.target

누군가 커널 4.15 이상에서 이 문제를 겪었습니까?

이 Dan Streetman 수정 사항(https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d)은 4.15 커널 버전에 처음 포함되었으며 적어도 누군가에게는 4.16(https:// /github.com/kubernetes/kubernetes/issues/64743#issuecomment-436839647)

누군가 시도 했습니까?

@victorgp 4.15 커널에서 여전히 문제가 발생합니다. 4.16 커널로 테스트했을 때 여기에 보고할 것입니다(몇 주 안에).

몇 달 동안 커널 버전:4.14.62 를 사용

내 이전 결의에 추가하려면 -- SIGTERM에 응답하는 컨테이너를 정상적으로 중지하면 절대 이를 트리거하지 않습니다.

또한 문제를 완전히 해결하는 호스트 네임스페이스에서 컨테이너를 실행해 보십시오(허용되는 경우).

@dElogics "호스트 네임스페이스"란 무엇을 의미합니까? 단순히 --privileged 입니까?

@dElogics "호스트 네임스페이스"란 무엇을 의미합니까? 단순히 --privileged 입니까?

아니요, --network=host를 의미합니다.

커널 4.4.0에서 4.15.0으로, 도커 1.11.2에서 18.09로 업그레이드한 후 문제가 사라졌습니다.

도커 호스트 역할을 하는 상당한 규모의 VM 집합에서 이 문제가 하루에 여러 번 나타났습니다(Docker 사용 사례에서).
45일이 지났지만 더 이상 이것을 볼 수 없습니다.

후세를 위해 unregister_netdevice: waiting for vethXXXXX 표시하는 중단된 Docker 1.11.2 w/printk의 스택 추적(수백 개의 VM에서 우리 함대에서 항상 보았던 것과 유사)은 http://paste 에서 찾을 수 있습니다 0xc820001980 임)

goroutine 8809 [syscall, 542 minutes, locked to thread]:
syscall.Syscall6(0x2c, 0xd, 0xc822f3d200, 0x20, 0x0, 0xc822f3d1d4, 0xc, 0x20, 0xc82435fda0, 0x10)
    /usr/local/go/src/syscall/asm_linux_amd64.s:44 +0x5
syscall.sendto(0xd, 0xc822f3d200, 0x20, 0x20, 0x0, 0xc822f3d1d4, 0xc80000000c, 0x0, 0x0)
    /usr/local/go/src/syscall/zsyscall_linux_amd64.go:1729 +0x8c
syscall.Sendto(0xd, 0xc822f3d200, 0x20, 0x20, 0x0, 0x7faba31bded8, 0xc822f3d1c8, 0x0, 0x0)
    /usr/local/go/src/syscall/syscall_unix.go:258 +0xaf
github.com/vishvananda/netlink/nl.(*NetlinkSocket).Send(0xc822f3d1c0, 0xc82435fda0, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go:333 +0xd4
github.com/vishvananda/netlink/nl.(*NetlinkRequest).Execute(0xc82435fda0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go:215 +0x111
github.com/vishvananda/netlink.LinkDel(0x7fab9c2b15d8, 0xc825ef2240, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/vishvananda/netlink/link_linux.go:615 +0x16b
github.com/docker/libnetwork/drivers/bridge.(*driver).DeleteEndpoint(0xc8204aac30, 0xc8203ae780, 0x40, 0xc826e7b800, 0x40, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go:1060 +0x5cf
github.com/docker/libnetwork.(*endpoint).deleteEndpoint(0xc822945b00, 0xc82001ac00, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/endpoint.go:760 +0x261
github.com/docker/libnetwork.(*endpoint).Delete(0xc822945b00, 0x7fab9c2b0a00, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/endpoint.go:735 +0xbcb
github.com/docker/libnetwork.(*sandbox).delete(0xc8226bc780, 0xc8229f0600, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/sandbox.go:217 +0xd3f
github.com/docker/libnetwork.(*sandbox).Delete(0xc8226bc780, 0x0, 0x0)
    /usr/src/docker/vendor/src/github.com/docker/libnetwork/sandbox.go:175 +0x32
github.com/docker/docker/daemon.(*Daemon).releaseNetwork(0xc820001980, 0xc820e23a40)
    /usr/src/docker/.gopath/src/github.com/docker/docker/daemon/container_operations.go:732 +0x4f1
github.com/docker/docker/daemon.(*Daemon).Cleanup(0xc820001980, 0xc820e23a40)
    /usr/src/docker/.gopath/src/github.com/docker/docker/daemon/start.go:163 +0x62
github.com/docker/docker/daemon.(*Daemon).StateChanged(0xc820001980, 0xc825f9fac0, 0x40, 0xc824155b50, 0x4, 0x8900000000, 0x0, 0x0, 0x0, 0x0, ...)
    /usr/src/docker/.gopath/src/github.com/docker/docker/daemon/monitor.go:39 +0x60a
github.com/docker/docker/libcontainerd.(*container).handleEvent.func2()
    /usr/src/docker/.gopath/src/github.com/docker/docker/libcontainerd/container_linux.go:177 +0xa5
github.com/docker/docker/libcontainerd.(*queue).append.func1(0xc820073c01, 0xc820f9a2a0, 0xc821f3de20, 0xc822ddf9e0)
    /usr/src/docker/.gopath/src/github.com/docker/docker/libcontainerd/queue_linux.go:26 +0x47
created by github.com/docker/docker/libcontainerd.(*queue).append
    /usr/src/docker/.gopath/src/github.com/docker/docker/libcontainerd/queue_linux.go:28 +0x1da

그로부터 우리는 그것이 https://github.com/moby/moby/blob/v1.11.2/daemon/container_operations.go#L732에 매달려 있음을 관찰할 수 있습니다.

https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/sandbox.go#L175 를 가리킵니다.

그리고
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/endpoint.go#L760

libnetwork 브리지 드라이버로 이동합니다(멋진 설명 확인)
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go#L1057 -L1061

넷링크로 이동
https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go#L601 -L617
https://github.com/moby/moby/blob/v1.11.2//vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go#L215

그리고 궁극적으로 해당 netlink 소켓에서 https://github.com/moby/moby/blob/v1.11.2/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go#L333을 호출합니다.

우리는 일반적으로 컨테이너를 중지할 때 버그가 발생하고 netns에서 SKB가 여전히 참조되기 때문에 veth가 릴리스되지 않고 Docker가 15초 후에 해당 컨테이너에 대해 Kill을 발행한다고 생각합니다. Docker 데몬은 이 상황을 정상적으로 처리하지 않지만 궁극적으로 버그는 커널에 있습니다. https://github.com/torvalds/linux/commit/4ee806d51176ba7b8ff1efd81f271d7252e03a1d(4.15 업스트림에서 허용됨) 및 이에 연결된 커밋(여러 개 있음)이 완화 역할을 한다고 믿습니다.

일반적으로 커널의 해당 부분은 그다지 좋지 않습니다.

그 가치를 위해... RHEL Linux 커널을 3.10.0에서 4.17.11로 업그레이드했습니다. (Kubernetes 클러스터 실행 중). 이 버그를 업그레이드하기 전에는 매일 여러 서버에서 여러 번 발생했습니다. 지금 3주 동안 업그레이드를 실행하고 있습니다. 버그는 한 번만 발생했습니다. 따라서 대략적으로 99% 감소합니다.

@marckamerbeek RHEL 커널을 커뮤니티 커널로 업데이트했습니까? 그러면 더 이상 지원되지 않습니다.

@Beatlor CentOS 사용자는 이렇게 할 수 있습니다.

centos 7.2에는 여전히 다음과 같은 문제가 있습니다. kernel:unregister_netdevice : lo가

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

최신 4.19+ 커널로 업그레이드를 시도할 수 있습니다.

몇 달만 기다리면 누군가 4.19 커널에 대해 불평할 것입니다. 반복되는 역사일 뿐입니다.

안녕하세요 여러분, 좋은 소식입니다!

여기에 내 마지막 댓글(작성 당시, 17일 전) 이후로 이러한 오류가 다시 발생하지 않았습니다. 내 서버(약 30개)는 일부 오래된 패키지와 함께 우분투 14.04를 실행하고 있었습니다.

docker-engine(1.7.1에서 1.8.3으로)을 포함한 전체 시스템 업그레이드 + 우분투 저장소에서 가능한 최신 버전으로 커널 업그레이드 후, 내 서버는 아무 문제 없이 실행되고 있습니다.

🎱

어떤 커널 버전을 업그레이드합니까?

아마도 이것과 관련이 있습니다 https://github.com/torvalds/linux/commit/f186ce61bb8235d80068c390dc2aad7ca427a4c2

https://github.com/kubernetes/kubernetes/issues/70427 , https://github.com/kubernetes/kubernetes/issues/64743 및 https://github.com/kubernetes/kubernetes/issues/70427 , 이 문제에 대한 의견에서 이 문제를 요약하려는 시도입니다 . //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.4에서 매일 수십 번씩 4.15.0에서 수천 개의 VM이 있는 것을 본 적이 없기 때문입니다. 0, 4.15.0에 더 많은 보고서가 있습니까?

Debian 9 Stretch( 4.9.0-8-amd64 )에서 Docker를 실행하는 머신 중 하나에서 이 문제가 발생합니다. Docker Gen을 통해 Docker 컨테이너 내에서 생성된 터널에서 이 문제가 발생하고 커널 패닉이 생성됩니다.

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 나는 이것을 우분투 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 BTW，livepatch_route.ko를 /var/lib/kpatch/$(uname -r)에 넣어야 합니다. kpatch.service를 활성화하면 재부팅 후 ko가 자동 로드될 수 있습니다.

우리는 오늘 갑자기 여러 kubernetes 클러스터에서 이것을 얻었습니다.

• uname -a :
  Linux ip-10-47-17-58 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux

• docker version :

  Client:
   Version:           18.09.5
   API version:       1.39
   Go version:        go1.10.8
   Git commit:        e8ff056dbc
   Built:             Thu Apr 11 04:44:28 2019
   OS/Arch:           linux/amd64
   Experimental:      false
  
  Server: Docker Engine - Community
   Engine:
    Version:          18.09.2
    API version:      1.39 (minimum version 1.12)
    Go version:       go1.10.6
    Git commit:       6247962
    Built:            Sun Feb 10 03:42:13 2019
    OS/Arch:          linux/amd64
    Experimental:     false
  

• kubectl version (서버):
  Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.2", GitCommit:"cff46ab41ff0bb44d8584413b598ad8360ec1def", GitTreeState:"clean", BuildDate:"2019-01-10T23:28:14Z", GoVersion:"go1.11.4", Compiler:"gc", Platform:"linux/amd64"}

우리는 아직 원인을 모릅니다. 우리는 문제 없이 몇 달 동안 위 소프트웨어의 이러한 버전을 실행해 왔습니다. 지금은 "이 버그가 발생하는 소프트웨어 버전" 목록에 추가하기 위해 댓글을 남깁니다.

@2rs2ts https://pingcap.com/blog/try-to-fix-two-linux-kernel-bugs-while-testing-tidb-operator-in-k8s/ 를 시도해 보셨습니까 ?

@ethercflow 나는 그것을 읽었지만 우리 회사에서 데비안을 실행하기 때문에 우리가 그 게시물에서 수정 사항을 구현하는 것이 간단하지 않습니다.

@ethercflow @2rs2ts 우리도 데비안을 실행하고 있습니다. kpatch-build가 작동하도록 하는 데 많은 문제가 발생했습니다. 해결 방법을 찾으면 계속 알려 드리겠습니다. 어쨌든 다른 해결책이 있습니까? 문제를 완화하는 커널 버전 4.15 또는 4.19입니까? 나는 지난 주 동안 답을 찾으려고 노력했지만 여전히 성공하지 못했습니다.

@commixon 우리의 경험은 https://github.com/moby/moby/issues/5618#issuecomment -455800975에서 보고된 것과 여전히 동일하며 수천 개의 VM에서 4.15.0에서 문제가 다시 발생하지 않습니다. Canonical에서 제공하는 일반, AWS 최적화 및 GCP 최적화 커널 버전입니다. 바닐라 4.15.0에 대한 제한된 테스트에서도 이러한 문제가 나타나지 않았지만 대규모로 테스트되지는 않았습니다.

@pmoust 감사합니다. 그들을 시험해 볼 것입니다. 어쨌든 나는 또한 데비안과 함께 작동하도록 kpatch를 패치하고(부수 프로젝트로) 관심 있는 사람을 위해 여기에 업데이트를 게시하려고 합니다.

@ethercflow @2rs2ts 우리도 데비안을 실행하고 있습니다. kpatch-build가 작동하도록 하는 데 많은 문제가 발생했습니다. 해결 방법을 찾으면 계속 알려 드리겠습니다. 어쨌든 다른 해결책이 있습니까? 문제를 완화하는 커널 버전 4.15 또는 4.19입니까? 나는 지난 주 동안 답을 찾으려고 노력했지만 여전히 성공하지 못했습니다.

4.19로 업그레이드할 수 있습니다. 백포트에 있습니다.

BTW 여기 우리를위한 1 년이었습니다. ;)

우리는 실제로 백포트에서 4.19를 시도했지만 다른 영역에서 몇 가지 주요 회귀가 있었습니다(EC2 인스턴스가 무작위로 재부팅되고 시작 시 네트워킹이 중단됨). 다음 안정 버전까지 이 문제를 처리해야 할 것 같습니다.

@2rs2ts 지난 4일 동안 우리는 백포트(EC2에서)에서 4.19를 사용하고 있으며 전혀 문제를 보지 못했습니다. 커널 크래시 문제는 전혀 나타나지 않았고 다른 모든 것도 잘 보입니다. 차이가 없다고 생각하지만 kops(https://github.com/kubernetes/kops/blob/master/docs/images.md#debian)에서 제공하는 데비안 이미지를 기반으로 했습니다. 우리는 스톡 데비안이 아니라 이 이미지에서 커널을 업데이트했습니다.

친구 여러분, 저는 반년 동안 안정적인 운영을 위해 4.19 커널을 사용해 왔습니다. 여러분도 안정감을 느끼셨으면 좋겠습니다.

나는 anther 컴퓨터 액세스 컨테이너 80에서 2주마다 80 및 443 포트를 여는 컨테이너를 가지고 있습니다.
443은 거부

centos7.3 커널 버전은 다음과 같습니다.
Linux 브라우저1 3.10.0-514.el7.x86_64 #1 SMP 화요일 11월 22일 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

root@browser1 ~]# 도커 버전
고객:
버전: 18.06.3-ce
API 버전: 1.38
이동 버전: go1.10.4
힘내 커밋: d7080c1
작성일: 2019년 2월 20일 수요일 02:24:22
OS/아치: linux/amd64
실험적: 거짓

섬기는 사람:
엔진:
버전: 18.06.3-ce
API 버전: 1.38(최소 버전 1.12)
이동 버전: go1.10.3
힘내 커밋: d7080c1
작성일: 2019년 2월 20일 수요일 02:25:33
OS/아치: linux/amd64
실험적: 거짓
[ root@browser1 ~]#

메시지:

[1063959.636785] unregister_netdevice: lo가 해제되기를 기다립니다. 사용 횟수 = 1
[1071340.887512] br-af29e1edc1b8: 포트 5(vethc2ac4f8)가 비활성화 상태가 됨
[1071340.891753] br-af29e1edc1b8: 포트 5(vethc2ac4f8)가 비활성화 상태가 됨
[1071340.895118] 장치 vethc2ac4f8 왼쪽 무차별 모드
[1071340.895138] br-af29e1edc1b8: 포트 5(vethc2ac4f8)가 비활성화 상태가 됨
[1071340.990505] 장치 veth5e4f161이 무차별 모드에 들어갔습니다.
[1071340.990897] IPv6: ADDRCONF(NETDEV_UP): veth5e4f161: 링크가 준비되지 않았습니다.
[1071340.990904] br-af29e1edc1b8: 포트 5(veth5e4f161)가 포워딩 상태가 됨
[1071340.990924] br-af29e1edc1b8: 포트 5(veth5e4f161)가 포워딩 상태가 됨
[1071341.231405] IPv6: ADDRCONF(NETDEV_CHANGE): veth5e4f161: 링크가 준비됨
[1071355.991701] br-af29e1edc1b8: 포트 5(veth5e4f161)가 포워딩 상태가 됨
[1071551.533907] br-af29e1edc1b8: 포트 5(veth5e4f161)가 비활성화 상태가 됨
[1071551.537564] br-af29e1edc1b8: 포트 5(veth5e4f161)가 비활성화 상태가 됨
[1071551.540295] 장치 veth5e4f161 왼쪽 무차별 모드
[1071551.540313] br-af29e1edc1b8: 포트 5(veth5e4f161)가 비활성화 상태가 됨
[1071551.570924] 장치 veth8fd3a0a가 무차별 모드에 들어갔습니다.
[1071551.571550] IPv6: ADDRCONF(NETDEV_UP): veth8fd3a0a: 링크가 준비되지 않았습니다.
[1071551.571556] br-af29e1edc1b8: 포트 5(veth8fd3a0a)가 포워딩 상태가 됨
[1071551.571582] br-af29e1edc1b8: 포트 5(veth8fd3a0a)가 포워딩 상태가 됨
[1071551.841656] IPv6: ADDRCONF(NETDEV_CHANGE): veth8fd3a0a: 링크가 준비됨
[1071566.613998] br-af29e1edc1b8: 포트 5(veth8fd3a0a)가 포워딩 상태가 됨
[1071923.465082] br-af29e1edc1b8: 포트 5(veth8fd3a0a)가 비활성화 상태가 됨
[1071923.470215] br-af29e1edc1b8: 포트 5(veth8fd3a0a)가 비활성화 상태가 됨
[1071923.472888] 장치 veth8fd3a0a 왼쪽 무차별 모드
[1071923.472904] br-af29e1edc1b8: 포트 5(veth8fd3a0a)가 비활성화 상태가 됨
[1071923.505580] 장치 veth9e693ae가 무차별 모드에 들어갔습니다.
[1071923.505919] IPv6: ADDRCONF(NETDEV_UP): veth9e693ae: 링크가 준비되지 않았습니다.
[1071923.505925] br-af29e1edc1b8: 포트 5(veth9e693ae)가 포워딩 상태가 됨
[1071923.505944] br-af29e1edc1b8: 포트 5(veth9e693ae)가 포워딩 상태가 됨
[1071923.781658] IPv6: ADDRCONF(NETDEV_CHANGE): veth9e693ae: 링크가 준비됨
[1071938.515044] br-af29e1edc1b8: 포트 5(veth9e693ae)가 포워딩 상태가 됨

4.19에서 이 버그를 본 사람이 있습니까?

예. 커널 4.19.4-1.e17.elrep.x86_64에 문제가 있습니다.

안녕하십니까,

이 오류도 표시됩니다. 이 문제에 대한 해결책이 있습니까? 커널 3.10.0-514.26.2.el7.x86_64

[username@ip-10-1-4-64 ~]$
Message from syslogd@ip-10-1-4-64 at Jul 19 10:50:01 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Message from syslogd@ip-10-1-4-64 at Jul 19 10:50:48 ...
 kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

이 문제는 계속 발생합니다:(업데이트/해결 방법에 대한 아이디어가 없습니까?

데비안 스트레치에서 발생합니다. 이 일이 발생했을 때 Ansible을 통해 Jenkins 컨테이너를 업데이트하려고 했습니다.

이 문제는 이 커밋으로 해결되었습니다.
https://github.com/torvalds/linux/commit/ee60ad219f5c7c4fb2f047f88037770063ef785f
kpatch 사용

curl -SOL https://raw.githubusercontent.com/Aleishus/kdt/master/kpatchs/route.patch
kpatch-build -t vmlinux route.patch 
mkdir -p /var/lib/kpatch/${UNAME} 
cp -a livepatch-route.ko /var/lib/kpatch/${UNAME}
systemctl restart kpatch
kpatch list

이 문제는 이 커밋으로 해결되었습니다.
토발즈 / linux@ee60ad2
kpatch 사용

curl -SOL https://raw.githubusercontent.com/Aleishus/kdt/master/kpatchs/route.patch
kpatch-build -t vmlinux route.patch 
mkdir -p /var/lib/kpatch/${UNAME} 
cp -a livepatch-route.ko /var/lib/kpatch/${UNAME}
systemctl restart kpatch
kpatch list

이것은 4.19.30 이후에 있어야 합니다.