@vieiraマシンを再起動して、まだ問題が発生する場合はお知らせください。

上記の手順は、マシンを再起動した後でも再現可能です。

@alexlarssonご覧いただけますか？ デバイスマッパーに関連しているようです

この問題は、デバイスマッパーに関連しているようです。 私はそれが本当に何か他のものだと思います。
これを試してみましたが、問題は「dockerの停止」部分です。 dockerデーモンをctrl-cするだけで、コンテナーを適切に停止しようとしますが、コンテナーの停止に成功することはないようです。 だから、私はDockerを強制的に死なせるためにさらに数回ctrl-cします。

この時点では、コンテナ（テール）はまだ実行されているため、デバイスマッパーデバイスがマウントされます。つまり、再度マウントしたり、削除したりすることはできません。 これが、これらの操作が失敗する理由です。

@alexlarssonこれがうまくいかなくなったら、システムをクリーンアップする簡単な方法を知っていますか？

さて、暴走したコンテナプロセスを見つけたら、それを強制的に強制終了することができます。

@vieiraアンマウントできます：
umount / var / lib / docker / devicemapper / mnt / c39206003c7ae8992a554a9ac2ea130327fc4af1b2c389656c34baf9a56c84b5

コンテナを再起動すると、動作するはずです

Dockerが-dと-rで開始されていることがわかります。 まず、dockerを再起動しても、コンテナーは再起動されません。 次に、上記のエラーが発生します（コンテナを起動しようとしたとき）。

私のcentos6.5はまだepelから1.0.0.6を取得しています。 これは1.0でバグとして識別され、1.1で修正されたことがありますか？ 誰か確認してもらえますか？

ありがとう

みなさん、こんにちは。1.1.1ではまだ修正されていません。
元の投稿の手順は引き続き適用されます。

Error response from daemon: Cannot start container 5e9bde9b409b: 
Error getting container 5e9bde9b409b001bcc685c0b478e925a53a03bab8d8ef3210bf24aa39410e30d 
from driver devicemapper: 
Error mounting '/dev/mapper/docker-253:0-267081-5e9bde9b409b001bcc685c0b478e925a53a03bab8d8ef3210bf24aa39410e30d' 
on 
'/var/lib/docker/devicemapper/mnt/5e9bde9b409b001bcc685c0b478e925a53a03bab8d8ef3210bf24aa39410e30d': 
device or resource busy

私もたくさん手に入れていますが、ある意味でコンテナを削除しているようです（同じ名前で新しいコンテナを開始できるという意味で）

この問題の回避策はありますか？

回避策も探しています。

dockerデーモンが問題を修正する前に、すべてのコンテナーを停止するようです。

回避策として、このpre-stopブロックをupstartジョブに追加しました。

pre-stop script
    /usr/bin/docker ps -q | xargs /usr/bin/docker stop
end script

これが私のデバッグ手順の要点です： https ：

@rochacon回避策をありがとうございます。 今日または明日1.2でテストします（1.1.1でテストしたようですよね？）。 それがうまくいくことを願っています。

@vieira私も1.2.0で試しましたが、同じ結果です。

4週間実行した後、コンテナの1つが停止しました...理由がわかりません...根本原因を見つけるにはどうすればよいですか？

とにかく、私は同じ問題を抱えていました...それは@aroragaganからの提案で解決しました：umount、 ところで私は

root<strong i="8">@pppdc9prd3ga</strong> mdesales]# docker start federated-registry
Error response from daemon: Cannot start container federated-registry: Error getting container 4841fcb6e51f4e9fcd7a115ac3efae4b0fd47e4f785c735e2020d1c479dc3946 from driver devicemapper: Error mounting '/dev/mapper/docker-253:0-394842-4841fcb6e51f4e9fcd7a115ac3efae4b0fd47e4f785c735e2020d1c479dc3946' on '/var/lib/docker/devicemapper/mnt/4841fcb6e51f4e9fcd7a115ac3efae4b0fd47e4f785c735e2020d1c479dc3946': device or resource busy
2014/10/17 21:04:33 Error: failed to start one or more containers

[root<strong i="9">@pppdc9prd3ga</strong> mdesales]# docker version
Client version: 1.1.2
Client API version: 1.13
Go version (client): go1.2.2
Git commit (client): d84a070/1.1.2
Server version: 1.1.2
Server API version: 1.13
Go version (server): go1.2.2
Git commit (server): d84a070/1.1.2

[root<strong i="10">@pppdc9prd3ga</strong> mdesales]# umount /var/lib/docker/devicemapper/mnt/4841fcb6e51f4e9fcd7a115ac3efae4b0fd47e4f785c735e2020d1c479dc3946

[root<strong i="11">@pppdc9prd3ga</strong> mdesales]# docker start federated-registry
federated-registry

これは、12.04から14.04にアップグレードされたEC2Ubuntuシステムの1.3.0で発生しています。 私の開発インスタンスはVagrantへの直接14.04インストールであり、この問題はありません。 コンテナーをアンマウントしてから再起動することは機能しているように見えますが、インスタンスの再起動時またはDockerの再起動時にコンテナーを自動的に再起動するように構成するという目的は無効になります。 動作しているシステムと動作していないシステムが利用できるので、サポートパッケージのバージョンなどについてさらに情報があれば教えてください。

Linuxカーネル3.13または3.14のいずれかを使用するdocker1.3 Ubuntu14.04で同じ問題が発生します。

@srobertsonは、「デーモンの再起動時にコンテナが再起動されない」ということですか？ 新しい_per-container_restart-policyを使用していますか？ デーモン全体の-r / --restart=trueがDocker1.2で削除されたため

新しい（コンテナごとの）再起動ポリシーについては、 CLIリファレンスで説明されてい

+ 1、3.17.2-1-ARCHカーネルを搭載したdocker 1.3 @ ArchLinuxx86_64でこの問題が発生しました。

$ docker --version
Docker version 1.3.1, build 4e9bbfa

Umountは問題を解決します。

umountは回避策ですが、問題が解決するとは言えません。 コンテナが実行されている状態でデーモンを再起動するだけで、問題が再現されます。

umountは、次のDockerバージョンでも機能します。

atc@li574-92> docker --version
Docker version 1.3.1, build 4e9bbfa

最初にdockerデーモンを停止しました。

umount /dev/mapper/docker-202\:0-729439-a7c53ae579d02aa7bb3aeb2af5f2f79c295e1f5962ec53f16b73896bb3970635 

@ mlehner616はい、その通りです。 申し訳ありませんが、もちろんこれは回避策であり、解決策ではありません。 それは言葉の悪い選択でした。

これも修正してほしいです。 =）

