@vieira Harap

Langkah-langkah di atas dapat direproduksi bahkan setelah me-reboot mesin.

@alexlarsson bisakah Anda melihatnya? Sepertinya ini terkait dengan devicemapper

Masalahnya sepertinya terkait dengan devicemapper. Saya pikir itu benar-benar sesuatu yang lain.
Saya mencoba ini, dan masalahnya adalah bagian "stop docker". Jika saya hanya menekan ctrl-c daemon buruh pelabuhan itu akan mencoba menghentikan kontainer dengan benar, tetapi sepertinya tidak pernah berhasil menghentikan kontainer. Jadi, saya ctrl-c beberapa kali lagi untuk memaksa buruh pelabuhan mati.

Pada titik ini container (tail) masih berjalan, sehingga device mapper device akan dipasang, yang berarti kita tidak bisa memasangnya lagi, atau menghapusnya. Inilah mengapa operasi ini gagal.

@alexlarsson tahukah Anda cara mudah untuk membersihkan sistem jika terjadi kesalahan?

Nah, jika Anda menemukan proses kontainer pelarian mungkin Anda bisa memaksa membunuhnya.

@vieira Anda dapat melepas:
umount / var / lib / docker / devicemapper / mnt / c39206003c7ae8992a554a9ac2ea130327fc4af1b2c389656c34baf9a56c84b5

dan mulai wadah lagi itu harus bekerja

Saya dapat melihat bahwa buruh pelabuhan saya dimulai dengan -d dan -r. Pertama, saat buruh pelabuhan di-restart, kontainer tidak akan dimulai ulang. Kemudian kesalahan yang disebutkan di atas terjadi (saat mencoba memulai penampung).

Centos 6.5 saya masih mendapatkan 1.0.0.6 dari epel. Apakah ini pernah diidentifikasi sebagai bug di 1.0 dan diperbaiki di 1.1? Adakah yang bisa mengkonfirmasi?

Terima kasih

Halo semuanya, masih belum diperbaiki di 1.1.1.
Langkah-langkah di postingan asli masih berlaku.

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

Saya mendapatkan banyak juga, tetapi tampaknya menghapus penampung dalam beberapa hal (karena saya dapat memulai penampung baru dengan nama yang sama)

Apakah ada solusi untuk masalah ini?

Mencari solusi juga.

Sepertinya menghentikan semua kontainer sebelum daemon buruh pelabuhan memperbaiki masalah.

Saya telah menambahkan blok pre-stop ke pekerjaan pemula saya sebagai solusi:

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

Berikut adalah inti dari langkah-langkah debugging saya: https://gist.github.com/rochacon/4dfa7bd4de3c5f933f0d

@rochacon Terima kasih atas solusi Anda. Saya akan mengujinya hari ini atau besok dengan 1.2 (sepertinya Anda menguji dengan 1.1.1, kan?). Semoga berhasil.

@vieira Saya juga mencoba dengan 1.2.0, hasil yang sama.

Setelah 4 minggu berjalan, salah satu penampung saya berhenti ... Tidak yakin mengapa ... Bagaimana saya dapat menemukan akar masalahnya?

Bagaimanapun, saya memiliki masalah yang sama ... Ini diselesaikan dengan saran dari @aroragagan : umount, docker start container ... Saya menggunakan RHEL 6.5 omong-omong ...

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

Kami melihat ini di 1.3.0 sekarang, pada sistem Ubuntu EC2 yang ditingkatkan dari 12.04 menjadi 14.04. Instance dev saya adalah instal langsung 14.04 ke Vagrant dan tidak memiliki masalah ini. Melepas dan memulai ulang penampung tampaknya berhasil, tetapi itu menggagalkan tujuan agar penampung dikonfigurasi untuk memulai ulang secara otomatis saat instans di-boot ulang atau saat pekerja galangan dimulai ulang. Beri tahu saya jika ada informasi lebih lanjut yang dapat saya berikan tentang versi paket pendukung, dll, karena saya memiliki sistem yang berfungsi dan tidak berfungsi.

Melihat masalah yang sama dengan buruh pelabuhan 1.3 Ubuntu 14.04 dengan kernel Linux 3.13 atau 3.14.

@srobertson, apakah Anda merujuk ke "kontainer tidak direstart ketika daemon restart"? Apakah Anda menggunakan kebijakan restart _per-container_ yang baru? Karena daemon -r / --restart=true telah dihapus di Docker 1.2

Kebijakan mulai ulang (per penampung) baru dijelaskan dalam referensi CLI

