이것을 보여주기 위해 축소 된 테스트 케이스를 갖게 될까요? 아마도 컨테이너에있는 것에 대한 작은 Dockerfile과 컨테이너 시작 / 중지 / ... 작업을 수행하는 bash 스크립트일까요?

duglin 에 2015년 06월 11일

컨테이너가 dockerhub kinvey / blrunner # v0.3.8에 있습니다.

다음 옵션과 함께 원격 API 사용 :

창조하다
이미지 : 'kinvey / blrunner # v0.3.8'
AttachStdout : 거짓
AttachStderr : 거짓
ExposedPorts : { '7000 / tcp': {}}
Tty : 거짓
HostConfig :
PublishAllPorts : true
CapDrop : [
"CHOWN"
"DAC_OVERRIDE"
"FOWNER"
"죽임"
"SETGID"
"SETPCAP"
"NET_BIND_SERVICE"
"NET_RAW"
"SYS_CHROOT"
"MKNOD"
"SETFCAP"
"AUDIT_WRITE"
]
LogConfig :
유형 : "없음"
구성 : {}

스타트

container.start

없애다
force : true

mjsalinger 에 2015년 06월 11일

흠, 과도한 리소스 사용량이 보이십니까?
ssh가 작동하지 않는다는 사실은 나를 의심하게 만듭니다.
오버레이의 inode 문제이거나 너무 많은 열린 FD 등이 될 수 있습니다.

cpuguy83 에 2015년 06월 11일

과도한 리소스 사용과 관련하여 특히는 아니지만 초기 증상은 docker가 완전히 중단되고 다른 프로세스는 행복하게 윙윙 거리는 것입니다 ...

중요한 점은 하나의 인스턴스에서 한 번에 8 개의 컨테이너 만 실행된다는 것입니다.

mjsalinger 에 2015년 06월 11일

docker가 더 이상 resposive가 아닌 일부 통계를 캡처했습니다.

lsof | 화장실 -l

1025를 보여줍니다.

그러나 오류가 여러 번 나타납니다.
lsof : 경고 : 오버레이 파일 시스템 / var / lib / docker / overlay / aba7820e8cb01e62f7ceb53b0d04bc1281295c38815185e9383ebc19c30325d0 / merged를 stat () 할 수 없습니다.
출력 정보가 불완전 할 수 있습니다.

상단의 샘플 출력 :
상단-00:16:53 12:22, 사용자 2 명,로드 평균 : 2.01, 2.05, 2.05
작업 : 총 123 개, 실행 중 1 개, 수면 121 개, 중지 0 개, 좀비 1 개
% Cpu (s) : 0.3 us, 0.0 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 총 3853940, 사용 2592920, 무료 1261020, 버퍼 172660
KiB 스왑 : 총 0 개, 사용 0 개, 무료 0 개. 1115644 캐시 된 메모리
24971 kinvey 20 0 992008 71892 10796 S 1.3 1.9 9 : 11.93 노드
902 루트 200 1365860 62800 12108 S 0.3 1.6 30 : 06.10 도커
29901 우분투 200 27988 6720 2676 S 0.3 0.2 3 : 58.17 tmux
1 루트 2000 33612 4152 2716 S 0.0 0.1 14 : 22.00 초기화
2 루트 20000 S 0.0 0.0 0 : 00.03 kthreadd
3 루트 20000 S 0.0 0.0 0 : 04.40 ksoftirqd / 0
5 루트 0-20 0 0 S 0.0 0.0 0 : 00.00 kworker / 0 : 0H
7 루트 200 000 S 0.0 0.0 2 : 21.81 rcu_sched
8 루트 200 000 S 0.0 0.0 0 : 01.91 rcu_bh

mjsalinger 에 2015년 06월 12일

@mjsalinger 사용중인 설정이 지원되지 않습니다. 지원되지 않는 이유는 사용자 지정 커널과 함께 Ubuntu 14.04를 사용하고 있기 때문입니다.

3.18.0-031800 커널은 어디에서 왔습니까? 이 커널 빌드가 오래된 것을 알았습니까? 사용중인 커널은 작년 12 월에 빌드되었습니다.

죄송합니다. 여기서 디버깅 할 항목이 없습니다. 이 문제는 실제로 오버레이와 관련된 커널 버그이거나 최신 버전의 커널 3.18에서 더 이상 문제가되지 않는 다른 이미 수정 된 커널 버그 일 수 있습니다.

이 문제를 종료하겠습니다. 최신 3.18 이상의 커널로 다시 시도하고 문제가 발생하는지 확인하십시오. 오버레이에 대해 여러 문제가 열려 있으며 최신 커널 버전 및 최신 Docker 버전으로 업데이트 한 후에도 오버레이 문제가 발생할 수 있음을 명심하십시오.

unclejack 에 2015년 06월 13일

@unclejack @ cpuguy83 @ LK4D4 이 문제를 다시여십시오. 이것은 우리가 사용하는 구성에 대한 조언이 특히 도커 팀과 실험에서 제공 한 것입니다. 우리는 최신 커널 (3.19 +)을 사용해 보았고 어떤 종류의 커널 패닉 버그가 있습니다. 따라서 12 월 이전에 3.18을 사용하는 것이 좋습니다. 그 이후에 알려진 커널 버그로 인해 우리가 알고있는 커널 패닉은 아직 수정되지 않았습니다.

OverlayFS에 관해서는 AUFS에서 _numerous_ 개의 성능 문제를 경험 한 후 Docker에 이상적인 FS로도 제시되었습니다. 이것이 지원되는 구성이 아닌 경우 누군가가이 사용 사례에 적합한 성능적이고 안정적인 구성을 찾도록 도와 줄 수 있습니까? 우리는이 안정을 몇 달 동안 추진해 왔습니다.

mjsalinger 에 2015년 06월 14일

@mjsalinger 오버레이가 실행되는 볼륨에 대한 inode 사용량을 제공 할 수 있습니까? ( df -i /var/lib/docker 해야합니다).

cpuguy83 에 2015년 06월 16일

다시 열어 주셔서 감사합니다. 대답이 다른 커널이면 괜찮습니다. 안정적인 시나리오를 원합니다.

df -i / ver / lib / docker

파일 시스템 Inode IUsed IFree IUse % Mounted on
/ dev / xvda1 1638400 643893 994507 40 % /

mjsalinger 에 2015년 06월 16일

오버레이에는 여전히 많은 문제가 있습니다 : https://github.com/docker/docker/issues?q=is%3Aopen+is%3Aissue+label%3A%2Fsystem%2Foverlay

프로덕션에서는 오버레이를 사용하지 않습니다. 다른 사람들은이 이슈 트래커에 대해 프로덕션에서 AUFS를 사용하고 있으며 안정적이라고 언급했습니다.

Kernel 3.18은 Ubuntu 14.04에서 지원되지 않습니다. Canonical은 이에 대한 지원을 제공하지 않습니다.

unclejack 에 2015년 06월 16일

프로덕션 환경의 AUFS는 성능이 전혀 떨어지지 않았고 우리에게는 안정적 이었지만 I / O 병목 현상, 멈춤 등이 자주 발생했습니다.

보다:

11228, # 12758, # 12962

오버레이로 전환하면 위의 모든 문제가 해결되었습니다. 남은 문제는 하나뿐입니다.

또한:

http://developerblog.redhat.com/2014/09/30/overview-storage-scalability-docker/
http://qconlondon.com/system/files/presentation-slides/Docker%20Clustering.pdf

Overlay는 일반적으로 커뮤니티에서 선택한 동인으로 제공되는 것 같습니다. 아직 안정적이지 않다면 괜찮지 만 AUFS도 아니고 Docker에 필요한 성능과 안정성을 얻을 수있는 방법이 있어야합니다. 나는 모두 새로운 것을 시도하고 있지만 이전 구성 (Ubuntu 12.04의 AUFS 및 Ubuntu 14.04의 AUFS)에서는 안정성이나 성능을 얻을 수 없었습니다. 적어도 Overlay를 사용하면 성능과 안정성이 향상되지만이 문제를 해결하면됩니다.

mjsalinger 에 2015년 06월 16일

또한 AUFS (12.04, 14.04 및 15.04)에서 실행중인 기본 Ubuntu 인스턴스와 유사한 증상을 경험했습니다.

10355 # 13940

현재 Kernel 및 OverlayFS로 전환 한 후이 두 가지 문제가 모두 사라졌습니다.

mjsalinger 에 2015년 06월 16일

@mjsalinger 최신 커널 3.13 패키지와 함께 Ubuntu 14.04를 사용하는 것이 좋습니다. 나는 그것을 직접 사용하고 있으며 이러한 문제는 전혀 발생하지 않았습니다.

unclejack 에 2015년 06월 16일

@unclejack 그것을 시도하고 대량의 대량 사용 (많은 컨테이너 생성 / 파괴)으로 위에 지정된 문제에 부딪 쳤고 AUFS는 성능이 매우 떨어졌습니다. 그래서 그것은 옵션이 아닙니다.

mjsalinger 에 2015년 06월 16일

@mjsalinger 도커를 시작하기 위해 upstart를 사용하고 있습니까? /etc/init/docker.conf는 어떻게 생겼습니까?

cpuguy83 에 2015년 06월 16일

예, upstart를 사용합니다.

/etc/init/docker.conf

description "Docker daemon"

start on (local-filesystems and net-device-up IFACE!=lo)
stop on runlevel [!2345]
limit nofile 524288 1048576
limit nproc 524288 1048576

respawn

pre-start script
        # see also https://github.com/tianon/cgroupfs-mount/blob/master/cgroupfs-mount
        if grep -v '^#' /etc/fstab | grep -q cgroup \
                || [ ! -e /proc/cgroups ] \
                || [ ! -d /sys/fs/cgroup ]; then
                exit 0
        fi
        if ! mountpoint -q /sys/fs/cgroup; then
                mount -t tmpfs -o uid=0,gid=0,mode=0755 cgroup /sys/fs/cgroup
        fi
        (
                cd /sys/fs/cgroup
                for sys in $(awk '!/^#/ { if ($4 == 1) print $1 }' /proc/cgroups); do
                        mkdir -p $sys
                        if ! mountpoint -q $sys; then
                                if ! mount -n -t cgroup -o $sys cgroup $sys; then
                                        rmdir $sys || true
                                fi
                        fi
                done
        )
end script

script
        # modify these in /etc/default/$UPSTART_JOB (/etc/default/docker)
        DOCKER=/usr/bin/$UPSTART_JOB
        DOCKER_OPTS=
        if [ -f /etc/default/$UPSTART_JOB ]; then
                . /etc/default/$UPSTART_JOB
        fi
        exec "$DOCKER" -d $DOCKER_OPTS
end script

# Don't emit "started" event until docker.sock is ready.
# See https://github.com/docker/docker/issues/6647
post-start script
        DOCKER_OPTS=
        if [ -f /etc/default/$UPSTART_JOB ]; then
                . /etc/default/$UPSTART_JOB
        fi
        if ! printf "%s" "$DOCKER_OPTS" | grep -qE -e '-H|--host'; then
                while ! [ -e /var/run/docker.sock ]; do
                        initctl status $UPSTART_JOB | grep -qE "(stop|respawn)/" && exit 1
                        echo "Waiting for /var/run/docker.sock"
                        sleep 0.1
                done
                echo "/var/run/docker.sock is up"
        fi
end script

mjsalinger 에 2015년 06월 16일

예를 들어 일부 인스턴스에서 Docker 명령을 실행할 때도 다음과 같은 내용이 표시됩니다.

sudo docker ps

FATA [0000] Get http : ///var/run/docker.sock/v1.18/containers/json? all = 1 : dial unix /var/run/docker.sock : 리소스를 일시적으로 사용할 수 없습니다. TLS 지원에 연결하려고합니까
TLS없는 데몬?

mjsalinger 에 2015년 06월 17일

@mjsalinger 그냥 엉터리 오류 메시지입니다. 대부분의 경우 데몬이 충돌했음을 의미합니다.

LK4D4 에 2015년 06월 17일

@mjsalinger 이 동안 docker 데몬 로그는 무엇을 말합니까? /var/log/upstart/docker.log 는 위치 여야합니다.

cpuguy83 에 2015년 06월 17일

고정 된 새 항목이 없습니다. 다음은 로그의 마지막 항목입니다.

