هل تصادف أن يكون لديك اختبار صغير لإظهار ذلك؟ ربما يكون ملف Dockerfile صغيرًا لما هو موجود في الحاوية ونص باش يقوم بعمل بدء / إيقاف / ... الحاويات؟

الحاوية في dockerhub kinvey / blrunner # v0.3.8

استخدام API البعيد مع الخيارات التالية:

خلق
الصورة: 'kinvey / blrunner # v0.3.8'
AttachStdout: خطأ
AttachStderr: خطأ
ExposedPorts: {'7000 / tcp': {}}
Tty: خطأ
HostConfig:
PublishAllPorts: صحيح
CapDrop: [
"تشون"
"DAC_OVERRIDE"
"فاونر"
"قتل"
"مجموعة"
"SETPCAP"
"NET_BIND_SERVICE"
"NET_RAW"
"SYS_CHROOT"
"MKNOD"
"SETFCAP"
"AUDIT_WRITE"
]
LogConfig:
النوع: "بلا"
التكوين: {}

بداية

الحاوية

إزالة
القوة: صحيح

حسنًا ، هل ترى استخدامًا مفرطًا للموارد؟
حقيقة أن ssh لا تعمل حتى تجعلني أشك.
يمكن أن تكون مشكلة inode مع التراكب ، أو الكثير من FD's المفتوحة ، إلخ.

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

من المهم ملاحظة أنه لدينا 8 حاويات فقط تعمل في وقت واحد في أي حالة واحدة.

تم التقاط بعض الإحصائيات حيث لم يعد عامل الإرساء سريع الاستجابة:

lsof | مرحاض -l

يظهر 1025.

ومع ذلك ، يظهر خطأ عدة مرات:
lsof: تحذير: لا يمكن إحصاء () نظام ملفات التراكب / var / lib / docker / overlay / aba7820e8cb01e62f7ceb53b0d04bc1281295c38815185e9383ebc19c30325d0 / merged
قد تكون معلومات الإخراج غير كاملة.

إخراج عينة من الأعلى:

أعلى - 00:16:53 حتى 12:22 ، مستخدمان ، متوسط ​​التحميل: 2.01 ، 2.05 ، 2.05
المهام: 123 مجموع ، 1 جري ، 121 نائم ، 0 توقف ، 1 زومبي
٪ وحدة المعالجة المركزية (وحدات المعالجة المركزية): 0.3 us ، 0.0 sy ، 0.0 ni ، 99.7 id ، 0.0 w ، 0.0 hi ، 0.0 si ، 0.0 st
KiB Mem: إجمالي 3853940 ، 2592920 مستخدم ، 1261020 مجاني ، 172660 مخازن مؤقتة
KiB Swap: 0 إجمالي ، 0 مستخدم ، 0 مجاني. 1115644 ذاكرة مخبأة

24971 كينفي 20 0 992008 71892 10796 S 1.3 1.9 9: 11.93 عقدة
902 جذر 20 0 1365860 62800 12108 S 0.3 1.6 30: 06.10 عامل إرساء
29901 أوبونتو 20 0 27988 6720 2676 S 0.3 0.2 3: 58.17 tmux
1 جذر 20 0 33612 4152 2716 S 0.0 0.1 14: 22.00 init
2 جذر 20 0 0 0 0 S 0.0 0.0 0: 00.03 kthreadd
3 جذر 20 0 0 0 0 S 0.0 0.0 0: 04.40 ksoftirqd / 0
5 جذر 0 - 20 0 0 0 S 0.0 0.0 0: 00.00 kworker / 0: 0H
7 جذر 20 0 0 0 0 S 0.0 0.0 2: 21.81 rcu_sched
8 جذر 20 0 0 0 0 S 0.0 0.0 0: 01.91 rcu_bh

mjsalinger الإعداد الذي تستخدمه غير مدعوم. سبب عدم دعمه هو أنك تستخدم Ubuntu 14.04 مع نواة مخصصة.

من أين تأتي نواة 3.18.0-031800؟ هل لاحظت أن بناء النواة هذا عفا عليه الزمن؟ تم إنشاء النواة التي تستخدمها في ديسمبر من العام الماضي.

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

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

unclejack @ cpuguy83 @ LK4D4 يرجى إعادة فتح هذه المشكلة. كانت هذه نصيحة للتهيئة التي نستخدمها والتي قدمها على وجه التحديد فريق عامل التحميل والتجربة. لقد جربنا نواة أحدث (3.19 +) ولديهم خطأ ذعر في النواة من نوع ما كنا نواجهه - لذا كانت النصيحة هي استخدام 3.18 قبل ديسمبر نظرًا لوجود خطأ معروف في kernel تم تقديمه بعد ذلك والذي تسبب في حدوث ذعر Kernel الذي كنا نواجهه ، والذي على حد علمي ، لم يتم إصلاحه بعد.

فيما يتعلق بـ OverlayFS ، تم تقديم ذلك لي أيضًا باعتباره FS مثالي لـ Docker بعد مواجهة مشكلات عديدة في الأداء مع AUFS. إذا لم يكن هذا تكوينًا مدعومًا ، فهل يمكن لأي شخص مساعدتي في العثور على تكوين فعال ومستقر يعمل في حالة الاستخدام هذه؟ كنا ندفع من أجل استقرار هذا الوضع لعدة أشهر.

mjsalinger هل يمكنك توفير استخدام inode لوحدة التخزين التي يعمل التراكب عليها؟ (يجب أن يفعل df -i /var/lib/docker ).

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

df -i / ver / lib / docker

نظام الملفات Inodes IUsed IFree IUse٪ Mounted on
/ dev / xvda1 1638400 643893 994507 40٪ /

لا يزال التراكب به مجموعة من المشكلات: https://github.com/docker/docker/issues؟q=is٪3Aopen+is٪3Aissue+label٪3A٪2Fsystem٪2Foverlay

لن أستخدم التراكب في الإنتاج. علق آخرون على أداة تعقب هذه المشكلة بأنهم يستخدمون AUFS في الإنتاج وأنه كان مستقرًا بالنسبة لهم.

Kernel 3.18 غير مدعوم على Ubuntu 14.04. لا تقدم Canonical دعمًا لذلك.

AUFS في الإنتاج ليس أداءً على الإطلاق وكان أي شيء _ ولكنه _ مستقر بالنسبة لنا - كنت سأواجه بشكل روتيني اختناقات I / O ، والتجميد ، إلخ

نرى:

11228 ، # 12758 ، # 12962

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

أيضا:

http://developerblog.redhat.com/2014/09/30/overview-storage-scalability-docker/
http://qconlondon.com/system/files/presentation-slides/Docker٪20Clustering.pdf

يبدو أن Overlay يتم تقديمه على أنه المحرك المفضل من قبل المجتمع بشكل عام. حسنًا ، إذا لم يكن مستقرًا بعد ، ولكن أيضًا AUFS يجب أن يكون هناك _بعض_ طريقة للحصول على الأداء والاستقرار اللذين أحتاجهما مع Docker. أنا جميعًا لتجربة أشياء جديدة ، لكن في التكوين السابق (AUFS على Ubuntu 12.04 و AUFS على Ubuntu 14.04) لم نتمكن من الحصول على الاستقرار أو الأداء. على الأقل مع Overlay نحصل على أداء جيد واستقرار أفضل - لكننا نحتاج فقط إلى حل هذه المشكلة.

لقد واجهت أيضًا أعراضًا مشابهة لتلك التي يتم تشغيلها على مثيلات Ubuntu الافتراضية ضمن AUFS (12.04 و 14.04 و 15.04).

10355 # 13940

اختفت هاتان المشكلتان بعد التبديل إلى Kernel و OverlayFS الحاليين.

mjsalinger أوصي باستخدام Ubuntu 14.04 مع حزم kernel 3.13 الأحدث. أنا أستخدم ذلك بنفسي ولم أواجه أيًا من هذه المشكلات على الإطلاق.

unclejack حاولت ذلك

mjsalinger هل تستخدم مغرور لبدء عامل ميناء؟ كيف يبدو /etc/init/docker.conf؟

نعم ، باستخدام مغرور.

/etc/init/docker.conf

description "Docker daemon"

start on (local-filesystems and net-device-up IFACE!=lo)
stop on runlevel [!2345]
limit nofile 524288 1048576
limit nproc 524288 1048576

respawn

pre-start script
        # see also https://github.com/tianon/cgroupfs-mount/blob/master/cgroupfs-mount
        if grep -v '^#' /etc/fstab | grep -q cgroup \
                || [ ! -e /proc/cgroups ] \
                || [ ! -d /sys/fs/cgroup ]; then
                exit 0
        fi
        if ! mountpoint -q /sys/fs/cgroup; then
                mount -t tmpfs -o uid=0,gid=0,mode=0755 cgroup /sys/fs/cgroup
        fi
        (
                cd /sys/fs/cgroup
                for sys in $(awk '!/^#/ { if ($4 == 1) print $1 }' /proc/cgroups); do
                        mkdir -p $sys
                        if ! mountpoint -q $sys; then
                                if ! mount -n -t cgroup -o $sys cgroup $sys; then
                                        rmdir $sys || true
                                fi
                        fi
                done
        )
end script

script
        # modify these in /etc/default/$UPSTART_JOB (/etc/default/docker)
        DOCKER=/usr/bin/$UPSTART_JOB
        DOCKER_OPTS=
        if [ -f /etc/default/$UPSTART_JOB ]; then
                . /etc/default/$UPSTART_JOB
        fi
        exec "$DOCKER" -d $DOCKER_OPTS
end script

# Don't emit "started" event until docker.sock is ready.
# See https://github.com/docker/docker/issues/6647
post-start script
        DOCKER_OPTS=
        if [ -f /etc/default/$UPSTART_JOB ]; then
                . /etc/default/$UPSTART_JOB
        fi
        if ! printf "%s" "$DOCKER_OPTS" | grep -qE -e '-H|--host'; then
                while ! [ -e /var/run/docker.sock ]; do
                        initctl status $UPSTART_JOB | grep -qE "(stop|respawn)/" && exit 1
                        echo "Waiting for /var/run/docker.sock"
                        sleep 0.1
                done
                echo "/var/run/docker.sock is up"
        fi
end script

نرى الآن أيضًا ما يلي عند تشغيل أي أمر Docker في بعض الحالات ، على سبيل المثال ...

sudo docker ps

FATA [0000] احصل على http: ///var/run/docker.sock/v1.18/containers/json؟ all = 1: اطلب unix /var/run/docker.sock: المورد غير متاح مؤقتًا. هل تحاول الاتصال بـ TLS ممكن
الخفي بدون TLS؟

mjsalinger إنها مجرد رسالة خطأ

mjsalinger ماذا تقول سجلات /var/log/upstart/docker.log هو الموقع.

مجمد ، لم ترد إدخالات جديدة. فيما يلي آخر الإدخالات في السجل:

