@vieira Bitte

Die obigen Schritte sind auch nach dem Neustart des Geräts reproduzierbar.

@alexlarsson kannst du bitte einen Blick darauf werfen? Es scheint mit Devicemapper verwandt zu sein

Das Problem scheint nur mit dem Devicemapper zu tun zu haben. Ich denke, es ist wirklich etwas anderes.
Ich habe es versucht, und das Problem ist der Teil "Docker stoppen". Wenn ich nur den Docker-Daemon bei gedrückter Strg-C-Taste drücke, wird versucht, die Container ordnungsgemäß zu stoppen, aber es scheint, dass es niemals gelingt, den Container zu stoppen. Also drücke ich noch ein paar Mal Strg-C, um den Docker zum Sterben zu zwingen.

Zu diesem Zeitpunkt läuft der Container (Tail) noch, sodass das Geräte-Mapper-Gerät bereitgestellt wird. Dies bedeutet, dass wir es nicht erneut bereitstellen oder entfernen können. Aus diesem Grund schlagen diese Vorgänge fehl.

@alexlarsson Kennen Sie eine einfache Möglichkeit, das System zu bereinigen, wenn dies schief geht?

Wenn Sie den außer Kontrolle geratenen Containerprozess finden, können Sie ihn möglicherweise erzwingen.

@vieira können Sie
umount / var / lib / docker / devicemapper / mnt / c39206003c7ae8992a554a9ac2ea130327fc4af1b2c389656c34baf9a56c84b5

und starten Sie den Container erneut, es sollte funktionieren

Ich kann sehen, dass mein Docker mit -d und -r gestartet wurde. Erstens, wenn Docker neu gestartet wird, werden die Container nicht neu gestartet. Dann tritt der oben genannte Fehler auf (beim Versuch, die Container zu starten).

Mein Centos 6.5 bekommt immer noch 1.0.0.6 aus dem Epel. Wurde dies jemals als Fehler in 1.0 identifiziert und in 1.1 behoben? Kann jemand bitte bestätigen?

Vielen Dank

Hallo allerseits, immer noch nicht in 1.1.1 behoben.
Die Schritte im ursprünglichen Beitrag gelten weiterhin.

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

Ich bekomme auch viel, aber es scheint den Container in gewissem Sinne zu entfernen (da ich einen neuen Container mit dem gleichen Namen starten kann)

Gibt es eine Problemumgehung für dieses Problem?

Suchen Sie auch nach einer Problemumgehung.

Scheint, als würden alle Container gestoppt, bevor der Docker-Daemon das Problem behebt.

Ich habe diesen pre-stop -Block als Problemumgehung zu meinem Startjob hinzugefügt:

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

Hier ist eine Übersicht über meine Debugging-Schritte: https://gist.github.com/rochacon/4dfa7bd4de3c5f933f0d

@rochacon Vielen Dank für Ihre

@vieira Ich habe es auch mit 1.2.0 versucht, die gleichen Ergebnisse.

Nach 4 Wochen hat einer meiner Container angehalten ... Ich weiß nicht warum ... Wie kann ich die Grundursache finden?

Wie auch immer, ich hatte das gleiche Problem ... Es wurde mit dem Vorschlag von @aroragagan gelöst: umount, Docker-Startcontainer ... Ich bin übrigens auf RHEL 6.5 ...

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

Wir sehen dies jetzt auf 1.3.0 auf einem EC2-Ubuntu-System, das von 12.04 auf 14.04 aktualisiert wurde. Meine Entwicklungsinstanz ist eine direkte 14.04-Installation in Vagrant und hat dieses Problem nicht. Das Aushängen und anschließende Neustarten der Container scheint zu funktionieren, aber das macht den Zweck zunichte, sie so zu konfigurieren, dass sie beim Neustart der Instanz oder beim Neustart des Dockers automatisch neu gestartet werden. Lassen Sie mich wissen, ob ich weitere Informationen zu Versionen unterstützender Pakete usw. bereitstellen kann, da mir ein funktionierendes und ein nicht funktionierendes System zur Verfügung steht.

Dasselbe Problem mit Docker 1.3 Ubuntu 14.04 mit Linux Kernel 3.13 oder 3.14.

@srobertson beziehen Sie sich auf "Container werden beim Neustart des Dämons nicht neu gestartet"? Verwenden Sie die neue _per-container_-Neustartrichtlinie? Weil das daemonweite -r / --restart=true in Docker 1.2 entfernt wurde

Die neue Neustartrichtlinie (pro Container) wird in der CLI-Referenz beschrieben

+1, habe dieses Problem auf Docker 1.3 @ ArchLinux x86_64 mit 3.17.2-1-ARCH-Kernel.

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