INFO[46655] -job log(create, 48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46655] -job create() = OK (0)
INFO[46655] POST /containers/48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a/start
INFO[46655] +job start(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a)
INFO[46655] +job allocate_interface(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a)
INFO[46655] -job allocate_interface(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a) = OK (0)
INFO[46655] +job allocate_port(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a)
INFO[46655] POST /containers/create?Image=kinvey%2Fblrunner%3Av0.3.8&AttachStdout=false&AttachStderr=false&ExposedPorts=&Tty=false&HostConfig=
INFO[46655] +job create()
INFO[46655] DELETE /containers/4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187?force=true
INFO[46655] +job rm(4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187)
INFO[46656] -job allocate_port(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a) = OK (0)
INFO[46656] +job log(start, 48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(start, 48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] +job log(create, 7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(create, 7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] -job create() = OK (0)
INFO[46656] +job log(die, 4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(die, 4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] +job release_interface(4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187)
INFO[46656] POST /containers/7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f/start
INFO[46656] +job start(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f)
INFO[46656] +job allocate_interface(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f)
INFO[46656] -job allocate_interface(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f) = OK (0)
INFO[46656] +job allocate_port(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f)
INFO[46656] -job release_interface(4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187) = OK (0)
INFO[46656] DELETE /containers/cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b?force=true
INFO[46656] +job rm(cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b)
INFO[46656] +job log(destroy, 4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(destroy, 4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] -job rm(4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187) = OK (0)
INFO[46656] +job log(die, cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(die, cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] +job release_interface(cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b)
INFO[46656] DELETE /containers/1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20?force=true
INFO[46656] +job rm(1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20)
INFO[46656] -job allocate_port(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f) = OK (0)
INFO[46656] +job log(start, 7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(start, 7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] -job start(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a) = OK (0)
INFO[46656] POST /containers/create?Image=kinvey%2Fblrunner%3Av0.3.8&AttachStdout=false&AttachStderr=false&ExposedPorts=&Tty=false&HostConfig=
INFO[46656] +job create()
INFO[46656] +job log(create, 1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(create, 1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] -job create() = OK (0)
INFO[46656] +job log(die, 1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(die, 1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] +job release_interface(1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20)
INFO[46656] GET /containers/48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a/json
INFO[46656] +job container_inspect(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a)
INFO[46656] -job container_inspect(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a) = OK (0)
INFO[46656] POST /containers/1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830/start
INFO[46656] +job start(1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830)
INFO[46656] +job allocate_interface(1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830)
INFO[46656] -job allocate_interface(1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830) = OK (0)
INFO[46656] +job allocate_port(1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830)
INFO[46656] -job release_interface(cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b) = OK (0)
INFO[46656] -job start(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f) = OK (0)
INFO[46656] GET /containers/7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f/json
INFO[46656] +job container_inspect(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f)
INFO[46656] -job release_interface(1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20) = OK (0)
INFO[46656] -job container_inspect(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f) = OK (0)
INFO[46656] +job log(destroy, cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(destroy, cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] -job rm(cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b) = OK (0)
INFO[46656] +job log(destroy, 1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(destroy, 1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] -job rm(1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20) = OK (0)
INFO[46656] DELETE /containers/4cfeb48701f194cfd40f71d7883d82906d54a538084fa7be6680345e4651aa60?force=true
INFO[46656] +job rm(4cfeb48701f194cfd40f71d7883d82906d54a538084fa7be6680345e4651aa60)
INFO[46656] -job allocate_port(1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830) = OK (0)
INFO[46656] +job log(start, 1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(start, 1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830, kinvey/blrunner:v0.3.8) = OK (0)

mjsalinger 에 2015년 06월 17일

@ cpuguy83 로그가 도움이 되었습니까?

mjsalinger 에 2015년 06월 19일

@mjsalinger 문제를 나타내는 다른 것이 없기 때문에 어딘가에 교착 상태가 있다고 생각하게 만듭니다.

cpuguy83 에 2015년 06월 19일

@ cpuguy83 증상을 감안할 때 의미가 있습니다. 이 문제와 그 원인을 추적하기 위해 내가 할 수있는 일이 있습니까?

mjsalinger 에 2015년 06월 19일

아마도 우리는 그것이 실제로 자물쇠에 매달려 있는지 확인하기 위해 strace를 얻을 수 있습니다.

cpuguy83 에 2015년 06월 19일

확인. 우리가 그것을 얻을 수 있는지 확인하기 위해 노력할 것입니다. 우리는 1.7을 먼저 시도하고 싶었습니다. 그렇게했지만 어떤 개선도 눈치 채지 못했습니다.

mjsalinger 에 2015년 06월 23일

@ cpuguy83 영향을받는 호스트 중 하나에서 :

root@<host>:~# strace -q -y -v -p 899
futex(0x134f1b8, FUTEX_WAIT, 0, NULL^C <detached ...>

mjsalinger 에 2015년 06월 23일

@ cpuguy83 어떤 아이디어?

mjsalinger 에 2015년 06월 25일

컨테이너가 죽거나 시작되지 않은 상태에서 1.7에서 다음을 참조하십시오. 이것은 문제의 선구자 인 것 같습니다 (참고로 1.6에서는 이러한 오류를 보지 못했지만 죽이기 / 제거하라는 명령이 실행 되었음에도 불구하고 죽은 컨테이너의 양이 쌓이기 시작하는 것을 보았습니다)

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container 09c12c9f72d461342447e822857566923d5532280f9ce25659d1ef3e54794484: Link not found

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container 5e29407bb3154d6f5778676905d112a44596a23fd4a1b047336c3efaca6ada18: Link not found

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container be22e8b24b70e24e5269b860055423236e4a2fca08969862c3ae3541c4ba4966: Link not found

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container c067d14b67be8fb81922b87b66c0025ae5ae1ebed3d35dcb4052155afc4cafb4: Link not found

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container 7f21c4fd8b6620eba81475351e8417b245f86b6014fd7125ba0e37c6684e3e42: Link not found

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container b31531492ab7e767158601c438031c8e9ef0b50b9e84b0b274d733ed4fbe03a0: Link not found

Error spawning container: Error: HTTP code is 500 which indicates error: server error - Cannot start container 477dc3c691a12f74ea3f07af0af732082094418f6825f7c3d320bda0495504a1: iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 32822 -j DNAT --to-destination 172.17.0.44:7000 ! -i docker0: iptables: No chain/target/match by that name.
 (exit status 1)

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container 6965eec076db173f4e3b9a05f06e1c87c02cfe849821bea4008ac7bd0f1e083a: Link not found

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container 7c721dd2b8d31b51427762ac1d0fe86ffbb6e1d7462314fdac3afe1f46863ff1: Link not found

Error spawning container: Error: HTTP code is 500 which indicates error: server error - Cannot start container c908d059631e66883ee1a7302c16ad16df3298ebfec06bba95232d5f204c9c75: iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 32837 -j DNAT --to-destination 172.17.0.47:7000 ! -i docker0: iptables: No chain/target/match by that name.
 (exit status 1)

Error spawning container: Error: HTTP code is 500 which indicates error: server error - Cannot start container c3e11ffb82fe08b8a029ce0a94e678ad46e3d2f3d76bed7350544c6c48789369: iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 32847 -j DNAT --to-destination 172.17.0.48:7000 ! -i docker0: iptables: No chain/target/match by that name.
 (exit status 1)

mjsalinger 에 2015년 06월 25일

최근 사건의 docker.log 꼬리 :

INFO[44089] DELETE /containers/4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25?force=true
INFO[44089] +job rm(4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25)
INFO[44089] DELETE /containers/a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96?force=true
INFO[44089] +job rm(a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96)
INFO[44089] +job log(die, 4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25, kinvey/blrunner:v0.3.8)
INFO[44089] -job log(die, 4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44089] +job release_interface(4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25)
INFO[44089] -job release_interface(4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25) = OK (0)
INFO[44089] +job log(die, a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96, kinvey/blrunner:v0.3.8)
INFO[44089] -job log(die, a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44089] +job release_interface(a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96)
INFO[44089] -job release_interface(a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96) = OK (0)
INFO[44092] +job log(destroy, 285274ee9c5b3bfa9fcea4d93b75e7e51949752b8d0eb101a31ea4f9aec5dad6, kinvey/blrunner:v0.3.8)
INFO[44092] -job log(destroy, 285274ee9c5b3bfa9fcea4d93b75e7e51949752b8d0eb101a31ea4f9aec5dad6, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44092] -job rm(285274ee9c5b3bfa9fcea4d93b75e7e51949752b8d0eb101a31ea4f9aec5dad6) = OK (0)
INFO[44092] POST /containers/create?Image=kinvey%2Fblrunner%3Av0.3.8&AttachStdout=false&AttachStderr=false&ExposedPorts=&Tty=false&HostConfig=
INFO[44092] +job create()
INFO[44097] +job log(destroy, 4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25, kinvey/blrunner:v0.3.8)
INFO[44097] -job log(destroy, 4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44097] -job rm(4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25) = OK (0)
INFO[44097] POST /containers/create?Image=kinvey%2Fblrunner%3Av0.3.8&AttachStdout=false&AttachStderr=false&ExposedPorts=&Tty=false&HostConfig=
INFO[44097] +job create()
INFO[44098] +job log(destroy, c80a39f060f200f1aff8ae52538779542437745e4184ed02793f8873adcb9cd4, kinvey/blrunner:v0.3.8)
INFO[44098] -job log(destroy, c80a39f060f200f1aff8ae52538779542437745e4184ed02793f8873adcb9cd4, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44098] -job rm(c80a39f060f200f1aff8ae52538779542437745e4184ed02793f8873adcb9cd4) = OK (0)
INFO[44098] POST /containers/create?Image=kinvey%2Fblrunner%3Av0.3.8&AttachStdout=false&AttachStderr=false&ExposedPorts=&Tty=false&HostConfig=
INFO[44098] +job create()
INFO[44098] +job log(create, 3b9a4635c068989ddb1983aa12460083e874d50fd42c743033ed3a08000eb7e9, kinvey/blrunner:v0.3.8)
INFO[44098] -job log(create, 3b9a4635c068989ddb1983aa12460083e874d50fd42c743033ed3a08000eb7e9, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44098] -job create() = OK (0)
INFO[44098] POST /containers/3b9a4635c068989ddb1983aa12460083e874d50fd42c743033ed3a08000eb7e9/start
INFO[44098] +job start(3b9a4635c068989ddb1983aa12460083e874d50fd42c743033ed3a08000eb7e9)
INFO[44102] +job log(destroy, a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96, kinvey/blrunner:v0.3.8)
INFO[44102] -job log(destroy, a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44102] -job rm(a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96) = OK (0)
INFO[44102] POST /containers/create?Image=kinvey%2Fblrunner%3Av0.3.8&AttachStdout=false&AttachStderr=false&ExposedPorts=&Tty=false&HostConfig=
INFO[44102] +job create()

mjsalinger 에 2015년 06월 26일

@ cpuguy83 @ LK4D4 어떤 아이디어 / 업데이트?

mjsalinger 에 2015년 07월 01일

무엇을 생각해야할지 몰라. 도커 정보도 중단되기 때문에 소프트웨어 교착 상태가 아닙니다. 이것이 메모리 누수 일 수 있습니까?

LK4D4 에 2015년 07월 01일

PID USER PR NI VIRT RES SHR S % CPU % MEM TIME + COMMAND
루트 20 0 1314832 89688 11568 S 0.3 2.3 65 : 47.56 도커

이것이 Docker 프로세스가 사용하는 것입니다. 나에게 메모리 누수처럼 보이지 않습니다 ...

mjsalinger 에 2015년 07월 01일

나는 그것에 대해 "우리도"라고 말할 것이다. 우리는 테스트 인프라에 Docker를 사용하고 있으며 동일한 조건 / 시나리오 내에서 문제가 발생합니다. 이것은 Docker가 부하 상태에서 잠긴 경우 의미있는 방식으로 Docker를 사용하는 능력에 영향을 미칠 것입니다.

정보로 필요한 것을 알려 주시면 문제 해결 결과를 기꺼이 기꺼이 제공하겠습니다.

nicolasnoble 에 2015년 07월 10일

CentOS7 호스트에서 동일한 문제가 발생했습니다.

$ docker version
Client version: 1.6.2
Client API version: 1.18
Go version (client): go1.4.2
Git commit (client): ba1f6c3/1.6.2
OS/Arch (client): linux/amd64
Server version: 1.6.2
Server API version: 1.18
Go version (server): go1.4.2
Git commit (server): ba1f6c3/1.6.2
OS/Arch (server): linux/amd64

$ docker info
Containers: 7
Images: 672
Storage Driver: devicemapper
 Pool Name: docker-253:2-67171716-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file: /dev/mapper/vg01-docker--data
 Metadata file: /dev/mapper/vg01-docker--metadata
 Data Space Used: 54.16 GB
 Data Space Total: 59.06 GB
 Data Space Available: 4.894 GB
 Metadata Space Used: 53.88 MB
 Metadata Space Total: 5.369 GB
 Metadata Space Available: 5.315 GB
 Udev Sync Supported: true
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.0-229.7.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 8
Total Memory: 31.25 GiB

이것은 우리 CI 시스템에서 발생했습니다. 병렬 작업 수를 변경 한 다음 4 개의 작업을 병렬로 시작했습니다. 따라서 4-6 개의 컨테이너가 실행되었습니다. 로드는 약 10 개였습니다 (8 개 코어 중 일부는 여전히 유휴 상태 임).

모든 컨테이너가 정상적으로 작동하는 동안 dockerd 자체가 멈췄습니다. docker images 은 (는) 여전히 이미지를 표시하지만 docker ps 또는 docker info 와 같은 모든 데몬 명령이 중단되었습니다.

내 strace는 위의 것과 유사했습니다.

strace -p 1194
Process 1194 attached
futex(0x11d2838, FUTEX_WAIT, 0, NULL

잠시 후 모든 컨테이너가 작업 (컴파일, 테스트 ..)을 완료했지만 둘 다 "반환"되지 않았습니다. 마치 그들이도 커드를 기다리는 것처럼 보입니다.

마침내 dockerd를 죽였을 때 컨테이너는 다음과 같은 메시지로 종료되었습니다.

time="2015-08-05T15:59:32+02:00" level=fatal msg="Post http:///var/run/docker.sock/v1.18/containers/9117731bd16a451b89fd938f569c39761b5f8d6df505256e172738e0593ba125/wait: EOF. Are you trying to connect to a TLS-enabled daemon without TLS?"

filex 에 2015년 08월 05일

CI 환경에서 Centos 7의 @filex 와 동일한 것을보고 있습니다.

Containers: 1
Images: 19
Storage Driver: devicemapper
 Pool Name: docker--vg-docker--pool
 Pool Blocksize: 524.3 kB
 Backing Filesystem: xfs
 Data file:
 Metadata file:
 Data Space Used: 2.611 GB
 Data Space Total: 32.17 GB
 Data Space Available: 29.56 GB
 Metadata Space Used: 507.9 kB
 Metadata Space Total: 54.53 MB
 Metadata Space Available: 54.02 MB
 Udev Sync Supported: true
 Deferred Removal Enabled: true
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.0-229.11.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 2
Total Memory: 7.389 GiB
Name: ip-10-1-2-234
ID: 5YVL:O32X:4NNA:ICSJ:RSYS:CNCI:6QVC:C5YR:XGR4:NQTW:PUSE:YFTA

Client version: 1.7.1
Client API version: 1.19
Package Version (client): docker-1.7.1-108.el7.centos.x86_64
Go version (client): go1.4.2
Git commit (client): 3043001/1.7.1
OS/Arch (client): linux/amd64
Server version: 1.7.1
Server API version: 1.19
Package Version (server): docker-1.7.1-108.el7.centos.x86_64
Go version (server): go1.4.2
Git commit (server): 3043001/1.7.1
OS/Arch (server): linux/amd64

fishnix 에 2015년 08월 12일

여기에서도 동일합니다. docker가 ps, rm, stop, run, info 등에 응답하지 않았습니다. 몇 번 재부팅하면 모든 것이 정상으로 돌아 왔습니다.

 도커 정보
 컨테이너 : 25
 이미지 : 1739
 스토리지 드라이버 : devicemapper
 풀 이름 : docker-9 : 2-62521632-pool
 풀 블록 크기 : 65.54 kB
 백업 파일 시스템 : extfs
 데이터 파일 : / dev / loop0
 메타 데이터 파일 : / dev / loop1
 사용 된 데이터 공간 : 96.01GB
 총 데이터 공간 : 107.4GB
 사용 가능한 데이터 공간 : 11.36GB
 사용 된 메타 데이터 공간 : 110.5MB
 총 메타 데이터 공간 : 2.147GB
 사용 가능한 메타 데이터 공간 : 2.037GB
 Udev 동기화 지원 : true
 지연 제거 활성화 : false
 데이터 루프 파일 : / var / lib / docker / devicemapper / devicemapper / data
 메타 데이터 루프 파일 : / var / lib / docker / devicemapper / devicemapper / metadata
 라이브러리 버전 : 1.02.93-RHEL7 (2015-01-28)
 실행 드라이버 : native-0.2
 로깅 드라이버 : json-file
 커널 버전 : 3.10.0-229.11.1.el7.x86_64
 운영 체제 : CentOS Linux 7 (코어)
 CPU : 8
 총 메모리 : 31.2GiB
 이름 : CentOS-70-64-minimal
 ID : EM3I : PELO : SBH6 : JRVL : AM6C : UM7W : XJWJ : FI5N : JO77 : 7PMF : S57A : PLAT

 도커 버전
 클라이언트 버전 : 1.7.1
 클라이언트 API 버전 : 1.19
 패키지 버전 (클라이언트) : docker-1.7.1-108.el7.centos.x86_64
 Go 버전 (클라이언트) : go1.4.2
 Git 커밋 (클라이언트) : 3043001 / 1.7.1
 OS / Arch (클라이언트) : linux / amd64
 서버 버전 : 1.7.1
 서버 API 버전 : 1.19
 패키지 버전 (서버) : docker-1.7.1-108.el7.centos.x86_64
 Go 버전 (서버) : go1.4.2
 Git 커밋 (서버) : 3043001 / 1.7.1
 OS / Arch (서버) : linux / amd64

avanja 에 2015년 08월 21일

나는 1.6.2와 1.8.2를 사용하고 있으며 도커 설정도 부하로 인해 녹고 있습니다. Docker 작업 대기열이 새로운 호출이 몇 분 걸리는 지점까지 천천히 채워지는 것 같습니다. 파일 시스템을 조정하고 컨테이너 수를 적게 유지하면 상황이 좀 더 나아집니다. 나는 여전히 몇 가지 패턴을 찾고 있습니다.

$ docker version
Client:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   44b3b67
 Built:        Mon Sep 14 23:56:40 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   44b3b67
 Built:        Mon Sep 14 23:56:40 UTC 2015
 OS/Arch:      linux/amd64

whosthatknocking 에 2015년 09월 19일

여기도 마찬가지입니다. 이 스레드를 발견하게되어 기쁩니다. 지난 2 주 동안 문제가 무엇인지 확인하려고 마음을 잃었습니다.
동시에 시작되는 컨테이너의 양이라고 생각합니다. 고전적인 교착 상태의 경우처럼 보입니다.

ohade 에 2015년 09월 20일

제 경우에는 동시에 시작되는 컨테이너로 가득 찬 손에 불과했습니다 (아마도 3-5). 그러나 그들 모두는 데몬에 추가 스트레스를 줄 수있는 STDIN (도커 실행의)을 통해 큰 입력 스트림을 수신합니다.

filex 에 2015년 09월 20일

@filex 는 비슷한 사용 사례를 가지고 있습니다. 1.8.2로 마이그레이션하기 전에는 이러한 동결에 직면하지 않았지만

oncletom 에 2015년 09월 29일

오늘 나는 이와 같은 문제를 만난다-docker ps frozen, docker는 100 % cpu를 먹습니다.
이제 내 datadog-agent가이 옵션을 사용하여 컨테이너에 대해 루프에서 docker를 요청한 것을 볼 수 있습니다.

collect_container_size: true

그래서 나는 매우 어려운 작업으로 무한 루프를 가지고 있습니다 (10k 이상의 컨테이너가 있습니다). 내가 datadog docker 통합을 중지 한 후 시스템 runnig ok-docker ps가 작동하고 docker는 0 % cpu를 먹습니다.

PlugIN73 에 2015년 09월 30일

❤2

나는 cadvisor로 실험하고 있고 그것은 또한 도커를 녹이고 있습니다.

whosthatknocking 에 2015년 10월 01일

당신의 발견에 대해 더 자세히 설명해 주시겠습니까?

2015 년 10 월 1 일 목요일 00:23 Alexander Vagin [email protected] 은 다음과 같이 썼습니다.

오늘 나는 이와 같은 문제를 만난다-docker ps frozen, docker는 100 % cpu를 먹습니다.
그리고 이제 내 datadog-agent가 루프에서 도커에게 물어 봤습니다.
이 옵션이있는 컨테이너 :
collect_container_size : true
그래서 나는 매우 어려운 작업으로 무한 루프를 가지고 있습니다 (나는 10k 이상
용기). 데이터 독 도커 통합을 중지 한 후 시스템 실행 확인-
docker ps가 작동하고 docker는 0 % cpu를 먹습니다.
—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/13885#issuecomment -144546581.

ohade 에 2015년 10월 01일

@ohade 내 도커는 연중 무휴로 작동하지 않습니다. 매번 60-80 개의 시작된 컨테이너가 있습니다. 하루에 약 1500 개의 새 컨테이너가 있습니다. 그래서이 부하로 인해 고정되고 도커에서만 (시스템에 여유 메모리, io, cpu가 많음) 일반적인 문제가 아니라고 생각했습니다.
누군가가 로그 (/var/log/upstart/docker.logs)에서 내 도커에 요청을 보내는 것을 발견했습니다. 그리고 나는 그것이 누구인지 찾았습니다 :)
무엇을 더 말합니까?

PlugIN73 에 2015년 10월 01일

:) 저는 그 에이전트가 도커의 일부이며 크기를 조정할 수 있습니다.
너무 확인하거나 외부 에이전트입니까?

2015 년 10 월 1 일 목요일 14:03 Alexander Vagin [email protected] 은 다음과 같이 썼습니다.

@ohade https://github.com/ohade 내도 커가 멈추지 않고 작동합니다.
24/7. 매번 60-80 개의 시작된 컨테이너가 있습니다. 나는 약 1500 개의 새로운
하루에 용기. 그래서이 부하로봤을 때 얼어 붙고
도커에서만 (시스템에 많은 여유 메모리, io, cpu가 있음), 나는
일반적인 문제가 아닙니다.
누군가 로그에서 내 도커에 요청을 보내는 것을 발견했습니다.
(/var/log/upstart/docker.logs). 그리고 나는 그것이 누구인지 찾았습니다 :)
무엇을 더 말합니까?
—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/13885#issuecomment -144697619.

ohade 에 2015년 10월 02일

@ohade 아니, 도커의 일부가 아닙니다. 도커 문제가 아니라고 생각합니다. Docker에 대한 과도한 요청이 있는지 환경을 확인해야합니다.

PlugIN73 에 2015년 10월 02일

도커 1.8.2로 업데이트 한 이후에도이 문제가 발생합니다.

naglalakk 에 2015년 10월 13일

이것에 대한 진전이 있습니까? 테스트 인프라에서 많은 수 또는 수명이 짧은 컨테이너를 회전하고 있으며 하루에 한 번 이상이 문제를 겪고 있습니다.

jtattermusch 에 2015년 10월 20일

docker version
Client:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Thu Sep 10 19:12:52 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:12:52 UTC 2015
 OS/Arch:      linux/amd64

Linux 버전 :

$ uname -a
Linux grpc-interop1 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u3~bpo70+1 (2015-08-08) x86_64 GNU/Linux

jtattermusch 에 2015년 10월 20일

1.8.3으로 이동했습니다.

# docker version 
Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:        Mon Oct 12 06:06:01 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 06:06:01 UTC 2015
 OS/Arch:      linux/amd64

그러나 그럼에도 불구하고 처음에는 며칠에 한 번, 나중에는 하루에 10 번까지 계속 충돌했습니다. 장치 매퍼 / 루프백이있는 CentOS 7에서 AUFS가 정렬 된 Ubuntu 14.04 LTS로 마이그레이션했습니다.

avanja 에 2015년 10월 20일

이 문제도 확인했습니다. https://github.com/docker/docker/issues/12606#issuecomment -149659953

이 kubernetes의 e2e 테스트를 루프에서 실행하여 문제를 안정적으로 재현 할 수 있습니다.

데몬의 추적 로그를 잡았습니다. 교착 상태가있는 것 같습니다. 많은 고 루틴이 semacquire 에 걸려 있습니다.

goroutine 8956 [semacquire, 8 minutes]:
sync.(*Mutex).Lock(0xc208961650)
/usr/lib/go/src/sync/mutex.go:66 +0xd3
github.com/docker/docker/daemon.func·028(0xc20861c1e0, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/list.go:84 +0xfc
github.com/docker/docker/daemon.(*Daemon).Containers(0xc2080a50a0, 0xc209ec4820, 0x0, 0x0, 0x0, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/list.go:187 +0x917
github.com/docker/docker/api/server.(*Server).getContainersJSON(0xc208032540, 0xc3f700, 0x4, 0x7f214584f110, 0xc20a306d20, 0xc209d4a9c0, 0xc20a09fa10, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/api/server/server.go:562 +0x3ba
github.com/docker/docker/api/server.*Server.(github.com/docker/docker/api/server.getContainersJSON)·fm(0xc3f700, 0x4, 0x7f214584f110, 0xc20a306d20, 0xc209d4a9c0, 0xc20a09fa10, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/api/server/server.go:1526 +0x7b
github.com/docker/docker/api/server.func·008(0x7f214584f110, 0xc20a306d20, 0xc209d4a9c0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/api/server/server.go:1501 +0xacd
net/http.HandlerFunc.ServeHTTP(0xc208033380, 0x7f214584f110, 0xc20a306d20, 0xc209d4a9c0)
/usr/lib/go/src/net/http/server.go:1265 +0x41
github.com/gorilla/mux.(*Router).ServeHTTP(0xc2080b1090, 0x7f214584f110, 0xc20a306d20, 0xc209d4a9c0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/vendor/src/github.com/gorilla/mux/mux.go:98 +0x297
net/http.serverHandler.ServeHTTP(0xc20804f080, 0x7f214584f110, 0xc20a306d20, 0xc209d4a9c0)
/usr/lib/go/src/net/http/server.go:1703 +0x19a
net/http.(*conn).serve(0xc208743680)
/usr/lib/go/src/net/http/server.go:1204 +0xb57
created by net/http.(*Server).Serve
/usr/lib/go/src/net/http/server.go:1751 +0x35e

여기에 전체 추적 :
https://gist.github.com/yifan-gu/ac0cbc2a59a7b8c3fe2d

yifan-gu 에 2015년 10월 21일

최신 버전에서 테스트를 시도합니다.

yifan-gu 에 2015년 10월 21일

여전히 1.7.1로 다른 실행을 시도했지만 이번에는 더 흥미로운 것을 발견했습니다.

goroutine 114 [syscall, 50 minutes]:
syscall.Syscall6(0x3d, 0x514, 0xc2084e74fc, 0x0, 0xc208499950, 0x0, 0x0, 0x44199c, 0x441e22, 0xb28140)
/usr/lib/go/src/syscall/asm_linux_amd64.s:46 +0x5
syscall.wait4(0x514, 0xc2084e74fc, 0x0, 0xc208499950, 0x90, 0x0, 0x0)
/usr/lib/go/src/syscall/zsyscall_linux_amd64.go:124 +0x79
syscall.Wait4(0x514, 0xc2084e7544, 0x0, 0xc208499950, 0x41a768, 0x0, 0x0)
/usr/lib/go/src/syscall/syscall_linux.go:224 +0x60
os.(*Process).wait(0xc2083e2b20, 0xc20848a860, 0x0, 0x0)
/usr/lib/go/src/os/exec_unix.go:22 +0x103
os.(*Process).Wait(0xc2083e2b20, 0xc2084e7608, 0x0, 0x0)
/usr/lib/go/src/os/doc.go:45 +0x3a
os/exec.(*Cmd).Wait(0xc2083c9a40, 0x0, 0x0)
/usr/lib/go/src/os/exec/exec.go:364 +0x23c
github.com/docker/libcontainer.(*initProcess).wait(0xc20822cf30, 0x1b6, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/vendor/src/github.com/docker/libcontainer/process_linux.go:194 +0x3d
github.com/docker/libcontainer.Process.Wait(0xc208374a30, 0x1, 0x1, 0xc20839b000, 0x47, 0x80, 0x127e348, 0x0, 0x127e348, 0x0, ...)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/vendor/src/github.com/docker/libcontainer/process.go:60 +0x11d
github.com/docker/libcontainer.Process.Wait·fm(0xc2084e7ac8, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/execdriver/native/driver.go:164 +0x58
github.com/docker/docker/daemon/execdriver/native.(*driver).Run(0xc20813c230, 0xc20832a900, 0xc20822cc00, 0xc208374900, 0x0, 0x41a900, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/execdriver/native/driver.go:170 +0xa0a
github.com/docker/docker/daemon.(*Daemon).Run(0xc2080a5880, 0xc2080a21e0, 0xc20822cc00, 0xc208374900, 0x0, 0xc2084b6000, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/daemon.go:1068 +0x95
github.com/docker/docker/daemon.(*containerMonitor).Start(0xc20853d180, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/monitor.go:138 +0x457
github.com/docker/docker/daemon.*containerMonitor.Start·fm(0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/container.go:732 +0x39
github.com/docker/docker/pkg/promise.func·001()
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/pkg/promise/promise.go:8 +0x2f
created by github.com/docker/docker/pkg/promise.Go
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/pkg/promise/promise.go:9 +0xfb

나는 여기에 그런 고 루틴이 매달려있는 것을 보았다. Container.Start() 가 중단되면 컨테이너 잠금이 해제되지 않고 다음 docker ps 이 모두 중단됩니다. (이것은 v.1.9.0-rc1에서도 마찬가지인 것 같습니다)

나는 확실하지 왜 나는 비록 Container.Start() 이 중단이가 유일한 원인인지 docker ps 끊습니다.

https://github.com/docker/docker/blob/v1.9.0-rc1/daemon/container.go#L243
https://github.com/docker/docker/blob/v1.9.0-rc1/daemon/container.go#L304
https://github.com/docker/docker/blob/v1.9.0-rc1/daemon/list.go#L113

어쨌든 그러한 syscall 전에 뮤텍스를 보유하지 않도록 노력해야한다고 생각합니다.

yifan-gu 에 2015년 10월 21일

그것은 나에게 중요한 문제입니다. Docker의 누군가가 이것을 조사하고 있습니까?

ohade 에 2015년 10월 21일

👍1

핑 @ LK4D4 @tiborvass ^^ https://github.com/docker/docker/issues/13885#issuecomment -149767470

thaJeztah 에 2015년 10월 21일

docker 1.8.2에서 비슷한 문제가 있습니다. 데몬에 일상적인 누출이나 기타 누출이 있다고 생각합니다.

빠른 생성 / 삭제 스트레스를 받으면 docker ps 은 (는) 완료하는 데 영원히 걸리고 결국 docker 데몬은 휴식을 잃게됩니다.

thefallentree 에 2015년 10월 26일

1.8.2와 비슷한 문제가 있습니다. 나는 1.9 rc2를 시도했고 비슷한 문제, 많은 중단 및 docker 데몬을 다시 시작했는데 때로는 문제가 해결되었지만 더 자주 그렇지 않았습니다.

pspierce 에 2015년 11월 02일

무언가가 언제 멈추는 지 궁금합니다. 죽기까지 얼마나 걸리나요?
그냥 기다리게 놔두면 다시 돌아 오나요?

cpuguy83 에 2015년 11월 02일

시간을 정하지는 않았지만 적어도 20 분이 넘었다 고 말하고 싶습니다. 나는 docker-compose kill vs. stop을 사용하기 시작했으며 더 좋아 보이지만 시간이 알려줄 것입니다. 로그에서도 분명한 것이 보이지 않습니다.

pspierce 에 2015년 11월 02일

centos 7.1, docker 1.8.2에서도 볼 수 있습니다. 내 직감은 그것이 데이터 매퍼 / 루프백 문제라고 말해줍니다.

다음 목록은 이것을 시도하는 것입니다 : https://github.com/projectatomic/docker-storage-setup (h / t @ibuildthecloud )

tobowers 에 2015년 11월 03일

또한 이것을 경험하고 무거운 부하가 아닙니다.

Centos 7

Docker 버전

Client:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Thu Sep 10 19:08:45 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:08:45 UTC 2015
 OS/Arch:      linux/amd64

Docker 정보

Containers: 4
Images: 40
Storage Driver: devicemapper
 Pool Name: docker-202:1-25190844-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 2.914 GB
 Data Space Total: 107.4 GB
 Data Space Available: 81.05 GB
 Metadata Space Used: 4.03 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.143 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.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.0-123.8.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 4
Total Memory: 6.898 GiB
Name: ip-10-50-185-203
ID: EOMR:4G7Y:7H6O:QOXE:WW4Z:3R2G:HLI4:ZMXY:GKF3:YKSK:TIHC:MHZF
[centos@ip-10-50-185-203 ~]$ uname -a
Linux ip-10-50-185-203 3.10.0-123.8.1.el7.x86_64 #1 SMP Mon Sep 22 19:06:58 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

docker 이미지는 작동하지만 docker ps가 중단됩니다.

strace 출력의 마지막 몇 줄 :

clock_gettime(CLOCK_MONOTONIC, {2393432, 541406232}) = 0
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
connect(3, {sa_family=AF_LOCAL, sun_path="/run/systemd/journal/socket"}, 30) = 0
epoll_create1(EPOLL_CLOEXEC)            = 4
epoll_ctl(4, EPOLL_CTL_ADD, 3, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=2856433208, u64=139812631852600}}) = 0
getsockname(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0
getpeername(3, {sa_family=AF_LOCAL, sun_path="/run/systemd/journal/socket"}, [30]) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 542834304}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 542897330}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543010460}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543090332}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543157219}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543208557}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543306537}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543364486}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 108316907}) = 0
mmap(0xc208100000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc208100000
mmap(0xc207fe0000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc207fe0000
clock_gettime(CLOCK_MONOTONIC, {2393432, 543814528}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543864338}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543956865}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 544018495}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 544402150}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 544559595}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 544607443}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 109474379}) = 0
epoll_wait(4, {{EPOLLOUT, {u32=2856433208, u64=139812631852600}}}, 128, 0) = 1
clock_gettime(CLOCK_MONOTONIC, {2393432, 544968692}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545036728}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545095771}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545147947}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545199057}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545251039}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545308858}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545756723}) = 0
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_REALTIME, {1446718224, 112187655}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 112265169}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 112345304}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 547677486}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 547743669}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 547801800}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 547864215}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 547934364}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 548042167}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 548133574}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 548209405}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 113124453}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 548493023}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 548566472}) = 0
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_MONOTONIC, {2393432, 549410983}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 549531015}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 549644468}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 549713961}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 549800266}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 549864335}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
stat("/root/.docker/config.json", 0xc208052900) = -1 ENOENT (No such file or directory)
stat("/root/.dockercfg", 0xc208052990)  = -1 ENOENT (No such file or directory)
clock_gettime(CLOCK_REALTIME, {1446718224, 115099477}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 115153125}) = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 5
setsockopt(5, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
connect(5, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, 23) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 550603891}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 115517051}) = 0
epoll_ctl(4, EPOLL_CTL_ADD, 5, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=2856433016, u64=139812631852408}}) = 0
getsockname(5, {sa_family=AF_LOCAL, NULL}, [2]) = 0
getpeername(5, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, [23]) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 550961223}) = 0
read(5, 0xc208131000, 4096)             = -1 EAGAIN (Resource temporarily unavailable)
clock_gettime(CLOCK_MONOTONIC, {2393432, 551138398}) = 0
write(5, "GET /v1.20/containers/json HTTP/"..., 108) = 108
epoll_wait(4, {{EPOLLOUT, {u32=2856433016, u64=139812631852408}}}, 128, 0) = 1
epoll_wait(4,

chbatey 에 2015년 11월 05일

@chbatey 댓글을 편집하고 docker version 출력을 추가 할 수 있습니까?

thaJeztah 에 2015년 11월 05일

나와 내 얼굴은 빨갛게 칠해. 디버그에서 데몬을 실행하고 cifs 마운트가 중단 된 공유 볼륨을 발견했습니다. 일단 내가 그것을 처리하면 이제는 잘 작동합니다.

pspierce 에 2015년 11월 05일

@pspierce 문제 없습니다. 다시 신고 해 주셔서 감사합니다!

나는 이것이 1.9에서 여전히 문제가 있는지 듣고 싶습니다.

thaJeztah 에 2015년 11월 05일

또한 centos 7.1에서 1.8.2로이 현상이 자주 발생하지만 이탈률이 높은 호스트에서만 발생합니다 (~ 2,100 컨테이너 / 시간). 동일하게 구성된 호스트에 영향을 미치지 않는 것 같지만 볼륨 (시간당 최대 300 개 컨테이너)의 호스트에 영향을주지 않는 것 같습니다. 따라서 많은 동시 작업에 의해 트리거되는 일종의 교착 상태 인 것 같습니다. 우리는 ~ / 6 시간의 높은 이탈 활동을 봅니다. 지금까지 우리가 찾은 유일한 해결책은 '/ var / lib / docker / containers'를 실행하고 '/ var / lib / docker / containers'

우리는 이번 주에 1.9를 시도하고 그것이 전혀 도움이되는지 볼 것입니다 (손가락이 교차했습니다!). fwiw, 우리는 1.6.2에서 이러한 점진적인 응답 성 저하 (및 최종 교착 상태)가 발생하지 않았습니다.

자세한 내용은 다음과 같습니다. 현재 설정 :

PRODUCTION [[email protected] ~]$ docker -D info
Containers: 8
Images: 41
Storage Driver: overlay
 Backing Filesystem: xfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.3.0-1.el7.elrepo.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 4
Total Memory: 7.796 GiB
Name: cc-docker01.prod.iad01.treehouse
ID: AB4S:SO4Z:AEOS:MC3H:XPRV:SIH4:VE2N:ELYX:TA5S:QQWP:WDAP:DUKE
Username: xxxxxxxxxxxxxx
Registry: https://index.docker.io/v1/
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

PRODUCTION [[email protected] ~]$ docker -D version
Client:
 Version:      1.8.2
 API version:  1.20
 Package Version: docker-1.8.2-7.el7.centos.x86_64
 Go version:   go1.4.2
 Git commit:   bb472f0/1.8.2
 Built:        
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.2
 API version:  1.20
 Package Version: 
 Go version:   go1.4.2
 Git commit:   bb472f0/1.8.2
 Built:        
 OS/Arch:      linux/amd64

nathwill 에 2015년 11월 20일

또한 우분투 14.04에서 8 개의 컨테이너 만 실행되지만 디스크 및 CPU 부하가 높습니다. 컨테이너는 완료되면 다시 시작되므로 항상 8 개가 실행됩니다. 데몬은 수백에서 수천 개의 누적 컨테이너 실행 후에 죽어 가고 있습니다. 루프백을 실행할 때 데몬이 멈추는 것을 보지 못했지만 씬풀을 사용하여 지난 며칠 동안 두 번 발생했습니다. 이것은 64GB RAM이있는 40 코어 워크 스테이션에 있습니다.

Docker 버전 :
~ $ 도커 버전
고객:
버전 : 1.9.1
API 버전 : 1.21
Go 버전 : go1.4.2
힘내 커밋 : a34a1d5
건축 : 2015 년 11 월 20 일 금요일 13:12:04 UTC
OS / 아치 : linux / amd64

섬기는 사람:
버전 : 1.9.1
API 버전 : 1.21
Go 버전 : go1.4.2
힘내 커밋 : a34a1d5
건축 : 2015 년 11 월 20 일 금요일 13:12:04 UTC
OS / 아치 : linux / amd64

--- Docker 이미지가 작동하지만 docker ps가 중단됩니다. 도커 정보도 중단됩니다. 다음은 docker ps에 대한 strace의 끝입니다.
소켓 (PF_LOCAL, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK, 0) = 3
setsockopt (3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
connect (3, {sa_family = AF_LOCAL, sun_path = "/ var / run / docker.sock"}, 23) = 0
epoll_create1 (EPOLL_CLOEXEC) = 4
epoll_ctl (4, EPOLL_CTL_ADD, 3, {EPOLLIN | EPOLLOUT | EPOLLRDHUP | EPOLLET, {u32 = 3565442144, u64 = 140517715498080}}) = 0
getsockname (3, {sa_family = AF_LOCAL, NULL}, [2]) = 0
getpeername (3, {sa_family = AF_LOCAL, sun_path = "/ var / run / docker.sock"}, [23]) = 0
read (3, 0xc208506000, 4096) = -1 EAGAIN (일시적으로 사용할 수없는 리소스)
write (3, "GET /v1.21/containers/json HTTP /"..., 108) = 108
epoll_wait (4, {{EPOLLOUT, {u32 = 3565442144, u64 = 140517715498080}}}, 128, 0) = 1
epoll_wait (4,

bavery22 에 2015년 12월 03일

1.7.1 미만이었고 매우 효과적으로 해결했습니다 (1.7.1 미만에서 몇 시간마다 확인했지만 1 개월 이상의 사후 해결 방법은 없었습니다).

udevadm control --timeout=300

RHEL7.1을 실행하고 있습니다. 우리는 다른 변경없이 Docker 1.8.2로 업그레이드했고 몇 시간 내에 앱이 잠겼습니다. Strace :

``
[pid 4200] open ( "/ sys / fs / cgroup / freezer / system.slice / docker-bcb29dad6848d250df7508f85e78ca9b83d40f0e22011869d89a176e27b7ef87.scope / freezer.state", O_RDONLY | O_CLOEXEC) = 36
[pid 4200] fstat (36, {st_mode = S_IFREG | 0644, st_size = 0, ...}) = 0
[pid 4239] <... 재개 선택>) = 0 (시간 초과)
[pid 4200] 읽기 (36, [pid 4239] select (0, NULL, NULL, NULL, {0, 20} [pid 4200] <... 읽기 재개 됨> "FREEZINGn", 512) = 9
[pid 4200] read (36, "", 1527) = 0
[pid 4200] close (36) = 0
[pid 4200] futex (0x1778e78, FUTEX_WAKE, 1 [pid 4239] <... 재개 선택>) = 0 (시간 초과)
[pid 5252] <... 퓨 텍스 재개 됨>) = 0
[pid 4200] <... futex 재개 됨>) = 1
[pid 5252] futex (0xc2085daed8, FUTEX_WAIT, 0, NULL [pid 4239] select (0, NULL, NULL, NULL, {0, 20} [pid 4200] futex (0xc2085daed8, FUTEX_WAKE, 1 [pid 5252] <... futex가 재개 됨>) = -1 EAGAIN (일시적으로 리소스를 사용할 수 없음)
[pid 4200] <... futex 재개 됨>) = 0
[pid 5252] epoll_wait (4, [pid 4200] futex (0x1778e78, FUTEX_WAIT, 0, {0, 958625} [pid 5252] <... epoll_wait resumed> {}, 128, 0) = 0
[pid 5252] futex (0xc2085daed8, FUTEX_WAIT, 0, NULL [pid 4239] <... 재개 선택>) = 0 (시간 초과)

daviesalex 에 2015년 12월 08일

우리는 동일한 문제에 직면하고 있습니다 https://github.com/giantswarm/giantswarm/issues/289

hectorj2f 에 2015년 12월 15일

업데이트 : 인터리브 된 docker run / docker rm 에 대한 내 가설이 불건전 한 것 같습니다. 나는 동시에 많은 docker run 시도했지만 동작을 트리거하기에 충분했습니다. 또한 dm thinpool로 전환하려고 시도했지만 도움이되지 않았습니다. 내 해결 방법은 단순히 여러 컨테이너가 "동일"시간에 시작되지 않도록하는 것입니다. 즉, 시작 사이에 최소 ~ 10-30 초 간격을 추가합니다. 이제 데몬은 2 주 이상 문제없이 실행됩니다. 업데이트 종료.

확인을 하나 더 추가하기 위해 1.9.0에서이를 확인할 수 있습니다. 우리는 한 번에 최대 8 개의 컨테이너 (코어 당 1 개)를 생성하지 않고 시간당 40 개를 넘지 않습니다. 원본 보고서의 공통점 중 하나는 docker run 및 docker rm -f 인터리브 호출도 몇 번 수행한다는 것입니다. 내 직감은 교착 상태를 유발하는 동시 컨테이너 생성 및 삭제의 조합이라는 것입니다.

$ docker version
Client:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 18:00:05 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 18:00:05 UTC 2015
 OS/Arch:      linux/amd64

$ docker -D info
Containers: 10
Images: 119
Server Version: 1.9.0
Storage Driver: devicemapper
 Pool Name: docker-253:1-2114818-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 107.4 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 7.234 GB
 Data Space Total: 107.4 GB
 Data Space Available: 42.64 GB
 Metadata Space Used: 10.82 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.137 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
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.0-229.20.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 8
Total Memory: 15.51 GiB

yfyf 에 2015년 12월 23일

@mjsalinger 우리는 당신과 같은 문제를 가지고 있는데, 같은 설정으로 문제를 해결 했습니까?

EddieJamsession 에 2016년 01월 07일

여기에 같은 문제

~ # docker info
Containers: 118
Images: 2239
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.2-coreos-r1
Operating System: CoreOS 835.8.0
CPUs: 16
Total Memory: 29.44 GiB
Username: util-user
Registry: https://index.docker.io/v1/
Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   cedd534-dirty
 Built:        Tue Dec  1 02:00:58 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   cedd534-dirty
 Built:        Tue Dec  1 02:00:58 UTC 2015
 OS/Arch:      linux/amd64

우리의 로그는 다음과 같은 것들로 가득 차 있습니다.

time="2016-01-08T21:38:34.735146159Z" level=error msg="Failed to compute size of container rootfs e4565ff148266389cbf70af9f22f9c62aa255bacaec0925a72eab5d0dca9da5f: Error getting container e4565ff148266389cbf70af9f22f9c62aa255bacaec0925a72eab5d0dca9da5f from driver overlay: stat /var/lib/docker/overlay/e4565ff148266389cbf70af9f22f9c62aa255bacaec0925a72eab5d0dca9da5f: no such file or directory"

과

time="2016-01-08T21:42:34.846701169Z" level=error msg="Handler for GET /containers/json returned error: write unix @: broken pipe"
time="2016-01-08T21:42:34.846717812Z" level=error msg="HTTP Error" err="write unix @: broken pipe" statusCode=500

그러나 어떤 것이 교수형 문제와 관련이 있는지 확실하지 않습니다.

chr0n1x 에 2016년 01월 08일

SIGUSR1을 데몬에 전송하여 모든 도커 고 루틴 스택의 덤프를 포함하는 것이 도움이 될 수 있습니다 ..

whosthatknocking 에 2016년 01월 08일

@whosthatknocking 은 내가 할 수 있다는 것을 몰랐습니다.

time="2016-01-08T22:20:16.181468178Z" level=info msg="=== BEGIN goroutine stack dump ===
goroutine 11 [running]:
github.com/docker/docker/pkg/signal.DumpStacks()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/signal/trap.go:60 +0x7a
github.com/docker/docker/daemon.func·025()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/debugtrap_unix.go:18 +0x6d
created by github.com/docker/docker/daemon.setupDumpStackTrap
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/debugtrap_unix.go:20 +0x18e

goroutine 1 [chan receive, 33262 minutes]:
main.(*DaemonCli).CmdDaemon(0xc20807d1a0, 0xc20800a020, 0x1, 0x1, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/docker/daemon.go:289 +0x1781
reflect.callMethod(0xc208142060, 0xc20842fce0)
    /usr/lib/go/src/reflect/value.go:605 +0x179
reflect.methodValueCall(0xc20800a020, 0x1, 0x1, 0x1, 0xc208142060, 0x0, 0x0, 0xc208142060, 0x0, 0x452ecf, ...)
    /usr/lib/go/src/reflect/asm_amd64.s:29 +0x36
github.com/docker/docker/cli.(*Cli).Run(0xc20810df80, 0xc20800a010, 0x2, 0x2, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/cli/cli.go:89 +0x38e
main.main()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/docker/docker.go:69 +0x428

goroutine 5 [syscall]:
os/signal.loop()
    /usr/lib/go/src/os/signal/signal_unix.go:21 +0x1f
created by os/signal.init·1
    /usr/lib/go/src/os/signal/signal_unix.go:27 +0x35

goroutine 17 [syscall, 33262 minutes, locked to thread]:
runtime.goexit()
    /usr/lib/go/src/runtime/asm_amd64.s:2232 +0x1

goroutine 13 [IO wait, 33262 minutes]:
net.(*pollDesc).Wait(0xc2081eb100, 0x72, 0x0, 0x0)
    /usr/lib/go/src/net/fd_poll_runtime.go:84 +0x47
net.(*pollDesc).WaitRead(0xc2081eb1
00, 0x0, 0x0)
    /usr/lib/go/src/net/fd_poll_runtime.go:89 +0x43
net.(*netFD).readMsg(0xc2081eb0a0, 0xc2081bd9a0, 0x10, 0x10, 0xc208440020, 0x1000, 0x1000, 0xffffffffffffffff, 0x0, 0x0, ...)
    /usr/lib/go/src/net/fd_unix.go:296 +0x54e
net.(*UnixConn).ReadMsgUnix(0xc2080384b8, 0xc2081bd9a0, 0x10, 0x10, 0xc208440020, 0x1000, 0x1000, 0x51, 0xc2081bd6d4, 0x4, ...)
    /usr/lib/go/src/net/unixsock_posix.go:147 +0x167
github.com/godbus/dbus.(*oobReader).Read(0xc208440000, 0xc2081bd9a0, 0x10, 0x10, 0xc208440000, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/transport_unix.go:21 +0xc5
io.ReadAtLeast(0x7f9ad52e9310, 0xc208440000, 0xc2081bd9a0, 0x10, 0x10, 0x10, 0x0, 0x0, 0x0)
    /usr/lib/go/src/io/io.go:298 +0xf1
io.ReadFull(0x7f9ad52e9310, 0xc208440000, 0xc2081bd9a0, 0x10, 0x10, 0x51, 0x0, 0x0)
    /usr/lib/go/src/io/io.go:316 +0x6d
github.com/godbus/dbus.(*unixTransport).ReadMessage(0xc2081df900, 0xc208115170, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/transport_unix.go:85 +0x1bf
github.com/godbus/dbus.(*Conn).inWorker(0xc208418480)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/conn.go:248 +0x58
created by github.com/godbus/dbus.(*Conn).Auth
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/auth.go:118 +0xe84

goroutine 10 [chan receive, 33262 minutes]:
github.com/docker/docker/api/server.(*Server).ServeApi(0xc208037800, 0xc20807d3d0, 0x1, 0x1, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/api/server/server.go:111 +0x74f
main.func·007()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/docker/daemon.go:239 +0x5b
created by main.(*DaemonCli).CmdDaemon
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-
1.8.3/work/docker-1.8.3/docker/daemon.go:245 +0xce9

goroutine 14 [chan receive, 33262 minutes]:
github.com/godbus/dbus.(*Conn).outWorker(0xc208418480)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/conn.go:370 +0x58
created by github.com/godbus/dbus.(*Conn).Auth
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/auth.go:119 +0xea1

goroutine 15 [chan receive, 33262 minutes]:
github.com/docker/libnetwork/iptables.signalHandler()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/docker/libnetwork/iptables/firewalld.go:92 +0x57
created by github.com/docker/libnetwork/iptables.FirewalldInit
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/docker/libnetwork/iptables/firewalld.go:48 +0x185

goroutine 50 [chan receive, 33262 minutes]:
database/sql.(*DB).connectionOpener(0xc2081aa0a0)
    /usr/lib/go/src/database/sql/sql.go:589 +0x4c
created by database/sql.Open
    /usr/lib/go/src/database/sql/sql.go:452 +0x31c

goroutine 51 [IO wait]:
net.(*pollDesc).Wait(0xc2081dcd10, 0x72, 0x0, 0x0)
    /usr/lib/go/src/net/fd_poll_runtime.go:84 +0x47
net.(*pollDesc).WaitRead(0xc2081dcd10, 0x0, 0x0)
    /usr/lib/go/src/net/fd_poll_runtime.go:89 +0x43
net.(*netFD).readMsg(0xc2081dccb0, 0xc20b38c970, 0x10, 0x10, 0xc20bf3b220, 0x1000, 0x1000, 0xffffffffffffffff, 0x0, 0x0, ...)
    /usr/lib/go/src/net/fd_unix.go:296 +0x54e
net.(*UnixConn).ReadMsgUnix(0xc208038618, 0xc20b38c970, 0x10, 0x10, 0xc20bf3b220, 0x1000, 0x1000, 0x35, 0xc20b38c784, 0x4, ...)
    /usr/lib/go/src/net/unixsock_posix.go:147 +0x167
github.com/godbus/dbus.(*oobReader).Read(0xc20bf3b200, 0xc20b38c970, 0x10, 0x10, 0xc20bf3b200, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/transport_unix.go:21 +0xc5
io.ReadAtLeast(0x7f9ad52e9310, 0xc20bf3b200, 0x
c20b38c970, 0x10, 0x10, 0x10, 0x0, 0x0, 0x0)
    /usr/lib/go/src/io/io.go:298 +0xf1
io.ReadFull(0x7f9ad52e9310, 0xc20bf3b200, 0xc20b38c970, 0x10, 0x10, 0x35, 0x0, 0x0)
    /usr/lib/go/src/io/io.go:316 +0x6d
github.com/godbus/dbus.(*unixTransport).ReadMessage(0xc208176950, 0xc208471470, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/transport_unix.go:85 +0x1bf
github.com/godbus/dbus.(*Conn).inWorker(0xc2080b0fc0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/conn.go:248 +0x58
created by github.com/godbus/dbus.(*Conn).Auth
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/auth.go:118 +0xe84

goroutine 52 [chan receive]:
github.com/godbus/dbus.(*Conn).outWorker(0xc2080b0fc0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/conn.go:370 +0x58
created by github.com/godbus/dbus.(*Conn).Auth
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/auth.go:119 +0xea1

goroutine 53 [chan receive]:
github.com/coreos/go-systemd/dbus.func·001()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/coreos/go-systemd/dbus/subscription.go:70 +0x64
created by github.com/coreos/go-systemd/dbus.(*Conn).initDispatch
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/coreos/go-systemd/dbus/subscription.go:94 +0x11c

goroutine 54 [chan receive]:
github.com/docker/docker/daemon.(*statsCollector).run(0xc20844dad0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/stats_collector_unix.go:91 +0xb2
created by github.com/docker/docker/daemon.newStatsCollector
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/wo
rk/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/stats_collector_unix.go:31 +0x116

goroutine 55 [chan receive, 2 minutes]:
github.com/docker/docker/daemon.(*Daemon).execCommandGC(0xc2080908c0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/exec.go:256 +0x8c
created by github.com/docker/docker/daemon.NewDaemon
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/daemon.go:736 +0x2358

goroutine 774 [semacquire, 33261 minutes]:
sync.(*Cond).Wait(0xc208460030)
    /usr/lib/go/src/sync/cond.go:62 +0x9e
io.(*pipe).read(0xc208460000, 0xc208c0bc00, 0x400, 0x400, 0x0, 0x0, 0x0)
    /usr/lib/go/src/io/pipe.go:52 +0x303
io.(*PipeReader).Read(0xc208b52750, 0xc208c0bc00, 0x400, 0x400, 0x1f, 0x0, 0x0)
    /usr/lib/go/src/io/pipe.go:134 +0x5b
github.com/docker/docker/pkg/ioutils.(*bufReader).drain(0xc2084600c0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/ioutils/readers.go:116 +0x10e
created by github.com/docker/docker/pkg/ioutils.NewBufReader
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/ioutils/readers.go:86 +0x2f3

goroutine 784 [semacquire, 33261 minutes]:
sync.(*Cond).Wait(0xc208460570)
    /usr/lib/go/src/sync/cond.go:62 +0x9e
io.(*pipe).read(0xc208460540, 0xc208963000, 0x400, 0x400, 0x0, 0x0, 0x0)
    /usr/lib/go/src/io/pipe.go:52 +0x303
io.(*PipeReader).Read(0xc208b529d8, 0xc208963000, 0x400, 0x400, 0x1f, 0x0, 0x0)
    /usr/lib/go/src/io/pipe.go:134 +0x5b
github.com/docker/docker/pkg/ioutils.(*bufReader).drain(0xc208460600)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/ioutils/readers.go:116 +0x10e
created by github.com/docker/docker/pkg/ioutils.NewBufReader
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/wo
rk/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/ioutils/readers.go:86 +0x2f3

goroutine 757 [semacquire, 33261 minutes]:
sync.(*Cond).Wait(0xc208141cb0)
    /usr/lib/go/src/sync/cond.go:62 +0x9e
github.com/docker/docker/pkg/ioutils.(*bufReader).Read(0xc208141c80, 0xc2089f2000, 0x1000, 0x1000, 0x0, 0x7f9ad52d4080, 0xc20802a0d0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/ioutils/readers.go:210 +0x158
bufio.(*Reader).fill(0xc208956ae0)
    /usr/lib/go/src/bufio/bufio.go:97 +0x1ce
bufio.(*Reader).ReadSlice(0xc208956ae0, 0x41d50a, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/lib/go/src/bufio/bufio.go:295 +0x257
bufio.(*Reader).ReadBytes(0xc208956ae0, 0xc208141c0a, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/lib/go/src/bufio/bufio.go:374 +0xd2
github.com/docker/docker/daemon/logger.(*Copier).copySrc(0xc2084def40, 0xf8ac00, 0x6, 0x7f9ad003e420, 0xc208141c80)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/logger/copier.go:47 +0x96
created by github.com/docker/docker/daemon/logger.(*Copier).Run
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/logger/copier.go:38 +0x11c

goroutine 842 [chan receive, 33261 minutes]:
github.com/docker/docker/daemon.(*Container).AttachWithLogs(0xc208cc90e0, 0x0, 0x0, 0x7f9ad003e398, 0xc208471e30, 0x7f9ad003e398, 0xc208471e00, 0x100, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/container.go:934 +0x40d
github.com/docker/docker/daemon.(*Daemon).ContainerAttachWithLogs(0xc2080908c0, 0xc208cc90e0, 0xc208471dd0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/attach.go:39 +0x42c
github.com/docker/docker/api/server.(*Server).postContainersAttach(0xc208037800, 0xc208b36007, 0x4, 0x7f9ad52f2870, 0xc20
87fde00, 0xc2087d4410, 0xc208471b90, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/api/server/server.go:1169 +0x5d1
github.com/docker/docker/api/server.*Server.(github.com/docker/docker/api/server.postContainersAttach)·fm(0xc208b36007, 0x4, 0x7f9ad52f2870, 0xc2087fde00, 0xc2087d4410, 0xc208471b90, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/api/server/server.go:1671 +0x7b
github.com/docker/docker/api/server.func·008(0x7f9ad52f2870, 0xc2087fde00, 0xc2087d4410)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/api/server/server.go:1614 +0xc8f
net/http.HandlerFunc.ServeHTTP(0xc2081cc580, 0x7f9ad52f2870, 0xc2087fde00, 0xc2087d4410)
    /usr/lib/go/src/net/http/server.go:1265 +0x41
github.com/gorilla/mux.(*Router).ServeHTTP(0xc20813cd70, 0x7f9ad52f2870, 0xc2087fde00, 0xc2087d4410)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/gorilla/mux/mux.go:98 +0x297
net/http.serverHandler.ServeHTTP(0xc2082375c0, 0x7f9ad52f2870, 0xc2087fde00, 0xc2087d4410)
    /usr/lib/go/src/net/http/server.go:1703 +0x19a
net/http.(*conn).serve(0xc2087fdd60)
    /usr/lib/go/src/net/http/server.go:1204 +0xb57
created by net/http.(*Server).Serve
    /usr/lib/go/src/net/http/server.go:1751 +0x35e

goroutine 789 [semacquire, 33261 minutes]:
sync.(*WaitGroup).Wait(0xc20882de60)
    /usr/lib/go/src/sync/waitgroup.go:132 +0x169
github.com/docker/docker/daemon.func·017(0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/container.go:1035 +0x42
github.com/docker/docker/pkg/promise.func·001()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/promise/promise.go:8 +0x2f
created by github.com/docker/docker/pkg
/promise.Go
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/promise/promise.go:9 +0xfb

goroutine 788 [semacquire, 33261 minutes]:
sync.(*Cond).Wait(0xc2084607b0)
    /usr/lib/go/src/sync/cond.go:62 +0x9e
github.com/docker/docker/pkg/ioutils.(*bufReader).Read(0xc208460780, 0xc208a70000, 0x8000, 0x8000, 0x0, 0x7f9ad52d4080, 0xc20802a0d0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/ioutils/readers.go:210 +0x158
io.Copy(0x7f9ad003e398, 0xc208845860, 0x7f9ad003e420, 0xc208460780, 0x0, 0x0, 0x0)
    /usr/lib/go/src/io/io.go:362 +0x1f6
github.com/docker/docker/daemon.func·016(0xf8abc0, 0x6, 0x7f9ad003e398, 0xc208845860, 0x7f9ad003e3f0, 0xc208460780)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/container.go:1021 +0x245
created by github.com/docker/docker/daemon.attach
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/container.go:1032 +0x597

goroutine 769 [IO wait, 33261 minutes]:
net.(*pollDesc).Wait(0xc20881de20, 0x72, 0x0, 0x0)
    /usr/lib/go/src/net/fd_poll_runtime.go:84 +0x47
net.(*pollDesc).WaitRead(0xc20881de20, 0x0, 0x0)
    /usr/lib/go/src/net/fd_poll_runtime.go:89 +0x43
net.(*netFD).Read(0xc20881ddc0, 0xc2088ac000, 0x1000, 0x1000, 0x0, 0x7f9ad52d8340, 0xc20880d758)
    /usr/lib/go/src/net/fd_unix.go:242 +0x40f
net.(*conn).Read(0xc208b52360, 0xc2088ac000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
    /usr/lib/go/src/net/net.go:121 +0xdc
net/http.(*liveSwitchReader).Read(0xc208792c28, 0xc2088ac000, 0x1000, 0x1000, 0x2, 0x0, 0x0)
    /usr/lib/go/src/net/http/server.go:214 +0xab
io.(*LimitedReader).Read(0xc20889f960, 0xc2088ac000, 0x1000, 0x1000, 0x2, 0x0, 0x0)
    /usr/lib/go/src/io/io.go:408 +0xce
bufio.(*Reader).fill(0xc2082544e0)
    /usr/lib/go/src/bufio/bufio.go:97 +0x1ce
bufio.(*Reader).ReadSlice(0xc208254
4e0, 0xc20889db0a, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/lib/go/src/bufio/bufio.go:295 +0x257
bufio.(*Reader).ReadLine(0xc2082544e0, 0x0, 0x0, 0x0, 0xc208bc2700, 0x0, 0x0)
    /usr/lib/go/src/bufio/bufio.go:324 +0x62
net/textproto.(*Reader).readLineSlice(0xc208845560, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/lib/go/src/net/textproto/reader.go:55 +0x9e
net/textproto.(*Reader).ReadLine(0xc208845560, 0x0, 0x0, 0x0, 0x0)
    /u
=== END goroutine stack dump ==="

chr0n1x 에 2016년 01월 08일

나는 방금 걸렸고 , docker go 루틴이 되었습니다.

rwky 에 2016년 01월 11일

정지 후 로그에도 반복적으로 표시됩니다.
kernel: unregister_netdevice: waiting for veth2fb10a9 to become free. Usage count = 1

rwky 에 2016년 01월 11일

@rwky는 아마도 https://github.com/docker/docker/issues/5618 과 관련이

thaJeztah 에 2016년 01월 12일

@thaJeztah 아마도 # 5618은 컨테이너가 바인딩 된 인터페이스가 아닌 lo 및 eth0에만 적용되는 것 같습니다.

rwky 에 2016년 01월 12일

과도한 Kubernetes 작업로드가 예약 된 경우에도 동일한 문제가 발생했습니다. docker ps 는 반환되지 않습니다. 실제로 curl --unix-socket /var/run/docker.sock http:/containers/json 이 정지됩니다. 문제를 복구하려면 도커 데몬을 다시 시작해야합니다. 더 나쁜 것은 도커 데몬을 다시 시작하는 데 몇 분이 걸린다는 것입니다!

$ docker version
Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.3
 Git commit:   cedd534-dirty
 Built:        Thu Nov 19 23:12:57 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.3
 Git commit:   cedd534-dirty
 Built:        Thu Nov 19 23:12:57 UTC 2015
 OS/Arch:      linux/amd64

$ docker info
Containers: 57
Images: 100
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.2-coreos-r2
Operating System: CoreOS 870.2.0
CPUs: 32
Total Memory: 251.9 GiB
Name: CNPVG50853311
ID: TV5P:6OHQ:QTSN:IF6K:5LPX:TSHS:DEAW:TQSF:QTOT:45NO:JH2X:DMSE
Http Proxy: http://proxy.wdf.sap.corp:8080
Https Proxy: http://proxy.wdf.sap.corp:8080
No Proxy: hyper.cd,anywhere.cd

stainboy 에 2016년 01월 14일

내 환경에서 비슷한 것을보고 디버깅을 돕기 위해 아래 정보를 덤프했습니다. 통계는 각각 약 70 개의 컨테이너를 실행하는 두 개의 고사양 물리적 rancheros4.2 호스트에서 가져온 것입니다. 도커의 성능이 저하되고 트리거를 추적하지 못했지만 도커 데몬을 다시 시작하면 문제가 해결됩니다.

Docker 버전

Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   994543b
 Built:        Mon Nov 23 06:08:57 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   994543b
 Built:        Mon Nov 23 06:08:57 UTC 2015
 OS/Arch:      linux/amd64

도커 정보

Containers: 35
Images: 1958
Server Version: 1.9.1
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.3-rancher
Operating System: RancherOS (containerized)
CPUs: 64
Total Memory: 251.9 GiB
Name: PTL-BCA-07
ID: Q5WF:7MOB:37YR:NRZR:P2FE:DVWV:W7XY:Z6OL:TAVC:4KCM:IUFU:LO4C

Stacktrace :
debug2.txt

Rucknar 에 2016년 01월 17일

이것에 +1하여 centos 6에서 실행되는 더 높은 부하에서 더 자주 볼 수 있습니다.

Docker 버전

Client version: 1.7.1
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 786b29d
OS/Arch (client): linux/amd64
Server version: 1.7.1
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 786b29d
OS/Arch (server): linux/amd64

Docker 정보

Containers: 1
Images: 55
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.18.23-74.el6.x86_64
Operating System: <unknown>
CPUs: 40
Total Memory: 157.4 GiB
Name: lively-frost
ID: SXAC:IJ45:UY45:FIXS:7MWD:MZAE:XSE5:HV3Z:DU4Z:CYK6:LXPB:A65F

ssalinas 에 2016년 01월 23일

@ssalinas 이 문제가 해결 되더라도 더 이상 지원하지 않는 배포판 (centos 6)과 사용자 지정 커널 (CentOS 6은 2.6.x와 함께 제공)에서 실행

thaJeztah 에 2016년 01월 24일

@theJeztah , 분명히 무거운 부하에서 막힘을 일으키는 몇 가지 문제가 있습니다. Docker 팀의 누군가가이 문제를 확인했으며 버전 1.9에서 해결되었는지 확인해 주시겠습니까?

이 외에도 Docker가 중단되고 더 이상 인스턴스를 생성하지 않는지 확인할 수있는 방법이 있습니까? 그렇다면 최소한 데몬을 다시 시작하고 작업을 계속하도록 자동화 할 수 있습니다.

mcmohd20 에 2016년 02월 01일

다음 구성에서도 문제가 발생합니다.

docker 1.8.3 및 coreos 835.10

docker ps는 높은 이탈률에 멈 춥니 다. 가능한 한 빨리 200 개 이상의 컨테이너를 생성하여 100 % 트리거 할 수 있습니다 (Kubernetes가 수행함).

rfliam 에 2016년 02월 04일

여기도 마찬가지
재현 :

A_LOT=300 # whatever
for i in `seq 1 $A_LOT`; 
  do docker run --rm alpine sh -c "echo $i; sleep 30" & 
done
sleep 5   # give it some time to start spawning containers
docker ps # hangs

core@pph-01 ~ $ docker version
Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   cedd534-dirty
 Built:        Tue Feb  2 13:28:10 UTC 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   cedd534-dirty
 Built:        Tue Feb  2 13:28:10 UTC 2016
 OS/Arch:      linux/amd64

Containers: 291
Images: 14
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.2-coreos-r2
Operating System: CoreOS 835.12.0
CPUs: 2
Total Memory: 1.958 GiB
Name: pph-01
ID: P4FX:IMCD:KF5R:MG3Y:XECP:JPKO:IRWM:3MGK:IAIW:UG5S:6KCR:IK2J
Username: pmoust
Registry: https://index.docker.io/v1/

pmoust 에 2016년 02월 09일

기록을 위해 위의 bash 스크립트를 사용하여 랩톱에서 문제를 재현하려고 시도했지만 나쁜 일은 없었습니다. Ubuntu 15.10을 실행합니다.

$ docker version
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   a34a1d5
 Built:        Fri Nov 20 13:20:08 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   a34a1d5
 Built:        Fri Nov 20 13:20:08 UTC 2015
 OS/Arch:      linux/amd64

$ docker info
Containers: 1294
Images: 1231
Server Version: 1.9.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 3823
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.0-27-generic
Operating System: Ubuntu 15.10
CPUs: 8
Total Memory: 5.809 GiB
Name: pochama
ID: 6VMD:Z57I:QDFF:TBSU:FNSH:Y433:6KDS:2AXU:CVMH:JUKU:TVQQ:7UMR
Username: tomfotherby
Registry: https://index.docker.io/v1/
WARNING: No swap limit support

tomfotherby 에 2016년 02월 09일

Docker 1.8.3 / CentOS 7에서이 문제의 여러 사례를 보았습니다. 우리는 많은 수의 컨테이너를 생성 할 수있는 kubernetes를 사용하고 있습니다. 때때로 우리의 도커 데몬이 응답하지 않고 (docker ps가 30 분 이상 중단됨) 데몬을 다시 시작해야만 문제가 해결됩니다.

그러나 @pmoust 의 스크립트를 사용하여 문제를 재현 할 수 없습니다.

Containers: 117
Images: 105
Storage Driver: devicemapper
 Pool Name: docker-docker--pool
 Pool Blocksize: 524.3 kB
 Backing Filesystem: xfs
 Data file: 
 Metadata file: 
 Data Space Used: 5.559 GB
 Data Space Total: 21.45 GB
 Data Space Available: 15.89 GB
 Metadata Space Used: 7.234 MB
 Metadata Space Total: 54.53 MB
 Metadata Space Available: 47.29 MB
 Udev Sync Supported: true
 Deferred Removal Enabled: true
 Library Version: 1.02.107-RHEL7 (2015-10-14)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.0-327.4.5.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 2
Total Memory: 3.451 GiB
Name: server
ID: MK35:YN3L:KULL:C4YU:IOWO:6OK2:FHLO:WIYE:CBVE:MZBL:KG3T:OV5T
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:        Mon Oct 12 06:06:01 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 06:06:01 UTC 2015
 OS/Arch:      linux/amd64

andrewmichaelsmith 에 2016년 02월 10일

@tomfotherby 케이스와 @andrewmichaelsmith 에서 스토리지 드라이버는 각각 aufs / devicemapper-xfs입니다.
스토리지 드라이버가 오버레이 일 때 일관되게 재현 할 수 있습니다

pmoust 에 2016년 02월 10일

CoreOS 835.12 에서 @pmoust의 스크립트를 사용하여 중단을 복제 할 수 있습니다.

Containers: 227
Images: 1
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.2-coreos-r2
Operating System: CoreOS 835.12.0
CPUs: 2
Total Memory: 3.864 GiB
Name: core-01
ID: WIYE:CGI3:2C32:LURO:MNHU:YQXU:NEU4:LPZG:YJM5:ZN3S:BBPF:3SXM

rwky 에 2016년 02월 11일

FWIW 우리는 이것을 devicemapper 커널 버그에 고정했을 수 있다고 생각합니다 : https://bugzilla.redhat.com/show_bug.cgi?id=1292481

andrewmichaelsmith 에 2016년 02월 29일

@andrewmichaelsmith 는 패치가있는 AWS AMI입니까?

pmoust 에 2016년 02월 29일

CentOS 7 AWS 상자의 @pmoust yum update 에서 해당 버그 보고서 (kernel-3.10.0-327.10.1.el7)에서 새 커널을 가져 왔습니다.

편집 : 만약 당신이 overlayfs를 사용하고 있다면 이것이 당신과 관련이 없다고 생각합니까?

andrewmichaelsmith 에 2016년 02월 29일

이 문제에 +1. CoreOS Alpha의 커널 4.4.1-coreos에서 Docker 1.10.1에서이 문제에 직면했습니다.
AWS의 970.1.0. 이로 인해 kubernetes 클러스터에 심각한 불안정성이 발생하고 있으며 우리 팀은 도커를 완전히 제거하는 것을 고려하고 있습니다.

이 문제에 대한 적극적인 조사가 있습니까?

gopinatht 에 2016년 03월 02일

@gopinatht 이 문제의 사람들은 다양한 문제의 영향을받는 것 같습니다. 우리에게는 docker 프로젝트와 전혀 관련이없는 문제를 해결 한 devicemapper의 버그였습니다.

andrewmichaelsmith 에 2016년 03월 02일

@andrewmichaelsmith 응답 docker ps 호출의 strace는 다음을 제공합니다.

read(5, 0xc20807d000, 4096) = -1 EAGAIN (Resource temporarily unavailable) write(5, "GET /v1.22/containers/json HTTP/"..., 109) = 109 futex(0x1fe97a0, FUTEX_WAKE, 1) = 1 futex(0x1fe9720, FUTEX_WAKE, 1) = 1 epoll_wait(4, {}, 128, 0) = 0 futex(0x1fea698, FUTEX_WAIT, 0, NULL

이것은 여기에있는 여러 다른 보고서와 매우 유사합니다. 이 문제를 해결하기 위해 또 무엇을 할 수 있습니까?

gopinatht 에 2016년 03월 02일

@andrewmichaelsmith 가 패치 커널로 시도했습니다.

다음은 결과입니다 https://github.com/coreos/bugs/issues/1117#issuecomment -191190839

pmoust 에 2016년 03월 02일

@pmoust 업데이트

@andrewmichaelsmith @pmoust 추가 조사를 위해 다음에 할 수있는 일에 대한 통찰력이 있습니까? 이에 대한 수정은 우리 팀이 도커 기반 kubernetes 클러스터를 발전시키는 데 절대적으로 중요합니다.

gopinatht 에 2016년 03월 02일

@gopinatht 나는 도커 / 구글에서 일하지 않거나 도커 또는 쿠 버네 티스를 사용하는 데 특히 관심이 있습니다.

사용중인 스토리지 드라이버가 무엇인지 확실하지 않습니까? 반복 : devicemapper 스토리지 드라이버를 사용할 때 docker가 완전히 멈추는 문제를 발견했습니다. 커널을 kernel-3.10.0-327.10.1.el7로 업그레이드하면이 문제가 해결되었습니다. 더 이상 추가 할 수 없습니다.

docker 스토리지 드라이버로 devicemapper를 사용하지 않는 경우 내 결과는 아마도 당신에게 큰 의미가 없을 것입니다.

andrewmichaelsmith 에 2016년 03월 02일

@andrewmichaelsmith 내가 이것에 대해 뭔가를해야 함을 암시하는 것처럼

나는 분명히 여기서 길을 잃었 기 때문에 조사 방향을 찾고 있었다. 어쨌든 지금까지 도움을 주셔서 감사합니다.

gopinatht 에 2016년 03월 02일

Ubuntu에서 최신 버전의 Kernel 3.13.0-83-generic . 다른 모든 작업은 괜찮은 것 같습니다. 유일한 문제는 docker ps 및 임의의 docker inspect

Docker 정보 :

Containers: 51
 Running: 48
 Paused: 0
 Stopped: 3
Images: 92
Server Version: 1.10.3
Storage Driver: devicemapper
 Pool Name: docker-data-tpool
 Pool Blocksize: 65.54 kB
 Base Device Size: 5.369 GB
 Backing Filesystem: ext4
 Data file:
 Metadata file:
 Data Space Used: 19.14 GB
 Data Space Total: 102 GB
 Data Space Available: 82.86 GB
 Metadata Space Used: 33.28 MB
 Metadata Space Total: 5.369 GB
 Metadata Space Available: 5.335 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Library Version: 1.02.77 (2012-10-15)
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: host bridge null
Kernel Version: 3.13.0-83-generic
Operating System: Ubuntu 14.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 29.96 GiB
Name: apocalypse.servers.lair.io
ID: Q444:V3WX:RIQJ:5B3T:SYFQ:H2TR:SPVF:U6YE:XNDX:HV2Z:CS7F:DEJJ
WARNING: No swap limit support

strace 꼬리 :

futex(0x20844d0, FUTEX_WAIT, 0, NULL)   = 0
futex(0xc82002ea10, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_MONOTONIC, {216144, 494093555}) = 0
clock_gettime(CLOCK_MONOTONIC, {216144, 506740959}) = 0
futex(0xc82002ea10, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_MONOTONIC, {216144, 506835134}) = 0
clock_gettime(CLOCK_MONOTONIC, {216144, 506958105}) = 0
futex(0x20844d0, FUTEX_WAIT, 0

또한 몇 분 정도 지나면 차단 된 strace에 다음과 같은 출력이 표시되지만 종료되지는 않았습니다.

futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0x20844d0, FUTEX_WAIT, 0, NULL

조금 더 기다린 후 동일한 futex 블록이 발생하지만 이번에는 '리소스를 일시적으로 사용할 수 없음 오류'도 발생합니다.

futex(0x20844d0, FUTEX_WAIT, 0, NULL)   = 0
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_MONOTONIC, {216624, 607690506}) = 0
clock_gettime(CLOCK_MONOTONIC, {216624, 607853434}) = 0
futex(0x2083970, FUTEX_WAIT, 0, {0, 100000}) = -1 EAGAIN (Resource temporarily unavailable)
epoll_wait(5, {}, 128, 0)               = 0
clock_gettime(CLOCK_MONOTONIC, {216624, 608219882}) = 0
futex(0x2083980, FUTEX_WAKE, 1)         = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_MONOTONIC, {216624, 608587202}) = 0
clock_gettime(CLOCK_MONOTONIC, {216624, 609140069}) = 0
clock_gettime(CLOCK_MONOTONIC, {216624, 609185048}) = 0
clock_gettime(CLOCK_MONOTONIC, {216624, 609272020}) = 0
futex(0xc82002ea10, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_MONOTONIC, {216624, 616982914}) = 0
sched_yield()                           = 0
clock_gettime(CLOCK_MONOTONIC, {216624, 626726774}) = 0
futex(0x20844d0, FUTEX_WAIT, 0, NULL)   = 0
futex(0x2083970, FUTEX_WAKE, 1)         = 1
futex(0x20838c0, FUTEX_WAKE, 1)         = 1
sched_yield()                           = 0
futex(0x20838c0, FUTEX_WAIT, 2, NULL)   = 0
futex(0x20838c0, FUTEX_WAKE, 1)         = 0
futex(0x20844d0, FUTEX_WAIT, 0, NULL

항상 동일한 futex 에서 strace가 차단됩니다.

akalipetis 에 2016년 03월 30일

@akalipetis 프로세스에 SIGUSR1 를 보내고 데몬 로그에서 전체 스택 추적을 가져올 수 있습니까?

cpuguy83 에 2016년 03월 30일

@ cpuguy83- 미안하지만 나는 그것을 인식하지 못했습니다 ...

akalipetis 에 2016년 03월 31일

(Un) 불행히도 다시 발생했습니다. 아래 첨부 파일에서 전체 스택 추적을 찾을 수 있습니다.

stacktrace.txt

내 편이 더 필요하면 알려주세요.

/ cc @ cpuguy83

akalipetis 에 2016년 04월 07일

@akalipetis 대단히 감사합니다!

cpuguy83 에 2016년 04월 12일

문제 없습니다 @ cpuguy83- 다른 데이터를 원하거나 향후

불행히도 나는 이것을 재현하는 방법을 찾지 못했거나 중단 사이의 유사한 상황을 식별하지 못했습니다.

akalipetis 에 2016년 04월 12일

rspec 도커 이미지 테스트를 실행하는 1.11.0으로 업데이트했기 때문에 (4 cpu 시스템에서 이러한 테스트를 실행하는 최대 10 개의 병렬 컨테이너) 가끔 멈추고 시간 초과로 실패합니다. Docker가 완전히 정지되고 응답하지 않습니다 (예 : docker ps ). 이것은 Debian strech (btrfs) 및 (vagrant) Parallels VM Ubuntu 14.04 (백 포트 된 커널 3.19.0-31-generic, ext4)를 사용하는 가상 서버에서 발생합니다.

두 서버의 /var/lib/docker 에 대한 파일 시스템이 첫 번째 고정 후 지워졌습니다 (btrfs가 다시 생성됨). 이러한 테스트를 실행할 때 멈춤이 무작위로 발생합니다.

스택 추적은 두 서버에서 연결됩니다.
docker-log.zip

docker-containerd 및 docker daemons strace :

# strace -p 21979 -p 22536
Process 21979 attached
Process 22536 attached
[pid 22536] futex(0x219bd90, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 21979] futex(0xf9b170, FUTEX_WAIT, 0, NULL

Docker 정보 (Debian strech)

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1096
Server Version: 1.11.0
Storage Driver: btrfs
 Build Version: Btrfs v4.4
 Library Version: 101
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge null
Kernel Version: 4.4.0-1-amd64
Operating System: Debian GNU/Linux stretch/sid
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 11.74 GiB
Name: slave.webdevops.io
ID: WU2P:YOYC:VP2F:N6DE:BINB:B6YO:2HJO:JKZA:HTP3:SIDA:QOJZ:PJ2E
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Username: webdevopsslave
Registry: https://index.docker.io/v1/
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support

Docker 정보 (백 포트 된 커널이있는 Ubuntu 14.04)

Client:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:34:23 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:34:23 2016
 OS/Arch:      linux/amd64
root@DEV-VM:/var/lib/docker# docker info
Containers: 11
 Running: 1
 Paused: 0
 Stopped: 10
Images: 877
Server Version: 1.11.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 400
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 3.19.0-31-generic
Operating System: Ubuntu 14.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 3.282 GiB
Name: DEV-VM
ID: KCQP:OGCT:3MLX:TAQD:2XG6:HBG2:DPOM:GJXY:NDMK:BXCK:QEIT:D6KM
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/

Docker 버전 (Debian strech)

Client:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:22:26 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:22:26 2016
 OS/Arch:      linux/amd64

Docker 버전 (백 포트 된 커널이있는 Ubuntu 14.04)

Client:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:34:23 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:34:23 2016
 OS/Arch:      linux/amd64

mblaschke 에 2016년 04월 15일

@mblaschke golang 프로그램 afaik의 strace에 -f 을 사용하고 싶습니다.

zeisss 에 2016년 04월 15일

Ubuntu 14.04에서이 버그를 확인할 수 있지만이 버그가 4.4 커널을 사용하는 Debian stretch의 문제인지 확실하지 않습니다. 여전히 더 많은 정보를 얻으려고합니다.

mblaschke 에 2016년 04월 16일

Docker 1.10.3에서 Debian stretch의 문제는 systemd의 프로세스 제한 (이전 512, 8192로 올림)이었으며 Docker 컨테이너 테스트는 이제 문제없이 실행됩니다. 1.11.0은 여전히 작동하지 않고 rspec 테스트는 여전히 멈춰 있지만 docker ps 은 4.4 커널을 사용하는 Debian Stretch에서 여전히 응답하므로 다른 문제라고 생각합니다.

mblaschke 에 2016년 04월 17일

새로운 문제 일 수있는 @mblaschke 의 보고서를 추적하기 위해 새로운 문제 # 22124를 생성했습니다.

tonistiigi 에 2016년 04월 18일

또한 이것에 실행 나는 믿는다

$ uname -a
Linux ip-10-15-42-103.ec2.internal 4.4.6-coreos #2 SMP Sat Mar 26 03:25:31 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz GenuineIntel GNU/Linux

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

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

$ docker info
Containers: 198
Images: 196
Server Version: 1.9.1
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: journald
Kernel Version: 4.4.6-coreos
Operating System: CoreOS 991.2.0 (Coeur Rouge)
CPUs: 2
Total Memory: 3.862 GiB

$ sudo strace -q -y -v -f docker ps
<snip>
[pid 26889] connect(5<socket:[18806726]>, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, 23) = 0
[pid 26889] clock_gettime(CLOCK_REALTIME, {1462217998, 860739240}) = 0
[pid 26889] epoll_ctl(4<anon_inode:[eventpoll]>, EPOLL_CTL_ADD, 5<socket:[18806726]>, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=914977888, u64=140334676407392}}) = 0
[pid 26889] getsockname(5<socket:[18806726]>, {sa_family=AF_LOCAL, NULL}, [2]) = 0
[pid 26889] getpeername(5<socket:[18806726]>, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, [23]) = 0
[pid 26889] read(5<socket:[18806726]>,  <unfinished ...>
[pid 26893] <... futex resumed> )       = 1
[pid 26889] <... read resumed> 0xc820015000, 4096) = -1 EAGAIN (Resource temporarily unavailable)
[pid 26893] futex(0xc8200e9790, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 26891] futex(0xc820026a10, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily unavailable)
[pid 26891] epoll_wait(4<anon_inode:[eventpoll]>, {{EPOLLOUT, {u32=914978080, u64=140334676407584}}, {EPOLLOUT, {u32=914977888, u64=140334676407392}}}, 128, 0) = 2
[pid 26891] epoll_wait(4<anon_inode:[eventpoll]>,  <unfinished ...>
[pid 26889] write(5<socket:[18806726]>, "GET /v1.21/containers/json HTTP/"..., 88 <unfinished ...>
[pid 26890] <... select resumed> )      = 0 (Timeout)
[pid 26889] <... write resumed> )       = 88
[pid 26891] <... epoll_wait resumed> {{EPOLLOUT, {u32=914977888, u64=140334676407392}}}, 128, -1) = 1
[pid 26891] epoll_wait(4<anon_inode:[eventpoll]>,  <unfinished ...>
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 935071149}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 861179188}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 935216184}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 861327424}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 935376601}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 861479813}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 935543531}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 861646718}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 935709999}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 861817062}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 935872149}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 861975102}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 936046201}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 862149543}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 936215534}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 862318597}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 936384887}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 862488231}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 936547503}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 862650775}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 936708047}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 862810981}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 936875834}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 862978790}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 937049520}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 863161620}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 937216897}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 863319694}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 937382999}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 863485851}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 937549477}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 863652283}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 937722463}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 863833602}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 937888537}) = 0
[pid 26889] futex(0xc8200e9790, FUTEX_WAKE, 1 <unfinished ...>
[pid 26890] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid 26889] <... futex resumed> )       = 1
[pid 26893] <... futex resumed> )       = 0
[pid 26890] <... clock_gettime resumed> {1462217998, 864010029}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid 26889] futex(0x1df2f50, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 26893] futex(0xc8200e9790, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 26890] <... select resumed> )      = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 938059687}) = 0
[pid 26890] futex(0x1df2400, FUTEX_WAIT, 0, {60, 0}

mwhooker 에 2016년 05월 02일

@mwhooker 불행히도 도커 클라이언트의 strace는 데몬에서 무슨 일이 일어나고 있는지 볼 필요가 있기 때문에 실제로별로 도움이되지 않습니다.

멈춘 데몬에서 SIGUSR1을 사용하여 로그에 스택 추적을 뱉어 내십시오.

cpuguy83 에 2016년 05월 02일

여기 내 sigusr1 출력 https://gist.github.com/mwhooker/6858c0d0c123e214ef69d0a4bff2d7cc (cc @ cpuguy83)

mwhooker 에 2016년 05월 02일

여기에 고정 된 도커 데몬의 또 다른 sigusr1 덤프가 있습니다.

https://gist.github.com/mwhooker/e837f08370145d183e661c03a5b9d07e

strace 다시 FUTEX_WAIT 에서 데몬을 찾습니다.

이번에는 실제로 호스트에 연결할 수 있으므로 추가 디버깅을 수행 할 수 있지만 곧 데몬을 죽일 것입니다.

mwhooker 에 2016년 05월 10일

핑 @ cpuguy83 ^^

thaJeztah 에 2016년 05월 10일

1.11.1 (4.2.5-300.fc23), Overlay / EXT4에서 동일한 문제가 있습니다. Celery 작업자를 실행하고 작업을로드 한 다음 stop 시도 할 때 발생합니다.

그런 다음 그 안에있는 어떤 것도 실행할 수 없습니다.
rpc error: code = 2 desc = "oci runtime error: exec failed: exit status 1"

그래서 컨테이너 중 일부가 파괴 된 것 같지만 작업을 완료 할 수 없습니다. 나는 셀러리가 용기 안에서 죽었다는 것을 확인했다. 그래서 무엇이 그것을 담고 있는지 확실하지 않다.

편집하다:
셀러리는 완전히 죽지 않았고 D에 프로세스가 멈춰있어서 재부팅이 유일한 옵션이라고 생각합니다.

joedborg 에 2016년 05월 16일

https://github.com/docker/docker/issues/20401#issuecomment -231337800을 참조

anosulchik 에 2016년 07월 08일

높은로드 (높은 비율로 생성 / 삭제하는 컨테이너)에서 동일한 문제가 발생했습니다.

CoreOS 1068.8.0
Docker 1.10.3
uname -a :

Linux coreos_k8s_28 4.6.3-coreos #2 SMP Mon Jul 18 06:10:39 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz GenuineIntel GNU/Linux

kubernetes 1.2.0

다음은 도커 디버그 로그의 요점입니다 (SIGUSR1을 도커 데몬으로 보냄) : https://gist.github.com/ntquyen/409376bc0d8418a31023c1546241e190

ntquyen 에 2016년 07월 20일

@ntquyen으로 . 동일한 os / kernel / docker 버전.

Repro는 여전히 서 있습니다 https://github.com/docker/docker/issues/13885#issuecomment -181811082

pmoust 에 2016년 07월 20일

제 경우에는 머신이 90 % 이상의 디스크 공간을 사용하여 실행 되었기 때문일 수 있습니다. 나는 그들에게 더 많은 디스크 공간을 할당했고 그들은 높은 부하 상태에서도 지금 꽤 안정적으로 실행되고 있습니다.

ntquyen 에 2016년 07월 20일

@mwhooker 인터페이스를 삭제하기 위해 데몬이 netlink 호출에 중단 된 것 같습니다.
어떤 데몬 옵션을 설정 했습니까?

내가 "중단"이라고 말하면 실제로 전체 데몬이 동결되는 것은 아니지만 해당 컨테이너 객체에 액세스해야하는 API 호출도 넷 링크 호출에 멈춰있는 컨테이너 뮤텍스를 기다리기 때문에 중단됩니다.

이러한 유형의 문제를 완화하기 위해 할 수있는 다양한 방법을 살펴 봅니다.

cpuguy83 에 2016년 07월 20일

@pmoust 데몬에서 스택 추적을 제공 할 수 있습니까? (고착 된 데몬에 SIGUSR1 보내기 및 데몬 로그에서 추적 수집)
또한 데몬을 시작한 옵션도 있습니다.

감사!

cpuguy83 에 2016년 07월 20일

@ntquyen 나는 당신이 맞은 문제가 1.11.2에서 수정 된 # 22732와 관련이 있다고 생각합니다.
문제를 한 번만 언급 했습니까?

cpuguy83 에 2016년 07월 20일

@ cpuguy83 나에게 돌아와 주셔서 감사합니다. 데몬을 실행하는 방법은 다음과 같습니다.

/usr/bin/docker daemon --icc=false --storage-driver=overlay --log-driver=journald --host=fd://

관련이 있는지 확실하지 않지만 로그에서 이러한 메시지를 많이 발견했습니다.

Jul 19 10:22:55 ip-10-0-37-191.ec2.internal systemd-networkd[852]: veth0adae8a: Removing non-existent address: fe80::e855:98ff:fe3f:8b2c/64 (valid forever)

(편집 : 이것들도)

[19409.536106] unregister_netdevice: waiting for veth2304bd1 to become free. Usage count = 1

mwhooker 에 2016년 07월 20일

@mwhooker 하단 메시지는 아마도 여기에 docker가 붙어 있지만 --userland-proxy=false 사용하지 않고 이것을 얻는 것에 놀랐습니다.

cpuguy83 에 2016년 07월 21일

@ cpuguy83 흥미로운 점은 --proxy-mode=userspace hyperkube를 실행하고 있다는 것입니다. 그 원인이 가능한가요?

mwhooker 에 2016년 07월 22일

@mwhooker 는 플래그 설명을 기반으로 한 것 같습니다.
기본적으로 --userland-proxy=false 은 컨테이너의 브리지 인터페이스에서 헤어핀 모드를 활성화합니다. 이는 커널에서 많은 컨테이너를 추가 / 제거 할 때 (또는 병렬로 여러 작업을 수행 할 때) 꽤 나쁜 동결을 유발하는 일부 조건을 트리거하는 것처럼 보입니다. (및 표시되는 오류 메시지).

브리지 인터페이스가 헤어핀 모드인지 확인할 수 있습니다.

cpuguy83 에 2016년 07월 22일

🎉1

@ cpuguy83 이것은이 문제가 발생하는 별도의 서버 집합의 docker 명령입니다.

docker daemon --host=fd:// --icc=false --storage-driver=overlay --log-driver=journald --exec-opt native.cgroupdriver=systemd --bip=10.2.122.1/24 --mtu=8951 --ip-masq=true --selinux-enable

이 veth 인터페이스가 헤어핀 모드에 있음을 알 수 있습니다.

cat /sys/devices/virtual/net/docker0/brif/veth*/hairpin_mode
1
1

이것이 우리가보고있는 도커 중단 문제 중 하나 이상의 원인인지 궁금합니다.

(fwiw 우리는 flannel https://github.com/kubernetes/kubernetes/issues/20391과의 상호 작용 때문에 kube-proxy에서 사용자 공간 프록시를 사용하고 있습니다)

mwhooker 에 2016년 07월 23일

@ cpuguy83 불행히도 최신 안정된 coreos에서 docker 1.10을 사용하고 있으며 docker 1.12로 업그레이드 할 수 없습니다. 디스크 공간을 늘린 후에도 문제가 완전히 해결되지 않았습니다.

ntquyen 에 2016년 07월 25일

여기도 마찬가지입니다.

Docker : 1.12
커널 : 4.4.3
배포판 : 우분투

악마:

    # strace -q -y -v -p `pidof dockerd`
    futex(0x2a69be8, FUTEX_WAIT, 0, NULL
    futex(0xc820e1b508, FUTEX_WAKE, 1)      = 1
    futex(0x2a69be8, FUTEX_WAIT, 0, NULL)   = 0
    futex(0xc8224b0508, FUTEX_WAKE, 1)      = 1
    futex(0x2a69be8, FUTEX_WAIT, 0, NULL)   = 0
    futex(0x2a69be8, FUTEX_WAIT, 0, NULL

고객:

    # strace docker ps
    execve("/usr/bin/docker", ["docker", "ps"], [/* 24 vars */]) = 0
    brk(0)                                  = 0x2584000
    ...
    stat("/root/.docker/config.json", {st_mode=S_IFREG|0600, st_size=91, ...}) = 0
    openat(AT_FDCWD, "/root/.docker/config.json", O_RDONLY|O_CLOEXEC) = 3
    read(3, "{\n\t\"auths\": {\n\t\t\"https://quay.io"..., 512) = 91
    close(3)                                = 0
    ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
    ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
    futex(0xc820068108, FUTEX_WAKE, 1)      = 1
    futex(0xc820068108, FUTEX_WAKE, 1)      = 1
    socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
    setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
    connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, 23) = 0
    epoll_create1(EPOLL_CLOEXEC)            = 4
    epoll_ctl(4, EPOLL_CTL_ADD, 3, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=3136698616, u64=140182279305464}}) = 0
    getsockname(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0
    getpeername(3, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, [23]) = 0
    futex(0xc820032d08, FUTEX_WAKE, 1)      = 1
    read(3, 0xc820356000, 4096)             = -1 EAGAIN (Resource temporarily unavailable)
    write(3, "GET /v1.24/containers/json HTTP/"..., 95) = 95
    futex(0x132aca8, FUTEX_WAIT, 0, NULL

Bregor 에 2016년 09월 18일

rspec 테스트를 실행할 때 Debian에서 여전히 발생합니다.

커널 : 4.4.0-28- 일반
Docker : 1.12.2-0 ~ xenial

현재 해결 방법은 마지막 안정 버전 인 Docker 1.10.3-0 ~ wily로 돌아가는 것입니다.

mblaschke 에 2016년 10월 13일

@mblaschke @Bregor stacktrace를 게시 할 수 있습니까?

tonistiigi 에 2016년 10월 13일

이것은 우리 환경에서 한동안 일어나고 있습니다 : [

$ docker info
Containers: 20
 Running: 6
 Paused: 0
 Stopped: 14
Images: 57
Server Version: 1.11.1
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge null host
Kernel Version: 3.18.27
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: x86_64
CPUs: 24
Total Memory: 125.8 GiB
Name: appdocker414-sjc1
ID: ZTWC:53NH:VKUZ:5FZK:SLZN:YPI4:ICK2:W7NF:UIGD:P2NQ:RHUD:PS6Y
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

커널 : 3.18.27

Stackstrace : https://gist.github.com/dmyerscough/6948218a228ff69dd6e309f8de0f0261

dmyerscough 에 2016년 10월 14일

@dmyerscough 이것은 https://github.com/docker/docker/issues/22732 인 것 같습니다. 1.11.2 및 1.12에서 수정 됨

tonistiigi 에 2016년 10월 14일

매분 docker run --rm 로 간단한 컨테이너를 실행하고 Docker 서비스는 때때로 다시 시작될 때까지 교착 상태가됩니다.

docker -D info
Containers: 6
 Running: 2
 Paused: 0
 Stopped: 4
Images: 6
Server Version: 1.11.2
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge null
Kernel Version: 4.7.3-coreos-r2
Operating System: CoreOS 1185.3.0 (MoreOS)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 7.8 GiB
Name: <hostname>
ID: GFHQ:Y6IV:XCQI:Y2NA:PCQN:DEII:OSPZ:LENL:OCFU:6CBI:MDFV:EMD7
Docker Root Dir: /var/lib/docker
Debug mode (client): true
Debug mode (server): false
Username: <username>
Registry: https://index.docker.io/v1/

중단되기 전 마지막 메시지 :

Nov 04 16:42:01 dockerd[1447]: time="2016-11-04T16:42:01Z" level=error msg="containerd: deleting container" error="wait: no child processes"

liquid-sky 에 2016년 11월 08일

@ liquid-sky 더 많은 정보가 있습니까? 데몬 로그에 유용한 정보 또는 스택 추적이 표시됩니까? 또한 CoreOS 용 공식 패키지가 없습니다. 수정 된 패키지 / 구성을 배포하는 경우보고 할 가치가 있습니다.

thaJeztah 에 2016년 11월 08일

@thaJeztah 불행히도 저널 로그는 프로세스가 마지막으로 기록 된 이후로 회전했습니다.

$ ps -ef | grep -w 148[9] | head -1
root      1489     1  0 Nov02 ?        00:20:35 docker daemon --host=fd:// --insecure-registry=<registry_address> --selinux-enabled

sudo strace -e verbose=all -v -p 1489
Process 1489 attached
futex(0x22509c8, FUTEX_WAIT, 0, NULL

$ sudo strace docker ps
.....
clock_gettime(CLOCK_REALTIME, {1478601605, 8732879}) = 0
clock_gettime(CLOCK_REALTIME, {1478601605, 9085011}) = 0
clock_gettime(CLOCK_REALTIME, {1478601605, 9242006}) = 0
socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
connect(3, {sa_family=AF_LOCAL, sun_path="/run/systemd/journal/socket"}, 30) = 0
epoll_create1(EPOLL_CLOEXEC)            = 4
epoll_ctl(4, EPOLL_CTL_ADD, 3, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=3317119944, u64=140066495609800}}) = 0
getsockname(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0
getpeername(3, {sa_family=AF_LOCAL, sun_path="/run/systemd/journal/socket"}, [30]) = 0
stat("/root/.docker/config.json", 0xc8203b6fa8) = -1 ENOENT (No such file or directory)
stat("/root/.dockercfg", 0xc8203b7078)  = -1 ENOENT (No such file or directory)
stat("/bin/docker-credential-secretservice", 0xc8203b7148) = -1 ENOENT (No such file or directory)
stat("/sbin/docker-credential-secretservice", 0xc8203b7218) = -1 ENOENT (No such file or directory)
stat("/usr/bin/docker-credential-secretservice", 0xc8203b72e8) = -1 ENOENT (No such file or directory)
stat("/usr/sbin/docker-credential-secretservice", 0xc8203b73b8) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/docker-credential-secretservice", 0xc8203b7488) = -1 ENOENT (No such file or directory)
stat("/usr/local/sbin/docker-credential-secretservice", 0xc8203b7558) = -1 ENOENT (No such file or directory)
stat("/opt/bin/docker-credential-secretservice", 0xc8203b7628) = -1 ENOENT (No such file or directory)
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
futex(0xc8202c9108, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_REALTIME, {1478601605, 11810493}) = 0
clock_gettime(CLOCK_REALTIME, {1478601605, 11888495}) = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 5
setsockopt(5, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
connect(5, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, 23) = 0
clock_gettime(CLOCK_REALTIME, {1478601605, 12378242}) = 0
epoll_ctl(4, EPOLL_CTL_ADD, 5, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=3317119752, u64=140066495609608}}) = 0
getsockname(5, {sa_family=AF_LOCAL, NULL}, [2]) = 0
getpeername(5, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, [23]) = 0
futex(0xc820026d08, FUTEX_WAKE, 1)      = 1
read(5, 0xc8203d6000, 4096)             = -1 EAGAIN (Resource temporarily unavailable)
write(5, "GET /v1.23/containers/json HTTP/"..., 89) = 89
futex(0xc820026d08, FUTEX_WAKE, 1)      = 1
futex(0x22509c8, FUTEX_WAIT, 0, NULL

liquid-sky 에 2016년 11월 08일

모든 containerd 서비스도 마찬가지입니다.

ps -ef | grep container[d]
root      1513  1489  0 Nov02 ?        00:00:53 containerd -l /var/run/docker/libcontainerd/docker-containerd.sock --runtime runc --start-timeout 2m
root      2774  1513  0 Nov02 ?        00:00:00 containerd-shim a90d4642fd88ab38c66a733e2cef8f427533e736d14d48743d42f55dec62447f /var/run/docker/libcontainerd/a90d4642fd88ab38c66a733e2cef8f427533e736d14d48743d42f55dec62447f runc
root      3946  1513  0 Nov02 ?        00:00:00 containerd-shim c8903c4a137fbb297efc3fcf2c69d746e94431f22c7fdf1a46ff7c69d04ffb0d /var/run/docker/libcontainerd/c8903c4a137fbb297efc3fcf2c69d746e94431f22c7fdf1a46ff7c69d04ffb0d runc
root      4783  1513  0 Nov02 ?        00:03:36 containerd-shim d8c2203adfc26f7d11a62d9d90ddf97f04c458f72855ee1987ed1af911a2ab55 /var/run/docker/libcontainerd/d8c2203adfc26f7d11a62d9d90ddf97f04c458f72855ee1987ed1af911a2ab55 runc
root     16684  1513  0 Nov02 ?        00:00:00 containerd-shim 4d62424ca8cceb29c877bf129cd46341a53e191c9858b93aca3d5cbcfaaa1876 /var/run/docker/libcontainerd/4d62424ca8cceb29c877bf129cd46341a53e191c9858b93aca3d5cbcfaaa1876 runc
root     16732  1513  0 Nov02 ?        00:03:24 containerd-shim 2f8e2a858306322c10aa7823c92f22133f1c5e5f267ce61e542c1d8bd537b121 /var/run/docker/libcontainerd/2f8e2a858306322c10aa7823c92f22133f1c5e5f267ce61e542c1d8bd537b121 runc
root     20902  1513  0 Nov02 ?        00:00:05 containerd-shim 58572e7fab122d593bdb096b0dd33551c22ce50a0c51d6662bc0c7b3d3bf9248 /var/run/docker/libcontainerd/58572e7fab122d593bdb096b0dd33551c22ce50a0c51d6662bc0c7b3d3bf9248 runc

$ sudo strace -T -e verbose=all -v -p 1513
Process 1513 attached
futex(0x1028dc8, FUTEX_WAIT, 0, NULL

liquid-sky 에 2016년 11월 08일

@ liquid-sky strace 일반 dockerd의 futex(0x22509c8, FUTEX_WAIT, 0, NULL 도 표시됩니다. 이것은 의미있는 내용이 없음을 보여줍니다. 모든 스레드를 추적하려면 -f 를 추가하는 것이 좋습니다. .

depay 에 2016년 11월 08일

나는 이것이이 문제 와 관련이 있다고 생각합니다. 우리가 --rm 매분 컨테이너를 실행하고 Docker가 해당 특정 컨테이너에 멈춘다는 의미에서 docker ps 가 매달린 일부 노드에는 unregistered loopback device 메시지.

경우에 따라 Docker 데몬의 strace -f 스 니펫 :

[pid  1507] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid  1766] write(23, "\2\0\0\0\0\0\0\321I1108 10:48:12.429657   "..., 217) = 217
[pid  1507] <... select resumed> )      = 0 (Timeout)
[pid  1766] futex(0xc822075d08, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid  1507] clock_gettime(CLOCK_MONOTONIC, {514752, 140621361}) = 0
[pid  1875] <... epoll_wait resumed> {{EPOLLIN|EPOLLOUT|EPOLLRDHUP, {u32=1298424080, u64=140528333381904}}}, 128, -1) = 1
[pid  1507] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1875] epoll_wait(6,  <unfinished ...>
[pid  1507] <... clock_gettime resumed> {1478602092, 431376727}) = 0
[pid  1507] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid  1514] <... read resumed> "I1108 10:48:12.431656    12 mast"..., 32768) = 1674
[pid  1507] <... select resumed> )      = 0 (Timeout)
[pid  1514] futex(0xc822075d08, FUTEX_WAKE, 1 <unfinished ...>
[pid  1507] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid  1766] <... futex resumed> )       = 0
[pid  1514] <... futex resumed> )       = 1
[pid  1766] select(0, NULL, NULL, NULL, {0, 100} <unfinished ...>
[pid  1514] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1507] <... clock_gettime resumed> {514752, 142476308}) = 0
[pid  1514] <... clock_gettime resumed> {1478602092, 432632124}) = 0
[pid  1507] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.431656   "..., 349 <unfinished ...>
[pid  1507] <... clock_gettime resumed> {1478602092, 432677401}) = 0
[pid  1514] <... write resumed> )       = 349
[pid  1507] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid  1514] clock_gettime(CLOCK_REALTIME, {1478602092, 432812895}) = 0
[pid  1766] <... select resumed> )      = 0 (Timeout)
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.431763   "..., 349 <unfinished ...>
[pid  1507] <... select resumed> )      = 0 (Timeout)
[pid  1514] <... write resumed> )       = 349
[pid  1507] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid  1514] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1507] <... clock_gettime resumed> {514752, 142831922}) = 0
[pid  1514] <... clock_gettime resumed> {1478602092, 432948135}) = 0
[pid  1507] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.431874   "..., 349 <unfinished ...>
[pid  1507] <... clock_gettime resumed> {1478602092, 432989394}) = 0
[pid  1514] <... write resumed> )       = 349
[pid  1507] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid  1766] read(44, "I1108 10:48:12.432255    12 mast"..., 32768) = 837
[pid  1514] clock_gettime(CLOCK_REALTIME, {1478602092, 433114452}) = 0
[pid  1766] read(44,  <unfinished ...>
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.431958   "..., 349) = 349
[pid  1507] <... select resumed> )      = 0 (Timeout)
[pid  1514] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1507] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid  1514] <... clock_gettime resumed> {1478602092, 433272783}) = 0
[pid  1507] <... clock_gettime resumed> {514752, 143176397}) = 0
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.432035   "..., 349 <unfinished ...>
[pid  1507] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1514] <... write resumed> )       = 349
[pid  1507] <... clock_gettime resumed> {1478602092, 433350170}) = 0
[pid  1514] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1507] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid  1514] <... clock_gettime resumed> {1478602092, 433416138}) = 0
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.432126   "..., 349) = 349
[pid  1514] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1507] <... select resumed> )      = 0 (Timeout)
[pid  1514] <... clock_gettime resumed> {1478602092, 433605782}) = 0
[pid  1507] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.432255   "..., 349 <unfinished ...>
[pid  1507] <... clock_gettime resumed> {514752, 143537029}) = 0
[pid  1514] <... write resumed> )       = 349
[pid  1507] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1514] clock_gettime(CLOCK_REALTIME, {1478602092, 433748730}) = 0
[pid  1507] <... clock_gettime resumed> {1478602092, 433752245}) = 0
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.432343   "..., 348 <unfinished ...>
[pid  1507] futex(0xc8211b2d08, FUTEX_WAKE, 1 <unfinished ...>
[pid  1514] <... write resumed> )       = 348
[pid  1507] <... futex resumed> )       = 1
[pid 10488] <... futex resumed> )       = 0
[pid 10488] write(23, "\2\0\0\0\0\0\t\317I1108 10:48:12.431656   "..., 2519 <unfinished ...>
[pid  1514] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1507] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid 10488] <... write resumed> )       = 2519
[pid 10488] futex(0xc8211b2d08, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid  1875] <... epoll_wait resumed> {{EPOLLIN|EPOLLOUT|EPOLLRDHUP, {u32=1298424080, u64=140528333381904}}}, 128, -1) = 1
[pid  1514] <... clock_gettime resumed> {1478602092, 434094221}) = 0
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.432445   "..., 349) = 349
[pid  1514] futex(0xc820209908, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid  1507] <... select resumed> )      = 0 (Timeout)
[pid  1507] clock_gettime(CLOCK_MONOTONIC, {514752, 144370753}) = 0
[pid  1507] futex(0x224fe10, FUTEX_WAIT, 0, {60, 0} <unfinished ...>
[pid  1875] epoll_wait(6,  <unfinished ...>
[pid  1683] <... futex resumed> )       = -1 ETIMEDOUT (Connection timed out)
[pid  1683] clock_gettime(CLOCK_MONOTONIC, {514752, 292709791}) = 0
[pid  1683] futex(0x224fe10, FUTEX_WAKE, 1) = 1
[pid  1507] <... futex resumed> )       = 0

