@vieira Veuillez redémarrer la machine et nous faire savoir si vous rencontrez toujours des problèmes.

Les étapes ci-dessus sont reproductibles même après le redémarrage de la machine.

@alexlarsson pouvez-vous jeter un oeil? Il semble être lié à devicemapper

Le problème semble simplement lié au devicemapper. Je pense que c'est vraiment autre chose.
J'ai essayé ceci, et le problème est la partie "stop docker". Si je ctrl-c simplement le démon docker, il essaiera d'arrêter correctement les conteneurs, mais il semble qu'il ne réussisse jamais à arrêter le conteneur. Donc, je ctrl-c encore quelques fois pour forcer docker à mourir.

À ce stade, le conteneur (queue) est toujours en cours d'exécution, de sorte que le périphérique de mappage de périphériques sera monté, ce qui signifie que nous ne pouvons pas le monter à nouveau ni le supprimer. C'est pourquoi ces opérations échouent.

@alexlarsson connaissez-vous un moyen simple de nettoyer le système une fois que cela ne va pas?

Eh bien, si vous trouvez le processus de conteneur emballé, vous pourriez peut-être le tuer.

@vieira vous pouvez démonter:
umount / var / lib / docker / devicemapper / mnt / c39206003c7ae8992a554a9ac2ea130327fc4af1b2c389656c34baf9a56c84b5

et redémarrez le conteneur, cela devrait fonctionner

Je peux voir que mon docker a été démarré avec -d et -r. Premièrement, lorsque le docker est redémarré, les conteneurs ne sont pas redémarrés. Ensuite, l'erreur mentionnée ci-dessus se produit (lorsque vous essayez de démarrer le ou les conteneurs).

Mon centos 6.5 reçoit toujours 1.0.0.6 de epel. Cela a-t-il déjà été identifié comme un bogue dans la version 1.0 et corrigé dans la version 1.1? Quelqu'un peut-il confirmer s'il vous plaît?

Merci

Bonjour à tous, toujours pas corrigé dans 1.1.1.
Les étapes de l'article d'origine s'appliquent toujours.

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

Je reçois aussi beaucoup, mais cela semble supprimer le conteneur dans un certain sens (en ce sens que je peux démarrer un nouveau conteneur avec le même nom)

Y a-t-il une solution à ce problème?

Vous recherchez également une solution de contournement.

Cela ressemble à l'arrêt de tous les conteneurs avant que le démon docker ne résolve le problème.

J'ai ajouté ce bloc pre-stop à mon travail de démarrage comme solution de contournement:

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

Voici l'essentiel de mes étapes de débogage: https://gist.github.com/rochacon/4dfa7bd4de3c5f933f0d

@rochacon Merci pour votre solution de contournement. Je vais le tester aujourd'hui ou demain avec 1.2 (semble-t-il que vous avez testé avec 1.1.1, non?). Esperons que ça marche.

@vieira J'ai aussi essayé avec 1.2.0, mêmes résultats.

Après 4 semaines consécutives, l'un de mes conteneurs s'est arrêté ... Je ne sais pas pourquoi ... Comment puis-je trouver la cause principale?

Quoi qu'il en soit, j'ai eu le même problème ... Il a été résolu avec la suggestion de @aroragagan : umount, docker start container ... Je suis sur RHEL 6.5 au fait ...

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

Nous voyons cela sur 1.3.0 maintenant, sur un système Ubuntu EC2 qui a été mis à niveau de 12.04 à 14.04. Mon instance de développement est une installation directe 14.04 dans Vagrant et n'a pas ce problème. Démonter puis redémarrer les conteneurs semble fonctionner, mais cela va à l'encontre de l'objectif de les avoir configurés pour redémarrer automatiquement lorsque l'instance redémarre ou lorsque le docker redémarre. Faites-moi savoir s'il y a d'autres informations que je peux fournir sur les versions des packages de support, etc., car j'ai un système fonctionnel et non opérationnel disponible.

Voir le même problème avec docker 1.3 Ubuntu 14.04 avec le noyau Linux 3.13 ou 3.14.