+1, dapatkan masalah ini di buruh pelabuhan 1.3 @ ArchLinux x86_64 dengan kernel 3.17.2-1-ARCH.

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

Umount memecahkan masalahnya.

umount adalah solusi, saya tidak akan mengatakan itu menyelesaikan masalah. Cukup dengan memulai ulang daemon dengan kontainer yang sedang berjalan akan mereproduksi masalah.

umount berfungsi untuk saya pada versi buruh pelabuhan berikut:

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

Saya menghentikan daemon buruh pelabuhan terlebih dahulu, lalu:

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

@ mlehner616 Ya, Anda benar. Maaf, tentu saja ini solusi, bukan solusi. Itu hanya pilihan kata yang buruk.

Saya ingin melihat ini diperbaiki juga, tentu saja. =)

fyi, unmounten tidak bekerja untuk saya. Saya mendapatkan pesan kesalahan bahwa tidak ada mount yang dapat ditemukan di / etc / mtab
Docker versi 1.0.0, build 63fe64c / 1.0.0 di RHEL 6.5

Saya telah mengatasinya dengan secara otomatis melepas semua mount lama saat daemon buruh pelabuhan kembali. Saya tidak ingin menambal /etc/init/docker.conf ubuntu yang besar, jadi saya meletakkan baris kecil di /etc/default/docker sebagai gantinya:

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

Itu sepertinya berhasil. Saya telah menggabungkannya dengan memulai pengelolaan baru dan memulai kembali kontainer buruh pelabuhan saya yang sebenarnya, jadi sekarang setelah service docker restart , semua kontainer akan kembali.

Terima kasih, @jypma , itu juga berhasil untuk saya!

_review session_ dengan @unclejack

Kami akan menggunakan terbitan ini sebagai pelacak untuk sebagian besar laporan "perangkat atau sumber daya sibuk" atau EBUSY .

Masalah ini, seperti masalah lainnya, diatasi dengan menangani namespace mount dari daemon buruh pelabuhan dengan benar. Saat ini tidak ada penanganan default dari ruang nama mount, jadi kami memiliki masalah seperti EBUSY ini.

Sementara kami mengerjakan solusi resmi untuk menanganinya, ada solusi yang dapat Anda terapkan sendiri. Lihat http://blog.hashbangbash.com/2014/11/docker-devicemapper-fix-for-device-or-resource-busy-ebusy/

Mengonfirmasi bahwa saya mengalami masalah ini juga menggunakan gambar freeipa stok. Saya menghentikan layanan buruh pelabuhan dan ketika saya mencoba untuk memulai ulang bersama dengan kontainer ipa saya mendapatkan yang berikut ini.

$ 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

Melepas "mount" mengatasi masalah ini sehingga saya dapat memulai ulang penampung.

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

$ docker start ipa
ipa

Menggunakan berikut ini:

$  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 memperbaiki masalah saya

buruh pelabuhan --version
Docker versi 1.3.2, build 39fa2fa

Jadi penyelesaian berikut adalah penyelesaian yang sedikit lebih permanen untuk kasus penggunaan saya.
Saya benar-benar menggunakan Amazon linux (RedHat6-Like) jadi saya membuat sedikit modifikasi pada skrip init (yang mungkin akan ditimpa jika buruh pelabuhan diperbarui.) Pada dasarnya semua yang dilakukan ini adalah menghentikan buruh pelabuhan seperti biasa, memeriksa tunggangan buruh pelabuhan yang tersisa , jika ada, lepaskan mereka. YMMV