Umount löst das Problem.

umount ist eine Problemumgehung, ich würde nicht sagen, dass es das Problem löst. Durch einfaches Neustarten des Dämons bei laufenden Containern wird das Problem reproduziert.

umount funktioniert auch für mich in der folgenden Docker-Version:

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

Ich habe dann zuerst den Docker-Daemon gestoppt:

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

@ mlehner616 Ja, du hast recht. Entschuldigung, natürlich ist es eine Problemumgehung, keine Lösung. Das war nur eine schlechte Wortwahl.

Ich würde gerne sehen, dass dies auch behoben wird. =)

fyi, unmounten hat bei mir nicht funktioniert. Ich erhalte die Fehlermeldung, dass in / etc / mtab kein Mount gefunden werden kann
Docker Version 1.0.0, Build 63fe64c / 1.0.0 auf RHEL 6.5

Ich habe es umgangen, indem ich alle alten Mounts automatisch abgemeldet habe, wenn der Docker-Daemon zurückkommt. Ich wollte Ubuntus großes /etc/init/docker.conf nicht patchen, also habe ich stattdessen eine kleine Zeile in /etc/default/docker eingefügt:

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

Das scheint den Trick zu tun. Ich habe es mit dem Start und dem erneuten Aufrufen meiner eigentlichen Docker-Container durch Upstart kombiniert. Nach einem service docker restart werden nun alle Container einfach zurückkommen.

Danke, @jypma , das hat auch für mich den Trick getan!

_review session_ mit @unclejack

Wir werden dieses Problem als Tracker für die meisten "Geräte- oder Ressourcen ausgelasteten" oder EBUSY Berichte verwenden.

Dieses Problem wird wie andere behoben, indem der Mount-Namespace des Docker-Daemons ordnungsgemäß behandelt wird. Derzeit gibt es keine Standardbehandlung für den Mount-Namespace, daher haben wir Probleme wie dieses EBUSY.

Während wir an der offiziellen Lösung für den Umgang damit arbeiten, gibt es Workarounds, die Sie selbst anwenden können. Siehe http://blog.hashbangbash.com/2014/11/docker-devicemapper-fix-for-device-or-resource-busy-ebusy/

Bestätigen, dass ich auch auf dieses Problem gestoßen bin, indem ich das Bild von freeipa verwendet habe. Ich habe den Docker-Dienst gestoppt und als ich versuchte, ihn zusammen mit dem IPA-Container neu zu starten, wurde Folgendes angezeigt.

$ 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

Das Aushängen des "Mount" hat das Problem umgangen, sodass ich den Container neu starten konnte.

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

$ docker start ipa
ipa

Verwenden Sie Folgendes:

$  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 hat mein Problem behoben

Docker - Version
Docker Version 1.3.2, Build 39fa2fa

Die folgende Problemumgehung ist also eine etwas dauerhaftere Problemumgehung für meinen Anwendungsfall.
Ich verwende ausschließlich Amazon Linux (RedHat6-Like), daher habe ich eine geringfügige Änderung am Init-Skript vorgenommen (die wahrscheinlich überschrieben wird, wenn Docker aktualisiert wird). Grundsätzlich wird Docker wie gewohnt gestoppt und nach verbleibenden Docker-Mounts gesucht Wenn es welche gibt, werden sie entfernt. YMMV