@srobertson parlez -vous de "conteneurs qui ne sont pas redémarrés lorsque le démon redémarre"? Utilisez-vous la nouvelle politique de redémarrage _per-container_? Parce que le -r / --restart=true échelle du démon a été supprimé dans Docker 1.2

La nouvelle politique de redémarrage (par conteneur) est décrite dans la référence CLI

+1, j'ai obtenu ce problème sur le docker 1.3 @ ArchLinux x86_64 avec le noyau 3.17.2-1-ARCH.

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

Umount résout le problème.

umount est une solution de contournement, je ne dirais pas que cela résout le problème. Le simple redémarrage du démon avec des conteneurs en cours d'exécution reproduira le problème.

umount fonctionne aussi pour moi sur la version de docker suivante:

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

J'ai d'abord arrêté le démon docker puis:

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

@ mlehner616 Oui, vous avez raison. Désolé, bien sûr, c'est une solution de contournement, pas une solution. C'était juste un mauvais choix de mots.

J'aimerais que cela soit corrigé aussi, ofc. =)

Pour info, unmounten n'a pas fonctionné pour moi. J'obtiens une erreur indiquant qu'il n'y a pas de montage dans / etc / mtab
Docker version 1.0.0, build 63fe64c / 1.0.0 sur RHEL 6.5

J'ai contourné ce problème en démontant automatiquement toutes les anciennes montures lorsque le démon docker revient. Je ne voulais pas patcher le gros /etc/init/docker.conf ubuntu, alors j'ai mis une petite ligne dans /etc/default/docker place:

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

Cela semble faire l'affaire. Je l'ai combiné avec la gestion par le haut du démarrage et de la réapparition de mes conteneurs docker réels, donc maintenant, après un service docker restart , tous les conteneurs reviendront.

Merci, @jypma , cela a fait l'affaire pour moi aussi!

_review session_ avec @unclejack

Nous allons utiliser ce problème comme outil de suivi pour la majorité des rapports "Périphérique ou ressource occupé" ou EBUSY .

Ce problème, comme d'autres, est atténué en gérant correctement l'espace de noms de montage du démon docker. Actuellement, il n'y a pas de gestion par défaut de l'espace de noms de montage, nous avons donc des problèmes comme celui-ci EBUSY.

Pendant que nous travaillons sur la solution officielle pour la gérer, vous pouvez appliquer vous-même des solutions de contournement. Voir http://blog.hashbangbash.com/2014/11/docker-devicemapper-fix-for-device-or-resource-busy-ebusy/

Confirmant que j'ai également rencontré ce problème en utilisant l'image stock freeipa. J'ai arrêté le service docker et quand j'ai essayé de le redémarrer avec le conteneur ipa, j'ai obtenu ce qui suit.

$ 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

Le démontage du «montage» a contourné le problème afin que je puisse redémarrer le conteneur.

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

$ docker start ipa
ipa

En utilisant ce qui suit:

$  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 a résolu mon problème

docker --version
Docker version 1.3.2, build 39fa2fa

Donc, la solution de contournement suivante est une solution légèrement plus permanente pour mon cas d'utilisation.
J'utilise strictement Amazon Linux (RedHat6-Like), j'ai donc apporté une légère modification au script d'initialisation (qui serait probablement écrasé si le docker était mis à jour.) Fondamentalement, tout ce que cela fait est d'arrêter docker comme d'habitude, de vérifier les montages de docker restants , s'il y en a, il les démonte. YMMV

_ / etc / init.d / docker_
Ajout de la variable lib (ligne ~ 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"

Ajout d'un bloc de montage pour arrêter la fonction (ligne ~ 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
}

Je rencontre le même problème avec docker 1.4.1 en utilisant le mappeur de périphériques comme pilote de stockage. J'ai pu collecter une trace de pile de panique à partir de docker via son fichier journal.

ENVIRONNEMENT

$ cat / etc / * version
DISTRIB_ID = Ubuntu
DISTRIB_RELEASE = 14,04
DISTRIB_CODENAME = fidèle
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/ "

$ version docker
sudo: impossible de résoudre l'hôte ip-172-30-0-39
Version du client: 1.4.1
Version de l'API client: 1.16
Version Go (client): go1.3.3
Git commit (client): 5bc2ff8
OS / Arch (client): linux / amd64
Version du serveur: 1.4.1
Version de l'API serveur: 1.16
Version Go (serveur): go1.3.3
Git commit (serveur): 5bc2ff8