INFO[46655] -job log(create, 48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46655] -job create() = OK (0)
INFO[46655] POST /containers/48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a/start
INFO[46655] +job start(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a)
INFO[46655] +job allocate_interface(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a)
INFO[46655] -job allocate_interface(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a) = OK (0)
INFO[46655] +job allocate_port(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a)
INFO[46655] POST /containers/create?Image=kinvey%2Fblrunner%3Av0.3.8&AttachStdout=false&AttachStderr=false&ExposedPorts=&Tty=false&HostConfig=
INFO[46655] +job create()
INFO[46655] DELETE /containers/4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187?force=true
INFO[46655] +job rm(4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187)
INFO[46656] -job allocate_port(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a) = OK (0)
INFO[46656] +job log(start, 48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(start, 48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] +job log(create, 7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(create, 7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] -job create() = OK (0)
INFO[46656] +job log(die, 4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(die, 4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] +job release_interface(4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187)
INFO[46656] POST /containers/7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f/start
INFO[46656] +job start(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f)
INFO[46656] +job allocate_interface(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f)
INFO[46656] -job allocate_interface(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f) = OK (0)
INFO[46656] +job allocate_port(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f)
INFO[46656] -job release_interface(4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187) = OK (0)
INFO[46656] DELETE /containers/cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b?force=true
INFO[46656] +job rm(cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b)
INFO[46656] +job log(destroy, 4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(destroy, 4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] -job rm(4d447093f522f1d74f482b2f76c91adfd38b5ad264202b1c8262f05a0edaf187) = OK (0)
INFO[46656] +job log(die, cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(die, cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] +job release_interface(cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b)
INFO[46656] DELETE /containers/1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20?force=true
INFO[46656] +job rm(1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20)
INFO[46656] -job allocate_port(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f) = OK (0)
INFO[46656] +job log(start, 7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(start, 7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] -job start(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a) = OK (0)
INFO[46656] POST /containers/create?Image=kinvey%2Fblrunner%3Av0.3.8&AttachStdout=false&AttachStderr=false&ExposedPorts=&Tty=false&HostConfig=
INFO[46656] +job create()
INFO[46656] +job log(create, 1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(create, 1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] -job create() = OK (0)
INFO[46656] +job log(die, 1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(die, 1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] +job release_interface(1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20)
INFO[46656] GET /containers/48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a/json
INFO[46656] +job container_inspect(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a)
INFO[46656] -job container_inspect(48abb699bb6b8aefe042c010d06268d5e13515d616c5ca61f3a4930a325de26a) = OK (0)
INFO[46656] POST /containers/1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830/start
INFO[46656] +job start(1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830)
INFO[46656] +job allocate_interface(1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830)
INFO[46656] -job allocate_interface(1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830) = OK (0)
INFO[46656] +job allocate_port(1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830)
INFO[46656] -job release_interface(cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b) = OK (0)
INFO[46656] -job start(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f) = OK (0)
INFO[46656] GET /containers/7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f/json
INFO[46656] +job container_inspect(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f)
INFO[46656] -job release_interface(1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20) = OK (0)
INFO[46656] -job container_inspect(7ef9e347b762b4fb34a85508e5d259a609392decf9ffc8488730dbe8e731c84f) = OK (0)
INFO[46656] +job log(destroy, cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(destroy, cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] -job rm(cb03fc14e5eab2acf01d1d42dec2fc1990cccca69149de2dc97873f87474db9b) = OK (0)
INFO[46656] +job log(destroy, 1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(destroy, 1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20, kinvey/blrunner:v0.3.8) = OK (0)
INFO[46656] -job rm(1e8ddec281bd9b5bfe239d0e955874f83d51ffec95c499f88c158639f7445d20) = OK (0)
INFO[46656] DELETE /containers/4cfeb48701f194cfd40f71d7883d82906d54a538084fa7be6680345e4651aa60?force=true
INFO[46656] +job rm(4cfeb48701f194cfd40f71d7883d82906d54a538084fa7be6680345e4651aa60)
INFO[46656] -job allocate_port(1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830) = OK (0)
INFO[46656] +job log(start, 1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830, kinvey/blrunner:v0.3.8)
INFO[46656] -job log(start, 1ae5798d7aeec4857944b40a27f1a69789323bbe8edb8d67a250150241484830, kinvey/blrunner:v0.3.8) = OK (0)

@ cpuguy83 هل كان السجل مفيدًا على الإطلاق؟

mjsalinger يجعلني أعتقد أن هناك طريق مسدود في مكان ما لأنه لا يوجد شيء آخر يشير إلى مشكلة.

@ cpuguy83 سيكون ذلك منطقيًا بالنظر إلى الأعراض. هل هناك أي شيء يمكنني القيام به للمساعدة في تتبع هذه المشكلة بشكل أكبر ومن أين تأتي؟

ربما يمكننا الحصول على دعامة لنرى أنها في الواقع معلقة بقفل.

حسنا. سوف نعمل لمعرفة ما إذا كان بإمكاننا الحصول على ذلك. أردنا تجربة 1.7 أولاً - فعلنا ذلك لكننا لم نلاحظ أي تحسن.

@ cpuguy83 من أحد المضيفين المتأثرين:

root@<host>:~# strace -q -y -v -p 899
futex(0x134f1b8, FUTEX_WAIT, 0, NULL^C <detached ...>

@ cpuguy83 أية أفكار؟

رؤية ما يلي في 1.7 مع عدم قتل / بدء الحاويات. يبدو أن هذا تمهيد للمشكلة (لاحظ عدم ظهور هذه الأخطاء في 1.6 ولكنك لاحظت أن حجم الحاويات الميتة يبدأ في التراكم ، على الرغم من إصدار أمر بقتل / إزالة)

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container 09c12c9f72d461342447e822857566923d5532280f9ce25659d1ef3e54794484: Link not found

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container 5e29407bb3154d6f5778676905d112a44596a23fd4a1b047336c3efaca6ada18: Link not found

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container be22e8b24b70e24e5269b860055423236e4a2fca08969862c3ae3541c4ba4966: Link not found

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container c067d14b67be8fb81922b87b66c0025ae5ae1ebed3d35dcb4052155afc4cafb4: Link not found

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container 7f21c4fd8b6620eba81475351e8417b245f86b6014fd7125ba0e37c6684e3e42: Link not found

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container b31531492ab7e767158601c438031c8e9ef0b50b9e84b0b274d733ed4fbe03a0: Link not found

Error spawning container: Error: HTTP code is 500 which indicates error: server error - Cannot start container 477dc3c691a12f74ea3f07af0af732082094418f6825f7c3d320bda0495504a1: iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 32822 -j DNAT --to-destination 172.17.0.44:7000 ! -i docker0: iptables: No chain/target/match by that name.
 (exit status 1)

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container 6965eec076db173f4e3b9a05f06e1c87c02cfe849821bea4008ac7bd0f1e083a: Link not found

Error spawning container: Error: HTTP code is 404 which indicates error: no such container - Cannot start container 7c721dd2b8d31b51427762ac1d0fe86ffbb6e1d7462314fdac3afe1f46863ff1: Link not found

Error spawning container: Error: HTTP code is 500 which indicates error: server error - Cannot start container c908d059631e66883ee1a7302c16ad16df3298ebfec06bba95232d5f204c9c75: iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 32837 -j DNAT --to-destination 172.17.0.47:7000 ! -i docker0: iptables: No chain/target/match by that name.
 (exit status 1)

Error spawning container: Error: HTTP code is 500 which indicates error: server error - Cannot start container c3e11ffb82fe08b8a029ce0a94e678ad46e3d2f3d76bed7350544c6c48789369: iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 32847 -j DNAT --to-destination 172.17.0.48:7000 ! -i docker0: iptables: No chain/target/match by that name.
 (exit status 1)

ذيل docker.log من حادث حديث:

INFO[44089] DELETE /containers/4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25?force=true
INFO[44089] +job rm(4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25)
INFO[44089] DELETE /containers/a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96?force=true
INFO[44089] +job rm(a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96)
INFO[44089] +job log(die, 4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25, kinvey/blrunner:v0.3.8)
INFO[44089] -job log(die, 4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44089] +job release_interface(4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25)
INFO[44089] -job release_interface(4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25) = OK (0)
INFO[44089] +job log(die, a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96, kinvey/blrunner:v0.3.8)
INFO[44089] -job log(die, a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44089] +job release_interface(a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96)
INFO[44089] -job release_interface(a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96) = OK (0)
INFO[44092] +job log(destroy, 285274ee9c5b3bfa9fcea4d93b75e7e51949752b8d0eb101a31ea4f9aec5dad6, kinvey/blrunner:v0.3.8)
INFO[44092] -job log(destroy, 285274ee9c5b3bfa9fcea4d93b75e7e51949752b8d0eb101a31ea4f9aec5dad6, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44092] -job rm(285274ee9c5b3bfa9fcea4d93b75e7e51949752b8d0eb101a31ea4f9aec5dad6) = OK (0)
INFO[44092] POST /containers/create?Image=kinvey%2Fblrunner%3Av0.3.8&AttachStdout=false&AttachStderr=false&ExposedPorts=&Tty=false&HostConfig=
INFO[44092] +job create()
INFO[44097] +job log(destroy, 4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25, kinvey/blrunner:v0.3.8)
INFO[44097] -job log(destroy, 4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44097] -job rm(4e455d01da8453688dd27cad41fea158757311c0c89f27619a728f272591ef25) = OK (0)
INFO[44097] POST /containers/create?Image=kinvey%2Fblrunner%3Av0.3.8&AttachStdout=false&AttachStderr=false&ExposedPorts=&Tty=false&HostConfig=
INFO[44097] +job create()
INFO[44098] +job log(destroy, c80a39f060f200f1aff8ae52538779542437745e4184ed02793f8873adcb9cd4, kinvey/blrunner:v0.3.8)
INFO[44098] -job log(destroy, c80a39f060f200f1aff8ae52538779542437745e4184ed02793f8873adcb9cd4, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44098] -job rm(c80a39f060f200f1aff8ae52538779542437745e4184ed02793f8873adcb9cd4) = OK (0)
INFO[44098] POST /containers/create?Image=kinvey%2Fblrunner%3Av0.3.8&AttachStdout=false&AttachStderr=false&ExposedPorts=&Tty=false&HostConfig=
INFO[44098] +job create()
INFO[44098] +job log(create, 3b9a4635c068989ddb1983aa12460083e874d50fd42c743033ed3a08000eb7e9, kinvey/blrunner:v0.3.8)
INFO[44098] -job log(create, 3b9a4635c068989ddb1983aa12460083e874d50fd42c743033ed3a08000eb7e9, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44098] -job create() = OK (0)
INFO[44098] POST /containers/3b9a4635c068989ddb1983aa12460083e874d50fd42c743033ed3a08000eb7e9/start
INFO[44098] +job start(3b9a4635c068989ddb1983aa12460083e874d50fd42c743033ed3a08000eb7e9)
INFO[44102] +job log(destroy, a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96, kinvey/blrunner:v0.3.8)
INFO[44102] -job log(destroy, a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96, kinvey/blrunner:v0.3.8) = OK (0)
INFO[44102] -job rm(a608bc1014317b083ac2f32a4c6c85dda65445420775e21d6406ca9146723c96) = OK (0)
INFO[44102] POST /containers/create?Image=kinvey%2Fblrunner%3Av0.3.8&AttachStdout=false&AttachStderr=false&ExposedPorts=&Tty=false&HostConfig=
INFO[44102] +job create()

@ cpuguy83 @ LK4D4 أي أفكار / تحديثات؟

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

PID USER PR NI VIRT RES SHR S٪ CPU٪ MEM TIME + COMMAND
الجذر 20 0 1314832 89688 11568 S 0.3 2.3 65: 47.56 عامل إرساء

هذا ما يبدو أن عملية Docker تستخدمه ؛ لا يشبه كثيرا تسرب الذاكرة بالنسبة لي ...

سأعلق على ذلك ليقول "نحن أيضا". نحن نستخدم Docker للبنية التحتية للاختبار الخاصة بنا ، وقد تأثرنا بذلك في نفس الظروف / السيناريوهات. سيؤثر هذا على قدرتنا على استخدام Docker بطريقة هادفة إذا تم قفلها تحت الحمل.

يسعدني المساهمة بنتائج تحري الخلل وإصلاحه إذا كنت ستوجهني إلى ما تحتاجه كمعلومات.

لقد واجهت نفس المشكلة على مضيف CentOS7.

$ docker version
Client version: 1.6.2
Client API version: 1.18
Go version (client): go1.4.2
Git commit (client): ba1f6c3/1.6.2
OS/Arch (client): linux/amd64
Server version: 1.6.2
Server API version: 1.18
Go version (server): go1.4.2
Git commit (server): ba1f6c3/1.6.2
OS/Arch (server): linux/amd64

$ docker info
Containers: 7
Images: 672
Storage Driver: devicemapper
 Pool Name: docker-253:2-67171716-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file: /dev/mapper/vg01-docker--data
 Metadata file: /dev/mapper/vg01-docker--metadata
 Data Space Used: 54.16 GB
 Data Space Total: 59.06 GB
 Data Space Available: 4.894 GB
 Metadata Space Used: 53.88 MB
 Metadata Space Total: 5.369 GB
 Metadata Space Available: 5.315 GB
 Udev Sync Supported: true
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.0-229.7.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 8
Total Memory: 31.25 GiB

حدث هذا في نظامنا CI. لقد غيرت عدد الوظائف المتوازية ثم بدأت 4 وظائف بالتوازي. لذلك كان هناك 4-6 حاويات قيد التشغيل. كان الحمل حوالي 10 (مع بقاء بعض النوى الثمانية في وضع الخمول).

بينما كانت جميع الحاويات تعمل بشكل جيد ، كان عامل الرصيف نفسه عالقًا. سيظل docker images يعرض الصور ، لكن جميع أوامر deamon مثل docker ps أو docker info توقفت.

كانت دعوتي مماثلة لتلك المذكورة أعلاه:

strace -p 1194
Process 1194 attached
futex(0x11d2838, FUTEX_WAIT, 0, NULL

بعد فترة ، تم الانتهاء من جميع الحاويات بوظائفها (التجميع والاختبار ..) ، لكن لم يتم "إرجاع" أي منهما. يبدو كما لو كانوا ينتظرون أنفسهم لرسو السفن.

عندما قتلت أخيرًا Dockerd ، انتهت الحاويات برسالة مثل هذه:

time="2015-08-05T15:59:32+02:00" level=fatal msg="Post http:///var/run/docker.sock/v1.18/containers/9117731bd16a451b89fd938f569c39761b5f8d6df505256e172738e0593ba125/wait: EOF. Are you trying to connect to a TLS-enabled daemon without TLS?" 

نحن نرى نفس الشيء مثل @ filex على Centos 7 في بيئة CI الخاصة بنا

Containers: 1
Images: 19
Storage Driver: devicemapper
 Pool Name: docker--vg-docker--pool
 Pool Blocksize: 524.3 kB
 Backing Filesystem: xfs
 Data file:
 Metadata file:
 Data Space Used: 2.611 GB
 Data Space Total: 32.17 GB
 Data Space Available: 29.56 GB
 Metadata Space Used: 507.9 kB
 Metadata Space Total: 54.53 MB
 Metadata Space Available: 54.02 MB
 Udev Sync Supported: true
 Deferred Removal Enabled: true
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.0-229.11.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 2
Total Memory: 7.389 GiB
Name: ip-10-1-2-234
ID: 5YVL:O32X:4NNA:ICSJ:RSYS:CNCI:6QVC:C5YR:XGR4:NQTW:PUSE:YFTA

Client version: 1.7.1
Client API version: 1.19
Package Version (client): docker-1.7.1-108.el7.centos.x86_64
Go version (client): go1.4.2
Git commit (client): 3043001/1.7.1
OS/Arch (client): linux/amd64
Server version: 1.7.1
Server API version: 1.19
Package Version (server): docker-1.7.1-108.el7.centos.x86_64
Go version (server): go1.4.2
Git commit (server): 3043001/1.7.1
OS/Arch (server): linux/amd64

نفس الشيء هنا: عامل الإرساء لم يكن يستجيب لـ ps ، rm ، stop ، run ، info وربما أكثر. بعد بضع عمليات إعادة تشغيل ، عاد كل شيء إلى طبيعته.

 معلومات عامل الميناء
 الحاويات: 25
 الصور: 1739
 برنامج تشغيل التخزين: devicemapper
 اسم البركة: docker-9: 2-62521632-pool
 حجم حوض السباحة: 65.54 kB
 دعم نظام الملفات: extfs
 ملف البيانات: / dev / loop0
 ملف البيانات الوصفية: / dev / loop1
 مساحة البيانات المستخدمة: 96.01 جيجا بايت
 إجمالي مساحة البيانات: 107.4 جيجا بايت
 مساحة البيانات المتوفرة: 11.36 جيجابايت
 مساحة البيانات الوصفية المستخدمة: 110.5 ميجا بايت
 إجمالي مساحة البيانات الوصفية: 2.147 جيجابايت
 مساحة البيانات الوصفية المتوفرة: 2.037 جيجابايت
 دعم Udev Sync: صحيح
 تم تمكين الإزالة المؤجلة: خطأ
 ملف حلقة البيانات: / var / lib / docker / devicemapper / devicemapper / data
 ملف حلقة البيانات الوصفية: / var / lib / docker / devicemapper / devicemapper / metadata
 إصدار المكتبة: 1.02.93-RHEL7 (2015-04-28)
 سائق التنفيذ: أصلي -0.2
 برنامج تشغيل التسجيل: ملف json
 إصدار النواة: 3.10.0-229.11.1.el7.x86_64
 نظام التشغيل: CentOS Linux 7 (Core)
 وحدات المعالجة المركزية: 8
 إجمالي الذاكرة: 31.2 جيجا بايت
 الاسم: CentOS-70-64-min
 المعرّف: EM3I: PELO: SBH6: JRVL: AM6C: UM7W: XJWJ: FI5N: JO77: 7PMF: S57A: PLAT

 نسخة عامل ميناء
 إصدار العميل: 1.7.1
 إصدار واجهة برمجة تطبيقات العميل: 1.19.1
 إصدار الحزمة (العميل): docker-1.7.1-108.el7.centos.x86_64
 إصدار Go (العميل): go1.4.2
 Git الالتزام (العميل): 3043001 / 1.7.1
 OS / Arch (العميل): linux / amd64
 إصدار الخادم: 1.7.1
 إصدار Server API: 1.19.1
 إصدار الحزمة (الخادم): docker-1.7.1-108.el7.centos.x86_64
 إصدار Go (الخادم): go1.4.2
 Git الالتزام (الخادم): 3043001 / 1.7.1
 OS / Arch (الخادم): linux / amd64

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

$ docker version
Client:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   44b3b67
 Built:        Mon Sep 14 23:56:40 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   44b3b67
 Built:        Mon Sep 14 23:56:40 UTC 2015
 OS/Arch:      linux/amd64

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

في حالتي ، كانت مجرد يد مليئة بالحاويات يتم تشغيلها في وقت واحد (ربما 3-5). لكنهم جميعًا يتلقون تدفقًا كبيرًا من المدخلات من خلال STDIN (من Docker run) ، مما قد يؤدي إلى زيادة الضغط على البرنامج الخفي.

filex لها حالة استخدام مماثلة. على الرغم من أننا لم نواجه هذا التجمد قبل الانتقال إلى 1.8.2

اليوم أواجه مشاكل مثل هذه - عامل الميناء مجمّد ، عامل الميناء يأكل 100٪ وحدة المعالجة المركزية.
والآن أرى أن وكيل البيانات الخاص بي قد سأل عامل ميناء في حلقة حول حاوياته مع هذا الخيار:

collect_container_size: true

لذلك لدي حلقة لا نهائية مع عملية صعبة للغاية (لدي أكثر من 10 آلاف حاوية). بعد أن توقفت عن تكامل Datadog Docker ، أصبح تشغيل النظام موافقًا - عملت Docker ps ، وأكل عامل Docker 0 ٪ cpu.

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

هل يمكنك تقديم المزيد من التفاصيل حول النتائج التي توصلت إليها؟

في الخميس ، 1 تشرين الأول (أكتوبر) 2015 ، 00:23 كتب Alexander Vagin [email protected] :

اليوم أواجه مشاكل مثل هذه - عامل الميناء مجمّد ، عامل الميناء يأكل 100٪ وحدة المعالجة المركزية.
والآن أرى أن وكيل البيانات الخاص بي قد سأل عامل الميناء في حلقة عنه
حاويات بهذا الخيار:

collect_container_size: صحيح

لذلك لدي حلقة لا نهائية مع عملية صعبة للغاية (لدي أكثر من 10 كيلو
حاويات). بعد أن توقفت عن تكامل Datadog Docker ، لا بأس بتشغيل النظام -
عملت عامل ميناء ps ، عامل عامل يأكل 0٪ وحدة المعالجة المركزية.

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

ohade يعمل عامل
لقد وجدت شخصًا ما يرسل طلبات إلى عامل الإرساء في السجلات (/var/log/upstart/docker.logs). ووجدت من كان :)
ماذا أخبرك أكثر؟

:) أنا منة ، هل هذا الوكيل جزء من عامل التحميل ويمكنني تغيير حجمه
يتحقق أيضا ، أم أنه وكيل خارجي؟

في الخميس ، 1 أكتوبر 2015 ، الساعة 14:03 كتب Alexander Vagin [email protected] :

ohade https://github.com/ohade يعمل عامل الإرساء الخاص بي بدون أي تجمد
24/7. في كل مرة لديها 60-80 حاوية بدأت. لدي حوالي 1500 جديد
حاويات في يوم واحد. لذلك عندما رأيت أنه مع هذا الحمل ، فقد تجمد و
فقط من عامل ميناء (يحتوي النظام على العديد من الذاكرة الخالية ، io ، وحدة المعالجة المركزية) ، أعتقد ذلك
إنها ليست مشكلة شائعة.
لقد وجدت شخصًا ما يرسل طلبات إلى عامل الإرساء الخاص بي في السجلات
(/var/log/upstart/docker.logs). ووجدت من كان :)
ماذا أخبرك أكثر؟

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

ohade لا ، إنه ليس جزءًا من عامل الميناء. رأيي أنها ليست قضية عامل ميناء. يجب أن تبحث في بيئتك عن الطلبات الثقيلة لرسو السفن.

أواجه هذه المشكلة أيضًا منذ أن قمت بالتحديث إلى docker 1.8.2

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

docker version
Client:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Thu Sep 10 19:12:52 UTC 2015
 OS/Arch:      linux/amd64
Server:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Thu Sep 10 19:12:52 UTC 2015
 OS/Arch:      linux/amd64

إصدار Linux:

$ uname -a
Linux grpc-interop1 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u3~bpo70+1 (2015-08-08) x86_64 GNU/Linux

انتقلنا إلى 1.8.3:

# docker version 
Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:        Mon Oct 12 06:06:01 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:        Mon Oct 12 06:06:01 UTC 2015
 OS/Arch:      linux/amd64

لكنه مع ذلك استمر في الانهيار ، في البداية مرة واحدة في غضون أيام قليلة ، وبعد ذلك حتى عشر مرات في اليوم. أدى الترحيل من CentOS 7 باستخدام أداة تعيين / الاسترجاع إلى Ubuntu 14.04 LTS باستخدام AUFS إلى فرزها.

شاهدت هذه المشكلة أيضًا https://github.com/docker/docker/issues/12606#issuecomment -149659953

أنا يمكن أن تتكاثر بشكل موثوق القضية عن طريق تشغيل هذه الاختبارات E2E في kubernetes في حلقة.

لقد اكتشفت سجل تتبع البرنامج الخفي ، ويبدو أن هناك طريق مسدود ، والكثير من goroutines معلقة على semacquire

goroutine 8956 [semacquire, 8 minutes]:
sync.(*Mutex).Lock(0xc208961650)
/usr/lib/go/src/sync/mutex.go:66 +0xd3
github.com/docker/docker/daemon.func·028(0xc20861c1e0, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/list.go:84 +0xfc
github.com/docker/docker/daemon.(*Daemon).Containers(0xc2080a50a0, 0xc209ec4820, 0x0, 0x0, 0x0, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/list.go:187 +0x917
github.com/docker/docker/api/server.(*Server).getContainersJSON(0xc208032540, 0xc3f700, 0x4, 0x7f214584f110, 0xc20a306d20, 0xc209d4a9c0, 0xc20a09fa10, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/api/server/server.go:562 +0x3ba
github.com/docker/docker/api/server.*Server.(github.com/docker/docker/api/server.getContainersJSON)·fm(0xc3f700, 0x4, 0x7f214584f110, 0xc20a306d20, 0xc209d4a9c0, 0xc20a09fa10, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/api/server/server.go:1526 +0x7b
github.com/docker/docker/api/server.func·008(0x7f214584f110, 0xc20a306d20, 0xc209d4a9c0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/api/server/server.go:1501 +0xacd
net/http.HandlerFunc.ServeHTTP(0xc208033380, 0x7f214584f110, 0xc20a306d20, 0xc209d4a9c0)
/usr/lib/go/src/net/http/server.go:1265 +0x41
github.com/gorilla/mux.(*Router).ServeHTTP(0xc2080b1090, 0x7f214584f110, 0xc20a306d20, 0xc209d4a9c0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/vendor/src/github.com/gorilla/mux/mux.go:98 +0x297
net/http.serverHandler.ServeHTTP(0xc20804f080, 0x7f214584f110, 0xc20a306d20, 0xc209d4a9c0)
/usr/lib/go/src/net/http/server.go:1703 +0x19a
net/http.(*conn).serve(0xc208743680)
/usr/lib/go/src/net/http/server.go:1204 +0xb57
created by net/http.(*Server).Serve
/usr/lib/go/src/net/http/server.go:1751 +0x35e

التتبع الكامل هنا:
https://gist.github.com/yifan-gu/ac0cbc2a59a7b8c3fe2d

سنحاول الاختبار على أحدث إصدار

حاولت مرة أخرى ، مع 1.7.1 ، ولكن هذه المرة وجدت شيئًا أكثر إثارة للاهتمام:

goroutine 114 [syscall, 50 minutes]:
syscall.Syscall6(0x3d, 0x514, 0xc2084e74fc, 0x0, 0xc208499950, 0x0, 0x0, 0x44199c, 0x441e22, 0xb28140)
/usr/lib/go/src/syscall/asm_linux_amd64.s:46 +0x5
syscall.wait4(0x514, 0xc2084e74fc, 0x0, 0xc208499950, 0x90, 0x0, 0x0)
/usr/lib/go/src/syscall/zsyscall_linux_amd64.go:124 +0x79
syscall.Wait4(0x514, 0xc2084e7544, 0x0, 0xc208499950, 0x41a768, 0x0, 0x0)
/usr/lib/go/src/syscall/syscall_linux.go:224 +0x60
os.(*Process).wait(0xc2083e2b20, 0xc20848a860, 0x0, 0x0)
/usr/lib/go/src/os/exec_unix.go:22 +0x103
os.(*Process).Wait(0xc2083e2b20, 0xc2084e7608, 0x0, 0x0)
/usr/lib/go/src/os/doc.go:45 +0x3a
os/exec.(*Cmd).Wait(0xc2083c9a40, 0x0, 0x0)
/usr/lib/go/src/os/exec/exec.go:364 +0x23c
github.com/docker/libcontainer.(*initProcess).wait(0xc20822cf30, 0x1b6, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/vendor/src/github.com/docker/libcontainer/process_linux.go:194 +0x3d
github.com/docker/libcontainer.Process.Wait(0xc208374a30, 0x1, 0x1, 0xc20839b000, 0x47, 0x80, 0x127e348, 0x0, 0x127e348, 0x0, ...)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/vendor/src/github.com/docker/libcontainer/process.go:60 +0x11d
github.com/docker/libcontainer.Process.Wait·fm(0xc2084e7ac8, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/execdriver/native/driver.go:164 +0x58
github.com/docker/docker/daemon/execdriver/native.(*driver).Run(0xc20813c230, 0xc20832a900, 0xc20822cc00, 0xc208374900, 0x0, 0x41a900, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/execdriver/native/driver.go:170 +0xa0a
github.com/docker/docker/daemon.(*Daemon).Run(0xc2080a5880, 0xc2080a21e0, 0xc20822cc00, 0xc208374900, 0x0, 0xc2084b6000, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/daemon.go:1068 +0x95
github.com/docker/docker/daemon.(*containerMonitor).Start(0xc20853d180, 0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/monitor.go:138 +0x457
github.com/docker/docker/daemon.*containerMonitor.Start·fm(0x0, 0x0)
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/daemon/container.go:732 +0x39
github.com/docker/docker/pkg/promise.func·001()
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/pkg/promise/promise.go:8 +0x2f
created by github.com/docker/docker/pkg/promise.Go
/build/amd64-usr/var/tmp/portage/app-emulation/docker-1.7.1-r4/work/docker-1.7.1/.gopath/src/github.com/docker/docker/pkg/promise/promise.go:9 +0xfb

رأيت حفنة من الغوروتين معلقة هنا. إذا توقف Container.Start() ، فسيؤدي ذلك إلى عدم تحرير قفل الحاوية ، وسيتم تعليق كل ما يلي docker ps . (يبدو أن هذا ينطبق أيضًا على الإصدار 1.9.0-rc1)

على الرغم من أنني لست متأكدًا من سبب تعليق Container.Start() ، وما إذا كان هذا هو السبب الوحيد لتعليق docker ps .

https://github.com/docker/docker/blob/v1.9.0-rc1/daemon/container.go#L243
https://github.com/docker/docker/blob/v1.9.0-rc1/daemon/container.go#L304
https://github.com/docker/docker/blob/v1.9.0-rc1/daemon/list.go#L113

أعتقد أننا يجب أن نحاول عدم الاحتفاظ بمفتاح مزامنة قبل مثل هذه النداءات على أي حال ...

هذه مشكلة كبيرة بالنسبة لي ، هل ينظر أي شخص من Docker في هذا؟

ping @ LK4D4tiborvass ^^ https://github.com/docker/docker/issues/13885#issuecomment -149767470

لدينا مشكلة مماثلة في Docker 1.8.2 ، وأظن أن هناك تسريبات روتينية أو أخرى تحدث في البرنامج الخفي.

عند وضعه تحت ضغط الإنشاء / الحذف السريع ، سيستغرق docker ps وقتًا طويلاً للانتهاء ، وفي النهاية سيفقد برنامج Docker daemon الراحة.

أواجه مشكلات مماثلة مع 1.8.2. لقد جربت 1.9 rc2 وكانت لدي مشكلات مماثلة ، والكثير من حالات التوقف وإعادة تشغيل برنامج Docker daemon ، والذي كان يعمل أحيانًا على تصحيح الأشياء وفي كثير من الأحيان لا.

سأكون فضوليًا لمعرفة وقت تعليق شيء ما ، ما هي المدة التي ستظل معلقة قبل أن يتم قتله؟
هل ستعود إذا تركتها تنتظر؟

على الرغم من أنني لم أحدد الوقت ، إلا أنني أقول إنها كانت أكثر من عشرين دقيقة على الأقل. لقد بدأت في استخدام Docker-Compose Kill مقابل Stop ويبدو أفضل ، لكن الوقت سيخبرنا. لا أرى أي شيء واضح من السجلات أيضًا.

نرى هذا أيضًا على centos 7.1 ، docker 1.8.2. يخبرني حدسي أنها مشكلة datamapper / الاسترجاع.

التالي في قائمتنا هو تجربة هذا: https://github.com/projectatomic/docker-storage-setup (h / tibuildthecloud )

تعاني أيضًا من هذا وليس تحت عبء ثقيل.

سنتوس 7

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

Client:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Thu Sep 10 19:08:45 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Thu Sep 10 19:08:45 UTC 2015
 OS/Arch:      linux/amd64

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

Containers: 4
Images: 40
Storage Driver: devicemapper
 Pool Name: docker-202:1-25190844-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 2.914 GB
 Data Space Total: 107.4 GB
 Data Space Available: 81.05 GB
 Metadata Space Used: 4.03 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.143 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.0-123.8.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 4
Total Memory: 6.898 GiB
Name: ip-10-50-185-203
ID: EOMR:4G7Y:7H6O:QOXE:WW4Z:3R2G:HLI4:ZMXY:GKF3:YKSK:TIHC:MHZF
[centos@ip-10-50-185-203 ~]$ uname -a
Linux ip-10-50-185-203 3.10.0-123.8.1.el7.x86_64 #1 SMP Mon Sep 22 19:06:58 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

تعمل صور عامل الميناء ولكن توقف عامل الميناء ملاحظة.

الأسطر القليلة الأخيرة من إخراج الدعامة:

clock_gettime(CLOCK_MONOTONIC, {2393432, 541406232}) = 0
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
connect(3, {sa_family=AF_LOCAL, sun_path="/run/systemd/journal/socket"}, 30) = 0
epoll_create1(EPOLL_CLOEXEC)            = 4
epoll_ctl(4, EPOLL_CTL_ADD, 3, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=2856433208, u64=139812631852600}}) = 0
getsockname(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0
getpeername(3, {sa_family=AF_LOCAL, sun_path="/run/systemd/journal/socket"}, [30]) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 542834304}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 542897330}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543010460}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543090332}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543157219}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543208557}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543306537}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543364486}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 108316907}) = 0
mmap(0xc208100000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc208100000
mmap(0xc207fe0000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc207fe0000
clock_gettime(CLOCK_MONOTONIC, {2393432, 543814528}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543864338}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 543956865}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 544018495}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 544402150}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 544559595}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 544607443}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 109474379}) = 0
epoll_wait(4, {{EPOLLOUT, {u32=2856433208, u64=139812631852600}}}, 128, 0) = 1
clock_gettime(CLOCK_MONOTONIC, {2393432, 544968692}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545036728}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545095771}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545147947}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545199057}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545251039}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545308858}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 545756723}) = 0
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_REALTIME, {1446718224, 112187655}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 112265169}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 112345304}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 547677486}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 547743669}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 547801800}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 547864215}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 547934364}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 548042167}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 548133574}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 548209405}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 113124453}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 548493023}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 548566472}) = 0
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
futex(0xc208020ed8, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_MONOTONIC, {2393432, 549410983}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 549531015}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 549644468}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 549713961}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 549800266}) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 549864335}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
stat("/root/.docker/config.json", 0xc208052900) = -1 ENOENT (No such file or directory)
stat("/root/.dockercfg", 0xc208052990)  = -1 ENOENT (No such file or directory)
clock_gettime(CLOCK_REALTIME, {1446718224, 115099477}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 115153125}) = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 5
setsockopt(5, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
connect(5, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, 23) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 550603891}) = 0
clock_gettime(CLOCK_REALTIME, {1446718224, 115517051}) = 0
epoll_ctl(4, EPOLL_CTL_ADD, 5, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=2856433016, u64=139812631852408}}) = 0
getsockname(5, {sa_family=AF_LOCAL, NULL}, [2]) = 0
getpeername(5, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, [23]) = 0
clock_gettime(CLOCK_MONOTONIC, {2393432, 550961223}) = 0
read(5, 0xc208131000, 4096)             = -1 EAGAIN (Resource temporarily unavailable)
clock_gettime(CLOCK_MONOTONIC, {2393432, 551138398}) = 0
write(5, "GET /v1.20/containers/json HTTP/"..., 108) = 108
epoll_wait(4, {{EPOLLOUT, {u32=2856433016, u64=139812631852408}}}, 128, 0) = 1
epoll_wait(4, 

chbatey هل يمكنك تعديل تعليقك وإضافة ناتج docker version ؟

بالنسبة لي ولون وجهي باللون الأحمر. قمت بتشغيل البرنامج الخفي في التصحيح واكتشفت وحدة تخزين مشتركة كانت معلقة على cifs mount. بمجرد أن اهتمت بذلك ، تسير الأمور بشكل جيد بالنسبة لي الآن.

pspierce لا توجد مشكلة ، شكرًا لك على الإبلاغ!

أنا مهتم بمعرفة ما إذا كان هذا لا يزال يمثل مشكلة على 1.9 لأي شخص هنا

نرى هذا أيضًا مع 1.8.2 على centos 7.1 بشكل متكرر جدًا ، ولكن فقط على مضيفينا ذوي النشاط المرتفع (حوالي 2100 حاوية / ساعة). لا يبدو أنه يؤثر على مضيفينا الذين تم تكوينهم بشكل مماثل ، ولكن حجم أقل (حوالي 300 حاوية / ساعة) ، لذلك يبدو أنه نوع من الجمود الناجم عن الكثير من العمليات المتزامنة؟ نرى ذلك ~ / 6 ساعات من النشاط عالي النشاط ، وحتى الآن الحل الوحيد الذي وجدناه هو تشغيل البرنامج الخفي

سنقوم بتجربة 1.9 في الأسبوع القادم ومعرفة ما إذا كان ذلك مفيدًا على الإطلاق (تقاطع الأصابع!) ؛ fwiw ، لم نواجه هذا التدهور التدريجي للاستجابة (والمأزق النهائي) في 1.6.2.

فيما يلي التفاصيل المتعلقة: الإعداد الحالي لدينا:

PRODUCTION [[email protected] ~]$ docker -D info
Containers: 8
Images: 41
Storage Driver: overlay
 Backing Filesystem: xfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.3.0-1.el7.elrepo.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 4
Total Memory: 7.796 GiB
Name: cc-docker01.prod.iad01.treehouse
ID: AB4S:SO4Z:AEOS:MC3H:XPRV:SIH4:VE2N:ELYX:TA5S:QQWP:WDAP:DUKE
Username: xxxxxxxxxxxxxx
Registry: https://index.docker.io/v1/
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

PRODUCTION [[email protected] ~]$ docker -D version
Client:
 Version:      1.8.2
 API version:  1.20
 Package Version: docker-1.8.2-7.el7.centos.x86_64
 Go version:   go1.4.2
 Git commit:   bb472f0/1.8.2
 Built:        
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.2
 API version:  1.20
 Package Version: 
 Go version:   go1.4.2
 Git commit:   bb472f0/1.8.2
 Built:        
 OS/Arch:      linux/amd64

نرى هذا أيضًا في Ubuntu 14.04 ، فقط 8 حاويات تعمل ولكن تحميل قرص عالي ووحدة المعالجة المركزية. يتم إعادة تشغيل الحاويات عند اكتمالها ، لذلك هناك دائمًا 8 حاويات قيد التشغيل. يموت البرنامج الخفي بعد أي شيء من بضع مئات إلى بضعة آلاف من جولات الحاوية التراكمية. لم أشاهد الشيطان معلقًا عندما كنت أجري على الاسترجاع ولكن حدث ذلك مرتين في اليومين الماضيين باستخدام Thinpool. هذا على محطة عمل 40 نواة مع 64 جيجابايت من ذاكرة الوصول العشوائي.

إصدار عامل ميناء:
~ إصدار عامل ميناء
عميل:
الإصدار: 1.9.1.1
إصدار API: 1.21
إصدار Go: go1.4.2
Git الالتزام: a34a1d5
بني: الجمعة 20 تشرين الثاني (نوفمبر) 13:12:04 بالتوقيت العالمي المنسق 2015
OS / Arch: لينكس / amd64

الخادم:
الإصدار: 1.9.1.1
إصدار API: 1.21
إصدار Go: go1.4.2
Git الالتزام: a34a1d5
بني: الجمعة 20 تشرين الثاني (نوفمبر) 13:12:04 بالتوقيت العالمي المنسق 2015
OS / Arch: لينكس / amd64

--- تعمل صورة عامل الميناء ولكن توقف عامل الميناء ملاحظة. توقف معلومات عامل الميناء أيضًا. ها هي نهاية الدعامة لـ Docker PS:
مقبس (PF_LOCAL ، SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK ، 0) = 3
setockopt (3، SOL_SOCKET، SO_BROADCAST، [1]، 4) = 0
connect (3، {sa_family = AF_LOCAL، sun_path = "/ var / run / docker.sock"}، 23) = 0
epoll_create1 (EPOLL_CLOEXEC) = 4
epoll_ctl (4، EPOLL_CTL_ADD، 3، {EPOLLIN | EPOLLOUT | EPOLLRDHUP | EPOLLET، {u32 = 3565442144، u64 = 140517715498080}}) = 0
getockname (3، {sa_family = AF_LOCAL، NULL}، [2]) = 0
getpeername (3، {sa_family = AF_LOCAL، sun_path = "/ var / run / docker.sock"}، [23]) = 0
قراءة (3، 0xc208506000، 4096) = -1 EAGAIN (المورد غير متاح مؤقتًا)
اكتب (3 ، "GET /v1.21/containers/json HTTP /" ... ، 108) = 108
epoll_wait (4، {{EPOLLOUT، {u32 = 3565442144، u64 = 140517715498080}}}، 128، 0) = 1
epoll_wait (4 ،

كان لدينا هذا أقل من 1.7.1 ، وعملنا حوله بشكل فعال للغاية (رأينا ذلك كل بضع ساعات تحت 1.7.1 ، ولكن ليس لمدة شهر واحد بعد الحل البديل):

udevadm control --timeout=300

نحن نشغل RHEL7.1. لقد قمنا للتو بترقية Docker 1.8.2 دون أي تغييرات أخرى ، وقام تطبيقنا بإغلاقه في غضون ساعات قليلة. دعامة:

"
[pid 4200] مفتوح ("/ sys / fs / cgroup / freezer / system.slice / docker-bcb29dad6848d250df7508f85e78ca9b83d40f0e22011869d89a176e27b7ef87.scope / freezer.state" ، O_RDONLY | O_CL
[pid 4200] fstat (36، {st_mode = S_IFREG | 0644، st_size = 0، ...}) = 0
[pid 4239] <... حدد استئناف>) = 0 (مهلة)
يستعاض عن [pid 4200] بـ (36، [pid 4239] حدد (0 ، NULL ، NULL ، NULL ، {0 ، 20} [pid 4200] <... تم استئناف القراءة> "FREEZINGn" ، 512) = 9
[pid 4200] يُقرأ (36، ""، 1527) = 0
[pid 4200] إغلاق (36) = 0
[pid 4200] Futex (0x1778e78، FUTEX_WAKE، 1 [pid 4239] <... حدد استئناف>) = 0 (مهلة)
[pid 5252] <... استئناف العقود الآجلة>) = 0
[pid 4200] <... استئناف العقود الآجلة>) = 1
[pid 5252] Futex (0xc2085daed8 ، FUTEX_WAIT ، 0 ، NULL [pid 4239] حدد (0 ، NULL ، NULL ، NULL ، {0 ، 20} [pid 4200] Futex (0xc2085daed8 ، FUTEX_WAKE ، 1 [pid 5252] <... استئناف futex>) = -1 EAGAIN (المورد غير متاح مؤقتًا)
[pid 4200] <... استئناف العقود الآجلة>) = 0
[pid 5252] epoll_wait (4 ، [pid 4200] Futex (0x1778e78، FUTEX_WAIT، 0، {0، 958625} [pid 5252] <... تم استئناف epoll_wait> {}، 128، 0) = 0
[pid 5252] Futex (0xc2085daed8 ، FUTEX_WAIT ، 0 ، NULL [pid 4239] <... حدد استئناف>) = 0 (مهلة)

نحن نواجه نفس المشكلة https://github.com/giantswarm/giantswarm/issues/289

تحديث: يبدو أن فرضيتي حول التشابك docker run / docker rm كانت غير سليمة. حاولت فقط القيام بالعديد من docker run s في وقت واحد وكان ذلك كافياً لتشغيل السلوك. حاولت أيضًا التبديل إلى dm thinpool ، لكن ذلك لم يساعد أيضًا. كان الحل الذي أجريته هو ببساطة ضمان عدم بدء تشغيل حاويات متعددة في "نفس الوقت" ، أي أقوم بإضافة فجوات 10-30 ثانية على الأقل بين البداية. الآن يتم تشغيل البرنامج الخفي دون أي مشاكل لأكثر من أسبوعين. نهاية التحديث.

فقط لإضافة تأكيد آخر ، نرى هذا في 1.9.0. نحن لا نفرخ كثيرًا ، بحد أقصى 8 حاويات (1 لكل نواة) في وقت واحد ، ولا يزيد عن 40 تقريبًا في الساعة. أحد الأشياء الشائعة في التقرير الأصلي هو أننا انتهينا أيضًا من القيام ببعض الاستدعاءات المتشابكة docker run و docker rm -f . شعوري الغريزي هو أنه مزيج من العديد من الحاويات المتزامنة التي تخلق وتحذف ما يؤدي إلى طريق مسدود.

$ docker version
Client:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 18:00:05 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 18:00:05 UTC 2015
 OS/Arch:      linux/amd64

$ docker -D info
Containers: 10
Images: 119
Server Version: 1.9.0
Storage Driver: devicemapper
 Pool Name: docker-253:1-2114818-pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 107.4 GB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 7.234 GB
 Data Space Total: 107.4 GB
 Data Space Available: 42.64 GB
 Metadata Space Used: 10.82 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.137 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
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.0-229.20.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 8
Total Memory: 15.51 GiB

mjsalinger لدينا نفس المشكلة التي تواجهك ، بنفس الإعداد ، هل قمت بحل المشكلة؟

نفس المشكلة هنا

~ # docker info
Containers: 118
Images: 2239
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.2-coreos-r1
Operating System: CoreOS 835.8.0
CPUs: 16
Total Memory: 29.44 GiB
Username: util-user
Registry: https://index.docker.io/v1/
Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   cedd534-dirty
 Built:        Tue Dec  1 02:00:58 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   cedd534-dirty
 Built:        Tue Dec  1 02:00:58 UTC 2015
 OS/Arch:      linux/amd64

سجلاتنا مليئة بأشياء مثل:

time="2016-01-08T21:38:34.735146159Z" level=error msg="Failed to compute size of container rootfs e4565ff148266389cbf70af9f22f9c62aa255bacaec0925a72eab5d0dca9da5f: Error getting container e4565ff148266389cbf70af9f22f9c62aa255bacaec0925a72eab5d0dca9da5f from driver overlay: stat /var/lib/docker/overlay/e4565ff148266389cbf70af9f22f9c62aa255bacaec0925a72eab5d0dca9da5f: no such file or directory"

و

time="2016-01-08T21:42:34.846701169Z" level=error msg="Handler for GET /containers/json returned error: write unix @: broken pipe"
time="2016-01-08T21:42:34.846717812Z" level=error msg="HTTP Error" err="write unix @: broken pipe" statusCode=500

لكنني لست متأكدًا مما إذا كان أي منها له علاقة بقضية التعليق.

قد يكون من المفيد تضمين تفريغ جميع مجموعات docker goroutines عن طريق إرسال SIGUSR1 إلى برنامج خفي ..

whosthatknocking لم يعرف حتى أنني أستطيع فعل ذلك ، رائع.

time="2016-01-08T22:20:16.181468178Z" level=info msg="=== BEGIN goroutine stack dump ===
goroutine 11 [running]:
github.com/docker/docker/pkg/signal.DumpStacks()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/signal/trap.go:60 +0x7a
github.com/docker/docker/daemon.func·025()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/debugtrap_unix.go:18 +0x6d
created by github.com/docker/docker/daemon.setupDumpStackTrap
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/debugtrap_unix.go:20 +0x18e

goroutine 1 [chan receive, 33262 minutes]:
main.(*DaemonCli).CmdDaemon(0xc20807d1a0, 0xc20800a020, 0x1, 0x1, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/docker/daemon.go:289 +0x1781
reflect.callMethod(0xc208142060, 0xc20842fce0)
    /usr/lib/go/src/reflect/value.go:605 +0x179
reflect.methodValueCall(0xc20800a020, 0x1, 0x1, 0x1, 0xc208142060, 0x0, 0x0, 0xc208142060, 0x0, 0x452ecf, ...)
    /usr/lib/go/src/reflect/asm_amd64.s:29 +0x36
github.com/docker/docker/cli.(*Cli).Run(0xc20810df80, 0xc20800a010, 0x2, 0x2, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/cli/cli.go:89 +0x38e
main.main()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/docker/docker.go:69 +0x428

goroutine 5 [syscall]:
os/signal.loop()
    /usr/lib/go/src/os/signal/signal_unix.go:21 +0x1f
created by os/signal.init·1
    /usr/lib/go/src/os/signal/signal_unix.go:27 +0x35

goroutine 17 [syscall, 33262 minutes, locked to thread]:
runtime.goexit()
    /usr/lib/go/src/runtime/asm_amd64.s:2232 +0x1

goroutine 13 [IO wait, 33262 minutes]:
net.(*pollDesc).Wait(0xc2081eb100, 0x72, 0x0, 0x0)
    /usr/lib/go/src/net/fd_poll_runtime.go:84 +0x47
net.(*pollDesc).WaitRead(0xc2081eb1
00, 0x0, 0x0)
    /usr/lib/go/src/net/fd_poll_runtime.go:89 +0x43
net.(*netFD).readMsg(0xc2081eb0a0, 0xc2081bd9a0, 0x10, 0x10, 0xc208440020, 0x1000, 0x1000, 0xffffffffffffffff, 0x0, 0x0, ...)
    /usr/lib/go/src/net/fd_unix.go:296 +0x54e
net.(*UnixConn).ReadMsgUnix(0xc2080384b8, 0xc2081bd9a0, 0x10, 0x10, 0xc208440020, 0x1000, 0x1000, 0x51, 0xc2081bd6d4, 0x4, ...)
    /usr/lib/go/src/net/unixsock_posix.go:147 +0x167
github.com/godbus/dbus.(*oobReader).Read(0xc208440000, 0xc2081bd9a0, 0x10, 0x10, 0xc208440000, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/transport_unix.go:21 +0xc5
io.ReadAtLeast(0x7f9ad52e9310, 0xc208440000, 0xc2081bd9a0, 0x10, 0x10, 0x10, 0x0, 0x0, 0x0)
    /usr/lib/go/src/io/io.go:298 +0xf1
io.ReadFull(0x7f9ad52e9310, 0xc208440000, 0xc2081bd9a0, 0x10, 0x10, 0x51, 0x0, 0x0)
    /usr/lib/go/src/io/io.go:316 +0x6d
github.com/godbus/dbus.(*unixTransport).ReadMessage(0xc2081df900, 0xc208115170, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/transport_unix.go:85 +0x1bf
github.com/godbus/dbus.(*Conn).inWorker(0xc208418480)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/conn.go:248 +0x58
created by github.com/godbus/dbus.(*Conn).Auth
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/auth.go:118 +0xe84

goroutine 10 [chan receive, 33262 minutes]:
github.com/docker/docker/api/server.(*Server).ServeApi(0xc208037800, 0xc20807d3d0, 0x1, 0x1, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/api/server/server.go:111 +0x74f
main.func·007()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/docker/daemon.go:239 +0x5b
created by main.(*DaemonCli).CmdDaemon
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-
1.8.3/work/docker-1.8.3/docker/daemon.go:245 +0xce9

goroutine 14 [chan receive, 33262 minutes]:
github.com/godbus/dbus.(*Conn).outWorker(0xc208418480)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/conn.go:370 +0x58
created by github.com/godbus/dbus.(*Conn).Auth
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/auth.go:119 +0xea1

goroutine 15 [chan receive, 33262 minutes]:
github.com/docker/libnetwork/iptables.signalHandler()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/docker/libnetwork/iptables/firewalld.go:92 +0x57
created by github.com/docker/libnetwork/iptables.FirewalldInit
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/docker/libnetwork/iptables/firewalld.go:48 +0x185

goroutine 50 [chan receive, 33262 minutes]:
database/sql.(*DB).connectionOpener(0xc2081aa0a0)
    /usr/lib/go/src/database/sql/sql.go:589 +0x4c
created by database/sql.Open
    /usr/lib/go/src/database/sql/sql.go:452 +0x31c

goroutine 51 [IO wait]:
net.(*pollDesc).Wait(0xc2081dcd10, 0x72, 0x0, 0x0)
    /usr/lib/go/src/net/fd_poll_runtime.go:84 +0x47
net.(*pollDesc).WaitRead(0xc2081dcd10, 0x0, 0x0)
    /usr/lib/go/src/net/fd_poll_runtime.go:89 +0x43
net.(*netFD).readMsg(0xc2081dccb0, 0xc20b38c970, 0x10, 0x10, 0xc20bf3b220, 0x1000, 0x1000, 0xffffffffffffffff, 0x0, 0x0, ...)
    /usr/lib/go/src/net/fd_unix.go:296 +0x54e
net.(*UnixConn).ReadMsgUnix(0xc208038618, 0xc20b38c970, 0x10, 0x10, 0xc20bf3b220, 0x1000, 0x1000, 0x35, 0xc20b38c784, 0x4, ...)
    /usr/lib/go/src/net/unixsock_posix.go:147 +0x167
github.com/godbus/dbus.(*oobReader).Read(0xc20bf3b200, 0xc20b38c970, 0x10, 0x10, 0xc20bf3b200, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/transport_unix.go:21 +0xc5
io.ReadAtLeast(0x7f9ad52e9310, 0xc20bf3b200, 0x
c20b38c970, 0x10, 0x10, 0x10, 0x0, 0x0, 0x0)
    /usr/lib/go/src/io/io.go:298 +0xf1
io.ReadFull(0x7f9ad52e9310, 0xc20bf3b200, 0xc20b38c970, 0x10, 0x10, 0x35, 0x0, 0x0)
    /usr/lib/go/src/io/io.go:316 +0x6d
github.com/godbus/dbus.(*unixTransport).ReadMessage(0xc208176950, 0xc208471470, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/transport_unix.go:85 +0x1bf
github.com/godbus/dbus.(*Conn).inWorker(0xc2080b0fc0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/conn.go:248 +0x58
created by github.com/godbus/dbus.(*Conn).Auth
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/auth.go:118 +0xe84

goroutine 52 [chan receive]:
github.com/godbus/dbus.(*Conn).outWorker(0xc2080b0fc0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/conn.go:370 +0x58
created by github.com/godbus/dbus.(*Conn).Auth
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/godbus/dbus/auth.go:119 +0xea1

goroutine 53 [chan receive]:
github.com/coreos/go-systemd/dbus.func·001()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/coreos/go-systemd/dbus/subscription.go:70 +0x64
created by github.com/coreos/go-systemd/dbus.(*Conn).initDispatch
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/coreos/go-systemd/dbus/subscription.go:94 +0x11c

goroutine 54 [chan receive]:
github.com/docker/docker/daemon.(*statsCollector).run(0xc20844dad0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/stats_collector_unix.go:91 +0xb2
created by github.com/docker/docker/daemon.newStatsCollector
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/wo
rk/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/stats_collector_unix.go:31 +0x116

goroutine 55 [chan receive, 2 minutes]:
github.com/docker/docker/daemon.(*Daemon).execCommandGC(0xc2080908c0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/exec.go:256 +0x8c
created by github.com/docker/docker/daemon.NewDaemon
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/daemon.go:736 +0x2358

goroutine 774 [semacquire, 33261 minutes]:
sync.(*Cond).Wait(0xc208460030)
    /usr/lib/go/src/sync/cond.go:62 +0x9e
io.(*pipe).read(0xc208460000, 0xc208c0bc00, 0x400, 0x400, 0x0, 0x0, 0x0)
    /usr/lib/go/src/io/pipe.go:52 +0x303
io.(*PipeReader).Read(0xc208b52750, 0xc208c0bc00, 0x400, 0x400, 0x1f, 0x0, 0x0)
    /usr/lib/go/src/io/pipe.go:134 +0x5b
github.com/docker/docker/pkg/ioutils.(*bufReader).drain(0xc2084600c0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/ioutils/readers.go:116 +0x10e
created by github.com/docker/docker/pkg/ioutils.NewBufReader
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/ioutils/readers.go:86 +0x2f3

goroutine 784 [semacquire, 33261 minutes]:
sync.(*Cond).Wait(0xc208460570)
    /usr/lib/go/src/sync/cond.go:62 +0x9e
io.(*pipe).read(0xc208460540, 0xc208963000, 0x400, 0x400, 0x0, 0x0, 0x0)
    /usr/lib/go/src/io/pipe.go:52 +0x303
io.(*PipeReader).Read(0xc208b529d8, 0xc208963000, 0x400, 0x400, 0x1f, 0x0, 0x0)
    /usr/lib/go/src/io/pipe.go:134 +0x5b
github.com/docker/docker/pkg/ioutils.(*bufReader).drain(0xc208460600)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/ioutils/readers.go:116 +0x10e
created by github.com/docker/docker/pkg/ioutils.NewBufReader
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/wo
rk/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/ioutils/readers.go:86 +0x2f3

goroutine 757 [semacquire, 33261 minutes]:
sync.(*Cond).Wait(0xc208141cb0)
    /usr/lib/go/src/sync/cond.go:62 +0x9e
github.com/docker/docker/pkg/ioutils.(*bufReader).Read(0xc208141c80, 0xc2089f2000, 0x1000, 0x1000, 0x0, 0x7f9ad52d4080, 0xc20802a0d0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/ioutils/readers.go:210 +0x158
bufio.(*Reader).fill(0xc208956ae0)
    /usr/lib/go/src/bufio/bufio.go:97 +0x1ce
bufio.(*Reader).ReadSlice(0xc208956ae0, 0x41d50a, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/lib/go/src/bufio/bufio.go:295 +0x257
bufio.(*Reader).ReadBytes(0xc208956ae0, 0xc208141c0a, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/lib/go/src/bufio/bufio.go:374 +0xd2
github.com/docker/docker/daemon/logger.(*Copier).copySrc(0xc2084def40, 0xf8ac00, 0x6, 0x7f9ad003e420, 0xc208141c80)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/logger/copier.go:47 +0x96
created by github.com/docker/docker/daemon/logger.(*Copier).Run
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/logger/copier.go:38 +0x11c

goroutine 842 [chan receive, 33261 minutes]:
github.com/docker/docker/daemon.(*Container).AttachWithLogs(0xc208cc90e0, 0x0, 0x0, 0x7f9ad003e398, 0xc208471e30, 0x7f9ad003e398, 0xc208471e00, 0x100, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/container.go:934 +0x40d
github.com/docker/docker/daemon.(*Daemon).ContainerAttachWithLogs(0xc2080908c0, 0xc208cc90e0, 0xc208471dd0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/attach.go:39 +0x42c
github.com/docker/docker/api/server.(*Server).postContainersAttach(0xc208037800, 0xc208b36007, 0x4, 0x7f9ad52f2870, 0xc20
87fde00, 0xc2087d4410, 0xc208471b90, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/api/server/server.go:1169 +0x5d1
github.com/docker/docker/api/server.*Server.(github.com/docker/docker/api/server.postContainersAttach)·fm(0xc208b36007, 0x4, 0x7f9ad52f2870, 0xc2087fde00, 0xc2087d4410, 0xc208471b90, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/api/server/server.go:1671 +0x7b
github.com/docker/docker/api/server.func·008(0x7f9ad52f2870, 0xc2087fde00, 0xc2087d4410)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/api/server/server.go:1614 +0xc8f
net/http.HandlerFunc.ServeHTTP(0xc2081cc580, 0x7f9ad52f2870, 0xc2087fde00, 0xc2087d4410)
    /usr/lib/go/src/net/http/server.go:1265 +0x41
github.com/gorilla/mux.(*Router).ServeHTTP(0xc20813cd70, 0x7f9ad52f2870, 0xc2087fde00, 0xc2087d4410)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/vendor/src/github.com/gorilla/mux/mux.go:98 +0x297
net/http.serverHandler.ServeHTTP(0xc2082375c0, 0x7f9ad52f2870, 0xc2087fde00, 0xc2087d4410)
    /usr/lib/go/src/net/http/server.go:1703 +0x19a
net/http.(*conn).serve(0xc2087fdd60)
    /usr/lib/go/src/net/http/server.go:1204 +0xb57
created by net/http.(*Server).Serve
    /usr/lib/go/src/net/http/server.go:1751 +0x35e

goroutine 789 [semacquire, 33261 minutes]:
sync.(*WaitGroup).Wait(0xc20882de60)
    /usr/lib/go/src/sync/waitgroup.go:132 +0x169
github.com/docker/docker/daemon.func·017(0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/container.go:1035 +0x42
github.com/docker/docker/pkg/promise.func·001()
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/promise/promise.go:8 +0x2f
created by github.com/docker/docker/pkg
/promise.Go
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/promise/promise.go:9 +0xfb

goroutine 788 [semacquire, 33261 minutes]:
sync.(*Cond).Wait(0xc2084607b0)
    /usr/lib/go/src/sync/cond.go:62 +0x9e
github.com/docker/docker/pkg/ioutils.(*bufReader).Read(0xc208460780, 0xc208a70000, 0x8000, 0x8000, 0x0, 0x7f9ad52d4080, 0xc20802a0d0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/pkg/ioutils/readers.go:210 +0x158
io.Copy(0x7f9ad003e398, 0xc208845860, 0x7f9ad003e420, 0xc208460780, 0x0, 0x0, 0x0)
    /usr/lib/go/src/io/io.go:362 +0x1f6
github.com/docker/docker/daemon.func·016(0xf8abc0, 0x6, 0x7f9ad003e398, 0xc208845860, 0x7f9ad003e3f0, 0xc208460780)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/container.go:1021 +0x245
created by github.com/docker/docker/daemon.attach
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.8.3/work/docker-1.8.3/.gopath/src/github.com/docker/docker/daemon/container.go:1032 +0x597

goroutine 769 [IO wait, 33261 minutes]:
net.(*pollDesc).Wait(0xc20881de20, 0x72, 0x0, 0x0)
    /usr/lib/go/src/net/fd_poll_runtime.go:84 +0x47
net.(*pollDesc).WaitRead(0xc20881de20, 0x0, 0x0)
    /usr/lib/go/src/net/fd_poll_runtime.go:89 +0x43
net.(*netFD).Read(0xc20881ddc0, 0xc2088ac000, 0x1000, 0x1000, 0x0, 0x7f9ad52d8340, 0xc20880d758)
    /usr/lib/go/src/net/fd_unix.go:242 +0x40f
net.(*conn).Read(0xc208b52360, 0xc2088ac000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
    /usr/lib/go/src/net/net.go:121 +0xdc
net/http.(*liveSwitchReader).Read(0xc208792c28, 0xc2088ac000, 0x1000, 0x1000, 0x2, 0x0, 0x0)
    /usr/lib/go/src/net/http/server.go:214 +0xab
io.(*LimitedReader).Read(0xc20889f960, 0xc2088ac000, 0x1000, 0x1000, 0x2, 0x0, 0x0)
    /usr/lib/go/src/io/io.go:408 +0xce
bufio.(*Reader).fill(0xc2082544e0)
    /usr/lib/go/src/bufio/bufio.go:97 +0x1ce
bufio.(*Reader).ReadSlice(0xc208254
4e0, 0xc20889db0a, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/lib/go/src/bufio/bufio.go:295 +0x257
bufio.(*Reader).ReadLine(0xc2082544e0, 0x0, 0x0, 0x0, 0xc208bc2700, 0x0, 0x0)
    /usr/lib/go/src/bufio/bufio.go:324 +0x62
net/textproto.(*Reader).readLineSlice(0xc208845560, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/lib/go/src/net/textproto/reader.go:55 +0x9e
net/textproto.(*Reader).ReadLine(0xc208845560, 0x0, 0x0, 0x0, 0x0)
    /u
=== END goroutine stack dump ==="

كان لدي للتو تعليق ، عامل ميناء الذهاب الروتينية المرفقة عامل ميناء hang.txt

أرى هذا أيضًا بشكل متكرر في السجلات بعد التعطل
kernel: unregister_netdevice: waiting for veth2fb10a9 to become free. Usage count = 1

rwky ربما مرتبط بـ https://github.com/docker/docker/issues/5618؟

thaJeztah ربما ولكن يبدو أن # 5618 ينطبق فقط على lo و eth0 وليس الواجهة التي كانت الحاوية مرتبطة بها.

حدثت نفس المشكلة عندما تم جدولة تحميل ثقيل من وظائف Kubernetes. لا يتم إرجاع docker ps أبدًا. بالفعل curl --unix-socket /var/run/docker.sock http:/containers/json توقف. لا بد لي من إعادة تشغيل Docker daemon لاستعادة المشكلة. ما هو أسوأ من ذلك هو أن إعادة تشغيل Docker daemon يستغرق دقيقتين!

$ docker version
Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.3
 Git commit:   cedd534-dirty
 Built:        Thu Nov 19 23:12:57 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.3
 Git commit:   cedd534-dirty
 Built:        Thu Nov 19 23:12:57 UTC 2015
 OS/Arch:      linux/amd64

$ docker info
Containers: 57
Images: 100
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.2-coreos-r2
Operating System: CoreOS 870.2.0
CPUs: 32
Total Memory: 251.9 GiB
Name: CNPVG50853311
ID: TV5P:6OHQ:QTSN:IF6K:5LPX:TSHS:DEAW:TQSF:QTOT:45NO:JH2X:DMSE
Http Proxy: http://proxy.wdf.sap.corp:8080
Https Proxy: http://proxy.wdf.sap.corp:8080
No Proxy: hyper.cd,anywhere.cd

عند رؤية شيء مشابه في بيئتنا ، فقد ألغيت المعلومات الواردة أدناه للمساعدة في أي تصحيح. الإحصائيات من مضيفين فيزيائيين عاليي المواصفات 4.2 يعملان في حوالي 70 حاوية لكل منهما. نرى أداء عامل الإرساء يتدهور ، ولم أتمكن من تعقب المشغل ، لكن إعادة تشغيل برنامج عامل الإرساء يعمل على حل المشكلة.

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

Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   994543b
 Built:        Mon Nov 23 06:08:57 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   994543b
 Built:        Mon Nov 23 06:08:57 UTC 2015
 OS/Arch:      linux/amd64

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

Containers: 35
Images: 1958
Server Version: 1.9.1
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.3-rancher
Operating System: RancherOS (containerized)
CPUs: 64
Total Memory: 251.9 GiB
Name: PTL-BCA-07
ID: Q5WF:7MOB:37YR:NRZR:P2FE:DVWV:W7XY:Z6OL:TAVC:4KCM:IUFU:LO4C

تتبع المكدس:
debug2.txt

إجراء +1 لذلك بالنسبة لنا أيضًا ، بالتأكيد نراه في كثير من الأحيان تحت حمولة أعلى ، يعمل على سنتوس 6

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

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

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

Containers: 1
Images: 55
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.18.23-74.el6.x86_64
Operating System: <unknown>
CPUs: 40
Total Memory: 157.4 GiB
Name: lively-frost
ID: SXAC:IJ45:UY45:FIXS:7MWD:MZAE:XSE5:HV3Z:DU4Z:CYK6:LXPB:A65F

ssalinas حتى لو تم حل هذا الأمر ، فلن يساعد وضعك ، نظرًا لأنك تعمل على توزيع لم نعد ندعمه (centos 6) ، وعلى نواة مخصصة (يتم شحن CentOS 6 مع 2.6.x). لن يتم حل هذه المشكلة في Docker 1.7 ، لأننا لا ندعم تغييرات المنفذ

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

بصرف النظر عن هذا ، هل هناك أي طريقة لتحديد ما إذا كان Docker معلقًا ولم يعد ينشئ مثيلات؟ إذا كانت الإجابة بنعم ، فيمكنني أتمتة على الأقل لإعادة تشغيل البرنامج الخفي ومتابعة العملية.

نرى المشكلة أيضًا في التكوين التالي:

docker 1.8.3 و coreos 835.10

يتوقف عامل الميناء PS على معدلات التمزق العالية. يمكنك تشغيله بنسبة 100٪ عن طريق إنشاء 200 حاوية أو أكثر بأسرع ما يمكن (يقوم Kubernetes بذلك).

كذلك هنا
repro:

A_LOT=300 # whatever
for i in `seq 1 $A_LOT`; 
  do docker run --rm alpine sh -c "echo $i; sleep 30" & 
done
sleep 5   # give it some time to start spawning containers
docker ps # hangs

core@pph-01 ~ $ docker version
Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   cedd534-dirty
 Built:        Tue Feb  2 13:28:10 UTC 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   cedd534-dirty
 Built:        Tue Feb  2 13:28:10 UTC 2016
 OS/Arch:      linux/amd64

Containers: 291
Images: 14
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.2-coreos-r2
Operating System: CoreOS 835.12.0
CPUs: 2
Total Memory: 1.958 GiB
Name: pph-01
ID: P4FX:IMCD:KF5R:MG3Y:XECP:JPKO:IRWM:3MGK:IAIW:UG5S:6KCR:IK2J
Username: pmoust
Registry: https://index.docker.io/v1/

للتسجيل ، جربت البرنامج النصي bash أعلاه لمحاولة إعادة إنتاج المشكلة على الكمبيوتر المحمول الخاص بي ، ولكن لم يحدث شيء سيئ ، كل شيء كان جيدًا. أقوم بتشغيل Ubuntu 15.10:

$ docker version
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   a34a1d5
 Built:        Fri Nov 20 13:20:08 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   a34a1d5
 Built:        Fri Nov 20 13:20:08 UTC 2015
 OS/Arch:      linux/amd64

$ docker info
Containers: 1294
Images: 1231
Server Version: 1.9.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 3823
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.0-27-generic
Operating System: Ubuntu 15.10
CPUs: 8
Total Memory: 5.809 GiB
Name: pochama
ID: 6VMD:Z57I:QDFF:TBSU:FNSH:Y433:6KDS:2AXU:CVMH:JUKU:TVQQ:7UMR
Username: tomfotherby
Registry: https://index.docker.io/v1/
WARNING: No swap limit support

لقد رأينا حالات متعددة لهذه المشكلة على Docker 1.8.3 / CentOS 7. نحن نستخدم kubernetes الذي يمكنه إنشاء عدد كبير من الحاويات. في بعض الأحيان ، سيصبح برنامج Docker daemon الخاص بنا غير مستجيب (توقف docker ps لمدة> 30 دقيقة) وستعمل إعادة تشغيل البرنامج الخفي فقط على حل المشكلة.

ومع ذلك ، لا يمكنني إعادة إظهار المشكلة باستخدام البرنامج النصي

Containers: 117
Images: 105
Storage Driver: devicemapper
 Pool Name: docker-docker--pool
 Pool Blocksize: 524.3 kB
 Backing Filesystem: xfs
 Data file: 
 Metadata file: 
 Data Space Used: 5.559 GB
 Data Space Total: 21.45 GB
 Data Space Available: 15.89 GB
 Metadata Space Used: 7.234 MB
 Metadata Space Total: 54.53 MB
 Metadata Space Available: 47.29 MB
 Udev Sync Supported: true
 Deferred Removal Enabled: true
 Library Version: 1.02.107-RHEL7 (2015-10-14)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.0-327.4.5.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 2
Total Memory: 3.451 GiB
Name: server
ID: MK35:YN3L:KULL:C4YU:IOWO:6OK2:FHLO:WIYE:CBVE:MZBL:KG3T:OV5T
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:        Mon Oct 12 06:06:01 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:        Mon Oct 12 06:06:01 UTC 2015
 OS/Arch:      linux/amd64

فيtomfotherby حالة ولكandrewmichaelsmith برنامج تشغيل التخزين غير aufs / devicemapper-XFS على التوالي.
يمكنني إعادة إنتاجه باستمرار عندما يكون برنامج تشغيل التخزين متراكبًا

يمكنني تكرار التعليق باستخدام البرنامج النصي بواسطة

Containers: 227
Images: 1
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.2-coreos-r2
Operating System: CoreOS 835.12.0
CPUs: 2
Total Memory: 3.864 GiB
Name: core-01
ID: WIYE:CGI3:2C32:LURO:MNHU:YQXU:NEU4:LPZG:YJM5:ZN3S:BBPF:3SXM

FWIW نعتقد أننا ربما نكون قد علقنا هذا على خطأ نواة devicemapper هذا: https://bugzilla.redhat.com/show_bug.cgi؟id=1292481

andrewmichaelsmith هل AWS AMI متاحًا به التصحيح؟

pmoust yum update على صناديق CentOS 7 AWS الخاصة بنا قام بسحب النواة الجديدة من تقرير الخطأ هذا (kernel-3.10.0-327.10.1.el7).

تحرير: على الرغم من أنك إذا كنت تستخدم تراكبات لا أعتقد أن هذا مناسب لك؟

+1 في هذه المسألة. أواجه هذه المشكلة مع Docker 1.10.1 على kernel 4.4.1-coreos على CoreOS Alpha
970.1.0 على AWS. يتسبب هذا في عدم استقرار خطير في مجموعة kubernetes وفريقي يفكر في إسقاط عمال الرصيف تمامًا.

هل هناك أي تحقيق نشط في هذه القضية؟

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

andrewmichaelsmith شكرا على الرد. هل هناك أي إرشادات حول كيفية الوصول إلى جوهر المشكلة؟ وضع استدعاء docker ps يعطي هذا:

read(5, 0xc20807d000, 4096) = -1 EAGAIN (Resource temporarily unavailable) write(5, "GET /v1.22/containers/json HTTP/"..., 109) = 109 futex(0x1fe97a0, FUTEX_WAKE, 1) = 1 futex(0x1fe9720, FUTEX_WAKE, 1) = 1 epoll_wait(4, {}, 128, 0) = 0 futex(0x1fea698, FUTEX_WAIT, 0, NULL

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

حاول andrewmichaelsmith باستخدام نواة مصححة

ها هي النتائج https://github.com/coreos/bugs/issues/1117#issuecomment -191190839

pmoust شكرا على التحديث.

andrewmichaelsmithpmoust هل لديك أي أفكار على ما يمكننا القيام به بعد ذلك لمزيد من التحقيق؟ يعد إصلاح هذا أمرًا بالغ الأهمية لفريقنا للمضي قدمًا في مجموعة kubernetes القائمة على عامل الإرساء.

gopinatht أنا لا أعمل في

أنا لست واضحًا حتى ما هو برنامج تشغيل التخزين الذي تستخدمه؟ للتكرار: لقد وجدنا مشكلة حيث يتوقف عامل الإرساء تمامًا عند استخدام برنامج تشغيل تخزين devicemapper. أدت ترقية kernel إلى kernel-3.10.0-327.10.1.el7 إلى حل هذه المشكلة. لا يمكنني إضافة المزيد إلى هذا.

إذا كنت لا تستخدم devicemapper كسائق تخزين عامل الإرساء ، فربما لا تعني نتائجي الكثير بالنسبة لك.

andrewmichaelsmith اعتذر إذا بدا لي أني أشير إلى أنك بحاجة إلى فعل شيء حيال هذا.

كنت أبحث فقط عن اتجاه التحقيق حيث من الواضح أنني ضائعة هنا. شكرا لمساعدتك حتى الآن على أي حال.

لقد حصلنا للتو على هذا على Ubuntu مع إصدار أحدث من Kernel 3.13.0-83-generic . يبدو أن كل عملية أخرى على ما يرام - المشكلات الوحيدة تتعلق بـ docker ps وبعضها عشوائي docker inspect

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

Containers: 51
 Running: 48
 Paused: 0
 Stopped: 3
Images: 92
Server Version: 1.10.3
Storage Driver: devicemapper
 Pool Name: docker-data-tpool
 Pool Blocksize: 65.54 kB
 Base Device Size: 5.369 GB
 Backing Filesystem: ext4
 Data file:
 Metadata file:
 Data Space Used: 19.14 GB
 Data Space Total: 102 GB
 Data Space Available: 82.86 GB
 Metadata Space Used: 33.28 MB
 Metadata Space Total: 5.369 GB
 Metadata Space Available: 5.335 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Library Version: 1.02.77 (2012-10-15)
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: host bridge null
Kernel Version: 3.13.0-83-generic
Operating System: Ubuntu 14.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 29.96 GiB
Name: apocalypse.servers.lair.io
ID: Q444:V3WX:RIQJ:5B3T:SYFQ:H2TR:SPVF:U6YE:XNDX:HV2Z:CS7F:DEJJ
WARNING: No swap limit support

strace ذيل:

futex(0x20844d0, FUTEX_WAIT, 0, NULL)   = 0
futex(0xc82002ea10, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_MONOTONIC, {216144, 494093555}) = 0
clock_gettime(CLOCK_MONOTONIC, {216144, 506740959}) = 0
futex(0xc82002ea10, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_MONOTONIC, {216144, 506835134}) = 0
clock_gettime(CLOCK_MONOTONIC, {216144, 506958105}) = 0
futex(0x20844d0, FUTEX_WAIT, 0

أيضًا ، بعد مرور بعض الوقت - ربما بضع دقائق - حصلت على الناتج التالي في الدعامة المحجوبة ، بينما لم تنتهِ أبدًا أيضًا:

futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0x20844d0, FUTEX_WAIT, 0, NULL

بعد الانتظار لبعض الوقت ، نفس كتل futex ، ولكن هذه المرة أيضًا "خطأ غير متوفر مؤقتًا في المورد":

futex(0x20844d0, FUTEX_WAIT, 0, NULL)   = 0
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_MONOTONIC, {216624, 607690506}) = 0
clock_gettime(CLOCK_MONOTONIC, {216624, 607853434}) = 0
futex(0x2083970, FUTEX_WAIT, 0, {0, 100000}) = -1 EAGAIN (Resource temporarily unavailable)
epoll_wait(5, {}, 128, 0)               = 0
clock_gettime(CLOCK_MONOTONIC, {216624, 608219882}) = 0
futex(0x2083980, FUTEX_WAKE, 1)         = 1
futex(0xc820574110, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_MONOTONIC, {216624, 608587202}) = 0
clock_gettime(CLOCK_MONOTONIC, {216624, 609140069}) = 0
clock_gettime(CLOCK_MONOTONIC, {216624, 609185048}) = 0
clock_gettime(CLOCK_MONOTONIC, {216624, 609272020}) = 0
futex(0xc82002ea10, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_MONOTONIC, {216624, 616982914}) = 0
sched_yield()                           = 0
clock_gettime(CLOCK_MONOTONIC, {216624, 626726774}) = 0
futex(0x20844d0, FUTEX_WAIT, 0, NULL)   = 0
futex(0x2083970, FUTEX_WAKE, 1)         = 1
futex(0x20838c0, FUTEX_WAKE, 1)         = 1
sched_yield()                           = 0
futex(0x20838c0, FUTEX_WAIT, 2, NULL)   = 0
futex(0x20838c0, FUTEX_WAKE, 1)         = 0
futex(0x20844d0, FUTEX_WAIT, 0, NULL

لاحظ أنه في جميع الأوقات ، تم حظر الدعامة على نفس futex .

akalipetis هل يمكنك إرسال SIGUSR1 إلى العملية وسحب تتبع المكدس الكامل من سجلات البرنامج الخفي من فضلك؟

سأفعل هذا بمجرد أن أواجه هذا مرة أخرى @ cpuguy83 - آسف ولكن لم أكن على علم بذلك ...

(لسوء الحظ) حدث ذلك مرة أخرى ، يمكنك العثور على تتبع التراص الكامل في الملف المرفق أدناه:

stacktrace.txt

اسمحوا لي أن أعرف إذا كنت ترغب في أي شيء آخر من جانبي.

/ cc @ cpuguy83

مقدر جداakalipetis!

لا توجد مشكلة @ cpuguy83 - أخبرني إذا كنت ترغب في أي بيانات أخرى ، أو حتى إذا كنت ترغب في الحصول على أسطر مكدس من الأكشاك المستقبلية.

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

نظرًا لأننا قمنا بالتحديث إلى 1.11.0 قيد التشغيل rspec لاختبارات صورة docker (~ 10 حاويات متوازية تجري هذه الاختبارات على جهاز 4 وحدات المعالجة المركزية) تتجمد أحيانًا وتفشل مع انتهاء المهلة. يتجمد Docker تمامًا ولا يستجيب (على سبيل المثال ، docker ps ). هذا يحدث على vserver مع Debian strech (btrfs) ومع (المتشرد) Parallels VM Ubuntu 14.04 (backported kernel 3.19.0-31-generic، ext4).

تم مسح نظام ملفات /var/lib/docker على كلا الخادمين (تم إعادة إنشاء btrfs) بعد التجميد الأول. يحدث التجميد بشكل عشوائي عند إجراء هذه الاختبارات.

تتبع المكدس مرفق من كلا الخادمين:
عامل ميناء-log.zip

من docker-containerd و docker daemons :

# strace -p 21979 -p 22536
Process 21979 attached
Process 22536 attached
[pid 22536] futex(0x219bd90, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 21979] futex(0xf9b170, FUTEX_WAIT, 0, NULL

معلومات Docker (Debian strech)

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1096
Server Version: 1.11.0
Storage Driver: btrfs
 Build Version: Btrfs v4.4
 Library Version: 101
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge null
Kernel Version: 4.4.0-1-amd64
Operating System: Debian GNU/Linux stretch/sid
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 11.74 GiB
Name: slave.webdevops.io
ID: WU2P:YOYC:VP2F:N6DE:BINB:B6YO:2HJO:JKZA:HTP3:SIDA:QOJZ:PJ2E
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Username: webdevopsslave
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

معلومات Docker (Ubuntu 14.04 with backported kernel)

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
root@DEV-VM:/var/lib/docker# docker info
Containers: 11
 Running: 1
 Paused: 0
 Stopped: 10
Images: 877
Server Version: 1.11.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 400
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 3.19.0-31-generic
Operating System: Ubuntu 14.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 3.282 GiB
Name: DEV-VM
ID: KCQP:OGCT:3MLX:TAQD:2XG6:HBG2:DPOM:GJXY:NDMK:BXCK:QEIT:D6KM
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/

إصدار Docker (Debian strech)

Client:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 18:22:26 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:22:26 2016
 OS/Arch:      linux/amd64

إصدار Docker (Ubuntu 14.04 with backported kernel)

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

mblaschke ، تريد استخدام -f للتثبيت في برامج golang afaik.

يمكنني تأكيد هذا الخطأ في Ubuntu 14.04 ولكني لست متأكدًا مما إذا كان هذا الخطأ هو بالفعل مشكلة امتداد Debian مع 4.4 kernel. لا تزال تحاول الحصول على مزيد من المعلومات.

كانت مشكلة امتداد دبيان مع Docker 1.10.3 هي الحد الأقصى لعملية systemd (كان 512 ، وتم رفعه إلى 8192) وتجري الآن اختبارات حاوية Docker دون مشاكل. 1.11.0 لا يزال لا يعمل ولا تزال اختبارات rspec متجمدة ولكن docker ps لا يزال مستجيبًا على Debian Stretch مع 4.4 kernel لذا أعتقد أنها مشكلة أخرى.

إنشاء إصدار جديد رقم 22124 لتتبع التقرير من mblaschke والذي قد يكون شيئًا جديدًا.

كما أواجه هذا على ما أعتقد

$ uname -a
Linux ip-10-15-42-103.ec2.internal 4.4.6-coreos #2 SMP Sat Mar 26 03:25:31 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz GenuineIntel GNU/Linux

$ docker version
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.5.3
 Git commit:   9894698
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.5.3
 Git commit:   9894698
 Built:
 OS/Arch:      linux/amd64

$ docker info
Containers: 198
Images: 196
Server Version: 1.9.1
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: journald
Kernel Version: 4.4.6-coreos
Operating System: CoreOS 991.2.0 (Coeur Rouge)
CPUs: 2
Total Memory: 3.862 GiB

$ sudo strace -q -y -v -f docker ps
<snip>
[pid 26889] connect(5<socket:[18806726]>, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, 23) = 0
[pid 26889] clock_gettime(CLOCK_REALTIME, {1462217998, 860739240}) = 0
[pid 26889] epoll_ctl(4<anon_inode:[eventpoll]>, EPOLL_CTL_ADD, 5<socket:[18806726]>, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=914977888, u64=140334676407392}}) = 0
[pid 26889] getsockname(5<socket:[18806726]>, {sa_family=AF_LOCAL, NULL}, [2]) = 0
[pid 26889] getpeername(5<socket:[18806726]>, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, [23]) = 0
[pid 26889] read(5<socket:[18806726]>,  <unfinished ...>
[pid 26893] <... futex resumed> )       = 1
[pid 26889] <... read resumed> 0xc820015000, 4096) = -1 EAGAIN (Resource temporarily unavailable)
[pid 26893] futex(0xc8200e9790, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 26891] futex(0xc820026a10, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily unavailable)
[pid 26891] epoll_wait(4<anon_inode:[eventpoll]>, {{EPOLLOUT, {u32=914978080, u64=140334676407584}}, {EPOLLOUT, {u32=914977888, u64=140334676407392}}}, 128, 0) = 2
[pid 26891] epoll_wait(4<anon_inode:[eventpoll]>,  <unfinished ...>
[pid 26889] write(5<socket:[18806726]>, "GET /v1.21/containers/json HTTP/"..., 88 <unfinished ...>
[pid 26890] <... select resumed> )      = 0 (Timeout)
[pid 26889] <... write resumed> )       = 88
[pid 26891] <... epoll_wait resumed> {{EPOLLOUT, {u32=914977888, u64=140334676407392}}}, 128, -1) = 1
[pid 26891] epoll_wait(4<anon_inode:[eventpoll]>,  <unfinished ...>
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 935071149}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 861179188}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 935216184}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 861327424}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 935376601}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 861479813}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 935543531}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 861646718}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 935709999}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 861817062}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 935872149}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 861975102}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 936046201}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 862149543}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 936215534}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 862318597}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 936384887}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 862488231}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 936547503}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 862650775}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 936708047}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 862810981}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 936875834}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 862978790}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 937049520}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 863161620}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 937216897}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 863319694}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 937382999}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 863485851}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 937549477}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 863652283}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 937722463}) = 0
[pid 26890] clock_gettime(CLOCK_REALTIME, {1462217998, 863833602}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20}) = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 937888537}) = 0
[pid 26889] futex(0xc8200e9790, FUTEX_WAKE, 1 <unfinished ...>
[pid 26890] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid 26889] <... futex resumed> )       = 1
[pid 26893] <... futex resumed> )       = 0
[pid 26890] <... clock_gettime resumed> {1462217998, 864010029}) = 0
[pid 26890] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid 26889] futex(0x1df2f50, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 26893] futex(0xc8200e9790, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 26890] <... select resumed> )      = 0 (Timeout)
[pid 26890] clock_gettime(CLOCK_MONOTONIC, {1194110, 938059687}) = 0
[pid 26890] futex(0x1df2400, FUTEX_WAIT, 0, {60, 0}

mwhooker لسوء الحظ ، لن تساعد دعامة عميل عامل الإرساء كثيرًا نظرًا لأننا نحتاج إلى رؤية ما يحدث في البرنامج الخفي.

الرجاء استخدام SIGUSR1 على البرنامج الخفي المتوقف لجعله يبصق تتبع المكدس إلى سجلاته.

هذا هو إخراج sigusr1 الخاص بي https://gist.github.com/mwhooker/6858c0d0c123e214ef69d0a4bff2d7cc (cc @ cpuguy83)

هذا تفريغ sigusr1 آخر لخفي عامل عامل ميناء عالق

https://gist.github.com/mwhooker/e837f08370145d183e661c03a5b9d07e

يعثر strace مرة أخرى على البرنامج الخفي في FUTEX_WAIT

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

ping @ cpuguy83 ^ ^

لدي نفس المشكلة في 1.11.1 (4.2.5-300.fc23) ، Overlay / EXT4. يحدث ذلك عندما أقوم بتشغيل عامل من الكرفس ، وأقوم بتحميله بالوظائف ثم أحاول الحصول على stop .

لا يمكنني بعد ذلك تنفيذ أي شيء بداخله:
rpc error: code = 2 desc = "oci runtime error: exec failed: exit status 1"

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

تعديل:
لم يُقتل الكرفس تمامًا ، فهناك عملية عالقة في D ، لذلك أعتقد أن إعادة التشغيل هو الخيار الوحيد.

يرجى الاطلاع على https://github.com/docker/docker/issues/20401#issuecomment -231337800

واجهت نفس المشكلة تحت حمولة عالية (إنشاء / حذف الحاويات بمعدل مرتفع)

• CoreOS 1068.8.0
• Docker 1.10.3.0 تحديث
• uname -a:

Linux coreos_k8s_28 4.6.3-coreos #2 SMP Mon Jul 18 06:10:39 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz GenuineIntel GNU/Linux

• kubernetes 1.2.0

إليكم جوهر سجلات تصحيح أخطاء عامل الإرساء (أرسلت SIGUSR1 إلى برنامج عامل الإرساء الخفي): https://gist.github.com/ntquyen/409376bc0d8418a31023c1546241e190

كـ ntquyen . نفس إصدار os / kernel / docker.

لا يزال Repro قائمًا https://github.com/docker/docker/issues/13885#issuecomment -181811082

بالنسبة لحالتي ، قد يكون ذلك بسبب أن الأجهزة كانت تعمل بأكثر من 90٪ من مساحة القرص المستخدمة. لقد خصصت مساحة أكبر على القرص لهم وهم يعملون بشكل مستقر الآن ، حتى مع وجود حمل كبير.

mwhooker ، يبدو أنه تم تعليق البرنامج الخفي في مكالمة netlink لحذف واجهة.
ما هي خيارات البرنامج الخفي التي قمت بإعدادها؟

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

النظر في أشياء مختلفة يمكننا القيام بها للتخفيف من هذه الأنواع من المشكلات.

pmoust هل يمكنك توفير تتبع مكدس من البرنامج الخفي؟ (أرسل SIGUSR1 إلى برنامج خفي عالق وجمع التتبع من سجلات البرنامج الخفي)
أيضًا الخيارات التي بدأت بها البرنامج الخفي.

شكر!

ntquyen ، أعتقد أن المشكلة التي تواجهها مرتبطة بـ # 22732 (على الرغم من اختلافها قليلاً ، لا تزال تتمحور حول حذف الصورة) والتي تم إصلاحها في 1.11.2
هل واجهت المشكلة مرة واحدة فقط؟

@ cpuguy83 شكرًا على عودتك إلي. إليكم كيفية تشغيل البرنامج الخفي

/usr/bin/docker daemon --icc=false --storage-driver=overlay --log-driver=journald --host=fd://

لست متأكدًا من أنه مرتبط ولكننا لاحظنا أيضًا مجموعة من هذه الرسائل في سجلاتنا

Jul 19 10:22:55 ip-10-0-37-191.ec2.internal systemd-networkd[852]: veth0adae8a: Removing non-existent address: fe80::e855:98ff:fe3f:8b2c/64 (valid forever)

(تحرير: أيضا هؤلاء)

[19409.536106] unregister_netdevice: waiting for veth2304bd1 to become free. Usage count = 1

mwhooker ، ربما تكون الرسالة السفلية هنا عالقة ، لكنني مندهش من حصولك على هذا بدون استخدام --userland-proxy=false

@ cpuguy83 مثير للاهتمام ، لقد ذكرت أنه يتم تشغيل hyperkube باستخدام --proxy-mode=userspace . هل من الممكن أن يكون سبب ذلك؟

mwhooker بناءً على وصف العلم ، لا يبدو الأمر كذلك.
بشكل أساسي ، يتيح --userland-proxy=false وضع دبوس الشعر على واجهة جسر الحاوية ، والذي يبدو أنه يؤدي إلى بعض الحالات في النواة حيث عندما نضيف / نزيل الكثير من الحاويات (أو نقوم بمجموعة بالتوازي) ، فإنه يتسبب في تجميد سيء جدًا (ورسالة الخطأ التي تراها).

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

@ cpuguy83 هذا هو أمر عامل

docker daemon --host=fd:// --icc=false --storage-driver=overlay --log-driver=journald --exec-opt native.cgroupdriver=systemd --bip=10.2.122.1/24 --mtu=8951 --ip-masq=true --selinux-enable

وأستطيع أن أرى أن واجهات veth هذه في وضع دبوس الشعر

cat /sys/devices/virtual/net/docker0/brif/veth*/hairpin_mode
1
1

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

(fwiw نحن نستخدم بروكسي مساحة المستخدمين على kube-proxy بسبب التفاعل مع الفانيلا https://github.com/kubernetes/kubernetes/issues/20391)

@ cpuguy83 لسوء الحظ ، أنا أستخدم

كذلك هنا.

• عامل ميناء: 1.12
• النواة: 4.4.3
• Distro: أوبونتو

الشيطان:

    # strace -q -y -v -p `pidof dockerd`
    futex(0x2a69be8, FUTEX_WAIT, 0, NULL
    futex(0xc820e1b508, FUTEX_WAKE, 1)      = 1
    futex(0x2a69be8, FUTEX_WAIT, 0, NULL)   = 0
    futex(0xc8224b0508, FUTEX_WAKE, 1)      = 1
    futex(0x2a69be8, FUTEX_WAIT, 0, NULL)   = 0
    futex(0x2a69be8, FUTEX_WAIT, 0, NULL

عميل:

    # strace docker ps
    execve("/usr/bin/docker", ["docker", "ps"], [/* 24 vars */]) = 0
    brk(0)                                  = 0x2584000
    ...
    stat("/root/.docker/config.json", {st_mode=S_IFREG|0600, st_size=91, ...}) = 0
    openat(AT_FDCWD, "/root/.docker/config.json", O_RDONLY|O_CLOEXEC) = 3
    read(3, "{\n\t\"auths\": {\n\t\t\"https://quay.io"..., 512) = 91
    close(3)                                = 0
    ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
    ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
    futex(0xc820068108, FUTEX_WAKE, 1)      = 1
    futex(0xc820068108, FUTEX_WAKE, 1)      = 1
    socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
    setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
    connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, 23) = 0
    epoll_create1(EPOLL_CLOEXEC)            = 4
    epoll_ctl(4, EPOLL_CTL_ADD, 3, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=3136698616, u64=140182279305464}}) = 0
    getsockname(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0
    getpeername(3, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, [23]) = 0
    futex(0xc820032d08, FUTEX_WAKE, 1)      = 1
    read(3, 0xc820356000, 4096)             = -1 EAGAIN (Resource temporarily unavailable)
    write(3, "GET /v1.24/containers/json HTTP/"..., 95) = 95
    futex(0x132aca8, FUTEX_WAIT, 0, NULL

لا يزال يحدث هنا على دبيان عند إجراء اختبارات rspec:

النواة: 4.4.0-28-عام
عامل ميناء: 1.12.2-0 ~ xenial

الحل الحالي هو العودة إلى Docker 1.10.3-0 ~ وهو آخر نسخة مستقرة.

mblaschkeBregor يمكنك بعد تتبع مكدس الذاكرة المؤقتة من فضلك؟

لقد كان هذا يحدث في بيئتنا منذ فترة الآن: [

$ docker info
Containers: 20
 Running: 6
 Paused: 0
 Stopped: 14
Images: 57
Server Version: 1.11.1
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge null host
Kernel Version: 3.18.27
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: x86_64
CPUs: 24
Total Memory: 125.8 GiB
Name: appdocker414-sjc1
ID: ZTWC:53NH:VKUZ:5FZK:SLZN:YPI4:ICK2:W7NF:UIGD:P2NQ:RHUD:PS6Y
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support

نواة: 3.18.27

Stackstrace: https://gist.github.com/dmyerscough/6948218a228ff69dd6e309f8de0f0261

dmyerscough يبدو أن هذا https://github.com/docker/docker/issues/22732 . ثابت في 1.11.2 و 1.12

تشغيل حاوية بسيطة بـ docker run --rm كل دقيقة وتوقف خدمة Docker بين الحين والآخر حتى يتم إعادة تشغيلها.

docker -D info
Containers: 6
 Running: 2
 Paused: 0
 Stopped: 4
Images: 6
Server Version: 1.11.2
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge null
Kernel Version: 4.7.3-coreos-r2
Operating System: CoreOS 1185.3.0 (MoreOS)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 7.8 GiB
Name: <hostname>
ID: GFHQ:Y6IV:XCQI:Y2NA:PCQN:DEII:OSPZ:LENL:OCFU:6CBI:MDFV:EMD7
Docker Root Dir: /var/lib/docker
Debug mode (client): true
Debug mode (server): false
Username: <username>
Registry: https://index.docker.io/v1/

آخر رسالة قبل تعليقها:

Nov 04 16:42:01 dockerd[1447]: time="2016-11-04T16:42:01Z" level=error msg="containerd: deleting container" error="wait: no child processes"

@ Liquid-sky هل لديك المزيد من المعلومات ، ربما تظهر سجلات البرنامج الخفي أي شيء مفيد ، أو Stackstrace؟ لاحظ أيضًا أنه ليس لدينا حزم رسمية لـ CoreOS ؛ نظرًا لأنهم يوزعون حزمة / تهيئة معدلة ، فقد يكون من المفيد الإبلاغ هناك.

thaJeztah لسوء الحظ ، تم تدوير سجل دفتر اليومية منذ آخر عملية تسجيل ، عندما أقوم بتتبعها ، أرى أنها معلقة على قفل كائن المزامنة.

$ ps -ef | grep -w 148[9] | head -1
root      1489     1  0 Nov02 ?        00:20:35 docker daemon --host=fd:// --insecure-registry=<registry_address> --selinux-enabled

sudo strace -e verbose=all -v -p 1489
Process 1489 attached
futex(0x22509c8, FUTEX_WAIT, 0, NULL

$ sudo strace docker ps
.....
clock_gettime(CLOCK_REALTIME, {1478601605, 8732879}) = 0
clock_gettime(CLOCK_REALTIME, {1478601605, 9085011}) = 0
clock_gettime(CLOCK_REALTIME, {1478601605, 9242006}) = 0
socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
connect(3, {sa_family=AF_LOCAL, sun_path="/run/systemd/journal/socket"}, 30) = 0
epoll_create1(EPOLL_CLOEXEC)            = 4
epoll_ctl(4, EPOLL_CTL_ADD, 3, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=3317119944, u64=140066495609800}}) = 0
getsockname(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0
getpeername(3, {sa_family=AF_LOCAL, sun_path="/run/systemd/journal/socket"}, [30]) = 0
stat("/root/.docker/config.json", 0xc8203b6fa8) = -1 ENOENT (No such file or directory)
stat("/root/.dockercfg", 0xc8203b7078)  = -1 ENOENT (No such file or directory)
stat("/bin/docker-credential-secretservice", 0xc8203b7148) = -1 ENOENT (No such file or directory)
stat("/sbin/docker-credential-secretservice", 0xc8203b7218) = -1 ENOENT (No such file or directory)
stat("/usr/bin/docker-credential-secretservice", 0xc8203b72e8) = -1 ENOENT (No such file or directory)
stat("/usr/sbin/docker-credential-secretservice", 0xc8203b73b8) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/docker-credential-secretservice", 0xc8203b7488) = -1 ENOENT (No such file or directory)
stat("/usr/local/sbin/docker-credential-secretservice", 0xc8203b7558) = -1 ENOENT (No such file or directory)
stat("/opt/bin/docker-credential-secretservice", 0xc8203b7628) = -1 ENOENT (No such file or directory)
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
futex(0xc8202c9108, FUTEX_WAKE, 1)      = 1
clock_gettime(CLOCK_REALTIME, {1478601605, 11810493}) = 0
clock_gettime(CLOCK_REALTIME, {1478601605, 11888495}) = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 5
setsockopt(5, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
connect(5, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, 23) = 0
clock_gettime(CLOCK_REALTIME, {1478601605, 12378242}) = 0
epoll_ctl(4, EPOLL_CTL_ADD, 5, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=3317119752, u64=140066495609608}}) = 0
getsockname(5, {sa_family=AF_LOCAL, NULL}, [2]) = 0
getpeername(5, {sa_family=AF_LOCAL, sun_path="/var/run/docker.sock"}, [23]) = 0
futex(0xc820026d08, FUTEX_WAKE, 1)      = 1
read(5, 0xc8203d6000, 4096)             = -1 EAGAIN (Resource temporarily unavailable)
write(5, "GET /v1.23/containers/json HTTP/"..., 89) = 89
futex(0xc820026d08, FUTEX_WAKE, 1)      = 1
futex(0x22509c8, FUTEX_WAIT, 0, NULL

وكذلك تفعل كل خدمة containerd :

ps -ef | grep container[d]
root      1513  1489  0 Nov02 ?        00:00:53 containerd -l /var/run/docker/libcontainerd/docker-containerd.sock --runtime runc --start-timeout 2m
root      2774  1513  0 Nov02 ?        00:00:00 containerd-shim a90d4642fd88ab38c66a733e2cef8f427533e736d14d48743d42f55dec62447f /var/run/docker/libcontainerd/a90d4642fd88ab38c66a733e2cef8f427533e736d14d48743d42f55dec62447f runc
root      3946  1513  0 Nov02 ?        00:00:00 containerd-shim c8903c4a137fbb297efc3fcf2c69d746e94431f22c7fdf1a46ff7c69d04ffb0d /var/run/docker/libcontainerd/c8903c4a137fbb297efc3fcf2c69d746e94431f22c7fdf1a46ff7c69d04ffb0d runc
root      4783  1513  0 Nov02 ?        00:03:36 containerd-shim d8c2203adfc26f7d11a62d9d90ddf97f04c458f72855ee1987ed1af911a2ab55 /var/run/docker/libcontainerd/d8c2203adfc26f7d11a62d9d90ddf97f04c458f72855ee1987ed1af911a2ab55 runc
root     16684  1513  0 Nov02 ?        00:00:00 containerd-shim 4d62424ca8cceb29c877bf129cd46341a53e191c9858b93aca3d5cbcfaaa1876 /var/run/docker/libcontainerd/4d62424ca8cceb29c877bf129cd46341a53e191c9858b93aca3d5cbcfaaa1876 runc
root     16732  1513  0 Nov02 ?        00:03:24 containerd-shim 2f8e2a858306322c10aa7823c92f22133f1c5e5f267ce61e542c1d8bd537b121 /var/run/docker/libcontainerd/2f8e2a858306322c10aa7823c92f22133f1c5e5f267ce61e542c1d8bd537b121 runc
root     20902  1513  0 Nov02 ?        00:00:05 containerd-shim 58572e7fab122d593bdb096b0dd33551c22ce50a0c51d6662bc0c7b3d3bf9248 /var/run/docker/libcontainerd/58572e7fab122d593bdb096b0dd33551c22ce50a0c51d6662bc0c7b3d3bf9248 runc

$ sudo strace -T -e verbose=all -v -p 1513
Process 1513 attached
futex(0x1028dc8, FUTEX_WAIT, 0, NULL

@ liquid-sky strace على رصيف عادي سيعرض أيضًا futex(0x22509c8, FUTEX_WAIT, 0, NULL الذي لا يظهر أي شيء ذي معنى على ما أعتقد ... من الأفضل إضافة -f للتثبيت لتتبع جميع الخيوط .

أعتقد أن هذا قد يكون مرتبطًا بهذه المشكلة بمعنى أننا نقوم بتشغيل الحاوية كل دقيقة بـ --rm و Docker معلق على تلك الحاوية المعينة ، لكن بعض العقد التي يكون فيها docker ps معلقًا لا تحتوي على unregistered loopback device .

فقط في حالة وجود مقتطف من strace -f من Docker daemon:

[pid  1507] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid  1766] write(23, "\2\0\0\0\0\0\0\321I1108 10:48:12.429657   "..., 217) = 217
[pid  1507] <... select resumed> )      = 0 (Timeout)
[pid  1766] futex(0xc822075d08, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid  1507] clock_gettime(CLOCK_MONOTONIC, {514752, 140621361}) = 0
[pid  1875] <... epoll_wait resumed> {{EPOLLIN|EPOLLOUT|EPOLLRDHUP, {u32=1298424080, u64=140528333381904}}}, 128, -1) = 1
[pid  1507] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1875] epoll_wait(6,  <unfinished ...>
[pid  1507] <... clock_gettime resumed> {1478602092, 431376727}) = 0
[pid  1507] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid  1514] <... read resumed> "I1108 10:48:12.431656    12 mast"..., 32768) = 1674
[pid  1507] <... select resumed> )      = 0 (Timeout)
[pid  1514] futex(0xc822075d08, FUTEX_WAKE, 1 <unfinished ...>
[pid  1507] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid  1766] <... futex resumed> )       = 0
[pid  1514] <... futex resumed> )       = 1
[pid  1766] select(0, NULL, NULL, NULL, {0, 100} <unfinished ...>
[pid  1514] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1507] <... clock_gettime resumed> {514752, 142476308}) = 0
[pid  1514] <... clock_gettime resumed> {1478602092, 432632124}) = 0
[pid  1507] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.431656   "..., 349 <unfinished ...>
[pid  1507] <... clock_gettime resumed> {1478602092, 432677401}) = 0
[pid  1514] <... write resumed> )       = 349
[pid  1507] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid  1514] clock_gettime(CLOCK_REALTIME, {1478602092, 432812895}) = 0
[pid  1766] <... select resumed> )      = 0 (Timeout)
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.431763   "..., 349 <unfinished ...>
[pid  1507] <... select resumed> )      = 0 (Timeout)
[pid  1514] <... write resumed> )       = 349
[pid  1507] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid  1514] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1507] <... clock_gettime resumed> {514752, 142831922}) = 0
[pid  1514] <... clock_gettime resumed> {1478602092, 432948135}) = 0
[pid  1507] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.431874   "..., 349 <unfinished ...>
[pid  1507] <... clock_gettime resumed> {1478602092, 432989394}) = 0
[pid  1514] <... write resumed> )       = 349
[pid  1507] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid  1766] read(44, "I1108 10:48:12.432255    12 mast"..., 32768) = 837
[pid  1514] clock_gettime(CLOCK_REALTIME, {1478602092, 433114452}) = 0
[pid  1766] read(44,  <unfinished ...>
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.431958   "..., 349) = 349
[pid  1507] <... select resumed> )      = 0 (Timeout)
[pid  1514] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1507] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid  1514] <... clock_gettime resumed> {1478602092, 433272783}) = 0
[pid  1507] <... clock_gettime resumed> {514752, 143176397}) = 0
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.432035   "..., 349 <unfinished ...>
[pid  1507] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1514] <... write resumed> )       = 349
[pid  1507] <... clock_gettime resumed> {1478602092, 433350170}) = 0
[pid  1514] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1507] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid  1514] <... clock_gettime resumed> {1478602092, 433416138}) = 0
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.432126   "..., 349) = 349
[pid  1514] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1507] <... select resumed> )      = 0 (Timeout)
[pid  1514] <... clock_gettime resumed> {1478602092, 433605782}) = 0
[pid  1507] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.432255   "..., 349 <unfinished ...>
[pid  1507] <... clock_gettime resumed> {514752, 143537029}) = 0
[pid  1514] <... write resumed> )       = 349
[pid  1507] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1514] clock_gettime(CLOCK_REALTIME, {1478602092, 433748730}) = 0
[pid  1507] <... clock_gettime resumed> {1478602092, 433752245}) = 0
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.432343   "..., 348 <unfinished ...>
[pid  1507] futex(0xc8211b2d08, FUTEX_WAKE, 1 <unfinished ...>
[pid  1514] <... write resumed> )       = 348
[pid  1507] <... futex resumed> )       = 1
[pid 10488] <... futex resumed> )       = 0
[pid 10488] write(23, "\2\0\0\0\0\0\t\317I1108 10:48:12.431656   "..., 2519 <unfinished ...>
[pid  1514] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
[pid  1507] select(0, NULL, NULL, NULL, {0, 20} <unfinished ...>
[pid 10488] <... write resumed> )       = 2519
[pid 10488] futex(0xc8211b2d08, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid  1875] <... epoll_wait resumed> {{EPOLLIN|EPOLLOUT|EPOLLRDHUP, {u32=1298424080, u64=140528333381904}}}, 128, -1) = 1
[pid  1514] <... clock_gettime resumed> {1478602092, 434094221}) = 0
[pid  1514] write(45, "{\"log\":\"I1108 10:48:12.432445   "..., 349) = 349
[pid  1514] futex(0xc820209908, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid  1507] <... select resumed> )      = 0 (Timeout)
[pid  1507] clock_gettime(CLOCK_MONOTONIC, {514752, 144370753}) = 0
[pid  1507] futex(0x224fe10, FUTEX_WAIT, 0, {60, 0} <unfinished ...>
[pid  1875] epoll_wait(6,  <unfinished ...>
[pid  1683] <... futex resumed> )       = -1 ETIMEDOUT (Connection timed out)
[pid  1683] clock_gettime(CLOCK_MONOTONIC, {514752, 292709791}) = 0
[pid  1683] futex(0x224fe10, FUTEX_WAKE, 1) = 1
[pid  1507] <... futex resumed> )       = 0