_ / etc / init.d / docker_
Menambahkan variabel lib (baris ~ 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"

Menambahkan blok umount untuk menghentikan fungsi (baris ~ 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
}

Saya mengalami masalah yang sama dengan buruh pelabuhan 1.4.1 menggunakan mapper perangkat sebagai driver penyimpanan. Saya bisa mengumpulkan jejak tumpukan panik dari buruh pelabuhan melalui file log-nya.

LINGKUNGAN HIDUP

$ cat / etc / * rilis
DISTRIB_ID = Ubuntu
DISTRIB_RELEASE = 14,04
DISTRIB_CODENAME = terpercaya
DISTRIB_DESCRIPTION = "Ubuntu 14.04.1 LTS"
NAME = "Ubuntu"
VERSI = "14.04.1 LTS, Tahr Terpercaya"
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/ "

$ versi buruh pelabuhan
sudo: tidak dapat menyelesaikan host ip-172-30-0-39
Versi klien: 1.4.1
Versi API Klien: 1.16
Go versi (klien): go1.3.3
Git commit (klien): 5bc2ff8
OS / Arch (klien): linux / amd64
Versi server: 1.4.1
Versi API Server: 1.16
Go versi (server): go1.3.3
Git commit (server): 5bc2ff8

$ tail -f / var / log / upstart / buruh pelabuhan
...
INFO [143413] -kecepatan pekerjaan (3dfcbc075227d5b3f0115bd73a1fea4a56a2c0fc68190d84b6d88e93938b4121, 37, 130)
2015/01/22 22:29:22 http: layanan panik @: error runtime: alamat memori tidak valid atau dereferensi pointer nol
goroutine 1932 [berjalan]:
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).Jalankan(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. (_ samb) .serve (0xc20a836300)
/usr/local/go/src/pkg/net/http/server.go:1174 + 0xa7e
dibuat oleh net / http. (* Server) .Serve
/usr/local/go/src/pkg/net/http/server.go:1721 + 0x313

...

INFO [0056] HAPUS /v1.16/containers/hoopla_docker_registry
INFO [0056] + rm pekerjaan (hoopla_docker_registry)
Tidak dapat menghancurkan kontainer hoopla_docker_registry: Driver devicemapper gagal menghapus sistem file root 6abcbfefe8bdd485dfb192f8926
3add895cda1ae28b578d4a0d9b23574dedc5c: Perangkat Sibuk
INFO [0066] -pekerjaan rm (hoopla_docker_registry) = ERR (1)
ERRO [0066] Penangan untuk DELETE / containers / { name :. *} mengembalikan kesalahan: Tidak dapat menghancurkan kontainer hoopla_docker_registry: Drive
r devicemapper gagal menghapus filesystem root 6abcbfefe8bdd485dfb192f89263add895cda1ae28b578d4a0d9b23574dedc5c: Device is Busy

ERRO [0066] Kesalahan HTTP: statusCode = 500 Tidak dapat menghancurkan kontainer hoopla_docker_registry: Driver devicemapper gagal menghapus sistem file root 6abcbfefe8bdd485dfb192f89263add895cda1ae28b578d4a0d9b23574dedc5c: Perangkat Sibuk

Saya melihat ini di ubuntu 14.04 (di ec2) dengan 1.4.1 dan juga tidak dengan 1.5. Aneh, karena buruh pelabuhan tampaknya sangat andal di linux mint 17 tetapi sangat tidak dapat diandalkan di server build kami dengan ubuntu 14.04.

Apakah ada cara untuk tidak menggunakan devicemapper, karena masalah ini sepertinya sudah ada sejak 0,9 hari?

Ini juga bisa terjadi dengan overlayf.

Nah, saya baru saja mengganti aufs dan sejauh ini tidak ada masalah.

Apa status masalah ini? Saya melihat beberapa PR digabungkan yang mungkin terkait tetapi tidak ada yang dinyatakan dengan jelas adalah perbaikan untuk ini. Ini adalah masalah _major_ pada produksi dan satu-satunya penyelesaian sekarang adalah menambal skrip init untuk melepas drive dengan bersih.

setelah meninjau ini lagi, ini bukan contoh ideal dari EBUSY yang semula kami katakan.
Kasus ini lebih berkaitan dengan tutup wadah yang tidak menangani sinyal dengan baik.

Karena kasus reproduksi di sini tail -f /dev/null tidak keluar pada SIGQUIT saat daemon keluar, maka driver devmapper tidak dapat membongkar dengan benar (ini tidak eksklusif untuk devmapper). Sebelum daemon dijalankan kembali, Anda dapat melihat tail -f /dev/null masih berjalan, bahkan saat buruh pelabuhan tidak.

Masalah seperti ini akan membutuhkan pemikiran tentang seberapa drastis memperlakukan pids dalam wadah saat buruh pelabuhan keluar ... @unclejack @crosbymichael pikiran?

Menguji ini di Fedora 21 x86_64. Memberikan informasi untuk tujuan perbandingan hanya karena masalahnya sepertinya tidak ada (lagi?). Hasil yang sama menggunakan centos: 7 atau ubuntu: gambar

$ 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

Sistem Informasi:

$ 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

Jalankan saja ini di 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

menjalankan umount /var/lib/docker/devicemapper/mnt/f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774 membantu.

Saya memiliki masalah yang sama di 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 gagal.

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

Lingkungan Hidup

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

Saya mereproduksinya dengan buruh pelabuhan 1.3.2 dari repositori resmi 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

buruh pelabuhan 1.5.0 mendapat bug yang sama
Error response from daemon: Cannot destroy container 485bf8d6502a: Driver devicemapper failed to remove root filesystem 485bf8d6502a6cf448075d20c529eb24f09a41946a5dd1c61a99e17

Masalah yang sama di sini, mudah direproduksi

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

Lingkungan Hidup

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: Satu-satunya solusi bagi saya (saya tidak menggunakan system.d) adalah memperbarui /etc/init.d/docker, baris 50 dengan perintah unshare. Perbaikan telah disediakan oleh @vbatts , Terima kasih btw
Namun, perbaikan ini tidak dapat diskalakan. Kami tidak ingin memperbarui setiap mesin yang kami miliki + Ini akan terhapus saat kami memperbarui buruh pelabuhan.

1. Apa saja pilihan saya yang lain?
2. Apakah ada sisi buruh pelabuhan memperbaiki yang keluar?
3. Apakah ini memengaruhi semua sistem operasi?
4. Apakah ini memengaruhi semua kernel?

Terima kasih

Saya pikir https://github.com/docker/docker/pull/12400 akan memperbaiki ini. Ini karena shutdown daemon buruh pelabuhan akan membuat container yang berjalan tidak dibersihkan (jika container tidak dimatikan dalam 10 detik, rootf container masih akan dipasang) dan tidak akan bisa dihapus pada daemon start berikutnya. (Saya menguji overlay)

Terima kasih @ coolljt0725 .

1) Docker versi apa yang akan diimplementasikan?
2) Apa saja pilihan saya yang lain?
3) Apakah itu mempengaruhi semua sistem operasi?
4) Apakah ini memengaruhi semua kernel?

