moby 🚀 - ドライバdevicemapperはルートファイルシステムの削除に失敗しました。デバイスがビジーです

これはどのコンテナでも発生していますか？コンテナーで何が実行されており、コンテナーを開始するためにどのオプションを使用しますか？（たとえば、バインドマウントされたディレクトリを使用していますか、コンテナで追加のプロセスを開始するためにdocker execを使用していますか？）

thaJeztah 2016年10月15日

すべてのコンテナをほぼ同じ方法で実行し、いずれかのコンテナでランダムに発生します。
docker execは使用せず、ディレクトリをバインドマウントしません。
デッドコンテナの1つの設定は次のとおりです。

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

ceecko 2016年10月15日

これは、このファイルシステムBacking Filesystem: ext4備えたサーバーでのみ発生することに気づきました。
この問題は、バッキングファイルシステムとしてxfsを実行しているサーバーでは発生しないようです。

ceecko 2016年10月15日

@ceeckoありがとう、それは面白い

@rhvgoyalこれはあなたの側の既知の問題ですか？

thaJeztah 2016年10月15日

これは生産において私たちに大きな打撃を与えます：/死んだコンテナを取り除く方法のヒントはありますか？

ceecko 2016年10月17日

@thaJeztahこれがext4でのみ発生し、xfsでは発生しないのは不思議です。私はそのようなことを知りません。

一般に、デバイスがビジーであると報告されていますが、それには多くの理由が考えられます。

@ceekoはまず、

rhvgoyal 2016年10月17日

@rhvgoyal MountFlags=slaveは、これまでのところ問題を解決しているようです。変更前に作成されたコンテナはまだ問題ですが、新しいコンテナは今のところエラーを引き起こしていないようです。何か変更があった場合はご連絡いたします。

ところで、リファレンスが見つからなかったため、本番環境のベストプラクティスとしてこれを推奨するように、ストレージドライバーのドキュメントを更新する価値があるかもしれません。

ご協力ありがとうございました。

ceecko 2016年10月17日

これはしばらく前に変更されました。 https://github.com/docker/docker/commit/2aee081cad72352f8b0c37ba0414ebc925b022e8#diff -ff907ce70a8c7e795bde1de91be6fa68（https://github.com/docker/docker/pull/22806）、議論によると、これは延期された場合に問題になる可能性があります有効になっていません; https://github.com/docker/docker/pull/22806#issuecomment -220043409

デフォルトを元に戻す必要がありますか？ @rhvgoyal

thaJeztah 2016年10月17日

@thaJeztahデフォルトをMountFlags = slaveに戻すのは良い考えかもしれないと思います。私たちはそれをしました。

理想的には、遅延削除および遅延削除機能がこれを処理する必要があり、MountFlags = slaveを使用する必要はありませんでした。しかし、延期された削除だけでは十分ではありません。古いカーネルには、別のマウント名前空間にマウントされている場合でも、マウント名前空間からディレクトリを削除できる機能がありません。そして、それがコンテナの削除が失敗する理由の1つです。

したがって、古いカーネルがその機能を提供するまでは、スレーブマウント名前空間でdockerデーモンを実行することをお勧めします。

rhvgoyal 2016年10月17日

@rhvgoyal MountFlags=slaveしても、エラーが再び表示され始めました。延期された削除と削除を試み、折り返しご連絡いたします。

ceecko 2016年10月20日

xfsでも同じエラーが発生しました。
これが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

ceecko 2016年10月22日

MountFlags=slaveとdm.use_deferred_deletion=trueとdm.use_deferred_removal=trueても、以前よりも頻度は低くなりますが、1.12.2でもエラーが発生することを確認しました。

ceecko 2016年10月27日

削除できなかったlogsre1コンテナの詳細は次のとおりです。

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

ceecko 2016年10月29日

次のメッセージは、ディレクトリの削除に失敗したことを示しています。

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

また、古いカーネルでは、ディレクトリが他のマウント名前空間にマウントされているために失敗する可能性があります。 deferred deletion機能を無効にすると、このメッセージは表示されなくなります。ただし、他のエラーメッセージになります。

ここでの問題の核心は、コンテナがまだ実行されているか、そのマウントポイントの一部が他のマウント名前空間にリークしていることです。そして、それがどのマウント名前空間にリークし、どのようにそこに到達したかを把握できれば、それを修正してみることができます。