أنا أستخدم devicemapper مع الاسترجاع على centos 7.

لست متأكدًا مما حدث ، لكن dmsetup udevcookies & dmsetup udevcomplete <cookie> يناسبني.

thaJeztah هل يمكنك المساعدة في شرح ما حدث؟

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

لدي تفريغ USR1 كما طلب tonistiigi مع تعليق تحت الحمل.

$ docker info
Containers: 18
 Running: 15
 Paused: 0
 Stopped: 3
Images: 232
Server Version: 1.12.3
Storage Driver: devicemapper
 Pool Name: vg_ex-docker--pool
 Pool Blocksize: 65.54 kB
 Base Device Size: 107.4 GB
 Backing Filesystem: xfs
 Data file: 
 Metadata file: 
 Data Space Used: 132.8 GB
 Data Space Total: 805.3 GB
 Data Space Available: 672.5 GB
 Metadata Space Used: 98.46 MB
 Metadata Space Total: 4.001 GB
 Metadata Space Available: 3.903 GB
 Thin Pool Minimum Free Space: 80.53 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: true
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Library Version: 1.02.107-RHEL7 (2016-06-09)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null bridge host overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-327.36.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 56
Total Memory: 251.6 GiB
Name: server.masked.example.com
ID: Z7J7:CLEG:KZPK:TNEI:QLYL:JBTO:XNM4:NX2X:KPQC:VHPC:6SFS:G4GR
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