Terima kasih

1 untuk solusi umount. terjadi pada saya dengan buruh pelabuhan 1.6.0, build 4749651.
layanan docker restart tidak menyelesaikannya. umount 'volume' yang bermasalah memperbaikinya.

Docker 1.6.1 (Ubuntu 14.04) masih mengalami masalah ini. umount bekerja.

Docker 1.6.2 (Ubuntu 14.04) umount tidak berfungsi

Docker 1.7.0 Centos 6.5 masih memiliki masalah yang sama.

Saya baru saja mendapatkan ini di Centos 6.3 setelah memutakhirkan ke Docker 1.7. Pemutakhiran merestart buruh pelabuhan (jelas), dan ketika saya pergi untuk me-restart kontainer, semua kontainer node.js saya restart, tetapi yang menjalankan uwsgi memberikan kesalahan:

# 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

Melakukan umount /local/docker/devicemapper/mnt/48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549 TIDAK memperbaiki masalah.

Sama di Debian. Tidak dapat memulai penampung apa pun, bahkan saat menarik gambar hello-world yang benar-benar segar.

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 Harap berikan docker info .

@unclejack docker info untuk host saya adalah

$ 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 dan CentOS 6 tidak lagi didukung oleh Red Hat untuk digunakan dengan Docker. Harap tingkatkan ke RHEL 7 atau CentOS 7.