liquid-sky 에 2016년 11월 08일

centos 7에서 루프백과 함께 devicemapper를 사용하고 있습니다.

무슨 일이 있었는지 확실하지 않지만 dmsetup udevcookies & dmsetup udevcomplete <cookie> 가 저에게 효과적입니다.

@thaJeztah 당신은 무슨 일이 일어 났는지 설명 할 수 있습니까?

depay 에 2016년 11월 09일

나는 여기에서 이전에 여러 번 언급 된 것을 반복하고있다. 중단이 발생하면 SIGUSR1 신호를 데몬 프로세스로 보내고 로그에 기록 된 추적을 복사하십시오. Strace 출력은 정지 디버깅에 유용하지 않으며 클라이언트 프로세스에서 발생할 가능성이 높으며 일반적으로 프로세스가 멈췄거나 잠자기 상태인지 표시하지 않습니다.

tonistiigi 에 2016년 11월 09일

👍1

@tonistiigi 가 Hang-under-load로

$ docker info
Containers: 18
 Running: 15
 Paused: 0
 Stopped: 3
Images: 232
Server Version: 1.12.3
Storage Driver: devicemapper
 Pool Name: vg_ex-docker--pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 107.4 GB
 Backing Filesystem: xfs
 Data file: 
 Metadata file: 
 Data Space Used: 132.8 GB
 Data Space Total: 805.3 GB
 Data Space Available: 672.5 GB
 Metadata Space Used: 98.46 MB
 Metadata Space Total: 4.001 GB
 Metadata Space Available: 3.903 GB
 Thin Pool Minimum Free Space: 80.53 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: true
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Library Version: 1.02.107-RHEL7 (2016-06-09)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null bridge host overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-327.36.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 56
Total Memory: 251.6 GiB
Name: server.masked.example.com
ID: Z7J7:CLEG:KZPK:TNEI:QLYL:JBTO:XNM4:NX2X:KPQC:VHPC:6SFS:G4GR
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Insecure Registries:
 127.0.0.0/8

