moby 🚀 - 드라이버 devicemapper가 루트 파일 시스템을 제거하지 못했습니다. 기기가 사용 중입니다.

이것은 모든 컨테이너에서 발생합니까? 컨테이너에서 실행 중인 것은 무엇이며 컨테이너를 시작하기 위해 어떤 옵션을 사용합니까? (예: 바인드 마운트된 디렉토리를 사용하고 있습니까? docker exec 를 사용하여 컨테이너에서 추가 프로세스를 시작하고 있습니까?)

thaJeztah 에 2016년 10월 15일

우리는 거의 동일한 방식으로 모든 컨테이너를 실행하고 그 중 하나에서 무작위로 발생합니다.
우리는 docker exec 를 사용하지 않고 어떤 디렉토리도 bind-mount하지 마십시오.
다음은 죽은 컨테이너 중 하나의 구성입니다.

[
    {
        "Id": "ce2ea989895b7e073b9c3103a7312f32e70b5ad01d808b42f16655ffcb06c535",
        "Created": "2016-10-13T09:14:52.069916456Z",
        "Path": "/run.sh",
        "Args": [],
        "State": {
            "Status": "dead",
            "Running": false,
            "Paused": false,
            "Restarting": false,
            "OOMKilled": false,
            "Dead": true,
            "Pid": 0,
            "ExitCode": 143,
            "Error": "",
            "StartedAt": "2016-10-13T18:05:50.839079884Z",
            "FinishedAt": "2016-10-14T01:49:22.133922284Z"
        },
        "Image": "sha256:df8....4f4",
        "ResolvConfPath": "/var/lib/docker/containers/ce2ea989895b7e073b9c3103a7312f32e70b5ad01d808b42f16655ffcb06c535/resolv.conf",
        "HostnamePath": "/var/lib/docker/containers/ce2ea989895b7e073b9c3103a7312f32e70b5ad01d808b42f16655ffcb06c535/hostname",
        "HostsPath": "/var/lib/docker/containers/ce2ea989895b7e073b9c3103a7312f32e70b5ad01d808b42f16655ffcb06c535/hosts",
        "LogPath": "",
        "Name": "/d9a....43",
        "RestartCount": 0,
        "Driver": "devicemapper",
        "MountLabel": "",
        "ProcessLabel": "",
        "AppArmorProfile": "",
        "ExecIDs": null,
        "HostConfig": {
            "Binds": [],
            "ContainerIDFile": "",
            "LogConfig": {
                "Type": "fluentd",
                "Config": {
                    "fluentd-address": "127.0.0.1:24224",
                    "fluentd-async-connect": "true",
                    "labels": "app_id",
                    "tag": "docker.{{if (.ExtraAttributes nil).app_id}}{{(.ExtraAttributes nil).app_id}}{{else}}{{.Name}}{{end}}"
                }
            },
            "NetworkMode": "default",
            "PortBindings": {
                "3000/tcp": [
                    {
                        "HostIp": "127.0.0.2",
                        "HostPort": ""
                    }
                ]
            },
            "RestartPolicy": {
                "Name": "always",
                "MaximumRetryCount": 0
            },
            "AutoRemove": false,
            "VolumeDriver": "",
            "VolumesFrom": null,
            "CapAdd": null,
            "CapDrop": null,
            "Dns": [],
            "DnsOptions": [],
            "DnsSearch": [],
            "ExtraHosts": [
                "mongodb:10.240.0.2"
            ],
            "GroupAdd": null,
            "IpcMode": "",
            "Cgroup": "",
            "Links": null,
            "OomScoreAdj": 0,
            "PidMode": "",
            "Privileged": false,
            "PublishAllPorts": false,
            "ReadonlyRootfs": false,
            "SecurityOpt": null,
            "UTSMode": "",
            "UsernsMode": "",
            "ShmSize": 67108864,
            "Runtime": "runc",
            "ConsoleSize": [
                0,
                0
            ],
            "Isolation": "",
            "CpuShares": 0,
            "Memory": 0,
            "CgroupParent": "mygroup/d9...43",
            "BlkioWeight": 0,
            "BlkioWeightDevice": null,
            "BlkioDeviceReadBps": null,
            "BlkioDeviceWriteBps": null,
            "BlkioDeviceReadIOps": null,
            "BlkioDeviceWriteIOps": null,
            "CpuPeriod": 0,
            "CpuQuota": 0,
            "CpusetCpus": "",
            "CpusetMems": "",
            "Devices": null,
            "DiskQuota": 0,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 0,
            "MemorySwappiness": -1,
            "OomKillDisable": false,
            "PidsLimit": 0,
            "Ulimits": null,
            "CpuCount": 0,
            "CpuPercent": 0,
            "IOMaximumIOps": 0,
            "IOMaximumBandwidth": 0
        },
        "GraphDriver": {
            "Name": "devicemapper",
            "Data": {
                "DeviceId": "29459",
                "DeviceName": "docker-8:1-34634049-8e884a263c75cfb042ac02136461c8e8258cf693f0e4992991d5803e951b3dbb",
                "DeviceSize": "107374182400"
            }
        },
        "Mounts": [],
        "Config": {
            "Hostname": "ce2ea989895b",
            "Domainname": "",
            "User": "app",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "ExposedPorts": {
                "3000/tcp": {}
            },
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PORT=3000",
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            ],
            "Cmd": [
                "/run.sh"
            ],
            "Image": "eu.gcr.io/reg/d9...43:latest",
            "Volumes": null,
            "WorkingDir": "/data/app",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": {
                "app_id": "d9...43"
            }
        },
        "NetworkSettings": {
            "Bridge": "",
            "SandboxID": "65632062399b8f9f011fdebcd044432c45f068b74d24c48818912a21e8036c98",
            "HairpinMode": false,
            "LinkLocalIPv6Address": "",
            "LinkLocalIPv6PrefixLen": 0,
            "Ports": null,
            "SandboxKey": "/var/run/docker/netns/65632062399b",
            "SecondaryIPAddresses": null,
            "SecondaryIPv6Addresses": null,
            "EndpointID": "",
            "Gateway": "",
            "GlobalIPv6Address": "",
            "GlobalIPv6PrefixLen": 0,
            "IPAddress": "",
            "IPPrefixLen": 0,
            "IPv6Gateway": "",
            "MacAddress": "",
            "Networks": {
                "bridge": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": null,
                    "NetworkID": "59d8aa11b92aaa8ad9da7f010e8689c158cad7d80ec4b9e4e4688778c49149e0",
                    "EndpointID": "",
                    "Gateway": "",
                    "IPAddress": "",
                    "IPPrefixLen": 0,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": ""
                }
            }
        }
    }
]

ceecko 에 2016년 10월 15일

이 파일 시스템이 Backing Filesystem: ext4 서버에서만 발생하는 것으로 나타났습니다.
xfs 를 백업 파일 시스템으로 실행하는 서버에서는 문제가 발생하지 않는 것 같습니다.

ceecko 에 2016년 10월 15일

@ceecko 감사합니다, 흥미

@rhvgoyal 이것은 귀하의 알려진 문제입니까?

thaJeztah 에 2016년 10월 15일

이것은 프로덕션에서 우리에게 큰 타격을 줍니다./ 죽은 컨테이너를 제거하는 방법에 대한 힌트가 있습니까?

ceecko 에 2016년 10월 17일

@thaJeztah 이것이 xfs가 아닌 ext4에서만 발생한다는

일반적으로 사람들은 장치가 사용 중이라고 보고했으며 그 이유는 매우 다양합니다.

@ceeko 먼저 도커 데몬이 호스트 마운트 네임스페이스가 아닌 자체 슬레이브 마운트 네임스페이스로 실행되고 있는지 확인합니다. 마운트 지점이 새지 않고 이러한 오류가 발생할 가능성이 줄어듭니다. 시스템 구동 도커를 사용하는 경우 도커 단위 파일이 있어야 하며 MountFlags=slave가 있어야 합니다.

rhvgoyal 에 2016년 10월 17일

@rhvgoyal MountFlags=slave 는 지금까지 문제를 해결한 것 같습니다. 변경 전에 생성된 컨테이너는 여전히 문제이지만 새 컨테이너는 지금까지 오류를 유발하지 않는 것 같습니다. 변경 사항이 있으면 연락 드리겠습니다.

Btw 참조를 찾을 수 없기 때문에 프로덕션에서 모범 사례로 권장하기 위해 저장소 드라이버 문서를 업데이트할 가치가 있습니다.

도와주셔서 감사합니다.

ceecko 에 2016년 10월 17일

이것은 얼마 전에 변경되었습니다. https://github.com/docker/docker/commit/2aee081cad72352f8b0c37ba0414ebc925b022e8#diff -ff907ce70a8c7e795bde1de91be6fa68(https://github.com/docker/228/pull) 토론에 따라 문제가 제거된 경우 활성화되지 않음; https://github.com/docker/docker/pull/22806#issuecomment -220043409

기본값을 다시 변경해야 합니까? @rhvgoyal

thaJeztah 에 2016년 10월 17일

@thaJeztah 기본값을 다시 MountFlags=slave로 변경하는 것이 좋습니다. 우리는 그렇게 했습니다.

이상적으로 지연된 제거 및 지연된 삭제 기능이 이를 처리해야 했으며 MountFlags=slave를 사용할 필요가 없었습니다. 그러나 지연 삭제만으로는 충분하지 않습니다. 이전 커널에는 다른 마운트 네임스페이스에 마운트된 경우에도 마운트 네임스페이스에서 디렉토리를 제거할 수 있는 기능이 없습니다. 이것이 컨테이너 제거가 실패할 수 있는 한 가지 이유입니다.

따라서 오래된 커널이 해당 기능을 제공할 때까지 슬레이브 마운트 네임스페이스에서 도커 데몬을 실행하는 것이 좋습니다.

rhvgoyal 에 2016년 10월 17일

@rhvgoyal MountFlags=slave 에서도 오류가 다시 나타나기 시작했습니다. 지연된 제거 및 삭제를 시도하고 다시 연락드리겠습니다.

ceecko 에 2016년 10월 20일

xfs 에서도 동일한 오류가 발생했습니다.
다음은 도커 정보입니다.

Containers: 52
 Running: 52
 Paused: 0
 Stopped: 0
Images: 9
Server Version: 1.12.2
Storage Driver: devicemapper
 Pool Name: data-docker_thin
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file:
 Metadata file:
 Data Space Used: 13 GB
 Data Space Total: 107.1 GB
 Data Space Available: 94.07 GB
 Metadata Space Used: 19.19 MB
 Metadata Space Total: 268.4 MB
 Metadata Space Available: 249.2 MB
 Thin Pool Minimum Free Space: 10.71 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: true
 Deferred Deletion Enabled: true
 Deferred Deleted Device Count: 0
 Library Version: 1.02.107-RHEL7 (2016-06-09)
Logging Driver: journald
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host overlay bridge null
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-327.10.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 7.389 GiB
Name: ip-172-31-25-29.eu-west-1.compute.internal
ID: ZUTN:S7TL:6JRZ:HG52:LDLZ:VR5Q:RWVV:IP7E:HOQ4:R55X:Z7AI:P63R
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Insecure Registries:
 127.0.0.0/8

ceecko 에 2016년 10월 22일

MountFlags=slave 와 dm.use_deferred_deletion=true 와 dm.use_deferred_removal=true 사용해도 1.12.2 에서 이전보다 덜 자주 발생하지만 여전히 오류가 발생함을 확인했습니다.

ceecko 에 2016년 10월 27일

다음은 제거할 수 없는 컨테이너 1개에 대한 추가 정보입니다.

libcontainerd: container 4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543 restart canceled
error locating sandbox id c9272d4830ba45e03efda777a14a4b5f7f94138997952f2ec1ba1a43b2c4e1c5: sandbox c9272d4830ba45e03efda777a14a4b5f7f94138997952f2ec1ba1a43b2c4e1c5 not found
failed to cleanup ipc mounts:\nfailed to umount /var/lib/docker/containers/4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543/shm: invalid argument
devmapper: Error unmounting device ed06c57080b8a8f25dc83d4afabaccb26d72009dad23a8e87310b873c226b905: invalid argument
Error unmounting container 4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543: invalid argument
Handler for DELETE /containers/4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543 returned error: Unable to remove filesystem for 4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543: remove /var/lib/docker/containers/4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543/shm: device or resource busy

ceecko 에 2016년 10월 29일

다음 메시지는 디렉터리 제거에 실패했음을 나타냅니다.

remove /var/lib/docker/containers/4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543/shm: device or resource busy

그리고 이전 커널에서는 디렉토리가 다른 마운트 네임스페이스에 마운트되어 있기 때문에 실패할 수 있습니다. deferred deletion 기능을 비활성화하면 이 메시지가 더 이상 표시되지 않습니다. 그러나 그것은 다른 오류 메시지가 될 것입니다.

여기서 문제의 핵심은 컨테이너가 여전히 실행 중이거나 일부 탑재 지점이 다른 일부 탑재 네임스페이스로 누출되었다는 것입니다. 그리고 그것이 누출된 마운트 네임스페이스와 그것이 어떻게 거기에 도달했는지 알아낼 수 있다면 우리는 그것을 고칠 수 있습니다.

이 문제가 발생하면 find /proc/*/mounts | xargs grep "4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543" 시도할 수 있습니다.

그런 다음 누출된 컨테이너와 관련된 마운트가 있는 pid를 확인합니다. 그리고 그것은 약간의 아이디어를 줄 수 있습니다.

rhvgoyal 에 2016년 10월 31일

👍13 ❤2 🎉1

나는 모두 죽은 4개의 컨테이너를 시도했고 장치가 사용 중이고 아무것도 얻지 못해 제거할 수 없습니다./

# find /proc/*/mounts | xargs grep -E "b3070ef60def|62777ad2994f|923a6d20506d|f3e079a9721c"
grep: /proc/9659/mounts: No such file or directory