$ tail -f / var / log / upstart / docker
...
INFO [143413] -job execResize (3dfcbc075227d5b3f0115bd73a1fea4a56a2c0fc68190d84b6d88e93938b4121, 37, 130)
2015/01/22 22:29:22 http: panique servant @: erreur d'exécution: adresse mémoire non valide ou déréférence de pointeur nul
goroutine 1932 [en cours d'exécution]:
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
créé par net / http. (* Server) .Serve
/usr/local/go/src/pkg/net/http/server.go:1721 + 0x313

...

INFO [0056] SUPPRIMER /v1.16/containers/hoopla_docker_registry
INFO [0056] + tâche rm (hoopla_docker_registry)
Impossible de détruire le conteneur hoopla_docker_registry: le pilote devicemapper n'a pas réussi à supprimer le système de fichiers racine 6abcbfefe8bdd485dfb192f8926
3add895cda1ae28b578d4a0d9b23574dedc5c: Le périphérique est occupé
INFO [0066] -job rm (hoopla_docker_registry) = ERR (1)
ERRO [0066] Handler for DELETE / containers / { name :. *} a renvoyé l'erreur: impossible de détruire le conteneur hoopla_docker_registry: lecteur
r devicemapper n'a pas réussi à supprimer le système de fichiers racine 6abcbfefe8bdd485dfb192f89263add895cda1ae28b578d4a0d9b23574dedc5c: Le périphérique est occupé

ERRO [0066] Erreur HTTP: statusCode = 500 Impossible de détruire le conteneur hoopla_docker_registry: Le pilote devicemapper n'a pas réussi à supprimer le système de fichiers racine 6abcbfefe8bdd485dfb192f89263add895cda1ae28b578d4a0d9b23574dedc5c: Le périphérique est occupé

Je voyais cela sur ubuntu 14.04 (sur ec2) avec 1.4.1 et aussi non avec 1.5. C'est étrange, car docker semble très fiable sur linux mint 17 mais très peu fiable sur notre serveur de build avec ubuntu 14.04.

Existe-t-il un moyen de ne pas utiliser devicemapper, car ce problème semble exister depuis 0,9 jours?

Cela peut également arriver avec overlayfs.

Eh bien, je viens de changer pour aufs et jusqu'à présent aucun problème.

Quel est le statut de ce problème? J'ai vu fusionner certains PR qui pourraient être liés, mais rien de ce qui était clairement indiqué n'était une solution à ce problème. Il s'agit d'un problème majeur en production et la seule solution consiste à présent à appliquer un correctif au script d'initialisation pour démonter proprement les lecteurs.

après avoir revu cela, ce n'est pas un exemple idéal du EBUSY que nous avions dit à l'origine.
Ce cas a plus à voir avec les pids d'un conteneur qui ne gère pas les signaux avec élégance.

Puisque le cas de reproduction ici tail -f /dev/null ne se termine pas sur SIGQUIT quand le démon se termine, alors le pilote devmapper ne peut pas démonter correctement (ce n'est pas exclusif à devmapper). Avant que le démon ne soit redémarré, vous pouvez voir que le tail -f /dev/null toujours en cours d'exécution, même si le docker ne l'est pas.

Un problème comme celui-ci nécessitera des réflexions sur la façon de traiter drastiquement les pids dans le conteneur à la sortie du docker ... @unclejack @crosbymichael pensées?

J'ai testé ceci sur Fedora 21 x86_64. Fournir des informations à des fins de comparaison uniquement car le problème ne semble pas être présent (plus?). Même résultats avec centos: 7 ou ubuntu: 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

Informations système:

$ 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

Il suffit de rencontrer ceci sur 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

exécuter umount /var/lib/docker/devicemapper/mnt/f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774 aidé cependant.

J'ai le même problème sur 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 échoue.

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

Environnement

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

Je le reproduis par docker 1.3.2 du référentiel officiel CentOS7.

$ 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 a le même bogue
Error response from daemon: Cannot destroy container 485bf8d6502a: Driver devicemapper failed to remove root filesystem 485bf8d6502a6cf448075d20c529eb24f09a41946a5dd1c61a99e17

Même problème ici, facile à reproduire

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

Environnement

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

EDIT: La seule solution de contournement pour moi (je n'utilise pas system.d) est de mettre à jour /etc/init.d/docker, ligne 50 avec la commande unshare. Le correctif a été fourni par @vbatts , merci btw
Cependant, ce correctif n'est pas évolutif. Nous ne voulons pas mettre à jour chaque machine que nous possédons + Elle sera effacée la prochaine fois que nous mettrons à jour le docker.

1. Quelles sont mes autres options?
2. Y a-t-il un côté fixe du docker qui sort?
3. Cela affecte-t-il tout le système d'exploitation?
4. Cela affecte-t-il tous les noyaux?

Merci

Je pense que https://github.com/docker/docker/pull/12400 va résoudre ce problème. En effet, l'arrêt du démon docker laissera les conteneurs en cours d'exécution non nettoyés (si les conteneurs ne sont pas tués dans 10 secondes, les rootfs du conteneur seront toujours montés) et il ne pourra pas être supprimé au prochain démarrage du démon. (Je teste sur superposition)

Merci @ coolljt0725 .

1) Quelle version de docker sera-t-il implémentée?
2) Quelles sont mes autres options?
3) Cela affecte-t-il tout le système d'exploitation?
4) Cela affecte-t-il tous les noyaux?