docker.txt

من السجل المقدم ، يبدو أنه عالق على dm_udev_wait

goroutine 2747 [syscall, 12 minutes, locked to thread]:
github.com/docker/docker/pkg/devicemapper._Cfunc_dm_udev_wait(0xc80d4d887c, 0xc800000000)
\t??:0 +0x41
github.com/docker/docker/pkg/devicemapper.dmUdevWaitFct(0xd4d887c, 0x44288e)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper_wrapper.go:222 +0x22
github.com/docker/docker/pkg/devicemapper.UdevWait(0xc821c7e8f8, 0x0, 0x0)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src
Nov 17 06:50:13 server docker: /github.com/docker/docker/pkg/devicemapper/devmapper.go:259 +0x3b
github.com/docker/docker/pkg/devicemapper.activateDevice(0xc82021a880, 0x1e, 0xc8202f0cc0, 0x57, 0x9608, 0x1900000000, 0x0, 0x0, 0x0, 0x0)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:771 +0x8b8
github.com/docker/docker/pkg/devicemapper.ActivateDevice(0xc82021a880, 0x1e, 0xc8202f0cc0, 0x57, 0x9608, 0x1900000000, 0x0, 0x0)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:732 +0x78
github.com/docker/docker/daemon/graphdriver/devmapper.(*DeviceSet).activateDeviceIfNeeded(0xc8200b6340, 0xc8208e0a40, 0xc8200b6300, 0x0, 0x0)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/deviceset.go:539 +0x58d
github.com/docker/docker/daemon/graphdriver/devmapper.(*DeviceSet).MountDevice(0xc8200b6340, 0xc820a00200, 0x40, 0xc820517ab0, 0x61, 0x0, 0x0, 0x0, 0x0)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/deviceset.go:2269 +0x2cd
github.com/docker/docker/daemon/graphdriver/devmapper.(*Driver).Get(0xc82047bf40, 0xc820a00200, 0x40, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/driver.go:185 +0x62f
github.com/docker/docker/daemon/graphdriver.(*NaiveDiffDriver).Get(0xc8201c2680, 0xc820a00200, 0x40, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
\t<autogenerated>:30 +0xa6

قضايا مماثلة # 27900 # 27543

@ AaronDMarasco-VSI هل جربت dmsetup udevcomplete_all ؟

@ coolljt0725 لا ، آسف ، بعد أن أعدت تشغيل البرنامج الخفي دون العبث به بعد الآن.

ttonistiigi ، يمكن العثور هنا على تتبع المكدس الكامل من Docker daemon بعد SIGUSR1

يبدو أن التتبع من @ liquid-sky محجوب على مقبس netlink

goroutine 13038 [syscall, 9838 minutes, locked to thread]:
syscall.Syscall6(0x2d, 0x16, 0xc820fc3000, 0x1000, 0x0, 0xc8219bc028, 0xc8219bc024, 0x0, 0x300000002, 0x66b5a6)
    /usr/lib/go1.6/src/syscall/asm_linux_amd64.s:44 +0x5
syscall.recvfrom(0x16, 0xc820fc3000, 0x1000, 0x1000, 0x0, 0xc8219bc028, 0xc8219bc024, 0x427289, 0x0, 0x0)
    /usr/lib/go1.6/src/syscall/zsyscall_linux_amd64.go:1712 +0x9e
syscall.Recvfrom(0x16, 0xc820fc3000, 0x1000, 0x1000, 0x0, 0x1000, 0x0, 0x0, 0x0, 0x0)
    /usr/lib/go1.6/src/syscall/syscall_unix.go:251 +0xb9
github.com/vishvananda/netlink/nl.(*NetlinkSocket).Receive(0xc820c6c5e0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go:341 +0xae
github.com/vishvananda/netlink/nl.(*NetlinkRequest).Execute(0xc820dded20, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/nl/nl_linux.go:228 +0x20b
github.com/vishvananda/netlink.LinkSetMasterByIndex(0
 x7f1e88c67c20, 0xc820e00630, 0x3, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go:231 +0x3b0
github.com/vishvananda/netlink.LinkSetMaster(0x7f1e88c67c20, 0xc820e00630, 0xc8219bc550, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go:205 +0xb7
github.com/docker/libnetwork/drivers/bridge.addToBridge(0xc820c78830, 0xb, 0x177bf88, 0x7, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go:782 +0x275
github.com/docker/libnetwork/drivers/bridge.(*driver).CreateEndpoint(0xc820316640, 0xc8201f6840, 0x40, 0xc821879500, 0x40, 0x7f1e88c67bd8, 0xc820f38580, 0xc821a87bf0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/docker/libnetwork/drivers/bridge/bridge.go:1004 +0x1436
github.com/docker/libnetwork.(*network).addEndpoint(0xc820f026c0, 0xc8209f2300, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/docker/libnetwork/network.go:749 +0x21b
github.com/docker/libnetwork.(*network).CreateEndpoint(0xc820f026c0, 0xc820eb1909, 0x6, 0xc8210af160, 0x4, 0x4, 0x0, 0x0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/docker/libnetwork/network.go:813 +0xaa7
github.com/docker/docker/daemon.(*Daemon).connectToNetwork(0xc82044e480, 0xc820e661c0, 0x177aea8, 0x6, 0xc820448c00, 0x0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/.gopath/src/github.com/docker/docker/daemon/container_operations.go:539 +0x39f
github.com/docker/docker/daemon.(*Daemon).allocateNetwork(0xc82044e480, 0xc820e661c0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker
 -1.11.2/.gopath/src/github.com/docker/docker/daemon/container_operations.go:401 +0x373
github.com/docker/docker/daemon.(*Daemon).initializeNetworking(0xc82044e480, 0xc820e661c0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/.gopath/src/github.com/docker/docker/daemon/container_operations.go:680 +0x459
github.com/docker/docker/daemon.(*Daemon).containerStart(0xc82044e480, 0xc820e661c0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/.gopath/src/github.com/docker/docker/daemon/start.go:125 +0x219
github.com/docker/docker/daemon.(*Daemon).ContainerStart(0xc82044e480, 0xc820ed61d7, 0x40, 0x0, 0x0, 0x0)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/.gopath/src/github.com/docker/docker/daemon/start.go:75 +0x575

cc aboch

كما اقترح آخرون ، من المحتمل أن يكون هذا أحد الآثار الجانبية لشيء سيء للغاية يحدث في النواة.
نقوم بإضافة https://github.com/docker/libnetwork/pull/1557 لمحاولة التخفيف من هذا الموقف.

ربما لدي اثنين من ثلاثة آثار مكدس أخرى مع بعض رسائل الخطأ (مأخوذة من journalctl syslog).
أنا أجري بعض اختبارات rspec / serverpec لصور عامل الإرساء وفي هذه الحالة يبدو أن عامل الإرساء لا يستجيب. الاختبار عالق لأكثر من 20 دقيقة (ستتم إعادة المحاولة 5 مرات إذا فشل).
تنتهي كل اختبارات الصور في أقل من 5 دقائق ، الاختبار قيد التشغيل الآن لمدة 30 أو 60 دقيقة على الأقل.

https://gist.github.com/mblaschke/d5d38cb34f6178e50e465c6e1f02131c

uname -a:
Linux webdevops.infogene.fr 4.4.0-47-generic # 68-Ubuntu SMP الأربعاء 26 أكتوبر 19:39:52 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux

معلومات عامل الميناء:
الحاويات: 5
الجري: 1
متوقف مؤقتًا: 0
متوقف: 4
الصور: 1208
إصدار الخادم: 1.12.3
سائق التخزين: aufs
الجذر Dir: / var / lib / docker / aufs
دعم نظام الملفات: extfs
Dirs: 449
Dirperm1 المدعومة: صحيح
برنامج تشغيل التسجيل: ملف json
برنامج تشغيل Cgroup: cgroupfs
الإضافات:
الحجم: محلي
الشبكة: تراكب مضيف جسر فارغ
سرب: غير نشط
أوقات التشغيل: runc
وقت التشغيل الافتراضي: runc
خيارات الأمان: apparmor seccomp
إصدار النواة: 4.4.0-47-generic
نظام التشغيل: Ubuntu 16.04.1 LTS
OSType: لينكس
العمارة: x86_64
وحدات المعالجة المركزية: 7
إجمالي الذاكرة: 11.73 جيجا بايت
الاسم: webdevops.infogene.fr
المعرّف: DGNM: G3MV : ZMMV: HY6K : UPLU: CMEV : VHCA: RVY3 : CRV7: FS5M: KMVQ: MQO5
Docker Root Dir: / var / lib / docker
وضع التصحيح (العميل): خطأ
وضع التصحيح (الخادم): خطأ
التسجيل: https://index.docker.io/v1/
تحذير: لا يوجد دعم لحد المبادلة
السجلات غير الآمنة:
127.0.0.0 / 8

هنا أيضًا ناتج النتيجة من serverpec:

https://gist.github.com/mblaschke/21a521367a2a2b71301607482647a748

mblaschke لقد بحثت عن docker ps أو docker exec/stop لم يتم حظرها في حالتك وكان التعليق الذي رأيته هو فقط أنك توقعت انتهاء حاوية معينة أو exec ولكن الأمر لم يحدث. ر. قد يكون هذا مرتبطًا إما بالتطبيق نفسه معلقًا على شيء ما أو بالحاوية لا يرسل إلينا أي أحداث حول الحاوية (ccmlaventure).

يجب إصلاح التحذيرات الموجودة في السجلات باستخدام https://github.com/docker/containerd/pull/351 . يجب أن تتسبب فقط في البريد العشوائي وألا تكون أي شيء خطير. نظرًا لعدم تمكين سجل تصحيح الأخطاء في السجلات ، لا يمكنني معرفة ما إذا كانت هناك أية أوامر مشبوهة تم إرسالها إلى البرنامج الخفي. لا يبدو أن هناك أي سجلات ذات معنى لدقائق قبل أن تقوم بتتبع الترتيب.

يعمل نفس الكود مع Docker 1.10.3 ، ولكن ليس بعد Docker 1.11.x. فشلت اختبارات serverpec بشكل عشوائي مع انتهاء المهلات.
لدي شعور بأن هذا يحدث في كثير من الأحيان عندما نجري الاختبارات في موازيات (على سبيل المثال ، إجراء اختبارين أو 4 اختبارات على 4 وحدات معالجة مركزية) مقارنة بالوضع التسلسلي ولكن النتيجة هي نفسها. لا يوجد تشغيل اختباري يعمل بنجاح.
مع Docker 1.11 ، كان برنامج Docker daemon بأكمله معلقًا ، منذ 1.12 Docker فقط يفشل exec أو ينفد.

mblaschke لقد

ما هو برنامج exec الذي تنفذه؟ هل تتفرع عمليات جديدة بمعرف الجلسة الخاص بها؟

نقوم بتنفيذ (docker exec) ip addr على أساس منتظم في جميع الحاويات للعثور على عناوين IP الخاصة بهم التي تم تعيينها بواسطة https://github.com/rancher/rancher ، والتي للأسف ليست جزءًا من بيانات تعريف عامل التحميل ( بعد)

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

تضمين التغريدة
نحن نستخدم serverpec / rspec للاختبار ونقوم بتنفيذ اختبارات بسيطة للغاية (فحوصات الملفات ، وفحوصات أوامر بسيطة ، وفحوصات بسيطة للتطبيق). في معظم الأحيان ، تفشل حتى عمليات التحقق من إذن الملفات البسيطة.

الاختبارات موجودة هنا (لكنها تحتاج إلى بعض إعدادات البيئة للتنفيذ):
https://github.com/webdevops/Dockerfile/tree/develop/tests/serverspec

يمكنك تجربته مع قاعدة التعليمات البرمجية الخاصة بنا:

1. make requirements لجلب كل وحدات python (pip) و ruby
2. bin/console docker:pull --threads=auto (جلب ~ 180 صورة من المحور)
3. bin/console test:serverspec --threads=auto لتشغيل جميع الاختبارات في الوضع المتوازن أو bin/console test:serverspec في الوضع التسلسلي

GameScripting أشعر بالحيرة الآن: sweat_smile:. هل تشير إلى نفس السياق الذي يتم تشغيل mblaschke منه؟

إذا لم يكن كذلك ، ما إصدار عامل الإرساء الذي تستخدمه؟

وللإجابة على سؤالك ، لا ، من غير المحتمل أن يقوم عنوان IP بفعل أي شيء كهذا.

ما الصورة التي تستخدمها؟ ما هو بالضبط أمر docker exec المستخدم؟

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

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

يبدو أن mblaschke قد وجد شيئًا حتى يتمكن من تشغيل الخطأ بشكل موثوق.

أستخدم CoreOS Stable (1185.3.0) مع Docker 1.11.2.
أدير ساعة مع docker exec في حاوية Redis الخاصة بي للتحقق من بعض المتغيرات. ما لا يقل عن يوم توقف Docker daemon.

لكنني وجدت حلاً حتى تجد حلاً. أستخدم الأداة المساعدة ctr من containerd (https://github.com/docker/containerd) لبدء عملية داخل الحاوية قيد التشغيل. يمكن استخدامه أيضًا لبدء تشغيل الحاويات وإيقافها. أعتقد أنه مدمج في عامل الإرساء 1.11.2.
لسوء الحظ ، يوجد خطأ آخر في CoreOS الذي أبلغت عنه هنا: https://github.com/docker/containerd/issues/356#event -874038823 (قاموا بإصلاحه منذ ذلك الحين) ، لذلك تحتاج إلى تنظيف / tmp بانتظام ولكن على الأقل لديه كنت أعمل لدي لمدة أسبوع في الإنتاج.

مثال Docker exec التالي:

docker exec -i container_name /bin/sh 'echo "Hello"'

يمكن ترجمتها إلى ctr:

/usr/bin/ctr --address=/run/docker/libcontainerd/docker-containerd.sock containers exec --id=${id_of_the_running_container} --pid=any_unique_process_name -a --cwd=/ /bin/sh -c 'echo "Hello"'

لذلك يمكنك ترجمة البرامج النصية مؤقتًا إلى ctr كحل بديل.

mblaschke الأوامر التي نشرتها فشلت بالنسبة لي لكنها لا تبدو وكأنها إخفاقات في عامل الإرساء. https://gist.github.com/tonistiigi/86badf5a41dff3fe53bd68d8e83e4ec4 هل يمكنك تمكين سجلات تصحيح الأخطاء. يخزن الإصدار الرئيسي أيضًا المزيد من بيانات التصحيح حول العناصر الداخلية للعفريت ويسمح بتتبع containerd بالإضافة إلى إشارات sigusr1. نظرًا لأننا نتتبع عملية متوقفة ، فقد يساعد حتى ps aux .

تضمين التغريدة
لقد نسيت القائمة السوداء لجبال الألب (مشكلات الإنشاء حاليًا) لذا يرجى تشغيل: bin/console test:serverspec --threads=auto --blacklist=:alpine

آسف :(

mblaschke ما زال لا يبدو وكأنه مشكلة عامل ميناء. إنه معلق على docker exec <id> /usr/bin/php -i . إذا تتبعت الصورة المستخدمة وبدأت في تشغيلها يدويًا ، أرى أن هذه الصورة لا تحتوي على php حقيقي مثبت:

root<strong i="8">@254424aecc57</strong>:/# php -v
HipHop VM 3.11.1 (rel)
Compiler: 3.11.1+dfsg-1ubuntu1
Repo schema: 2f678922fc70b326c82e56bedc2fc106c2faca61

ولا يدعم HipHopVM -i لكن فقط الكتل.

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

لقد بحثت في سجلات البناء ووجدت فشل اختبار واحد (مشكلة عشوائية ، وليس في اختبارات hhvm) عند استخدام 1.12.3. سنواصل التأكيد على Docker ونحاول إيجاد المشكلة.

@ coolljt0725 لقد docker ps في جلسة واحدة ، وتم تعليق sudo service docker stop أيضًا. افتتح الجلسة الثالثة:

$ sudo lvs
  LV          VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  docker-pool vg_ex  twi-aot--- 750.00g             63.49  7.88                            
$ sudo dmsetup udevcomplete_all
This operation will destroy all semaphores with keys that have a prefix 3405 (0xd4d).
Do you really want to continue? [y/n]: y
2 semaphores with keys prefixed by 3405 (0xd4d) destroyed. 0 skipped.

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

مثال على الإخراج المعلق بعد أن أجريت استدعاء dmsetup ، بدأ docker run منذ أيام:

docker run -td -v /opt/Xilinx/:/opt/Xilinx/:ro -v /opt/Modelsim/:/opt/Modelsim/:ro -v /data/jenkins_workspace_modelsim/workspace/examples_hdl/APPLICATION/bias/HDL_PLATFORM/modelsim_pf/TARGET_OS/7:/build --name jenkins-examples_hdl-APPLICATION--bias--HDL_PLATFORM--modelsim_pf--TARGET_OS--7-546 jenkins/build:v3-C7 /bin/sleep 10m
docker: An error occurred trying to connect: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/create?name=jenkins-examples_hdl-APPLICATION--bias--HDL_PLATFORM--modelsim_pf--TARGET_OS--7-546: EOF.
See 'docker run --help'.

Docker 1.11.2 معلق ، تتبع المكدس: https://gist.github.com/Calpicow/871621ba807d6eb9b18b91e8c2eb4eef

يبدو أن التتبع من Calpicow عالق في devicemapper. ولكن لا ننظر إلى حالة udev_wait. تضمين التغريدة

goroutine 488 [syscall, 10 minutes, locked to thread]:
github.com/docker/docker/pkg/devicemapper._C2func_dm_task_run(0x7fbffc010f80, 0x0, 0x0, 0x0)
    ??:0 +0x47
github.com/docker/docker/pkg/devicemapper.dmTaskRunFct(0x7fbffc010f80, 0xc800000001)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper_wrapper.go:96 +0x21
github.com/docker/docker/pkg/devicemapper.(*Task).run(0xc8200266d8, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engin
e/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:155 +0x37
github.com/docker/docker/pkg/devicemapper.SuspendDevice(0xc821b07380, 0x55, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:627 +0x99
github.com/docker/docker/pkg/devicemapper.CreateSnapDevice(0xc821013f80, 0x25, 0x1a, 0xc821b07380, 0x55, 0x17, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:759 +0x92
github.com/docker/docker/daemon/graphdriver/devmapper.(*DeviceSet).createRegisterSnapDevice(0xc8203be9c0, 0xc82184d1c0, 0x40, 0xc821a78f40, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/deviceset.go:860 +0x557
github.com/docker/docker/daemon/graphdriver/devmapper.(*DeviceSet).AddDevice(0xc8203be9c0, 0xc82184d1c0, 0x40, 0xc8219c47c0, 0x40, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/deviceset.go:1865 +0x81f
github.com/docker/docker/daemon/graphdriver/devmapper.(*Driver).Create(0xc8200ff770, 0xc82184d1c0, 0x40, 0xc8219c47c0, 0x40, 0x0, 0x0, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/driver.go:124 +0x5f
github.com/docker/docker/daemon/graphdriver.(*NaiveDiffDriver).Create(0xc820363940, 0xc82184d1c0, 0x40, 0xc8219c47c0, 0x40, 0x0, 0x0, 0x0, 0x0)
    <autogenerated>:24 +0xaa
github.com/docker/docker/layer.(*layerStore).Register(0xc820363980, 0x7fc02faa3898, 0xc821a6ae00, 0xc821ace370, 0x47, 0x0, 0x0, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/layer/layer_store.go:266 +0x382
github.com/docker/docker/distribution/xfer.(*LayerDownloadManager).makeDownloadFunc.func1.1(0xc8210cd740, 0xc8210cd680, 0x7fc02fb6b758, 0xc820f422d0, 0xc820ee15c0, 0xc820ee1680, 0xc8210cd6e0, 0xc820e8e0b0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/distribut
ion/xfer/download.go:316 +0xc01
created by github.com/docker/docker/distribution/xfer.(*LayerDownloadManager).makeDownloadFunc.func1
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/distribution/xfer/download.go:341 +0x191

Calpicow هل لديك سجل dmesg ؟ وهل يمكنك إظهار ناتج dmsetup status ؟

تم تعليق docker ps ، لكن الأوامر الأخرى مثل info / restart / images تعمل بشكل جيد.

لدي تفريغ ضخم لـ SIGUSR1 أدناه أيضًا (لم يناسب هنا). https://gist.github.com/ahmetalpbalkan/34bf40c02a78e319eaf5710acb15cf9a

• إصدار خادم عامل الإرساء: 1.11.2
• سائق التخزين: تراكب
• إصدار النواة: 4.7.3-coreos-r3
• نظام التشغيل: CoreOS 1185.5.0 (MoreOS)

يبدو أن لدي طن (مثل 700) من هذه goroutines:

...
goroutine 1149 [chan send, 1070 minutes]:
github.com/vishvananda/netlink.LinkSubscribe.func2(0xc821159d40, 0xc820fa4c60)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go:898 +0x2de
created by github.com/vishvananda/netlink.LinkSubscribe
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go:901 +0x107

goroutine 442 [chan send, 1129 minutes]:
github.com/vishvananda/netlink.LinkSubscribe.func2(0xc8211eb380, 0xc821095920)
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go:898 +0x2de
created by github.com/vishvananda/netlink.LinkSubscribe
    /build/amd64-usr/var/tmp/portage/app-emulation/docker-1.11.2-r5/work/docker-1.11.2/vendor/src/github.com/vishvananda/netlink/link_linux.go:901 +0x107
...

ahmetalpbalkan يبدو أنك محظور في انتظار مقبس netlink للعودة.
هذا خطأ في النواة ، لكن 1.12.5 يجب أن يكون على الأقل مهلة على مقبس netlink هذا.
إذا كان عليّ التخمين ، فسيكون لديك شيء في ناتجك dmesg مثل device_count = 1; waiting for <interface> to become free

@ cpuguy83 نعم لقد رأيت https://github.com/coreos/bugs/issues/254 التي بدت مشابهة لحالتي ، ومع ذلك لا أرى تلك الرسائل "المنتظرة" في النواة تسجل الشخص وأنت ذكرته.

يبدو أن 1.12.5 لم تصل إلى تيار alpha core حتى الآن. هل هناك إصدار kernel / docker يمكنني الرجوع إلى إصدار أقدم وتشغيله؟

ahmetalpbalkan Yay ، من أجل خطأ آخر في النواة.
هذا هو السبب في أننا قدمنا ​​المهلة على مقبس netlink ... في جميع الاحتمالات لن تتمكن من بدء / إيقاف أي حاويات جديدة ، ولكن على الأقل لن يتم حظر Docker.

هل تعرف بالضبط ما هو الخطأ؟ هل تم الإبلاغ عن خطأ النواة في المنبع؟ أم أن هناك نسخة kernel تم فيها إصلاح هذا الخطأ؟

يجب الإبلاغ عنGameScripting Issue لأي توزيعة تم إنتاجها فيها ، وكما ترى ، لدينا أكثر من مشكلة واحدة تسبب نفس التأثير هنا أيضًا.

هذا واحد آخر مع Docker v1.12.3

تفريغ
dmesg
dmsetup

سجل النظام ذي الصلة:

Jan  6 01:41:19 ip-100-64-32-70 kernel: INFO: task kworker/u31:1:91 blocked for more than 120 seconds.
Jan  6 01:41:19 ip-100-64-32-70 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan  6 01:41:19 ip-100-64-32-70 kernel: kworker/u31:1   D ffff880201fc98e0     0    91      2 0x00000000
Jan  6 01:41:19 ip-100-64-32-70 kernel: Workqueue: kdmremove do_deferred_remove [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: ffff88020141bcf0 0000000000000046 ffff8802044ce780 ffff88020141bfd8
Jan  6 01:41:20 ip-100-64-32-70 kernel: ffff88020141bfd8 ffff88020141bfd8 ffff8802044ce780 ffff880201fc98d8
Jan  6 01:41:20 ip-100-64-32-70 kernel: ffff880201fc98dc ffff8802044ce780 00000000ffffffff ffff880201fc98e0
Jan  6 01:41:20 ip-100-64-32-70 kernel: Call Trace:
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff8163b959>] schedule_preempt_disabled+0x29/0x70
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff81639655>] __mutex_lock_slowpath+0xc5/0x1c0
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff81638abf>] mutex_lock+0x1f/0x2f
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa0392e9d>] __dm_destroy+0xad/0x340 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa03947e3>] dm_destroy+0x13/0x20 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa0398d6d>] dm_hash_remove_all+0x6d/0x130 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa039b50a>] dm_deferred_remove+0x1a/0x20 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa0390dae>] do_deferred_remove+0xe/0x10 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff8109d5fb>] process_one_work+0x17b/0x470
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff8109e3cb>] worker_thread+0x11b/0x400
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff8109e2b0>] ? rescuer_thread+0x400/0x400
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff810a5aef>] kthread+0xcf/0xe0
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff810a5a20>] ? kthread_create_on_node+0x140/0x140
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff81645818>] ret_from_fork+0x58/0x90
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff810a5a20>] ? kthread_create_on_node+0x140/0x140
Jan  6 01:41:20 ip-100-64-32-70 kernel: INFO: task dockerd:31587 blocked for more than 120 seconds.
Jan  6 01:41:20 ip-100-64-32-70 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan  6 01:41:20 ip-100-64-32-70 kernel: dockerd         D 0000000000000000     0 31587      1 0x00000080
Jan  6 01:41:20 ip-100-64-32-70 kernel: ffff8800e768fab0 0000000000000086 ffff880034215c00 ffff8800e768ffd8
Jan  6 01:41:20 ip-100-64-32-70 kernel: ffff8800e768ffd8 ffff8800e768ffd8 ffff880034215c00 ffff8800e768fbf0
Jan  6 01:41:20 ip-100-64-32-70 kernel: ffff8800e768fbf8 7fffffffffffffff ffff880034215c00 0000000000000000
Jan  6 01:41:20 ip-100-64-32-70 kernel: Call Trace:
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff8163a879>] schedule+0x29/0x70
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff81638569>] schedule_timeout+0x209/0x2d0
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff8108e4cd>] ? mod_timer+0x11d/0x240
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff8163ac46>] wait_for_completion+0x116/0x170
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff810b8c10>] ? wake_up_state+0x20/0x20
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff810ab676>] __synchronize_srcu+0x106/0x1a0
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff810ab190>] ? call_srcu+0x70/0x70
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff81219e3f>] ? __sync_blockdev+0x1f/0x40
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff810ab72d>] synchronize_srcu+0x1d/0x20
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa039318d>] __dm_suspend+0x5d/0x220 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa0394c9a>] dm_suspend+0xca/0xf0 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa0399fe0>] ? table_load+0x380/0x380 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa039a174>] dev_suspend+0x194/0x250 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa0399fe0>] ? table_load+0x380/0x380 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa039aa25>] ctl_ioctl+0x255/0x500 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff8112482d>] ? call_rcu_sched+0x1d/0x20
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffffa039ace3>] dm_ctl_ioctl+0x13/0x20 [dm_mod]
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff811f1e75>] do_vfs_ioctl+0x2e5/0x4c0
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff8128bbee>] ? file_has_perm+0xae/0xc0
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff81640d01>] ? __do_page_fault+0xb1/0x450
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff811f20f1>] SyS_ioctl+0xa1/0xc0
Jan  6 01:41:20 ip-100-64-32-70 kernel: [<ffffffff816458c9>] system_call_fastpath+0x16/0x1b