ceecko 에 2016년 10월 31일

이제 실제로 약간 다른 오류 메시지가 나타납니다.

# docker rm b3070ef60def
Error response from daemon: Driver devicemapper failed to remove root filesystem b3070ef60deffc0e496631ed6e058c4569d6233bb6947b27072a70c663d9e579: remove /var/lib/docker/devicemapper/mnt/527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd: device or resource busy

ceecko 에 2016년 10월 31일

같은 것. 이 디렉토리는 다른 마운트 네임스페이스에 마운트되어 있으므로 삭제할 수 없습니다. /proc/에서 검색해 보세요.이 id 527ae5 대해 /mounts 및 grep을 수행하고 이 마운트 지점을 보고 있는 pid를 확인합니다. 설정에서 컨테이너 rootfs 마운트 포인트가 다른 마운트 네임스페이스로 누출되는 이유를 파악해야 합니다.

rhvgoyal 에 2016년 10월 31일

여기 우리가 간다:

# find /proc/*/mounts | xargs grep -E "527ae5"
grep: /proc/10080/mounts: No such file or directory
/proc/15890/mounts:/dev/mapper/docker-253:1-1050933-527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd /var/lib/docker/devicemapper/mnt/527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd xfs rw,seclabel,relatime,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota 0 0
/proc/23584/mounts:/dev/mapper/docker-253:1-1050933-527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd /var/lib/docker/devicemapper/mnt/527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd xfs rw,seclabel,relatime,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota 0 0
/proc/31591/mounts:/dev/mapper/docker-253:1-1050933-527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd /var/lib/docker/devicemapper/mnt/527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd xfs rw,seclabel,relatime,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota 0 0
/proc/4194/mounts:/dev/mapper/docker-253:1-1050933-527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd /var/lib/docker/devicemapper/mnt/527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd xfs rw,seclabel,relatime,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota 0 0
/proc/4700/mounts:/dev/mapper/docker-253:1-1050933-527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd /var/lib/docker/devicemapper/mnt/527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd xfs rw,seclabel,relatime,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota 0 0
/proc/4701/mounts:/dev/mapper/docker-253:1-1050933-527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd /var/lib/docker/devicemapper/mnt/527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd xfs rw,seclabel,relatime,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota 0 0
/proc/8858/mounts:/dev/mapper/docker-253:1-1050933-527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd /var/lib/docker/devicemapper/mnt/527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd xfs rw,seclabel,relatime,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota 0 0
/proc/8859/mounts:/dev/mapper/docker-253:1-1050933-527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd /var/lib/docker/devicemapper/mnt/527ae5985b1b730a05a667d147ce15abcbfb950a334aea4b673a413b6b21c4dd xfs rw,seclabel,relatime,nouuid,attr2,inode64,logbsize=64k,sunit=128,swidth=128,noquota 0 0

nginx     4194  0.0  0.0  55592 10520 ?        S    11:55   0:06 nginx: worker process is shutting down
nginx     4700  2.3  0.0  55804 10792 ?        S    11:58   3:52 nginx: worker process is shutting down
nginx     4701  1.8  0.0  55800 10784 ?        S    11:58   3:04 nginx: worker process is shutting down
nginx     8858  2.4  0.0  55560 10720 ?        S    14:05   0:59 nginx: worker process
nginx     8859  3.1  0.0  55560 10700 ?        S    14:05   1:15 nginx: worker process
root     15890  0.0  0.0  55004  9524 ?        Ss   Oct29   0:05 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    23584  0.0  0.0  55576 10452 ?        S    09:17   0:00 nginx: worker process is shutting down
nginx    31591  0.9  0.0  63448 18820 ?        S    09:46   2:53 nginx: worker process is shutting down

ceecko 에 2016년 10월 31일

👍1

이 pid가 매핑되는 프로세스는 무엇입니까? cat /proc/<pid>/comm 또는 ps -eaf | grep <pid> 시도

rhvgoyal 에 2016년 10월 31일

이들은 모두 구성을 다시 로드한 후 종료되는 nginx 작업자 프로세스입니다(위의 편집된 주석 참조). 컨테이너가 볼륨을 바인딩하지 않기 때문에 마운트를 차단하는 이유가 궁금합니다.

ceecko 에 2016년 10월 31일

그래서 nginx 프로세스가 다른 컨테이너에서 실행되고 있습니까? 아니면 호스트에서 실행 중입니까?

rhvgoyal 에 2016년 10월 31일

👍1

다음을 수행할 수 있습니다.

ls -l /proc/<docker-daemon-pid>/ns/mnt
ls -l /proc/<nginx-pid>/ns/mnt
호스트에서 bash 셸을 실행하고 ls -l /proc/$$/ns/mnt

그리고 출력을 붙여넣습니다. 여기.

rhvgoyal 에 2016년 10월 31일

nginx는 호스트에서 실행됩니다.

docker-pid

# ls -l /proc/13665/ns/mnt
lrwxrwxrwx. 1 root root 0 Oct 31 15:01 /proc/13665/ns/mnt -> mnt:[4026531840]

nginx-pid

# ls -l /proc/15890/ns/mnt
lrwxrwxrwx. 1 root root 0 Oct 31 15:01 /proc/15890/ns/mnt -> mnt:[4026533289]

ls -l /proc/$$/ns/mnt
lrwxrwxrwx. 1 root root 0 Oct 31 15:02 /proc/10063/ns/mnt -> mnt:[4026531840]

ceecko 에 2016년 10월 31일

docker-pid와 host 둘 다 동일한 마운트 네임스페이스를 공유하는 것 같습니다. 이는 도커 데몬이 호스트 마운트 네임스페이스에서 실행되고 있음을 의미합니다. 그리고 그것은 아마도 nginx가 컨테이너 시작 후 어느 시점에서 시작되었고 자체 마운트 네임스페이스에서 실행되는 것처럼 보인다는 것을 의미합니다. 그리고 그 당시 마운트 포인트가 nginx 마운트 네임스페이스로 누출되어 컨테이너 삭제를 방지하고 있습니다.

MountFlags=slave가 작동하는지 확인하십시오. 작동하면 /proc//ns/mnt는 호스트 마운트 네임스페이스에서 실행되는 docker 데몬과 bash 셸에 대해 다른 출력을 제공합니다.

rhvgoyal 에 2016년 10월 31일

네가 옳아. 이 호스트는 아직 MountFlags=slave 설정되지 않았습니다.
다른 호스트가 그랬지만 여전히 죽은 컨테이너가 있습니다. 지금은 수동으로 모두 제거했지만 MountFlags=slave 로 생성되었습니다.

상황이 반복될 때까지 기다렸다가 여기에 업데이트를 게시하겠습니다. 감사 해요.

ceecko 에 2016년 10월 31일

이제 상황은 다음과 같습니다. MountFlags=slave 및 지연된 제거 및 삭제를 사용하고 때때로 원격 API에서 장치가 사용 중이어서 제거할 수 없다는 오류가 발생합니다. 그러나 오류 직후에 docker rm container 를 호출하면 컨테이너가 잘 제거됩니다.

ceecko 에 2016년 11월 03일

👍1

문제가 다시 나타났습니다.

도커드

# ll /proc/16441/ns/mnt
lrwxrwxrwx. 1 root root 0 Nov  4 23:05 /proc/16441/ns/mnt -> mnt:[4026534781]

nginx

# ll /proc/15890/ns/mnt
lrwxrwxrwx. 1 root root 0 Oct 31 15:01 /proc/15890/ns/mnt -> mnt:[4026533289]

# ll /proc/$$/ns/mnt
lrwxrwxrwx. 1 root root 0 Nov  4 23:06 /proc/22029/ns/mnt -> mnt:[4026531840]

# find /proc/*/mounts | xargs grep -E "a2388cf8d19a"
/proc/11528/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/12918/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/1335/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/14853/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/1821/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/22241/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/22406/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/22618/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
grep: /proc/22768/mounts: No such file or directory
/proc/22771/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/23601/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/24108/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/24405/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/24614/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/24817/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/25116/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/25277/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/25549/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/25779/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/26036/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/26211/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/26369/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/26638/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/26926/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/27142/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/27301/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/27438/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/27622/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/27770/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/27929/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/28146/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/28309/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/28446/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/28634/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/28805/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/28961/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/29097/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/2909/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/29260/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/29399/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/29540/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/29653/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/29675/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/29831/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/30040/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/30156/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/30326/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/30500/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/30619/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/30772/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/30916/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/31077/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/31252/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/31515/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/31839/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/32036/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/32137/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/3470/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/5628/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/5835/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
/proc/8076/mounts:shm /var/lib/docker/containers/a2388cf8d19a431f47e9df533a853809ceaf819581c23c438fefe470d2bf8f03/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0

이전 명령의 프로세스

  PID TTY      STAT   TIME COMMAND
 1335 ?        Sl     0:00 docker-containerd-shim 9a678ecbd9334230d61a0e305cbbb50e3e5207e283decc2d570d787d98f8d930 /var/run/docker/libcontainerd/9a678ecbd9334230d61a0e305cbbb50e3e5207e283decc2d570d787d98f8d930 docker-runc
 1821 ?        Sl     0:00 docker-containerd-shim 97f0a040c0ebe15d7527a54481d8946e87f1ec0681466108fd8356789de0232b /var/run/docker/libcontainerd/97f0a040c0ebe15d7527a54481d8946e87f1ec0681466108fd8356789de0232b docker-runc
 2909 ?        Sl     0:00 docker-containerd-shim ef2e6a22e5ea5f221409ff8888ac976bd9b23633fab13b6968253104424a781f /var/run/docker/libcontainerd/ef2e6a22e5ea5f221409ff8888ac976bd9b23633fab13b6968253104424a781f docker-runc
 3470 ?        Sl     0:00 docker-containerd-shim 24b6918ce273a82100a1c6bae711554340bc60ff965527456130bd2fabf0ca6f /var/run/docker/libcontainerd/24b6918ce273a82100a1c6bae711554340bc60ff965527456130bd2fabf0ca6f docker-runc
 5628 ?        Sl     0:00 docker-containerd-shim 9561cbe2f0133119e2749d09e5db3f6473e77830a7981c1171849fe403d73973 /var/run/docker/libcontainerd/9561cbe2f0133119e2749d09e5db3f6473e77830a7981c1171849fe403d73973 docker-runc
 5835 ?        Sl     0:00 docker-containerd-shim a5afb5ab32c2396cdddd24390f94b01f597850012ad9731d6d47db9708567b24 /var/run/docker/libcontainerd/a5afb5ab32c2396cdddd24390f94b01f597850012ad9731d6d47db9708567b24 docker-runc
 8076 ?        Sl     0:00 docker-containerd-shim 20cca8e6ec26364aa4eb9733172c7168052947d5e204d302034b2d14fd659302 /var/run/docker/libcontainerd/20cca8e6ec26364aa4eb9733172c7168052947d5e204d302034b2d14fd659302 docker-runc