_ / etc / init.d / docker_
Hinzufügen einer lib-Variablen (Zeile ~ 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"

Hinzufügen eines Umount-Blocks zur Stoppfunktion (Zeile ~ 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
}

Ich habe das gleiche Problem mit Docker 1.4.1, das Device Mapper als Speichertreiber verwendet. Ich konnte eine Panikstapel-Ablaufverfolgung von Docker über seine Protokolldatei sammeln.

UMGEBUNG

$ cat / etc / * release
DISTRIB_ID = Ubuntu
DISTRIB_RELEASE = 14.04
DISTRIB_CODENAME = vertrauenswürdig
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-Version
sudo: Host ip-172-30-0-39 kann nicht aufgelöst werden
Client-Version: 1.4.1
Client-API-Version: 1.16
Go-Version (Client): go1.3.3
Git Commit (Client): 5bc2ff8
OS / Arch (Client): Linux / AMD64
Serverversion: 1.4.1
Server-API-Version: 1.16
Go-Version (Server): go1.3.3
Git Commit (Server): 5bc2ff8

$ tail -f / var / log / upstart / docker
...
INFO [143413] -job execResize (3dfcbc075227d5b3f0115bd73a1fea4a56a2c0fc68190d84b6d88e93938b4121, 37, 130)
2015/01/22 22:29:22 http: Panic Serving @: Laufzeitfehler: Ungültige Speicheradresse oder Nullzeiger-Dereferenzierung
Goroutine 1932 [läuft]:
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
erstellt von net / http. (* Server) .Serve
/usr/local/go/src/pkg/net/http/server.go:1721 + 0x313

...

INFO DELETE /v1.16/containers/hoopla_docker_registry
INFO + job rm (hoopla_docker_registry)
Container hoopla_docker_registry kann nicht zerstört werden: Der Treiber-Devicemapper konnte das Root-Dateisystem 6abcbfefe8bdd485dfb192f8926 nicht entfernen
3add895cda1ae28b578d4a0d9b23574dedc5c: Gerät ist ausgelastet
INFO -job rm (hoopla_docker_registry) = ERR (1)
ERRO-Handler für DELETE / container / { name:. *} Fehler zurückgegeben: Container kann nicht zerstört werden hoopla_docker_registry: Drive
r devicemapper konnte das Root-Dateisystem 6abcbfefe8bdd485dfb192f89263add895cda1ae28b578d4a0d9b23574dedc5c nicht entfernen: Gerät ist ausgelastet

ERRO HTTP-Fehler: statusCode = 500 Container kann nicht zerstört werden hoopla_docker_registry: Treiber-Devicemapper konnte das Root-Dateisystem 6abcbfefe8bdd485dfb192f89263add895cda1ae28b578d4a0d9b23574dedc5c nicht entfernen: Gerät ist ausgelastet

Ich habe dies auf Ubuntu 14.04 (auf ec2) mit 1.4.1 und auch nein mit 1.5 gesehen. Es ist seltsam, weil Docker unter Linux Mint 17 sehr zuverlässig zu sein scheint, aber auf unserem Build-Server mit Ubuntu 14.04 sehr unzuverlässig.

Gibt es eine Möglichkeit, Devicemapper nicht zu verwenden, da dieses Problem seit 0,9 Tagen zu bestehen scheint?

Dies kann auch bei Overlays passieren.

Naja, ich habe gerade auf aufs gewechselt und bisher keine Probleme.

Wie ist der Status dieses Problems? Ich habe gesehen, dass einige PRs zusammengeführt wurden, die in Beziehung stehen könnten, aber nichts, was eindeutig angegeben wurde, war eine Lösung dafür. Dies ist ein großes Problem in der Produktion und die einzige Lösung besteht jetzt darin, das Init-Skript zu patchen, um die Bereitstellung der Laufwerke sauber aufzuheben.

Nachdem wir dies noch einmal überprüft haben, ist dies kein ideales Beispiel für das EBUSY , das wir ursprünglich gesagt hatten.
Dieser Fall hat mehr mit den Pids eines Containers zu tun, der Signale nicht ordnungsgemäß verarbeitet.

Da der Reproduktionsfall hier tail -f /dev/null Beenden des Daemons nicht auf SIGQUIT beendet wird, kann der Devmapper-Treiber nicht ordnungsgemäß herunterfahren (dies gilt nicht nur für Devmapper). Bevor der Dämon erneut gestartet wird, können Sie sehen, dass tail -f /dev/null noch ausgeführt wird, auch wenn Docker dies nicht ist.

Ein Problem wie dieses erfordert Gedanken darüber, wie drastisch die Pids im Container beim Verlassen des Dockers behandelt werden sollen ... @unclejack @crosbymichael Gedanken?

Getestet auf Fedora 21 x86_64. Bereitstellung von Informationen nur zu Vergleichszwecken, da das Problem (nicht mehr?) Nicht mehr vorhanden zu sein scheint. Gleiche Ergebnisse mit Centos: 7 oder Ubuntu: Trusty Images.

$ 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

System Information:

$ 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

Laufen Sie einfach auf Docker 1.5, Ubuntu 14.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

Das Ausführen von umount /var/lib/docker/devicemapper/mnt/f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774 geholfen.

Ich habe das gleiche Problem unter 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 schlägt fehl.

[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)

Umgebung

[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.

Ich reproduziere es mit Docker 1.3.2 aus dem offiziellen CentOS7-Repository.

$ 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

Docker 1.5.0 hat den gleichen Fehler
Error response from daemon: Cannot destroy container 485bf8d6502a: Driver devicemapper failed to remove root filesystem 485bf8d6502a6cf448075d20c529eb24f09a41946a5dd1c61a99e17

Gleiches Problem hier, leicht zu reproduzieren

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

Umgebung

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

BEARBEITEN: Die einzige Problemumgehung für mich (ich verwende nicht system.d) besteht darin, /etc/init.d/docker, Zeile 50, mit dem Befehl unshare zu aktualisieren. Der Fix wurde von @vbatts zur Verfügung gestellt, Dank btw
Dieser Fix ist jedoch nicht skalierbar. Wir möchten nicht jeden Computer aktualisieren, den wir besitzen. + Er wird beim nächsten Update des Dockers gelöscht.

1. Was sind meine anderen Optionen?
2. Gibt es eine feste Docker-Seite?
3. Betrifft es alle Betriebssysteme?
4. Betrifft es alle Kernel?

Vielen Dank

Ich denke, https://github.com/docker/docker/pull/12400 wird dies beheben. Dies liegt daran, dass beim Herunterfahren des Docker-Daemons die laufenden Container nicht bereinigt werden (wenn die Container nicht innerhalb von 10 Sekunden beendet werden, werden die Rootfs des Containers weiterhin bereitgestellt) und beim nächsten Start des Daemons nicht entfernt werden können. (Ich teste auf Overlay)

Danke @ coolljt0725 .

1) Welche Docker-Version wird implementiert?
2) Was sind meine anderen Optionen?
3) Betrifft es alle Betriebssysteme?
4) Betrifft es alle Kernel?