fyi、unmountenは私のために働きませんでした。 / etc / mtabにマウントが見つからないというエラーが表示されます
Dockerバージョン1.0.0、RHEL6.5で63fe64c / 1.0.0をビルド

Dockerデーモンが戻ってきたときに、古いマウントを自動的にアンマウントすることで回避しました。 私はubuntuの大きな/etc/init/docker.confにパッチを当てたくなかったので、代わりに/etc/default/dockerに小さな行を入れました。

cat /proc/mounts | grep "mapper/docker" | awk '{print $2}' | xargs -r umount

それでうまくいくようです。 私はそれをupstartに実際のDockerコンテナーの開始と再生成を管理させることと組み合わせたので、 service docker restart後、すべてのコンテナーが戻ってきます。

ありがとう、 @ jypma 、それは私にとってもトリックをしました！

_review session_ with @unclejack

この問題は、「デバイスまたはリソースがビジー」またはEBUSYレポートの大部分のトラッカーとして使用します。

この問題は、他の問題と同様に、dockerデーモンのマウント名前空間を適切に処理することで軽減されます。 現在、マウント名前空間のデフォルト処理はないため、このEBUSYのような問題があります。

私たちはそれを処理するための公式の解決策に取り組んでいますが、あなたが自分で適用できる回避策があります。 http://blog.hashbangbash.com/2014/11/docker-devicemapper-fix-for-device-or-resource-busy-ebusy/を参照してください

ストックfreeipaイメージを使用して、この問題にも遭遇したことを確認します。 Dockerサービスを停止し、ipaコンテナーを使用して再起動しようとすると、次のようになりました。

$ docker start ipa
Error response from daemon: Cannot start container ipa: Error getting container 98f224de38a0879b8a628179fa29a53b314dfada8c4c2e018113f0affa76f9d2 from driver devicemapper: Error mounting '/dev/mapper/docker-253:0-786581-98f224de38a0879b8a628179fa29a53b314dfada8c4c2e018113f0affa76f9d2' on '/var/lib/docker/devicemapper/mnt/98f224de38a0879b8a628179fa29a53b314dfada8c4c2e018113f0affa76f9d2': device or resource busy
2015/01/11 21:44:38 Error: failed to start one or more containers

「マウント」をアンマウントすると、コンテナを再起動できるように問題が回避されました。

$ umount /var/lib/docker/devicemapper/mnt/98f224de38a0879b8a628179fa29a53b314dfada8c4c2e018113f0affa76f9d2

$ docker start ipa
ipa

以下を使用します。

$  docker version
Client version: 1.3.2
Client API version: 1.15
Go version (client): go1.3.3
Git commit (client): 39fa2fa/1.3.2
OS/Arch (client): linux/amd64
Server version: 1.3.2
Server API version: 1.15
Go version (server): go1.3.3
Git commit (server): 39fa2fa/1.3.2

$ lsb_release -i -d
Distributor ID: CentOS
Description:    CentOS release 6.6 (Final)

umountは私の問題を修正しました

docker --version
Dockerバージョン1.3.2、ビルド39fa2fa

したがって、次の回避策は、私のユースケースではもう少し永続的な回避策です。
私は厳密にAmazonlinux（RedHat6-Like）を使用しているので、initスクリプトにわずかな変更を加えました（dockerが更新されると上書きされる可能性があります）。基本的に、これは通常どおりdockerを停止し、残りのdockerマウントをチェックします。 、もしあれば、それらをアンマウントします。 YMMV

_ / etc / init.d / docker_
lib変数の追加（行〜28）

prog="docker"
exec="/usr/bin/$prog"
# Adding lib variable here
lib="/var/lib/$prog"
pidfile="/var/run/$prog.pid"
lockfile="/var/lock/subsys/$prog"
logfile="/var/log/$prog"

停止機能へのumountブロックの追加（行〜77）

stop() {
    echo -n $"Stopping $prog: "
    killproc -p $pidfile -d 300 $prog
    retval=$?
    echo
    [ $retval -eq 0 ] && rm -f $lockfile

    # BEGIN UMOUNT BLOCK
    if [ $(df | grep $lib | awk '{print $1}' | wc -l) -gt 0 ]; then
        umount $(df | grep $lib | awk '{print $1}')
    fi
    # END UMOUNT BLOCK
    return $retval
}

ストレージドライバーとしてデバイスマッパーを使用しているdocker1.4.1で同じ問題が発生しています。 Dockerからログファイルを介してパニックスタックトレースを収集することができました。

環境

$ cat / etc / * release
DISTRIB_ID = Ubuntu
DISTRIB_RELEASE = 14.04
DISTRIB_CODENAME = trusty
DISTRIB_DESCRIPTION = "Ubuntu 14.04.1 LTS"
NAME = "Ubuntu"
VERSION = "14.04.1 LTS、Trusty Tahr"
ID = ubuntu
ID_LIKE = debian
PRETTY_NAME = "Ubuntu 14.04.1 LTS"
VERSION_ID = "14.04"
HOME_URL = " http://www.ubuntu.com/ "
SUPPORT_URL = " http://help.ubuntu.com/ "
BUG_REPORT_URL = " http://bugs.launchpad.net/ubuntu/ "

$ dockerバージョン
sudo：ホストip-172-30-0-39を解決できません
クライアントバージョン：1.4.1
クライアントAPIバージョン：1.16
Goバージョン（クライアント）：go1.3.3
Gitコミット（クライアント）：5bc2ff8
OS / Arch（クライアント）：linux / amd64
サーバーバージョン：1.4.1
サーバーAPIバージョン：1.16
Goバージョン（サーバー）：go1.3.3
Gitコミット（サーバー）：5bc2ff8