11528 ?        Sl     0:00 docker-containerd-shim f7584de190086d41da71235a6ce2516cbccb8ac0fff9f71b03d405af9478660f /var/run/docker/libcontainerd/f7584de190086d41da71235a6ce2516cbccb8ac0fff9f71b03d405af9478660f docker-runc
12918 ?        Sl     0:00 docker-containerd-shim 9ada39a06c5e1351df30dde993adcd048f8bd7984af2b412b8f3339f037c8847 /var/run/docker/libcontainerd/9ada39a06c5e1351df30dde993adcd048f8bd7984af2b412b8f3339f037c8847 docker-runc
14853 ?        Sl     0:00 docker-containerd-shim 4d05a794e0be9e710b804f5a7df22e2dd268083b3d7d957daae6f017c1c8fb67 /var/run/docker/libcontainerd/4d05a794e0be9e710b804f5a7df22e2dd268083b3d7d957daae6f017c1c8fb67 docker-runc
22241 ?        Sl     0:00 docker-containerd-shim ce81b6b51fcbf1163491381c790fc944b54adf3333f82d75281bc746b81ccd47 /var/run/docker/libcontainerd/ce81b6b51fcbf1163491381c790fc944b54adf3333f82d75281bc746b81ccd47 docker-runc
22406 ?        Sl     0:00 docker-containerd-shim 519e5531104278559d95f351e2212b04b06f44cbd1e05336cd306b9a958c8874 /var/run/docker/libcontainerd/519e5531104278559d95f351e2212b04b06f44cbd1e05336cd306b9a958c8874 docker-runc
22618 ?        Sl     0:00 docker-containerd-shim 869b356e7838ef3c0200864c58a89a22c812574a60da535eb2107a5da1d07a65 /var/run/docker/libcontainerd/869b356e7838ef3c0200864c58a89a22c812574a60da535eb2107a5da1d07a65 docker-runc
22771 ?        Sl     0:00 docker-containerd-shim 63f0816e72d4be4ed79fe2c31794876b1b3ab7a300ca69497a8bddbd8cf8953f /var/run/docker/libcontainerd/63f0816e72d4be4ed79fe2c31794876b1b3ab7a300ca69497a8bddbd8cf8953f docker-runc
23601 ?        Sl     0:00 docker-containerd-shim 9943b9930cb4803666caf5499dfb0753c36193efe0285f2ae697be63c6122003 /var/run/docker/libcontainerd/9943b9930cb4803666caf5499dfb0753c36193efe0285f2ae697be63c6122003 docker-runc
24108 ?        Sl     0:00 docker-containerd-shim 21af7db24bbd1679f48ae3cf0d022535c208c63dc42a274dd54e3cfcb90b9737 /var/run/docker/libcontainerd/21af7db24bbd1679f48ae3cf0d022535c208c63dc42a274dd54e3cfcb90b9737 docker-runc
24405 ?        Sl     0:00 docker-containerd-shim 0dccc5141be2367de2601d83020f7f4c27762d4c8e986b4b100a4bce12fc2f5a /var/run/docker/libcontainerd/0dccc5141be2367de2601d83020f7f4c27762d4c8e986b4b100a4bce12fc2f5a docker-runc
24614 ?        Sl     0:00 docker-containerd-shim e1023b528f8b2a1889c0fc360c0d1738a15be0bd53e0722920a9abb5ecc2c538 /var/run/docker/libcontainerd/e1023b528f8b2a1889c0fc360c0d1738a15be0bd53e0722920a9abb5ecc2c538 docker-runc
24817 ?        Sl     0:00 docker-containerd-shim 2106fe528147306e768b01b03ef7f10c53536ad4aaee6a628608c9c5bbf9494c /var/run/docker/libcontainerd/2106fe528147306e768b01b03ef7f10c53536ad4aaee6a628608c9c5bbf9494c docker-runc
25116 ?        Sl     0:00 docker-containerd-shim 1b9623bf34b5030d47faf21dee6462478d6d346327af0b4c96e6ccae4c880368 /var/run/docker/libcontainerd/1b9623bf34b5030d47faf21dee6462478d6d346327af0b4c96e6ccae4c880368 docker-runc
25277 ?        Sl     0:00 docker-containerd-shim 6662486b063f530a446602eed47811443eb737151b404c0d253bf54df9e6b93f /var/run/docker/libcontainerd/6662486b063f530a446602eed47811443eb737151b404c0d253bf54df9e6b93f docker-runc
25549 ?        Sl     0:05 docker-containerd-shim f6e3e14362455f38d6abfdeb106f280151ee3f12dc9d2808c774dd3d2cd3e828 /var/run/docker/libcontainerd/f6e3e14362455f38d6abfdeb106f280151ee3f12dc9d2808c774dd3d2cd3e828 docker-runc
25779 ?        Sl     0:00 docker-containerd-shim 144fded452cd9a0bdbcdf72890aa400eadb65e434038373e2ddfc1f4e28a1279 /var/run/docker/libcontainerd/144fded452cd9a0bdbcdf72890aa400eadb65e434038373e2ddfc1f4e28a1279 docker-runc
26036 ?        Sl     0:00 docker-containerd-shim e076f6cfc4fcd04a9a4fa6aecf37fe244d6d84e200380b6ef4a1e0a79575e952 /var/run/docker/libcontainerd/e076f6cfc4fcd04a9a4fa6aecf37fe244d6d84e200380b6ef4a1e0a79575e952 docker-runc
26211 ?        Sl     0:00 docker-containerd-shim 65bea267b22c9a6efe58ea9d7339986b01e7f67c095aa1451768de5114a5b027 /var/run/docker/libcontainerd/65bea267b22c9a6efe58ea9d7339986b01e7f67c095aa1451768de5114a5b027 docker-runc
26369 ?        Sl     0:00 docker-containerd-shim 390bc07f95b460220bda115aad2f247b33f50c81f7bd2b3d1a20e1696b95511b /var/run/docker/libcontainerd/390bc07f95b460220bda115aad2f247b33f50c81f7bd2b3d1a20e1696b95511b docker-runc
26638 ?        Sl     0:00 docker-containerd-shim b6d86f96d33260673b2e072419f08578716582578015a30e4f23d4e481a55809 /var/run/docker/libcontainerd/b6d86f96d33260673b2e072419f08578716582578015a30e4f23d4e481a55809 docker-runc
26926 ?        Sl     0:00 docker-containerd-shim 337ec28dd75f2f5bc2cfa813504d35a8c148777c7f246f8af5d792c36f3453ae /var/run/docker/libcontainerd/337ec28dd75f2f5bc2cfa813504d35a8c148777c7f246f8af5d792c36f3453ae docker-runc
27142 ?        Sl     0:00 docker-containerd-shim ba2216d6b46d7b57493734b093bc153823fb80a48ef4b91d0d1c660ee9adc519 /var/run/docker/libcontainerd/ba2216d6b46d7b57493734b093bc153823fb80a48ef4b91d0d1c660ee9adc519 docker-runc
27301 ?        Sl     0:00 docker-containerd-shim 520f66841a97b2545784b29ea3bc7a22a58d97987c404e1d99314da75307d279 /var/run/docker/libcontainerd/520f66841a97b2545784b29ea3bc7a22a58d97987c404e1d99314da75307d279 docker-runc
27438 ?        Sl     0:00 docker-containerd-shim 0908466da160ed739d74d675e1a6e04d85da0caa2216c739c0e218e75219dc3e /var/run/docker/libcontainerd/0908466da160ed739d74d675e1a6e04d85da0caa2216c739c0e218e75219dc3e docker-runc
27622 ?        Sl     0:00 docker-containerd-shim e627ef7439b405376ac4cf58702241406e3c8b9fbe76694a9593c6f96b4e5925 /var/run/docker/libcontainerd/e627ef7439b405376ac4cf58702241406e3c8b9fbe76694a9593c6f96b4e5925 docker-runc
27770 ?        Sl     0:00 docker-containerd-shim 0b6275f8f1d8277ac39c723825e7b830e0cf852c44696074a279227402753827 /var/run/docker/libcontainerd/0b6275f8f1d8277ac39c723825e7b830e0cf852c44696074a279227402753827 docker-runc
27929 ?        Sl     0:00 docker-containerd-shim fcf647fbe0fe024cc4c352a2395d8d315d647aeda7f75a2f9d42826eca3dee58 /var/run/docker/libcontainerd/fcf647fbe0fe024cc4c352a2395d8d315d647aeda7f75a2f9d42826eca3dee58 docker-runc
28146 ?        Sl     0:00 docker-containerd-shim 19f020044a3e600aa554a7ab00264155206e8791a7002f5616b397745b2c6405 /var/run/docker/libcontainerd/19f020044a3e600aa554a7ab00264155206e8791a7002f5616b397745b2c6405 docker-runc
28309 ?        Sl     0:00 docker-containerd-shim 3f6a5b9136df8169d3d1e1eb104bda6f4baf32ca5a2bc35ddaeea4a3a0bf774a /var/run/docker/libcontainerd/3f6a5b9136df8169d3d1e1eb104bda6f4baf32ca5a2bc35ddaeea4a3a0bf774a docker-runc
28446 ?        Sl     0:00 docker-containerd-shim f1ede5511531d05ab9eb86612ed239446a4b3acefe273ee65474b4a4c1d462e2 /var/run/docker/libcontainerd/f1ede5511531d05ab9eb86612ed239446a4b3acefe273ee65474b4a4c1d462e2 docker-runc
28634 ?        Sl     0:00 docker-containerd-shim 7485d577ec2e707e1151a73132ceba7db5c0509c1ffbaf750515e0228b2ffa33 /var/run/docker/libcontainerd/7485d577ec2e707e1151a73132ceba7db5c0509c1ffbaf750515e0228b2ffa33 docker-runc
28805 ?        Sl     0:00 docker-containerd-shim e5afd9eccb217e16f0494f71504d167ace8377498ce6141e2eaf96de71c74233 /var/run/docker/libcontainerd/e5afd9eccb217e16f0494f71504d167ace8377498ce6141e2eaf96de71c74233 docker-runc
28961 ?        Sl     0:00 docker-containerd-shim bd62214b90fab46a92893a15e06d5e2744659d61d422776ce9b395e56bb0e774 /var/run/docker/libcontainerd/bd62214b90fab46a92893a15e06d5e2744659d61d422776ce9b395e56bb0e774 docker-runc
29097 ?        Sl     0:00 docker-containerd-shim 81db13c46756851006d2f0b0393e37590bac228a3d958a12cc9f6c86d5992253 /var/run/docker/libcontainerd/81db13c46756851006d2f0b0393e37590bac228a3d958a12cc9f6c86d5992253 docker-runc
29260 ?        Sl     0:00 docker-containerd-shim 188d2c3a98cc1d65a88daeb17dacca7fca978831a9292b7225e60f7443096114 /var/run/docker/libcontainerd/188d2c3a98cc1d65a88daeb17dacca7fca978831a9292b7225e60f7443096114 docker-runc
29399 ?        Sl     0:00 docker-containerd-shim 1dc12f09be24722a18057072ac5a0b2b74324e13de051f213e1966c1d31e1348 /var/run/docker/libcontainerd/1dc12f09be24722a18057072ac5a0b2b74324e13de051f213e1966c1d31e1348 docker-runc
29540 ?        Sl     0:00 docker-containerd-shim 0c425984d9c544683de0644a77849807a9ee31db99043e3e2bace9d2e9cfdb63 /var/run/docker/libcontainerd/0c425984d9c544683de0644a77849807a9ee31db99043e3e2bace9d2e9cfdb63 docker-runc
29653 ?        Sl     0:00 docker-containerd-shim b1805c289749d432a0680aa7f082703175b647005d240d594124a64e69f5de28 /var/run/docker/libcontainerd/b1805c289749d432a0680aa7f082703175b647005d240d594124a64e69f5de28 docker-runc
29675 ?        Sl     0:36 docker-containerd-shim 6a9751b28d88c61d77859b296a8bde21c6c0c8379089ae7886b7332805bb8463 /var/run/docker/libcontainerd/6a9751b28d88c61d77859b296a8bde21c6c0c8379089ae7886b7332805bb8463 docker-runc
29831 ?        Sl     0:00 docker-containerd-shim 09796b77ef046f29439ce6cab66797314b27e9f77137017773f3b90637107433 /var/run/docker/libcontainerd/09796b77ef046f29439ce6cab66797314b27e9f77137017773f3b90637107433 docker-runc
30040 ?        Sl     0:20 docker-containerd-shim a2e26ba3d11f876b38e88cc6501fae51e7c66c7c2d40982eec72f23301f82772 /var/run/docker/libcontainerd/a2e26ba3d11f876b38e88cc6501fae51e7c66c7c2d40982eec72f23301f82772 docker-runc
30156 ?        Sl     0:00 docker-containerd-shim 35d157883a8c586e5086e940d1a5f2220e2731ca19dd7655c9ee3150321bac66 /var/run/docker/libcontainerd/35d157883a8c586e5086e940d1a5f2220e2731ca19dd7655c9ee3150321bac66 docker-runc
30326 ?        Sl     0:00 docker-containerd-shim 5af072f8c0b1af434139104ad884706079e2c46bf951200eaf9531614e2dc92a /var/run/docker/libcontainerd/5af072f8c0b1af434139104ad884706079e2c46bf951200eaf9531614e2dc92a docker-runc
30500 ?        Sl     0:00 docker-containerd-shim ba71715ba985511a617a7377b3b0d66f0b75af8323c17544c54f75da1a267a1f /var/run/docker/libcontainerd/ba71715ba985511a617a7377b3b0d66f0b75af8323c17544c54f75da1a267a1f docker-runc
30619 ?        Sl     0:08 docker-containerd-shim f42fdd0d4d971442969637f9e1db4c1e45270d86f950e614d8721d767872930a /var/run/docker/libcontainerd/f42fdd0d4d971442969637f9e1db4c1e45270d86f950e614d8721d767872930a docker-runc
30772 ?        Sl     0:00 docker-containerd-shim 8a745ab948d51e41b80992e2246058082f274d30d9f68f46dd3fef2e441afc01 /var/run/docker/libcontainerd/8a745ab948d51e41b80992e2246058082f274d30d9f68f46dd3fef2e441afc01 docker-runc
30916 ?        Sl     0:00 docker-containerd-shim 238f635c6adac1786ee46a99f0c20f36544cc5ebd644fc0c0908d38e9177eb1e /var/run/docker/libcontainerd/238f635c6adac1786ee46a99f0c20f36544cc5ebd644fc0c0908d38e9177eb1e docker-runc
31077 ?        Sl     0:00 docker-containerd-shim 9c208554dcb64c6568f026455a33d64830995c0411c6876fbea66355bab2cb5f /var/run/docker/libcontainerd/9c208554dcb64c6568f026455a33d64830995c0411c6876fbea66355bab2cb5f docker-runc
31252 ?        Sl     0:00 docker-containerd-shim afc0a4c93a27d9451875f8d917b24c64f59ba3b1992ff52f9ac3f93623440a54 /var/run/docker/libcontainerd/afc0a4c93a27d9451875f8d917b24c64f59ba3b1992ff52f9ac3f93623440a54 docker-runc
31515 ?        Sl     0:00 docker-containerd-shim b84b9b1d32bb9001359812a4dbbdf139c64c9eb9cf29475c73b2b498d990826f /var/run/docker/libcontainerd/b84b9b1d32bb9001359812a4dbbdf139c64c9eb9cf29475c73b2b498d990826f docker-runc
31839 ?        Sl     0:00 docker-containerd-shim 5b328bfc29a6a3033c1c5aa39fa38006538307aca3056f17d6421e5855bc496f /var/run/docker/libcontainerd/5b328bfc29a6a3033c1c5aa39fa38006538307aca3056f17d6421e5855bc496f docker-runc
32036 ?        Sl     0:00 docker-containerd-shim 5994ea24313b7e685321bd5bc03c0646c266969fa02f8061c0b4f1d94287f017 /var/run/docker/libcontainerd/5994ea24313b7e685321bd5bc03c0646c266969fa02f8061c0b4f1d94287f017 docker-runc
32137 ?        Sl     0:00 docker-containerd-shim aa4d9711bce7f85e04b94c8f733d0e29fb08763031fa81068acf9b5ee1bf3061 /var/run/docker/libcontainerd/aa4d9711bce7f85e04b94c8f733d0e29fb08763031fa81068acf9b5ee1bf3061 docker-runc

