Moby: Driver devicemapper falhou ao remover o sistema de arquivos raiz. Dispositivo está ocupado

Isso está acontecendo com algum contêiner? O que está sendo executado no contêiner e quais opções você usa para iniciar o contêiner? (por exemplo, você está usando diretórios montados em bind, está usando docker exec para iniciar processos adicionais no contêiner?)

Executamos todos os contêineres praticamente da mesma maneira e isso acontece aleatoriamente em qualquer um deles.
Não usamos docker exec , não faça bind-mount em nenhum diretório.
Aqui está a configuração de um dos contêineres mortos:

[
    {
        "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": ""
                }
            }
        }
    }
]

Acabei de notar que isso acontece apenas em servidores com este sistema de arquivos Backing Filesystem: ext4
O problema não parece ocorrer em servidores executando xfs como sistema de arquivos de apoio.

@ceecko obrigado, isso é interessante

@rhvgoyal esse é um problema conhecido do seu lado?

Isso nos atinge fortemente na produção: / Alguma dica de como remover os recipientes mortos?

@thaJeztah Estranho que isso aconteça apenas com ext4 e não com xfs. Não estou ciente de tal coisa.

Em geral, as pessoas relatam que o dispositivo está ocupado e pode haver muitos motivos para isso.

@ceeko antes de mais nada, certifique-se de que o docker daemon esteja rodando em um namespace de montagem escrava próprio e não em um namespace de montagem de host. Para que os pontos de montagem não vazem e as chances de obter tais erros sejam menores. Se você estiver usando um docker orientado pelo systemd, deve haver um arquivo da unidade docker e deve ter MountFlags = slave.

@rhvgoyal O MountFlags=slave parece resolver o problema até agora. Os contêineres criados antes da mudança ainda são um problema, mas os novos contêineres não parecem ter acionado o erro até agora. Entrarei em contato caso algo mude.

A propósito, pode valer a pena atualizar os documentos do driver de armazenamento para recomendar isso como uma prática recomendada na produção, já que não consegui encontrar nenhuma referência.

Obrigado pela ajuda.

Isso foi mudado há um tempo; https://github.com/docker/docker/commit/2aee081cad72352f8b0c37ba0414ebc925b022e8#diff -ff907ce70a8c7e795bde1de91be6fa68 (https://github.com/docker/docker/pull/22806), se esse problema for adiado, se a remoção for adiada não habilitado; https://github.com/docker/docker/pull/22806#issuecomment -220043409

Devemos alterar o padrão de volta? @rhvgoyal

@thaJeztah Acho que pode ser uma boa ideia alterar o padrão de volta para MountFlags = slave. Nós fizemos isso.

Idealmente, os recursos de remoção adiada e exclusão adiada deveriam ter cuidado disso e não havia necessidade de usar MountFlags = slave. Mas a exclusão adiada por si só não é suficiente. Os kernels antigos não possuem um recurso em que é possível remover um diretório de um namespace de montagem, mesmo se ele estiver montado em um namespace de montagem diferente. E esse é um dos motivos pelos quais a remoção do contêiner pode falhar.

Então, até que os kernels antigos ofereçam esse recurso, pode ser uma boa ideia executar o docker daemon em um namespace de montagem escrava.

@rhvgoyal os erros começaram a aparecer novamente mesmo com MountFlags=slave . Tentaremos a remoção adiada e a exclusão e entraremos em contato com você.

Acabamos de encontrar o mesmo erro em xfs também.
Aqui estão as informações do docker

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

Confirmo que o erro ainda ocorre em 1.12.2, mesmo com MountFlags=slave e dm.use_deferred_deletion=true e dm.use_deferred_removal=true , embora com menos frequência do que antes.

Aqui estão mais informações dos logs sobre 1 contêiner que não pôde ser removido:

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

A mensagem a seguir sugere que a remoção do diretório falhou.

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

E no kernel mais antigo, ele pode falhar porque o diretório está montado em algum outro namespace de montagem. Se você desabilitar o recurso deferred deletion , esta mensagem deixará de chegar. Mas isso se tornará alguma outra mensagem de erro.

O cerne da questão aqui é que o contêiner ainda está em execução ou alguns de seus pontos de montagem vazaram para outro namespace de montagem. E se pudermos descobrir em qual espaço de nomes de montagem ele vazou e como foi parar lá, podemos tentar consertá-lo.

