描述
无法删除容器,docker 报告Driver devicemapper failed to remove root filesystem. Device is busy
。 这使容器处于Dead
状态。
重现问题的步骤:
docker rm container_id
描述您收到的结果:
显示错误信息: Error response from daemon: Driver devicemapper failed to remove root filesystem ce2ea989895b7e073b9c3103a7312f32e70b5ad01d808b42f16655ffcb06c535: Device is Busy
描述您期望的结果:
容器应该被移除。
您认为重要的其他信息(例如,问题仅偶尔发生):
这在从 1.11.2 升级到 1.12.2 后开始发生并且偶尔发生(10% 的删除)
docker version
:
Client:
Version: 1.12.2
API version: 1.24
Go version: go1.6.3
Git commit: bb80604
Built:
OS/Arch: linux/amd64
Server:
Version: 1.12.2
API version: 1.24
Go version: go1.6.3
Git commit: bb80604
Built:
OS/Arch: linux/amd64
docker info
:
Containers: 83
Running: 72
Paused: 0
Stopped: 11
Images: 49
Server Version: 1.12.2
Storage Driver: devicemapper
Pool Name: data-docker_thin
Pool Blocksize: 65.54 kB
Base Device Size: 107.4 GB
Backing Filesystem: ext4
Data file:
Metadata file:
Data Space Used: 33.66 GB
Data Space Total: 86.72 GB
Data Space Available: 53.06 GB
Metadata Space Used: 37.3 MB
Metadata Space Total: 268.4 MB
Metadata Space Available: 231.1 MB
Thin Pool Minimum Free Space: 8.672 GB
Udev Sync Supported: true
Deferred Removal Enabled: false
Deferred Deletion Enabled: false
Deferred Deleted Device Count: 0
Library Version: 1.02.107-RHEL7 (2016-06-09)
Logging Driver: journald
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge null overlay host
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.305 GiB
Name: us-2.c.evennode-1234.internal
ID: HVU4:BVZ3:QYUQ:IJ6F:Q2FP:Z4T3:MBKH:I4KC:XFIF:W5DV:4HZW:45NJ
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
其他环境详细信息(AWS、VirtualBox、物理等):
我们在其中运行服务器的所有环境 - AWS、gcloud、物理等。
任何容器都会发生这种情况吗? 容器中正在运行什么,您使用哪些选项来启动容器? (例如,您是否使用绑定挂载的目录,您是否使用docker exec
在容器中启动其他进程?)
我们以几乎相同的方式运行所有容器,并且它在其中任何一个上随机发生。
我们不使用docker exec
,也不绑定挂载任何目录。
这是死容器之一的配置:
[
{
"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": ""
}
}
}
}
]
我刚刚注意到这种情况只发生在具有此文件系统Backing Filesystem: ext4
在运行xfs
作为后备文件系统的服务器上似乎不会出现该问题。
@ceecko谢谢,这很有趣
@rhvgoyal这是您这边的已知问题吗?
这在生产中对我们造成了沉重打击:/任何提示如何删除死容器?
@thaJeztah奇怪的是,这只会发生在 ext4 而不是 xfs。 我不知道任何这样的事情。
一般来说,人们报告设备正忙,可能有很多原因。
@ceeko首先确保
@rhvgoyal MountFlags=slave
到目前为止似乎解决了这个问题。 在更改之前创建的容器仍然是一个问题,但到目前为止,新容器似乎没有触发错误。 如果有任何变化,我会与您联系。
顺便说一句,可能值得更新存储驱动程序文档以将其推荐为生产中的最佳实践,因为我找不到任何参考资料。
感谢您的帮助。
这在不久前发生了变化; https://github.com/docker/docker/commit/2aee081cad72352f8b0c37ba0414ebc925b022e8#diff -ff907ce70a8c7e795bde1de91be6fa68(https://github.com/docker/docker/pull/2280,如果这个问题被删除,这个问题可能会被删除)未启用; https://github.com/docker/docker/pull/22806#issuecomment -220043409
我们应该改回默认值吗? @rhvgoyal
@thaJeztah我认为将默认值改回 MountFlags=slave 可能是个好主意。 我们已经做到了。
理想情况下,延迟删除和延迟删除功能应该已经解决了这个问题,并且不需要使用 MountFlags=slave。 但仅延迟删除是不够的。 旧内核缺少一项功能,即使它安装在不同的挂载命名空间中,也可以从挂载命名空间中删除目录。 这就是容器移除可能失败的原因之一。
因此,在旧内核提供该功能之前,最好在从属挂载命名空间中运行 docker 守护进程。
@rhvgoyal即使使用MountFlags=slave
,错误也开始再次出现。 我们将尝试延迟删除和删除,并会回复您。
我们刚刚在xfs
上也遇到了同样的错误。
这是码头工人信息
Containers: 52
Running: 52
Paused: 0
Stopped: 0
Images: 9
Server Version: 1.12.2
Storage Driver: devicemapper
Pool Name: data-docker_thin
Pool Blocksize: 65.54 kB
Base Device Size: 10.74 GB
Backing Filesystem: xfs
Data file:
Metadata file:
Data Space Used: 13 GB
Data Space Total: 107.1 GB
Data Space Available: 94.07 GB
Metadata Space Used: 19.19 MB
Metadata Space Total: 268.4 MB
Metadata Space Available: 249.2 MB
Thin Pool Minimum Free Space: 10.71 GB
Udev Sync Supported: true
Deferred Removal Enabled: true
Deferred Deletion Enabled: true
Deferred Deleted Device Count: 0
Library Version: 1.02.107-RHEL7 (2016-06-09)
Logging Driver: journald
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: host overlay bridge null
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-327.10.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 7.389 GiB
Name: ip-172-31-25-29.eu-west-1.compute.internal
ID: ZUTN:S7TL:6JRZ:HG52:LDLZ:VR5Q:RWVV:IP7E:HOQ4:R55X:Z7AI:P63R
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Insecure Registries:
127.0.0.0/8
我确认错误仍然发生在 1.12.2 上,即使使用MountFlags=slave
和dm.use_deferred_deletion=true
和dm.use_deferred_removal=true
也是如此,尽管频率低于以前。
以下是无法删除的日志 re 1 容器的更多信息:
libcontainerd: container 4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543 restart canceled
error locating sandbox id c9272d4830ba45e03efda777a14a4b5f7f94138997952f2ec1ba1a43b2c4e1c5: sandbox c9272d4830ba45e03efda777a14a4b5f7f94138997952f2ec1ba1a43b2c4e1c5 not found
failed to cleanup ipc mounts:\nfailed to umount /var/lib/docker/containers/4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543/shm: invalid argument
devmapper: Error unmounting device ed06c57080b8a8f25dc83d4afabaccb26d72009dad23a8e87310b873c226b905: invalid argument
Error unmounting container 4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543: invalid argument
Handler for DELETE /containers/4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543 returned error: Unable to remove filesystem for 4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543: remove /var/lib/docker/containers/4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543/shm: device or resource busy
以下消息表明目录删除失败。
remove /var/lib/docker/containers/4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543/shm: device or resource busy
在较旧的内核中,它可能会失败,因为目录安装在其他一些安装命名空间中。 如果您禁用deferred deletion
功能,此消息将停止出现。 但它会变成其他一些错误信息。
这里问题的核心是容器仍在运行,或者它的一些挂载点已经泄漏到其他一些挂载命名空间中。 如果我们能弄清楚它泄漏到哪个挂载命名空间以及它是如何到达那里的,我们可以尝试修复它。
一旦你遇到这个问题,你可以尝试做find /proc/*/mounts | xargs grep "4d9bbd9b4da95f0ba1947055fa263a059ede9397bcf1456e6795f16e1a7f0543"
然后查看哪些 pid 具有与泄漏到其中的容器相关的挂载。 这可能会给出一些想法。
我试过四个容器,它们都死了,由于设备忙而无法移除,但一无所获:/
# find /proc/*/mounts | xargs grep -E "b3070ef60def|62777ad2994f|923a6d20506d|f3e079a9721c"
grep: /proc/9659/mounts: No such file or directory
现在我实际上收到了一条略有不同的错误消息:
# 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
一样。 无法删除此目录,因为它已挂载在其他某个挂载命名空间中。 尝试在 /proc/ 中搜索527ae5
并查看哪个 pid 正在查看此安装点。 我们需要弄清楚在您的设置中为什么容器 rootfs 挂载点泄漏到其他挂载命名空间。
开始了:
# 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
这些pid映射到什么进程? 试试cat /proc/<pid>/comm
或ps -eaf | grep <pid>
这些都是在配置重新加载后关闭的 nginx 工作进程(请参阅上面编辑的评论)。 我想知道为什么他们阻止安装,因为容器不绑定任何卷。
那么 nginx 进程是否在另一个容器中运行? 或者它在主机上运行?
可以跟着做吗。
ls -l /proc/<docker-daemon-pid>/ns/mnt
ls -l /proc/<nginx-pid>/ns/mnt
ls -l /proc/$$/ns/mnt
并粘贴输出。 这里。
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]
您 docker-pid 和 host 似乎都共享相同的挂载命名空间。 这意味着 docker 守护进程正在主机挂载命名空间中运行。 这可能意味着 nginx 在容器启动后的某个时间点启动,并且它似乎在自己的挂载命名空间中运行。 那时挂载点泄漏到 nginx 挂载命名空间中,这阻止了容器的删除。
请确保 MountFlags=slave 正在为您工作。 一旦它工作, /proc/
你是对的。 该主机尚未设置MountFlags=slave
。
一个不同的主机做了,但仍然有死容器。 我现在手动删除了它们,但它们是用MountFlags=slave
。
我会等到情况再次发生,然后在此处发布更新。 谢谢。
现在情况如下 - 我们使用MountFlags=slave
和延迟删除和删除,有时远程 API 会抛出一个错误,即设备正忙且无法删除。 但是,当docker rm container
在错误发生后立即被调用时,它会很好地移除容器。
问题又出现了。
码头工人
# 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
好的,所以 docker-containerd-shim 看到了这个挂载点,因此让它保持忙碌。 我不确定什么是 docker-containerd-shim 以及为什么挂载点在那里泄漏。 谁知道呢。
@crosbymichael你可能知道。
抄送@mrunalp
谢谢你的ping。 我会看一看。
@ceecko你能检查一下这些 docker-containerd-shim 线程/进程的挂载命名空间是什么吗? 我怀疑这些没有与 docker daemon 共享挂载命名空间,它可能应该。
@rhvgoyal他们共享相同的命名空间
码头工人
# ll /proc/16441/ns/mnt
lrwxrwxrwx. 1 root root 0 Nov 4 23:05 /proc/16441/ns/mnt -> mnt:[4026534781]
我检查了三个 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]
我们没有任何现在无法移除的死容器。
问题是每周两次我们定期停止并删除所有容器,并使用相同的配置启动新容器。 在此“重新启动”之前,一些容器最终已死且无法删除。 在常规的“重启”之后,大部分容器最终都死了,但是当所有旧容器都停止时,所有死容器都可以突然删除。
我有同样的问题,但是当我尝试使用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
错误,我很确定不应该发生,因为我使用了哑初始化来启动我的容器。
这些错误是否与此问题有关?
我目前正在为此进行修复。 我在 containerd 中有一个公开的 PR 可以提供帮助。
很难找到一种可重现的方法来测试这个,所以在我完成修复后,你们中的一个人有兴趣测试这个修复吗?
是的,绝对。 我将尝试创建一个可以重现此问题的虚拟机,并在那里尝试修复; 如果这不起作用,那么我将在出现问题的服务器上对其进行测试。
我刚刚创建了一个 VM,我能够(很容易!)重现这个问题。
这就是我使用 Virtualbox 所做的:
systemctl enable docker
,然后重新启动系统docker-compose up -d
systemctl start nginx
docker-compose pull
docker-compose up -d
(它尝试重新创建容器,然后给我两个容器的“设备正忙”错误。停止 nginx 可以让我移除容器。
docker-compose.yml
截至目前(我模仿了我失败的系统的 docker 设置):
我可以根据要求提供对 VM 的访问权限,只需给我一封电子邮件即可将登录信息发送到。
@mlaventure这个问题可以重开吗? 现在我们不知道这个问题是否已经修复。
@SEAPUNK我们将使用此建议的修复程序更新 containerd。 如果您有机会进行测试,我可以为您提供二进制文件供您试用。
当然,我的 VM 处于待机状态。
知道二进制文件什么时候准备好吗?
@SEAPUNK 1.13 的候选版本现在可供测试,并且应该有这个变化; https://github.com/docker/docker/releases
好的,我试试; 谢谢!
我对所有人,
我想我遇到了与此处报告的相同的问题
[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
我最终需要通过 PKGBUILD 手动构建二进制文件,因为它更简单,并且通过调整我可以强制 PKGBUILD 使用特定的容器提交(我设置为 docker/containerd@03e5862ec0d8d3b3f750e19fca3ee367e13c090e):
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/docker #n19
我应该很快就会有修复的结果。
我可能做错了什么,但我现在根本无法启动容器:
哦,我想我得更新 runc...brb 重建
是的,修复似乎不起作用:
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
除非您可以在自己的 VM 中重现此问题,否则我愿意提供对重现此问题的 VM 的访问权限,并为其构建自定义 Docker 包。
我在 CentOs 7 上的 docker 1.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
来自守护进程的错误响应:Driver devicemapper failed to remove root filesystem e1b9cdeb519d2f4bea53a552c8b76c1085650aa76c1fb90c8e22cac9c2e18830:设备忙
我没有使用 docker compose。
我想也许我也遇到了这个错误。
当我们为 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
在运行 dockerd 1.12.4 的 RHEL7.1 上停止/死容器删除/移除期间遇到“设备繁忙”问题,延迟删除和移除启用=true,而 systemd docker.service 单元文件中没有任何 MountFlags。
还看到内核消息,如:
“内核:设备映射器:瘦:删除瘦设备 120 失败。” (120 是被移除容器的 Thinpool 设备的设备 ID)
在所有情况下,被移除容器的 devicemapper Thinpool 设备挂载点被泄露到主机上另一个 pid 的挂载命名空间中,该名称以 MountFlag=private/slave 启动。
因此,看起来很容易泄漏主机挂载命名空间中的挂载点,因为上述系统进程默认取消共享某些挂载命名空间,这些命名空间不能单独更改/控制。
使用 mountflags=slave 运行 dockerd 是这里唯一的解决方案吗? 你也能帮我理解为什么 mountflags=slave (默认为共享)从 docker systemd 单元文件中删除了一段时间。
在什么情况下,使用从挂载点传播运行 dockerd 会破坏其他事情?
谢谢。
RHEL 内核与我们试图修复的上游内核存在差异,这迫使我们在自己的挂载命名空间中运行 dockerd,而在 Fedora 中,内核的工作方式不同,这允许我们在主机命名空间中运行 dockerd。
@rhvgoyal可以为您提供血腥的细节。
@ravilr ,在 rhel/centos 内核上,禁用延迟删除。 内核没有补丁来支持它。
还使用 MountFlags=slave 运行 docker
您可以继续在 rhel/centos 内核上使用延迟删除,这应该可以工作。
顺便说一句,如果您使用 docker-storage-setup 来设置存储,它会自动确定底层内核是否支持延迟删除并相应地设置/取消设置该选项。
@rhvgoyal你知道在删除容器根文件系统失败后有什么方法可以释放空间吗?
@rhvgoyal感谢您的建议。 如果我们继续看到有关容器移除的相关问题,我会按照您的建议尝试并在此处报告。
撞; 您是否需要更多信息来帮助解决此问题?
我自己在 Centos 7 上运行 1.12.5 时遇到了这个问题。
启用 moutflags=slave 以及启用延迟删除和删除为我解决了这个问题。 现在我遇到了这个竞争条件错误: https :
这比强制移除卡住的容器要好 100 倍,但仍然不是很好。
我可以在 xfs 上的 CentOS 7 上重现。
同样的问题,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
关于这个的任何解决方案? 我仍然看到问题,我试图找到保持设备打开的过程失败了。 似乎没有任何进程使繁忙的设备保持打开状态。
谢谢。
(更新我的评论:第一次阅读该线程时不清楚,但看起来启用延迟删除并设置 MountFlags=slave 可能会修复它。我也会将 Docker 更新到 1.13。)
想要解决这个问题的人可以在上面看到@ravilr的评论,详细信息如下:
在所有情况下,被移除容器的 devicemapper Thinpool 设备挂载点被泄露到主机上另一个 pid 的挂载命名空间中,该名称以 MountFlag=private/slave 启动。
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也许我误解了您的评论。
但在我的情况下(ubuntu 14.04),我所要做的就是解决这个问题,就是重新启动 docker 服务本身
( service docker restart
)。 不涉及“ntpd.service”或“systemd-udevd 服务”。
有道理吗?
@quexer当然,重启
@KevinTHU重新启动不会影响任何正在运行的容器。 你可以自己试试。
@quexer这取决于您的配置。 但我怀疑如果您让容器以--live-restore
模式运行,它可能无法解决问题。
默认情况下,Docker 会在退出时停止所有容器,然后如果有任何备份,它也会杀死它们。
@cpuguy83 @KevinTHU对不起,这是我的错。 你说得对,重启 docker 会导致所有容器重启。
我现在突然用我的一个虚拟机定期得到这个。 有趣的是,其中一个在放置 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)
而且它又坏了。
不知道这是否相关,但 /var/log/messages 有:
2 月 14 日 16:58:49 vrici 内核:dev_remove:40 个回调被抑制
2 月 14 日 16:58:54 vrici 内核:dev_remove:40 个回调被抑制
2 月 14 日 16:58:59 vrici 内核:dev_remove:40 个回调被抑制
现在的错误是:
来自守护进程的错误响应:Driver devicemapper 未能删除根文件系统 b265eec88a6d1220eab75391bcf4f85bcd687301bfabfa3a2331217918c7377e:未能删除设备 dd81b82c875f94bcef98c84bc84f98c86e8c86d8c85c86e7f95c85c85c86e95c85c86e96e96e96e96e96e96e95c86e95c86e95c84e96
设备在某处忙碌。 您能否在失败后尝试以下脚本并查看设备可能繁忙的位置。
https://github.com/rhvgoyal/misc/blob/master/find-busy-mnt.sh
./find-busy-mnt.sh
./find-busy-mnt.sh dd81b82c875f4bcef819be83e9344c507965a9e9f48189f08c79fde5a9bde681
rlpowell@vrici> 须藤 bash /tmp/find-busy-mnt.sh b2205428f34a0d755e7eeaa73b778669189584977c17df2bf3c3bf46fe98be10
未找到 pid
rlpowell@vrici> 须藤泊坞窗 rm freq_build
来自守护进程的错误响应:驱动程序 devicemapper 无法删除根文件系统 b2205428f34a0d755e7eeaa73b778669189584977c17df2bf3c3bf46fe98be10:未能删除设备 5f1095868bbfe928f4bfc5ab4bf4b4bf4b4bf4b4bf4868f8c5a8c54bfc5a4bfc5a4bf5a4bf5a4bf5a4bf5a4bf5a4bf5a4bf5aaaa86f95aaaaaaaaaaaaaaa73bf88586
哦,看起来那是错误的哈希。
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是的,这就是这个问题背后的全部问题。 某些原因导致挂载命名空间无法正常工作。
我在这里找到了一个可行的解决方法: http :
这基本上意味着将以下行添加到您的 systemd docker.service 文件中:
MountFlags=私有
这似乎有效,至少对于我自部署以来所做的 docker 运行的小样本而言。 如果完全了解 docker 的人可以解释这个标志的后果,那就太好了,我怀疑在 docker 启动后安装的文件系统可能无法用于容器,但老实说我不知道。 我们的配置是在构建服务器上使用的,看起来一切正常。
这个非常重要的问题,有效地使 docker 在 Centos 7/RHEL 上无法使用 - (并且已经开放了 4 个月?)
任何预计到达时间?
最新的 RHEL/centos 应该在 docker.service 文件中附带 MountFlags=slave。
@rhvgoyal情况并非如此: https :
这是在分支 master 上,但分支 1.13.x 和 17.03.x 也没有它。
据我所知,这个标志在以前的服务单位中,但已被删除。 但我没有找到原因。 也许这个标志解决了当前的问题,但会产生其他问题。
@rlpowell @SEAPUNK在我的 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
我写了一篇文章解释了为什么 RHEL7 在 RHEL7.4 之前不能支持 --live-restore 以及为什么 docker 应该在与主机不同的挂载命名空间中运行。
+1 我想使用不同的挂载命名空间运行,并将所有 docker 挂载设为私有。
不过,那里有一些棘手的地方。
如果上游 docker 没有在MountFlags=slave
运行的正确标志,那么这是一个错误,并且很容易引发容器和主机之间挂载命名空间泄漏的问题,并可能导致删除容器图像的问题。
FWIW,红帽维护者审查后,在https://github.com/docker/docker/pull/22806中删除了MountFlags=slave
,但看起来它引起了问题,所以想知道是否应该恢复直到 RHEL7.4?
是的,我们已经删除了它,后来它引起了问题,因此在一个讨论线程中我们得出结论,让我们重新引入它。 我以为你已经做到了。 不记得是哪个线程了。
@thaJeztah 是的,我们错了,发现了其他问题。
这些问题主要是针对旧内核的。 较新的内核工作得很好。
让我打开一个 PR 来讨论选项
同样的问题,docker 1.10.3,CentOS Linux 7.2.1511
邮箱:
[1732917.246900] 设备映射器:ioctl:无法删除打开的设备 docker-8:3-5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef788
留言:
4 月 3 日 03:32:34 A02-R05-I97-106 docker-current: time="2017-04-03T03:32:34.346374677+08:00" level=error msg="删除挂载层时出错 b0b1e839f36e839f37feeffed856e37edb756e37edb75a37edb75a3c6edb75a36edb76e35c5a36edb75a36edb36e35c5a36edb36e35c5a36edb75a3edb36e32f32:32:34.346374677+08:00 ”
4 月 3 日 03:32:34 A02-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 未能删除根文件系统
山:
查找 /proc/*/mounts | xargs grep -E "5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78"
的/ proc / 159779 /安装件是:/ dev /映射器/搬运工-8:3-5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 /出口/搬运工/ devicemapper的/ mnt / b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 XFS RW,relatime,nouuid,attR2位,inode64,logbsize = 64K,苏尼特= 128, swidth=128,noquota 0 0
的/ proc / 159806 /安装件是:/ dev /映射器/搬运工-8:3-5242884-b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 /出口/搬运工/ devicemapper的/ mnt / b3c2bfc1d52638ca89c5bd4c880ac1ca1b596e574bcda09042eaafef74866f78 XFS RW,relatime,nouuid,attR2位,inode64,logbsize = 64K,苏尼特= 128, swidth=128,noquota 0 0
新容器:
码头工人检查 8777d36c94ec|grep Pid
“Pid”:159779,
//我的错,已经解决了。
什么是 ID“8777d36c94ec”? 这是正在移除的容器或其他容器的容器 ID?
所以设备很忙,因为它仍然安装在容器中。 因此,被移除的任一容器尚未停止。 或者如果它是不同的容器,那么它在其他容器中不应该是可见的。
不确定挂载点“/export/docker/devicemapper/mnt/....”是什么以及谁创建的?
在我的 Mint 系统上,从17.03.1~ce-0~ubuntu-xenial
升级到17.04.0~ce-0~ubuntu-xenial
会导致此问题非常频繁地发生。
在升级之前,我从未遇到过。 之后升级是非常频繁的。 降级回 17.03.1 似乎已经解决了。
正如其他人阅读此线程的说明一样,如果您正在运行来自 Google 的 cAdvisor,您将在尝试删除容器时看到此问题。 首先你需要停止 cAdvisor,然后移除容器,然后再次启动 cAdvisor。
@bmbroom同上。 我们运行基于 ubuntu 的构建服务器,它整天搅动容器(通常由 docker-compose 驱动),我们每周都会看到几次这个问题。 服务器是trusty 和xenials 的混合体。 我们最近开始升级到 17.04.0~ce,现在每天都会看到这种情况发生多次。
我不清楚 MountFlags=slave 是否适用于 ubuntu,但这就是我接下来要尝试的。
@rhvgoyal
对不起,我的错。
其他人仍然安装在我的容器中。
刚刚遇到了同样的问题:
执行systemctl restart ntpd
立即解决了问题。
@xeor
你在 docker.service 单元文件中的MountFlags
什么?
我的/usr/lib/systemd/system/docker.service
文件中没有MountFlags
,但systemctl show docker
显示MountFlags=0
。
ntpd.service
。 在[Service]
节下也有PrivateTmp=true
(如果有的话)。
现在使用 MountFlags=slave 运行。
@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 怎么样? 你能解释一下 private 和 slave 之间的区别吗?
我目前在 RHEL/CentOS 7.3,内核 3.10.0-514.16.1.el7.x86_64,Docker 版本 17.05.0-ce,构建 89658be 上看到这个问题。 在过去的一年里,我们一直在看到这个问题。
我们在 /etc/systemd/system/multi-user.target.wants/docker.service 中也没有 MountFlags 选项。 我们应该在那里添加“MountFlags=slave”吗?
我看到评论说这个问题发生在 Centos、RHEL 和 Ubuntu 中。 其他操作系统是否可以避免此特定问题,例如 Debian、ContainerLinux 或 SUSE?
@earwax任何具有较新内核(> = 3.15)的东西通常都应该能更好地工作。
但总有一些情况是您可以在发生此错误的地方创建的。
此外,这里的评论中列出了几种方法来缓解它。
我在 SUSE 上看到了这个问题......但找不到解决方案......我看到这主要发生在提供者上:AZURE
当我们将 dockerd 从 1.12.6 更新到 17.05 时,我们也发现了这个问题。 没有'-f'就不能删除所有旧容器,这些容器有一个共同的特点,它们在我们更新dockerd时都不会被停止,因为我们有'--live-restore'配置。 我认为这里有一些问题。
这在 17.06 中仍然是一个问题,仅供参考,至少在 CentOS 7 中是这样。
@MGD1981这个bug需要修复,我们也是用centos 7,发现不仅更新docker之前创建的旧容器有“设备繁忙”的问题,新创建的容器也有问题,这个真的很关键,我们通过向 docker.service 添加“MountFlags=slave”来解决这个问题。 但是,我们不知道这个参数是否会带来一些其他问题。
是的,现在在我们的 QA 环境中尝试这个。 会密切关注
到坐骑。 容器的 FS 是否存在潜在风险
“忘记”了这个设置,随着时间的推移用磁盘填充主机
死容器?
2017 年 7 月 3 日星期一晚上 10 点 38 分,KevinTHU通知@github.com 写道:
@MGD1981 https://github.com/mgd1981这个bug需要修复,我们是
用centos 7也一样,发现不光是旧容器
在更新 docker 之前创建的有“设备正忙”的问题,而且还有
新创建的容器,这真的很关键,我们解决了它
将“MountFlags=slave”添加到 docker.service。 然而,我们不知道
这个参数会带来一些其他的问题。—
你收到这个是因为你被提到了。
直接回复本邮件,在GitHub上查看
https://github.com/moby/moby/issues/27381#issuecomment-312766596或静音
线程
https://github.com/notifications/unsubscribe-auth/ADzZzStBbgubPK4soa2w5WW_hthYnZwjks5sKaW2gaJpZM4KW5Fn
.
@MGD1981是的,主机上似乎有不再使用的磁盘。 见#33025
@ceecko从 17.06 开始,这不应再发生,尽管如果您启用延迟删除/删除,则可能不会立即清除它。
@cpuguy83不错! 它会清理以前版本留下的旧磁盘吗?
@cpuguy83 17.06 发布了吗? (已经是 7 月了,所以是 17.07?)在 github 发布页面中找不到它。
@ravilr出来了。 发布来自 github.com/docker/docker-ce。
@ceecko我不这么认为。
@cpuguy83谢谢。 17.06 的发行说明似乎没有提及有关此问题的任何公关修复。 解决这个问题的方法是什么? 再次感谢。
@ravilr这个 PR https://github.com/moby/moby/pull/31012
我在 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
这是有或没有MountFlags=slave
,@AaronDMarasco-VSI 吗? CentOS 7.3?
17.06 没有解决根本问题,它只是更好地处理它。
我正在查看 docker(或诸如 containerd 之类的一些子组件)是否正在做一些加剧问题的事情。
@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,我建议将其更改为MountFlags=slave
,这改善了我们的情况,但我们仍在 17.05 上,我想我看到了您不想使用的地方MountFlags=slave
与dm.use_deferred_removal
? 也许其他人会评论并确认。
我在 centos 7.3 和内核 4.10 上使用 docker 17.03。 我一直看到这个错误很多。 下面是有关 MountFlag 的更多详细信息。
# systemctl show docker | grep Private
PrivateTmp=no
PrivateNetwork=no
PrivateDevices=no
# systemctl show docker | grep Mount
MountFlags=0
Debian 8 也有同样的问题。它破坏了我们的 CI,有什么可能的解决方法吗??
@thg303尝试关闭您的 dockerdeamon,如果可能,并尝试清理/删除出现在您的日志文件 (rm /var/lib/docker/..... ) 中的根文件系统。 但是你应该在 :-) 之前拍摄快照/备份
Fedora 25 内核 4.11.12 也有同样的问题。
Containers: 5
Running: 0
Paused: 0
Stopped: 5
Images: 16
Server Version: 17.06.0-ce
Storage Driver: devicemapper
Pool Name: docker-253:2-5373989-pool
Pool Blocksize: 65.54kB
Base Device Size: 21.47GB
Backing Filesystem: xfs
Data file: /dev/loop1
Metadata file: /dev/loop2
Data Space Used: 59.33GB
Data Space Total: 107.4GB
Data Space Available: 48.05GB
Metadata Space Used: 76.11MB
Metadata Space Total: 2.147GB
Metadata Space Available: 2.071GB
Thin Pool Minimum Free Space: 10.74GB
Udev Sync Supported: true
Deferred Removal Enabled: false
Deferred Deletion Enabled: false
Deferred Deleted Device Count: 0
Data loop file: /var/lib/docker/devicemapper/devicemapper/data
Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
Library Version: 1.02.136 (2016-11-05)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: cfb82a876ecc11b5ca0977d1733adbe58599088a
runc version: 2d41c047c83e09a6d61d464906feb2a2f3c52aa4
init version: 949e6fa
Security Options:
seccomp
Profile: default
Kernel Version: 4.11.12-200.fc25.x86_64
Operating System: Fedora 25 (Workstation Edition)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.703GiB
Name: wayland
ID: 3T2X:CMFA:53Y2:27FL:RBMD:FHMH:32QE:2DKL:L256:O2GJ:LT2X:N4DD
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Http Proxy: http://127.0.0.1:8118/
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: devicemapper: usage of loopback devices is strongly discouraged for production use.
Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
每次在 centos7 上更新 docker 时,我都会遇到这个问题。 我重新启动 docker,然后一切正常。
我在 Fedora 26 和 Docker 17.06.0-ce 上也是如此。 重新启动 docker 并没有解决问题。
$ systemctl show docker | grep Private
PrivateTmp=no
PrivateDevices=no
PrivateNetwork=no
PrivateUsers=no
$ systemctl show docker | grep Mount
MountFlags=0
MountAPIVFS=no
认真对待一年了,这个错误仍然存在?
@NeckBeardPrince请不要在这种毫无意义的评论上浪费我们的时间。
如果您愿意帮助解决它,那就太好了。 如果您想报告有关该问题的更多数据,那就太好了。
除此之外,这里发布了几种解决此问题的方法。
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
上次我遇到这个问题时,是ntpd
持有坐骑。
今天,我遇到了同样的问题,这一次,是主机上运行的mariadb
实例是原因所在。
查找持有坐骑的 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
大多数删除失败是由于挂载点(因此 device )在其他一些挂载命名空间中忙。 如果内核足够新,我认为遵循提议的 PR 将有助于解决这个问题。
https://github.com/moby/moby/pull/34573
如果您运行的是旧内核,那么我们编写了一个插件调用 oci-umount 来减少挂载泄漏问题。
@rhvgoyal您是否计划在哪个driver "devicemapper" failed to remove root filesystem
。
CentOS Linux 版本 7.4.1708(核心)
3.10.0-693.5.2.el7.x86_64
17.06.2-ce
看起来它终于修复了
我们正在运行 Docker 版本 17.09.0-ce,但仍然面临同样的问题。
我们偶尔会在 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,我们在那里没有看到这个问题。
刚刚在 4.11.9 上的 arch Linux 上使用 Docker 17.05 设法解决了这个问题的一个实例
经过
docker rm -f [myContainer]
(像往常一样以driver "devicemapper" failed to remove root filesystem
失败)ls /var/lib/docker/devicemapper/mnt/
这使得容器最终消失了(但不知道为什么)。
@MonsieurWave看起来很不可思议,当其他一切
docker rm -f [container]
将报告失败,但最终会清理容器和文件系统。 ls
命令是一条红鲱鱼,您真正需要的只是等待几秒钟。 但比这更好的是使用MountFlags=slave
。 最好是关闭 devicemapper 并改用overlay2。
最好是关闭 devicemapper 并改用overlay2。
我们已经在 CentOS 7.x(目前为 7.4)上使用 Docker 一年多了。 当我们第一次安装 Docker 时,所有人都说你必须使用 devicemapper 和 direct-lvm 以获得最佳性能和稳定性。 https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/仍然说你必须在 CentOS 上使用 devicemapper 和 Docker EE。 幸运的是,我们使用 Docker CE,所以我们可以切换到 overlay2。 我觉得 Docker 人员在 v1.13.0/1 中的 CentOS 上从 devicemapper 到 overlay2 的默认更改中滑倒了,几乎没有大张旗鼓或讨论。 在 CentOS 7 上,overlay2 与 devicemapper(direct-lvm)的性能/稳定性是否有任何可靠的信息? 我的谷歌搜索没有找到太多......
我们在 CentOS 7.2 内核(他们的 3.10.x frankenstein)上度过了一段非常糟糕的时光。 很多崩溃。 我们在开发环境中运行 Kubernetes,因此容器的流失率非常高,但即使在相对安静的安装中,我们也发现 CentOS+overlay 组合非常不稳定。 使用 overlay2 运行 4.10+ 上游内核要好得多。 还没有尝试过更新的 CentOS 版本。
您将需要使用使用“-n ftype=1”格式化的 ext4 或 XFS 基础文件系统。 如果您的 XFS 格式不正确,Docker 将运行,但结果将是不可预测的。
是的,我早就切换到overlay2,并推荐任何仍在使用可以使用overlay2切换的devicemapper的人,因为即使不考虑这个问题,我也读到devicemapper对于docker来说是一个非常糟糕的存储驱动程序。
重新启动 ntpd 解决了我遇到的问题......太混乱了。 Centos7 上的 docker 是否有“推荐”的 daemon.json 配置?
一些改进正在进行中。
具体来说,这些其他系统服务的问题似乎是设置挂载命名空间(对于那些其他系统服务)和 docker 试图将自己的挂载保密的竞争条件......目的是让 Docker 防止它的挂载泄漏到容器,不幸的是它在其他地方导致泄漏,实际上最终持有对这些挂载点的私有引用,这意味着它们不能在这些命名空间中卸载,除非手动或进程重新启动。
此外,最近在 runc 和 docker 中使用 MS_PRIVATE 挂载传播处理竞争条件的一些更改。
下个版本会完美吗? 可能不会……但我确实希望这会变得更好。
我在docker 12.1.1 上得到了与
这些版本完全解决了我的问题,包括--live-restore
CentOS 7.4.1708 (3.10.0-693.5.2.el7.x86_64)
Docker 17.09.0-ce
@esabol我们已经评估了在升级到 CentOS 7.4 后切换到 overlay2。 可惜工作量太大了。 我们可以用来存储数据的分区是 XFS,在 7.4 之前,CentOS 默认的 XFS 格式化选项缺少一个参数(我忘记了哪个)能够支持overlay2。 所以这意味着我们必须重新格式化分区才能在 XFS 之上使用 overlay2。 那时切换到overlay2会花费我们太多的工作来避免停机,而最新的7.4内核+ Docker 17.09和上面对LVM配置的建议在大多数情况下帮助避免了这个问题。
注意: docker info
显示了一个很大的警告,即不支持在没有此特定选项的情况下在 XFS 上运行 overlay2,并将在未来版本中删除。
https://github.com/moby/moby/pull/34573修复在 17.09.1-ce、17.12.0-ce 版本中发布
@jcberthon我们最近硬着头皮过渡到了overlay2,我很高兴我们做到了! 在我们执行docker run --rm
单元测试的基准测试中,性能提高了 40%。 我们对 devmapper 的最后一根稻草是问题 #20401。 切换到overlay2 并不难,但我们有足够的可用磁盘空间。 我写了一个脚本到docker save
我们所有的图像到 tarball 和另一个脚本到docker load
所有的 tarball。 我们在 2-3 小时内完成。 我知道这看起来很麻烦,如果您没有足够的磁盘空间,它可能会很麻烦,但从长远来看,我认为这是值得的。 祝你好运!
这已在 17.12.1 中修复
谢谢大家。
在fixed release之前,重启物理节点即可解决问题
@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从未尝试过,但我认为这可能没问题,因为 docker 单元文件中的 PrivateTmp=true 仅适用于 docker,甚至可以更好地解决这个问题。
我发现同样的问题。 因为我打开文件夹,关闭窗口来解决它。
最有用的评论
刚刚遇到了同样的问题:
执行
systemctl restart ntpd
立即解决了问题。