ceecko 에 2016년 11월 05일

❤3 👍1

좋아, docker-containerd-shim이 이 마운트 지점을 보고 있으므로 계속 사용 중입니다. docker-containerd-shim이 무엇이고 마운트 지점이 거기에서 누출되는 이유가 확실하지 않습니다. 누가 그것에 대해 알고 있습니다.

@crosbymichael 당신이 그것에 대해 알고있을 것입니다.

rhvgoyal 에 2016년 11월 07일

cc @mrunalp

rhvgoyal 에 2016년 11월 07일

핑 주셔서 감사합니다. 내가 볼게요.

crosbymichael 에 2016년 11월 07일

@ceecko 이 docker-containerd-shim 스레드/프로세스의 마운트 네임스페이스가 무엇인지 확인할 수 있습니다. 나는 이것이 docker 데몬과 마운트 네임 스페이스를 공유하지 않는다고 생각하며 아마도 그래야 할 것입니다.

rhvgoyal 에 2016년 11월 07일

@rhvgoyal 그들은 같은 이름 공간을 공유합니다

도커드

# ll /proc/16441/ns/mnt
lrwxrwxrwx. 1 root root 0 Nov  4 23:05 /proc/16441/ns/mnt -> mnt:[4026534781]

3개의 docker-container-shim 프로세스를 확인했습니다.

# ll /proc/23774/ns/mnt
lrwxrwxrwx. 1 root root 0 Nov  8 07:49 /proc/23774/ns/mnt -> mnt:[4026534781]
# ll /proc/27296/ns/mnt
lrwxrwxrwx. 1 root root 0 Nov  8 07:49 /proc/27296/ns/mnt -> mnt:[4026534781]
# ll /proc/31485/ns/mnt
lrwxrwxrwx. 1 root root 0 Nov  8 07:49 /proc/31485/ns/mnt -> mnt:[4026534781]

지금 제거할 수 없는 죽은 컨테이너가 없습니다.
문제는 일주일에 두 번 정기적으로 모든 컨테이너를 중지 및 제거하고 동일한 구성으로 새 컨테이너를 시작한다는 것입니다. 이 "다시 시작"하기 전에 일부 컨테이너가 종료되어 제거할 수 없습니다. 정기적으로 "다시 시작"하면 대부분의 컨테이너가 죽지만 모든 오래된 컨테이너가 중지되면 모든 죽은 컨테이너가 갑자기 제거될 수 있습니다.

ceecko 에 2016년 11월 08일

동일한 문제가 있지만 docker-compose up -d 를 사용하여 컨테이너를 다시 만들려고 할 때 몇 가지 추가 오류가 발생합니다.

Nov 10 13:25:21 omega dockerd[27830]: time="2016-11-10T13:25:21.418142082-06:00" level=info msg="Container b7fbb78311cdfb393bc2d3d9b7a6f0742d80dc5b672909408809bf6f7af55434 failed to exit within 10 seconds of signal 15 - using
Nov 10 13:25:21 omega dockerd[27830]: time="2016-11-10T13:25:21.530704247-06:00" level=warning msg="libcontainerd: container b7fbb78311cdfb393bc2d3d9b7a6f0742d80dc5b672909408809bf6f7af55434 restart canceled"
Nov 10 13:25:21 omega dockerd[27830]: time="2016-11-10T13:25:21.536115733-06:00" level=error msg="Error closing logger: invalid argument"
Nov 10 13:25:42 omega dockerd[27830]: time="2016-11-10T13:25:42.329001072-06:00" level=error msg="devmapper: Error unmounting device 0795abc37cc58b775ce4fb142271f5de5fa771477310321d1283f37ad6b20df9: Device is Busy"
Nov 10 13:25:42 omega dockerd[27830]: time="2016-11-10T13:25:42.329149437-06:00" level=error msg="Error unmounting container b7fbb78311cdfb393bc2d3d9b7a6f0742d80dc5b672909408809bf6f7af55434: Device is Busy"
Nov 10 13:25:42 omega dockerd[27830]: time="2016-11-10T13:25:42.544584079-06:00" level=error msg="Handler for GET /v1.24/containers/xbpf3invpull/logs returned error: No such container: xbpf3invpull"

특히 Error closing logger: invalid argument 오류와 failed to exit within 10 seconds 오류가 발생합니다. 이는 내가 dumb-init 를 사용하여 컨테이너를 시작하기 때문에 발생하지 않아야 한다고 확신합니다.

이 오류가 이 문제와 관련이 있습니까?

SEAPUNK 에 2016년 11월 10일

현재 이 문제를 해결하기 위해 노력하고 있습니다. 나는 도움을 드리기 위해 containerd에 공개 PR을 가지고 있습니다.

이를 테스트할 재현 가능한 방법을 찾기가 어렵습니다. 수정이 완료된 후 이 수정을 테스트하는 데 관심이 있으신가요?

crosbymichael 에 2016년 11월 10일

그래, 확실히. 이 문제를 재현할 수 있는 가상 머신을 만들고 수정을 시도하겠습니다. 그래도 작동하지 않으면 문제가 있는 서버에서 테스트하겠습니다.

SEAPUNK 에 2016년 11월 10일

방금 VM을 만들었고 (아주 쉽게!) 문제를 재현할 수 있었습니다.

이것이 내가 Virtualbox로 한 일입니다.

