由于设备映射器错误，无法运行 Docker 容器

Posted 2023-02-25

【中文标题】由于设备映射器错误，无法运行 Docker 容器

【英文标题】：Can't run Docker container due device mapper error

【发布时间】：2014-09-02 18:54:47

【问题描述】：

我不能再在 Docker 中创建和运行新容器了。 但同时可以运行以前创建的容器。

当我尝试做这样的事情时：

[user@host ~ ] docker run --name=fpm-5.3 debian:jessie
2014/07/12 07:34:08 Error: Error running DeviceCreate (createSnapDevice) dm_task_run failed

来自 docker.log：

2014/07/12 05:57:11 POST /v1.12/containers/create?name=fpm-5.3
[f56fcb6f] +job create(fpm-5.3)
Error running DeviceCreate (createSnapDevice) dm_task_run failed
[f56fcb6f] -job create(fpm-5.3) = ERR (1)
[error] server.go:1025 Error: Error running DeviceCreate (createSnapDevice) dm_task_run failed
[error] server.go:90 HTTP Error: statusCode=500 Error running DeviceCreate (createSnapDevice) dm_task_run failed

dmsetup 状态

docker-8:1-1210426-pool: 0 209715200 thin-pool 352 2510/524288 205173/1638400 - ro discard_passdown queue_if_no_space 

但是它们在磁盘上有很多可用空间。

dmsetup 信息

Name:              docker-8:1-1210426-pool
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        1
Event number:      1
Major, minor:      252, 0
Number of targets: 1

码头信息

Containers: 4
Images: 65
Storage Driver: devicemapper
 Pool Name: docker-8:1-1210426-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 12823.3 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 9.9 Mb
 Metadata Space Total: 2048.0 Mb
Execution Driver: native-0.2
Kernel Version: 3.14.4

码头工人版本

Client version: 1.0.0
Client API version: 1.12
Go version (client): go1.2.2
Git commit (client): 63fe64c
Server version: 1.0.0
Server API version: 1.12
Go version (server): go1.2.2
Git commit (server): 63fe64c

【参考方案1】：

在我们的例子中只需要启动和停止服务。

根据您的系统，您可以运行：

service docker stop
service docker start

或：

sudo systemctl stop docker.service
sudo systemctl start docker.service

或：

sudo /etc/init.d/docker restart

【参考方案2】：

以下是针对 Fedora/RHEL 系统的，因此您需要针对 Debian 进行调整...

# systemctl stop docker.service
# thin_check /var/lib/docker/devicemapper/devicemapper/metadata

如果没有错误，则继续：

# thin_check --clear-needs-check-flag /var/lib/docker/devicemapper/devicemapper/metadata
# systemctl start docker.service
# docker run --name=fpm-5.3 debian:jessie

---

要安装thin_check 命令，运行：

# apt-get install -y thin-provisioning-tools

【讨论】：

谢谢。在此期间，我已切换到 aufs。但是在运行 thing_check 之后一切正常。而且我认为，在 Docker Docs 上制作一些关于切换存储后端和相关问题的“存储信息页面”会很有用。

【参考方案3】：

我一直在用 Debian 8.2 解决这个问题。 我还有其他问题，因为我使用 grsec 运行 4.3.3 内核（默认为 3.16）。

尽管存在 GRSEC 问题（mount 和 chmod 被拒绝），我还是能够运行 docker 并创建一些映像和容器。

然后，我会重新启动，docker 只会吐出错误。 我跑了thin_check，发现是这样的：

元数据很好（我现在不使用精简池，因为 docker 一直告诉我我的精简池不是精简池...） 数据已损坏。

试图修复它，但 Thin_restore 崩溃了。

我意识到：docker daemon ... 正在工作，但无法使用 systemctl stop docker.service 停止。 它说服务已停止但守护进程仍在内存中（ps -elf | grep docker）

为了解决这个问题，我不得不更改 /etc/default/docker 中的 DOCKER_STORAGE_OPTIONS

rm -rf /var/lib/docker
reboot

在启动时，服务启动。 码头工人信息

按预期显示信息。 建立了形象。重新启动，服务再次正常启动。 我认为基本上 docker 守护进程无法停止并使用以下命令将其杀死：

kill <pid>

导致数据文件损坏，因此校验和不匹配。

底线是不要混合和匹配 docker.service 和 docker 守护进程。至少在 Debian/Ubuntu 上。

【讨论】：

我可以确认 docker 在 Jessie 的 一些 devops 测试用例中可能“不稳定”，但现在这是一个 systemd 和 Debian 问题。但是在最新的 Docker 和 aufs（4.4.0-r1 内核）上，一切都像魅力一样（主要在 amazon linux、Debian 和 Gentoo 上）。所以我建议你切换到aufs，它对我来说比dm稳定得多，反正你可以偷看。

不幸的是，我无法切换到 aufs，因为我需要运行 GRSEC 并且 aufs 补丁不喜欢 GRSEC 补丁。我成功地切换到了一个精简池，但由于池已损坏并且 udev 无法再挂载它，所以情况更糟。即使我在重新启动之前停止容器，池仍然会搞砸。

所以，GRSEC 似乎在这里破坏了一些东西。也许只是把机器放在 DMZ 中运行 Docker 的地方或类似的地方？根据我的经验，Docker 对内核构建标志非常敏感，尤其是补丁。

我将尝试 OverlayFS，因为 AUFS 已被弃用，取而代之的是 overlayfs，它应该已经成为内核的一部分。

【参考方案4】：

我遇到了同样的问题，但无法解决。 我在以下位置发现了一些有希望的东西： http://grokbase.com/t/gg/docker-user/1563fzdtm7/docker-docker-runs-out-of-space-when-trying-to-create-a-new-image '默认的 docker 存储驱动程序会为您分配 10GB 的存储块 图片。移至overlayfs 并完全避免这种情况。在那个命令中 启动你的 docker 守护进程只需添加“-s overlay”'

这解决了我的问题。

【讨论】：

不幸的是你不能使用 rpm 或 yum 和 OverlayFS bugzilla.redhat.com/show_bug.cgi?id=1213602

【参考方案5】：

当 docker 分区已满且重启后 docker 将不再启动时，我遇到了这种情况：

# thin_check /var/lib/docker/devicemapper/devicemapper/metadata
examining superblock
examining devices tree
  missing devices: [0, -]
    bad checksum in btree node
examining mapping tree
  thin device 72 is missing mappings [137494, 137594]
    bad checksum in btree node
  thin device 72 is missing mappings [137721, -]
    bad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree nodebad checksum in btree node

我能够通过这个程序进行修复：

# thin_dump -r /var/lib/docker/devicemapper/devicemapper/metadata -o /tmp/metadata.xml
# thin_restore -i /tmp/metadata.xml -o /var/lib/docker/devicemapper/devicemapper/metadata

【讨论】：

转储然后恢复，这是有效的。