Merci

+1 pour la solution de contournement umount. m'est arrivé avec docker 1.6.0, build 4749651.
le redémarrage du docker de service ne l'a pas résolu. umount le «volume» troublé l'a corrigé.

Docker 1.6.1 (Ubuntu 14.04) a toujours ce problème. umount fonctionne.

Docker 1.6.2 (Ubuntu 14.04) umount ne fonctionne pas

Docker 1.7.0 Centos 6.5 a toujours les mêmes problèmes.

Je viens de le recevoir sur Centos 6.3 après la mise à niveau vers Docker 1.7. La mise à niveau a redémarré le docker (évidemment), et quand je suis allé redémarrer les conteneurs, tous mes conteneurs node.js ont redémarré, mais ceux exécutant uwsgi donnent l'erreur:

# 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

Faire un umount /local/docker/devicemapper/mnt/48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549 n'a PAS résolu le problème.

Idem sur Debian. Vous ne pouvez démarrer aucun conteneur, même lorsque vous tirez une image Hello-world totalement nouvelle.

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 Veuillez fournir la sortie docker info .

@unclejack Le docker info pour mon hôte est

$ 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 et CentOS 6 ne sont plus pris en charge par Red Hat pour une utilisation avec Docker. Veuillez mettre à niveau vers RHEL 7 ou CentOS 7.