일반 아치 Linux VM 설치(일반 설치 프로세스 사용)
docker, docker-compose 및 여러 프로세스(이 경우 nginx 선택)를 실행할 수 있는 다른 데몬을 설치한 다음 systemctl enable docker 시스템을 재부팅합니다.
500개의 작업자 프로세스와 함께 실행되도록 nginx 구성
3개의 장기 실행 컨테이너가 있는 docker-compose 파일을 만듭니다(postgres, 태그 9.2 선택).
docker-compose up -d
systemctl start nginx
이미지 태그 9.3을 사용하도록 docker-compose 파일 내부의 몇 가지 컨테이너 버전 변경
docker-compose pull
docker-compose up -d (컨테이너를 다시 생성하려고 시도한 다음 두 컨테이너 모두에 대해 "장치가 사용 중입니다" 오류가 표시됩니다.

nginx를 중지하면 컨테이너를 제거할 수 있습니다.

docker-compose.yml 현재(나는 실패한 시스템의 도커 설정을 모방함):

요청 시 VM에 대한 액세스를 제공할 수 있습니다. 로그인을 보낼 이메일을 저에게만 주십시오.

SEAPUNK 에 2016년 11월 11일

👍2

@mlaventure 이 문제를 다시 열 수 있습니까? 현재로서는 이 문제가 수정되었는지 여부를 알 수 없습니다.

SEAPUNK 에 2016년 11월 17일

👍4

@SEAPUNK 우리는 이 제안된 수정 사항으로 containerd를 업데이트할 것입니다. 테스트할 기회가 있다면 시도해 볼 수 있는 바이너리를 제공할 수 있습니다.

crosbymichael 에 2016년 11월 17일

물론, 내 VM이 대기 상태입니다.

SEAPUNK 에 2016년 11월 17일

❤1

바이너리가 언제 준비될지 알 수 있습니까?

SEAPUNK 에 2016년 11월 28일

@SEA펑크 1.13 릴리스 후보는 지금 테스트할 수 있으며 이 변경 사항이 있어야 합니다. https://github.com/docker/docker/releases

thaJeztah 에 2016년 11월 29일

알겠습니다. 시도해 보겠습니다. 감사 해요!

SEAPUNK 에 2016년 11월 29일

나는 모두에게,
여기에보고 된 것과 동일한 문제가 있다고 생각합니다.

[asantos<strong i="7">@fosters</strong> atp]$ docker-compose -f docker-compose-tst-u.yml rm api
Going to remove atp_api_1
Are you sure? [yN] y
Removing atp_api_1 ... error

ERROR: for atp_api_1  Driver devicemapper failed to remove root filesystem 63fac33396c5ab7de18505b6a6b6f41b4f927abeca74472fbe8490656ed85f3f: Device is Busy



dez 02 11:26:11 fosters.vi.pt kernel: device-mapper: ioctl: unable to remove open device docker-253:1-1315304-214b3ed3285aae193228831aba63b4e24592a96facfb604e4d2ff8b36000d6f9
dez 02 11:26:11 fosters.vi.pt kernel: device-mapper: ioctl: unable to remove open device docker-253:1-1315304-214b3ed3285aae193228831aba63b4e24592a96facfb604e4d2ff8b36000d6f9
dez 02 11:26:11 fosters.vi.pt kernel: device-mapper: ioctl: unable to remove open device docker-253:1-1315304-214b3ed3285aae193228831aba63b4e24592a96facfb604e4d2ff8b36000d6f9
dez 02 11:26:11 fosters.vi.pt kernel: device-mapper: ioctl: unable to remove open device docker-253:1-1315304-214b3ed3285aae193228831aba63b4e24592a96facfb604e4d2ff8b36000d6f9
dez 02 11:26:11 fosters.vi.pt kernel: device-mapper: ioctl: unable to remove open device docker-253:1-1315304-214b3ed3285aae193228831aba63b4e24592a96facfb604e4d2ff8b36000d6f9
dez 02 11:26:11 fosters.vi.pt kernel: device-mapper: ioctl: unable to remove open device docker-253:1-1315304-214b3ed3285aae193228831aba63b4e24592a96facfb604e4d2ff8b36000d6f9
dez 02 11:26:11 fosters.vi.pt kernel: device-mapper: ioctl: unable to remove open device docker-253:1-1315304-214b3ed3285aae193228831aba63b4e24592a96facfb604e4d2ff8b36000d6f9
dez 02 11:26:15 fosters.vi.pt docker[2535]: time="2016-12-02T11:26:15.943631263Z" level=error msg="Error removing mounted layer 63fac33396c5ab7de18505b6a6b6f41b4f927abeca74472fbe8490656ed85f3f: Device is Busy"
dez 02 11:26:15 fosters.vi.pt docker[2535]: time="2016-12-02T11:26:15.943863042Z" level=error msg="Handler for DELETE /v1.22/containers/63fac33396c5ab7de18505b6a6b6f41b4f927abeca74472fbe8490656ed85f3f returned error: Driver devicemapper failed to remove root filesystem 63fac33396c5ab7de18505b6a6b6f41b4f927abeca74472
dez 02 11:26:17 fosters.vi.pt docker[2535]: time="2016-12-02T11:26:17.299066706Z" level=error msg="Handler for GET /containers/7ea053faaf5afac4af476a70d2a9611a6b882d6a135bcea7c86579a6ae657884/json returned error: No such container: 7ea053faaf5afac4af476a70d2a9611a6b882d6a135bcea7c86579a6ae657884"
dez 02 11:26:17 fosters.vi.pt docker[2535]: time="2016-12-02T11:26:17.299608100Z" level=error msg="Handler for GET /containers/c3b1a805ed5d19a5f965d0ac979f05cbb59f362336041daea90a2fa4a1845d7d/json returned error: No such container: c3b1a805ed5d19a5f965d0ac979f05cbb59f362336041daea90a2fa4a1845d7d"


[asantos<strong i="8">@fosters</strong> atp]$ docker info
Containers: 4
 Running: 3
 Paused: 0
 Stopped: 1
Images: 110
Server Version: 1.12.3
Storage Driver: devicemapper
 Pool Name: docker-253:1-1315304-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file: /dev/fosters/docker-data
 Metadata file: /dev/fosters/docker-metadata
 Data Space Used: 10.71 GB
 Data Space Total: 20.72 GB
 Data Space Available: 10.02 GB
 Metadata Space Used: 16.73 MB
 Metadata Space Total: 2.303 GB
 Metadata Space Available: 2.286 GB
 Thin Pool Minimum Free Space: 2.072 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Library Version: 1.02.131 (2016-07-15)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay null bridge host
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.8.8-300.fc25.x86_64
Operating System: Fedora 25 (Workstation Edition)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.672 GiB
Name: fosters.vi.pt
ID: EBFN:W46P:BMFR:OSJ5:UPY2:7KAT:5NMT:KAOF:XQI3:ITEM:XQNL:46P7
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: xxxxxxx
Registry: https://index.docker.io/v1/
Insecure Registries:
 127.0.0.0/8

asantos82 에 2016년 12월 02일

PKGBUILD를 통해 바이너리를 수동으로 빌드해야 했습니다. 더 간단하고 조정을 통해 PKGBUILD가 특정 containerd 커밋(docker/containerd@03e5862ec0d8d3b3f750e19fca3ee367e13c090e로 설정)을 사용하도록 강제할 수 있기 때문입니다.

https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/docker #n19

곧 수정 결과가 나와야 합니다.

SEAPUNK 에 2016년 12월 02일

내가 뭔가 잘못하고 있을지 모르지만 지금은 컨테이너를 전혀 시작할 수 없습니다.

SEAPUNK 에 2016년 12월 02일

오, runc를 업데이트해야 할 것 같습니다... brb 재구축

SEAPUNK 에 2016년 12월 02일

예, 수정이 작동하지 않는 것 같습니다.

docker info

Containers: 3
 Running: 0
 Paused: 0
 Stopped: 3
Images: 8
Server Version: 1.13.0-rc2
Storage Driver: devicemapper
 Pool Name: docker-8:1-1835956-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 745.6 MB
 Data Space Total: 107.4 GB
 Data Space Available: 27.75 GB
 Metadata Space Used: 2.744 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.145 GB
 Thin Pool Minimum Free Space: 10.74 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.136 (2016-11-05)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 03e5862ec0d8d3b3f750e19fca3ee367e13c090e
runc version: 51371867a01c467f08af739783b8beafc154c4d7
init version: N/A (expected: 949e6facb77383876aeff8a6944dde66b3089574)
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.8.11-1-ARCH
Operating System: Arch Linux
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 3.864 GiB
Name: docker-vm
ID: KOVC:UCU5:5J77:P7I6:XXBX:33ST:H3UZ:GA7G:O7IF:P4RZ:VSSW:YBMJ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

docker version

[root@docker-vm ~]# docker version
Client:
 Version:      1.13.0-rc2
 API version:  1.25
 Go version:   go1.7.4
 Git commit:   1f9b3ef
 Built:        Fri Dec  2 12:37:59 2016
 OS/Arch:      linux/amd64

Server:
 Version:             1.13.0-rc2
 API version:         1.25
 Minimum API version: 1.12
 Go version:          go1.7.4
 Git commit:          1f9b3ef
 Built:               Fri Dec  2 12:37:59 2016
 OS/Arch:             linux/amd64
 Experimental:        false

SEAPUNK 에 2016년 12월 02일

자신의 VM에서 이것을 재현할 수 없다면 이 문제를 재현하고 사용자 지정 Docker 패키지를 빌드하는 VM에 대한 액세스를 제공할 용의가 있습니다.

SEAPUNK 에 2016년 12월 02일

CentOs 7의 docker 1.12.3에서 이것을 보고 있습니다.

dc2-elk-02:/root/staging/ls-helper$ 도커 --버전
Docker 버전 1.12.3, 빌드 6b644ec
dc2-elk-02:/root/staging/ls-helper$ uname -a
Linux dc2-elk-02 3.10.0-327.36.3.el7.x86_64 #1 SMP 월요일 10월 24일 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
dc2-elk-02:/root/staging/ls-helper$ 도커 rm ls-helper
데몬의 오류 응답: 드라이버 devicemapper가 루트 파일 시스템 e1b9cdb519d2f4bea53a552c8b76c1085650aa76c1fb90c8e22cac9c2e18830: Device is Busy를 제거하지 못했습니다.

나는 도커 작성을 사용하지 않습니다.

bladedoyle 에 2016년 12월 13일

나도 아마 이 오류가 발생했을 것 같다.

Flocker에 대한 승인 테스트를 실행할 때 다음과 같은 오류가 많이 나타납니다.

[root@acceptance-test-richardw-axpeyhrci22pi-1 ~]# journalctl  --boot --dmesg
...
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: dev_remove: 41 callbacks suppressed
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:34:56 acceptance-test-richardw-axpeyhrci22pi-1 kernel: device-mapper: ioctl: unable to remove open device docker-8:1-1072929-8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62
Dec 13 17:35:00 acceptance-test-richardw-axpeyhrci22pi-1 kernel: XFS (dm-1): Unmounting Filesystem

[root@acceptance-test-richardw-axpeyhrci22pi-1 ~]# journalctl --boot --unit docker
...
-- Logs begin at Tue 2016-12-13 17:30:53 UTC, end at Tue 2016-12-13 18:01:09 UTC. --
Dec 13 17:31:12 acceptance-test-richardw-axpeyhrci22pi-1 systemd[1]: Starting Docker Application Container Engine...
Dec 13 17:31:14 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:14.676133774Z" level=info msg="libcontainerd: new containerd process, pid: 1034"
Dec 13 17:31:16 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:16.209852977Z" level=warning msg="devmapper: Usage of loopback devices is strongly discouraged for production use. Please use `--storage-opt dm.thinpooldev` or use `man docker`
Dec 13 17:31:16 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:16.241124769Z" level=warning msg="devmapper: Base device already exists and has filesystem xfs on it. User specified filesystem  will be ignored."
Dec 13 17:31:16 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:16.259633105Z" level=info msg="[graphdriver] using prior storage driver \"devicemapper\""
Dec 13 17:31:16 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:16.423748590Z" level=info msg="Graph migration to content-addressability took 0.00 seconds"
Dec 13 17:31:16 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:16.443108711Z" level=info msg="Loading containers: start."
Dec 13 17:31:16 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:16.507397974Z" level=info msg="Firewalld running: true"
Dec 13 17:31:17 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:17.025244392Z" level=info msg="Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip can be used to set a preferred IP address"
Dec 13 17:31:17 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:17.195947610Z" level=info msg="Loading containers: done."
Dec 13 17:31:17 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:17.196550209Z" level=info msg="Daemon has completed initialization"
Dec 13 17:31:17 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:17.196575340Z" level=info msg="Docker daemon" commit=1564f02 graphdriver=devicemapper version=1.12.4
Dec 13 17:31:17 acceptance-test-richardw-axpeyhrci22pi-1 systemd[1]: Started Docker Application Container Engine.
Dec 13 17:31:17 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:17.231752452Z" level=info msg="API listen on [::]:2376"
Dec 13 17:31:17 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:31:17.231875125Z" level=info msg="API listen on /var/run/docker.sock"
Dec 13 17:32:41 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:32:41.631480676Z" level=error msg="devmapper: Error unmounting device 2a1e449a617f575520ef95c99fb8feab06986b7b86d81e7236a49e1a1cf192bb: Device is Busy"
Dec 13 17:32:41 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:32:41.632903143Z" level=error msg="Error unmounting container 117647e8bdd4e401d8d983c80872b84385d202015265663fae39754379ece719: Device is Busy"
Dec 13 17:33:20 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:33:20.300663432Z" level=error msg="devmapper: Error unmounting device 52e079667cf40f83b5be6d9375261500a626885581f41fc99873af58bc75939e: Device is Busy"
Dec 13 17:33:20 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:33:20.301660779Z" level=error msg="Error unmounting container 2aeabbd72f90da6d4fb1c797068f5c49c8e4da2182daba331dfe3e3da29c5053: Device is Busy"
Dec 13 17:34:50 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:34:50.461588888Z" level=error msg="devmapper: Error unmounting device 8a41ac9ebe13aa65b8513000bec2606a1dfc3ff624082dc9f4636b0e88d8ac62: Device is Busy"
Dec 13 17:34:50 acceptance-test-richardw-axpeyhrci22pi-1 dockerd[795]: time="2016-12-13T17:34:50.462602087Z" level=error msg="Error unmounting container e0c45f71e2992831a10bc68562bcc266beba6ef07546d950f3cfb06c39873505: Device is Busy"

[root@acceptance-test-richardw-axpeyhrci22pi-1 ~]# docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 4
Server Version: 1.12.4
Storage Driver: devicemapper
 Pool Name: docker-8:1-1072929-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 525.5 MB
 Data Space Total: 107.4 GB
 Data Space Available: 8.327 GB
 Metadata Space Used: 1.384 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.146 GB
 Thin Pool Minimum Free Space: 10.74 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.135-RHEL7 (2016-09-28)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: flocker local
 Network: host bridge overlay null
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-514.2.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 7.305 GiB
Name: acceptance-test-richardw-axpeyhrci22pi-1
ID: 4OHX:ODXJ:R2MH:ZMRK:52B6:J4TH:PMDR:OQ5D:YUQB:5RE3:YDAQ:V5JP
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

[root@acceptance-test-richardw-axpeyhrci22pi-1 ~]# cat /usr/lib/systemd/system/docker.service
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network.target

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd
ExecReload=/bin/kill -s HUP $MAINPID
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this version.
#TasksMax=infinity
TimeoutStartSec=0
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
# kill only the docker process, not all processes in the cgroup
KillMode=process

[Install]
WantedBy=multi-user.target

wallrj 에 2016년 12월 13일

@hvgoyal @rhatdan @vbatts
systemd docker.service 단위 파일에 MountFlags 없이 지연된 삭제 및 제거가 활성화된=true인 dockerd 1.12.4를 실행하는 RHEL7.1에서 중지/죽은 컨테이너 삭제/제거 중에 '장치 사용 중' 문제가 발생합니다.
다음과 같은 커널 메시지도 표시됩니다.
"커널: 장치 매퍼: 씬: 씬 장치 120 삭제에 실패했습니다." (120은 제거되는 컨테이너의 씬풀 장치의 장치 ID임)

모든 경우에 제거되는 컨테이너의 devicemapper 씬풀 장치 마운트 지점이 MountFlag=private/slave로 시작되는 호스트에 있는 다른 pid의 마운트 네임스페이스로 누출되었습니다.

ntpd.service는 RHEL에서 PrivateTmp=true로 시작됩니다.
systemd-udevd 서비스는 RHEL에서 MountFlags=slave로 시작됩니다.
컨테이너 삭제가 실패한 호스트에서 이러한 프로세스 중 하나는 해당 컨테이너 시작 시간 이후에 다시 시작되었습니다.

따라서 위의 시스템 프로세스는 기본적으로 개별적으로 변경/제어할 수 없는 일부 마운트 네임스페이스를 공유 해제하므로 호스트 마운트 네임스페이스에서 마운트 지점을 누출하는 것이 매우 쉬운 것처럼 보입니다.
mountflags=slave로 dockerd를 실행하는 것이 유일한 솔루션입니까? 또한 mountflags=slave(기본값은 공유)가 도커 시스템 단위 파일에서 얼마 전에 제거된 이유를 이해하는 데 도움을 줄 수 있습니까?
어떤 시나리오에서 슬레이브 마운트 지점 전파로 dockerd를 실행하면 다른 문제가 발생합니까?
감사 해요.

ravilr 에 2016년 12월 16일

👍5

RHEL 커널과 Fedora에서 자체 마운트 네임스페이스에서 dockerd를 실행하도록 강제하는 수정하려는 업스트림 커널은 다르게 작동하므로 호스트 네임스페이스에서 dockerd를 실행할 수 있습니다.

@rhvgoyal 은 당신에게

rhatdan 에 2016년 12월 16일

@ravilr , rhel/centos 커널에서 지연된 삭제를 비활성화합니다. 커널에는 이를 지원하는 패치가 없습니다.

또한 MountFlags=slave를 사용하여 docker를 실행합니다.

rhvgoyal 에 2016년 12월 16일

rhel/centos 커널에서 지연 제거를 계속 사용할 수 있으며 작동해야 합니다.

rhvgoyal 에 2016년 12월 16일

BTW, docker-storage-setup을 사용하여 스토리지를 설정하는 경우 기본 커널이 지연 삭제를 지원하는지 여부를 자동으로 파악하고 그에 따라 해당 옵션을 설정/해제합니다.

rhvgoyal 에 2016년 12월 16일

@rhvgoyal 컨테이너 루트 파일 시스템 제거에 실패한 후 공간을 확보하는 방법을 알고 있습니까?

mtrofimm 에 2016년 12월 19일

@rhvgoyal 제안 감사합니다. 제안하신 대로 시도하고 컨테이너 제거와 관련된 문제가 계속 발생하면 여기에 다시 보고하겠습니다.

ravilr 에 2016년 12월 20일

충돌; 이 문제를 해결하는 데 도움이 필요한 정보가 더 있습니까?

SEAPUNK 에 2017년 01월 10일

나는 Centos 7에서 1.12.5를 실행하는 것을 직접 쳤습니다.

moutflags=slave를 활성화하고 지연된 제거 및 삭제를 활성화하면 이 문제가 해결되었습니다. 이제 나는이 경쟁 조건 버그를 치고 있습니다. https://github.com/docker/docker/issues/23418

이것은 붙어 있는 컨테이너를 강제로 제거하는 것보다 약 100배 낫지만 여전히 좋지는 않습니다.

mechanicjay 에 2017년 01월 11일

xfs의 CentOS 7에서 재현할 수 있습니다.

dereckson 에 2017년 01월 28일

동일한 문제, Docker 1.13.0 - CentOS7:

docker-compose down
Removing container_container_1 ... error

ERROR: for container_container_1  Driver devicemapper failed to remove root filesystem 4d2d6c59f8435436e4144cc4e8675a0828658014cf53804f786ef2b175b4b324: Device is Busy

gerwim 에 2017년 01월 28일

이 문제에 대한 해결책이 있습니까? 여전히 문제가 표시되며 장치를 열어둔 상태로 유지하는 프로세스를 찾으려는 시도가 실패했습니다. 사용 중인 장치를 열어두고 있는 프로세스가 없는 것 같습니다.

감사 해요.

(내 의견에 대한 업데이트: 스레드를 처음 읽을 때는 명확하지 않았지만 지연 제거를 활성화하고 MountFlags=slave를 설정하면 문제가 해결될 수 있습니다. Docker도 1.13으로 업데이트하겠습니다.)

vsheffer 에 2017년 02월 02일

이 문제를 해결하려는 사람은 위의 @ravilr 의 의견을 볼 수 있으며 자세한 내용은 아래에서 확인할 수 있습니다.

모든 경우에 제거되는 컨테이너의 devicemapper 씬풀 장치 마운트 지점이 MountFlag=private/slave로 시작되는 호스트에 있는 다른 pid의 마운트 네임스페이스로 누출되었습니다.

ntpd.service는 RHEL에서 PrivateTmp=true로 시작됩니다.
systemd-udevd 서비스는 RHEL에서 MountFlags=slave로 시작됩니다.
컨테이너 삭제가 실패한 호스트에서 이러한 프로세스 중 하나는 해당 컨테이너 시작 시간 이후에 다시 시작되었습니다.

either of these processes were restarted after the corresponding container start time. 가 핵심이고, "tmp"와 같은 일부 디렉토리의 파일은 docker 컨테이너뿐만 아니라 다른 네임스페이스에서 사용하므로 docker가 강제로 파일을 종료할 수 없습니다.
다시 시작된 프로세스를 중지하거나 시스템 매개변수 PrivateTmp=true 를 false로 설정하고 다시 시작하여 이 문제를 해결할 수 있습니다.

참조: https://www.freedesktop.org/software/systemd/man/systemd.exec.html

KevinTHU 에 2017년 02월 03일

@KevinTHU 어쩌면 내가 당신의 의견을 오해하고 있습니다.

그러나 내 경우(우분투 14.04) 이 문제를 해결하기 위해 해야 할 일은 도커 서비스 자체를 다시 시작하는 것입니다.
( service docker restart ). "ntpd.service" 또는 "systemd-udevd 서비스"가 관련되어 있지 않습니다.

그게 말이 됩니까?

quexer 에 2017년 02월 08일

@quexer 물론 docker를 다시 시작하면 이 문제를 해결할 수 있지만 모든 컨테이너도 다시 시작되므로 프로덕션 환경에서는 비용이 너무 많이 듭니다.

KevinTHU 에 2017년 02월 08일

👍6

@KevinTHU 다시 시작 고정 표시기 서비스는 실행중인 모든 컨테이너에 영향을주지 않습니다. 직접 시도해 볼 수 있습니다.

quexer 에 2017년 02월 09일

👎2

@quexer 구성에 따라 다릅니다. 하지만 --live-restore 모드로 실행 중인 컨테이너를 그대로 두면 문제가 해결되지 않을 수 있습니다.
기본적으로 Docker는 종료 시 모든 컨테이너를 중지한 다음 백업할 때 무언가가 있으면 컨테이너도 종료합니다.

cpuguy83 에 2017년 02월 09일

@cpuguy83 @KevinTHU 죄송합니다. 제 잘못입니다. 맞습니다. docker를 다시 시작하면 모든 컨테이너가 다시 시작됩니다.

quexer 에 2017년 02월 13일

이제 갑자기 내 VM 중 하나에서 정기적으로 이것을 얻고 있습니다. 흥미롭게도 그 중 하나는 8시간 이상 방치한 후에 삭제할 수 있게 되었습니다. 내 정보는 다음과 같습니다.

rlpowell@vrici> sudo docker info
Containers: 15
 Running: 3
 Paused: 0
 Stopped: 12
Images: 155
Server Version: 1.12.6
Storage Driver: devicemapper
 Pool Name: docker-253:0-2621441-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 24.5 GB
 Data Space Total: 107.4 GB
 Data Space Available: 24.28 GB
 Metadata Space Used: 29.57 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.118 GB
 Thin Pool Minimum Free Space: 10.74 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.135 (2016-09-26)
Logging Driver: journald
Cgroup Driver: systemd
Plugins:
 Volume: local
 Network: host bridge null overlay
 Authorization: rhel-push-plugin
Swarm: inactive
Runtimes: oci runc
Default Runtime: oci
Security Options: seccomp selinux
Kernel Version: 4.9.0-0.rc1.git4.1.fc26.x86_64
Operating System: Fedora 26 (Server Edition)
OSType: linux
Architecture: x86_64
Number of Docker Hooks: 2
CPUs: 4
Total Memory: 8.346 GiB
Name: vrici.digitalkingdom.org
ID: JIIS:TCH7:ZYXV:M2KK:EXQH:GZPY:OAPY:2DJF:SE7A:UZBO:A3PX:NUWF
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://registry.access.redhat.com/v1/
Insecure Registries:
 127.0.0.0/8
Registries: registry.access.redhat.com (secure), docker.io (secure)

rlpowell 에 2017년 02월 14일

그리고 또 고장났습니다.

rlpowell 에 2017년 02월 15일

👍3

이것이 관련이 있는지 모르지만 /var/log/messages에는 다음이 있습니다.

2월 14일 16:58:49 vrici 커널: dev_remove: 40개의 콜백이 억제됨
2월 14일 16:58:54 vrici 커널: dev_remove: 40개의 콜백 억제
2월 14일 16:58:59 vrici 커널: dev_remove: 40개 콜백 억제

현재 오류는 다음과 같습니다.

데몬의 Busdef89 오류 응답: 드라이버 devicemapper가 루트 파일 시스템 b265eec88a6d1220eab75391bcf4f85bcd687301bfabfa3a2331217918c7377e: dd81b83c879f4bcef81 제거 실패

rlpowell 에 2017년 02월 15일

장치가 어딘가에서 사용 중입니다. 실패 후 다음 스크립트를 시도하고 장치가 사용 중일 수 있는 위치를 확인할 수 있습니까?

https://github.com/rhvgoyal/misc/blob/master/find-busy-mnt.sh

./find-busy-mnt.sh

./find-busy-mnt.sh dd81b82c875f4bcef819be83e9344c507965a9e9f48189f08c79fde5a9bde681

rhvgoyal 에 2017년 02월 16일

rlpowell@vrici> sudo bash /tmp/find-busy-mnt.sh b2205428f34a0d755e7eeaa73b778669189584977c17df2bf3c3bf46fe98be10
pid를 찾을 수 없습니다.
rlpowell@vrici> sudo 도커 rm freq_build
데몬의 Bus5abac8 오류 응답: 드라이버 devicemapper가 루트 파일 시스템 b2205428f34a0d755e7eeaa73b778669189584977c17df2bf3c3bf46fe98be10: 장치 5f1095868bbfe25를 제거하지 못했습니다.

rlpowell 에 2017년 02월 20일

오, 그것은 잘못된 해시였던 것 같습니다.

rlpowell@vrici> mount | grep b2205428f34a0d755e7eeaa73b778669189584977c17df2bf3c3bf46fe98be10
rlpowell@vrici> sudo bash /tmp/find-busy-mnt.sh 5f1095868bbfe85afccf392f6f4fbb8ed4bcfac88a5a8044bb122463b765956a
PID     NAME            MNTNS
12244   php-fpm         mnt:[4026532285]
12553   php-fpm         mnt:[4026532285]
12556   php-fpm         mnt:[4026532285]
12557   php-fpm         mnt:[4026532285]
12558   php-fpm         mnt:[4026532285]
rlpowell@vrici> pg php-fpm
rlpowell 25371 10518  0 00:43 pts/9    00:00:00  |           \_ grep --color=auto php-fpm
root     12244     1  0 00:08 ?        00:00:00 php-fpm: master process (/etc/php-fpm.conf)
apache   12553 12244  0 00:08 ?        00:00:00  \_ php-fpm: pool www
apache   12556 12244  0 00:08 ?        00:00:00  \_ php-fpm: pool www
apache   12557 12244  0 00:08 ?        00:00:00  \_ php-fpm: pool www
apache   12558 12244  0 00:08 ?        00:00:00  \_ php-fpm: pool www
rlpowell@vrici> sudo service php-fpm stop
Redirecting to /bin/systemctl stop  php-fpm.service
rlpowell@vrici> sudo bash /tmp/find-busy-mnt.sh 5f1095868bbfe85afccf392f6f4fbb8ed4bcfac88a5a8044bb122463b765956a
No pids found
rlpowell@vrici> sudo docker rm freq_build
freq_build

그것은 ... 매우 이상합니다. 왜 완전히 관련이 없는 php-fpm 프로세스가 해당 마운트를 열린 상태로 유지하기 위해 커널에서 볼 수 있는지 모르겠습니다.

rlpowell 에 2017년 02월 20일

@rlpowell 예, 이것이 이 문제의 전체 문제입니다. 마운트 네임스페이스가 제대로 작동하지 않는 문제가 있습니다.

SEAPUNK 에 2017년 02월 20일

여기에서 작동하는 해결 방법으로 보이는 것을 찾았습니다. http://blog.hashbangbash.com/2014/11/docker-devicemapper-fix-for-device-or-resource-busy-ebusy/

이것은 기본적으로 systemd docker.service 파일에 다음 줄을 추가하는 것을 의미합니다.
MountFlags=비공개

이것은 적어도 배포 이후에 수행한 도커 실행의 작은 샘플에서는 작동하는 것 같습니다. 도커를 완전히 이해하는 사람이 이 플래그의 결과를 설명할 수 있다면 좋을 것입니다. 도커가 시작된 후 마운트된 파일 시스템이 컨테이너에서 사용 가능하지 않을 수 있다고 생각하지만 솔직히 모르겠습니다. 우리의 구성은 빌드 서버에서 사용하기 위한 것이며 제대로 작동하는 것 같습니다.

pyssling 에 2017년 02월 25일

이것은 꽤 중요한 문제로 Centos 7/RHEL에서 도커를 효과적으로 사용할 수 없게 만듭니다. (그리고 4개월 동안 열려 있습니까?)
도착 예정 시간이 있습니까?

paulwilton 에 2017년 02월 28일

👍8

최신 RHEL/centos는 docker.service 파일에 MountFlags=slave와 함께 제공되어야 합니다.

rhvgoyal 에 2017년 02월 28일

@rhvgoyal 이것은 그렇지 않습니다: https://github.com/docker/docker/blob/master/contrib/init/systemd/docker.service.rpm

이것은 브랜치 마스터에 있지만 브랜치 1.13.x 및 17.03.x에도 없습니다.

내가 말할 수 있는 한 이 플래그는 이전 서비스 단위에 있었지만 제거되었습니다. 그러나 나는 그 이유를 찾지 못했습니다. 이 플래그는 현재 문제를 해결하지만 다른 문제를 일으킬 수 있습니다.

jcberthon 에 2017년 03월 02일

@rlpowell @SEAPUNK 내 우분투 설치의 경우가 아닌 것 같습니다.

$ docker rm test
Error response from daemon: Driver devicemapper failed to remove root filesystem f23064c71f22215f8cc7c7192488ab1bbb24693b36e07018b32d58292ee6ce47: Device is Busy
$ sudo ./find-busy-mnts.sh f23064c71f22215f8cc7c7192488ab1bbb24693b36e07018b32d58292ee6ce47
No pids found

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"

$ docker version
Client:
 Version:      1.13.1
 API version:  1.26
 Go version:   go1.7.5
 Git commit:   092cba3
 Built:        Wed Feb  8 06:50:14 2017
 OS/Arch:      linux/amd64

Server:
 Version:      1.13.1
 API version:  1.26 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   092cba3
 Built:        Wed Feb  8 06:50:14 2017
 OS/Arch:      linux/amd64
 Experimental: false

$ docker info
Containers: 17
 Running: 14
 Paused: 0
 Stopped: 3
Images: 148
Server Version: 1.13.1
Storage Driver: devicemapper
 Pool Name: ubuntu--vg-thinpool
 Pool Blocksize: 524.3 kB
 Base Device Size: 10.74 GB
 Backing Filesystem: ext4
 Data file: 
 Metadata file: 
 Data Space Used: 29.3 GB
 Data Space Total: 386.5 GB
 Data Space Available: 357.2 GB
 Metadata Space Used: 16.97 MB
 Metadata Space Total: 4.295 GB
 Metadata Space Available: 4.278 GB
 Thin Pool Minimum Free Space: 38.65 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: true
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Library Version: 1.02.110 (2015-10-30)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: aa8187dbd3b7ad67d8e5e3a15115d3eef43a7ed1
runc version: 9df8b306d01f59d3a8029be411de015b7304dd8f
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-62-generic
Operating System: Ubuntu 16.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 15.56 GiB
Name: martin
ID: W4KC:COLM:3G33:I54E:PNUD:A5XX:TEBZ:VG43:BR62:JWCU:B44Y:DQWJ
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
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

smoebody 에 2017년 03월 02일

RHEL7이 RHEL7.4까지 --live-restore를 지원할 수 없는 이유와 도커가 호스트가 아닌 다른 마운트 네임스페이스 내에서 실행되어야 하는 이유를 설명하는 기사를 작성했습니다.

https://access.redhat.com/articles/2938171

rhatdan 에 2017년 03월 02일

❤6 👍1

+1 다른 마운트 네임스페이스로 실행하고 모든 도커 마운트를 비공개로 만들고 싶습니다.
하지만 거기에 약간의 까다로운 비트가 있습니다.

cpuguy83 에 2017년 03월 02일

업스트림 도커에 MountFlags=slave 에서 실행하기 위한 적절한 플래그가 없는 경우 이는 버그이며 컨테이너와 호스트 간에 누출되는 마운트 네임스페이스 문제를 쉽게 유발하고 컨테이너 이미지를 제거하는 데 문제가 발생할 수 있습니다.

rhatdan 에 2017년 03월 02일

FWIW, Red Hat 유지 관리자가 검토한 후 MountFlags=slave 가 https://github.com/docker/docker/pull/22806 에서 제거되었지만 문제를 일으키는 것 같으므로 되돌려야 하는지 궁금합니다. RHEL7.4까지?

thaJeztah 에 2017년 03월 02일

예, 우리는 그것을 제거했고 나중에 문제를 일으켰습니다. 그래서 토론 스레드 중 하나에서 우리는 그것을 다시 도입하자는 결론을 내렸습니다. 나는 당신이 이미 그것을 했다고 생각했습니다. 어떤 스레드였는지 기억나지 않습니다.

rhvgoyal 에 2017년 03월 02일

@thaJeztah 예, 우리가 잘못 알고 추가 문제를 발견했습니다.

rhatdan 에 2017년 03월 02일

그리고 이러한 문제는 주로 이전 커널에만 해당되었습니다. 최신 커널은 잘 작동합니다.

rhvgoyal 에 2017년 03월 02일

PR을 열어 옵션에 대해 논의하겠습니다.

thaJeztah 에 2017년 03월 02일

여기에서 PR을 열었습니다. https://github.com/docker/docker/pull/31490

thaJeztah 에 2017년 03월 02일

동일한 문제, docker 1.10.3, CentOS Linux 릴리스 7.2.1511
dmesg:
[1732917.246900] device-mapper: ioctl: 열려 있는 장치를 제거할 수 없습니다. docker-8:3-5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef7486
메시지:
4월 3일 03:32:34 A02-R05-I97-106 docker-current: time="2017-04-03T03:32:34.346374677+08:00" level=error2ceea4677+08:00" level=error31c0a4a msg="장착된 레이어 제거 오류 b0b1e839f366086f "
4월 3일 03:32:34 A02-R05-I97-106 docker-current: time="2017-04-03T03:32:34.346597095+08:00" level=error msg="DELETE /v1.22/containers 처리기 /b0b1e839f366086fd7cff564feee385a3aed71a56db90e4c0416517a72c13f2d 반환된 오류: 드라이버 devicemapper가 루트 파일 시스템 b0b1e839f366086fd7cff564fea5를 제거하지 못했습니다.

산:
/proc/*/mounts 찾기 | xargs grep -E "5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78"
은 / proc / 159,779 / 마운트 / 디바이스 / 매퍼 / 고정 표시기-8-3-5242884 b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 / 수출 / 고정 표시기 / devicemapper / MNT / b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 XFS RW, relatime 옵션, nouuid, ATTR2, inode64, logbsize = 64K, sunit = 128 너비=128, 할당량 없음 0 0
은 / proc / 159,806 / 마운트 / 디바이스 / 매퍼 / 고정 표시기-8-3-5242884 b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 / 수출 / 고정 표시기 / devicemapper / MNT / b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 XFS RW, relatime 옵션, nouuid, ATTR2, inode64, logbsize = 64K, sunit = 128 너비=128, 할당량 없음 0 0
새 컨테이너 ：
도커 검사 8777d36c94ec|grep Pid
"피드": 159779,

//내 잘못, 해결했습니다 。

foxwang 에 2017년 04월 05일

ID "8777d36c94ec"는 무엇입니까? 이것은 제거되는 컨테이너의 컨테이너 ID입니까 아니면 다른 컨테이너입니까?

따라서 장치는 여전히 컨테이너에 탑재되어 있으므로 사용 중입니다. 따라서 제거되는 컨테이너 중 하나가 아직 중지되지 않았습니다. 또는 다른 컨테이너인 경우 다른 컨테이너에서 보이지 않아야 합니다.

마운트 지점 "/export/docker/devicemapper/mnt/...."가 무엇이며 누가 생성했는지 확실하지 않습니까?

rhvgoyal 에 2017년 04월 05일

내 Mint 시스템에서 17.03.1~ce-0~ubuntu-xenial 에서 17.04.0~ce-0~ubuntu-xenial 로 업그레이드하면 이 문제가 매우 자주 발생합니다.

업그레이드하기 전에 나는 그것을 만난 적이 없습니다. 업그레이드 후에는 매우 빈번했습니다. 17.03.1로 다시 다운 그레이드하면 해결 된 것 같습니다.

bmbroom 에 2017년 04월 14일

이 스레드를 읽는 다른 사람들을 위한 참고 사항으로 Google에서 cAdvisor를 실행 중인 경우 컨테이너를 제거하려고 할 때 이 문제가 표시됩니다. 먼저 cAdvisor를 중지한 다음 컨테이너를 제거한 다음 cAdvisor를 다시 시작해야 합니다.

jmwilkinson 에 2017년 04월 18일

👍3

@bmbroom 마찬가지 입니다. 우리는 하루 종일 컨테이너를 휘젓는 우분투 기반 빌드 서버를 실행하며(보통 docker-compose에 의해 구동됨) 이 문제를 일주일에 두 번 보았습니다. 서버는 신뢰할 수 있는 서버와 xenial 서버가 혼합되어 있습니다. 최근에 17.04.0~ce로 업그레이드를 시작했으며 현재 하루에도 여러 번 이러한 일이 발생하고 있습니다.

MountFlags=slave가 우분투에 적용 가능한지 확실하지 않지만 그것이 다음에 시도하는 것입니다.

ansel1 에 2017년 04월 19일

@rhvgoyal
미안하다，내 잘못이다。
다른 사람들은 여전히 내 컨테이너에 탑재되어 있습니다.。

foxwang 에 2017년 04월 21일

다음에서 동일한 문제가 발생했습니다.

docker: Docker 버전 17.03.1-ce, 빌드 c6d412e
os: Red Hat Enterprise Linux Server 릴리스 7.3(Maipo)
커널: 3.10.0-514.6.1.el7.x86_64
ntpd: 4.2.6p5

systemctl restart ntpd 수행하면 문제가 즉시 해결되었습니다.

xeor 에 2017년 04월 21일

👍11 😄4 ❤2 🎉2

@제오르
docker.service 단위 파일 안에 있는 MountFlags 무엇입니까?

sfwn 에 2017년 04월 23일

/usr/lib/systemd/system/docker.service 파일에 MountFlags 가 없지만 systemctl show docker 는 MountFlags=0 보여줍니다.

ntpd.service 마찬가지입니다. 또한 것을 PrivateTmp=true 세 이하 [Service] D 자 (있는 경우 그 문제를).

xeor 에 2017년 04월 24일

지금은 MountFlags=slave로 실행하십시오.

rhvgoyal 에 2017년 04월 24일

@rhvgoyal이 내 docker.service 파일을 확인했습니다. 그러나 귀하의 가치는 이미 설정되어 있습니다.

grep MountFlags /etc/systemd/system/multi-user.target.wants/docker.service
MountFlags=slave

최신 redhat(3.10.0-514.16.1.el7)/docker(1.12.6-16.el7) 사용

MountFlags=private는 어떻습니까? 개인과 노예의 차이점을 설명할 수 있습니까?

phhutter 에 2017년 04월 25일

현재 RHEL/CentOS 7.3, 커널 3.10.0-514.16.1.el7.x86_64, Docker 버전 17.05.0-ce, 빌드 89658be에서 이 문제를 보고 있습니다. 우리는 지난 1년 동안 이 문제를 계속해서 보아왔습니다.

/etc/systemd/system/multi-user.target.wants/docker.service에도 MountFlags 옵션이 없습니다. 거기에 "MountFlags=slave"를 추가해야 합니까?

esabol 에 2017년 05월 24일

이 문제가 Centos, RHEL 및 Ubuntu에서 발생한다는 의견이 있습니다. Debian이나 ContainerLinux 또는 SUSE와 같은 다른 운영 체제는 이 특정 문제로부터 안전합니까?

ghost 에 2017년 06월 16일

@earwax 최신 커널(>= 3.15)이 있는 모든 것이 일반적으로 더 잘 작동합니다.
그러나 이 오류가 발생할 수 있는 상황은 항상 있습니다.
또한, 이를 완화하기 위해 여기 주석에 몇 가지 방법이 나열되어 있습니다.

cpuguy83 에 2017년 06월 16일

SUSE에서 이 문제를 보았지만 해결 방법을 찾을 수 없었습니다...대부분 공급자에서 발생하는 것으로 보입니다: AZURE

prachi02 에 2017년 06월 19일

dockerd를 1.12.6에서 17.05로 업데이트할 때도 이 문제를 발견했습니다. 모든 오래된 컨테이너는 '-f' 없이 삭제할 수 없습니다. 이러한 컨테이너에는 '--live-restore' 구성이 있기 때문에 dockerd를 업데이트할 때 모두 중지되지 않는 공통 기능이 있었습니다. 여기에 문제가 있다고 생각합니다.

KevinTHU 에 2017년 06월 26일

이것은 참고로 적어도 CentOS 7에서는 17.06에서 여전히 문제입니다.

MGD1981 에 2017년 07월 03일

👍6

@MGD1981 이 버그를 수정해야 합니다. 우리는 centos 7을 동일하게 사용하고 있으며 docker를 업데이트하기 전에 생성된 이전 컨테이너에는 "장치가 사용 중" 문제가 있을 뿐만 아니라 새로 생성된 컨테이너에도 문제가 있다는 것을 알았습니다. 이것은 정말 중요합니다. , 그리고 docker.service에 "MountFlags=slave"를 추가하여 해결합니다. 그러나 이 매개변수가 다른 문제를 일으킬지 여부는 알 수 없습니다.

KevinTHU 에 2017년 07월 04일

예, 지금 QA 환경에서 이것을 시도하고 있습니다. 세심한 주의를 기울일 것
마운트에. 컨테이너의 FS가
이 설정을 사용하면 시간이 지남에 따라 호스트가 디스크로 "잊혀짐"
죽은 컨테이너?

2017년 7월 3일 월요일 오후 10시 38분 KevinTHU [email protected]이(가) 작성했습니다.

@MGD1981 https://github.com/mgd1981 이 버그를 수정해야 합니다.
centos 7을 동일하게 사용하고 우리는 오래된 컨테이너뿐만 아니라
도커를 업데이트하기 전에 생성된 "장치 사용 중" 문제가 있지만
새로 생성된 컨테이너, 이것은 정말 중요하며 다음과 같이 해결합니다.
docker.service에 "MountFlags=slave"를 추가합니다. 그러나 우리는 날씨를 모른다
이 매개변수는 다른 문제를 가져올 것입니다.
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/moby/moby/issues/27381#issuecomment-312766596 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ADzZzStBbgubPK4soa2w5WW_hthYnZwjks5sKaW2gaJpZM4KW5Fn
.

MGD1981 에 2017년 07월 04일

@MGD1981 예, 호스트에 더 이상 사용되지 않는 디스크가 있는 것 같습니다. #33025 참조

ceecko 에 2017년 07월 04일

@ceecko 이것은 17.06부터 더 이상 발생하지 않습니다. 그러나 지연된 제거/삭제를 활성화하면 즉시 정리되지 않을 수 있습니다.

cpuguy83 에 2017년 07월 04일

@cpuguy83 좋아요 ! 이전 버전에서 남겨둔 오래된 디스크도 정리합니까?

ceecko 에 2017년 07월 04일

@cpuguy83 은 17.06이 아직 출시되었나요? (이미 7월이므로 17.07?) github 릴리스 페이지에서 찾을 수 없습니다.

ravilr 에 2017년 07월 05일

@ravilr 종료 되었습니다. 릴리스는 github.com/docker/docker-ce에서 제공됩니다.

@ceecko 저는 그렇게 생각하지 않습니다.

cpuguy83 에 2017년 07월 05일

@cpuguy83 감사합니다. 17.06의 릴리스 정보에는 이 문제와 관련된 사전 수정 사항이 언급되어 있지 않은 것 같습니다. 이 문제를 해결하기 위한 수정 사항은 무엇이었습니까? 다시 한번 감사합니다.

ravilr 에 2017년 07월 06일

@ravilr 이 홍보 https://github.com/moby/moby/pull/31012

thaJeztah 에 2017년 07월 06일

저는 CentOS 7(가상 풀 스토리지 포함)에서 17.06.0-ce를 실행 중이며 최근에 많이 발생하고 있습니다.

+ docker rm -f jenkins-build_rcc_testrun-1945
Error response from daemon: driver "devicemapper" failed to remove root filesystem for d626082dffb7c52fa8c012a2de3b113e431d1bdbc834084654051900e9482f23: failed to remove device 01c54a8701901f7fcb096e61b9028665df7f0596a0ad01d8ce0cd88215959d14: Device is Busy
Build step 'Execute shell' marked build as failure

AaronDMarasco-VSI 에 2017년 07월 07일

MountFlags=slave , @AaronDMarasco-VSI 가 있거나 없는 것입니까? 센트OS 7.3?

esabol 에 2017년 07월 07일

17.06은 근본적인 문제를 해결하지 않고 처리하는 것이 더 좋습니다.
문제를 악화시키는 도커(또는 containerd와 같은 일부 하위 구성요소)가 수행하는 작업이 있는지 살펴보고 있습니다.

cpuguy83 에 2017년 07월 07일

@esabol 아니... 비공개?

docker.service.d$ cat * | grep -v '^#'
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd --exec-opt native.cgroupdriver=cgroupfs --storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/vg_ex-docker--pool --storage-opt dm.use_deferred_removal=true

[Unit]
After=lvm2-lvmetad.socket lvm2-activation.service lvm2-lvmetad.service

[Service]
MountFlags=private

docker.service.d$ cat /etc/redhat-release 
CentOS Linux release 7.3.1611 (Core)

AaronDMarasco-VSI 에 2017년 07월 07일

@AaronDMarasco-VSI, 상황을 개선한 MountFlags=slave 변경하는 것이 좋습니다. 하지만 아직 17.05이고 사용하고 싶지 않은 곳을 본 것 같습니다. MountFlags=slave 와 dm.use_deferred_removal ? 아마도 다른 사람이 댓글을 달고 확인할 것입니다.

esabol 에 2017년 07월 08일

centos 7.3 및 커널 4.10에서 docker 17.03을 사용하고 있습니다. 그리고 나는이 오류를 많이 보았습니다. 아래는 MountFlag에 대한 몇 가지 자세한 내용입니다.

# systemctl show docker | grep Private
PrivateTmp=no
PrivateNetwork=no
PrivateDevices=no
# systemctl show docker | grep Mount
MountFlags=0

pntailor 에 2017년 07월 13일

👍2

여기 Debian 8과 동일한 문제가 있습니다. CI가 깨지고 가능한 해결 방법이 있습니까?

thg303 에 2017년 07월 16일

@thg303 가능하면 dockerdeamon을 종료하고 로그 파일(rm /var/lib/docker/.....)에서 발생하는 루트 파일 시스템을 정리/제거하십시오. 하지만 그 전에 스냅샷/백업을 해야 합니다 :-)

phhutter 에 2017년 07월 16일

Fedora 25, 커널 4.11.12에서도 동일한 문제가 발생합니다.

Containers: 5
 Running: 0
 Paused: 0
 Stopped: 5
Images: 16
Server Version: 17.06.0-ce
Storage Driver: devicemapper
 Pool Name: docker-253:2-5373989-pool
 Pool Blocksize: 65.54kB
 Base Device Size: 21.47GB
 Backing Filesystem: xfs
 Data file: /dev/loop1
 Metadata file: /dev/loop2
 Data Space Used: 59.33GB
 Data Space Total: 107.4GB
 Data Space Available: 48.05GB
 Metadata Space Used: 76.11MB
 Metadata Space Total: 2.147GB
 Metadata Space Available: 2.071GB
 Thin Pool Minimum Free Space: 10.74GB
 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.136 (2016-11-05)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: cfb82a876ecc11b5ca0977d1733adbe58599088a
runc version: 2d41c047c83e09a6d61d464906feb2a2f3c52aa4
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.11.12-200.fc25.x86_64
Operating System: Fedora 25 (Workstation Edition)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.703GiB
Name: wayland
ID: 3T2X:CMFA:53Y2:27FL:RBMD:FHMH:32QE:2DKL:L256:O2GJ:LT2X:N4DD
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Http Proxy: http://127.0.0.1:8118/
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: devicemapper: usage of loopback devices is strongly discouraged for production use.
         Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.

jacknlliu 에 2017년 08월 06일

centos7에서 도커가 업데이트될 때마다 이 문제가 발생했습니다. 도커를 다시 시작하면 모든 것이 잘 작동합니다.

sandrodz 에 2017년 08월 16일

Docker 17.06.0-ce가 있는 Fedora 26에서도 마찬가지입니다. 도커를 다시 시작해도 문제가 해결되지 않았습니다.

$ systemctl show docker | grep Private
PrivateTmp=no
PrivateDevices=no
PrivateNetwork=no
PrivateUsers=no
$ systemctl show docker | grep Mount
MountFlags=0
MountAPIVFS=no

giovtorres 에 2017년 08월 18일

1년이 지난 지금 이 버그가 여전히 존재합니까?

NeckBeardPrince 에 2017년 09월 06일

👎5 👍1

@NeckBeardPrince 이런 무의미한 댓글로 시간낭비하지
문제를 해결하는 데 도움이 되었으면 합니다. 문제에 대한 추가 데이터를 보고하고 싶다면 좋습니다.

그 외에도 여기에 게시된 이 문제를 해결하는 몇 가지 방법이 있습니다.

cpuguy83 에 2017년 09월 06일

😄4 👎1

systemd 단위 파일은 MountFlags=slave 와 함께 제공되지 않습니다.

Server Version: 17.06.1-ce
CentOS Linux release 7.3.1611 (Core)

[root<strong i="7">@dokken</strong> /]# systemctl show docker | grep Private
PrivateTmp=no
PrivateNetwork=no
PrivateDevices=no
[root<strong i="8">@dokken</strong> /]# systemctl show docker | grep Mount
MountFlags=0

chasebolt 에 2017년 09월 06일

지난번에 이 문제가 발생했을 때 마운트를 잡고 있던 것은 ntpd 였습니다.
오늘도 같은 문제가 발생했는데 이번에는 호스트에서 실행 중인 mariadb 인스턴스가 원인이었습니다.

docker-engine-17.05.0.ce-1.el7.centos.x86_64
mariadb-서버-5.5.56-2.el7.x86_64

마운트를 들고 있는 프로시저를 찾는 예....

# container with the problem
docker rm efad7...
Error response from daemon: Driver devicemapper failed to remove root filesystem efad7...: remove /var/lib/docker/devicemapper/mnt/9bd66290ee...: device or resource busy

# Grep after parts of the mountpoint
grep docker /proc/*/mountinfo | grep 9bd66290ee
/proc/9736/mountinfo:776 427 253:24 / /var/lib/docker/devicemapper/mnt/9bd66290e...
/proc/9910/mountinfo:776 427 253:24 / /var/lib/docker/devicemapper/mnt/9bd66290e...

# Find who the pid's belongs to
ps aux | grep -E "9736|9910"
mysql     9736  0.0... /usr/bin/mysqld_safe --basedir=/usr
mysql     9910  9.8 ... /usr/libexec/mysqld --base...

# Do some extra research on one of the pids
grep docker /proc/9736/mountinfo | wc -l
70

grep docker /proc/9736/mountinfo | grep -o "/run/docker/netns/" | wc -l
17

grep docker /proc/9736/mountinfo | grep -o "/var/lib/docker/containers/" | wc -l
18

grep docker /proc/9736/mountinfo | grep -o "/var/lib/docker/devicemapper/mnt/" | wc -l
33

mariadb를 다시 시작한 후 마운트 포인트를 해제했지만 시작할 때 마운트 포인트를 많이 잡았습니다.

grep docker /proc/16367/mountinfo | wc -l
52

xeor 에 2017년 09월 08일

👍5 🚀1

대부분의 제거 실패는 마운트 지점(따라서 device)이 다른 마운트 네임스페이스에서 사용 중이기 때문에 발생합니다. 커널이 충분히 새롭다면 제안된 PR을 따르면 이 문제를 해결하는 데 도움이 될 것이라고 생각합니다.

https://github.com/moby/moby/pull/34573

이전 커널을 실행 중인 경우 마운트 누수 문제를 줄이기 위해 플러그인 호출 oci-umount를 작성했습니다.

https://github.com/projectatomic/oci-umount

rhvgoyal 에 2017년 09월 08일

@rhvgoyal 이 PR을 포함할 docker 릴리스에 대한 계획이 있습니까? 우리는 여전히 정기적으로 driver "devicemapper" failed to remove root filesystem 를 처리하고 있습니다.

bjonen 에 2017년 10월 13일

👍5

CentOS Linux 릴리스 7.4.1708(코어)
3.10.0-693.5.2.el7.x86_64
17.06.2-ce

마침내 수정된 것 같습니다

fitz123 에 2017년 10월 24일

Docker 버전 17.09.0-ce를 실행 중이며 여전히 동일한 문제에 직면하고 있습니다.

bjonen 에 2017년 10월 25일

Oracle Linux에서 이 문제가 가끔 발생합니다. docker 버전 17.03.1-ce(Oracle 저장소에서)

Linux server 4.1.12-103.3.8.1.el7uek.x86_64 #2 SMP Fri Sep 15 17:23:08 PDT 2017 x86_64 x86_64 x86_64 GNU/Linux

위의 내용은 모두 프로젝트의 TDA에 의해 수정되었으므로 당분간 변경할 수 없습니다.

다른 환경의 90%는 Centos 7.3/7.4이며 여기서 문제가 발생하지 않습니다.

the-nw1-group 에 2017년 10월 27일

4.11.9의 아치 Linux에서 Docker 17.05로 이 문제의 인스턴스를 해결했습니다.
~에 의해

docker rm -f [myContainer] (평소와 같이 driver "devicemapper" failed to remove root filesystem 실패)
ls /var/lib/docker/devicemapper/mnt/

이로 인해 컨테이너가 마침내 사라졌습니다(왜 그런지는 확실하지 않음).

JulianKlug 에 2017년 10월 29일

👍10

@MonsieurWave가 보기 에는 믿기지 않을 만큼, "ls" 트릭은 다른 모든 것이 작동하지 않았을 때 완벽하게 작동했습니다!

Xophe 에 2017년 11월 03일

docker rm -f [container] 는 실패를 보고하지만 결국에는 컨테이너와 파일 시스템을 정리합니다. ls 명령은 붉은 청어이므로 몇 초만 기다리면 됩니다. 그러나 그보다 더 나은 방법은 MountFlags=slave 를 사용하는 것입니다. 그리고 가장 좋은 방법은 devicemapper를 끄고 대신 overlay2를 사용하는 것입니다.

bmitchboxboat 에 2017년 11월 03일

👍2 😕1

그리고 가장 좋은 방법은 devicemapper를 끄고 대신 overlay2를 사용하는 것입니다.

우리는 1년 넘게 CentOS 7.x(현재 7.4)에서 Docker를 사용해 왔습니다. Docker를 처음 설치했을 때 모든 사람은 최고의 성능과 안정성을 위해 direct-lvm과 함께 devicemapper를 사용해야 한다고 말했습니다. https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/는 여전히 Docker EE와 함께 CentOS에서 devicemapper를 사용해야 한다고 말합니다. 다행히도 Docker CE를 사용하므로 오버레이2로 전환할 수 있습니다. Docker 사람들이 v1.13.0/1에서 CentOS의 devicemapper에서 overlay2로의 기본값 변경에 약간의 팡파르나 토론이 있는 것처럼 느껴집니다. CentOS 7에서 오버레이2 대 devicemapper(direct-lvm)의 성능/안정성에 대한 확실한 정보가 있습니까? 내 구글링은 많이 찾지 못했다....

esabol 에 2017년 11월 04일

우리는 재고 CentOS 7.2 커널(3.10.x frankenstein)과 함께 아주 나쁜 시간을 보냈습니다. 많은 충돌. 우리는 개발 환경에서 Kubernetes를 실행하고 있었기 때문에 컨테이너 변동이 매우 높았지만 비교적 조용한 설치에서도 기본 CentOS + 오버레이 콤보가 매우 불안정하다는 것을 알았습니다. 오버레이2로 4.10+ 업스트림 커널을 실행하는 것이 훨씬 좋습니다. 최신 CentOS 릴리스를 시도하지 않았습니다.

ext4 또는 "-n ftype=1"로 포맷된 XFS인 기본 파일 시스템을 사용해야 합니다. 형식이 잘못된 XFS가 있는 경우 Docker가 실행되지만 결과는 예측할 수 없습니다.

rsanders 에 2017년 11월 04일

👍1

그래, 나는 오랫동안 overlay2 로 전환했고 , 이 문제를 제쳐두고 devicemapper가 일반적으로 docker에 대한 매우 열악한 스토리지 드라이버라는 것을 읽었기 때문에 오버레이2

SEAPUNK 에 2017년 11월 05일

ntpd를 다시 시작하면 문제가 해결되었습니다... 너무 혼란스럽습니다. Centos7의 도커에 대한 "권장" daemon.json 구성이 있습니까?

sharksforarms 에 2017년 11월 06일

👍2

몇 가지 개선 사항이 파이프라인을 따라오고 있습니다.

특히 이러한 다른 시스템 서비스의 문제는 마운트 네임스페이스 설정(다른 시스템 서비스용)과 자체 마운트를 비공개로 유지하려는 도커의 시도와 경쟁 조건인 것으로 보입니다. 컨테이너, 불행히도 다른 곳에서 누출을 일으키고 실제로 해당 마운트 지점에 대한 개인 참조를 보유하게 되므로 수동으로 또는 프로세스가 다시 시작될 때를 제외하고는 해당 네임스페이스에서 마운트 해제할 수 없습니다.

또한 runc와 docker 모두에서 MS_PRIVATE 마운트 전파를 사용하여 경쟁 조건을 처리하기 위한 몇 가지 최근 변경 사항이 있습니다.
다음 버전은 완벽할까요? 아마 아닐 겁니다... 하지만 저는 이것이 더 나아질 것으로 기대합니다.

cpuguy83 에 2017년 11월 06일

👍2

나는 docker 12.1.1을 사용하여 @ceecko 와 똑같은 것을 얻었습니다. 지금 업데이트할 기회가 없습니다. 나중에 어딘가에 수정됩니까? 빠른 수정은 프로세스를 종료하고 도커 서비스를 다시 시작하는 것이지만..

FelikZ 에 2017년 11월 14일

이 버전은 --live-restore 포함하여 문제를 완전히 해결합니다.

CentOS 7.4.1708 (3.10.0-693.5.2.el7.x86_64)
Docker 17.09.0-ce

fitz123 에 2017년 11월 14일

👍5

@esabol CentOS 7.4로 업그레이드한 후

참고: docker info 는 이 특정 옵션 없이 XFS를 통해 오버레이2를 실행하는 것은 지원되지 않으며 향후 릴리스에서 제거될 것이라는 큰 경고를 표시합니다.

jcberthon 에 2017년 11월 30일

https://github.com/moby/moby/pull/34573 수정 사항이 17.09.1-ce, 17.12.0-ce 버전에서 릴리스됨

srinivassurishetty 에 2018년 03월 01일

@jcberthon 우리는 최근에 총알을 docker run --rm 하는 단위 테스트의 벤치마크에서 성능이 40% 향상되었습니다. devmapper를 위한 마지막 빨대는 문제 #20401이었습니다. 오버레이2로 전환하는 것은 그리 어렵지 않았지만 디스크 여유 공간이 충분합니다. 저는 docker save 모든 이미지를 tarball로, 또 다른 스크립트를 docker load 모든 tarball에 작성했습니다. 우리는 2-3시간 만에 끝났다. 번거롭고 디스크 공간이 충분하지 않은 경우에 가능하지만 장기적으로 볼 때 가치가 있다고 생각합니다. 행운을 빕니다!

esabol 에 2018년 03월 01일

🎉2 👍2 ❤1

이것은 17.12.1에서 수정되었습니다.

감사합니다.

cpuguy83 에 2018년 03월 12일

👍5 ❤2 🎉2

수정 릴리스 전에 물리적 노드를 재부팅하면 문제가 해결됩니다.

elonmia 에 2018년 07월 11일

👍1

@ravilr @KevinTHU 귀하의 의견에 대해 https://github.com/moby/moby/issues/27381#issuecomment -277148106 및 https://github.com/moby/moby/issues/27381#issuecomment -267547259 관찰했습니다. RHEL의 도커 유닛 파일을 PrivateTmp=true 로 변경하면 문제도 해결됩니다. 비슷한 것을 본 적이 있습니까?

MohdAhmad 에 2018년 09월 05일

@MohdAhmad 는

KevinTHU 에 2018년 09월 19일

나는 같은 문제를 찾습니다. 폴더를 열었으니까 창을 닫아서 해결하세요.

libaojie 에 2019년 04월 18일

Moby: 드라이버 devicemapper가 루트 파일 시스템을 제거하지 못했습니다. 기기가 사용 중입니다.

가장 유용한 댓글

모든 153 댓글

관련 문제