vieira يرجى إعادة تشغيل الجهاز وإعلامنا إذا كنت لا تزال تواجه مشاكل.

الخطوات المذكورة أعلاه قابلة للتكرار حتى بعد إعادة تشغيل الجهاز.

alexlarsson هل يمكنك إلقاء نظرة من فضلك؟ يبدو أنه مرتبط بـ devicemapper

يبدو أن المشكلة تتعلق فقط بالجهاز. اعتقد انه حقا شيء آخر بالرغم من ذلك.
لقد جربت هذا ، والمشكلة هي جزء "عامل الإرساء". إذا قمت فقط بالضغط على ctrl-c الخفي من عامل الإرساء ، فسيحاول إيقاف الحاويات بشكل صحيح ، ولكن يبدو أنه لم ينجح أبدًا في إيقاف الحاوية. لذلك ، أنا ctrl-c عدة مرات لإجبار عامل الرصيف على الموت

في هذه المرحلة ، لا تزال الحاوية (الذيل) قيد التشغيل ، لذلك سيتم تثبيت جهاز مخطط الجهاز ، مما يعني أنه لا يمكننا تركيبه مرة أخرى أو إزالته. هذا هو سبب فشل هذه العمليات.

alexlarsson هل تعرف طريقة سهلة لتنظيف النظام بمجرد حدوث هذا الخطأ؟

حسنًا ، إذا وجدت عملية الحاوية الجامحة ، فربما يمكنك قتلها بالقوة.

vieira يمكنك إلغاء
umount / var / lib / docker / devicemapper / mnt / c39206003c7ae8992a554a9ac2ea130327fc4af1b2c389656c34baf9a56c84b5

وبدء الحاوية مرة أخرى يجب أن تعمل

أستطيع أن أرى أن عامل الإرساء الخاص بي بدأ بـ -d و -r. أولاً ، عند إعادة تشغيل عامل الإرساء ، لا يتم إعادة تشغيل الحاويات. ثم يحدث الخطأ المذكور أعلاه (عند محاولة بدء تشغيل الحاوية (الحاويات)).

لا يزال سنتوس 6.5 الخاص بي يحصل على 1.0.0.6 من epel. هل تم تحديد هذا على أنه خطأ في 1.0 وتم إصلاحه في 1.1؟ هل يمكن لشخص ما أن يؤكد؟

شكر

مرحبًا بالجميع ، لم يتم إصلاح هذا بعد في 1.1.1.
لا تزال الخطوات الواردة في المنشور الأصلي سارية.

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

أحصل على الكثير أيضًا ، لكن يبدو أنه يزيل الحاوية بمعنى ما (حيث يمكنني بدء حاوية جديدة بنفس الاسم)

هل هناك حل لهذه المشكلة؟

أبحث عن حل أيضا.

يبدو أنه يتم إيقاف جميع الحاويات قبل أن يقوم برنامج عامل الإرساء بإصلاح المشكلة.

لقد أضفت كتلة pre-stop إلى وظيفتي المبتدئة كحل بديل:

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

إليك خلاصة خطوات التصحيح الخاصة بي: https://gist.github.com/rochacon/4dfa7bd4de3c5f933f0d

rochacon شكرا على الحل الخاص بك. سأختبرها اليوم أو غدًا مع 1.2 (يبدو أنك اختبرت مع 1.1.1 ، أليس كذلك؟). نأمل أن يعمل.

vieira لقد حاولت أيضًا باستخدام 1.2.0 ، نفس النتائج.

بعد 4 أسابيع من التشغيل ، توقفت إحدى الحاويات الخاصة بي ... لست متأكدًا من السبب ... كيف يمكنني العثور على السبب الرئيسي؟

على أي حال ، كان لدي نفس المشكلة ... لقد تم حلها بالاقتراح من aroragan : umount ، بالمناسبة ، أنا على RHEL 6.5 ...

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

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

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

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

نشهد هذا في 1.3.0 الآن ، على نظام EC2 Ubuntu الذي تمت ترقيته من 12.04 إلى 14.04. مثيل dev الخاص بي هو تثبيت مباشر 14.04 في Vagrant ولا توجد به هذه المشكلة. يبدو أن إلغاء تثبيت الحاويات ثم إعادة تشغيلها يعمل ، لكن هذا يلغي الغرض من تكوينها لإعادة التشغيل تلقائيًا عند إعادة تشغيل المثيل أو عند إعادة تشغيل عامل الإرساء. اسمحوا لي أن أعرف ما إذا كان هناك أي معلومات أخرى يمكنني تقديمها حول إصدارات الحزم الداعمة ، وما إلى ذلك ، حيث يتوفر لدي نظام يعمل وغير عامل.

رؤية نفس المشكلة مع docker 1.3 Ubuntu 14.04 مع Linux kernel 3.13 أو 3.14.

srobertson هل تشير إلى "عدم إعادة تشغيل الحاويات عند إعادة تشغيل البرنامج الخفي"؟ هل تستخدم سياسة إعادة تشغيل _per-container_ الجديدة؟ لأنه تمت إزالة -r / --restart=true على مستوى البرنامج الخفي في Docker 1.2

تم وصف سياسة إعادة التشغيل الجديدة (لكل حاوية) في مرجع CLI

+1 ، حصلت على هذه المشكلة على docker 1.3 @ ArchLinux x86_64 مع 3.17.2-1-ARCH kernel.

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

Umount يحل المشكلة.

umount هو حل بديل ، لن أقول أنه يحل المشكلة. ببساطة إعادة تشغيل البرنامج الخفي مع تشغيل الحاويات سيعيد إظهار المشكلة.