この問題が発生したら、 find /proc/*/mounts | xargs grep "4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543"試してみてください

次に、どのpidにコンテナに関連するマウントがリークされているかを確認します。そして、それはいくつかのアイデアを与えるかもしれません。

rhvgoyal 2016年10月31日

👍13 ❤2 🎉1

私は4つのコンテナを試しましたが、それらはすべて死んでいて、デバイスがビジーで何も得られなかったために削除できません：/

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

ceecko 2016年10月31日

今、私は実際にはわずかに異なるエラーメッセージを受け取っています：

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

ceecko 2016年10月31日

同じこと。このディレクトリは、他のマウント名前空間にマウントされているため、削除できません。 / proc /で検索してみてくださいこのID 527ae5 / mountsとgrepを使用して、このマウントポイントを認識しているpidを確認します。セットアップで、コンテナーrootfsマウントポイントが他のマウント名前空間にリークしている理由を理解する必要があります。

rhvgoyal 2016年10月31日

どうぞ：

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

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

ceecko 2016年10月31日

👍1

これらのpidはどのプロセスにマップされますか？ cat /proc/<pid>/commまたはps -eaf | grep <pid>試しください

rhvgoyal 2016年10月31日

これらはすべて、構成のリロード後にシャットダウンするnginxワーカープロセスです（上記の編集されたコメントを参照）。コンテナがボリュームをバインドしないので、なぜマウントをブロックするのか疑問に思います。

ceecko 2016年10月31日

では、nginxプロセスは別のコンテナで実行されていますか？または、ホスト上で実行されていますか？

rhvgoyal 2016年10月31日

👍1

次のことができますか。

ls -l /proc/<docker-daemon-pid>/ns/mnt
ls -l /proc/<nginx-pid>/ns/mnt
ホストでbashシェルを実行し、 ls -l /proc/$$/ns/mntを実行します

そして、出力を貼り付けます。ここ。

rhvgoyal 2016年10月31日

nginxはホスト上で実行されます。

docker-pid

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

nginx-pid

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

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

ceecko 2016年10月31日

docker-pidとホストの両方が同じマウント名前空間を共有しているようです。これは、dockerデーモンがホストマウント名前空間で実行されていることを意味します。そしてそれはおそらく、nginxがコンテナの開始後のある時点で開始され、それ自体のマウント名前空間で実行されているように見えることを意味します。そしてその時、マウントポイントがnginxマウント名前空間にリークし、それがコンテナの削除を妨げています。

MountFlags = slaveが機能していることを確認してください。動作したら、/ proc // ns / mntは、ホストマウント名前空間で実行されているdockerデーモンとbashシェルに対して異なる出力を提供します。

rhvgoyal 2016年10月31日

あなたが正しい。このホストにはまだMountFlags=slave設定されていません。
しかし、別のホストがそうしましたが、それでも死んだコンテナがありました。今はすべて手動で削除しましたが、 MountFlags=slave作成されました。

状況が繰り返されるまで待ち、ここに更新を投稿します。ありがとう。

ceecko 2016年10月31日

現在の状況は次のとおりです。 MountFlags=slaveを使用し、削除と削除を延期しました。リモートAPIが、デバイスがビジーで削除できないというエラーをスローする場合があります。ただし、エラーの直後にdocker rm containerが呼び出されると、コンテナは正常に削除されます。

ceecko 2016年11月03日

👍1

問題が再び発生しました。

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

前のコマンドからのプロセス

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

ceecko 2016年11月05日

❤3 👍1

わかりました。docker-containerd-shimはこのマウントポイントを認識しているため、ビジー状態を維持します。 docker-containerd-shimとは何か、マウントポイントがそこにリークしている理由がわかりません。誰がそれを知っていますか。

@crosbymichaelあなたはそれについて知っているかもしれません。

rhvgoyal 2016年11月07日

cc @mrunalp

rhvgoyal 2016年11月07日

pingをありがとう。見てみます。

crosbymichael 2016年11月07日

@ceeckoは、これらのdocker-containerd-shimスレッド/プロセスのマウント名前空間が何であるかを確認できます。これらはdockerデーモンとマウント名前空間を共有していないのではないかと思います。おそらくそうすべきです。

rhvgoyal 2016年11月07日

@rhvgoyal同じ名前空間を共有します

dockerd

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

3つの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]

現在取り除けなかった死んだコンテナはありません。
重要なのは、週に2回、定期的にすべてのコンテナーを停止して削除し、同じ構成で新しいコンテナーを開始することです。この「再起動」の前に、一部のコンテナは停止し、削除できなくなります。通常の「再起動」後、ほとんどのコンテナは死んでしまいますが、古いコンテナがすべて停止すると、死んだコンテナはすべて突然削除される可能性があります。

ceecko 2016年11月08日

同じ問題がありますが、 docker-compose up -dコンテナを再作成しようとすると、いくつかの追加エラーが発生します。

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

特に、 Error closing logger: invalid argumentエラーとfailed to exit within 10 secondsエラーは、 dumb-initを使用してコンテナーを

これらのエラーはこの問題に関連していますか？

SEAPUNK 2016年11月10日

私は現在、これの修正に取り組んでいます。私はコンテナにオープンPRを持っています。

これをテストするための再現可能な方法を見つけるのは難しいので、修正が完了した後、この修正のテストに興味がある人はいますか？

crosbymichael 2016年11月10日

ええ、間違いなく。この問題を再現できる仮想マシンを作成し、そこで修正を試みます。それが機能しない場合は、問題が発生しているサーバーでテストします。

SEAPUNK 2016年11月10日

たった今VMを作成しましたが、問題を（非常に簡単に！）再現することができました。

これは私がVirtualboxでやったことです：

プレーンなArchLinux VMをインストールします（通常のインストールプロセスを使用）
docker、docker-compose、および複数のプロセスを実行できる別のデーモン（この場合はnginxを選択）をインストールしてから、 systemctl enable dockerをインストールし、システムを再起動します
500ワーカープロセスで実行するようにnginxを構成する
3つの長時間実行コンテナを含むdocker-composeファイルを作成します（postgres、タグ9.2を選択しました）
docker-compose up -d
systemctl start nginx
docker-composeファイル内のいくつかのコンテナーのバージョンを変更して、イメージタグ9.3を使用します
docker-compose pull
docker-compose up -d （コンテナを再作成しようとすると、両方のコンテナで「デバイスがビジーです」というエラーが表示されます。

nginxを停止すると、コンテナーを削除できます。

現在のところdocker-compose.yml （失敗したシステムのDockerセットアップを模倣しました）：

リクエストに応じてVMへのアクセスを提供できます。ログインを送信するメールを送ってください。

SEAPUNK 2016年11月11日

👍2

@mlaventureこの問題を

SEAPUNK 2016年11月17日

👍4

@SEAPUNKこの提案された修正でcontaineredを更新します。テストする機会があれば、試してみるバイナリを提供できます。

crosbymichael 2016年11月17日

確かに、VMはスタンバイ状態です。

SEAPUNK 2016年11月17日

❤1

バイナリがいつ準備できるかについて何か考えはありますか？

SEAPUNK 2016年11月28日

1.13の@SEAPUNKリリース候補は現在テストに利用可能であり、この変更が必要です。 https://github.com/docker/docker/releases

thaJeztah 2016年11月29日

了解しました。試してみます。ありがとう！

SEAPUNK 2016年11月29日

私はみんなに、
私はここで報告されているのと同じ問題を抱えていると思います

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

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



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


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

asantos82 2016年12月02日

PKGBUILDを介してバイナリを手動でビルドする必要がありました。これは、より簡単で、調整により、PKGBUILDに特定のコンテナコミット（docker / containerd @ 03e5862ec0d8d3b3f750e19fca3ee367e13c090eに設定）を使用させることができるためです。

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

すぐに修正の結果が出るはずです。

SEAPUNK 2016年12月02日

私は何か間違ったことをしているかもしれませんが、今はコンテナをまったく起動できません：

SEAPUNK 2016年12月02日

ああ、私はruncを更新しなければならないと思います... brbの再構築

SEAPUNK 2016年12月02日

ええ、修正は機能していないようです：

docker info

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

docker version

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

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

SEAPUNK 2016年12月02日

これを自分のVMで再現できない限り、この問題を再現しているVMへのアクセスを提供し、のカスタムDockerパッケージをビルドします。

SEAPUNK 2016年12月02日

CentOs7のdocker1.12.3でこれが表示されます

dc2-elk-02：/ root / staging / ls-helper $ docker --version
Dockerバージョン1.12.3、ビルド6b644ec
dc2-elk-02：/ root / staging / ls-helper $ uname -a
Linux dc2-elk-02 3.10.0-327.36.3.el7.x86_64＃1 SMP Mon Oct 24 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux
dc2-elk-02：/ root / staging / ls-helper $ docker rm ls-helper
デーモンからのエラー応答：ドライバーdevicemapperがルートファイルシステムe1b9cdeb519d2f4bea53a552c8b76c1085650aa76c1fb90c8e22cac9c2e18830の削除に失敗しました：デバイスがビジーです

dockercomposeを使用していません。

bladedoyle 2016年12月13日

多分私もこのエラーに遭遇していると思います。

Flockerの受け入れテストを実行すると、次のエラーが多数発生します。

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

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

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

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

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

[Install]
WantedBy=multi-user.target

wallrj 2016年12月13日

@rhvgoyal @rhatdan @vbatts
systemddocker.serviceユニットファイルにMountFlagsがない状態で遅延削除と削除が有効になっているdockerd1.12.4を実行しているRHEL7.1で、停止/デッドコンテナの削除/削除中に「デバイスビジー」の問題が発生しました。
次のようなカーネルメッセージも表示されます。
「カーネル：デバイスマッパー：シン：シンデバイス120の削除に失敗しました。」（120は、削除されるコンテナーのシンプールデバイスのデバイスIDです）

いずれの場合も、削除されるコンテナーのdevicemapper thinpoolデバイスマウントポイントが、MountFlag = private / slaveで開始されているホスト上の別のpidのマウント名前空間にリークされました。

ntpd.serviceは、RHELでPrivateTmp = trueで開始されます
systemd-udevdサービスは、RHELのMountFlags = slaveで開始されます
コンテナーの削除が失敗しているホストでは、これらのプロセスのいずれかが、対応するコンテナーの開始時刻の後に再起動されました。

したがって、上記のシステムプロセスはデフォルトで一部のマウント名前空間の共有を解除するため、ホストマウント名前空間のマウントポイントをリークするのは非常に簡単なようです。これらは個別に変更/制御することはできません。
ここでは、mountflags = slaveを使用してdockerdを実行することが唯一の解決策ですか？また、mountflags = slave（およびデフォルトで共有）がdockersystemdユニットファイルから削除された理由を理解するのに役立ちます。
どのようなシナリオで、スレーブマウントポイントの伝播を使用してdockerdを実行すると、他の問題が発生しますか？
ありがとう。

ravilr 2016年12月16日

👍5

RHELカーネルと、修正しようとしているアップストリームカーネルには違いがあり、独自のマウント名前空間でdockerdを実行する必要があります。Fedoraでは、カーネルの動作が異なり、ホスト名前空間でdockerdを実行できます。

@rhvgoyalはあなたに

rhatdan 2016年12月16日

@ ravilr 、rhel / centosカーネルでは、遅延削除を無効にします。カーネルには、それをサポートするパッチがありません。

また、MountFlags = slaveでdockerを実行します

rhvgoyal 2016年12月16日

rhel / centosカーネルで引き続き遅延削除を使用でき、それは機能するはずです。

rhvgoyal 2016年12月16日

ところで、docker-storage-setupを使用してストレージをセットアップしている場合、基盤となるカーネルが遅延削除をサポートしているかどうかを自動的に判断し、それに応じてそのオプションを設定/設定解除します。

rhvgoyal 2016年12月16日

@rhvgoyalコンテナルートファイルシステムの削除に失敗した後、スペースを解放する方法を知っていますか？

mtrofimm 2016年12月19日

@rhvgoyal提案をありがとう。コンテナの削除に関連する問題が引き続き発生する場合は、提案どおりに試して、ここに報告します。

ravilr 2016年12月20日

バンプ; これを解決するために必要な情報は他にありますか？

SEAPUNK 2017年01月10日

Centos7で1.12.5を実行している自分でこれをヒットしました。

moutflags = slaveを有効にし、遅延削除と削除を有効にすると、この問題が修正されました。今、私はこの競合状態のバグにぶつかっています： //github.com/docker/docker/issues/23418

これは、スタックしたコンテナを強制的に削除するよりも約100倍優れていますが、それでも優れていません。

mechanicjay 2017年01月11日

xfs上のCentOS7で再現できます。

dereckson 2017年01月28日

ここで同じ問題、Docker 1.13.0-CentOS7：

docker-compose down
Removing container_container_1 ... error

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

gerwim 2017年01月28日

これに関する解決策はありますか？まだ問題が発生しており、デバイスを開いたままにするプロセスを見つける試みが失敗しました。ビジー状態のデバイスを開いたままにするプロセスはないようです。

ありがとう。

（私のコメントの更新：スレッドの最初の読み取りでは明確ではありませんでしたが、遅延削除を有効にし、MountFlags = slaveを設定すると修正される可能性があります。Dockerも1.13に更新します。）

vsheffer 2017年02月02日

この問題を修正したい人は、上記の@ravilrのコメント、以下の詳細を参照できます。

いずれの場合も、削除されるコンテナーのdevicemapper thinpoolデバイスマウントポイントが、MountFlag = private / slaveで開始されているホスト上の別のpidのマウント名前空間にリークされました。

ntpd.serviceは、RHELでPrivateTmp = trueで開始されます
systemd-udevdサービスは、RHELのMountFlags = slaveで開始されます
コンテナーの削除が失敗しているホストでは、これらのプロセスのいずれかが、対応するコンテナーの開始時刻の後に再起動されました。

either of these processes were restarted after the corresponding container start time.が重要なポイントです。「tmp」などのディレクトリ内のファイルは、dockerコンテナだけでなく他の名前空間でも使用されるため、dockerは強制的に強制的にファイルを強制終了することはできません。
再起動されたプロセスを停止するか、systemdパラメーターPrivateTmp=trueをfalseに設定して再起動することで、この問題を修正できます。

参照： https ：

KevinTHU 2017年02月03日

@KevinTHU多分私はあなたのコメントを誤解しています。

しかし、私の場合（ubuntu 14.04）、これを修正するために私がしなければならないのは、Dockerサービス自体を再起動することだけです
（ service docker restart ）。「ntpd.service」または「systemd-udevdサービス」は含まれません。

それは理にかなっていますか？

quexer 2017年02月08日

@quexerもちろん、

KevinTHU 2017年02月08日

👍6

@KevinTHUのDockerサービスの再起動は、実行中のコンテナーに影響を与えません。自分で試すことができます。

quexer 2017年02月09日

👎2

@quexer構成によって異なります。ただし、コンテナを--live-restoreモードで実行したままにすると、問題が解決しない可能性があります。
デフォルトでは、Dockerは終了時にすべてのコンテナーを停止しますが、バックアップ時に何かがある場合は、それらも強制終了します。

cpuguy83 2017年02月09日

@ cpuguy83 @KevinTHU申し訳ありませんが、それは私のせいです。そうです、dockerを再起動するとすべてのコンテナが再起動します。

quexer 2017年02月13日

私は今、VMの1つでこれを定期的に取得しています。興味深いことに、そのうちの1つは、8時間以上放置すると削除可能になりました。これが私の情報です：

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

rlpowell 2017年02月14日

そして、それは再び壊れています。

rlpowell 2017年02月15日

👍3

これが関連しているかどうかはわかりませんが、/ var / log / messagesには次のものがあります。

2月14日16：58：49vriciカーネル：dev_remove：40のコールバックが抑制されました
2月14日16：58：54vriciカーネル：dev_remove：40のコールバックが抑制されました
2月14日16：58：59vriciカーネル：dev_remove：40のコールバックが抑制されました

現在のエラーは次のとおりです。

デーモンからのエラー応答：ドライバーdevicemapperがルートファイルシステムb265eec88a6d1220eab75391bcf4f85bcd687301bfabfa3a2331217918c7377eの削除に失敗しました：デバイスdd81b82c875f4bcef819be83e9344c507965a9e9f48189f08c79fde5a9bde68の削除に失敗しました

rlpowell 2017年02月15日

デバイスはどこかでビジーです。障害が発生した後、次のスクリプトを試して、デバイスがビジー状態になっている可能性がある場所を確認できますか。

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

./find-busy-mnt.sh

./find-busy-mnt.sh dd81b82c875f4bcef819be83e9344c507965a9e9f48189f08c79fde5a9bde681

rhvgoyal 2017年02月16日

rlpowell @ vrici> sudo bash /tmp/find-busy-mnt.sh b2205428f34a0d755e7eeaa73b778669189584977c17df2bf3c3bf46fe98be10
pidが見つかりません
rlpowell @ vrici> sudo docker rm freq_build
デーモンからのエラー応答：ドライバーdevicemapperがルートファイルシステムの削除に失敗しましたb2205428f34a0d755e7eeaa73b778669189584977c17df2bf3c3bf46fe98be10：デバイスの削除に失敗しました5f1095868bbfe85afccf392f6f4fbb8ed4bcfac88a5a8044bb122463b765956a：Device is Bus

rlpowell 2017年02月20日

ああ、それは間違ったハッシュだったようです。

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

それは...非常に奇妙です。まったく関係のないphp-fpmプロセスが、カーネルによってそれらのマウントを開いたままにしていると見なされる理由がわかりません。

rlpowell 2017年02月20日

@rlpowellええ、それがこの問題の背後にある問題全体です。マウントの名前空間が正しく機能しない原因があります。

SEAPUNK 2017年02月20日

動作しているように見える回避策をここで見つけました： //blog.hashbangbash.com/2014/11/docker-devicemapper-fix-for-device-or-resource-busy-ebusy/

これは基本的に、systemddocker.serviceファイルに次の行を追加することを意味します。
MountFlags = private

これは、少なくともデプロイしてから行ったdockerrunの小さなサンプルでは機能するようです。 dockerを完全に理解している人がこのフラグの結果を説明できればいいのですが、dockerの起動後にマウントされたファイルシステムがコンテナーで使用できなくなる可能性があると思いますが、正直なところわかりません。私たちの構成はビルドサーバーで使用するためのものであり、問題なく動作しているようです。

pyssling 2017年02月25日

これはかなり大きな問題であり、Centos 7 / RHELでDockerを事実上使用できなくなります-（そして4か月間開いていましたか？）
ETAはありますか？

paulwilton 2017年02月28日

👍8

最新のRHEL / centosは、docker.serviceファイルにMountFlags = slaveで出荷されます。

rhvgoyal 2017年02月28日

@rhvgoyalこれはhttps ：

これはブランチマスター上にありますが、ブランチ1.13.xと17.03.xにもありません。

私の知る限り、このフラグは以前のサービスユニットにありましたが、削除されました。しかし、その理由はわかりませんでした。たぶん、このフラグは現在の問題を解決しますが、他の問題を作成します。

jcberthon 2017年03月02日

@rlpowell @SEAPUNKこれは私のubuntu-installationには当てはまらないようです：

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

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

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

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

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

smoebody 2017年03月02日

RHEL7がRHEL7.4まで--live-restoreをサポートできない理由と、dockerをホストとは異なるマウント名前空間内で実行する必要がある理由を説明する記事を書きました。

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

rhatdan 2017年03月02日

❤6 👍1

+1別のマウント名前空間で実行し、すべてのDockerマウントをプライベートにします。
ただし、そこにはいくつかの注意が必要な部分があります。

cpuguy83 2017年03月02日

アップストリームDockerにMountFlags=slaveで実行するための適切なフラグがない場合、それはバグであり、コンテナーとホストの間でマウント名前空間がリークする問題を簡単に引き起こし、コンテナーイメージの削除で問題が発生する可能性があります。

rhatdan 2017年03月02日

FWIW、 MountFlags=slaveは、Red Hatのメンテナによるレビューの結果、 https：//github.com/docker/docker/pull/22806で削除されましたが、問題が発生しているようです。元に戻す必要があるかどうか疑問に思っています。 RHEL7.4まで？

thaJeztah 2017年03月02日

はい、削除しましたが、後で問題が発生したため、ディスカッションスレッドの1つで、再度紹介すると結論付けました。私はあなたがすでにそれをしたと思った。それがどのスレッドだったか覚えていない。

rhvgoyal 2017年03月02日

@thaJeztahうん、私たちは間違っていて、追加の問題を見つけました。

rhatdan 2017年03月02日

そして、これらの問題は主に古いカーネルに固有のものでした。新しいカーネルは問題なく動作します。

rhvgoyal 2017年03月02日

オプションについて話し合うためにPRを開きましょう

thaJeztah 2017年03月02日

PRはここで始まりました。 https://github.com/docker/docker/pull/31490

thaJeztah 2017年03月02日

同じ問題、docker 1.10.3、CentOSLinuxリリース7.2.1511
dmesg：
[1732917.246900]デバイスマッパー：ioctl：開いているデバイスDockerを削除できません-8：3-5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78
メッセージ：
4月3日03：32：34A02-R05-I97-106 docker-current：time = "2017-04-03T03：32：34.346374677 + 08：00" level = error msg = "マウントされたレイヤーの削除中にエラーが発生しましたb0b1e839f366086fd7cff564feee385a3aed71a56db90e4c0416517a72c13f2d：デバイスはBusyです「」
4月3日03：32：34A02-R05-I97-106 docker-current：time = "2017-04-03T03：32：34.346597095 + 08：00" level = error msg = "Handler for DELETE /v1.22/containers / b0b1e839f366086fd7cff564feee385a3aed71a56db90e4c0416517a72c13f2dがエラーを返しました：ドライバーdevicemapperがルートファイルシステムb0b1e839f366086fd7cff564feee385a3aed71a56db90e4c0416517a72c13f2dを削除できませんでした

マウント：
/ proc / * / mountsを見つける| xargs grep -E "5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78"
/ proc / 159779 / mounts：/ dev / mapper / docker-8：3-5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 / export / docker / devicemapper / mnt / b3c2bfc1d52638ca89c5bd4c880ac1ca1 swidth = 128、noquota 0 0
/ proc / 159806 / mounts：/ dev / mapper / docker-8：3-5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 / export / docker / devicemapper / mnt / b3c2bfc1d52638ca89c5bd4c880ac1ca1 swidth = 128、noquota 0 0
新しいコンテナ：
docker inspect 8777d36c94ec | grep Pid
「ピッド」：159779、

//私のせいです。解決しました。

foxwang 2017年04月05日

ID「8777d36c94ec」とは何ですか？これは、削除されるコンテナまたはその他のコンテナのコンテナIDですか？

そのため、デバイスはまだコンテナにマウントされているため、ビジーです。したがって、削除されるコンテナはまだ停止していません。または、別のコンテナの場合は、他のコンテナに表示されないようにする必要があります。

マウントポイント「/ export / docker / devicemapper / mnt / ....」とは何で、誰がこれを作成したのかわかりませんか？

rhvgoyal 2017年04月05日

私のMintシステムでは、 17.03.1~ce-0~ubuntu-xenialから17.04.0~ce-0~ubuntu-xenialにアップグレードすると、この問題が非常に頻繁に発生します。

アップグレードする前に、私はそれに遭遇したことがありませんでした。アップグレード後は非常に頻繁でした。 17.03.1にダウングレードすると、問題が解決したようです。

bmbroom 2017年04月14日

このスレッドを読んでいる他の人へのメモと同じように、GoogleからcAdvisorを実行している場合、コンテナを削除しようとするとこの問題が発生します。最初にcAdvisorを停止し、次にコンテナーを削除してから、cAdvisorを再起動する必要があります。

jmwilkinson 2017年04月18日

👍3

@bmbroom同上。私たちは、コンテナを1日中解約するubuntuに基づいてビルドサーバーを実行し（通常はdocker-composeによって駆動されます）、この問題は週に2、3回発生していました。サーバーは、信頼できるサーバーとxenialsが混在しています。最近、17.04.0〜ceへのアップグレードを開始しましたが、現在、これが1日に複数回発生しています。

MountFlags = slaveがubuntuに適用できるかどうかはわかりませんが、次に試しているのはそれです。

ansel1 2017年04月19日

@rhvgoyal
すみません、私のせいです。
他の人はまだ私のコンテナにマウントされています。

foxwang 2017年04月21日

ちょうど同じ問題がありました：

docker：Dockerバージョン17.03.1-ce、ビルドc6d412e
os：Red Hat Enterprise Linux Serverリリース7.3（Maipo）
カーネル：3.10.0-514.6.1.el7.x86_64
ntpd：4.2.6p5

systemctl restart ntpdすると、問題が即座に修正されました。

xeor 2017年04月21日

👍11 😄4 ❤2 🎉2

@xeor
docker.serviceユニットファイル内のMountFlags何ですか？

sfwn 2017年04月23日

/usr/lib/systemd/system/docker.serviceファイルにMountFlagsはありませんが、 systemctl show dockerはMountFlags=0ます。

ntpd.serviceについても同じです。また、持っていることをPrivateTmp=trueの下に[Service]スタンザ（もしその問題を）。

xeor 2017年04月24日

今のところ、MountFlags = slaveで実行します。

rhvgoyal 2017年04月24日

@rhvgoyalは私のdocker.serviceファイルをチェックしました。しかし、あなたの価値はすでに設定されています：

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

最新のredhat（3.10.0-514.16.1.el7）/ docker（1.12.6-16.el7）を使用

MountFlags = privateはどうですか？プライベートとスレーブの違いを説明していただけますか？

phhutter 2017年04月25日

現在、この問題はRHEL / CentOS 7.3、カーネル3.10.0-514.16.1.el7.x86_64、Dockerバージョン17.05.0-ce、ビルド89658beで発生しています。この1年間、この問題は何度も発生しています。

/etc/systemd/system/multi-user.target.wants/docker.serviceにもMountFlagsオプションはありません。そこに「MountFlags = slave」を追加する必要がありますか？

esabol 2017年05月24日

この問題はCentos、RHEL、Ubuntuで発生するというコメントがあります。 Debian、ContainerLinux、SUSEなど、他のオペレーティングシステムはこの特定の問題から安全ですか？

ghost 2017年06月16日

@earwax新しいカーネル（> = 3.15）を使用すると、通常はより適切に機能するはずです。
ただし、このエラーが発生する場所を作成できる状況は常にあります。
また、それを軽減するためにここのコメントにリストされているいくつかの方法があります。

cpuguy83 2017年06月16日

この問題はSUSEで見られますが、解決策が見つかりませんでした...これは主にプロバイダーで発生していることがわかります：AZURE

prachi02 2017年06月19日

dockerdを1.12.6から17.05に更新したときにも、この問題が見つかりました。 '-f'がないと、すべての古いコンテナーを削除できませんでした。これらのコンテナーには、 '-live-restore'構成があるため、dockerdの更新時にすべてが停止されないという共通の機能がありました。ここに問題があると思います。

KevinTHU 2017年06月26日

これは、少なくともCentOS 7では、FYIの17.06でもまだ問題です。

MGD1981 2017年07月03日

👍6

@ MGD1981このバグを修正する必要があります。同じように、centos 7を使用しています。ドッカーを更新する前に作成された古いコンテナーに「デバイスがビジー」の問題があるだけでなく、新しく作成されたコンテナーにも問題があることがわかりました。これは非常に重要です。、およびdocker.serviceに「MountFlags = slave」を追加することで回避します。ただし、このパラメータが他の問題を引き起こすかどうかはわかりません。

KevinTHU 2017年07月04日

ええ、今私たちのQA環境でこれを試してみてください。細心の注意を払います
マウントに。コンテナのFSが
この設定で「忘れられた」、時間の経過とともにホストがディスクでいっぱいになる
死んだコンテナの？

月、2017年7月3日、10：38 PM KevinTHUに[email protected]書きました：

@ MGD1981https ：//github.com/mgd1981このバグは修正する必要があり
同じcentos7を使用すると、古いコンテナだけでなく、
Dockerを更新する前に作成されたものには、「デバイスがビジーです」という問題がありますが、
新しく作成されたコンテナ、これは非常に重要であり、次の方法で回避します。
docker.serviceに「MountFlags = slave」を追加します。しかし、私たちはかどうかわかりません
このパラメータは他の問題を引き起こします。
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/moby/moby/issues/27381#issuecomment-312766596 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/ADzZzStBbgubPK4soa2w5WW_hthYnZwjks5sKaW2gaJpZM4KW5Fn
。

MGD1981 2017年07月04日

@ MGD1981はい、ホスト上にもう使用されていないディスクがあるようです。＃33025を参照

ceecko 2017年07月04日

@ceecko 17.06以降、これは発生しないはずですが、遅延削除/削除を有効にすると、すぐにクリーンアップされない場合があります。

cpuguy83 2017年07月04日

@ cpuguy83いいね！以前のバージョンで残っていた古いディスクもクリーンアップしますか？

ceecko 2017年07月04日

@ cpuguy83はまだ17.06リリースされていますか？（すでに7月なので、17.07？）githubリリースページにはありません。

ravilr 2017年07月05日

@ravilr出ました。リリースはgithub.com/docker/docker-ceから提供されます。

@ceeckoそうは思いません。

cpuguy83 2017年07月05日

@ cpuguy83ありがとう。 17.06のリリースノートには、この問題に関するPRの修正については触れられていないようです。これに対処するための修正は何でしたか？再度、感謝します。

ravilr 2017年07月06日

@ravilrこの：//github.com/moby/moby/pull/31012

thaJeztah 2017年07月06日

CentOS 7（シンプールストレージ付き）で17.06.0-ceを実行していますが、これは最近頻繁に発生しています。

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

AaronDMarasco-VSI 2017年07月07日

それはMountFlags=slave 、@ AaronDMarasco-VSIの有無にかかわらずですか？ CentOS 7.3？

esabol 2017年07月07日

17.06は根本的な問題を修正するのではなく、それを処理するのに優れています。
docker（またはcontainerdなどのサブコンポーネント）が実行していることが問題を悪化させているかどうかを調べています。

cpuguy83 2017年07月07日

@esabolいいえ...プライベート？

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

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

[Service]
MountFlags=private

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

AaronDMarasco-VSI 2017年07月07日

ええと、@ AaronDMarasco-VSI、それをMountFlags=slaveに変更することをお勧めします。これにより、状況が改善されましたが、まだ17.05であり、使用したくない場所を見たと思います。 MountFlags=slaveとdm.use_deferred_removal ？おそらく他の誰かがコメントして確認するでしょう。

esabol 2017年07月08日

私はcentos7.3とカーネル4.10でdocker17.03を使用しています。そして私はこのエラーをたくさん見ています。以下は、MountFlagの詳細です。

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

pntailor 2017年07月13日

👍2

ここでDebian8と同じ問題が発生し、CIが破損します。考えられる回避策はありますか？

thg303 2017年07月16日

@ thg303は、可能であればdockerdeamonをシャットダウンし、ログファイル（rm / var / lib / docker / .....）にあるルートファイルシステムをクリーンアップ/削除してみてください。ただし、前にスナップショット/バックアップを取る必要があります:-)

phhutter 2017年07月16日

ここでFedora25、カーネル4.11.12で同じ問題が発生します。

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

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

jacknlliu 2017年08月06日

dockerがcentos7で更新されるたびに、この問題が発生します。 dockerを再起動すると、すべて正常に動作します。

sandrodz 2017年08月16日

Docker17.06.0-ceを使用したFedora26でも同じです。 dockerを再起動しても問題は解決しませんでした。

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

giovtorres 2017年08月18日

真剣に1年が経ちましたが、このバグはまだここにありますか？

NeckBeardPrince 2017年09月06日

👎5 👍1

@NeckBeardPrinceこのような無意味な解説で時間を無駄にしないでください。
あなたがそれを解決するのを手伝いたいなら、素晴らしい。問題に関するデータをさらに報告したい場合は、すばらしいです。

それ以外に、ここに投稿されているこの問題を回避する方法がいくつかあります。

cpuguy83 2017年09月06日

😄4 👎1

systemdユニットファイルはMountFlags=slave梱されていません

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

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

chasebolt 2017年09月06日

前回この問題が発生したとき、マウントを保持していたのはntpdた。
今日も同じ問題が発生しましたが、今回はホスト上で実行されているmariadbインスタンスが原因でした。

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

マウントを保持しているprocを見つけるための例...

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

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

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

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

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

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

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

mariadbを再起動した後、マウントポイントを手放しましたが、起動時に多くのマウントポイントを取得しました。

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

xeor 2017年09月08日

👍5 🚀1

削除の失敗のほとんどは、マウントポイント（したがってデバイス）が他のマウント名前空間でビジーであることが原因です。カーネルが十分に新しい場合は、提案されたPRに従うことがこの問題に役立つと思います。

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

古いカーネルを実行している場合は、マウントリークの問題を減らすために、プラグイン呼び出しoci-umountを作成しました。

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

rhvgoyal 2017年09月08日

@rhvgoyalこのPRを含めるdriver "devicemapper" failed to remove root filesystemを扱っています。

bjonen 2017年10月13日

👍5

CentOS Linuxリリース7.4.1708（コア）
3.10.0-693.5.2.el7.x86_64
17.06.2-ce

最終的に修正されたように見えます

fitz123 2017年10月24日

Dockerバージョン17.09.0-ceを実行していますが、同じ問題に直面しています。

bjonen 2017年10月25日

Oracle Linuxでこの問題が発生することがあります：dockerバージョン17.03.1-ce（Oracleのリポジトリから）

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

上記はすべてプロジェクトのTDAによって修正されているため、当面は変更できません。

他の環境の90％はCentos 7.3 / 7.4であり、問題は発生していません。

the-nw1-group 2017年10月27日

4.11.9のarchLinux上のDocker17.05でこの問題のインスタンスを解決することができました
に

docker rm -f [myContainer] （通常どおりdriver "devicemapper" failed to remove root filesystem失敗します）
ls /var/lib/docker/devicemapper/mnt/

これにより、コンテナは最終的に消えました（理由はわかりませんが）。

JulianKlug 2017年10月29日

👍10

@MonsieurWaveは見た目と同じくらい信じられないほど、「ls」トリックは他のすべてがうまくいかなかったときに私にとって完璧に機能しました！

Xophe 2017年11月03日

docker rm -f [container]は失敗を報告しますが、最終的にはコンテナとファイルシステムをクリーンアップします。 lsコマンドは赤いニシンです。本当に必要なのは数秒待つことだけです。ただし、それよりも優れているのは、 MountFlags=slaveを使用することです。そして、デバイスマッパーをオフにして、代わりにoverlay2を使用するのが最善です。

bmitchboxboat 2017年11月03日

👍2 😕1

そして、デバイスマッパーをオフにして、代わりにoverlay2を使用するのが最善です。

CentOS 7.x（現在は7.4）でDockerを1年以上使用しています。 Dockerを最初にインストールしたとき、すべての人が、最高のパフォーマンスと安定性を得るには、direct-lvmを備えたdevicemapperを使用する必要があると言っていました。 https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/には、DockerEEを搭載したCentOSでdevicemapperを使用する必要があると記載されています。幸い、Docker CEを使用しているため、overlay2に切り替えることができます。 Dockerの人々は、v1.13.0 / 1のCentOSでのデフォルトのdevicemapperからoverlay2への変更を、ほとんどファンファーレや議論なしにすり抜けたように感じます。 CentOS 7でのoverlay2とdevicemapper（direct-lvm）のパフォーマンス/安定性に関する確かな情報はありますか？私のグーグルはあまり見つかりませんでした....

esabol 2017年11月04日

在庫のCentOS7.2カーネル（3.10.xフランケンシュタイン）で非常に苦労しました。たくさんのクラッシュ。開発環境でKubernetesを実行していたため、コンテナのチャーンは非常に高かったのですが、比較的静かなインストールでも、ストックのCentOS +オーバーレイコンボは非常に不安定でした。 overlay2を使用して4.10以降のアップストリームカーネルを実行する方がはるかに優れています。新しいCentOSリリースを試していません。

「-nftype = 1」でフォーマットされたext4またはXFSである基礎となるファイルシステムを使用する必要があります。不適切にフォーマットされたXFSがある場合、Dockerは実行されますが、結果は予測できません。

rsanders 2017年11月04日

👍1

ええ、私はoverlay2に切り替えてから長い間、overlay2を使用をまだ使用している人にはお勧めします。この問題は別として、devicemapperは一般的にdockerの非常に貧弱なストレージドライバーであることを読みました。

SEAPUNK 2017年11月05日

ntpdを再起動すると、私が抱えていた問題が修正されました...とても混乱しました。 Centos7のdockerに「推奨される」daemon.json構成はありますか？

sharksforarms 2017年11月06日

👍2

いくつかの改善がパイプラインで行われています。

具体的には、これらの他のシステムサービスの問題は、マウント名前空間の設定（これらの他のシステムサービス用）とdockerが自身のマウントをプライベートに保とうとする競合状態のようです... Dockerがマウントがリークしないようにすることを目的としています残念ながら、コンテナは他の場所でリークを引き起こし、実際にはそれらのマウントポイントへのプライベート参照を保持することになります。つまり、手動またはプロセスの再起動時を除いて、これらの名前空間でマウントを解除することはできません。

さらに、runcとdockerの両方でMS_PRIVATEマウント伝播を使用して競合状態に対処するための最近の変更がいくつかあります。
次のバージョンは完璧ですか？おそらくそうではありません...しかし、私はこれが良くなることを期待しています。

cpuguy83 2017年11月06日

👍2

docker 12.1.1で取得しましたが、今は更新する機会がありません。後でどこかで修正されますか？クイックフィックスは、プロセスを強制終了してDockerサービスを再起動することですが..

FelikZ 2017年11月14日

これらのバージョンは、 --live-restoreを含め、私にとっての問題を完全に修正します

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

fitz123 2017年11月14日

👍5

@esabol CentOS 7.4にアップグレードした後、overlay2への切り替えを評価しました。悲しいことに、それは大変な作業です。データの保存に使用できるパーティションはXFSであり、7.4より前のCentOSのデフォルトのXFSフォーマットオプションでは、overlay2をサポートできるように1つのパラメーターが欠落していました（どれを忘れたか）。つまり、XFS上でoverlay2を使用できるようにするには、パーティションを再フォーマットする必要があるということです。そのとき、overlay2に切り替えると、ダウンタイムを回避するために多大な作業が必要になります。最新の7.4カーネル+ Docker 17.09およびLVM構成に関する上記の推奨事項は、ほとんどの場合、問題を回避するのに大いに役立ちました。

注： docker infoは、この特定のオプションなしでXFS上でoverlay2を実行することはサポートされておらず、将来のリリースで削除されるという大きな警告を示しています。

jcberthon 2017年11月30日

https://github.com/moby/moby/pull/34573 17.09.1-ce、17.12.0-ceバージョンでリリースされた修正

srinivassurishetty 2018年03月01日

@jcberthon最近、弾丸を噛んでoverlay2に移行しましたが、とてもうれしく思います。 docker run --rmを実行する単体テストのベンチマークでは、パフォーマンスが40％向上しました。 devmapperの最後のストローは問題＃20401でした。 overlay2への切り替えはそれほど難しくありませんでしたが、十分な空きディスク容量があります。私は、すべての画像をtarballにdocker saveするスクリプトを作成し、別のスクリプトをdocker loadすべてのtarballに作成しました。 2〜3時間で完了しました。面倒なことのように思えますし、十分なディスク容量がない場合もあり得ますが、長期的にはそれだけの価値があると思います。幸運を！

esabol 2018年03月01日

🎉2 👍2 ❤1

これは17.12.1で修正されています

皆さんありがとう。

cpuguy83 2018年03月12日

👍5 ❤2 🎉2

fiexedリリースの前に、物理ノードを再起動すると問題が解決します

elonmia 2018年07月11日

👍1

@ ravilr @ KevinTHUあなたのコメントについてhttps://github.com/moby/moby/issues/27381#issuecomment-277148106およびhttps://github.com/moby/moby/issues/27381#issuecomment-267547259私が観察したRHELのDockerユニットファイルをPrivateTmp=trueすると、問題も修正されます。似たようなものを見た可能性はありますか？

MohdAhmad 2018年09月05日

@MohdAhmadはこれを試したことがありませんが、dockerunitファイルのPrivateTmp = trueはdocker専用であるため、これはおそらく問題ないと思います。この問題をさらに修正できる可能性があります。

KevinTHU 2018年09月19日

同じ問題が見つかりました。フォルダを開いているので、ウィンドウを閉じて解決します。

libaojie 2019年04月18日

Moby: ドライバdevicemapperはルートファイルシステムの削除に失敗しました。デバイスがビジーです

最も参考になるコメント

全てのコメント153件

関連する問題

Moby: ドライバdevicemapperはルートファイルシステムの削除に失敗しました。 デバイスがビジーです

最も参考になるコメント

全てのコメント153件

関連する問題

Moby: ドライバdevicemapperはルートファイルシステムの削除に失敗しました。デバイスがビジーです