Vielen Dank

+1 für die Umount-Problemumgehung. ist mir mit Docker 1.6.0 passiert, Build 4749651.
Service Docker Neustart hat es nicht gelöst. Umount das gestörte "Volumen" hat es behoben.

Docker 1.6.1 (Ubuntu 14.04) hat immer noch dieses Problem. umount funktioniert.

Docker 1.6.2 (Ubuntu 14.04) umount funktioniert nicht

Docker 1.7.0 Centos 6.5 hat immer noch die gleichen Probleme.

Ich habe dies gerade auf Centos 6.3 nach dem Upgrade auf Docker 1.7 erhalten. Das Upgrade hat Docker (offensichtlich) neu gestartet, und als ich die Container neu gestartet habe, wurden alle meine node.js-Container neu gestartet, aber diejenigen, die uwsgi ausführen, geben den Fehler aus:

# 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

Durch umount /local/docker/devicemapper/mnt/48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549 das Problem NICHT behoben.

Gleiches gilt für Debian. Ich kann keinen Container starten, selbst wenn ich ein völlig frisches Hallo-Welt-Bild ziehe.

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 Bitte geben Sie die Ausgabe docker info .

@unclejack Die docker info für meinen Host ist

$ 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 RHEL 6 und CentOS 6 werden von Red Hat für die Verwendung mit Docker nicht mehr unterstützt. Bitte aktualisieren Sie auf RHEL 7 oder CentOS 7.