umount بالنسبة لي أيضًا على إصدار عامل الإرساء التالي:

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

لقد أوقفت برنامج Docker daemon أولاً ثم:

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

@ mlehner616 نعم ، أنت على حق. آسف ، بالطبع هذا حل بديل وليس حلاً. كان هذا مجرد اختيار سيئ للكلمات.

أود أن أرى هذا ثابتًا أيضًا ، OFC. =)

لمعلوماتك ، لم يعمل unmounten بالنسبة لي. تلقيت خطأ مفاده أنه لا يوجد تحميل يمكن العثور عليه في / etc / mtab
إصدار Docker 1.0.0 ، الإصدار 63fe64c / 1.0.0 على RHEL 6.5

لقد عملت على حلها عن طريق إلغاء تثبيت أي حوامل قديمة تلقائيًا عند عودة برنامج عامل الإرساء. لم أرغب في تصحيح /etc/init/docker.conf الكبير لأوبونتو ، لذلك وضعت سطرًا صغيرًا في /etc/default/docker بدلاً من ذلك:

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

ويبدو أن تفعل خدعة. لقد دمجتها مع إدارة مغرورة في بدء تشغيل حاوياتي الفعلية وإعادة نشرها ، لذا الآن بعد service docker restart ، ستعود جميع الحاويات للتو.

شكرًا ياjypma ، هذه هي الحيلة بالنسبة لي أيضًا!

_review session_ مع unclejack

سنستخدم هذه المشكلة كمتتبع لمعظم تقارير "الجهاز أو المورد مشغول" أو تقارير EBUSY .

يتم تخفيف هذه المشكلة ، مثل المشكلات الأخرى ، من خلال التعامل بشكل صحيح مع مساحة اسم التحميل لبرنامج docker daemon. لا يوجد حاليًا معالجة افتراضية لمساحة اسم التحميل ، وبالتالي لدينا مشكلات مثل EBUSY.

بينما نعمل على الحل الرسمي للتعامل معها ، هناك حلول يمكنك تطبيقها بنفسك. انظر http://blog.hashbangbash.com/2014/11/docker-devicemapper-fix-for-device-or-resource-busy-ebusy/

تأكيدًا على أنني واجهت هذه المشكلة أيضًا باستخدام صورة الأسهم المجانية. لقد أوقفت خدمة عامل الإرساء وعندما حاولت إعادة تشغيلها على طول مع حاوية ipa ، حصلت على ما يلي.

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

أدى إلغاء تثبيت "الحامل" إلى حل المشكلة حتى أتمكن من إعادة تشغيل الحاوية.

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

$ docker start ipa
ipa

باستخدام ما يلي:

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

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

umount أصلح مشكلتي

عامل ميناء - الإصدار
إصدار Docker 1.3.2 ، بناء 39fa2fa

لذا فإن الحل البديل التالي هو حل دائم أكثر لحالة الاستخدام الخاصة بي.
أنا أستخدم Amazon linux (RedHat6-Like) بشكل صارم ، لذا قمت بإجراء تعديل طفيف على البرنامج النصي الخاص بـ init (والذي من المحتمل أن يتم استبداله إذا تم تحديث عامل الإرساء). ، إذا كان هناك أي منها فإنه يفصلهم. YMMV

_ / etc / init.d / docker_
إضافة متغير lib (السطر ~ 28)

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

إضافة كتلة umount لإيقاف الوظيفة (السطر 77 ~)

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

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

أواجه نفس المشكلة مع docker 1.4.1 باستخدام مخطط الجهاز كبرنامج تشغيل التخزين. لقد تمكنت من جمع أثر كومة الذعر من عامل التحميل عبر ملف السجل الخاص به.

بيئة

قطة $ / etc / * release
DISTRIB_ID = أوبونتو
DISTRIB_RELEASE = 14.04
DISTRIB_CODENAME = موثوق
DISTRIB_DESCRIPTION = "Ubuntu 14.04.1 LTS"
NAME = "أوبونتو"
الإصدار = "14.04.1 LTS ، طاهر موثوق به"
المعرف = ubuntu
ID_LIKE = ديبيان
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/ "

نسخة عامل ميناء دولار
sudo: غير قادر على حل المضيف ip-172-30-0-39
إصدار العميل: 1.4.1
إصدار واجهة برمجة تطبيقات العميل: 1.16.1
إصدار Go (العميل): go1.3.3
Git الالتزام (العميل): 5bc2ff8
OS / Arch (العميل): linux / amd64
إصدار الخادم: 1.4.1
إصدار Server API: 1.16.1
إصدار Go (الخادم): go1.3.3
Git الالتزام (الخادم): 5bc2ff8