docker.txt

AaronDMarasco-VSI 에 2016년 11월 17일

👍1

제공된 로그에서 dm_udev_wait 에 멈춘 것 같습니다.

goroutine 2747 [syscall, 12 minutes, locked to thread]:
github.com/docker/docker/pkg/devicemapper._Cfunc_dm_udev_wait(0xc80d4d887c, 0xc800000000)
\t??:0 +0x41
github.com/docker/docker/pkg/devicemapper.dmUdevWaitFct(0xd4d887c, 0x44288e)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper_wrapper.go:222 +0x22
github.com/docker/docker/pkg/devicemapper.UdevWait(0xc821c7e8f8, 0x0, 0x0)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src
Nov 17 06:50:13 server docker: /github.com/docker/docker/pkg/devicemapper/devmapper.go:259 +0x3b
github.com/docker/docker/pkg/devicemapper.activateDevice(0xc82021a880, 0x1e, 0xc8202f0cc0, 0x57, 0x9608, 0x1900000000, 0x0, 0x0, 0x0, 0x0)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:771 +0x8b8
github.com/docker/docker/pkg/devicemapper.ActivateDevice(0xc82021a880, 0x1e, 0xc8202f0cc0, 0x57, 0x9608, 0x1900000000, 0x0, 0x0)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:732 +0x78
github.com/docker/docker/daemon/graphdriver/devmapper.(*DeviceSet).activateDeviceIfNeeded(0xc8200b6340, 0xc8208e0a40, 0xc8200b6300, 0x0, 0x0)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/deviceset.go:539 +0x58d
github.com/docker/docker/daemon/graphdriver/devmapper.(*DeviceSet).MountDevice(0xc8200b6340, 0xc820a00200, 0x40, 0xc820517ab0, 0x61, 0x0, 0x0, 0x0, 0x0)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/deviceset.go:2269 +0x2cd
github.com/docker/docker/daemon/graphdriver/devmapper.(*Driver).Get(0xc82047bf40, 0xc820a00200, 0x40, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/driver.go:185 +0x62f
github.com/docker/docker/daemon/graphdriver.(*NaiveDiffDriver).Get(0xc8201c2680, 0xc820a00200, 0x40, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
\t<autogenerated>:30 +0xa6

비슷한 문제 # 27900 # 27543

@ AaronDMarasco-VSI dmsetup udevcomplete_all 사용해 보셨습니까?

coolljt0725 에 2016년 11월 17일

@ coolljt0725 아니요,보고를 위해 로그를 덤프 한 후 더 이상 데몬을 사용하지 않고 데몬을 다시 시작했습니다.

AaronDMarasco-VSI 에 2016년 11월 17일

@tonistiigi , SIGUSR1 이후 Docker 데몬의 전체 스택 추적은 여기에서 찾을 수 있습니다.

liquid-sky 에 2016년 11월 17일

@ liquid-sky의 추적이 netlink 소켓에서 차단 된 것 같습니다.

goroutine 13038 [syscall, 9838 minutes, locked to thread]:
syscall.Syscall6(0x2d, 0x16, 0xc820fc3000, 0x1000, 0x0, 0xc8219bc028, 0xc8219bc024, 0x0, 0x300000002, 0x66b5a6)
    /usr/lib/go1.6/src/syscall/asm_linux_amd64.s:44 +0x5
syscall.recvfrom(0x16, 0xc820fc3000, 0x1000, 0x1000, 0x0, 0xc8219bc028, 0xc8219bc024, 0x427289, 0x0, 0x0)
    /usr/lib/go1.6/src/syscall/zsyscall_linux_amd64.go:1712 +0x9e
syscall.Recvfrom(0x16, 0xc820fc3000, 0x1000, 0x1000, 0x0, 0x1000, 0x0, 0x0, 0x0, 0x0)
    /usr/lib/go1.6/src/syscall/syscall_unix.go:251 +0xb9
github.com/vishvananda/netlink/nl.(*NetlinkSocket).Receive(0xc820c6c5e0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go:341 +0xae
github.com/vishvananda/netlink/nl.(*NetlinkRequest).Execute(0xc820dded20, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go:228 +0x20b
github.com/vishvananda/netlink.LinkSetMasterByIndex(0
 x7f1e88c67c20, 0xc820e00630, 0x3, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go:231 +0x3b0
github.com/vishvananda/netlink.LinkSetMaster(0x7f1e88c67c20, 0xc820e00630, 0xc8219bc550, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go:205 +0xb7
github.com/docker/libnetwork/drivers/bridge.addToBridge(0xc820c78830, 0xb, 0x177bf88, 0x7, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go:782 +0x275
github.com/docker/libnetwork/drivers/bridge.(*driver).CreateEndpoint(0xc820316640, 0xc8201f6840, 0x40, 0xc821879500, 0x40, 0x7f1e88c67bd8, 0xc820f38580, 0xc821a87bf0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go:1004 +0x1436
github.com/docker/libnetwork.(*network).addEndpoint(0xc820f026c0, 0xc8209f2300, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/docker/libnetwork/network.go:749 +0x21b
github.com/docker/libnetwork.(*network).CreateEndpoint(0xc820f026c0, 0xc820eb1909, 0x6, 0xc8210af160, 0x4, 0x4, 0x0, 0x0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/docker/libnetwork/network.go:813 +0xaa7
github.com/docker/docker/daemon.(*Daemon).connectToNetwork(0xc82044e480, 0xc820e661c0, 0x177aea8, 0x6, 0xc820448c00, 0x0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/.gopath/src/github.com/docker/docker/daemon/container_operations.go:539 +0x39f
github.com/docker/docker/daemon.(*Daemon).allocateNetwork(0xc82044e480, 0xc820e661c0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker
 -1.11.2/.gopath/src/github.com/docker/docker/daemon/container_operations.go:401 +0x373
github.com/docker/docker/daemon.(*Daemon).initializeNetworking(0xc82044e480, 0xc820e661c0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/.gopath/src/github.com/docker/docker/daemon/container_operations.go:680 +0x459
github.com/docker/docker/daemon.(*Daemon).containerStart(0xc82044e480, 0xc820e661c0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/.gopath/src/github.com/docker/docker/daemon/start.go:125 +0x219
github.com/docker/docker/daemon.(*Daemon).ContainerStart(0xc82044e480, 0xc820ed61d7, 0x40, 0x0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/.gopath/src/github.com/docker/docker/daemon/start.go:75 +0x575

cc @aboch

tonistiigi 에 2016년 11월 17일

다른 사람들이 제안했듯이 이것은 커널에서 발생하는 매우 나쁜 일의 부작용 일 수 있습니다.
이 상황을 완화하기 위해 https://github.com/docker/libnetwork/pull/1557 을 추가하고 있습니다.

aboch 에 2016년 11월 17일

일부 오류 메시지 ( ~~journalctl~~ syslog에서 ~~2 개의~~ 3 개 스택 추적이있을 수 있습니다.
도커 이미지에 대한 rspec / serverspec 테스트를 실행 중이며이 상태에서도 커가 응답하지 않는 것 같습니다. 테스트가 20 분 이상 중단되었습니다 (실패 할 경우 5 회 재시도).
각 이미지 테스트는 5 분 이내에 완료되며 이제 테스트는 최소 30 분 또는 60 분 동안 실행됩니다.

https://gist.github.com/mblaschke/d5d38cb34f6178e50e465c6e1f02131c

uname -a :
Linux webdevops.infogene.fr 4.4.0-47-generic # 68-Ubuntu SMP 10 월 26 일 수요일 19:39:52 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux

도커 정보 :
컨테이너 : 5
달리기 : 1
일시 중지됨 : 0
중지됨 : 4
이미지 : 1208
서버 버전 : 1.12.3
스토리지 드라이버 : aufs
루트 디렉토리 : / var / lib / docker / aufs
백업 파일 시스템 : extfs
Dirs : 449
Dirperm1 지원 : true
로깅 드라이버 : json-file
Cgroup 드라이버 : cgroupfs
플러그인 :
볼륨 : 로컬
네트워크 : 브리지 호스트 널 오버레이
Swarm : 비활성
런타임 : runc
기본 런타임 : runc
보안 옵션 : apparmor seccomp
커널 버전 : 4.4.0-47-generic
운영 체제 : Ubuntu 16.04.1 LTS
OSType : 리눅스
아키텍처 : x86_64
CPU : 7
총 메모리 : 11.73GiB
이름 : webdevops.infogene.fr
ID : DGNM : G3MV : ZMMV : HY6K : UPLU : CMEV : VHCA : RVY3 : CRV7 : FS5M : KMVQ : MQO5
Docker 루트 디렉토리 : / var / lib / docker
디버그 모드 (클라이언트) : false
디버그 모드 (서버) : false
레지스트리 : https://index.docker.io/v1/
경고 : 스왑 제한 지원 없음
안전하지 않은 레지스트리 :
127.0.0.0/8

mblaschke 에 2016년 11월 26일

다음은 serverspec의 결과 출력입니다.

https://gist.github.com/mblaschke/21a521367a2a2b71301607482647a748

mblaschke 에 2016년 11월 26일

@mblaschke 나는 당신의 흔적을 살펴 보았습니다 (https://gist.github.com/tonistiigi/0fb0abfb068a89975c072b68e6ed07ce). 나는 거기에서 의심스러운 것을 찾을 수 없습니다. 모든 장기 실행 고 루틴은 실행중인 컨테이너 또는 실행중인 고 루틴이 잠금을 보유하지 않으므로 정상인 개방형 io 사본에서 가져옵니다. 추적에서 docker ps 또는 docker exec/stop 와 같은 다른 명령이 귀하의 경우에 차단되지 않았을 것으로 예상하고 귀하가 본 중단은 특정 컨테이너 또는 exec가 완료 될 것으로 예상했지만 완료되지 않았습니다. 티. 이것은 애플리케이션 자체가 무언가에 매달려 있거나 컨테이너에 대한 이벤트를 보내지 않는 컨테이너와 관련이있을 수 있습니다 (cc @mlaventure).

로그에있는 경고는 https://github.com/docker/containerd/pull/351 로 수정해야합니다. 스팸을 유발할뿐 심각한 문제는 아닙니다. 로그에서 디버그 로그가 활성화되지 않았기 때문에 데몬에 전송 된 의심스러운 명령이 있는지 확인할 수 없습니다. 스택 추적을 수행하기 전에 몇 분 동안 의미있는 로그가없는 것 같습니다.

tonistiigi 에 2016년 11월 28일

동일한 코드가 Docker 1.10.3에서 작동하지만 Docker 1.11.x 이후에는 작동하지 않습니다. serverspec 테스트가 시간 초과와 함께 무작위로 실패합니다.
직렬 모드보다 병렬로 테스트를 실행할 때 (예 : 4 코어 CPU에서 2 개 또는 4 개의 테스트를 실행하는 경우) 더 자주 발생한다는 느낌이 있지만 결과는 동일합니다. 성공적으로 실행되는 테스트 실행이 없습니다.
Docker 1.11에서는 전체 docker 데몬이 중단되었습니다. 1.12 Docker는 exec 만 실패하거나 시간 초과로 실행되기 때문입니다.

mblaschke 에 2016년 11월 29일

@mblaschke 추적도

어떤 exec 프로그램을 실행하고 있습니까? 자체 세션 ID로 새 프로세스를 포크합니까?

mlaventure 에 2016년 11월 29일

https://github.com/rancher/rancher 에 의해 할당 된 IP 주소를 찾기 위해 모든 컨테이너에서 정기적으로 ip addr 를 실행합니다. 아직)

프로덕션 클러스터 내에서 정기적으로 중단 문제가 발생하고 있습니다.
ip addr 사용하면 자체 세션 ID로 실행되는 프로세스에 별다른 마법이 없습니다.

GameScripting 에 2016년 11월 29일

뿡 빵뀨
우리는 테스트를 위해 serverspec / rspec을 사용하고 있으며 매우 간단한 테스트 (파일 검사, 간단한 명령 검사, 간단한 응용 프로그램 검사)를 실행하고 있습니다. 대부분의 경우 단순한 파일 권한 검사조차도 실패합니다.

테스트는 여기에 있습니다 (그러나 실행을 위해 일부 환경 설정이 필요함) :
https://github.com/webdevops/Dockerfile/tree/develop/tests/serverspec

코드베이스로 시도해 볼 수 있습니다.

모든 파이썬 (pip) 및 루비 모듈을 가져 오기위한 make requirements
bin/console docker:pull --threads=auto (허브에서 최대 180 개의 이미지 가져 오기)
bin/console test:serverspec --threads=auto 모든 parallized 모드에서 테스트 또는 실행하려면 bin/console test:serverspec 시리얼 모드를

mblaschke 에 2016년 11월 29일

@GameScripting 지금 혼란 스러워요 : sweat_smile :. @mblaschke 가 실행되는 것과 동일한 컨텍스트를 언급하고 있습니까?

그렇지 않은 경우 어떤 Docker 버전을 사용하고 있습니까?

그리고 귀하의 질문에 대답하기 위해 ip addr가 이와 같은 일을 할 가능성은 거의 없습니다.

어떤 이미지를 사용하고 있습니까? 사용중인 정확한 docker exec 명령은 무엇입니까?

mlaventure 에 2016년 11월 29일

죄송합니다. 좀 더 혼란스럽게 만들 의도가 없었습니다.
나는 동일한 맥락을 언급하지 않고 그가 언급 한 테스트 스위트를 사용하지 않습니다. 문제의 원인이 될 수있는 작업에 대한 더 많은 (유용한) 컨텍스트 및 / 또는 정보를 제공하고 싶었습니다.

이 버그를 해결하는 데있어 주요 문제는 아직 안정적이고 재현 가능한 단계를 제시하여 중단을 유발할 수 없다는 것입니다.

@mblaschke 가 버그를 안정적으로 트리거 할 수 있도록 무언가를 찾은 것 같습니다.

GameScripting 에 2016년 11월 29일

Docker 1.11.2와 함께 CoreOS 안정 (1185.3.0)을 사용합니다.
일부 변수를 확인하기 위해 내 Redis 컨테이너에 docker exec로 시계를 실행합니다. 적어도 하루 동안 Docker 데몬이 중단됩니다.

하지만 해결책 을 찾을 때까지 containerd (https://github.com/docker/containerd)의 ctr 유틸리티를 사용하여 실행중인 컨테이너 내에서 프로세스를 시작합니다. 컨테이너를 시작하고 중지하는데도 사용할 수 있습니다. 나는 그것이 docker 1.11.2에 통합되었다고 생각합니다.
: 불행하게도 그것은 CoreOS I에 또 다른 버그가 여기에보고가 https://github.com/docker/containerd/issues/356#event 당신이 정기적으로 청소 / tmp를 필요하지만, 적어도이있다, 그래서 (그들은 이후 고정) -874038823를 프로덕션에서 일주일 동안 나를 위해 일했습니다.

다음 docker exec 예제 :

docker exec -i container_name /bin/sh 'echo "Hello"'

ctr로 번역 할 수 있습니다.

/usr/bin/ctr --address=/run/docker/libcontainerd/docker-containerd.sock containers exec --id=${id_of_the_running_container} --pid=any_unique_process_name -a --cwd=/ /bin/sh -c 'echo "Hello"'

따라서 임시 해결책으로 스크립트를 ctr로 변환 할 수 있습니다.

wallneradam 에 2016년 11월 29일

@mblaschke 게시 한 명령이 실패했지만 docker 실패처럼 보이지 않습니다. https://gist.github.com/tonistiigi/86badf5a41dff3fe53bd68d8e83e4ec4 디버그 로그를 활성화 할 수 있습니까? 마스터 빌드는 또한 데몬 내부에 대한 더 많은 디버그 데이터를 저장하고 sigusr1 신호로 containerd를 추적 할 수도 있습니다. 멈춘 프로세스를 추적하고 있기 때문에 ps aux 도 도움이 될 수 있습니다.

tonistiigi 에 2016년 11월 30일

헉헉
알파인 블랙리스트 (현재 빌드 문제)를 잊어 버렸으므로 다음을 실행하십시오. bin/console test:serverspec --threads=auto --blacklist=:alpine

죄송합니다 :(

mblaschke 에 2016년 11월 30일

@mblaschke 여전히 도커 문제처럼 보이지 않습니다. docker exec <id> /usr/bin/php -i 에 걸려 있습니다. 사용중인 이미지를 추적하고 수동으로 시작하면이 이미지에 실제 PHP가 설치되어 있지 않음을 알 수 있습니다.

root<strong i="8">@254424aecc57</strong>:/# php -v
HipHop VM 3.11.1 (rel)
Compiler: 3.11.1+dfsg-1ubuntu1
Repo schema: 2f678922fc70b326c82e56bedc2fc106c2faca61

그리고이 HipHopVM은 -i 지원하지 않고 블록 만 지원합니다.

tonistiigi 에 2016년 12월 01일

헉헉
나는 지난 Docker 버전에서 오랫동안이 버그를 사냥하고 있었고 우리 테스트 스위트에서이 버그를 보지 못했습니다. 우리는 그것을 고쳤습니다. 감사합니다. / o

빌드 로그를 검색 한 결과 1.12.3을 사용할 때 하나의 테스트 실패 (hhvm 테스트가 아닌 임의의 문제)를 발견했습니다. 우리는 Docker를 계속 강조하고 문제를 찾으려고 노력할 것입니다.

mblaschke 에 2016년 12월 01일

@ coolljt0725 방금 Docker가 다시 중단 된 것을 찾기 위해 일하러 돌아 왔습니다. docker ps 는) 한 세션에 중단되었고 sudo service docker stop 중단되었습니다. 세 번째 세션을 열었습니다.

$ sudo lvs
  LV          VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  docker-pool vg_ex  twi-aot--- 750.00g             63.49  7.88                            
$ sudo dmsetup udevcomplete_all
This operation will destroy all semaphores with keys that have a prefix 3405 (0xd4d).
Do you really want to continue? [y/n]: y
2 semaphores with keys prefixed by 3405 (0xd4d) destroyed. 0 skipped.

완료 되 자마자 다른 두 세션은 차단 해제되었습니다. 이전에 문제가 되었기 때문에 디스크 공간을 확인하고 있었기 때문에 가장 먼저 살펴 보았습니다. 2 개의 세마포어는 내가 가진 두 번의 호출 일 수 있지만 Jenkins 서버에서 많은 docker 호출이 걸려 있었기 때문에 내가 주변을 찌르고 있었던 것입니다 ...

dmsetup 호출을 수행 한 후 중단 된 출력의 예, docker run 는 며칠 전에 시작되었습니다.

docker run -td -v /opt/Xilinx/:/opt/Xilinx/:ro -v /opt/Modelsim/:/opt/Modelsim/:ro -v /data/jenkins_workspace_modelsim/workspace/examples_hdl/APPLICATION/bias/HDL_PLATFORM/modelsim_pf/TARGET_OS/7:/build --name jenkins-examples_hdl-APPLICATION--bias--HDL_PLATFORM--modelsim_pf--TARGET_OS--7-546 jenkins/build:v3-C7 /bin/sleep 10m
docker: An error occurred trying to connect: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/create?name=jenkins-examples_hdl-APPLICATION--bias--HDL_PLATFORM--modelsim_pf--TARGET_OS--7-546: EOF.
See 'docker run --help'.

AaronDMarasco-VSI 에 2016년 12월 06일

Docker 1.11.2 중단, 스택 추적 : https://gist.github.com/Calpicow/871621ba807d6eb9b18b91e8c2eb4eef

Calpicow 에 2016년 12월 21일

@Calpicow의 추적이 멈춘 것 같습니다. 그러나 udev_wait 케이스를 보지 않습니다. 트윗 담아 가기

goroutine 488 [syscall, 10 minutes, locked to thread]:
github.com/docker/docker/pkg/devicemapper._C2func_dm_task_run(0x7fbffc010f80, 0x0, 0x0, 0x0)
    ??:0 +0x47
github.com/docker/docker/pkg/devicemapper.dmTaskRunFct(0x7fbffc010f80, 0xc800000001)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper_wrapper.go:96 +0x21
github.com/docker/docker/pkg/devicemapper.(*Task).run(0xc8200266d8, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engin
e/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:155 +0x37
github.com/docker/docker/pkg/devicemapper.SuspendDevice(0xc821b07380, 0x55, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:627 +0x99
github.com/docker/docker/pkg/devicemapper.CreateSnapDevice(0xc821013f80, 0x25, 0x1a, 0xc821b07380, 0x55, 0x17, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:759 +0x92
github.com/docker/docker/daemon/graphdriver/devmapper.(*DeviceSet).createRegisterSnapDevice(0xc8203be9c0, 0xc82184d1c0, 0x40, 0xc821a78f40, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/deviceset.go:860 +0x557
github.com/docker/docker/daemon/graphdriver/devmapper.(*DeviceSet).AddDevice(0xc8203be9c0, 0xc82184d1c0, 0x40, 0xc8219c47c0, 0x40, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/deviceset.go:1865 +0x81f
github.com/docker/docker/daemon/graphdriver/devmapper.(*Driver).Create(0xc8200ff770, 0xc82184d1c0, 0x40, 0xc8219c47c0, 0x40, 0x0, 0x0, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/driver.go:124 +0x5f
github.com/docker/docker/daemon/graphdriver.(*NaiveDiffDriver).Create(0xc820363940, 0xc82184d1c0, 0x40, 0xc8219c47c0, 0x40, 0x0, 0x0, 0x0, 0x0)
    <autogenerated>:24 +0xaa
github.com/docker/docker/layer.(*layerStore).Register(0xc820363980, 0x7fc02faa3898, 0xc821a6ae00, 0xc821ace370, 0x47, 0x0, 0x0, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/layer/layer_store.go:266 +0x382
github.com/docker/docker/distribution/xfer.(*LayerDownloadManager).makeDownloadFunc.func1.1(0xc8210cd740, 0xc8210cd680, 0x7fc02fb6b758, 0xc820f422d0, 0xc820ee15c0, 0xc820ee1680, 0xc8210cd6e0, 0xc820e8e0b0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/distribut
ion/xfer/download.go:316 +0xc01
created by github.com/docker/docker/distribution/xfer.(*LayerDownloadManager).makeDownloadFunc.func1
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/distribution/xfer/download.go:341 +0x191

tonistiigi 에 2016년 12월 22일

@Calpicow dmesg 로그가 있습니까? dmsetup status 의 출력을 보여줄 수 있습니까?

coolljt0725 에 2016년 12월 22일

내 docker ps 이 중단되지만 info / restart / images 같은 다른 명령은 정상적으로 작동합니다.

아래에도 거대한 SIGUSR1 덤프가 있습니다 (여기에 맞지 않음). https://gist.github.com/ahmetalpbalkan/34bf40c02a78e319eaf5710acb15cf9a

docker 서버 버전 : 1.11.2
스토리지 드라이버 : 오버레이
커널 버전 : 4.7.3-coreos-r3
운영 체제 : CoreOS 1185.5.0 (MoreOS)

이 고 루틴이 700 톤 정도있는 것 같습니다.

...
goroutine 1149 [chan send, 1070 minutes]:
github.com/vishvananda/netlink.LinkSubscribe.func2(0xc821159d40, 0xc820fa4c60)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go:898 +0x2de
created by github.com/vishvananda/netlink.LinkSubscribe
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go:901 +0x107

goroutine 442 [chan send, 1129 minutes]:
github.com/vishvananda/netlink.LinkSubscribe.func2(0xc8211eb380, 0xc821095920)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go:898 +0x2de
created by github.com/vishvananda/netlink.LinkSubscribe
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go:901 +0x107
...

ahmetb 에 2017년 01월 02일

@ahmetalpbalkan netlink 소켓이 돌아올 때까지 기다리는 것이 차단 된 것
이것은 커널의 버그이지만 1.12.5는 최소한이 넷 링크 소켓에서 시간 초과가 있어야합니다.
내가 추측해야한다면 dmesg 출력에 device_count = 1; waiting for <interface> to become free 와 같은 무언가가있을 것입니다.

cpuguy83 에 2017년 01월 02일

@ cpuguy83 네, 제 경우와 비슷한 https://github.com/coreos/bugs/issues/254 를 봤지만 커널 로그에 "대기"메시지가 표시되지 않습니다.

1.12.5는 아직 coreos 알파 스트림에도 도달하지 않은 것 같습니다. 다운 그레이드 할 수있는 커널 / 도커 버전이 있습니까?

ahmetb 에 2017년 01월 02일

@ahmetalpbalkan Yay, 또 다른 커널 버그입니다.
이것이 우리가 netlink 소켓에 타임 아웃을 도입 한 이유입니다. 새로운 컨테이너를 시작 / 중지 할 수는 없지만 적어도 Docker는 차단되지 않습니다.

cpuguy83 에 2017년 01월 02일

버그가 정확히 무엇인지 알고 있습니까? 커널 버그가 업스트림으로보고 되었습니까? 아니면이 버그가 수정 된 커널 버전이 있습니까?

GameScripting 에 2017년 01월 02일

@GameScripting 문제는 이것이 생성 된 배포판에보고되어야하며, 여기에서도 동일한 효과를 일으키는 하나 이상의 문제가 있음을 알 수 있습니다.

cpuguy83 에 2017년 01월 02일

Docker v1.12.3이있는 또 다른 것이 있습니다.

덤프
dmesg
dmsetup

30003

Calpicow 에 2017년 01월 09일

Moby: Docker 데몬이로드 중 정지됨

가장 유용한 댓글

모든 174 댓글

11228, # 12758, # 12962

10355 # 13940

30003

관련 문제