Docker prend officiellement en charge Centos 6.5 (https://docs.docker.com/installation/centos/). De plus, nous avons mis à jour le noyau vers la version 3.10. D'autres personnes ici signalent que l'erreur existe également sur CentOS 7. Cela ressemble plus à un problème de devicemapper qu'à un problème de version CentOS. Je n'ai aucune raison de croire que la mise à niveau vers CentOS 7 fera quelque chose de différent.

Je viens de l'avoir dans CentOS 7, Docker version 1.6.0, build 4749651 avec devicemapper. Mes 15 conteneurs se sont tous écrasés. J'essaie de supprimer certaines images pendantes et j'obtiens la même erreur:

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 avec le démon arrêté, l'exécution de mount | grep docker peut afficher quelques répertoires montés (comme /dev/mapper/docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0 on ... ). vous pouvez umount ceux-ci d'abord, puis redémarrer le démon. Si le problème persiste, dmsetup ls | grep docker et voyez les entrées comme docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0 (253:5) . Dont vous pouvez appeler dmsetup remove docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0

@vbatts Merci pour l'aide. Notre vrai problème est que notre groupe de production de 15 machines vient de mourir. C'est une discussion différente, mais que faut-il faire si nous voulons du support sur docker?

J'ai un problème similaire après la mise à niveau vers la version 1.7, cela fonctionnait bien dans la version 1.6.2 sur elementaryOS.

Chaque fois que je démarre un conteneur, je reçois le message

Réponse d'erreur du démon: impossible de démarrer le conteneur 560640442c770dff574f5af7b6cdcc8e86ba8a613db87bf90a77aea7f0db322a: périphérique ou ressource occupé

J'ai purgé docker, rm -rf / var / lib / docker, et avec une nouvelle installation, j'ai toujours la même erreur lors de l'exécution de l'image hello-world.

J'ai également remarqué que les dossiers s'accumulent dans / var / docker / lib / aufs / mnt après chaque tentative infructueuse.

Je frappe très fréquemment, et j'utilise aufs, pas 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

Faites-moi savoir si je peux fournir d'autres informations de débogage.

Voyant le même problème. umount ne fonctionne pas, cela indique que le dossier n'est pas monté. J'ai observé cela avec docker 1.5.0, puis j'ai mis à jour vers 1.7.1 avec le même effet.

$ 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

Voir la même chose sur 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

Je suis sur le point d'exécuter une application et si ce problème est résolu, je ne peux pas utiliser docker en production car j'ai déjà rencontré un crash de conteneur et je ne pouvais pas les supprimer sans redémarrage du système, ce qui est pénible pour un système de production.

Le devicemapper @trompx avec la synchronisation udev désactivée ne fonctionnera pas.
C'est en partie la raison pour laquelle nous proposons désormais des binaires dynamiques (qui résout le problème de synchronisation) au lieu d'un binaire statique.
Je recommanderais de remplacer vos dépôts de get.docker.com (et le package lxc-docker) par le repo apt.dockerproject.org (et le package docker-engine).
Voir http://blog.docker.com/2015/07/new-apt-and-yum-repos/ pour plus de détails.

Il existe également un nouvel état de conteneur (ish) appelé "mort", qui est défini en cas de problèmes de suppression du conteneur. Il s'agit bien sûr d'une solution de contournement pour ce problème particulier, qui vous permet d'aller chercher pourquoi il y a l'erreur device or resource busy (probablement une condition de concurrence), auquel cas vous pouvez essayer de supprimer à nouveau, ou essayer manuellement correction (par exemple, démontez toutes les montures restantes, puis supprimez-les).

Peut-être que les graphdrivers peuvent être un peu plus résilients dans les cas où nous avons une sorte de course avec le fs (par exemple, essayez de le démonter à nouveau).

@ cpuguy83 Merci pour l'info. J'utilise maintenant la dernière version avec udev true mais alors que j'essayais de configurer un système de surveillance de journalisation, un problème est survenu, entraînant le statut de tous mes conteneurs avec le statut «Exited (137)» puis «dead» et en essayant de les supprimer les supprimant "Réponse d'erreur du démon: impossible de détruire le conteneur 9ca0b5642a55: Le pilote devicemapper n'a pas réussi à supprimer le système de fichiers racine". Donc j'ai toujours ce problème.

Je ne pouvais pas voir ce qui s'était passé lorsque j'utilisais le pilote syslog (pour essayer de configurer mon système de journalisation) donc je ne sais pas vraiment ce qui s'est passé. Je vous ferai savoir si je règle ça.

@trompx Si ceux-ci traînent depuis l'installation précédente, cela peut causer un problème.
Une fois que les conteneurs sont dans un état "mort", vous pouvez les docker rm -f les à nouveau pour les supprimer du docker et ils ne devraient plus apparaître. Il est probable que les fichiers manquent, de sorte que devicemapper ne puisse pas vraiment les trouver.

J'ai réussi à le faire planter à nouveau mais avec ce pilote de journal de temps json activé. Après avoir vérifié les logs de tous les containers, seul le haproxy retourne une entrée utile "/run.sh: fork: Cannot allocate memory". J'étais un peu à court de mémoire sans échange, et j'ai dû manquer de mémoire. Si c'est la cause, cela signifie-t-il que Docker se plantera lorsqu'il manquera de mémoire, quittant ainsi tous les conteneurs?

@trompx Certainement rien
Les conteneurs ne se terminent pas si le docker tombe en panne, mais lorsque docker démarre la sauvegarde, il tue tous les conteneurs en cours d'exécution (et démarre ceux qui ont une politique de redémarrage).

Je vois cela assez régulièrement lorsque j'utilise docker-compose 1.4.2 et docker-engine 1.8.3 sur Ubuntu 14.04.

@superdump version du noyau?

@gionn : 3.13.0-65-générique

@superdump @gionn idem même versions de logiciel, noyau 3.13.0-67-generic

sur AWS à l'aide de SSD EBS

Quelqu'un a-t-il essayé avec docker 1.9 pour voir si cela avait été corrigé? Il y a eu quelques travaux liés aux volumes ...

Les volumes (dans le sens d'étendre les données en dehors du cycle de vie du conteneur) sont une fonctionnalité différente de ce qui est affecté ici, n'est-ce pas?

Si les montages non partagés sont une solution viable à ces problèmes, docker ne peut-il pas le faire par défaut lorsque le démon démarre ..?
Cela devrait être assez simple à mettre en œuvre.

C'est simple à faire et il existe différentes manières d'accomplir cette tâche. le
les responsables ne voulaient pas accepter les pull requests qui faisaient cela car
était un "hack".
Le ven 27 novembre 2015 à 06:49 Andreas Stenius [email protected]
a écrit:

Si l'annulation des montages est une solution viable à ces problèmes, docker ne peut pas faire
que par défaut lorsque le démon démarre ..?
Cela devrait être assez simple à mettre en œuvre.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/docker/docker/issues/5684#issuecomment -160153438.

Ce n'est pas vrai. Nous l'avons eu et cela a causé des problèmes, nous l'avons donc annulé. C'est trivial pour vous de le faire si cela ne vous pose aucun problème.

Merci pour l'info. Nous avons ajouté le "hack" de unshare sur quelques nœuds,
voir comment ça se passe...
fre 27 nov. 2015 kl. 19:01 skrev Brian Goff [email protected] :

Ce n'est pas vrai. Nous l'avons eu et cela a causé des problèmes, nous l'avons donc annulé.
C'est trivial pour vous de le faire si cela ne vous pose aucun problème.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/docker/docker/issues/5684#issuecomment -160182860.

Salut,

Je reçois le problème discuté ci-dessus lors de l'utilisation de 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

Les informations de ma version de Docker sont les suivantes:
Client:
La dernière version: 1.10.2
Version de l'API: 1.22
Version Go: go1.5.3
Commit Git: c3959b1
Construit: Mon 22 février 21:37:01 2016
OS / Arch: linux / amd64

Serveur:
La dernière version: 1.10.2
Version de l'API: 1.22
Version Go: go1.5.3
Commit Git: c3959b1
Construit: Mon 22 février 21:37:01 2016
OS / Arch: linux / amd64

Il faut noter que je suis tombé sur ce problème très récemment. Je travaille avec Docker depuis près d'un an.

Salut,
Je voulais juste mentionner qu'après avoir redémarré mon ordinateur, j'ai constaté que les conteneurs précédemment non supprimés avaient été supprimés. Cela résout le problème, mais il sera néanmoins irritant de voir des conteneurs s'accumuler et de toujours redémarrer le système d'exploitation.

@chirangaalwis +1. Avez-vous remarqué que cela se produit après que le conteneur a fonctionné pendant un certain temps ou est-ce que cela se produit directement après le démarrage du conteneur?

Salut,
Pour autant que je me souvienne, j'ai vécu cela après un temps considérable depuis le début des conteneurs. Pas après très longtemps pour être précis.

Au fait, ce serait bien si quelqu'un pouvait expliquer en détail la raison de ce problème. Je suis relativement nouveau dans le concept de conteneurisation.

@chirangaalwis avez-vous vérifié ce problème: https://github.com/docker/docker/issues/17902 Il semble que cela puisse être spécifique à la version du noyau. Je vais mettre à niveau le noyau sur la machine rencontrant le problème le lendemain environ et voir si cela le résout.

+1. Ouais, semble-t-il, même ma version du noyau est la 3.13. Ouais, je vais aussi vérifier avec ça, des cartes avec ce que j'ai rapporté.

@chirangaalwis @kabobbob ... Je suis sur RHEL 7.2 et le noyau 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

Lors de l'arrêt et du démarrage de conteneurs en utilisant docker-compose , j'obtiens constamment cette erreur ....

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

La seule solution de contournement est d'arrêter et d'attendre quelques secondes avant de réessayer. Le problème est que le redémarrage n'est pas garanti de fonctionner. J'essaye parfois plusieurs fois de redémarrer.

@chirangaalwis @marcellodesales J'ai pu mettre à niveau le serveur vers le noyau 3.16 et essayé un arrêt de conteneur et rm. Tout semblait bien fonctionner. Il faudra travailler et voir si le problème est résolu.

@kabobbob veuillez signaler dans quelques jours si cela s'est avéré mieux fonctionner ... Je vais essayer de mettre à jour mes environnements de pré-production et de faire un rapport.

Avait cela sur rhel 7.2 - une mise à jour yum et un redémarrage de systemctl l'ont corrigé.

Utilisait directement LVM et Docker version 1.9.1

J'ai également ce problème. Ma configuration: Ubuntu 14.04, mise à jour vers le noyau "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".

Lorsque docker-compose up -d redémarre un conteneur à cause d'une nouvelle image, il se termine souvent par l'impossibilité de supprimer le conteneur arrêté.

Seul un redémarrage aidera à démarrer le conteneur. Alors le problème n'est pas reproductible à 100% mais il arrive très souvent. Je suis donc obligé de redémarrer fréquemment la machine hôte :-(

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

et

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

@dsteinkopf Avez-vous rencontré ce

Non, le problème existait déjà en utilisant docker 1.10 et avec le noyau par défaut ubuntu 14.04-kernel (~ 3.10 je pense) et en utilisant aufs. Ensuite, j'ai mis à niveau (étape par étape) le pilote de stockage, le noyau et le docker. Pas de changement significatif dans le problème rencontré ...

Pensez-vous qu'il vaut la peine d'essayer la superposition concernant ce problème? (Les performances ne sont pas un gros problème dans mon cas.)

@thaJeztah je n'ai jamais vu ce problème avant et depuis que je

Avez-vous rencontré cela après la mise à niveau de 1.10 à 1.11

J'ai ce problème :(

J'ai toujours ça
RHEL 7.2 noyau-3.10.0-327.el7.x86_64
Docker version 1.9.1, build 78ee77d / 1.9.1
mappeur-de-périphérique-libs-1.02.107-5.el7_2.1.x86_64

J'ai également eu le problème:

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

version 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

infos 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

uname -a

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

C'est un mélange de différents problèmes. Je pense que nous devons fermer cela. Aucun des derniers cas signalés ne ressemble au PO.

@guenhter Je soupçonne que cela est lié à un autre problème avec le montage de / var / run dans un conteneur (tout autre conteneur sur votre hôte) ou le montage de / var / lib / docker

@guenhter Pour la

De plus, la plupart des problèmes antérieurs à 1.11 avec des erreurs de type "périphérique ou ressource occupé" sont très probablement dus à la destruction du démon (sans grâce) et à son redémarrage.
Cela provoque la remise à 0 du nombre de références internes sur les montages du pilote de stockage, tandis que les montages eux-mêmes sont toujours actifs.
1.11 traite de ce cas.

Fermeture pour les raisons exposées ci-dessus.

Désolé, je ne suis pas sûr de comprendre cela. Qu'entendez-vous par "Aucun des derniers cas signalés ne ressemble au PO"?
Que dois-je (et les autres personnes confrontées à ce problème) faire? Ouvrir une autre affaire?

@dsteinkopf Oui, avec autant de détails que vous pouvez fournir (composition de fichiers, journaux de démon, etc.).

Bonjour juste pour noter le problème que j'ai spécifié plus tôt, j'ai mis à niveau ma version de noyau vers 4.4.0-21-generic et les informations de version de docker sont les suivantes:
Client:
La dernière version: 1.11.0
Version de l'API: 1.23
Version Go: go1.5.4
Commit Git: 4dc5990
Construit: mer 13 avril 18:38:59 2016
OS / Arch: linux / amd64

Serveur:
La dernière version: 1.11.0
Version de l'API: 1.23
Version Go: go1.5.4
Commit Git: 4dc5990
Construit: mer 13 avril 18:38:59 2016
OS / Arch: linux / amd64

Le problème signalé précédemment semble avoir cessé de se produire. Utilisé Docker pendant un temps considérable en mettant à jour les versions du noyau et il semblait s'être arrêté.

Trouvé une solution de contournement pour le problème, au moins lorsqu'il est utilisé avec docker-compose voir https://github.com/docker/docker/issues/3786#issuecomment -221601065

Même problème avec un conteneur qui ne redémarre pas.

Ubuntu 14.04
Noyau: 3.13.0-24-générique
Version 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

Erreur:

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

Le démontage échoue:

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

C'est toujours un problème pour nous (en utilisant 1.11.2 sur Ubuntu 14.04.4 LTS (avec KVM) (3.13.0-88-generic)).

Y a-t-il un ticket ouvert auquel je peux m'abonner pour obtenir des mises à jour?

@GameScripting Voir # 21704

Linux zk1 3.10.0-327.28.3.el7.x86_64 (centos 7)
Docker version 1.12.1, build 23cf638

Réponse d'erreur du démon: le pilote devicemapper n'a pas réussi à supprimer le système de fichiers racine 228f2c2da3de4d5abd3881184aeb330a4c18e4311ecf404e2fb8cd4ffe15e901: devicemapper: erreur d'exécution de DeleteDevice dm_task_run a échoué

Je viens de rencontrer ça. /etc/init.d/docker restart aidé, je suis heureux que ce ne soit pas sur une machine de production ... 😢

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

J'ai toujours ça aussi

$ docker --version
Docker version 1.12.2, build bb80604

Le même problème s'est produit sur de nombreuses versions de Docker. J'utilise docker-compose pour recréer des conteneurs. Parfois cela fonctionne proprement, parfois non. Le redémarrage du démon docker ou le redémarrage du serveur nettoie le conteneur défectueux.

Arch Linux; conteneurs devicemapper sur 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

Si ça aide ...

Je crois que j'ai le même problème / similaire ici aussi. Si vous déployez un service à l'aide de compose up -d, puis mettez à jour le nom de l'image vers un autre dans le compose.yaml et effectuez un autre compose up -d, la composition échoue avec une erreur autour de devicemapper:

Erreur
ERREUR: pour <> Le pilote devicemapper n'a pas réussi à supprimer le système de fichiers racine 216c098e0f051407863934c27111bd1e9b7561dff1c4d67c0f0d45a99505fa70: Le périphérique est occupé

Information sur la version:
version docker
Client:
La dernière version: 1.12.1
Version de l'API: 1.24
Version Go: go1.6.3
Commit Git: 23cf638
Construit:
OS / Arch: linux / amd64

Serveur:
La dernière version: 1.12.1
Version de l'API: 1.24
Version Go: go1.6.3
Commit Git: 23cf638
Construit:
OS / Arch: linux / amd64

Comme solution de contournement temporaire, j'ai ajouté un docker-compose down --rmi tout avant de réexécuter le up.

J'ai également le même problème dans la version Docker: 1.12.3

Je suis presque sûr que le reste des personnes qui rencontrent ce problème est lié à # 27381

Je vois cela dans docker 1.12.3 sur 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 Mon 24 octobre 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux
dc2-elk-02: / root / staging / ls-helper $ docker rm ls-helper
Réponse d'erreur du démon: Driver devicemapper n'a pas réussi à supprimer le système de fichiers racine e1b9cdeb519d2f4bea53a552c8b76c1085650aa76c1fb90c8e22cac9c2e18830: Le périphérique est occupé

PS Je n'utilise pas docker compose.

Mordu après que l'hôte soit à court d'espace disque.
Toute commande affectant le point de montage se bloque (y compris "docker ps", "sync", "ls", ...)

J'ai eu un problème similaire, j'ai vu ces erreurs dans mon fichier / 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"
J'ai essayé de rechercher le point de montage sous /var/lib/docker/volumes mais je n'en ai trouvé aucun
enfin redémarrer le système a résolu le problème