$ tail -f / var / log / upstart / docker
...
INFO [143413] -job execResize (3dfcbc075227d5b3f0115bd73a1fea4a56a2c0fc68190d84b6d88e93938b4121، 37، 130)
2015/01/22 22:29:22 http: خدمة الذعر @: خطأ وقت التشغيل: عنوان ذاكرة غير صالح أو عدم إشارة مؤشر عدم
goroutine 1932 [قيد التشغيل]:
net / http.func · 011 ()
/usr/local/go/src/pkg/net/http/server.go:1100 + 0xb7
runtime.panic (0xbe5c40 ، 0x127da13)
/usr/local/go/src/pkg/runtime/panic.c:248 + 0x18d
github.com/docker/docker/daemon.(_execConfig).Resize(0xc20989c800، 0x25، 0x82، 0x0، 0x0)
/go/src/github.com/docker/docker/daemon/exec.go:65 + 0x66
github.com/docker/docker/daemon.(_Daemon).ContainerExecResize(0xc208044f20، 0xc20a836e00، 0x1)
/go/src/github.com/docker/docker/daemon/resize.go:49 + 0x314
github.com/docker/docker/daemon._Daemon.ContainerExecResize·fm(0xc20a836e00، 0x7f49bcd007d8)
/go/src/github.com/docker/docker/daemon/daemon.go:132 + 0x30
github.com/docker/docker/engine.(_Job).Run(0xc20a836e00، 0x0، 0x0)
/go/src/github.com/docker/docker/engine/job.go:83 + 0x837
github.com/docker/docker/api/server.postContainerExecResize(0xc208114fd0 ، 0xc20a55db27 ، 0x4 ، 0x7f49bcd08c58 ، 0xc209498320 ، 0xc209e
621a0، 0xc20a69c0c0، 0x0، 0x0)
/go/src/github.com/docker/docker/api/server/server.go:1170 + 0x2d1
github.com/docker/docker/api/server.func·002(0x7f49bcd08c58، 0xc209498320، 0xc209e621a0)
/go/src/github.com/docker/docker/api/server/server.go:1219 + 0x810
net / http.HandlerFunc.ServeHTTP (0xc2081b8280 ، 0x7f49bcd08c58 ، 0xc209498320 ، 0xc209e621a0)
/usr/local/go/src/pkg/net/http/server.go:1235 + 0x40
github.com/gorilla/mux.(_Router).ServeHTTP(0xc2080a3cc0، 0x7f49bcd08c58، 0xc209498320، 0xc209e621a0)
/go/src/github.com/docker/docker/vendor/src/github.com/gorilla/mux/mux.go:98 + 0x297
net / http.serverHandler.ServeHTTP (0xc208180480 ، 0x7f49bcd08c58 ، 0xc209498320 ، 0xc209e621a0)
/usr/local/go/src/pkg/net/http/server.go:1673 + 0x19f
net / http. (_ conn) .serve (0xc20a836300)
/usr/local/go/src/pkg/net/http/server.go:1174 + 0xa7e
تم إنشاؤها بواسطة net / http. (* Server) .Serv
/usr/local/go/src/pkg/net/http/server.go:1721 + 0x313

...

INFO [0056] حذف /v1.16/containers/hoopla_docker_registry
INFO [0056] + job rm (hoopla_docker_registry)
لا يمكن تدمير الحاوية hoopla_docker_registry: فشل برنامج تشغيل devicemapper في إزالة نظام ملفات الجذر 6abcbfefe8bdd485dfb192f8926
3add895cda1ae28b578d4a0d9b23574dedc5c: الجهاز مشغول
INFO [0066] -job rm (hoopla_docker_registry) = ERR (1)
ERRO [0066] معالج لـ DELETE / حاويات / { name :. *} تم إرجاع الخطأ: لا يمكن إتلاف الحاوية hoopla_docker_registry: Drive
فشل r devicemapper في إزالة نظام ملفات الجذر 6abcbfefe8bdd485dfb192f89263add895cda1ae28b578d4a0d9b23574dedc5c: الجهاز مشغول

ERRO [0066] خطأ HTTP: statusCode = 500 لا يمكن تدمير الحاوية hoopla_docker_registry: فشل برنامج التشغيل devicemapper في إزالة نظام ملفات الجذر 6abcbfefe8bdd485dfb192f89263add895cda1ae28b578d4a0d9b23574dedc5c: الجهاز مشغول

كنت أرى هذا في ubuntu 14.04 (على ec2) مع 1.4.1 وأيضًا لا مع 1.5. إنه أمر غريب ، لأن عامل الإرساء يبدو موثوقًا للغاية على نظام Linux Mint 17 ولكنه غير موثوق به للغاية على خادم الإنشاء الخاص بنا مع ubuntu 14.04.

هل هناك طريقة لعدم استخدام devicemapper ، حيث يبدو أن هذه المشكلة موجودة منذ 0.9 يوم؟

يمكن أن يحدث هذا مع التراكبات أيضًا.

حسنًا ، لقد غيرت للتو إلى aufs ولا توجد مشاكل حتى الآن.

ما هي حالة هذه القضية؟ لقد رأيت بعض العلاقات العامة يتم دمجها والتي يمكن أن تكون ذات صلة ولكن لا يوجد شيء مذكور بوضوح كان إصلاحًا لذلك. هذه مشكلة كبيرة تتعلق بالإنتاج والحل الوحيد الآن هو تصحيح البرنامج النصي الخاص بـ init لإلغاء تحميل محركات الأقراص بشكل سليم.

بعد مراجعة هذا مرة أخرى ، هذا ليس مثالًا مثاليًا على EBUSY الذي قلناه في الأصل.
هذه الحالة لها علاقة أكبر بأوعية حاوية لا تتعامل مع الإشارات بأمان.

نظرًا لأن حالة الاستنساخ هنا tail -f /dev/null لا تخرج عند SIGQUIT عند خروج البرنامج الخفي ، فإن برنامج تشغيل devmapper لا يمكنه التفكيك بشكل صحيح (هذا ليس حصريًا لمطور البرامج). قبل بدء تشغيل البرنامج الخفي مرة أخرى ، يمكنك رؤية tail -f /dev/null لا يزال قيد التشغيل ، حتى عندما لا يتم تشغيل عامل الإرساء.

وثمة مسألة مثل هذه تتطلب الأفكار حول كيفية بشكل كبير لعلاج PIDS في الحاوية على عامل ميناء إنهاء ...unclejackcrosbymichael الأفكار؟