Calpicow شكرًا ، يبدو أن جهاز devicemapper قد توقف.

github.com/docker/docker/pkg/devicemapper._C2func_dm_task_run(0x7fd3a40231b0, 0x7fd300000000, 0x0, 0x0)
    ??:0 +0x4c
github.com/docker/docker/pkg/devicemapper.dmTaskRunFct(0x7fd3a40231b0, 0xc821a91620)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper_wrapper.go:96 +0x75
github.com/docker/docker/pkg/devicemapper.(*Task).run(0xc820345838, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:155 +0x37
github.com/docker/docker/pkg/devicemapper.SuspendDevice(0xc8219c8600, 0x5a, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:648 +0x99
github.com/docker/docker/pkg/devicemapper.CreateSnapDevice(0xc821a915f0, 0x25, 0x21, 0xc8219c8600, 0x5a, 0x1f, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/pkg/devicemapper/devmapper.go:780 +0x92
github.com/docker/docker/daemon/graphdriver/devmapper.(*DeviceSet).createRegisterSnapDevice(0xc820433040, 0xc821084080, 0x40, 0xc8210842c0, 0x140000000, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/deviceset.go:861 +0x550
github.com/docker/docker/daemon/graphdriver/devmapper.(*DeviceSet).AddDevice(0xc820433040, 0xc821084080, 0x40, 0xc82025b5e0, 0x45, 0x0, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/deviceset.go:1887 +0xa5c
github.com/docker/docker/daemon/graphdriver/devmapper.(*Driver).Create(0xc82036af00, 0xc821084080, 0x40, 0xc82025b5e0, 0x45, 0x0, 0x0, 0x0, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/driver.go:131 +0x6f
github.com/docker/docker/daemon/graphdriver/devmapper.(*Driver).CreateReadWrite(0xc82036af00, 0xc821084080, 0x40, 0xc82025b5e0, 0x45, 0x0, 0x0, 0x0, 0x0, 0x0)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/daemon/graphdriver/devmapper/driver.go:126 +0x86
github.com/docker/docker/daemon/graphdriver.(*NaiveDiffDriver).CreateReadWrite(0xc82021c500, 0xc821084080, 0x40, 0xc82025b5e0, 0x45, 0x0, 0x0, 0x0, 0x0, 0x0)
    <autogenerated>:28 +0xbe
github.com/docker/docker/layer.(*layerStore).CreateRWLayer(0xc82021c580, 0xc82154f980, 0x40, 0xc82025b2c0, 0x47, 0x0, 0x0, 0xc820981380, 0x0, 0x0, ...)
    /root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/layer/layer_store.go:476 +0x5a9
github.com/docker/docker/daemon.(*Daemon).setRWLayer(0xc820432ea0, 0xc8216d12c0, 0x0, 0x0)

هل يمكنك فتح قضية منفصلة بكل التفاصيل؟
شكر!

30003