Depois de se deparar com esse problema, você pode tentar find /proc/*/mounts | xargs grep "4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543"

E então veja quais pids têm montagens relacionadas aos contêineres que vazaram para eles. E isso pode dar uma ideia.

Eu tentei quatro contêineres que estão todos mortos e não podem ser removidos devido ao dispositivo estar ocupado e não obteve nada: /

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

Agora estou recebendo uma mensagem de erro ligeiramente diferente:

# 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

Mesma coisa. este diretório não pode ser excluído porque está montado em algum outro namespace de montagem. Tente pesquisar em / proc // mounts e grep para este id 527ae5 e veja qual pid está vendo este ponto de montagem. Precisamos descobrir isso em sua configuração por que o ponto de montagem rootfs do contêiner está vazando para outro namespace de montagem.

Aqui vamos nós:

# 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

para quais processos esses pids são mapeados? Experimente cat /proc/<pid>/comm ou ps -eaf | grep <pid>

Esses são todos os processos de trabalho do nginx que são encerrados após uma recarga de configuração (consulte o comentário editado acima). Estou me perguntando por que eles bloqueiam as montagens, já que os contêineres não ligam nenhum volume.

O processo nginx está sendo executado em outro contêiner? Ou está rodando no host?

Você pode fazer o seguinte.

• ls -l /proc/<docker-daemon-pid>/ns/mnt
• ls -l /proc/<nginx-pid>/ns/mnt
• Execute um shell bash no host e execute ls -l /proc/$$/ns/mnt

E cole a saída. aqui.

nginx é executado no host.

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]

Você docker-pid e host parecem estar compartilhando o mesmo namespace de montagem. E isso significa que o daemon do docker está sendo executado no namespace de montagem do host. E isso provavelmente significa que o nginx foi iniciado em algum ponto após o início do contêiner e parece estar sendo executado em seu próprio namespace de montagem. E naquele momento os pontos de montagem vazaram para o namespace de montagem do nginx e isso impediu a exclusão do contêiner.

Certifique-se de que MountFlags = slave esteja funcionando para você. Assim que estiver funcionando, / proc // ns / mnt fornecerá saídas diferentes para docker daemon e bash shell em execução no namespace de montagem do host.

Você tem razão. Este host ainda não tinha MountFlags=slave configurado.
Um hospedeiro diferente o fez e ainda havia contêineres mortos. Eu removi todos eles manualmente agora, mas eles foram criados com MountFlags=slave .

Vou esperar até que a situação se repita e postarei uma atualização aqui. Obrigado.

Agora a situação é a seguinte - usamos MountFlags=slave e a remoção e exclusão adiadas e, às vezes, a API remota exibe um erro informando que o dispositivo está ocupado e não pode ser removido. No entanto, quando docker rm container é chamado logo após o erro, ele remove o contêiner perfeitamente.

O problema apareceu novamente.

dockerd

# 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

Processos do comando anterior

  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

Ok, então docker-containerd-shim está vendo este ponto de montagem e, portanto, o mantém ocupado. Não tenho certeza do que é docker-containerd-shim e por que o ponto de montagem está vazando lá. Quem sabe disso.

@crosbymichael você deve saber sobre isso.

cc @mrunalp

Obrigado pelo ping. Vou dar uma olhada.

@ceecko pode verificar qual é o namespace de montagem desses threads / processos docker-containerd-shim. Suspeito que eles não estejam compartilhando o namespace de montagem com o docker daemon e provavelmente deveriam.

@rhvgoyal Eles compartilham o mesmo namespace

dockerd

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

Eu verifiquei três processos docker-containerd-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]

Não temos recipientes mortos que não puderam ser removidos agora.
O fato é que, duas vezes por semana, paramos e removemos regularmente todos os contêineres e iniciamos novos com a mesma configuração. Antes deste "reinício", alguns containers acabam morrendo e não podem ser removidos. Após a "reinicialização" regular, a maioria dos contêineres acabam mortos, mas quando todos os contêineres

Tenho o mesmo problema, mas também recebo alguns erros adicionais quando tento recriar um contêiner com 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"

Em particular, o erro Error closing logger: invalid argument , bem como o erro failed to exit within 10 seconds , que tenho certeza que não deveria acontecer, já que uso o dumb-init para iniciar meus contêineres.

Esses erros estão relacionados a esse problema?

Atualmente estou trabalhando em uma correção para isso. Eu tenho um PR aberto no containerd para ajudar.

É difícil encontrar uma maneira reproduzível de testar isso, então, depois de concluir uma correção, algum de vocês estaria interessado em testar essa correção?

Sim, definitivamente. Vou tentar criar uma máquina virtual na qual possa reproduzir esse problema e tentar consertá-la; se não funcionar, testarei no servidor em que estou tendo problemas.

Acabei de criar uma VM e consegui (com bastante facilidade!) Reproduzir o problema.

Isso é o que eu fiz com o Virtualbox:

1. Instale uma VM simples do Arch Linux (usando o processo de instalação normal)
2. Instale docker, docker-compose e outro daemon que eu possa executar vários processos (neste caso, eu escolhi nginx), então systemctl enable docker e reinicie o sistema
3. Configure o nginx para ser executado com 500 processos de trabalho
4. Crie um arquivo docker-compose com 3 contêineres de longa duração (eu escolhi postgres, tag 9.2)
5. docker-compose up -d
6. systemctl start nginx
7. Altere as versões de alguns contêineres dentro do arquivo docker-compose para usar a tag de imagem 9.3
8. docker-compose pull
9. docker-compose up -d (ele tenta recriar os contêineres e, em seguida, exibe o erro "Dispositivo está ocupado" para ambos os contêineres.

Parar o nginx me permite remover os contêineres.

docker-compose.yml partir de agora (eu imitei a configuração do docker do meu sistema com falha):

Posso fornecer acesso à VM mediante solicitação, basta me dar um e-mail para enviar o login.

@mlaventure Esse problema pode ser reaberto? No momento, não sabemos se esse problema foi corrigido ou não.

@SEAPUNK estaremos atualizando o containerd com esta correção proposta. Se você tiver a chance de testar, posso fornecer binários para tentar.

Claro, tenho minha VM em espera.

Alguma ideia de quando os binários estarão prontos?

Candidatos ao lançamento https://github.com/docker/docker/releases

Tudo bem, vou tentar; obrigado!

Eu para todos,
Acho que estou tendo o mesmo problema que está sendo relatado aqui

[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

Acabei precisando construir manualmente o binário via PKGBUILD, já que é mais simples e com ajustes posso forçar o PKGBUILD a usar um commit de containerd específico (que configurei para docker / containerd @ 03e5862ec0d8d3b3f750e19fca3ee367e13c090e):

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

Devo ter os resultados da correção em breve.

Posso estar fazendo algo errado, mas não consigo inicializar os contêineres agora:

Acho que preciso atualizar o runc ... brb rebuilding

Sim, a correção não parece estar funcionando:

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

A menos que você possa reproduzir isso em sua própria VM, estou disposto a fornecer acesso à minha VM, onde estou reproduzindo este problema e construí o pacote Docker personalizado para.

Estou vendo isso no docker 1.12.3 no CentOs 7

dc2-elk-02: / root / staging / ls-helper $ docker --version
Docker versão 1.12.3, compilação 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 Seg 24 de outubro 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux
dc2-elk-02: / root / staging / ls-helper $ docker rm ls-helper
Resposta de erro do daemon: Driver devicemapper falhou ao remover o sistema de arquivos raiz e1b9cdeb519d2f4bea53a552c8b76c1085650aa76c1fb90c8e22cac9c2e18830: O dispositivo está ocupado

Não estou usando o docker compose.

Acho que também estou encontrando esse erro.

Estou vendo muitos desses erros quando executamos testes de aceitação para 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

@rhvgoyal @rhatdan @vbatts
Encontrando problemas de 'Dispositivo ocupado' durante a exclusão / remoção de contêiner interrompido / inativo no RHEL7.1 executando dockerd 1.12.4 com exclusão e remoção adiada ativada = true sem nenhum MountFlags nos arquivos da unidade docker.service do systemd.
Também vendo mensagens do kernel como:
"kernel: device-mapper: thin: Falha na exclusão do thin device 120." (120 sendo o id do dispositivo do dispositivo thinpool do contêiner sendo removido)

Em todos os casos, o ponto de montagem do dispositivo thinpool devicemapper para o contêiner sendo removido vazou para o namespace de montagem de outro pid no host que está sendo iniciado com MountFlag = private / slave.

• ntpd.service é iniciado com PrivateTmp = true no RHEL
• O serviço systemd-udevd é iniciado com MountFlags = slave no RHEL
  Em hosts nos quais as exclusões de contêineres estão falhando, qualquer um desses processos foi reiniciado após o horário de início do contêiner correspondente.

Portanto, parece que é muito fácil vazar pontos de montagem no namespace de montagem do host, pois o sistema acima processa o descompartilhamento de alguns namespaces de montagem, por padrão, que não podem ser alterados / controlados individualmente.
Executar dockerd com mountflags = slave é a única solução aqui? Você também pode me ajudar a entender por que mountflags = slave (e padronizado como compartilhado) foi removido há algum tempo do arquivo docker systemd unit.
Em quais cenários, executar dockerd com propagação de ponto de montagem escravo quebra outras coisas?
Obrigado.

Existem diferenças no kernel RHEL e no kernel upstream que estamos tentando remediar, o que nos força a executar o dockerd em seu próprio namespace de montagem, no Fedora o kernel funciona de forma diferente, o que nos permite executar o dockerd no namespace do host.

@rhvgoyal pode lhe dar os detalhes sangrentos.

@ravilr , em kernels

Execute também o docker com MountFlags = slave

Você pode continuar a usar a remoção adiada em kernels rhel / centos e isso deve funcionar.

BTW, se você estiver usando docker-storage-setup para configurar o armazenamento, ele descobrirá automaticamente se o kernel subjacente oferece suporte à exclusão adiada ou não e definirá / não definirá essa opção de acordo.

@rhvgoyal você conhece alguma maneira de liberar espaço após a falha na remoção do sistema de arquivos raiz do contêiner?

@rhvgoyal Obrigado pelas sugestões. Vou tentar como você sugeriu e relatar aqui, se continuarmos a ver problemas relacionados à remoção de contêineres.

Ressalto; há mais informações de que você precisa para ajudar a resolver isso?

Eu mesmo cheguei a esse ponto rodando 1.12.5 no Centos 7.

Habilitar moutflags = slave, bem como habilitar a remoção e exclusão adiada, corrigiu esse problema para mim. Agora estou encontrando este bug de condição de corrida: https://github.com/docker/docker/issues/23418

Isso é cerca de 100 vezes melhor do que ter que forçar a remoção dos recipientes presos, mas ainda não é ótimo.

Posso reproduzir em um CentOS 7 em xfs.

Mesmo problema aqui, 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

Alguma resolução em vista sobre este? Ainda estou vendo o problema e minhas tentativas de encontrar o processo que mantém o dispositivo aberto falharam. Não parece haver nenhum processo mantendo o dispositivo ocupado aberto.

Obrigado.

(Atualização em meu comentário: não estava claro na primeira leitura do tópico, mas parece que habilitar a remoção adiada e configurar MountFlags = slave pode consertar. Também atualizarei o Docker para 1.13.)

alguém que queira consertar este problema pode ver o comentário de @ravilr acima, detalhes abaixo:

Em todos os casos, o ponto de montagem do dispositivo thinpool devicemapper para o contêiner sendo removido vazou para o namespace de montagem de outro pid no host que está sendo iniciado com MountFlag = private / slave.

ntpd.service é iniciado com PrivateTmp = true no RHEL
O serviço systemd-udevd é iniciado com MountFlags = slave no RHEL
Em hosts nos quais as exclusões de contêineres estão falhando, qualquer um desses processos foi reiniciado após o horário de início do contêiner correspondente.

either of these processes were restarted after the corresponding container start time. é o ponto chave, os arquivos em algum diretório como "tmp" são usados ​​por outro namespace não apenas o container docker, então o docker não pode matá-los sem força.
você pode corrigir esse problema interrompendo os processos reiniciados ou definindo o parâmetro PrivateTmp=true systemd

referência: https://www.freedesktop.org/software/systemd/man/systemd.exec.html

@KevinTHU Talvez eu não tenha entendido seus comentários.

Mas no meu caso (ubuntu 14.04), tudo que tenho que fazer para consertar isso, é reiniciar o próprio serviço docker
( service docker restart ). nenhum "ntpd.service" ou "serviço systemd-udevd" está envolvido.

Isso faz sentido?

@quexer é claro, reiniciar o docker pode resolver este problema, mas, todo o contêiner será reiniciado também, isso é muito caro para um ambiente de produção

@KevinTHU reiniciando o serviço docker NÃO afeta nenhum contêiner em execução. Você pode tentar você mesmo.

@quexer Depende da sua configuração. Mas eu suspeito que se você deixar os containers rodando no modo --live-restore , isso pode não resolver o problema.
Por padrão, o Docker irá parar todos os contêineres na saída e, mesmo assim, se houver algo quando vier o backup, ele também os matará.

@ cpuguy83 @KevinTHU Desculpe, é minha culpa. Você está certo, reiniciar o docker fará com que todos os contêineres sejam reiniciados.

Agora estou obtendo isso regularmente com uma de minhas VMs, do nada. Curiosamente, um deles tornou-se deletável após 8 horas ou mais de ser deixado sozinho. Aqui estão minhas informações:

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)

E está quebrado novamente.

Não sei se isso é relevante, mas / var / log / messages tem:

14 de fevereiro 16:58:49 kernel vrici: dev_remove: 40 retornos de chamada suprimidos
14 de fevereiro 16:58:54 kernel vrici: dev_remove: 40 retornos de chamada suprimidos
14 de fevereiro 16:58:59 kernel vrici: dev_remove: 40 retornos de chamada suprimidos

O erro agora é:

Resposta de erro do daemon: Driver devicemapper falhou ao remover o sistema de arquivos raiz b265eec88a6d1220eab75391bcf4f85bcd687301bfabfa3a2331217918c7377e: falhou ao remover o dispositivo dd81b82c875f4bcef819be83e9344c08787965a9e9by9f

O dispositivo está ocupado em algum lugar. Você pode tentar seguir o script após a falha e ver onde o dispositivo pode estar ocupado.

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

./find-busy-mnt.sh

./find-busy-mnt.sh dd81b82c875f4bcef819be83e9344c507965a9e9f48189f08c79fde5a9bde681

rlpowell @ vrici> sudo bash /tmp/find-busy-mnt.sh b2205428f34a0d755e7eeaa73b778669189584977c17df2bf3c3bf46fe98be10
Nenhum pids encontrado
rlpowell @ vrici> sudo docker rm freq_build
Resposta de erro do daemon: Driver devicemapper falhou ao remover o sistema de arquivos raiz b2205428f34a0d755e7eeaa73b778669189584977c17df2bf3c3bf46fe98be10: falhou ao remover o dispositivo 5f1095868bbfe85afccf392f6f4fbb8edbcfccf392f6f4fbb8ed4bcfac895a6a8958954955a8658658958955a895895465a8654958954958954958954954956

Oh, parece que esse foi o hash errado.

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

Isso é ... extremamente estranho. Não tenho ideia de por que um processo php-fpm totalmente não relacionado seria visto pelo kernel mantendo essas montagens abertas.

@rlpowell Sim, esse é todo o problema por trás dessa questão. Algo está fazendo com que o namespace de montagem não funcione corretamente.

Encontrei o que parece ser uma solução alternativa aqui:

Basicamente, isso significa adicionar a seguinte linha ao arquivo docker.service do systemd:
MountFlags = privado

Isso parece funcionar, pelo menos para a pequena amostra de execuções do docker que fiz desde a implantação. Seria bom se alguém que entende completamente o docker pudesse explicar as consequências desse sinalizador, eu suspeito que os sistemas de arquivos montados depois que o docker é iniciado podem não se tornar disponíveis para contêineres, mas eu honestamente não sei. Nossa configuração deve ser usada em um servidor de compilação e parece que as coisas funcionam bem.

Este é um grande problema que torna o docker inutilizável no Centos 7 / RHEL - (e está aberto há 4 meses?)
Qualquer hora prevista de chegada?

O RHEL / centos mais recente deve ser enviado com MountFlags = slave no arquivo docker.service.

@rhvgoyal este não é o caso: https://github.com/docker/docker/blob/master/contrib/init/systemd/docker.service.rpm

Este está no branch master, mas o branch 1.13.xe 17.03.x também não o tem.

Tanto quanto posso dizer é que esta bandeira estava em uma unidade de serviço anterior, mas foi removida. Mas não descobri por quê. Talvez esses sinalizadores resolvam o problema atual, mas criem outros problemas.

@rlpowell @SEAPUNK parece que este não é o caso na minha instalação do ubuntu:

$ 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

Eu escrevi um artigo explicando por que RHEL7 não pode suportar --live-restore até RHEL7.4 e por que docker deve ser executado em um namespace de montagem diferente do host.

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

+1 Eu gostaria de executar com um namespace de montagem diferente e tornar todas as montagens do docker privadas.
Há algumas partes complicadas aí, no entanto.

Se o docker upstream não tiver um sinalizador adequado para execução no MountFlags=slave , isso é um bug e irá facilmente acionar problemas com o vazamento de namespaces de montagem entre os contêineres e o host e pode levar a problemas com a remoção de imagens do contêiner.

FWIW, o MountFlags=slave foi removido em https://github.com/docker/docker/pull/22806 , após revisão pelos mantenedores do Red Hat, mas parece que está causando problemas, então me pergunto se isso deve ser revertido até RHEL7.4?

Sim, nós o removemos e mais tarde ele causou problemas, então em um dos tópicos de discussão concluímos que vamos reintroduzi-lo de volta. Eu pensei que você já tinha feito isso. Não me lembro de qual tópico era.

@thaJeztah Sim, estávamos enganados e encontramos problemas adicionais.

E esses problemas eram principalmente específicos para os grãos mais antigos. Kernels mais novos funcionam bem.

Deixe-me abrir um PR para discutir opções

PR abriu aqui; https://github.com/docker/docker/pull/31490

mesmo problema, docker 1.10.3, CentOS Linux versão 7.2.1511
dmesg ：
[1732917.246900] mapeador de dispositivo: ioctl: não foi possível remover o dispositivo docker-8 aberto: 3-5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78
mensagens ：
3 de abril 03:32:34 A02-R05-I97-106 docker-current: time = "2017-04-03T03: 32: 34.346374677 + 08: 00" nível = erro msg = "Erro ao remover a camada montada b0b1e839f366086fd7cff564feee385a3aed71a56db290e4c04 is1351717 "
3 de abril 03:32:34 A02-R05-I97-106 docker-current: time = "2017-04-03T03: 32: 34.346597095 + 08: 00" nível = erro msg = "Manipulador para DELETE /v1.22/containers / b0b1e839f366086fd7cff564feee385a3aed71a56db90e4c0416517a72c13f2d retornou o erro: Driver devicemapper falhou ao remover o sistema de arquivos raiz b0b1e839f366086fd7cff564feee385a3aed72c0416517a72c13f2d Devicemapper falhou ao remover sistema de arquivos raiz b0b1e839f366086fd7cff564feee385a3aed71a5690e4

montagem:
find / proc / * / mounts | xargs grep -E "5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78"
/ proc / 159779 / montagens: / dev / mapeador / janela de encaixe-8: 3-5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 / exportação / janela de encaixe / devicemapper / mnt / b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 XFS rw, relatime, nouuid, attr2, inode64, logbsize = 64k, Sunit = 128, swidth = 128, noquota 0 0
/ proc / 159806 / montagens: / dev / mapeador / janela de encaixe-8: 3-5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 / exportação / janela de encaixe / devicemapper / mnt / b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 XFS rw, relatime, nouuid, attr2, inode64, logbsize = 64k, Sunit = 128, swidth = 128, noquota 0 0
novo contêiner ：
docker inspect 8777d36c94ec | grep Pid
"Pid": 159779,

// minha culpa, resolvi isso。

O que é ID "8777d36c94ec"? Este é o ID do contêiner sendo removido ou algum outro contêiner?

Portanto, o dispositivo está ocupado porque ainda está montado no contêiner. Portanto, qualquer um dos contêineres que está sendo removido ainda não foi interrompido. Ou se for um contêiner diferente, não deve ser visível em outro contêiner.

Não tenho certeza de qual é o ponto de montagem "/ export / docker / devicemapper / mnt / ...." e quem o criou?

No meu sistema Mint, atualizar de 17.03.1~ce-0~ubuntu-xenial para 17.04.0~ce-0~ubuntu-xenial faz com que esse problema ocorra com muita frequência.

Antes de atualizar, eu nunca o havia encontrado. Depois que a atualização é muito frequente. O downgrade para 17.03.1 parece ter resolvido o problema.

Apenas como uma observação para os outros que estão lendo este tópico, se você estiver executando o cAdvisor do Google, verá esse problema ao tentar remover um contêiner. Primeiro você precisa parar o cAdvisor, depois remover o contêiner e, em seguida, iniciá-lo novamente.

@bmbroom Ditto. Executamos servidores de compilação baseados no ubuntu que agitam contêineres o dia todo (geralmente acionados por docker-compose), e víamos esse problema algumas vezes por semana. Os servidores são uma mistura de trusty e xenials. Recentemente, começamos a atualização para 17.04.0 ~ ce e estamos vendo isso acontecendo várias vezes ao dia agora.

Não estou certo se MountFlags = slave é aplicável ao ubuntu, mas é o que estou tentando a seguir.

@rhvgoyal
desculpe minha culpa。
outros ainda montados em meu contêiner。

Acabei de ter o mesmo problema em:

• docker: Docker versão 17.03.1-ce, compilação c6d412e
• os: Red Hat Enterprise Linux Server versão 7.3 (Maipo)
• kernel: 3.10.0-514.6.1.el7.x86_64
• ntpd: 4.2.6p5

Fazer systemctl restart ntpd corrigiu o problema instantaneamente.

@xeor
qual é o seu MountFlags arquivo da unidade docker.service?

Não há MountFlags no meu arquivo /usr/lib/systemd/system/docker.service , mas systemctl show docker mostra MountFlags=0 .

O mesmo vale para ntpd.service . Isso também tem PrivateTmp=true sob a estrofe [Service] (se esse for o caso).

Execute com MountFlags = slave por enquanto.

@rhvgoyal verificou meu arquivo docker.service. Mas seu valor já está definido:

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

usando o redhat mais recente (3.10.0-514.16.1.el7) / docker (1.12.6-16.el7)

o que há sobre MountFlags = private? Você poderia explicar a diferença entre privado e escravo?

Atualmente, estou vendo esse problema no RHEL / CentOS 7.3, kernel 3.10.0-514.16.1.el7.x86_64, com Docker versão 17.05.0-ce, build 89658be. Temos visto esse problema de vez em quando no ano passado.

Também não temos a opção MountFlags em /etc/systemd/system/multi-user.target.wants/docker.service. Devemos adicionar "MountFlags = slave" lá?

Vejo comentários dizendo que esse problema acontece no Centos, RHEL e Ubuntu. Os outros sistemas operacionais estão protegidos contra esse problema específico, como Debian, ContainerLinux ou SUSE?

@earwax Qualquer coisa com um kernel mais recente (> = 3.15) geralmente deve funcionar melhor.
Mas sempre há situações que você pode criar onde esse erro ocorre.
Além disso, existem várias maneiras listadas nos comentários aqui para atenuá-lo.

Vejo esse problema no SUSE ... mas não consegui encontrar uma solução para ele ... Vejo isso acontecendo principalmente no provedor: AZURE

também encontramos esse problema, quando atualizamos o dockerd de 1.12.6 para 17.05. Todos os contêineres antigos não podiam ser excluídos sem '-f', esses contêineres tinham uma característica comum de que todos eles não eram interrompidos quando atualizamos o dockerd, porque temos a configuração '--live-restore'. Acho que há algum problema aqui.

Este ainda é um problema no 17.06, FYI, pelo menos com o CentOS 7.

@ MGD1981 este bug precisa ser consertado, estamos usando centos 7 da mesma forma, e descobrimos que não apenas os containers antigos criados antes da atualização do docker têm o problema de "dispositivo está ocupado", mas também os novos containers criados, isso é realmente crítico , e contornamos isso adicionando "MountFlags = slave" a docker.service. Porém, não sabemos se este parâmetro trará algum outro problema.

Sim, tentando fazer isso agora em nosso ambiente de controle de qualidade. Estarei prestando muita atenção
para as montagens. Existe um risco potencial de o FS de um contêiner ser
"esquecido" com esta configuração, com o tempo enchendo o host com discos
de recipientes mortos?

Na segunda-feira, 3 de julho de 2017, 22h38, KevinTHU [email protected] escreveu:

@ MGD1981 https://github.com/mgd1981 esse bug precisa ser corrigido, estamos
usando centos 7 da mesma forma, e descobrimos que não apenas os contêineres antigos
criado antes de atualizar o docker tem o problema "dispositivo está ocupado", mas também o
novos contêineres criados, isso é realmente crítico, e nós contornamos isso
adicionando "MountFlags = slave" a docker.service. No entanto, não sabemos se
este parâmetro trará algum outro problema.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/moby/moby/issues/27381#issuecomment-312766596 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ADzZzStBbgubPK4soa2w5WW_hthYnZwjks5sKaW2gaJpZM4KW5Fn
.

@ MGD1981 sim, parece haver discos no host que não são mais usados. Veja # 33025

@ceecko Isso não deve acontecer mais a partir de 17.06, embora se você habilitar a remoção / exclusão adiada, então pode não ser limpo imediatamente.

@ cpuguy83 legal! Ele limpará discos antigos que foram deixados por versões anteriores também?

@ cpuguy83 já foi lançado em 17.06? (já é julho, então 17.07?) ele não foi encontrado na página de lançamentos do github.

@ravilr Saiu. Os lançamentos vêm de github.com/docker/docker-ce.

@ceecko Acho que não.

@ cpuguy83 obrigado. as notas de lançamento de 17.06 não parecem mencionar nenhuma correção de pr em relação a esse problema. qual foi a solução para resolver isso? Obrigado novamente.

@ravilr este PR https://github.com/moby/moby/pull/31012

Estou executando o 17.06.0-ce no CentOS 7 (com armazenamento de thin pool) e isso está acontecendo muito recentemente.

+ 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

Isso é com ou sem MountFlags=slave , @ AaronDMarasco-VSI? CentOS 7.3?

17.06 não corrige o problema fundamental, apenas é melhor em lidar com ele.
Estou procurando se há algo que o docker (ou algum subcomponente como containerd) está fazendo que exacerba o problema.

@esabol Não ... privado?

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) 

Bem, @ AaronDMarasco-VSI, aconselho mudar para MountFlags=slave , o que melhorou a situação para nós, mas ainda estamos em 17.05 e acho que vi algum lugar que você não quer usar MountFlags=slave com dm.use_deferred_removal ? Talvez outra pessoa comente e confirme.

Estou usando o docker 17.03 no centos 7.3 e no kernel 4.10. e tenho visto esse lote de erros. abaixo estão mais alguns detalhes sobre MountFlag.

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

mesmo problema aqui com o Debian 8. ele quebra nosso CI, qualquer solução possível ??

@ thg303 tente desligar seu dockerdeamon, se possível, e tente limpar / remover o sistema de arquivos raiz que ocorre em seu arquivo de log (rm / var / lib / docker / .....). Mas você deve fazer um instantâneo / backup antes de :-)

O mesmo problema aqui com o Fedora 25, kernel 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.

Tenho esse problema toda vez que o docker é atualizado no centos7. Reinicio o docker e tudo funciona bem.

O mesmo para mim no Fedora 26 com Docker 17.06.0-ce. Reiniciar o docker não corrigiu o problema.

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

Sério, já vai fazer um ano e esse bug ainda está aqui?

@NeckBeardPrince Por favor, não perca nosso tempo com comentários tão inúteis.
Se você gostaria de ajudar a resolver isso, ótimo. Se você gostaria de relatar mais alguns dados sobre o problema, ótimo.

Além disso, há algumas maneiras de contornar esse problema que foram postadas aqui.

o arquivo de unidade systemd não é enviado com 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

A última vez que tive esse problema, era ntpd que estava segurando as montagens.
Hoje, tive o mesmo problema e, desta vez, era uma instância mariadb em execução no host que era o motivo.

• docker-engine-17.05.0.ce-1.el7.centos.x86_64
• mariadb-server-5.5.56-2.el7.x86_64

Exemplo para encontrar o proc segurando as montagens ....

# 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

Depois de reiniciar o mariadb, ele soltou os pontos de montagem, no entanto, agarrou muitos deles quando começou.

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

A maioria das falhas de remoção deve-se ao ponto de montagem (portanto, dispositivo) estar ocupado em alguns outros namespaces de montagem. Acho que seguir o PR proposto ajudará com este problema se o kernel for novo o suficiente.

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

Se você estiver executando um kernel antigo, escrevemos uma chamada de plug-in oci-umount para reduzir os problemas de vazamento de montagem.

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

@rhvgoyal Você tem um plano sobre qual versão do docker incluirá este PR? Ainda estamos lidando com driver "devicemapper" failed to remove root filesystem regularmente.

CentOS Linux versão 7.4.1708 (Core)
3.10.0-693.5.2.el7.x86_64
17.06.2-ce

PARECE QUE ESTÁ FINALMENTE CORRIGIDO

Estamos executando o Docker versão 17.09.0-ce e ainda enfrentamos o mesmo problema.

Ocasionalmente, encontramos esse problema no Oracle Linux :, com docker versão 17.03.1-ce (dos repositórios da 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

O acima é tudo corrigido pelo TDA do projeto, então não podemos mudar nada por enquanto.

90% de nossos outros ambientes são Centos 7.3 / 7.4, e não vimos o problema lá.

Acabei de resolver uma instância deste problema com Docker 17.05 no arch Linux em 4.11.9
por

1. docker rm -f [myContainer] (falhando com driver "devicemapper" failed to remove root filesystem como de costume)
2. ls /var/lib/docker/devicemapper/mnt/

Isso fez com que o contêiner finalmente desaparecesse (embora não tenha certeza do porquê).

@MonsieurWave tão incrível quanto parece, o truque "ls" funcionou perfeitamente para mim quando todo o resto não funcionou!

O docker rm -f [container] relatará uma falha, mas eventualmente limpará o contêiner e o sistema de arquivos. O comando ls é uma pista falsa, tudo o que você realmente precisa é esperar alguns segundos. Mas melhor do que isso é usar MountFlags=slave . E o melhor é desligar o mapeador de dispositivos e usar overlay2.

E o melhor é desligar o mapeador de dispositivos e usar overlay2.

Estamos usando o Docker no CentOS 7.x (atualmente em 7.4) há mais de um ano. Quando instalamos o Docker pela primeira vez, tudo e todos disseram que você tinha que usar o devicemapper com direct-lvm para obter o melhor desempenho e estabilidade. https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/ ainda diz que você precisa usar o devicemapper no CentOS com Docker EE. Felizmente, usamos Docker CE, então podemos mudar para overlay2. Eu sinto que o pessoal do Docker escorregou na mudança no padrão de devicemapper para overlay2 no CentOS em v1.13.0 / 1 com pouca fanfarra ou discussão. Existe alguma informação sólida sobre desempenho / estabilidade de overlay2 versus devicemapper (direct-lvm) no CentOS 7? Meu googling não encontrou muito ....

Passamos muito mal com os kernels CentOS 7.2 padrão (seu frankenstein 3.10.x). Muitos acidentes. Estávamos executando o Kubernetes em um ambiente de desenvolvimento, então a rotatividade de nossos contêineres era muito alta, mas mesmo em instalações relativamente silenciosas, achamos o combo CentOS + overlay de estoque muito instável. Rodar um kernel superior 4.10+ com overlay2 é muito melhor. Ainda não tentei uma versão mais recente do CentOS.

Você precisará usar um sistema de arquivos subjacente que seja ext4 ou XFS formatado com "-n ftype = 1". O Docker será executado se você tiver um XFS formatado incorretamente, mas os resultados serão imprevisíveis.

Sim, há muito tempo mudei para overlay2 e recomendo a qualquer um que ainda use o devicemapper que possa usar o overlay2 para alternar , já que mesmo esse problema de lado, li que o devicemapper é um driver de armazenamento muito ruim para docker em geral.

Reiniciar o ntpd corrigiu o problema que eu estava tendo ... muito confuso. Existe alguma configuração daemon.json "recomendada" para docker em Centos7?

Algumas melhorias estão sendo implementadas.

Especificamente, o problema com esses outros serviços do sistema parece ser uma condição de corrida com a configuração de namespaces de montagem (para esses outros serviços do sistema) e a tentativa do docker de manter suas próprias montagens privadas ... a intenção é que o Docker evite que suas montagens vazem para dentro contêineres, infelizmente está causando vazamentos em outros lugares e na verdade acabam mantendo referências privadas a esses pontos de montagem, o que significa que eles não podem ser desmontados nesses namespaces, exceto manualmente ou quando o processo for reiniciado.

Além disso, houve algumas mudanças recentes para lidar com as condições de corrida com o uso de propagação de montagem MS_PRIVATE em runc e docker.
A próxima versão será perfeita? Provavelmente não ... mas espero que isso melhore.

Recebi exatamente a mesma coisa que @ceecko com docker 12.1.1, sem chance de atualizar agora. É consertado mais tarde em algum lugar? A solução rápida é eliminar processos e reiniciar o serviço docker, mas ..

Essas versões corrigem completamente o problema para mim, incluindo --live-restore

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

@esabol , avaliamos a mudança para overlay2 depois de atualizar para o CentOS 7.4. Infelizmente, é muito trabalho. As partições que poderíamos usar para armazenar os dados são XFS e antes de 7.4, a opção de formatação XFS padrão do CentOS perdia um parâmetro (esqueci qual) para poder suportar overlay2 no topo. Portanto, isso significa que teríamos que reformatar a partição para poder usar o overlay2 no topo do XFS. É quando a mudança para overlay2 vai nos custar muito trabalho para evitar o tempo de inatividade, e o kernel 7.4 + Docker 17.09 mais recente e as recomendações acima para a configuração do LVM ajudaram muito a evitar o problema na maioria das vezes.

Nota: docker info mostra um grande aviso de que a execução de overlay2 sobre XFS sem essas opções específicas não é suportada e será removida em uma versão futura.

https://github.com/moby/moby/pull/34573 correção lançada nas versões 17.09.1-ce, 17.12.0-ce

@jcberthon Recentemente, docker run --rm . A gota d'água para nós, para o devmapper, foi a edição # 20401. Mudar para overlay2 não foi muito difícil, mas temos bastante espaço livre em disco. Eu escrevi um script para docker save todas as nossas imagens para tarballs e outro script para docker load todos os tarballs. Terminamos em 2-3 horas. Eu sei que parece um aborrecimento e pode ser se você não tiver espaço em disco suficiente, mas vai valer a pena no longo prazo, eu acho. Boa sorte!

Isso foi corrigido em 17.12.1

Obrigado a todos.

antes do lançamento corrigido, reinicializar o nó físico resolverá o problema

@ravilr @KevinTHU sobre seu comentário https://github.com/moby/moby/issues/27381#issuecomment -277148106 e https://github.com/moby/moby/issues/27381#issuecomment -267547259 Eu observei que alterar o arquivo da unidade docker no RHEL para PrivateTmp=true corrige o problema também. Alguma chance de você ter visto algo semelhante?

@MohdAhmad nunca tentei isso, mas acho que pode ser ok, já que PrivateTmp = true no arquivo da unidade do docker é apenas para o docker, talvez conserte esse problema ainda melhor.

Eu acho o mesmo problema. Porque abro a pasta, fecho a janela para resolver.