تم اختبار هذا على Fedora 21 x86_64. تقديم معلومات لأغراض المقارنة فقط لأن المشكلة لا يبدو أنها موجودة (بعد الآن؟). نفس النتائج باستخدام centos: 7 أو ubuntu: صور

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

$ systemctl stop docker

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

$ systemctl start docker

$ docker ps -q

$ docker ps -a -q
ec496f1a6738

$ docker start ec496f1a6738
ec496f1a6738

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

$ docker stop ec496f1a6738
ec496f1a6738

$ docker rm ec496f1a6738
ec496f1a6738

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

معلومات النظام:

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

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

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

فقط واجه هذا الأمر على Docker 1.5 ، 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

تشغيل umount /var/lib/docker/devicemapper/mnt/f3a7515112a0b5af94b0520844ef8c586763d2051b41b1db90e4c4efbd07e774 ساعد على الرغم من ذلك.

لدي نفس المشكلة على Docker 1.5.0 ، Centos7.0 ،

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

فشل umount.

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

بيئة

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

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

أنا أعيد إنتاجه بواسطة docker 1.3.2 من مستودع 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

حصل عامل ميناء 1.5.0 على نفس الخطأ
Error response from daemon: Cannot destroy container 485bf8d6502a: Driver devicemapper failed to remove root filesystem 485bf8d6502a6cf448075d20c529eb24f09a41946a5dd1c61a99e17

نفس المشكلة هنا ، سهلة التكاثر

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

On another shell:

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

بيئة

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

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

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

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

تحرير: الحل الوحيد بالنسبة لي (أنا لا أستخدم system.d) هو تحديث /etc/init.d/docker ، السطر 50 باستخدام أمر إلغاء المشاركة. تم توفير الإصلاح بواسطة vbatts ، شكرًا راجع للشغل
ومع ذلك ، فإن هذا الإصلاح غير قابل للتطوير. لا نريد تحديث كل جهاز نملكه + سيتم مسحه في المرة القادمة التي نقوم فيها بتحديث عامل الإرساء.

1. ما هي خياراتي الأخرى؟
2. هل هناك جانب عامل إصلاح يخرج؟
3. هل يؤثر على كل أنظمة التشغيل؟
4. هل يؤثر على جميع النوى؟

شكر

أعتقد أن https://github.com/docker/docker/pull/12400 سيصلح هذا. هذا لأن إيقاف تشغيل برنامج Docker daemon سيترك الحاويات قيد التشغيل غير نظيفة (إذا لم يتم قتل الحاويات في غضون 10 ثوانٍ ، فسيظل جذر الحاوية مثبتًا) ولن يمكن إزالته عند البدء الخفي التالي. (أختبر على التراكب)

شكرا @ coolljt0725 .

1) ما هو إصدار عامل الإرساء الذي سيتم تنفيذه؟
2) ما هي خياراتي الأخرى؟
3) هل يؤثر على جميع أنظمة التشغيل؟
4) هل يؤثر على جميع الألباب؟

شكر

+1 لحل المشكلة. حدث لي مع Docker 1.6.0 ، بناء 4749651.
إعادة تشغيل عامل ميناء الخدمة لم يحلها. umount "الحجم" المضطرب إصلاحه.

لا يزال Docker 1.6.1 (Ubuntu 14.04) يواجه هذه المشكلة. umount يعمل.

Docker 1.6.2 (Ubuntu 14.04) umount لا يعمل

لا يزال Docker 1.7.0 Centos 6.5 لديه نفس المشكلات.

لقد حصلت للتو على هذا على Centos 6.3 بعد الترقية إلى Docker 1.7. أعادت الترقية إعادة تشغيل عامل الإرساء (من الواضح) ، وعندما ذهبت لإعادة تشغيل الحاويات ، تمت إعادة تشغيل جميع حاويات node.js الخاصة بي ، ولكن تلك التي تقوم بتشغيل uwsgi أعطت الخطأ:

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

إجراء umount /local/docker/devicemapper/mnt/48596c91d263e44201f9141e7bc701ab9e11fe691c61eadc95019fcfa0e4a549 لم يحل المشكلة.

نفس الشيء على ديبيان. لا يمكن بدء تشغيل أي حاوية ، حتى عند سحب صورة جديدة تمامًا لعالم مرحبًا.

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

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

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

tnolet يرجى تقديم docker info .

unclejack docker info لمضيفي هو

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

tdterry RHEL 6 و CentOS 6 غير مدعومين من قبل Red Hat للاستخدام مع Docker بعد الآن. يرجى الترقية إلى RHEL 7 أو CentOS 7.