Docker secara resmi mendukung Centos 6.5 (https://docs.docker.com/installation/centos/). Selain itu, kami telah memperbarui kernel menjadi 3.10. Orang lain di sini melaporkan kesalahan itu ada di CentOS 7 juga. Sepertinya lebih seperti masalah peta perangkat daripada masalah versi CentOS. Saya tidak punya alasan untuk percaya bahwa memutakhirkan ke CentOS 7 akan melakukan sesuatu yang berbeda.

Saya baru saja memiliki ini di CentOS 7, Docker versi 1.6.0, build 4749651 dengan devicemapper. 15 kontainer saya semuanya rusak. Saya mencoba menghapus beberapa gambar yang menjuntai dan mendapatkan kesalahan yang sama:

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 dengan daemon dihentikan, menjalankan mount | grep docker mungkin menampilkan beberapa direktori yang dipasang (seperti /dev/mapper/docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0 on ... ). Anda dapat umount ini terlebih dahulu, kemudian menjalankan daemon lagi. Jika masalah masih ada, dmsetup ls | grep docker dan lihat entri seperti docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0 (253:5) . Di antaranya Anda dapat menelepon dmsetup remove docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0

@vbatts Terima kasih atas bantuannya. Masalah sebenarnya kami adalah bahwa cluster produksi kami yang terdiri dari 15 mesin baru saja mati. Ini pembahasan yang berbeda, tapi apa yang harus dilakukan jika kita menginginkan dukungan pada buruh pelabuhan?

Saya memiliki masalah serupa setelah saya meningkatkan ke 1.7, itu berfungsi dengan baik di 1.6.2 di ElementOS.

Setiap kali saya memulai wadah apa pun , saya mendapatkan pesannya

Respons kesalahan dari daemon: Tidak dapat memulai penampung 560640442c770dff574f5af7b6cdcc8e86ba8a613db87bf90a77aea7f0db322a: perangkat atau sumber daya sibuk

Saya membersihkan buruh pelabuhan, rm -rf / var / lib / buruh pelabuhan, dan dengan instalasi baru masih mendapatkan kesalahan yang sama saat menjalankan image hello-world.

Saya juga memperhatikan bahwa folder menumpuk di / var / docker / lib / aufs / mnt setelah setiap upaya yang gagal.

Saya sangat sering memukul ini, dan saya menggunakan aufs, bukan 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

Beri tahu saya jika ada informasi debugging lagi yang dapat saya berikan.

Melihat masalah yang sama. umount tidak berfungsi, dikatakan folder tidak dipasang. Saya mengamati ini dengan buruh pelabuhan 1.5.0, lalu saya memperbarui ke 1.7.1 dengan efek yang sama.

$ 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

Melihat hal yang sama di 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

Saya akan menjalankan aplikasi dan apakah masalah ini telah teratasi, saya tidak dapat menggunakan buruh pelabuhan dalam produksi karena saya telah mengalami beberapa kontainer macet dan saya tidak dapat menghapusnya tanpa reboot sistem, yang merupakan masalah pada sistem produksi.

@trompx devicemapper dengan sinkronisasi udev dinonaktifkan tidak akan berfungsi.
Ini adalah bagian dari alasan kami sekarang menawarkan biner dinamis (yang memperbaiki masalah sinkronisasi), bukan biner statis.
Saya akan merekomendasikan untuk mengganti repo Anda dari get.docker.com (dan paket lxc-docker) dengan repo apt.dockerproject.org (dan paket docker-engine).
Lihat http://blog.docker.com/2015/07/new-apt-and-yum-repos/ untuk lebih jelasnya.

Ada juga status penampung (ish) baru yang disebut "mati", yang disetel saat ada masalah saat menghapus penampung. Ini tentu saja merupakan solusi untuk masalah khusus ini, yang memungkinkan Anda pergi dan menyelidiki mengapa ada kesalahan device or resource busy (mungkin kondisi balapan), dalam hal ini Anda dapat mencoba menghapus lagi, atau mencoba secara manual fix (mis. unmount semua mount yang tersisa, lalu hapus).

Mungkin graphdrivers dapat menjadi sedikit lebih tangguh dalam kasus di mana kita memiliki semacam perlombaan dengan fs (misalnya, coba unmount lagi).

@ cpuguy83 Terima kasih atas infonya. Saya sekarang menggunakan versi terakhir dengan udev true tetapi ketika saya mencoba menyiapkan sistem pemantauan logging, terjadi masalah yang mengakibatkan semua penampung saya dengan status "Keluar (137)" lalu "mati" dan mencoba menghapusnya mencegah saya dari menghapusnya "Respons error dari daemon: Tidak dapat menghancurkan container 9ca0b5642a55: Driver devicemapper gagal menghapus filesystem root". Jadi saya masih punya masalah ini.

Saya tidak bisa melihat apa yang terjadi karena saya menggunakan driver syslog (untuk mencoba mengatur sistem logging saya) jadi saya tidak begitu tahu apa yang terjadi. Saya akan memberi tahu Anda jika saya menyelesaikan masalah ini.

@trompx Jika ini tergantung dari penginstalan sebelumnya, ini dapat menyebabkan masalah.
Setelah kontainer dalam keadaan "mati" Anda dapat docker rm -f mereka lagi untuk menghapusnya dari buruh pelabuhan dan mereka tidak akan muncul lagi. Kemungkinan file hilang sehingga devicemapper tidak dapat menemukannya.

Saya berhasil membuatnya crash lagi tetapi dengan waktu itu log driver json on. Setelah memeriksa log dari semua kontainer, hanya haproxy yang mengembalikan beberapa input berguna "/run.sh: fork: Cannot mengalokasikan memori". Saya sedikit kehabisan memori tanpa swap, dan saya pasti kehabisan memori. Jika itu penyebabnya, apakah itu berarti Docker akan crash saat kehabisan memori, sehingga keluar dari semua container?

@trompx Tentu tidak ada yang menghentikan Docker dari menjadi OOM terbunuh.
Container tidak keluar jika buruh pelabuhan mengalami crash, namun ketika buruh pelabuhan mulai kembali itu mematikan semua container yang sedang berjalan (dan memulai yang memiliki kebijakan restart).

Saya melihat ini secara teratur ketika menggunakan docker-compose 1.4.2 dan docker-engine 1.8.3 di Ubuntu 14.04.

@superdump versi kernel?

@gionn : 3.13.0-65-generik

@superdump @gionn ditto versi perangkat lunak yang sama, kernel 3.13.0-67-generik

di AWS menggunakan SSD EBS

Adakah yang mencoba dengan buruh pelabuhan 1.9 untuk melihat apakah hal itu telah diperbaiki? Ada beberapa pekerjaan yang berhubungan dengan volume ...

Volume (dalam arti memperluas data di luar siklus hidup kontainer) adalah fitur yang berbeda dari apa yang terpengaruh di sini bukan?

Jika unshare mounts adalah solusi yang bisa diterapkan untuk masalah ini, tidak bisakah buruh pelabuhan melakukannya secara default saat daemon dimulai ..?
Itu seharusnya cukup sederhana untuk diterapkan ..

Ini sederhana untuk dilakukan dan ada berbagai cara untuk menyelesaikan tugas ini. Itu
pengelola tidak ingin menerima permintaan penarikan yang melakukan ini karena itu
adalah "hack".
Pada Jum, 27 Nov 2015 pukul 06.49 Andreas Stenius [email protected]
menulis:

Jika unshare mounts adalah solusi yang bisa diterapkan untuk masalah ini, tidak dapat melakukan docker
yang secara default ketika daemon dimulai ..?
Itu seharusnya cukup sederhana untuk diterapkan ..

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/5684#issuecomment -160153438.

Itu tidak benar. Kami memang memiliki ini dan itu menyebabkan masalah jadi kami mengembalikannya. Sepele bagi Anda untuk melakukannya jika itu tidak menimbulkan masalah bagi Anda.

Terimakasih atas infonya. Kami telah menambahkan "retas" yang tidak dibagikan pada beberapa node,
lihat bagaimana kelanjutannya ...
gratis 27 nov. 2015 kl. 19:01 skrev Brian Goff [email protected] :

Itu tidak benar. Kami memang memiliki ini dan itu menyebabkan masalah jadi kami mengembalikannya.
Sepele bagi Anda untuk melakukannya jika itu tidak menimbulkan masalah bagi Anda.

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/5684#issuecomment -160182860.

Hai,

Saya mendapatkan masalah yang dibahas di atas saat menggunakan 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

Informasi Versi Docker saya adalah sebagai berikut:
Klien:
Versi: 1.10.2.0
Versi API: 1.22.0
Go versi: go1.5.3
Git commit: c3959b1
Dibangun: Sen 22 Feb 21:37:01 2016
OS / Arch: linux / amd64

Server:
Versi: 1.10.2.0
Versi API: 1.22.0
Go versi: go1.5.3
Git commit: c3959b1
Dibangun: Sen 22 Feb 21:37:01 2016
OS / Arch: linux / amd64

Perlu dicatat bahwa saya menemukan masalah ini baru-baru ini. Saya telah bekerja dengan Docker hampir setahun.

Hai,
Hanya ingin menyebutkan bahwa setelah saya me-restart komputer saya, saya menemukan bahwa kontainer yang sebelumnya tidak dihapus telah dihapus. Ini memang menyelesaikan masalah yang dihadapi, tetapi akan menjengkelkan jika kontainer menumpuk dan selalu harus me-reboot OS.

@chirangaalwis +1. Pernahkah Anda memperhatikan ini terjadi setelah penampung telah berjalan selama beberapa waktu atau apakah itu terjadi langsung setelah memulai penampung?

Hai,
Sejauh yang saya ingat, saya mengalami ini setelah waktu yang cukup lama sejak dimulainya kontainer. Tidak setelah waktu yang sangat lama tepatnya.

Ngomong-ngomong alangkah baiknya jika seseorang bisa memberikan penjelasan yang menyeluruh tentang alasan dibalik masalah ini. Saya relatif baru dengan konsep containerization.

@chirangaalwis sudahkah Anda memeriksa masalah ini: https://github.com/docker/docker/issues/17902 Tampaknya ini khusus untuk versi kernel. Saya akan memutakhirkan kernel pada mesin yang mengalami masalah di sekitar hari berikutnya dan melihat apakah itu menyelesaikannya.

+1. Ya sepertinya begitu, bahkan versi kernel saya adalah 3.13. Ya, saya juga akan memeriksa dengan ini, peta dengan apa yang telah saya laporkan.

@chirangaalwis @kabobbob ... Saya menggunakan RHEL 7.2 dan 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

Saat menghentikan dan memulai kontainer menggunakan docker-compose , saya terus-menerus mendapatkan kesalahan ini ....

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

Satu-satunya solusi adalah berhenti, dan tunggu beberapa detik sebelum mencoba lagi. Masalahnya adalah restart tidak dijamin berhasil. Saya terkadang mencoba beberapa kali untuk memulai ulang.

@chirangaalwis @marcellodesales Saya bisa mengupgrade server ke kernel 3.16 dan mencoba container stop dan rm. Semua sepertinya bekerja dengan baik. Akan perlu bekerja dan melihat apakah masalah telah teratasi.

@kabobbob tolong laporkan dalam beberapa hari jika itu terbukti bekerja lebih baik ... Saya akan mencoba meningkatkan lingkungan pra-prod saya dan melaporkan.

Apakah ini di rhel 7.2 - pembaruan yum && reboot systemctl memperbaikinya.

Menggunakan LVM langsung dan Docker versi 1.9.1

Saya juga mengalami masalah ini. Pengaturan saya: Ubuntu 14.04, diperbarui ke kernel "3.19.0-58-generic # 64 ~ 14.04.1-Ubuntu". Docker versi 1.11.0, build 4dc5990. "docker-compose versi 1.7.0, build 0d7bf73".

Saat docker-compose up -d memulai ulang penampung karena gambar baru, sering kali tidak dapat menghapus penampung yang dihentikan.

Hanya reboot yang akan membantu untuk memulai penampung. Maka masalahnya bukan 100% dapat direproduksi tetapi itu sering terjadi. Jadi saya terpaksa sering mereboot mesin host :-(

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

dan

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

@dsteinkopf Apakah Anda mengalami ini setelah meningkatkan dari 1,10 ke 1,11? Adakah alasan Anda menggunakan devicemapper di Ubuntu? Secara keseluruhan, default (aufs) akan memberi Anda kinerja yang lebih baik. Pada kernel 3.19, overlay mungkin merupakan pilihan yang lebih baik

Tidak, masalah sudah ada menggunakan buruh pelabuhan 1.10 dan dengan ubuntu 14.04-kernel default (~ 3.10 menurut saya) dan dengan menggunakan aufs. Kemudian saya mengupgrade (langkah demi langkah) driver penyimpanan, kernel dan buruh pelabuhan. Tidak ada perubahan signifikan pada masalah yang dialami ...

Apakah menurut Anda, ada baiknya mencoba overlay tentang masalah ini? (Performa bukanlah masalah besar dalam kasus saya.)

@thaJeztah Saya tidak pernah melihat masalah ini sebelumnya dan sejak saya

Apakah Anda mengalami ini setelah meningkatkan dari 1,10 ke 1,11

Saya memiliki masalah ini :(

Masih pakai ini
RHEL 7.2 kernel-3.10.0-327.el7.x86_64
Docker versi 1.9.1, build 78ee77d / 1.9.1
device-mapper-libs-1.02.107-5.el7_2.1.x86_64

Juga mendapat masalah:

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

versi buruh pelabuhan

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

info buruh pelabuhan

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

Ini adalah campuran dari berbagai masalah. Saya pikir kita harus menutup ini. Tak satu pun dari kasus terbaru yang dilaporkan mirip dengan OP.

@guenhter Saya curiga ini terkait dengan masalah lain dengan memasang / var / dijalankan ke dalam wadah (wadah lain di host Anda) atau memasang / var / lib / buruh pelabuhan

@guenhter Untuk catatan # 21969

Selain itu, banyak dari masalah pra-1.11 dengan kesalahan tipe "perangkat atau sumber daya sibuk" kemungkinan besar karena mematikan daemon (tidak terlacak) dan kemudian memulainya kembali.
Hal ini menyebabkan jumlah ref internal pada dudukan driver penyimpanan disetel ulang ke 0, sementara tunggangan itu sendiri masih aktif.
1.11 menangani kasus itu.

Menutup karena alasan yang disebutkan di atas.

Maaf - Saya tidak yakin apakah saya mengerti ini. Apa yang Anda maksud dengan "Tidak ada kasus terbaru yang dilaporkan seperti OP"?
Apa yang harus saya (dan orang lain yang mengalami masalah ini) lakukan? Buka kasus lain?

@dsteinkopf Ya, sedetail yang Anda berikan (buat file, log daemon, dll.).

Halo hanya untuk mencatat tentang masalah yang telah saya tentukan sebelumnya, saya telah meningkatkan versi kernel saya ke 4.4.0-21-generik dan info versi buruh pelabuhan adalah sebagai berikut:
Klien:
Versi: 1.11.0.0
Versi API: 1.23
Go versi: go1.5.4
Git commit: 4dc5990
Dibangun: Rabu 13 Apr 18:38:59 2016
OS / Arch: linux / amd64

Server:
Versi: 1.11.0.0
Versi API: 1.23
Go versi: go1.5.4
Git commit: 4dc5990
Dibangun: Rabu 13 Apr 18:38:59 2016
OS / Arch: linux / amd64

Masalah yang dilaporkan sebelumnya tampaknya telah berhenti terjadi. Docker digunakan untuk waktu yang cukup lama dengan memutakhirkan versi kernel dan sepertinya telah berhenti.

Menemukan solusi untuk masalah ini, setidaknya saat digunakan dengan docker-compose, lihat https://github.com/docker/docker/issues/3786#issuecomment -221601065

Masalah yang sama dengan penampung yang gagal dimulai ulang.

Ubuntu 14.04
Kernel: 3.13.0-24-generik
Versi 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

Kesalahan:

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

Lepas gagal:

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

Ini masih menjadi masalah bagi kami (menggunakan 1.11.2 di Ubuntu 14.04.4 LTS (dengan KVM) (3.13.0-88-generik)).

Apakah ada tiket terbuka yang saya dapat berlangganan untuk mendapatkan pembaruan?

@GameScripting Lihat # 21704

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

Respons kesalahan dari daemon: Driver devicemapper gagal menghapus sistem file root 228f2c2da3de4d5abd3881184aeb330a4c18e4311ecf404e2fb8cd4ffe15e901: devicemapper: Kesalahan menjalankan DeleteDevice dm_task_run gagal

Baru saja mengalami ini. /etc/init.d/docker restart membantu, saya senang ini tidak ada di mesin produksi ... 😢

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

Masih mendapatkan ini juga

$ docker --version
Docker version 1.12.2, build bb80604

Masalah yang sama, telah terjadi di banyak versi Docker. Saya menggunakan docker-compose untuk membuat ulang kontainer. Terkadang itu bekerja dengan bersih, terkadang tidak. Memulai ulang daemon buruh pelabuhan atau me-reboot server akan membersihkan container yang buruk.

Arch Linux; devicemapper container di 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

Jika itu membantu ...

Saya yakin bahwa saya juga mengalami masalah yang sama / serupa di sini. Jika menerapkan layanan menggunakan compose up -d dan kemudian perbarui nama image ke nama lain di compose.yaml dan lakukan compose lain -d compose gagal dengan error di sekitar devicemapper:

Kesalahan
EROR: untuk <> Driver devicemapper gagal menghapus filesystem root 216c098e0f051407863934c27111bd1e9b7561dff1c4d67c0f0d45a99505fa70: Perangkat Sibuk

Informasi Versi:
versi buruh pelabuhan
Klien:
Versi: 1.12.1.0
Versi API: 1.24
Go versi: go1.6.3
Git commit: 23cf638
Dibangun di:
OS / Arch: linux / amd64

Server:
Versi: 1.12.1.0
Versi API: 1.24
Go versi: go1.6.3
Git commit: 23cf638
Dibangun di:
OS / Arch: linux / amd64

Sebagai solusi sementara, saya telah menambahkan docker-compose down --rmi semua sebelum menjalankan ulang up.

Saya juga memiliki masalah yang sama di versi Docker: 1.12.3

Saya cukup yakin orang lain yang mengalami masalah ini terkait dengan # 27381

Saya melihat ini di buruh pelabuhan 1.12.3 di CentOs 7

dc2-elk-02: / root / staging / ls-helper $ docker --version
Docker versi 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 Sen 24 Okt 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux
dc2-elk-02: / root / staging / ls-helper $ docker rm ls-helper
Respons kesalahan dari daemon: Driver devicemapper gagal menghapus sistem file root e1b9cdeb519d2f4bea53a552c8b76c1085650aa76c1fb90c8e22cac9c2e18830: Perangkat Sibuk

PS Saya tidak menggunakan docker compose.

Digigit setelah host keluar-of-disk-space.
Perintah apa pun yang memengaruhi titik pemasangan akan macet (termasuk "docker ps", "sync", "ls", ...)

Saya memiliki masalah serupa, saya melihat kesalahan ini seperti di file / var / log / syslog saya:
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"
Saya mencoba mencari titik pemasangan di bawah /var/lib/docker/volumes tetapi tidak menemukan apa pun
akhirnya reboot sistem memperbaiki masalah