Docker unterstützt offiziell Centos 6.5 (https://docs.docker.com/installation/centos/). Zusätzlich haben wir den Kernel auf 3.10 aktualisiert. Andere Leute hier berichten, dass der Fehler auch unter CentOS 7 vorliegt. Scheint eher ein Devicemapper-Problem als ein CentOS-Versionsproblem zu sein. Ich habe keinen Grund zu der Annahme, dass ein Upgrade auf CentOS 7 etwas anderes bewirken wird.

Ich hatte dies gerade in CentOS 7, Docker Version 1.6.0, Build 4749651 mit Devicemapper. Meine 15 Container sind alle abgestürzt. Ich versuche einige baumelnde Bilder zu entfernen und erhalte den gleichen Fehler:

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 mit angehaltenem Daemon und Ausführen von mount | grep docker möglicherweise einige gemountete Verzeichnisse an (z. B. /dev/mapper/docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0 on ... ). Sie können diese zuerst umount und dann den Daemon erneut starten. Wenn das Problem weiterhin besteht, dmsetup ls | grep docker und Einträge wie docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0 (253:5) . Davon können Sie dmsetup remove docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0

@vbatts Danke für die Hilfe. Unser eigentliches Problem ist, dass unser Produktionscluster von 15 Maschinen gerade gestorben ist. Dies ist eine andere Diskussion, aber was sollte getan werden, wenn wir Unterstützung für Docker wünschen?

Ich habe ein ähnliches Problem, nachdem ich auf 1.7 aktualisiert habe. Es funktionierte in 1.6.2 unter ElementaryOS einwandfrei.

Immer wenn ich einen Container starte, erhalte ich die Nachricht

Fehlerantwort vom Dämon: Container 560640442c770dff574f5af7b6cdcc8e86ba8a613db87bf90a77aea7f0db322a kann nicht gestartet werden: Gerät oder Ressource belegt

Ich habe Docker, rm -rf / var / lib / docker, gelöscht und bei der Neuinstallation wird immer noch der gleiche Fehler angezeigt, wenn das Hallo-Welt-Image ausgeführt wird.

Ich habe auch festgestellt, dass sich Ordner nach jedem fehlgeschlagenen Versuch in / var / docker / lib / aufs / mnt stapeln.

Ich treffe das extrem häufig und verwende aufs, nicht devicemapper:

$ 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

Lassen Sie mich wissen, ob ich weitere Debugging-Informationen bereitstellen kann.

Das gleiche Problem sehen. umount funktioniert nicht, es heißt, der Ordner ist nicht gemountet. Ich habe dies mit Docker 1.5.0 beobachtet und dann mit demselben Effekt auf 1.7.1 aktualisiert.

$ 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

Ich sehe dasselbe auf Ubuntu 14.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

Ich bin im Begriff, eine Anwendung auszuführen, und ob dieses Problem behoben ist, kann Docker nicht in der Produktion verwenden, da bereits einige Container abgestürzt sind und ich sie nicht ohne Neustart des Systems entfernen konnte, was für ein Produktionssystem ein Problem darstellt.

@trompx Devicemapper mit deaktivierter udev-Synchronisierung funktioniert nicht.
Dies ist Teil des Grundes, warum wir jetzt dynamische Binärdateien (die das Synchronisierungsproblem beheben) anstelle einer statischen Binärdatei anbieten.
Ich würde empfehlen, Ihre Repos von get.docker.com (und dem lxc-docker-Paket) durch das apt.dockerproject.org-Repo (und das docker-engine-Paket) zu ersetzen.
Weitere Informationen finden Sie unter http://blog.docker.com/2015/07/new-apt-and-yum-repos/ .

Es gibt auch einen neuen (ish) Container-Status namens "dead", der festgelegt wird, wenn beim Entfernen des Containers Probleme aufgetreten sind. Dies ist natürlich eine Problemumgehung für dieses spezielle Problem, mit der Sie untersuchen können, warum der Fehler device or resource busy (wahrscheinlich eine Rennbedingung) vorliegt. In diesem Fall können Sie versuchen, ihn erneut zu entfernen oder manuell zu versuchen Fix (z. B. verbleibende Halterungen entfernen und dann entfernen).

Vielleicht können die Grafiktreiber in Fällen, in denen wir eine Art Rennen mit dem fs haben, etwas widerstandsfähiger sein (z. B. versuchen, es erneut abzunehmen).

@ cpuguy83 Danke für die Info. Ich verwende jetzt die letzte Version mit udev true, aber während ich versuchte, ein Protokollierungsüberwachungssystem einzurichten, trat ein Problem auf, das dazu führte, dass mein gesamter Container den Status "Beendet (137)" und dann "tot" hatte und der Versuch, sie zu entfernen, mich daran hinderte Entfernen "Fehlerantwort vom Daemon: Container 9ca0b5642a55 kann nicht zerstört werden: Treiber-Devicemapper konnte Root-Dateisystem nicht entfernen". Ich habe also immer noch dieses Problem.

Ich konnte nicht sehen, was passiert ist, als ich den Syslog-Treiber verwendet habe (um zu versuchen, mein Protokollierungssystem einzurichten), daher weiß ich nicht wirklich, was passiert ist. Ich werde Sie wissen lassen, wenn ich das kläre.

@trompx Wenn diese von der vorherigen Installation abhängen, kann dies zu einem Problem führen.
Sobald sich die Container in einem "toten" Zustand befinden, können Sie sie erneut docker rm -f , um sie aus dem Docker zu entfernen, und sie sollten nicht wieder angezeigt werden. Es ist wahrscheinlich, dass die Dateien so fehlen, dass Devicemapper sie nicht wirklich finden kann.

Ich habe es geschafft, es wieder zum Absturz zu bringen, aber mit dieser Zeit war der Log-Treiber json eingeschaltet. Nach dem Überprüfen der Protokolle aller Container gibt nur der Haproxy eine nützliche Eingabe zurück: "/run.sh: fork: Speicher kann nicht zugeordnet werden". Ich hatte ein bisschen wenig Speicher ohne Tausch, und mir muss der Speicher ausgegangen sein. Wenn dies die Ursache ist, bedeutet dies, dass Docker abstürzt, wenn der Arbeitsspeicher knapp wird, wodurch alle Container beendet werden?

@trompx Sicherlich
Container werden nicht beendet, wenn Docker abstürzt. Wenn Docker jedoch erneut gestartet wird, werden alle laufenden Container getötet (und diejenigen gestartet, für die eine Neustartrichtlinie gilt).

Ich sehe dies ziemlich regelmäßig, wenn ich Docker-Compose 1.4.2 und Docker-Engine 1.8.3 unter Ubuntu 14.04 verwende.

@ Superdump Kernel Version?

@gionn : 3.13.0-65-generic

@superdump @gionn dito gleiche Versionen der Software, Kernel 3.13.0-67-generic

auf AWS mit EBS-SSDs

Hat jemand mit Docker 1.9 versucht, festzustellen, ob es behoben wurde? Es gab einige Arbeiten im Zusammenhang mit Bänden ...

Volumes (im Sinne der Erweiterung von Daten außerhalb des Container-Lebenszyklus) sind eine andere Funktion als das, was hier betroffen ist, nicht wahr?

Wenn das Nicht-Teilen von Bereitstellungen eine praktikable Lösung für diese Probleme ist, kann Docker dies nicht standardmäßig tun, wenn der Dämon gestartet wird.
Das sollte einfach genug zu implementieren sein.

Es ist einfach und es gibt verschiedene Möglichkeiten, diese Aufgabe zu erfüllen. Das
Betreuer wollten keine Pull-Anfragen akzeptieren, die dies taten, weil es
war ein "Hack".
Am Fr, 27. November 2015 um 6:49 Uhr Andreas Stenius [email protected]
schrieb:

Wenn das Nicht-Teilen von Mounts eine praktikable Lösung für diese Probleme ist, kann Docker dies nicht tun
das standardmäßig, wenn der Dämon startet ..?
Das sollte einfach genug zu implementieren sein.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/docker/docker/issues/5684#issuecomment -160153438.

Das ist nicht wahr. Wir hatten dies und es verursachte Probleme, also haben wir es zurückgesetzt. Es ist trivial für Sie, dies zu tun, wenn es Ihnen keine Probleme bereitet.

Danke für die Information. Wir haben den Unshare "Hack" auf einigen Knoten hinzugefügt.
Schau wie es läuft...
fre 27 nov. 2015 kl. 19:01 skrev Brian Goff [email protected] :

Das ist nicht wahr. Wir hatten dies und es verursachte Probleme, also haben wir es zurückgesetzt.
Es ist trivial für Sie, dies zu tun, wenn es Ihnen keine Probleme bereitet.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/docker/docker/issues/5684#issuecomment -160182860.

Hallo,

Ich erhalte das oben beschriebene Problem bei der Verwendung von 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

Meine Docker-Versionsinformationen lauten wie folgt:
Klient:
Version: 1.10.2
API-Version: 1.22
Go-Version: go1.5.3
Git Commit: c3959b1
Gebaut: Montag, 22. Februar, 21:37:01 Uhr 2016
OS / Arch: Linux / AMD64

Server:
Version: 1.10.2
API-Version: 1.22
Go-Version: go1.5.3
Git Commit: c3959b1
Gebaut: Montag, 22. Februar, 21:37:01 Uhr 2016
OS / Arch: Linux / AMD64

Es muss angemerkt werden, dass ich vor kurzem auf dieses Problem gestoßen bin. Ich habe fast ein Jahr mit Docker gearbeitet.

Hallo,
Ich wollte nur erwähnen, dass ich nach dem Neustart meines Computers festgestellt habe, dass die zuvor nicht entfernten Container entfernt wurden. Dies löst das vorliegende Problem, aber es wird irritierend sein, wenn sich Container ansammeln und das Betriebssystem immer neu gestartet werden muss.

@chirangaalwis +1. Haben Sie bemerkt, dass dies geschieht, nachdem der Container einige Zeit ausgeführt wurde, oder direkt nach dem Starten des Containers?

Hallo,
Soweit ich mich erinnern kann, habe ich dies nach einer beträchtlichen Zeit seit dem Start der Container erlebt. Nicht nach sehr langer Zeit, um genau zu sein.

Übrigens wäre es schön, wenn jemand den Grund für dieses Problem gründlich erklären könnte. Ich bin relativ neu im Konzept der Containerisierung.

@chirangaalwis haben Sie dieses Problem überprüft: https://github.com/docker/docker/issues/17902 Scheint, dass es spezifisch für die Kernel-Version ist. Ich werde den Kernel auf dem Computer aktualisieren, auf dem das Problem am nächsten Tag aufgetreten ist, und prüfen, ob das Problem dadurch behoben wird.

+1. Ja scheint so, sogar meine Kernel-Version ist 3.13. Ja, ich werde auch nachsehen, Karten mit dem, was ich berichtet habe.

@chirangaalwis @kabobbob ... Ich bin auf RHEL 7.2 und Kernel 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

Beim Stoppen und Starten von Containern mit docker-compose wird ständig der Fehler angezeigt.

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

Die einzige Problemumgehung besteht darin, anzuhalten und einige Sekunden zu warten, bevor Sie es erneut versuchen. Das Problem ist, dass der Neustart nicht garantiert funktioniert. Ich versuche manchmal mehrmals, neu zu starten.

@chirangaalwis @marcellodesales Ich konnte den Server auf Kernel 3.16 aktualisieren und habe versucht, einen Container zu stoppen und rm. Alles schien gut zu funktionieren. Muss arbeiten und sehen, ob das Problem behoben ist.

@kabobbob Bitte melden Sie sich in ein paar Tagen, wenn dies besser funktioniert hat ... Ich werde versuchen, meine Pre-Prod-Umgebungen zu aktualisieren und zu berichten.

Hatte dies auf Rhel 7.2 - ein yum Update && Systemctl Neustart hat es behoben.

Verwendete direktes LVM und Docker Version 1.9.1

Ich habe auch dieses Problem. Mein Setup: Ubuntu 14.04, aktualisiert auf Kernel "3.19.0-58-generic # 64 ~ 14.04.1-Ubuntu". Docker Version 1.11.0, Build 4dc5990. "Docker-Compose Version 1.7.0, Build 0d7bf73".

Wenn docker-compose up -d einen Container aufgrund eines neuen Images neu startet, kann der gestoppte Container häufig nicht mehr entfernt werden.

Nur ein Neustart hilft, den Container starten zu können. Dann ist das Problem nicht zu 100% reproduzierbar, aber es tritt sehr oft auf. Daher muss ich den Host-Computer häufig neu starten :-(

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

und

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

@dsteinkopf Sind Sie nach dem Upgrade von 1.10 auf 1.11 darauf

Nein, das Problem bestand bereits mit Docker 1.10 und dem Standard-Ubuntu 14.04-Kernel (~ 3.10, glaube ich) und mit aufs. Dann habe ich (Schritt für Schritt) Speichertreiber, Kernel und Docker aktualisiert. Keine wesentliche Änderung des erlebten Problems ...

Denken Sie, es lohnt sich, Overlay in Bezug auf dieses Problem zu versuchen? (Leistung ist in meinem Fall kein großes Problem.)

@thaJeztah Ich habe dieses Problem noch nie zuvor und seitdem gesehen

Sind Sie nach dem Upgrade von 1.10 auf 1.11 darauf gestoßen?

Ich habe dieses Problem :(

Habe das immer noch an
RHEL 7.2 Kernel-3.10.0-327.el7.x86_64
Docker Version 1.9.1, Build 78ee77d / 1.9.1
device-mapper-libs-1.02.107-5.el7_2.1.x86_64

Habe auch das Problem:

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-Version

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-Info

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

uname -a

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

Dies ist eine Mischung aus verschiedenen Themen. Ich denke, wir müssen das schließen. Keiner der zuletzt gemeldeten Fälle ähnelt dem OP.

@guenhter Ich vermute, dass dies mit einem anderen Problem beim Mounten von / var / run in einem Container (einem anderen Container auf Ihrem Host) oder dem Mounten von / var / lib / docker zusammenhängt

@guenhter Für den Datensatz # 21969

Viele der Probleme vor 1.11 mit Fehlern vom Typ "Gerät oder Ressource ausgelastet" sind höchstwahrscheinlich darauf zurückzuführen, dass der Dämon (unanständig) beendet und anschließend neu gestartet wurde.
Dies führt dazu, dass die internen Ref-Zählungen auf den Lagertreiber-Mounts auf 0 zurückgesetzt werden, während die Mounts selbst noch aktiv sind.
1.11 befasst sich mit diesem Fall.

Schließen aus den oben genannten Gründen.

Entschuldigung - ich bin mir nicht sicher, ob ich das verstehe. Was meinen Sie mit "Keiner der zuletzt gemeldeten Fälle hat etwas mit dem OP zu tun"?
Was soll ich (und andere, bei denen dieses Problem auftritt) tun? Einen anderen Fall öffnen?

@dsteinkopf Ja, mit so vielen Details wie möglich (Dateien, Daemon-Protokolle usw. erstellen).

Hallo, um nur das Problem zu erwähnen, das ich zuvor angegeben habe: Ich habe meine Kernel-Version auf 4.4.0-21-generic aktualisiert und die Docker-Versionsinformationen lauten wie folgt:
Klient:
Version: 1.11.0
API-Version: 1.23
Go-Version: go1.5.4
Git Commit: 4dc5990
Gebaut: Mi Apr 13 18:38:59 2016
OS / Arch: Linux / AMD64

Server:
Version: 1.11.0
API-Version: 1.23
Go-Version: go1.5.4
Git Commit: 4dc5990
Gebaut: Mi Apr 13 18:38:59 2016
OS / Arch: Linux / AMD64

Das zuvor gemeldete Problem scheint nicht mehr aufzutreten. Benutzte Docker für eine beträchtliche Zeit durch Aktualisieren der Kernel-Versionen und es schien gestoppt zu haben.

Es wurde eine Problemumgehung für das Problem gefunden, zumindest bei Verwendung mit Docker-Compose unter https://github.com/docker/docker/issues/3786#issuecomment -221601065

Gleiches Problem mit einem Container, der nicht neu gestartet werden kann.

Ubuntu 14.04
Kernel: 3.13.0-24-generic
Docker-Version:

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:

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

Das Aushängen schlägt fehl:

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

Dies ist immer noch ein Problem für uns (unter Verwendung von 1.11.2 unter Ubuntu 14.04.4 LTS (mit KVM) (3.13.0-88-generic)).

Gibt es ein offenes Ticket, das ich abonnieren kann, um Updates zu erhalten?

@GameScripting Siehe # 21704

Linux zk1 3.10.0-327.28.3.el7.x86_64 (Centos 7)
Docker Version 1.12.1, Build 23cf638

Fehlerantwort vom Daemon: Treiber-Devicemapper konnte das Root-Dateisystem 228f2c2da3de4d5abd3881184aeb330a4c18e4311ecf404e2fb8cd4ffe15e901 nicht entfernen: devicemapper: Fehler beim Ausführen von DeleteDevice dm_task_run fehlgeschlagen

Bin gerade darauf gestoßen. /etc/init.d/docker restart geholfen, ich bin froh, dass dies nicht auf einer Produktionsmaschine war ... 😢

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

Ich bekomme das auch immer noch

$ docker --version
Docker version 1.12.2, build bb80604

Das gleiche Problem trat bei vielen verschiedenen Versionen von Docker auf. Ich benutze docker-compose , um Container neu zu erstellen. Manchmal funktioniert es sauber, manchmal nicht. Durch einen Neustart des Docker-Daemons oder einen Neustart des Servers wird der fehlerhafte Container bereinigt.

Arch Linux; Devicemapper-Container auf ext4 FS.

$ 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

Wenn es hilft ...

Ich glaube, dass ich auch hier das gleiche / ähnliche Problem habe. Wenn Sie einen Dienst mit compose up -d bereitstellen und dann den Image-Namen in der compose.yaml auf einen anderen Namen aktualisieren und ein anderes compose up -d ausführen, schlägt das Compose mit dem Fehler um devicemapper fehl:

Error
FEHLER: für <> Der Treiber-Devicemapper konnte das Root-Dateisystem nicht entfernen. 216c098e0f051407863934c27111bd1e9b7561dff1c4d67c0f0d45a99505fa70: Gerät ist ausgelastet

Versionsinformation:
Docker-Version
Klient:
Version: 1.12.1
API-Version: 1.24
Go-Version: go1.6.3
Git Commit: 23cf638
Gebaut:
OS / Arch: Linux / AMD64

Server:
Version: 1.12.1
API-Version: 1.24
Go-Version: go1.6.3
Git Commit: 23cf638
Gebaut:
OS / Arch: Linux / AMD64

Als vorübergehende Problemumgehung habe ich ein Docker-Compose-Down hinzugefügt - rmi all, bevor das Up erneut ausgeführt wird.

Ich habe auch das gleiche Problem in Docker Version: 1.12.3

Ich bin mir ziemlich sicher, dass der Rest der Leute, bei denen dieses Problem auftritt, mit # 27381 verwandt ist

Ich sehe dies in Docker 1.12.3 auf CentOs 7

dc2-elk-02: / root / staging / ls-helper $ docker --version
Docker Version 1.12.3, Build 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 Mo 24.10. 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux
dc2-elk-02: / root / staging / ls-helper $ docker rm ls-helper
Fehlerantwort des Dämons: Treiber-Devicemapper konnte das Root-Dateisystem e1b9cdeb519d2f4bea53a552c8b76c1085650aa76c1fb90c8e22cac9c2e18830 nicht entfernen: Gerät ist ausgelastet

PS Ich benutze Docker Compose nicht.

Gebissen, nachdem der Host nicht mehr genügend Speicherplatz hat.
Jeder Befehl, der sich auf den Mount-Punkt auswirkt, hängt (einschließlich "Docker ps", "sync", "ls"", ...)

Ich hatte ein ähnliches Problem. Ich habe diese Fehler in meiner Datei / var / log / syslog gesehen:
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"
Ich habe versucht, den Einhängepunkt unter /var/lib/docker/volumes durchsuchen, aber keinen gefunden
Beim Neustart des Systems wurde das Problem behoben