يدعم Docker رسميًا Centos 6.5 (https://docs.docker.com/installation/centos/). بالإضافة إلى ذلك ، قمنا بتحديث kernel إلى 3.10. أبلغ أشخاص آخرون هنا عن وجود الخطأ في CentOS 7 أيضًا. يبدو وكأنه مشكلة في تطبيق Devicemapper أكثر من كونه مشكلة في إصدار CentOS. ليس لدي سبب للاعتقاد بأن الترقية إلى CentOS 7 ستؤدي إلى أي شيء مختلف.

لقد حصلت للتو على هذا في CentOS 7 ، إصدار Docker 1.6.0 ، بناء 4749651 مع devicemapper. تحطمت جميع حاوياتي الـ 15. أحاول إزالة بعض الصور المتدلية وأحصل على نفس الخطأ:

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

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

amalagaura مع إيقاف البرنامج الخفي ، قد يؤدي تشغيل mount | grep docker إلى ظهور دليلين مثبتين (مثل /dev/mapper/docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0 on ... ). يمكنك umount هذه أولاً ، ثم ابدأ البرنامج الخفي مرة أخرى. إذا كانت المشكلة لا تزال قائمة ، dmsetup ls | grep docker وشاهد إدخالات مثل docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0 (253:5) . من الذي يمكنك الاتصال بـ dmsetup remove docker-253:2-7995406-6296eddc5eaca30246c02d9b9c956161825bd7e92882a357214e091feba6f9b0

vbatts شكرا لك على المساعدة. مشكلتنا الحقيقية هي أن مجموعة إنتاجنا المكونة من 15 آلة قد ماتت للتو. هذه مناقشة مختلفة ، ولكن ما الذي يجب فعله إذا أردنا دعمًا على عامل الميناء؟

لدي مشكلة مماثلة بعد أن قمت بالترقية إلى 1.7 ، كانت تعمل بشكل جيد في 1.6.2 على elementaryOS.

كلما بدأت تشغيل أي حاوية ، أحصل على الرسالة

استجابة الخطأ من البرنامج الخفي: لا يمكن بدء الحاوية 560640442c770dff574f5af7b6cdcc8e86ba8a613db87bf90a77aea7f0db322a: الجهاز أو المورد مشغول

لقد قمت بإزالة عامل الإرساء ، rm -rf / var / lib / docker ، ومع التثبيت الجديد ، لا يزال هناك نفس الخطأ عند تشغيل صورة hello-world.

لقد لاحظت أيضًا أن المجلدات تتراكم في / var / docker / lib / aufs / mnt بعد كل محاولة فاشلة.

أنا أضرب هذا كثيرًا ، وأنا أستخدم aufs ، وليس 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

يُرجى إعلامي إذا كان هناك المزيد من معلومات تصحيح الأخطاء التي يمكنني تقديمها.

رؤية نفس المشكلة. umount لا يعمل ، تقول أن المجلد لم يتم تحميله. لقد لاحظت ذلك باستخدام عامل الإرساء 1.5.0 ، ثم قمت بالتحديث إلى 1.7.1 بنفس التأثير.

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

نفس الشيء على 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

أنا على وشك تشغيل تطبيق وما إذا كان قد تم حل هذه المشكلة ، لا يمكنني استخدام عامل الإرساء في الإنتاج لأنني واجهت بالفعل بعض الحاوية تحطمت ولم أتمكن من إزالتها بدون إعادة تشغيل النظام ، وهو ما يمثل ألمًا في نظام الإنتاج.

trompx devicemapper مع تعطيل مزامنة udev لن يعمل.
إنه جزء من السبب في أننا نقدم الآن ثنائيات ديناميكية (تعمل على إصلاح مشكلة المزامنة) بدلاً من ثنائي ثابت.
أوصي باستبدال repos الخاص بك من get.docker.com (وحزمة lxc-docker) بـ apt.dockerproject.org repo (وحزمة docker-engine).
راجع http://blog.docker.com/2015/07/new-apt-and-yum-repos/ لمزيد من التفاصيل.

هناك أيضًا حالة حاوية (ish) جديدة تسمى "ميتة" ، والتي يتم تعيينها عند وجود مشكلات في إزالة الحاوية. هذا بالطبع حل بديل لهذه المشكلة بالذات ، والذي يتيح لك الانتقال والتحقيق في سبب وجود الخطأ device or resource busy (ربما يكون حالة سباق) ، وفي هذه الحالة يمكنك محاولة الإزالة مرة أخرى ، أو محاولة يدويًا الإصلاح (على سبيل المثال ، قم بإلغاء تثبيت أي حوامل متبقية ، ثم قم بإزالتها).

ربما يمكن لسائقي الرسوم أن يكونوا أكثر مرونة قليلاً في الحالات التي يكون لدينا فيها نوع من العرق مع fs (على سبيل المثال ، اجعله يحاول إلغاء التحميل مرة أخرى).

@ cpuguy83 شكرا لك على المعلومات. أنا الآن أستخدم الإصدار الأخير مع udev true ولكن أثناء محاولتي إعداد نظام مراقبة التسجيل ، حدثت مشكلة نتج عنها جميع حاوياتي بالحالة "Exited (137)" ثم "dead" ومحاولة إزالتها تمنعني من إزالتها "استجابة خطأ من البرنامج الخفي: لا يمكن إتلاف الحاوية 9ca0b5642a55: فشل برنامج تشغيل devicemapper في إزالة نظام ملفات الجذر". لذلك لا يزال لدي هذه المشكلة.

لم أتمكن من رؤية ما حدث لأنني أستخدم برنامج تشغيل سجل النظام (لمحاولة إعداد نظام التسجيل الخاص بي) لذلك لا أعرف حقًا ما حدث. سأخبرك إذا قمت بفرز ذلك.

trompx إذا كانت هذه معلقة من التثبيت السابق ، فقد يتسبب ذلك في مشكلة.
بمجرد أن تكون الحاويات في حالة "ميتة" ، يمكنك docker rm -f مرة أخرى لإزالتها من عامل الإرساء ويجب ألا تظهر مرة أخرى. من المحتمل أن تكون الملفات مفقودة بحيث يتعذر على devicemapper العثور عليها حقًا.

تمكنت من جعله يتعطل مرة أخرى ولكن مع ذلك الوقت سجل السائق json. بعد التحقق من سجلات جميع الحاويات ، فقط haproxy يُرجع بعض المدخلات المفيدة "/run.sh: fork: لا يمكن تخصيص الذاكرة". لقد كنت تعاني من نقص في الذاكرة قليلاً بدون مبادلة ، ولا بد أن ذاكرتي قد نفدت. إذا كان هذا هو السبب ، فهل هذا يعني أن Docker سيتعطل عند نفاد الذاكرة ، وبالتالي الخروج من جميع الحاويات؟

trompx بالتأكيد لا شيء يمنع Docker من قتل OOM.
لا تخرج الحاويات في حالة تعطل عامل الإرساء ، ولكن عندما يبدأ عامل التحميل احتياطيًا ، فإنه يقتل جميع الحاويات قيد التشغيل (ويبدأ الحاويات التي لديها سياسة إعادة التشغيل).

أرى هذا بشكل منتظم تمامًا عند استخدام docker-compose 1.4.2 و docker-engine 1.8.3 على Ubuntu 14.04.

إصدار نواة superdump @ ؟

gionn : 3.13.0-65 ​​عام

@ superdumpgionn نفس إصدارات البرنامج ، kernel 3.13.0-67-generic

على AWS باستخدام محركات أقراص الحالة الصلبة EBS

هل حاول أي شخص استخدام Docker 1.9 لمعرفة ما إذا كان قد تم إصلاحه؟ كان هناك بعض الأعمال المتعلقة بوحدات التخزين ...

تعد الأحجام (بمعنى توسيع البيانات خارج دورة حياة الحاوية) ميزة مختلفة عما يتأثر هنا ، أليس كذلك؟

إذا كانت أدوات إلغاء المشاركة حلاً عمليًا لهذه المشكلات ، فلا يمكن أن يقوم عامل التحميل بذلك افتراضيًا عند بدء البرنامج الخفي ..؟
يجب أن يكون هذا بسيطًا بما يكفي للتنفيذ ..

من السهل القيام به وهناك طرق مختلفة لإنجاز هذه المهمة. ال
لم يرغب المشرفون في قبول طلبات السحب التي قامت بذلك بسبب ذلك
كان "اختراق".
يوم الجمعة ، 27 نوفمبر 2015 ، الساعة 6:49 صباحًا Andreas Stenius [email protected]
كتب:

إذا كانت حوامل إلغاء المشاركة حلاً عمليًا لهذه المشكلات ، فلا يمكن لـ docker القيام بذلك
ذلك بشكل افتراضي عندما يبدأ البرنامج الخفي ..؟
يجب أن يكون هذا بسيطًا بما يكفي للتنفيذ ..

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/docker/docker/issues/5684#issuecomment -160153438.

هذا ليس صحيحا. لقد حصلنا على هذا وتسبب في حدوث مشكلات لذا قمنا بإعادته. إنه أمر تافه بالنسبة لك أن تفعل ذلك إذا لم يسبب لك أي مشاكل.

شكرا للمعلومة. لقد أضفنا "الاختراق" غير المشترك إلى عقدتين ،
نرى كيف ستسير الامور...
فري 27 نوفمبر 2015 kl. 19:01 سكريف براين جوف [email protected] :

هذا ليس صحيحا. لقد حصلنا على هذا وتسبب في حدوث مشكلات لذا قمنا بإعادته.
إنه أمر تافه بالنسبة لك أن تفعل ذلك إذا لم يسبب لك أي مشاكل.

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/docker/docker/issues/5684#issuecomment -160182860.

مرحبا،

أحصل على المشكلة التي تمت مناقشتها أعلاه عند استخدام Docker.

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

معلومات My Docker Version هي كما يلي:
عميل:
الإصدار: 1.10.2
إصدار API: 1.22
إصدار Go: go1.5.3
Git الالتزام: c3959b1
تاريخ البناء: الاثنين 22 فبراير 21:37:01 2016
OS / Arch: لينكس / amd64

الخادم:
الإصدار: 1.10.2
إصدار API: 1.22
إصدار Go: go1.5.3
Git الالتزام: c3959b1
تاريخ البناء: الاثنين 22 فبراير 21:37:01 2016
OS / Arch: لينكس / amd64

تجدر الإشارة إلى أنني صادفت هذه المشكلة مؤخرًا. لقد عملت مع Docker منذ ما يقرب من عام.

مرحبا،
أردت فقط أن أذكر أنه بعد إعادة تشغيل جهاز الكمبيوتر ، وجدت أن الحاويات التي لم تتم إزالتها من قبل قد تمت إزالتها. هذا يحل المشكلة المطروحة ولكن سيكون مزعجًا أن تتراكم الحاويات وتضطر دائمًا إلى إعادة تشغيل نظام التشغيل.

chirangaalwis +1. هل لاحظت أن هذا يحدث بعد تشغيل الحاوية لبعض الوقت أم أنه يحدث مباشرة بعد بدء الحاوية؟

مرحبا،
حسنًا ، بقدر ما أتذكر ، لقد اختبرت هذا بعد وقت طويل منذ بدء الحاويات. ليس بعد وقت طويل على وجه الدقة.

بالمناسبة ، سيكون من الجيد أن يقدم شخص ما شرحًا شاملاً للسبب وراء هذه المشكلة. أنا جديد نسبيًا على مفهوم النقل بالحاويات.

chirangaalwis هل قمت بفحص هذه المشكلة: https://github.com/docker/docker/issues/17902 يبدو أنه قد يكون خاصًا بإصدار kernel. سأقوم بترقية kernel على الجهاز حيث كانت تواجه المشكلة في اليوم التالي أو نحو ذلك ومعرفة ما إذا كان ذلك يحلها.

+1. نعم يبدو كذلك ، حتى إصدار kernel الخاص بي هو 3.13. نعم ، سأتحقق أيضًا من هذا ، الخرائط مع ما أبلغت عنه.

chirangaalwis @ kabobbob ... أنا على RHEL 7.2 و 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

أثناء إيقاف الحاويات وبدء تشغيلها باستخدام docker-compose ، أتلقى هذا الخطأ باستمرار ...

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

الحل الوحيد هو التوقف والانتظار لبضع ثوانٍ قبل المحاولة مرة أخرى. المشكلة هي أن إعادة التشغيل ليست مضمونة للعمل. أحاول أحيانًا إعادة التشغيل عدة مرات.

marcellodesaleschirangaalwis كنت قادرا على ترقية الخادم إلى النواة 3.16 وحاولت توقف الحاويات وجمهورية مقدونيا. يبدو أن كل شيء يعمل بشكل جيد. سوف تحتاج إلى العمل ومعرفة ما إذا كان قد تم حل المشكلة.

kabobbob ، يرجى الإبلاغ في غضون يومين إذا ثبت أن ذلك يعمل بشكل أفضل ... سأحاول ترقية بيئات الإنتاج المسبق والتقرير.

كان هذا في rhel 7.2 - تحديث yum && إعادة تشغيل systemctl إصلاحه.

تم استخدام إصدار LVM و Docker المباشر 1.9.1

أنا أيضا لدي هذه المشكلة. الإعداد الخاص بي: Ubuntu 14.04 ، تم تحديثه إلى kernel "3.19.0-58-generic # 64 ~ 14.04.1-Ubuntu". إصدار Docker 1.11.0 ، بناء 4dc5990. "إصدار docker-compose 1.7.0، build 0d7bf73".

عندما يقوم docker-compose up -d بإعادة تشغيل حاوية بسبب صورة جديدة ، فعادةً ما ينتهي الأمر بعدم القدرة على إزالة الحاوية المتوقفة.

فقط إعادة التشغيل ستساعد على أن تكون قادرًا على بدء الحاوية. إذاً فالمشكلة ليست قابلة للتكرار بنسبة 100٪ ولكنها تظهر في كثير من الأحيان. لذلك أجد نفسي مضطرًا لإعادة تشغيل الجهاز المضيف بشكل متكرر :-(

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

و

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

dsteinkopf هل واجهت هذا بعد الترقية من 1.10 إلى 1.11؟ أي سبب لاستخدام devicemapper على Ubuntu؟ بشكل عام ، يجب أن تمنحك (aufs) الافتراضية أداءً أفضل. في kernel 3.19 ، قد يكون التراكب خيارًا أفضل

لا ، المشكلة موجودة بالفعل باستخدام docker 1.10 ومع ubuntu 14.04-kernel الافتراضي (~ 3.10 على ما أعتقد) وباستخدام aufs. ثم قمت بترقية (خطوة بخطوة) برنامج تشغيل التخزين والنواة و docker. لا يوجد تغيير كبير في المشكلة من ذوي الخبرة ...

هل تعتقد أن الأمر يستحق تجربة التراكب بخصوص هذه المشكلة؟ (الأداء ليس مشكلة كبيرة في حالتي.)

thaJeztah لم أر هذه المشكلة من قبل ومنذ أن

هل واجهت هذا بعد الترقية من 1.10 إلى 1.11

لدي هذه المشكلة :(

لا يزال هذا على
RHEL 7.2 نواة 3.10.0-327.el7.x86_64
إصدار Docker 1.9.1 ، الإصدار 78ee77d / 1.9.1
جهاز مخطط- libs-1.02.107-5.el7_2.1.x86_64

حصلت أيضًا على المشكلة:

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

نسخة عامل ميناء

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

معلومات عامل الميناء

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

هذا مزيج من القضايا المختلفة. أعتقد أننا بحاجة إلى إغلاق هذا. لا تعتبر أي من أحدث الحالات المبلغ عنها مثل OP.

guenhter أظن أن هذا مرتبط

guenhter للسجل # 21969

أيضًا ، من المرجح أن تكون العديد من مشكلات ما قبل 1.11 مع أخطاء النوع "الجهاز أو المورد مشغول" من قتل البرنامج الخفي (بشكل غير لائق) ثم بدء تشغيله احتياطيًا.
يؤدي هذا إلى إعادة تعيين عدد المرجع الداخلي في حوامل برنامج تشغيل التخزين إلى 0 ، بينما لا تزال الحوامل نفسها نشطة.
1.11 يعالج هذه الحالة.

الختام للأسباب المذكورة أعلاه.

آسف - لست متأكدًا مما إذا كنت أفهم ذلك. ماذا تقصد بعبارة "ليست أي حالة من أحدث الحالات المبلغ عنها مثل OP"؟
ماذا علي (والآخرين الذين يعانون من هذه المشكلة) أن أفعل؟ فتح حالة أخرى؟

dsteinkopf نعم ، بأكبر قدر ممكن من التفاصيل (إنشاء الملفات ، سجلات البرنامج ، وما إلى ذلك).

مرحبًا فقط للإشارة إلى المشكلة التي حددتها سابقًا ، لقد قمت بترقية إصدار kernel الخاص بي إلى 4.4.0-21-generic ومعلومات إصدار docker كما يلي:
عميل:
الإصدار: 1.11.0
إصدار API: 1.23
إصدار Go: go1.5.4
Git الالتزام: 4dc5990
تاريخ البناء: الأربعاء 13 أبريل 18:38:59 2016
OS / Arch: لينكس / amd64

الخادم:
الإصدار: 1.11.0
إصدار API: 1.23
إصدار Go: go1.5.4
Git الالتزام: 4dc5990
تاريخ البناء: الأربعاء 13 أبريل 18:38:59 2016
OS / Arch: لينكس / amd64

يبدو أن المشكلة التي تم الإبلاغ عنها مسبقًا قد توقفت عن الحدوث. استخدم Docker لفترة طويلة من خلال ترقية إصدارات kernel ويبدو أنه قد توقف.

تم العثور على حل للمشكلة ، على الأقل عند استخدامه مع إنشاء عامل ميناء ، راجع https://github.com/docker/docker/issues/3786#issuecomment -221601065

نفس المشكلة مع الحاوية التي فشلت في إعادة التشغيل.

أوبونتو 14.04.2018
النواة: 3.13.0-24 عام
إصدار عامل ميناء:

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

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

خطأ:

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

فشل تحميل:

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

لا تزال هذه مشكلة بالنسبة لنا (باستخدام 1.11.2 على Ubuntu 14.04.4 LTS (مع KVM) (3.13.0-88 عام)).

هل هناك أي تذكرة مفتوحة يمكنني الاشتراك بها للحصول على التحديثات؟

GameScripting انظر #

Linux zk1 3.10.0-327.28.3.el7.x86_64 (سنتوس 7)
إصدار Docker 1.12.1 ، الإصدار 23cf638

استجابة الخطأ من البرنامج الخفي: فشل برنامج تشغيل devicemapper في إزالة نظام ملفات الجذر 228f2c2da3de4d5abd3881184aeb330a4c18e4311ecf404e2fb8cd4ffe15e901: فشل devicemapper: خطأ في تشغيل DeleteDevice dm_task_run

فقط ركض في هذا. /etc/init.d/docker restart ساعدني ، أنا سعيد لأن هذا لم يكن على آلة إنتاج ... 😢

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

لا يزال يحصل هذا أيضا

$ docker --version
Docker version 1.12.2, build bb80604

نفس المشكلة ، كانت تحدث على العديد من إصدارات Docker. أستخدم docker-compose لإعادة إنشاء الحاويات. أحيانًا يعمل بشكل نظيف ، وأحيانًا لا يعمل. إعادة تشغيل برنامج Docker daemon أو إعادة تشغيل الخادم ينظف الحاوية التالفة.

قوس لينكس حاويات devicemapper على 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

إذا كان يساعد ...

أعتقد أن لدي نفس / مشكلة مماثلة هنا أيضًا. في حالة نشر خدمة باستخدام إنشاء up -d ثم تحديث اسم الصورة إلى اسم مختلف في compose.yaml وإجراء عملية إنشاء أخرى - d ، يفشل الإنشاء مع وجود خطأ حول devicemapper:

خطأ
خطأ: لـ <> فشل برنامج تشغيل devicemapper في إزالة نظام ملفات الجذر 216c098e0f051407863934c27111bd1e9b7561dff1c4d67c0f0d45a99505fa70: الجهاز مشغول

معلومات الإصدار:
نسخة عامل ميناء
عميل:
الإصدار: 1.12.1
إصدار API: 1.24
إصدار Go: go1.6.3
Git الالتزام: 23cf638
مبني:
OS / Arch: لينكس / amd64

الخادم:
الإصدار: 1.12.1
إصدار API: 1.24
إصدار Go: go1.6.3
Git الالتزام: 23cf638
مبني:
OS / Arch: لينكس / amd64

كحل مؤقت ، لقد أضفت عامل إنشاء - rmi قبل إعادة تشغيله.

لدي أيضًا نفس المشكلة في إصدار Docker: 1.12.3

أنا متأكد تمامًا من أن بقية الأشخاص الذين يواجهون هذه المشكلة مرتبطون بـ # 27381

أرى هذا في Docker 1.12.3 على CentOs 7

dc2-elk-02: / root / staging / ls-helper $ docker --version
إصدار Docker 1.12.3 ، النسخة 6b644ec
dc2-elk-02: / root / staging / ls-helper $ uname -a
Linux dc2-elk-02 3.10.0-327.36.3.el7.x86_64 # 1 SMP Mon Oct 24 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux
dc2-elk-02: / root / staging / ls-helper $ docker rm ls-helper
استجابة الخطأ من البرنامج الخفي: فشل برنامج تشغيل devicemapper في إزالة نظام ملفات الجذر e1b9cdeb519d2f4bea53a552c8b76c1085650aa76c1fb90c8e22cac9c2e18830: الجهاز مشغول

ملاحظة: أنا لا أستخدم عامل إنشاء.

العض بعد خروج المضيف من مساحة القرص.
يتوقف أي أمر يؤثر على نقطة التحميل (بما في ذلك "docker ps" و "sync" و "ls"، ...)

واجهت مشكلة مماثلة ، ورأيت هذه الأخطاء في ملف / var / log / syslog الخاص بي:
Dec 16 14:32:18 rzing dockerd[3093]: time="2018-12-16T14:32:18.627417173+05:30" level=error msg="Failed to load container mount 00d7b9d64ff6c465276e67f5a5e3642ebacd9616c7602d4361b3a7fab038510a: mount does not exist" Dec 16 14:32:18 rzing dockerd[3093]: time="2018-12-16T14:32:18.627816711+05:30" level=error msg="Failed to load container mount fb108b942f8ed87a9e1affb6480ed477a8f5f823b2639e36348cde4a97924c5e: mount does not exist"
حاولت البحث عن نقطة التثبيت تحت /var/lib/docker/volumes لكن لم أجد أيًا منها
أخيرًا إعادة تشغيل النظام إصلاح المشكلة