$ tail -f / var / log / upstart / docker
..。
INFO [143413] -job execResize（3dfcbc075227d5b3f0115bd73a1fea4a56a2c0fc68190d84b6d88e93938b4121、37、130）
2015/01/22 22:29:22 http：パニックサービング@：ランタイムエラー：無効なメモリアドレスまたはnilポインタの逆参照
goroutine 1932 [実行中]：
net / http.func・011（）
/usr/local/go/src/pkg/net/http/server.go:1100 + 0xb7
runtime.panic（0xbe5c40、0x127da13）
/usr/local/go/src/pkg/runtime/panic.c:248 + 0x18d
github.com/docker/docker/daemon。（_ execConfig）.Resize（0xc20989c800、0x25、0x82、0x0、0x0）
/go/src/github.com/docker/docker/daemon/exec.go:65 + 0x66
github.com/docker/docker/daemon。（_ Daemon）.ContainerExecResize（0xc208044f20、0xc20a836e00、0x1）
/go/src/github.com/docker/docker/daemon/resize.go:49 + 0x314
github.com/docker/docker/daemon._Daemon.ContainerExecResize・fm（0xc20a836e00、0x7f49bcd007d8）
/go/src/github.com/docker/docker/daemon/daemon.go:132 + 0x30
github.com/docker/docker/engine.(_Job).Run(0xc20a836e00、0x0、0x0）
/go/src/github.com/docker/docker/engine/job.go:83 + 0x837
github.com/docker/docker/api/server.postContainerExecResize(0xc208114fd0、0xc20a55db27、0x4、0x7f49bcd08c58、0xc209498320、0xc209e
621a0、0xc20a69c0c0、0x0、0x0）
/go/src/github.com/docker/docker/api/server/server.go:1170 + 0x2d1
github.com/docker/docker/api/server.func・002（0x7f49bcd08c58、0xc209498320、0xc209e621a0）
/go/src/github.com/docker/docker/api/server/server.go:1219 + 0x810
net / http.HandlerFunc.ServeHTTP（0xc2081b8280、0x7f49bcd08c58、0xc209498320、0xc209e621a0）
/usr/local/go/src/pkg/net/http/server.go:1235 + 0x40
github.com/gorilla/mux.(_Router).ServeHTTP(0xc2080a3cc0、0x7f49bcd08c58、0xc209498320、0xc209e621a0）
/go/src/github.com/docker/docker/vendor/src/github.com/gorilla/mux/mux.go:98 + 0x297
net / http.serverHandler.ServeHTTP（0xc208180480、0x7f49bcd08c58、0xc209498320、0xc209e621a0）
/usr/local/go/src/pkg/net/http/server.go:1673 + 0x19f
net / http。（_ conn）.serve（0xc20a836300）
/usr/local/go/src/pkg/net/http/server.go:1174 + 0xa7e
net / http。（* Server）.Serveによって作成されました
/usr/local/go/src/pkg/net/http/server.go:1721 + 0x313

..。

情報[0056]削除/v1.16/containers/hoopla_docker_registry
情報[0056] + job rm（hoopla_docker_registry）
コンテナhoopla_docker_registryを破棄できません：ドライバdevicemapperがルートファイルシステム6abcbfefe8bdd485dfb192f8926を削除できませんでした
3add895cda1ae28b578d4a0d9b23574dedc5c：デバイスがビジーです
情報[0066] -job rm（hoopla_docker_registry）= ERR（1）
ERRO [0066] DELETE / containers / { name：のハンドラー
r devicemapperはルートファイルシステム6abcbfefe8bdd485dfb192f89263add895cda1ae28b578d4a0d9b23574dedc5cの削除に失敗しました：デバイスはビジーです

ERRO [0066] HTTPエラー：statusCode = 500コンテナを破棄できませんhoopla_docker_registry：ドライバdevicemapperがルートファイルシステムの削除に失敗しました6abcbfefe8bdd485dfb192f89263add895cda1ae28b578d4a0d9b23574dedc5c：デバイスがビジーです

私はこれをubuntu14.04（ec2）で1.4.1で見ていましたが、1.5では見ていませんでした。 dockerはlinuxmint 17では非常に信頼できるように見えますが、ubuntu14.04を使用するビルドサーバーでは非常に信頼できないため、奇妙です。

この問題は0。9日以降存在しているように見えるため、devicemapperを使用しない方法はありますか？

これはoverlayfsでも発生する可能性があります。

さて、私はaufsに変更したばかりで、今のところ問題はありません。

この問題の状況はどうなっていますか？ 関連する可能性のあるいくつかのPRがマージされるのを見ましたが、これに対する修正は明確に述べられていませんでした。 これは本番環境での_主要な_問題であり、現在の唯一の回避策は、initスクリプトにパッチを適用して、ドライブをクリーンにアンマウントすることです。

これをもう一度確認した後、これは最初に言ったEBUSY理想的な例ではありません。
このケースは、シグナルを適切に処理しないコンテナーのpidと関係があります。

ここでの再生の場合以来tail -f /dev/null上から出ていませんSIGQUITときデーモンが終了し、その後、devmapperドライバことはできません解体適切に（これはdevmapperに排他的ではありません）。 デーモンが再起動される前に、dockerが実行されていない場合でも、 tail -f /dev/nullが実行されていることを確認できます。

このような問題では、Dockerが終了するときにコンテナー内のpidをどのように大幅に処理するかについて考える必要があります... @ unclejack @crosbymichaelの考えですか？

これをFedora21x86_64でテストしました。 問題が存在しないように思われるため、比較目的でのみ情報を提供します（もう？）。 centos：7またはubuntu：trustyイメージを使用した場合と同じ結果。

$ docker run -d centos:7 tail -f /dev/null
ec496f1a6738430972b79e5f3c9fdbf2527e55817d4638678e3b0dd486191203

$ systemctl stop docker

$ ps ax | grep tail
14681 ?        Ss     0:00 tail -f /dev/null
14738 pts/9    S+     0:00 grep --color=auto tail

$ systemctl start docker

$ docker ps -q

$ docker ps -a -q
ec496f1a6738

$ docker start ec496f1a6738
ec496f1a6738

$ docker rm ec496f1a6738
Error response from daemon: Conflict, You cannot remove a running container. Stop the container before attempting removal or use -f
FATA[0000] Error: failed to remove one or more containers 

$ docker stop ec496f1a6738
ec496f1a6738

$ docker rm ec496f1a6738
ec496f1a6738

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

システムインフォメーション：

$ uname -a
Linux localhost 3.18.9-200.fc21.x86_64 #1 SMP Mon Mar 9 15:10:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

$ rpm -q device-mapper docker-io
device-mapper-1.02.93-3.fc21.x86_64
docker-io-1.5.0-1.fc21.x86_64

$ docker version
Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.3.3
Git commit (client): a8a31ef/1.5.0
OS/Arch (client): linux/amd64
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.3.3
Git commit (server): a8a31ef/1.5.0

Docker 1.5、Ubuntu14.04でこれに遭遇するだけです
root@ip-10-148-25-50:~# docker start service Error response from daemon: Cannot start container service: Error getting container f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774 from driver devicemapper: Error mounting '/dev/mapper/docker-202:1-153948-f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774' on '/var/lib/docker/devicemapper/mnt/f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774': device or resource busy FATA[0000] Error: failed to start one or more containers

ただし、 umount /var/lib/docker/devicemapper/mnt/f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774を実行すると役に立ちました。

Docker 1.5.0、Centos7.0、でも同じ問題が発生します

[vagrant<strong i="6">@localhost</strong> ~]$  sudo systemctl start docker
[vagrant<strong i="7">@localhost</strong> ~]$  sudo docker ps -a
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS                        PORTS               NAMES
5189b16c0917        mongo:3             "/entrypoint.sh mong   35 minutes ago      Exited (128) 29 minutes ago                       mongod
[vagrant<strong i="8">@localhost</strong> ~]$ sudo docker inspect 5189b16c0917 | grep Error
        "Error": "Error getting container 5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6 from driver devicemapper: Error mounting '/dev/mapper/docker-253:1-134,

umountが失敗します。

[vagrant<strong i="12">@localhost</strong> ~]$ sudo stat /var/lib/docker/devicemapper/mnt/5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6
  File: `/var/lib/docker/devicemapper/mnt/5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6'
  Size: 6               Blocks: 0          IO Block: 4096   ディレクトリ
Device: fd01h/64769d    Inode: 201732136   Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-03-21 20:36:14.407505308 +0900
Modify: 2015-03-21 20:16:58.863146490 +0900
Change: 2015-03-21 20:16:58.863146490 +0900
 Birth: -
[vagrant<strong i="13">@localhost</strong> ~]$ sudo umount /var/lib/docker/devicemapper/mnt/5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6
umount: /var/lib/docker/devicemapper/mnt/5189b16c0917ff1f87b8aa8ab2e86953887d0e65ad95d0637b0f2213222d55e6: not mounted
[vagrant<strong i="14">@localhost</strong> ~]$ grep docker /proc/mounts
(no results)

環境

[vagrant<strong i="18">@localhost</strong> ~]$ cat /etc/centos-release
CentOS Linux release 7.0.1406 (Core)
[vagrant<strong i="19">@localhost</strong> ~]$ uname -a
Linux localhost.localdomain 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[vagrant<strong i="20">@localhost</strong> ~]$ sudo docker version
Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.3.3
Git commit (client): a8a31ef/1.5.0
OS/Arch (client): linux/amd64
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.3.3
Git commit (server): a8a31ef/1.5.0

[vagrant<strong i="21">@localhost</strong> ~]$ rpm -qi docker
Name        : docker
Version     : 1.5.0
Release     : 1.el7
Architecture: x86_64
Install Date: 2015年03月21日 20時04分29秒
Group       : Unspecified
Size        : 27215826
License     : ASL 2.0
Signature   : (none)
Source RPM  : docker-1.5.0-1.el7.src.rpm
Build Date  : 2015年02月12日 05時10分39秒
Build Host  : c1bj.rdu2.centos.org
Relocations : (not relocatable)
Packager    : CBS <[email protected]>
Vendor      : CentOS
URL         : http://www.docker.com
Summary     : Automates deployment of containerized applications
Description :
Docker is an open-source engine that automates the deployment of any
application as a lightweight, portable, self-sufficient container that will
run virtually anywhere.

CentOS7公式リポジトリからdocker1.3.2で複製します。

$ rpm -qi docker
Name        : docker
Version     : 1.3.2
Release     : 4.el7.centos
Architecture: x86_64
Install Date: 2015年03月22日 02時44分58秒
Group       : Unspecified
Size        : 25505685
License     : ASL 2.0
Signature   : RSA/SHA256, 2014年12月11日 04時21分03秒, Key ID 24c6a8a7f4a80eb5
Source RPM  : docker-1.3.2-4.el7.centos.src.rpm
Build Date  : 2014年12月11日 04時15分49秒
Build Host  : worker1.bsys.centos.org
Relocations : (not relocatable)
Packager    : CentOS BuildSystem <http://bugs.centos.org>
Vendor      : CentOS
URL         : http://www.docker.com
Summary     : Automates deployment of containerized applications

docker1.5.0にも同じバグがあります
Error response from daemon: Cannot destroy container 485bf8d6502a: Driver devicemapper failed to remove root filesystem 485bf8d6502a6cf448075d20c529eb24f09a41946a5dd1c61a99e17

ここでも同じ問題、再現しやすい

docker run -it --name busybox --rm busybox tail -f /dev/null

On another shell:

root<strong i="6">@staging5</strong>:/home/shopmedia #service docker stop
Stopping docker:                                           [  OK  ]
root<strong i="7">@staging5</strong>:/home/shopmedia #service docker start
Starting docker:                                           [  OK  ]
root<strong i="8">@staging5</strong>:/home/shopmedia #docker rm -f busybox
Error response from daemon: Cannot destroy container busybox: Driver devicemapper failed to remove root filesystem 124cd3329e0fafa6be2a284b36a75571666745436c601a702a4beedb75adc7c0: Device is Busy
FATA[0011] Error: failed to remove one or more containers

環境

docker version
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8/1.4.1
OS/Arch (client): linux/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8/1.4.1

cat /etc/centos-release
CentOS release 6.6 (Final)

cat /proc/version
Linux version 2.6.32-504.8.1.el6.x86_64 ([email protected]) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) ) #1 SMP Wed Jan 28 21:11:36 UTC 2015

rpm -q device-mapper
device-mapper-1.02.90-2.el6_6.1.x86_64

編集：私にとっての唯一の回避策（私はsystem.dを使用していません）は、unshareコマンドで/etc/init.d/dockerの50行目を更新することです。 修正は@vbattsによって提供され
ただし、この修正はスケーラブルではありません。 所有しているすべてのマシンを更新する必要はありません+次にdockerを更新するときに消去されます。

1. 私の他のオプションは何ですか？
2. 修正ドッカー側が出てきますか？
3. すべてのオペレーティングシステムに影響がありますか？
4. それはすべてのカーネルに影響を与えていますか？

ありがとう

https://github.com/docker/docker/pull/12400でこれが修正されると思い

ありがとう@ coolljt0725 。

1）どのバージョンのDockerが実装されますか？
2）他のオプションは何ですか？
3）すべてのオペレーティングシステムに影響がありますか？
4）それはすべてのカーネルに影響を与えていますか？

ありがとう

umount回避策の+1。 docker 1.6.0、ビルド4749651で私に起こりました。
service dockerrestartはそれを解決しませんでした。 問題のある「ボリューム」をアンマウントすると修正されました。

Docker 1.6.1（Ubuntu 14.04）にはまだこの問題があります。 umount機能します。

Docker 1.6.2（Ubuntu 14.04） umountが機能しない

Docker 1.7.0 Centos6.5にも同じ問題があります。

Docker 1.7にアップグレードした後、Centos6.3でこれを取得しました。 アップグレードによりdockerが（明らかに）再起動し、コンテナーを再起動しようとすると、すべてのnode.jsコンテナーが再起動しましたが、uwsgiを実行しているコンテナーはエラーを出します：

# docker start 48596c91d263
Error response from daemon: Cannot start container 48596c91d263: Error getting container 48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549 from driver devicemapper: Error mounting '/dev/mapper/docker-8:17-262147-48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549' on '/local/docker/devicemapper/mnt/48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549': device or resource busy

umount /local/docker/devicemapper/mnt/48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549しても、問題は解決しません

Debianでも同じです。 まったく新しいhello-worldイメージをプルしている場合でも、コンテナーを開始できません。

root<strong i="6">@vamp1</strong>:~# docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from hello-world
a8219747be10: Pull complete 
91c95931e552: Already exists 
hello-world:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provi
de security.
Digest: sha256:aa03e5d0d5553b4c3473e89c8619cf79df368babd18681cf5daeb82aab55838d
Status: Downloaded newer image for hello-world:latest
Error response from daemon: Cannot start container 69be8cff86828d1f4ca3db9eeeeb1a8891ce1e305bd07847108750a0051846ff: device or resource busy

Client version: 1.7.0
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 0baf609
OS/Arch (client): linux/amd64
Server version: 1.7.0
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 0baf609
OS/Arch (server): linux/amd64

PRETTY_NAME="Debian GNU/Linux 7 (wheezy)"
NAME="Debian GNU/Linux"
VERSION_ID="7"
VERSION="7 (wheezy)"

@tnolet docker info出力を提供してください。

@unclejack私のホストのdocker infoは

$ docker info
Containers: 24
Images: 128
Storage Driver: devicemapper
 Pool Name: docker-8:17-262147-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: 
 Metadata file: 
 Data Space Used: 2.897 GB
 Data Space Total: 107.4 GB
 Data Space Available: 104.5 GB
 Metadata Space Used: 7.918 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.14 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Library Version: 1.02.89-RHEL6 (2014-09-01)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.81-1.el6.elrepo.x86_64
Operating System: <unknown>
CPUs: 4
Total Memory: 7.812 GiB
Name: radioedit-app101
ID: RY22:ODAC:5NT5:MSBZ:Y52X:L33V:UCHA:IOIL:SR23:YX3U:IILJ:J44R
WARNING: No swap limit support

@tdterry RHEL6および

DockerはCentos6.5（https://docs.docker.com/installation/centos/）を公式にサポートしています。 さらに、カーネルを3.10に更新しました。 ここにいる他の人々は、CentOS7にもエラーが存在すると報告しています。 CentOSバージョンの問題というよりもデバイスマッパーの問題のようです。 CentOS7にアップグレードすると何か違うことが起こると信じる理由はありません。

私はこれをCentOS7、Dockerバージョン1.6.0、devicemapperでビルド4749651に持っていました。 15個のコンテナがすべてクラッシュしました。 ぶら下がっている画像を削除しようとしていますが、同じエラーが発生します。

Error response from daemon: Cannot destroy container: Driver devicemapper failed to remove root filesystem : Device is Busy

Containers: 25
Images: 237
Storage Driver: devicemapper
 Pool Name: docker-253:2-8594920394-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file: 
 Metadata file: 
 Data Space Used: 22.03 GB
 Data Space Total: 107.4 GB
 Data Space Available: 85.34 GB
 Metadata Space Used: 25.47 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.122 GB
 Udev Sync Supported: false
 Library Version: 1.02.82-git (2013-10-04)
Execution Driver: native-0.2
Kernel Version: 3.10.0-229.4.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 24
Total Memory: 141.5 GiB
Name: localhost.localdomain

デーモンが停止している@amalagauraで、 mount | grep dockerすると、いくつかのディレクトリがマウントされていることが表示される場合があります（ /dev/mapper/docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0 on ... ）。 これらを最初にumountから、デーモンを再起動できます。 問題がまだ解決しない場合は、 dmsetup ls | grep docker 、 docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0 (253:5)ようなエントリを確認してください。 そのうちdmsetup remove docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0電話できます

@vbattsご

1.7にアップグレードした後も同様の問題が発生しますが、elementaryOSの1.6.2では問題なく動作していました。

コンテナを起動するたびに、メッセージが表示されます

デーモンからのエラー応答：コンテナーを開始できません560640442c770dff574f5af7b6cdcc8e86ba8a613db87bf90a77aea7f0db322a：デバイスまたはリソースがビジーです

docker、rm -rf / var / lib / dockerを削除しましたが、新規インストールでもhello-worldイメージの実行時に同じエラーが発生します。

また、試行が失敗するたびに、フォルダーが/ var / docker / lib / aufs / mntに蓄積されることに気付きました。

私はこれを非常に頻繁にヒットしており、devicemapperではなくaufsを使用しています：

$ sudo docker info
Containers: 3
Images: 2278
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 2284
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.5.0-54-generic
Operating System: Ubuntu precise (12.04.2 LTS)
CPUs: 8
Total Memory: 7.725 GiB
Name: (omitted)
ID: DWS4:G2M5:XD2Q:CQKA:5OXF:I3RB:6M6F:GUVO:NUFM:KKTF:4RB2:X3HP

提供できるデバッグ情報が他にあるかどうか教えてください。

同じ問題が発生しています。 umountは機能せず、フォルダがマウントされていないことを示しています。 docker 1.5.0でこれを観察した後、同じ効果で1.7.1に更新しました。

$ docker info
Containers: 15
Images: 91
Storage Driver: devicemapper
 Pool Name: docker-202:1-149995-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: 
 Metadata file: 
 Data Space Used: 2.225 GB
 Data Space Total: 107.4 GB
 Data Space Available: 105.1 GB
 Metadata Space Used: 5.03 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.142 GB
 Udev Sync Supported: false
 Deferred Removal Enabled: false
 Library Version: 1.02.82-git (2013-10-04)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-40-generic
Operating System: Ubuntu 14.04.1 LTS
CPUs: 1
Total Memory: 3.676 GiB
WARNING: No swap limit support

ubuntu14.04で同じように設定します

$ docker info
Containers: 6
Images: 537
Storage Driver: devicemapper
 Pool Name: docker-8:1-262623-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file:
 Metadata file:
 Data Space Used: 7.546 GB
 Data Space Total: 107.4 GB
 Data Space Available: 99.83 GB
 Metadata Space Used: 19.05 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.128 GB
 Udev Sync Supported: false
 Deferred Removal Enabled: false
 Library Version: 1.02.82-git (2013-10-04)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-52-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 2
Total Memory: 2.939 GiB
Name: test-app
ID: F5T4:5AIR:TDBZ:DGH4:WBFT:ZX6A:FVSA:DI4O:5HE2:CJIV:VVLZ:TGDS
WARNING: No swap limit support

$ docker version
Client version: 1.7.1
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 786b29d
OS/Arch (client): linux/amd64
Server version: 1.7.1
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 786b29d
OS/Arch (server): linux/amd64

アプリケーションを実行しようとしていますが、この問題が解決したかどうかにかかわらず、すでにいくつかのコンテナーがクラッシュしたため、本番環境でdockerを使用できません。また、本番システムの問題であるシステムの再起動なしでそれらを削除できませんでした。

udev同期が無効になっている@trompxdevicemapperは機能しません。
これは、静的バイナリの代わりに動的バイナリ（同期の問題を修正する）を提供する理由の一部です。
get.docker.com（およびlxc-dockerパッケージ）のリポジトリをapt.dockerproject.orgリポジトリ（およびdocker-engineパッケージ）に置き換えることをお勧めします。
詳細については、 http：//blog.docker.com/2015/07/new-apt-and-yum-repos/を参照してください。

「デッド」と呼ばれる新しい（っぽい）コンテナ状態もあります。これは、コンテナの削除で問題が発生したときに設定されます。 これはもちろん、この特定の問題の回避策です。これにより、 device or resource busyエラー（おそらく競合状態）が発生する理由を調査できます。この場合、再度削除するか、手動で試みることができます。修正します（たとえば、残っているマウントをすべてアンマウントしてから削除します）。

たぶん、グラフドライバーは、fsとのある種の競争がある場合（たとえば、再度マウントを解除しようとする場合）、もう少し弾力性がある可能性があります。

@ cpuguy83情報ありがとうございます。 現在、udev trueで最後のバージョンを使用していますが、ロギング監視システムをセットアップしようとしたときに問題が発生し、すべてのコンテナーのステータスが「終了（137）」、次に「デッド」になり、それらを削除しようとすると、それらを削除する「デーモンからのエラー応答：コンテナ9ca0b5642a55を破棄できません：ドライバdevicemapperがルートファイルシステムを削除できませんでした」。 だから私はまだこの問題を抱えています。

（ロギングシステムをセットアップするために）syslogドライバーを使用しているときに何が起こったのかわからなかったので、何が起こったのか本当にわかりません。 これを整理したらお知らせします。

@trompxこれらが以前のインストールからぶら下がっている場合は、問題が発生する可能性があります。
コンテナーが「デッド」状態になったら、コンテナーを再びdocker rm -fして、Dockerから削除することができ、コンテナーが再び表示されないようにする必要があります。 devicemapperが実際にファイルを見つけられないように、ファイルが欠落している可能性があります。

私はなんとかそれを再びクラッシュさせることができましたが、その時ログドライバーjsonがオンになっています。 すべてのコンテナのログを確認した後、haproxyのものだけがいくつかの有用な入力「/run.sh：fork：メモリを割り当てることができません」を返します。 スワップなしでメモリが少し不足していたので、メモリが不足したに違いありません。 それが原因である場合、メモリが不足するとDockerがクラッシュし、すべてのコンテナが終了することを意味しますか？

@trompx確かに、DockerがOOMを殺すのを
dockerがクラッシュした場合、コンテナーは終了しませんが、dockerがバックアップを開始すると、実行中のすべてのコンテナーが強制終了されます（そして、再起動ポリシーのあるコンテナーが開始されます）。

Ubuntu14.04でdocker-compose1.4.2とdocker-engine1.8.3を使用すると、これがかなり定期的に発生します。

@superdumpカーネルバージョン？

@gionn ：3.13.0-65-ジェネリック

@superdump @gionn同上同じバージョンのソフトウェア、カーネル3.13.0-67-generic

EBSSSDを使用するAWSで

docker 1.9を試して、修正されたかどうかを確認した人はいますか？ ボリュームに関連するいくつかの作業がありました...

ボリューム（コンテナのライフサイクル外にデータを拡張するという意味で）は、ここで影響を受けているものとは異なる機能ですよね？

unshareマウントがこれらの問題の実行可能な解決策である場合、デーモンの起動時にデフォルトでdockerはそれを実行できません。
それは実装するのに十分単純でなければなりません。

行うのは簡単で、このタスクを実行するにはさまざまな方法があります。 ザ・
メンテナは、これを行ったプルリクエストを受け入れたくありませんでした。
「ハック」でした。
午前6時49分AMアンドレアスSteniusで金、2015年11月27日には[email protected]
書きました：

マウントの共有解除がこれらの問題の実行可能な解決策である場合、dockerは実行できません
デフォルトでは、デーモンの起動時です。
それは実装するのに十分単純でなければなりません。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/5684#issuecomment-160153438 。

それは真実ではない。 これはありましたが、問題が発生したため、元に戻しました。 問題が発生しなければ、それを行うのは簡単です。

情報をありがとう。 いくつかのノードに共有解除の「ハック」を追加しました。
それがどうなるか見てください...
11月27日 2015kl。 19時01 skrevブライアンゴフ[email protected] ：

それは真実ではない。 これはありましたが、問題が発生したため、元に戻しました。
問題が発生しなければ、それを行うのは簡単です。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/5684#issuecomment-160182860 。

こんにちは、

Dockerを使用すると、上記の問題が発生します。

Failed to remove container (da3b06dc0723): Error response from daemon: Unable to remove filesystem for da3b06dc072328112eec54d7b0e00c2c355a8ef471e1ba3c82ab3ffb8e93891f: remove /var/lib/docker/containers/da3b06dc072328112eec54d7b0e00c2c355a8ef471e1ba3c82ab3ffb8e93891f/shm: device or resource busy
Failed to remove container (99cfba26be16): Error response from daemon: Unable to remove filesystem for 99cfba26be16bf7b475aaa4ed3d50f7fca3179082decc60f1418d22745f5a855: remove /var/lib/docker/containers/99cfba26be16bf7b475aaa4ed3d50f7fca3179082decc60f1418d22745f5a855/shm: device or resource busy
Failed to remove container (c34922906202): Error response from daemon: Unable to remove filesystem for c34922906202713a573a45f18f8db45ad6788bde2255f75b0f0e027800721b26: remove /var/lib/docker/containers/c34922906202713a573a45f18f8db45ad6788bde2255f75b0f0e027800721b26/shm: device or resource busy

私のDockerバージョン情報は次のとおりです。
クライアント：
バージョン：1.10.2
APIバージョン：1.22
Goバージョン：go1.5.3
Gitコミット：c3959b1
構築日：2016年2月22日月曜日21:37:01
OS / Arch：linux / amd64

サーバ：
バージョン：1.10.2
APIバージョン：1.22
Goバージョン：go1.5.3
Gitコミット：c3959b1
構築日：2016年2月22日月曜日21:37:01
OS / Arch：linux / amd64

ごく最近、この問題に遭遇したことに注意する必要があります。 私はDockerを1年近く使用しています。

こんにちは、
コンピューターを再起動した後、以前は削除されていなかったコンテナーが削除されていることがわかりました。 これは目前の問題を解決しますが、それでもコンテナが蓄積され、常にOSを再起動しなければならないのはイライラします。

@ chirangaalwis + 1。 これは、コンテナがしばらく実行された後に発生することに気づきましたか、それともコンテナを起動した直後に発生しますか？

こんにちは、
覚えている限りでは、コンテナを始めてからかなりの時間が経ちました。 正確には、非常に長い時間が経過した後ではありません。

ちなみに、この問題の背後にある理由を誰かが徹底的に説明できればいいのですが。 私はコンテナ化の概念に比較的慣れていません。

@chirangaalwisはこの問題をチェックアウトしました： https ：

+1。 ええ、そうです、私のカーネルバージョンでさえ3.13です。 ええ、私もこれをチェックします、私が報告したものとマップします。

@chirangaalwis @kabobbob ...私はRHEL7.2とカーネル3.10を使用しています。

[root<strong i="7">@pe2enpmas301</strong> npmo-server]# uname -a
Linux pe2enpmas301.corp.intuit.net 3.10.0-327.3.1.el7.x86_64 #1 SMP Fri Nov 20 05:40:26 EST 2015 x86_64 x86_64 x86_64 GNU/Linux

docker-composeを使用してコンテナを停止および開始している間、常にこのエラーが発生します。

Recreating npmoserver_policyfollower_1
ERROR: Driver devicemapper failed to remove root filesystem 3bb07965510f2c398c0fc99c3e0ce4696914f710efabc47f2df19ecf85725021: Device is Busy

唯一の回避策は、停止し、数秒待ってから再試行することです。 問題は、再起動が機能することが保証されていないことです。 再起動を何度も試みることがあります。

@chirangaalwis @marcellodesalesサーバーをカーネル3.16にアップグレードし、コンテナーの停止とrmを試しました。 すべてうまくいったようです。 作業して、問題が解決するかどうかを確認する必要があります。

@kabobbobは、それがうまく機能することが証明された場合は、数日以内に報告してください...私はプリプロダクション環境をアップグレードして報告します。

これはrhel7.2で発生しました-yumupdate && systemctlrebootで修正されました。

直接LVMとDockerバージョン1.9.1を使用していました

私もこの問題を抱えています。 私のセットアップ：Ubuntu 14.04、カーネル「3.19.0-58-generic＃64〜14.04.1-Ubuntu」に更新。 Dockerバージョン1.11.0、ビルド4dc5990。 「docker-composeバージョン1.7.0、ビルド0d7bf73」。

docker-compose up -dが新しいイメージのためにコンテナを再起動すると、停止したコンテナを削除できなくなることがよくあります。

再起動するだけで、コンテナを起動できるようになります。 その場合、問題は100％再現可能ではありませんが、非常に頻繁に発生します。 だから私は頻繁にホストマシンを再起動することを余儀なくされています:-(

$ docker rm 5435d816c9a3_dockercomposeui_docker-compose-ui_1
Error response from daemon: Driver devicemapper failed to remove root filesystem 5435d816c9a35c63a5a636dc56b7d9052f1681ae21d604127b1685dab3848404: Device is Busy

そして

# docker ps -a | grep dockercomposeui
5435d816c9a3        c695fdb43f7a                          "/env/bin/python /app"   2 days ago          Dead                                                                                                                   5435d816c9a3_dockercomposeui_docker-compose-ui_1

@dsteinkopf 1.10から1.11にアップグレードした後、これに

いいえ、問題はdocker1.10とデフォルトのubuntu14.04-kernel（〜3.10だと思います）とaufsを使用してすでに存在していました。 次に、ストレージドライバー、カーネル、Dockerを（段階的に）アップグレードしました。 経験した問題に大きな変化はありません...

この問題に関してオーバーレイを試す価値があると思いますか？ （私の場合、パフォーマンスは大きな問題ではありません。）

@thaJeztah私はこれまで、そしてそれ以来、この問題を見たことがありません

1.10から1.11にアップグレードした後、これに遭遇しましたか

私はこの問題を抱えています:(

まだこれをつけた
RHEL7.2カーネル-3.10.0-327.el7.x86_64
Dockerバージョン1.9.1、ビルド78ee77d / 1.9.1
device-mapper-libs-1.02.107-5.el7_2.1.x86_64

また、問題が発生しました：

docker rm agent4 Error response from daemon: Driver aufs failed to remove root filesystem 16a3129667975c411d0084b38ba512761b64eaa7853f3452a7f8e4f2898d1175: rename /var/lib/docker/aufs/diff/76125e9141ec9de7c12e20d41b00cb44826b19bedf98bd9c650cb7a7cc07913a /var/lib/docker/aufs/diff/76125e9141ec9de7c12e20d41b00cb44826b19bedf98bd9c650cb7a7cc07913a-removing: device or resource busy

Dockerバージョン

Client:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:26:49 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:26:49 2016
 OS/Arch:      linux/amd64

Docker情報

Containers: 9
 Running: 8
 Paused: 0
 Stopped: 1
Images: 80
Server Version: 1.11.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 193
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 7 (wheezy)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 31.45 GiB
Name: chell
ID: BXX3:THMK:SWD4:FP35:JPVM:3MV4:XJ7S:DREY:O6XO:XYUV:RHXO:KUBS
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support

うなめ-a

Linux chell 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) x86_64 GNU/Linux

これはさまざまな問題が混在しています。 これを閉じる必要があると思います。 最近報告されたケースはどれもOPのようなものではありません。

@guenhterこれは、/ var / runをコンテナー（ホスト上の他のコンテナー）にマウントするか、/ var / lib /

@guenhter記録のために＃21969

また、「デバイスまたはリソースがビジー」タイプのエラーに関する1.11より前の問題の多くは、デーモンを（正常に）強制終了してから再起動することが原因である可能性があります。
これにより、ストレージドライバーマウントの内部参照カウントが0にリセットされますが、マウント自体はまだアクティブです。
1.11はそのケースに対処します。

上記の理由により閉鎖。

申し訳ありませんが、これを理解しているかどうかはわかりません。 「最近報告されたケースのどれもOPのようなものではない」とはどういう意味ですか？
私（およびこの問題を経験している他の人）は何をすべきですか？ 別のケースを開きますか？

@dsteinkopfはい、提供できる限り詳細に（ファイルの作成、デーモンログなど）。

こんにちは、以前に指定した問題に注意してください。カーネルバージョンを4.4.0-21-genericにアップグレードしました。Dockerのバージョン情報は次のとおりです。
クライアント：
バージョン：1.11.0
APIバージョン：1.23
Goバージョン：go1.5.4
Gitコミット：4dc5990
構築：2016年4月13日水曜日18:38:59
OS / Arch：linux / amd64

サーバ：
バージョン：1.11.0
APIバージョン：1.23
Goバージョン：go1.5.4
Gitコミット：4dc5990
構築：2016年4月13日水曜日18:38:59
OS / Arch：linux / amd64

以前に報告された問題は発生しなくなったようです。 カーネルバージョンをアップグレードすることでDockerをかなりの時間使用しましたが、停止したようです。

少なくともdocker-composeで使用した場合、問題の回避策が見つかりました。https ： //github.com/docker/docker/issues/3786#issuecomment-221601065を参照して

再起動に失敗するコンテナでも同じ問題が発生します。

Ubuntu 14.04
カーネル：3.13.0-24-generic
Dockerバージョン：

Client:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:34:23 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:34:23 2016
 OS/Arch:      linux/amd64

エラー：

Error response from daemon: Driver aufs failed to remove root filesystem 
802f3a6eb28f8f16bf8452675a389b1d8bf755e59c827d50bec9372420f4194a: 
rename /var/lib/docker/aufs/diff/79e53988cfddcc3fb9868316bd9d8c3d7a825fd09a8620553c148bd96243224f /var/lib/docker/aufs/diff/79e53988cfddcc3fb9868316bd9d8c3d7a825fd09a8620553c148bd96243224f-removing: 
device or resource busy

アンマウントに失敗しました：

umount: /var/lib/docker/devicemapper
/mnt/79e53988cfddcc3fb9868316bd9d8c3d7a825fd09a8620553c148bd96243224f is not mounted 
(according to mtab)

これはまだ私たちの問題です（Ubuntu 14.04.4 LTS（KVM付き）で1.11.2を使用（3.13.0-88-generic））。

更新を取得するためにサブスクライブできるオープンチケットはありますか？

@ GameScripting ＃

Linux zk1 3.10.0-327.28.3.el7.x86_64（centos 7）
Dockerバージョン1.12.1、ビルド23cf638

デーモンからのエラー応答：ドライバーdevicemapperがルートファイルシステム228f2c2da3de4d5abd3881184aeb330a4c18e4311ecf404e2fb8cd4ffe15e901の削除に失敗しました：devicemapper：DeleteDevicedm_task_runの実行中にエラーが発生しました

ちょうどこれに遭遇しました。 /etc/init.d/docker restartが役に立ちました、これが本番マシンになかったことを嬉しく思います...😢

$ docker --version
Docker version 1.11.1, build 5604cbe

まだこれも取得しています

$ docker --version
Docker version 1.12.2, build bb80604

同じ問題が、Dockerの多くのバージョンで発生しています。 docker-composeを使用してコンテナを再作成します。 きれいに動作する場合もあれば、動作しない場合もあります。 Dockerデーモンを再起動するか、サーバーを再起動すると、不良コンテナがクリーンアップされます。

Arch Linux; ext4FS上のdevicemapperコンテナー。

$ docker version
Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.7.3
 Git commit:   6b644ec
 Built:        Thu Oct 27 19:42:59 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.7.3
 Git commit:   6b644ec
 Built:        Thu Oct 27 19:42:59 2016
 OS/Arch:      linux/amd64
$ docker info
Containers: 24
 Running: 22
 Paused: 0
 Stopped: 2
Images: 56
Server Version: 1.12.3
Storage Driver: devicemapper
 Pool Name: docker-8:3-13500430-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: 9.394 GB
 Data Space Total: 107.4 GB
 Data Space Available: 78.15 GB
 Metadata Space Used: 24.82 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.123 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: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.7.2-1-ARCH
Operating System: Arch Linux
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 30.85 GiB
Name: omega
ID: IR7W:NSNN:F2B3:YP32:YTQJ:OFEB:2XLK:HHCK:HJ33:5K3O:KEHI:SDUB
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
$ df -T
Filesystem     Type     1K-blocks      Used Available Use% Mounted on
dev            devtmpfs  16169500         0  16169500   0% /dev
run            tmpfs     16173076      2712  16170364   1% /run
/dev/sda3      ext4     447260560 371064976  53453004  88% /
tmpfs          tmpfs     16173076         0  16173076   0% /dev/shm
tmpfs          tmpfs     16173076         0  16173076   0% /sys/fs/cgroup
tmpfs          tmpfs     16173076      1144  16171932   1% /tmp
/dev/sda1      ext4        289293     45063    224774  17% /boot
tmpfs          tmpfs      3234612         8   3234604   1% /run/user/1000
/dev/sdb2      ext4     403042160  15056296 367489480   4% /run/media/ivan/backup
/dev/sda4      ext4     480580312 320608988 135536228  71% /run/media/ivan/ARCHIVES
/dev/sdb3      ext4     225472980   1473948 212522604   1% /run/media/ivan/data

それが役立つなら...

私はここでも同じ/同様の問題を抱えていると思います。 compose up -dを使用してサービスをデプロイしてから、compose.yamlでイメージ名を別の名前に更新し、別のcompose up -dを実行すると、デバイスマッパー周辺のエラーで作成が失敗します。

エラー
エラー：<>ドライバーdevicemapperがルートファイルシステムの削除に失敗しました216c098e0f051407863934c27111bd1e9b7561dff1c4d67c0f0d45a99505fa70：デバイスがビジーです

バージョン情報：
Dockerバージョン
クライアント：
バージョン：1.12.1
APIバージョン：1.24
Goバージョン：go1.6.3
Gitコミット：23cf638
構築：
OS / Arch：linux / amd64

サーバ：
バージョン：1.12.1
APIバージョン：1.24
Goバージョン：go1.6.3
Gitコミット：23cf638
構築：
OS / Arch：linux / amd64

一時的な回避策として、upを再実行する前にdocker-compose down--rmiをすべて追加しました。

Dockerバージョンでも同じ問題があります：1.12.3

この問題を経験している残りの人々は＃27381に関連していると確信しています

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の削除に失敗しました：デバイスがビジーです

PS私はdockercomposeを使用していません。

ホストがディスク領域を使い果たした後に噛まれました。
マウントポイントに影響するコマンドがハングします（「dockerps」、「sync」、「ls」を含む）"、...）

私は同様の問題を抱えていました、私は私の/ var / log / syslogファイルでこれらのエラーのようなものを見ました：
Dec 16 14:32:18 rzing dockerd[3093]: time="2018-12-16T14:32:18.627417173+05:30" level=error msg="Failed to load container mount 00d7b9d64ff6c465276e67f5a5e3642ebacd9616c7602d4361b3a7fab038510a: mount does not exist" Dec 16 14:32:18 rzing dockerd[3093]: time="2018-12-16T14:32:18.627816711+05:30" level=error msg="Failed to load container mount fb108b942f8ed87a9e1affb6480ed477a8f5f823b2639e36348cde4a97924c5e: mount does not exist"
/var/lib/docker/volumes下のマウントポイントを検索しようとしましたが、見つかりませんでした
最後にシステムを再起動して問題を修正しました