# docker --version
Docker version 1.10.3, build 99b71ce

# docker info
Containers: 3
 Running: 0
 Paused: 0
 Stopped: 3
Images: 29
Server Version: 1.10.3
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 99
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 3.13.0-83-generic
Operating System: <unknown>
OSType: linux
Architecture: x86_64
CPUs: 24
Total Memory: 125.9 GiB
Name: dev34-devc
ID: VKMX:YMJ2:3NGV:5J6I:5RYM:AVBK:QPOZ:ODYE:VQ2D:AF2J:2LEM:TKTE
WARNING: No swap limit support

يجب أن أظهر أيضًا أن عامل الإرساء لا يسرد أي حاويات أو مجلدات أو صور:

$ docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE

$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

$ docker volume ls
DRIVER              VOLUME NAME

غريب؛ خاصة بسبب ؛

Containers: 3
 Running: 0
 Paused: 0
 Stopped: 3
Images: 29

الذي لا يتطابق مع ناتج docker images / docker ps .

ما هو نظام التشغيل الذي تعمل عليه؟

Operating System: <unknown>

tonistiigi أي فكرة؟

كان ذلك بعد ذلك. أعتقد أن بعض العمليات بدأت في هذه الأثناء.

الحالة التي أشير إليها (لدي الآن) هي:

$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0

وما زلت أمتلك:

$ sudo du -hs /var/lib/docker/aufs/diff/a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
296M    /var/lib/docker/aufs/diff/a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea

نحن على Ubuntu Lucid بنواة مطورة = /

$ uname -a
Linux dev34-devc 3.13.0-83-generic #127-Ubuntu SMP Fri Mar 11 00:25:37 UTC 2016 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 10.04.1 LTS
Release:        10.04
Codename:       lucid

يبدو أنها قضية مثيرة للاهتمام.
هل من الممكن أن يكون لدينا طريقة لإعادة إنتاجها؟ تضمين التغريدة

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

باش #!

! / بن / باش

مجموعة -eu

صدى "تحذير:: سيؤدي هذا إلى إيقاف جميع عمليات عامل الإرساء وإزالة جميع صور عامل الإرساء."
قراءة -p "هل تريد المتابعة (y / n)؟"
إذا ["$ REPLY"! = "y"] ؛ ومن بعد
صدى "إجهاض".
خروج 1
فاي

xdocker () {exec xargs -P10 -r -n1 --verbose docker "$ @"؛ }

مجموعة -x

إزالة الحاويات

عامل ميناء ps -q | xdocker توقف
عامل ميناء ps -aq | xdocker rm

إزالة العلامات

صور عامل ميناء | Sed 1d | grep -v '^'| عمود 1 2 | sed / /: / '| xdocker rmi

إزالة الصور

صور عامل ميناء -q | xdocker rmi
صور عامل ميناء -aq | xdocker rmi

إزالة وحدات التخزين

حجم عامل الإرساء ls -q | حجم xdocker rm
""

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

bukzor سيكون مُنسِّج يبدأ من دليل رسم بياني فارغ ، وسحب / تشغيل الصور وإدخالها في حالة لا يتم فيها تنظيفها بالكامل بعد تشغيل البرنامج النصي.

سيكون ذلك ممتعًا ، لكنه يبدو وكأنه عمل ليوم كامل.
لا يمكنني الالتزام بذلك.

إليك بعض البيانات الإضافية المتعلقة بالفارق المزعج (المحدد بشكل تعسفي) أعلاه ، a800 .

"" #! sh
$ docker-find a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea | sudo xargs -n1 wc -l | فرز -rn

• sudo find / nail / var / lib / docker '(' -path '/ nail / var / lib / docker / aufs / diff / ' -o -path '/ nail / var / lib / docker / aufs / mnt / " ) '-prune -o -print
• grep a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
• sudo find / nail / var / lib / docker '(' -path '/ nail / var / lib / docker / aufs / diff / ' -o -path '/ nail / var / lib / docker / aufs / mnt / " ) '-prune -o -type f -print0.)
• sudo xargs -0 -P20 grep -l a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
  15 / مسمار / var / lib / عامل ميناء / aufs / طبقات / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579
  14 / مسمار / var / lib / عامل ميناء / aufs / طبقات / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579-init
  13 / مسمار / var / lib / عامل ميناء / aufs / طبقات / 993e4988c510ec3ab4f6d139740a059df40585576f8196817e573a9684554c5c
  12 / مسمار / var / lib / عامل إرساء / aufs / طبقات / cf9fd1c4a64baa39b6d6d9dac048ad2fff3c3fe13924b07377e767eed230ba9f
  11 / مسمار / var / lib / عامل ميناء / aufs / طبقات / 4e6afb958b5ee6dea6d1a886d19fc9c780d4ecc4baeebfbde31f9bb97732d10d
  10 / مسمار / var / lib / عامل ميناء / aufs / طبقات / 23ce5a473b101d85f0e9465debe5a0f3b8a2079b99528a797b02052d06bc11d8
  9 / مسمار / var / lib / عامل ميناء / aufs / طبقات / 95e68d59a8704f2bb52cc1306ca910ddb7af8956eb7c57970fcf7d8b3d9baddb
  8 / مسمار / فار / ليب / عامل ميناء / aufs / طبقات / ac6b8ff4c0e7b91230ebf4c1caf16f06c1fdceff6111fd58f4ea50fc2dd5050b
  7 / مسمار / var / lib / عامل ميناء / aufs / طبقات / fd895b6f56aedf09c48dba97931a34cea863a21175450c31b6ceadde03f7b3da
  6 / مسمار / var / lib / عامل إرساء / aufs / طبقات / d5bbef5adf2efb6f15d4f96c4bee21beb955255d1ec17baf35de66e98e6c7328
  5 / مسمار / var / lib / عامل ميناء / aufs / طبقات / 9646360df378b88eae6f1d6288439eebd9647d5b9e8a471840d4a9d6ed5d92a4
  4 / مسمار / var / lib / عامل إرساء / aufs / طبقات / a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
  0 / مسمار / var / lib / عامل ميناء / image / aufs / layerdb / sha256 / d1c659b8e3d0e893e95c8eedc755adcb91a1c2022e1090376b451f7206f9b1c0 / cache-id

So we see there's a chain of child layers, with `f3286009193` as the tip.

$ docker-find f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 '$'

• sudo find / nail / var / lib / docker '(' -path '/ nail / var / lib / docker / aufs / diff / ' -o -path '/ nail / var / lib / docker / aufs / mnt / " ) '-prune -o -print
• grep - اللون "f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 $"
  / مسمار / var / lib / عامل إرساء / aufs / طبقات / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579
• sudo find / nail / var / lib / docker '(' -path '/ nail / var / lib / docker / aufs / diff / ' -o -path '/ nail / var / lib / docker / aufs / mnt / " ) '-prune -o -type f -print0.)
• sudo xargs -0 -P20 grep - color -l 'f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 $'
  / Nail / var / lib / Docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / mount-id

So that layer was used in mount `eb809c0321`. I don't find any references to that mount anywhere:

$ Docker-find eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e

• sudo find / nail / var / lib / docker '(' -path '/ nail / var / lib / docker / aufs / diff / ' -o -path '/ nail / var / lib / docker / aufs / mnt / " ) '-prune -o -print
• grep - اللون eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e
  / Nail / var / lib / Docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e
  / Nail / var / lib / Docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / mount-id
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / init-id
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / الوالدين
• sudo find / nail / var / lib / docker '(' -path '/ nail / var / lib / docker / aufs / diff / ' -o -path '/ nail / var / lib / docker / aufs / mnt / " ) '-prune -o -type f -print0.)
• سودو xargs -0 -P20 grep - color -l eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e
  ""

هل توجد أي طريقة للعثور على الحاوية التي تم استخدامها؟
يقول المستند فقط أن معرف التحميل لم يعد مساويًا لمعرف الحاوية ، وهو أمر غير مفيد للغاية.
https://docs.docker.com/engine/userguide/storagedriver/aufs-driver/

bukzor eb809c0321 هو معرف الحاوية. ما يعنيه محرر المستندات هو أن معرف aufs ( f3286009193f في حالتك) ليس معرف حاوية.

/ ccdmcgowan أيضًا

تضمين التغريدة

ثم من الواضح أن الحامل قد تجاوز عمر الحاوية الخاصة به.

في أي مرحلة من دورة حياة الحاوية يتم تنظيف الحامل؟
هل هذا هو aufs المؤقت للكتابة لتشغيل / إيقاف الحاويات؟

يتم حذف bukzor (rw) mount عند حذف الحاوية. يحدث إلغاء التحميل عند توقف عملية الحاوية. مجلدات Diff هي المكان الذي يتم فيه تخزين محتويات الطبقة الفردية ، ولا يهم ما إذا كانت الطبقة مثبتة أم لا.

bukzor الرابط بين معرف aufs ومعرف الحاوية يمكن العثور عليه على image/aufs/layerdb/mounts/<container-id>/mount-id . من مجرد معرفة معرف aufs ، فإن أسهل طريقة للعثور على معرف الحاوية هي إنشاء دليل image/aufs/layerdb له. إذا لم يتم العثور على شيء ، فهذا يعني أن التنظيف لم يكتمل بشكل نظيف.

الوقوع في مشكلة مماثلة.

نحن نقوم بتشغيل CI يوميًا في خادم docker daemon. يأخذ / var / lib / docker / aufs / diff قدرًا كبيرًا من سعة القرص ، وهو ما لا ينبغي أن يكون كذلك.

لا يزال 2gb في aufs/diff بعد تجربة كل ما هو معقول مقترح هنا أو في المواضيع ذات الصلة (بما في ذلك bash script لـ bukzor أعلاه).

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

أواجه نفس المشكلة. أنا أستخدم هذا الجهاز لاختبار الكثير من الحاويات ، ثم الالتزام / الحذف. دليل / var / lib / docker / aufs الخاص بي ثقيل 7.9G حاليًا. سأضطر إلى نقل هذا الدليل إلى نقطة تحميل أخرى ، لأن التخزين في هذا الدليل محدود. :(

# du -sh /var/lib/docker/aufs/diff/
1.9T    /var/lib/docker/aufs/diff/

mcallaway كل شيء في aufs/diff سيكون عبارة عن عمليات كتابة fs التي يتم إجراؤها في حاوية.

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

أستخدم k8s 1.3.5 و docker 1.12.

ساعد تشغيل docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc spotify/docker-gc .

لدي نفس المشكلة. أنا أستخدم Gitlab CI مع dock (عامل ميناء في عامل الإرساء).

IMHO عندما تم تحديث الصورة في التسجيل داخل نفس العلامة وتم سحبها ، ثم أعيد تشغيل الحاوية ذات الصلة ، والحاوية القديمة والصورة لا يتم تجميعهما إلا إذا قمت بتشغيل spotify/docker-gc .

يمكن لشخص آخر يؤكد هذا؟

kayrus صحيح ، لن يفترض عامل docker rmi $(docker images -qa -f dangling=true) . أيضًا ، سيحصل عامل الإرساء 1.13 على أوامر إدارة البيانات (انظر https://github.com/docker/docker/pull/26108) ، والتي تتيح لك تنظيف الصور والحاويات غير المستخدمة بسهولة أكبر وما إلى ذلك.

thaJeztah هل يحتوي /var/lib/docker/aufs/diff/ فعليًا على الصور "غير المميزة"؟

kayrus نعم هم جزء من الصور (معلم ، وغير موسوم)

الحصول على مشكلة مماثلة ، لا توجد حاويات / صور / وحدات تخزين ، حوالي 13 جيجا بايت من الاختلافات

$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 1.12.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 1030
 Dirperm1 Supported: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor
Kernel Version: 3.13.0-32-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 3.861 GiB
Name: gitrunner
ID: GSAW:6X5Z:SHHU:NZIM:O76D:P5OE:7OZG:UFGQ:BOAJ:HJFM:5G6W:5APP
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
Insecure Registries:
 127.0.0.0/8

$ docker volume ls
DRIVER              VOLUME NAME
$ docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
$

$ df -h
Filesystem                                 Size  Used Avail Use% Mounted on
...
/dev/mapper/gitrunner--docker-lib--docker   18G   15G  2.6G  85% /var/lib/docker

/var/lib/docker# sudo du -sm aufs/*
13782   aufs/diff
5       aufs/layers
5       aufs/mnt

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 1.12.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: xfs
 Dirs: 1122

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

هذا حظر نسبيًا في هذه المرحلة.

كذلك هنا. لا يوجد حل رسمي بعد؟

لقد طرحت هذا عدة مرات مختلفة في (مجتمع Docker) Slack. في كل مرة يقوم عدد قليل من الأشخاص بتشغيل قائمة البرامج النصية لجمع البيانات المهملة / cmds ، يجب أن أقوم بتشغيلها كحل.

في حين أن هؤلاء قد ساعدوا (اقرأ: لم يتم حلها - لا تزال المساحة تزحف نحو الامتلاء) في غضون ذلك ، أعتقد أنه يمكننا جميعًا الاتفاق على أن هذا ليس الحل المثالي على المدى الطويل.

jadametz 1.13 لديه docker system prune .
أبعد من ذلك ، لست متأكدًا من الطريقة الأخرى التي يمكن أن يساعد بها Docker (مفتوح للاقتراح). لا تصل الصور إلى النظام من تلقاء نفسها فحسب ، بل من خلال عمليات السحب والبناء وما إلى ذلك.

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

لدي نفس المشكلة بالضبط!

docker info Containers: 0 Running: 0 Paused: 0 Stopped: 0 Images: 0 Server Version: 1.12.1 Storage Driver: aufs Root Dir: /var/lib/docker/aufs Backing Filesystem: extfs Dirs: 2501 Dirperm1 Supported: false Logging Driver: json-file Cgroup Driver: cgroupfs Plugins: Volume: local Network: bridge host null overlay Swarm: inactive Runtimes: runc Default Runtime: runc Security Options: apparmor Kernel Version: 3.13.0-96-generic Operating System: Ubuntu 14.04.2 LTS OSType: linux Architecture: x86_64 CPUs: 8 Total Memory: 14.69 GiB Name: ip-172-31-45-4 ID: R5WV:BXU5:AV6T:GZUK:SAEA:6E74:PRSO:NQOH:EPMQ:W6UT:5DU4:LE64 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 Insecure Registries: 127.0.0.0/8

لا توجد صور أو حاويات أو مجلدات. 42 جيجا بايت في aufs / فرق

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

adamdry البرنامج النصي لجهة خارجية فقط: https://github.com/docker/docker/issues/22207#issuecomment -252560212

شكرًا @ kayrus ، لقد وزاد استخدامي للقرص بشكل طفيف ولم يبدو أنه يفعل أي شيء بدليل aufs / diff.

لقد جربت أيضًا docker system prune الذي لم يعمل. وحاولت docker rmi $(docker images -qa -f dangling=true) ولم أجد أي صور لإزالتها.

بالنسبة لأي شخص مهتم ، أستخدم هذا الآن لتنظيف جميع الحاويات والصور والأحجام والأشكال القديمة:

### FYI I am a Docker noob so I don't know if this causes any underlying issues but it does work for me - use at your own risk ###

الكثير من الإلهام مأخوذ من هنا: http://stackoverflow.com/questions/30984569/error-error-creating-aufs-mount-to-when-building-dockerfile

docker rm -f $(docker ps -a -q) && docker rmi -f $(docker images -q) && docker rmi -f $(docker images -a -q)
service docker stop
rm -rf /var/lib/docker/aufs
rm -rf /var/lib/docker/image/aufs
rm -f /var/lib/docker/linkgraph.db
service docker start

adamdry من الأفضل عدم استخدام -f عند تنفيذ rm / rmi لأنه سيخفي الأخطاء في الإزالة.
أنا أعتبر الوضع الحالي ... حيث يخفي -f خطأ ثم يترك لنا بعض الحالة المتبقية غير المرئية تمامًا للمستخدم ... على أنها خطأ.

أرى هذا أيضًا في تثبيت جديد تمامًا وغير مفاجئ:

root<strong i="6">@builder</strong>:/var/lib/docker# docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 1.12.4
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 63
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay host null bridge
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options:
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 3.625 GiB
Name: builder
ID: 2WXZ:BT74:G2FH:W7XD:VVXM:74YS:EA3A:ZQUK:LPID:WYKF:HDWC:UKMJ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
Insecure Registries:
 127.0.0.0/8
root<strong i="7">@builder</strong>:/var/lib/docker# docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
root<strong i="8">@builder</strong>:/var/lib/docker# docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
root<strong i="9">@builder</strong>:/var/lib/docker# du -hd2
4.0K    ./swarm
6.0M    ./image/aufs
6.0M    ./image
4.0K    ./trust
28K ./volumes
4.0K    ./containers
276K    ./aufs/layers
292K    ./aufs/mnt
1.5G    ./aufs/diff <-------------------------
1.5G    ./aufs
4.0K    ./tmp
72K ./network/files
76K ./network
1.5G    .
root<strong i="10">@builder</strong>:/var/lib/docker# 

robhaswell نظرًا لأنه تثبيت جديد ، هل تريد تجربة ذلك؟ https://github.com/docker/docker/issues/22207#issuecomment -266784433

adamdry لقد حذفت بالفعل /var/lib/docker/aufs لأنه كان يحظر عملي. ماذا تتوقع أن تحقق تعليماتك؟ إذا منعوا حدوث المشكلة مرة أخرى في المستقبل ، فيمكنني محاولة إعادة إنشاء المشكلة وتجربة التعليمات الخاصة بك. ومع ذلك ، إذا كان الغرض هو تحرير المساحة ، فقد حققت ذلك بالفعل.

robhaswell نعم ، كان الأمر يتعلق بتحرير مساحة على القرص ولكنني

أثناء الإنشاء ، إذا تم مقاطعة عملية الإنشاء أثناء عملية بناء الطبقة (والتي تحتوي أيضًا على blob ليتم نسخها) ، متبوعًا بإيقاف الحاوية ، فإنها تترك خلفها البيانات في / var / lib / docker / aufs / diff /. ظهرت صورة متدلية. تنظيفه أيضًا لم يحرر المساحة. هل من الممكن إدراجه كجزء من نظام تقليم عامل الإرساء؟ يؤدي حذف بيانات blob الموجودة داخل هذا المجلد فقط إلى تحرير المساحة ، والتي لست متأكدًا من أنها ستسبب أي مشكلة أم لا.

إصدار عامل الإرساء: 1.13.0-rc1

أثناء الإنشاء ، إذا تم مقاطعة عملية الإنشاء أثناء عملية بناء الطبقة (والتي تحتوي أيضًا على blob ليتم نسخها) ، متبوعًا بإيقاف الحاوية ، فإنها تترك البيانات خلفها

قد يكون هذا أيضًا سبب مشاكلي - لقد قطعت الكثير من الإنشاءات.

أثناء سحب عامل الميناء ، لوحظ في الحالتين التاليتين:

1. إذا تمت مقاطعة العملية عندما تقول التنزيل (الذي يقوم بتنزيل طبقة الصورة في / var / lib / docker / tmp /) ، فإنه ينظف جميع البيانات الموجودة في هذا المجلد
2. إذا توقفت العملية عندما تقول الاستخراج (والذي أفترض أنه يستخرج الطبقة من tmp إلى / var / lib / docker / aufs / diff /) ، فإنه ينظف بيانات tmp و diff على حد سواء.

أثناء عملية بناء الصورة ،

1. عند مقاطعة العملية عند "إرسال سياق الإنشاء إلى Docker daemon" (الذي ينسخ بيانات blob في حالتي في / var / lib / docker / tmp /) ، تظل هناك إلى الأبد ولا يمكن تنظيفها بأي أمر باستثناء حذفها يدويًا. لست متأكدًا من كيفية معالجة apt الحصول على التحديثات في الصورة.
2. أثناء إنشاء الطبقة التي تحتوي على بيانات blob ، على سبيل المثال إعداد برنامج كبير ، إذا تمت مقاطعة العملية ، تستمر حاوية عامل الإرساء في العمل على الصورة. في حالتي ، تشكل بيانات blob ذات الطبقة الواحدة ، المتوفرة بالفعل في مجلد tmp ، الصورة بأكملها. ولكن ، إذا تم إيقاف الحاوية باستخدام أمر docker stop ، فستحدث حالتان:
   أ. إذا استمرت عملية التحميل ، فستترك البيانات في مجلد tmp و diff.
   ب. إذا تم نسخ البيانات في مجلد فرق ، فسيتم إزالة البيانات من مجلد tmp وترك البيانات في مجلد مختلف وربما تحميل مجلد.

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

إذا تم إنشاء صورة واحدة من طبقتين ، تم إنشاء طبقة واحدة وتم مقاطعة الثانية ، يبدو أن نظام Docker يقوم بتنظيف البيانات الخاصة بحاوية الطبقة التي تمت مقاطعتها وتوقفت الحاوية. لكنه لا ينظف بيانات الطبقات السابقة في حالة المقاطعة. كما أنها لا تعكس إجمالي مساحة القرص المطالب بها. قم بإجراء هذه الاختبارات على نظام AWS و ubuntu 14.04 و x86_64 bit مع نظام ملفات aufs. شغّل اختبار Docker Prune باستخدام Docker 1.13.0 rc3 و Docker 1.12

تضمين التغريدة
يرجى إعلامي إذا كنت أسيء تفسير أي شيء.

فتحت إصدارًا لملفات /var/lib/docker/tmp لم يتم تنظيفها ؛ https://github.com/docker/docker/issues/29486

يبدو أن نظام Docker يقوم بتنظيف البيانات الخاصة بحاوية الطبقة التي تمت مقاطعتها وتوقفت الحاوية. لكنه لا ينظف بيانات الطبقات السابقة في حالة المقاطعة.

حاولت إعادة إنتاج هذا الموقف ، لكنني لم أتمكن من رؤية ذلك في حالة بسيطة ؛

ابدأ بتثبيت نظيف فارغ /var/lib/docker ، أنشئ ملفًا كبيرًا لـ
الاختبار ، وملف Dockerfile ؛

mkdir repro && cd repro
fallocate -l 300M bigfile

cat > Dockerfile <<EOF
FROM scratch
COPY ./bigfile /
COPY ./bigfile /again/
COPY ./bigfile /and-again/
EOF

ابدأ docker build ، وقم بالإلغاء أثناء البناء ، ولكن _ بعد_ الإنشاء
تم إرسال السياق ؛

docker build -t stopme .
Sending build context to Docker daemon 314.6 MB
Step 1/4 : FROM scratch
 --->
Step 2/4 : COPY ./bigfile /
 ---> 28eb6d7b0920
Removing intermediate container 98876b1673bf
Step 3/4 : COPY ./bigfile /again/
^C

تحقق من محتوى /var/lib/docker/aufs/

du -h /var/lib/docker/aufs/
301M    /var/lib/docker/aufs/diff/9127644c356579741348f7f11f50c50c9a40e0120682782dab55614189e82917
301M    /var/lib/docker/aufs/diff/81fd6b2c0cf9a28026cf8982331016a6cd62b7df5a3cf99182e7e09fe0d2f084/again
301M    /var/lib/docker/aufs/diff/81fd6b2c0cf9a28026cf8982331016a6cd62b7df5a3cf99182e7e09fe0d2f084
601M    /var/lib/docker/aufs/diff
8.0K    /var/lib/docker/aufs/layers
4.0K    /var/lib/docker/aufs/mnt/9127644c356579741348f7f11f50c50c9a40e0120682782dab55614189e82917
4.0K    /var/lib/docker/aufs/mnt/81fd6b2c0cf9a28026cf8982331016a6cd62b7df5a3cf99182e7e09fe0d2f084
4.0K    /var/lib/docker/aufs/mnt/b6ffb1d5ece015ed4d3cf847cdc50121c70dc1311e42a8f76ae8e35fa5250ad3-init
16K /var/lib/docker/aufs/mnt
601M    /var/lib/docker/aufs/

قم بتشغيل الأمر docker system prune لتنظيف الصور والحاويات ؛

docker system prune -a
WARNING! This will remove:
    - all stopped containers
    - all volumes not used by at least one container
    - all networks not used by at least one container
    - all images without at least one container associated to them
Are you sure you want to continue? [y/N] y
Deleted Images:
deleted: sha256:253b2968c0b9daaa81a58f2a04e4bc37f1dbf958e565a42094b92e3a02c7b115
deleted: sha256:cad1de5fd349865ae10bfaa820bea3a9a9f000482571a987c8b2b69d7aa1c997
deleted: sha256:28eb6d7b09201d58c8a0e2b861712701cf522f4844cf80e61b4aa4478118c5ab
deleted: sha256:3cda5a28d6953622d6a363bfaa3b6dbda57b789e745c90e039d9fc8a729740db

Total reclaimed space: 629.1 MB

تحقق من محتوى /var/lib/docker/aufs/

du -h /var/lib/docker/aufs/
4.0K    /var/lib/docker/aufs/diff
4.0K    /var/lib/docker/aufs/layers
4.0K    /var/lib/docker/aufs/mnt/b6ffb1d5ece015ed4d3cf847cdc50121c70dc1311e42a8f76ae8e35fa5250ad3-init
8.0K    /var/lib/docker/aufs/mnt
20K /var/lib/docker/aufs/

أرى أن التركيب -init قد ترك ، سأتحقق مما إذا كان بإمكاننا حل المشكلة
هذا (على الرغم من أنه مجرد دليل فارغ)

كان الاختلاف الوحيد في ملف الرصيف الذي استخدمته هو (لإنشاء طبقات مختلفة)
من الصفر
نسخ ["./bigfile" ، "randomNoFile1" ، /]
نسخ ["./bigfile" ، "randomNoFile2" ، /]
EOF

لست متأكدًا مما إذا كان يحدث فرقًا.

لا ، المشكلة ليست في مجلدات init الفارغة. في حالتي ، كان الأمر te blob. ومع ذلك ، يمكنني إعادة التحقق منه يوم الاثنين والتحديث.

أيضًا ، تم استخدام ملف 5 جيجا بايت ، تم إنشاؤه عن طريق قراءة بايت من dev urandom.
في حالتك ، تتم إضافة نفس الملف مرتين. هل سيؤدي ذلك إلى إنشاء طبقة واحدة وتركيب الطبقة الثانية منها أم أنها ستكون طبقتين منفصلتين؟ في حالتي ، دائمًا طبقتان منفصلتان.

تضمين التغريدة
شكرا لك على هذا الرد السريع على هذه القضية. ستكون إضافة هذه الميزة مفيدة للغاية!

@ monikakatiyar16 لقد حاولت إعادة إنتاج هذا أيضًا مع إلغاء ADD و RUN ولكن لم أستطع الحصول على أي شيء يتسرب إلى aufs/diff بعد الحذف. لم أستطع فهم الحاوية التي توقفها تمامًا لأن الحاويات يجب ألا تعمل أثناء عمليات ADD/COPY . إذا تمكنت من تجميع أداة إعادة إنتاج يمكننا تشغيلها فسيكون ذلك موضع تقدير كبير.

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

تضمين التغريدة
أشعر أنك على حق. لا توجد في الواقع أي حاويات مدرجة على أنها نشطة وقيد التشغيل. بدلا من ذلك هناك حاويات ميتة. لم يعمل Docker system prune في حالتي ، فقد يكون ذلك لأن العملية لم تقتل باستخدام Ctrl + C. بدلاً من ذلك ، استمر في العمل في الخلفية. في حالتي ، سيكون هذا هو السبب ، لا يمكنه إزالة تلك النقاط.

عندما أقاطع العملية باستخدام Ctrl + C ، يتم إنهاء عملية الإنشاء ، ولكن تظل عملية docker-untar حية في الخلفية ، والتي تستمر في العمل على بناء الصورة. (ملاحظة: / var / lib / docker مرتبط بشكل ناعم بـ / home / lib / docker لاستخدام وحدات تخزين EBS للبيانات الكبيرة على AWS)

root 12700 10781 7 11:43 ? 00:00:04 docker-untar /home/lib/docker/aufs/mnt/d446d4f8a7dbae162e7578af0d33ac38a63b4892905aa86a8d131c1e75e2828c

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

أرفق أيضًا سلوك عملية الإنشاء لبناء صورة - مقاطعة الصورة باستخدام Ctrl + C (DockerBuild_WOProcessKill) وبناء صورة - مقاطعة ذلك باستخدام Ctrl + C - قتل العملية (DockerBuild_WithProcessKill)

باستخدام الأوامر -

لإنشاء ملف كبير: ./gc_maxpush_pull.sh 1 5gblayer 0 512 1

لإنشاء الصور: ./gc_maxpush_pull.sh 1 5gblayer 1 512 1

DockerBuild.zip

خطوات التكرار:

1. قم بإنشاء ملف كبير بحجم 5 جيجا بايت
2. ابدأ عملية الإنشاء وقم بمقاطعتها فقط بعد انتهاء إرسال سياق الإنشاء ونسخ blob بالفعل.
3. يكمل بناء الصورة بعد فترة ويظهرها في صور عامل ميناء (كما في الحالة 1 المرفقة من قبلي - DockerBuild_WOProcessKill)
4. إذا تم إنهاء العملية ، فستستغرق بعض الوقت وتترك بيانات blob في / diff (وهو ما يجب أن يحدث عند القتل فجأة كما هو مرفق في الملف - DockerBuild_WithProcessKill)

إذا كان ما أفترضه صحيحًا ، فقد لا تكون هذه مشكلة في docker prune ، بدلاً من قتل بنية docker التي لا تعمل بطريقة ما بالنسبة لي.

هل هناك طريقة رشيقة لمقاطعة أو إيقاف عملية صورة البناء ، والتي تهتم أيضًا بتنظيف البيانات المنسوخة (كما تم التعامل معها في Docker pull)؟

في السابق ، لم أكن أقتل العملية. كما أنني أشعر بالفضول بشأن ما يفعله docker-untar ولماذا يقوم بتثبيته على مجلدات / mnt و / diff كليهما ثم تنظيف مجلد / mnt لاحقًا؟

تم اختبار ذلك باستخدام Docker الإصدار 1.12.5 ، والإصدار 7392c3b على AWS

معلومات عامل الميناء
الحاويات: 2
الجري: 0
متوقف مؤقتًا: 0
متوقف: 2
الصور: 0
إصدار الخادم: 1.12.5
سائق التخزين: aufs
مدير الجذر: / home / lib / docker / aufs
دعم نظام الملفات: extfs
Dirs: 4
Dirperm1 المدعومة: خطأ
برنامج تشغيل التسجيل: ملف json
برنامج تشغيل Cgroup: cgroupfs
الإضافات:
الحجم: محلي
الشبكة: تراكب مضيف جسر فارغ
سرب: غير نشط
أوقات التشغيل: runc
وقت التشغيل الافتراضي: runc
خيارات الأمان: apparmor
إصدار النواة: 3.13.0-105-generic
نظام التشغيل: Ubuntu 14.04.4 LTS
OSType: لينكس
العمارة: x86_64
وحدات المعالجة المركزية: 2
إجمالي الذاكرة: 3.859 جيجابايت
الاسم: سيد
المعرف: 2 NQU: D2C5 : 5 WPL: IIDR : P6FO: OAG7: GHW6: ZJMQ: VDHI : B5CI: XFZJ: ZSZM
Docker Root Dir: / home / lib / docker
وضع التصحيح (العميل): خطأ
وضع التصحيح (الخادم): خطأ
التسجيل: https://index.docker.io/v1/
تحذير: لا يوجد دعم لحد المبادلة
السجلات غير الآمنة:
127.0.0.0 / 8

@ monikakatiyar16 عندما أقوم بقتل عملية untar يدويًا أثناء الإنشاء ، أحصل على Error processing tar file(signal: killed): في ناتج الإنشاء. ترك الحاوية في docker ps -a هو السلوك الصحيح ، يحدث نفس الشيء في أي خطأ في البناء ويتيح لك تصحيح المشكلات التي تسببت في فشل الإنشاء. ليس لدي أي مشكلة في حذف هذه الحاوية ، وإذا فعلت ذلك ، فسيتم تنظيف جميع البيانات الموجودة في /var/lib/docker/aufs أيضًا.

tonistiigi نعم أنت على صواب. تمكنت من حذف المجلد المرتبط بالحاوية وقام بتنظيف كل شيء ، بعد قتل عملية docker-untar. يعمل Docker system prune أيضًا في هذه الحالة.

كانت المشكلة الفعلية التي تركت أكثر من وحدات التخزين هي الحالة ، عندما لم أقتل عملية docker-untar ، حاولت إزالة حاوية عامل التحميل جنبًا إلى جنب مع وحدات التخزين - والتي أعطت الخطأ التالي:

docker rm -v -f $(docker ps -a -q)
Error response from daemon: Driver aufs failed to remove root filesystem 97931bf059a0ec219efd3f762dbb173cf9372761ff95746358c08e2b61f7ce79: rename /home/lib/docker/aufs/diff/359d27c5b608c9dda1170d1e34e5d6c5d90aa2e94826257f210b1442317fad70 /home/lib/docker/aufs/diff/359d27c5b608c9dda1170d1e34e5d6c5d90aa2e94826257f210b1442317fad70-removing: device or resource busy

سجلات الشيطان:

Error removing mounted layer 78fb899aab981557bc2ee48e9738ff4c2fcf2d10a1984a62a77eefe980c68d4a: rename /home/lib/docker/aufs/diff/d2605125ef072de79dc948f678aa94dd6dde562f51a4c0bd08a210d5b2eba5ec /home/lib/docker/aufs/diff/d2605125ef072de79dc948f678aa94dd6dde562f51a4c0bd08a210d5b2eba5ec-removing: device or resource busy ERRO[0956] Handler for DELETE /v1.25/containers/78fb899aab98 returned error: Driver aufs failed to remove root filesystem 78fb899aab981557bc2ee48e9738ff4c2fcf2d10a1984a62a77eefe980c68d4a: rename /home/lib/docker/aufs/diff/d2605125ef072de79dc948f678aa94dd6dde562f51a4c0bd08a210d5b2eba5ec /home/lib/docker/aufs/diff/d2605125ef072de79dc948f678aa94dd6dde562f51a4c0bd08a210d5b2eba5ec-removing: device or resource busy ERRO[1028] Error unmounting container 78fb899aab981557bc2ee48e9738ff4c2fcf2d10a1984a62a77eefe980c68d4a: no such file or directory

يبدو أن الأمر الذي يجب اتباعه الآن لمقاطعة بناء عامل الإرساء هو:
Interrupt docker build > Kill docker untar process > remove container and volume : docker rm -v -f $(docker ps -a -q)

بالنسبة إلى docker v1.13.0-rc4 ، يمكن أن يكون Interrupt docker build > Kill docker untar process > docker system prune -a

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

سأقوم بالبحث / التحديث / تسجيل مشكلة جديدة للمقاطعة الرشيقة لبناء عامل الإرساء والتي توقف أيضًا عملية docker-untar معها.

(تم التحقق من ذلك باستخدام Docker v1.12.5 و v1.13.0-rc4)

تحديث: عند قتل docker-untar أثناء إرسال سياق الإنشاء إلى docker daemon ، فإنه يعطي خطأ في الإنشاء: Error response from daemon: Error processing tar file(signal: terminated) ، لكن أثناء نسخ الطبقة لا يحدث ذلك (بالنسبة لي)

شكرا لكونك صبورا جدا ولإعطاء وقتك!

أرى /var/lib/docker/aufs يتزايد باستمرار في الحجم على عامل وضع سرب الرصيف. يتم إدارة هذا الشيء في الغالب من قبل مدير السرب والقليل جدًا من إنشاء الحاويات يدويًا بصرف النظر عن بعض أوامر الصيانة هنا وهناك.

أقوم بتشغيل docker exec على حاويات الخدمة ؛ لست متأكدًا مما إذا كان هذا قد يكون سببًا.

كان الحل البديل لحل هذه المشكلة في حالتي هو بدء تشغيل عامل آخر ، وتعيين العقدة الكاملة على --availability=drain والتحرك يدويًا عبر بضع مرات تحميل لوحدة التخزين.

ubuntu@ip-172-31-18-156:~$ docker --version
Docker version 1.12.3, build 6b644ec

لقد وصل هذا إلى خادم CI الخاص بنا على مر العصور. هذا يحتاج إلى الإصلاح.

orf شكرا

نفس المشكلة هنا. لا يكون لأي من الحاوية أو وحدات التخزين أو إزالة الصور أو أوامر تنظيف nore Docker 1.13 أي تأثير.

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

تملأ الملفات الموجودة في / var / lib / docker / aufs / diff مساحة 100٪ لنظام ملفات / dev / sda1 من 30 جيجا بايت

root @ Ubuntu : / var / lib / docker / aufs / diff # df -h

حجم نظام الملفات المستخدم متوفر استخدم٪ Mounted on
udev 14G 0 14G 0٪ / ديف
tmpfs 2.8G 273M 2.5G 10٪ / تشغيل
/ dev / sda1 29G 29G 0100٪ /
tmpfs 14G 0 14G 0٪ / dev / shm
tmpfs 5.0M 0 5.0M 0٪ / تشغيل / قفل
tmpfs 14G 0 14G 0٪ / sys / fs / cgroup
/ dev / sdb117G 60M 187G 1٪ / mnt
tmpfs 2.8G 0 2.8G 0٪ / تشغيل / مستخدم / 1000

du -h -d 1 / var / lib / docker / aufs / diff | grep "[0-9] G>"
عروض

4.1G / var / lib / Docker / aufs / diff / a0cde42cbea362bbb2a73ffbf30059bcce7ef0256d1d7e186264f915d15
14G / var / lib / Docker / aufs / diff / 59aee33d8a607b5315ce103cd99f17b4dfdec73c9a2f3bb2afc7d02bfae
20G / var / lib / docker / aufs / diff

حاول أيضًا تقليم نظام عامل ميناء ، الذي لم يساعد.

هل وجد أي شخص حلاً لهذه المشكلة المستمرة للملفات الكبيرة جدًا في الاختلافات قبل إصلاح هذا الخطأ في الكود؟

نعم ، لقد تم تقديم هذه الطريقة بالفعل ، ولكن إليك مقتطف من نهاية العالم يدمر كل شيء أضعه هنا في العمل (باستثناء المجلدات المحلية للمجلدات). لوضع bashrc أو ملف تهيئة bash آخر.

""
الاسم المستعار عامل تنظيف كامل = 'func_full-cleanup-docker'

func_full-cleanup-docker () {

صدى "تحذير: سيؤدي هذا إلى إزالة كل شيء من عامل الإرساء: الأحجام والحاويات والصور. هل تجرؤ على ذلك؟ [نعم / لا]"
قراءة الاختيار

إذا [("$ choice" == "y") -o ("$ choice" == "Y")]
ومن بعد
sudo echo "> sudo rights check [OK]"
الحجم = sudo du -sh /var/lib/docker/aufs

echo "Stopping all running containers"
containers=`docker ps -a -q`
if [ -n "$containers" ]
then
  docker stop $containers
fi

echo "Removing all docker images and containers"
docker system prune -f

echo "Stopping Docker daemon"
sudo service docker stop

echo "Removing all leftovers in /var/lib/docker (bug #22207)"
sudo rm -rf /var/lib/docker/aufs
sudo rm -rf /var/lib/docker/image/aufs
sudo rm -f /var/lib/docker/linkgraph.db

echo "Starting Docker daemon"
sudo service docker start

sizeb=`sudo du -sh /var/lib/docker/aufs`
echo "Size before full cleanup:"
echo "        $sizea"
echo "Size after full cleanup:"
echo "        $sizeb"

فاي
} ``

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

مرحبًا ، لدي نفس المشكلة في docker 1.10.2 ، أنا أقوم بتشغيل kubernetes. هذه هي نسخة عامل الإرساء الخاص بي:

Containers: 7
 Running: 0
 Paused: 0
 Stopped: 7
Images: 4
Server Version: 1.10.2
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 50
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 4.4.0-31-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 1.954 GiB
Name: ubuntu-k8s-03
ID: NT23:5Y7J:N2UM:NA2W:2FHE:FNAS:56HF:WFFF:N2FR:O4T4:WAHC:I3PO
Debug mode (server): true
 File Descriptors: 10
 Goroutines: 23
 System Time: 2017-02-14T15:25:00.740998058+09:00
 EventsListeners: 0
 Init SHA1: 3e247d0d32543488f6e70fbb7c806203f3841d1b
 Init Path: /usr/lib/docker/dockerinit
 Docker Root Dir: /var/lib/docker
WARNING: No swap limit support

أحاول تتبع كل دليل diff غير المستخدم ضمن /var/lib/docker/aufs/diff و /var/lib/docker/aufs/mnt/ خلال تحليل ملفات الطبقة تحت /var/lib/docker/image/aufs/imagedb ، ها هو البرنامج النصي الذي استخدمته:

https://gist.github.com/justlaputa/a50908d4c935f39c39811aa5fa9fba33

لكنني واجهت مشكلة عندما أتوقف وأعد تشغيل برنامج Docker daemon ، يبدو أنني أقوم بعمل حالة غير متسقة لعمال التحميل:

/var/log/upstart/docker.log:

DEBU[0277] Cleaning up old shm/mqueue mounts: start.
DEBU[0277] Cleaning up old shm/mqueue mounts: done.
DEBU[0277] Clean shutdown succeeded
Waiting for /var/run/docker.sock
DEBU[0000] docker group found. gid: 999
DEBU[0000] Server created for HTTP on unix (/var/run/docker.sock)
DEBU[0000] Using default logging driver json-file
INFO[0000] [graphdriver] using prior storage driver "aufs"
DEBU[0000] Using graph driver aufs
INFO[0000] Graph migration to content-addressability took 0.00 seconds
DEBU[0000] Option DefaultDriver: bridge
DEBU[0000] Option DefaultNetwork: bridge
INFO[0000] Firewalld running: false
DEBU[0000] /sbin/iptables, [--wait -t nat -D PREROUTING -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -D OUTPUT -m addrtype --dst-type LOCAL ! --dst 127.0.0.0/8 -j DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -D OUTPUT -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -D PREROUTING]
DEBU[0000] /sbin/iptables, [--wait -t nat -D OUTPUT]
DEBU[0000] /sbin/iptables, [--wait -t nat -F DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -X DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -F DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -X DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -F DOCKER-ISOLATION]
DEBU[0000] /sbin/iptables, [--wait -t filter -X DOCKER-ISOLATION]
DEBU[0000] /sbin/iptables, [--wait -t nat -n -L DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -N DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -n -L DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -n -L DOCKER-ISOLATION]
DEBU[0000] /sbin/iptables, [--wait -t filter -C DOCKER-ISOLATION -j RETURN]
DEBU[0000] /sbin/iptables, [--wait -I DOCKER-ISOLATION -j RETURN]
/var/run/docker.sock is up
DEBU[0000] Registering ipam driver: "default"
DEBU[0000] releasing IPv4 pools from network bridge (dcfcc71060f02440ae53da5ee0f083ca51c33a290565f1741f451754ae6b4257)
DEBU[0000] ReleaseAddress(LocalDefault/10.254.69.0/24, 10.254.69.1)
DEBU[0000] ReleasePool(LocalDefault/10.254.69.0/24)
DEBU[0000] Allocating IPv4 pools for network bridge (159d0a404ff6564b4fcfe633f0c8c123c0c0606d28ec3b110272650c5fc1bcb6)
DEBU[0000] RequestPool(LocalDefault, 10.254.69.1/24, , map[], false)
DEBU[0000] RequestAddress(LocalDefault/10.254.69.0/24, 10.254.69.1, map[RequestAddressType:com.docker.network.gateway])
DEBU[0000] /sbin/iptables, [--wait -t nat -C POSTROUTING -s 10.254.69.0/24 ! -o docker0 -j MASQUERADE]
DEBU[0000] /sbin/iptables, [--wait -t nat -C DOCKER -i docker0 -j RETURN]
DEBU[0000] /sbin/iptables, [--wait -t nat -I DOCKER -i docker0 -j RETURN]
DEBU[0000] /sbin/iptables, [--wait -D FORWARD -i docker0 -o docker0 -j DROP]
DEBU[0000] /sbin/iptables, [--wait -t filter -C FORWARD -i docker0 -o docker0 -j ACCEPT]
DEBU[0000] /sbin/iptables, [--wait -t filter -C FORWARD -i docker0 ! -o docker0 -j ACCEPT]
DEBU[0000] /sbin/iptables, [--wait -t filter -C FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT]
DEBU[0001] /sbin/iptables, [--wait -t nat -C PREROUTING -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0001] /sbin/iptables, [--wait -t nat -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0001] /sbin/iptables, [--wait -t nat -C OUTPUT -m addrtype --dst-type LOCAL -j DOCKER ! --dst 127.0.0.0/8]
DEBU[0001] /sbin/iptables, [--wait -t nat -A OUTPUT -m addrtype --dst-type LOCAL -j DOCKER ! --dst 127.0.0.0/8]
DEBU[0001] /sbin/iptables, [--wait -t filter -C FORWARD -o docker0 -j DOCKER]
DEBU[0001] /sbin/iptables, [--wait -t filter -C FORWARD -o docker0 -j DOCKER]
DEBU[0001] /sbin/iptables, [--wait -t filter -C FORWARD -j DOCKER-ISOLATION]
DEBU[0001] /sbin/iptables, [--wait -D FORWARD -j DOCKER-ISOLATION]
DEBU[0001] /sbin/iptables, [--wait -I FORWARD -j DOCKER-ISOLATION]
WARN[0001] Your kernel does not support swap memory limit.
DEBU[0001] Cleaning up old shm/mqueue mounts: start.
DEBU[0001] Cleaning up old shm/mqueue mounts: done.
DEBU[0001] Loaded container 0790b33ec8e5345ac944d560263b8e13cb75f80dd82cd25753c7320bbcb2747c
DEBU[0001] Loaded container 0e36a6c9319e6b7ca4e5b5408e99d77d51b1f4e825248c039ba0260e628c483d
DEBU[0001] Loaded container 135fb2e8cad26d531435dcd19d454e41cf7aece289ddc7374b4c2a984f8b094a
DEBU[0001] Loaded container 2c28de46788ce96026ac8e61e99c145ec55517543e078a781e8ce6c8cddec973
DEBU[0001] Loaded container 35eb075b5815e621378eb8a7ff5ad8652819ec851eaa4f7baedb1383dfa51a57
DEBU[0001] Loaded container 6be37a301a8f52040adf811041c140408224b12599aa55155f8243066d2b0b69
DEBU[0001] Loaded container d98ac7f052fef31761b82ab6c717760428ad5734df4de038d80124ad5b5e8614
DEBU[0001] Starting container 2c28de46788ce96026ac8e61e99c145ec55517543e078a781e8ce6c8cddec973
ERRO[0001] Couldn't run auplink before unmount: exit status 22
ERRO[0001] error locating sandbox id d4c538661db2edc23c79d7dddcf5c7a8886c9477737888a5fc2641bc5e66da8b: sandbox d4c538661db2edc23c79d7dddcf5c7a8886c9477737888a5fc2641bc5e66da8b not found
WARN[0001] failed to cleanup ipc mounts:
failed to umount /var/lib/docker/containers/2c28de46788ce96026ac8e61e99c145ec55517543e078a781e8ce6c8cddec973/shm: invalid argument
ERRO[0001] Failed to start container 2c28de46788ce96026ac8e61e99c145ec55517543e078a781e8ce6c8cddec973: error creating aufs mount to /var/lib/docker/aufs/mnt/187b8026621da2add42330c9393a474fcd9af2e4567596d61bcd7a40c85f71da: invalid argument
INFO[0001] Daemon has completed initialization
INFO[0001] Docker daemon                                 commit=c3959b1 execdriver=native-0.2 graphdriver=aufs version=1.10.2
DEBU[0001] Registering routers
DEBU[0001] Registering HEAD, /containers/{name:.*}/archive

وعندما أحاول إنشاء حاويات جديدة docker run ، فقد فشلت مع الرسالة:

docker: Error response from daemon: error creating aufs mount to /var/lib/docker/aufs/mnt/f9609c0229baa2cdc6bc07c36970ef4f192431c1b1976766b3ea23d72c355df3-init: invalid argument.
See 'docker run --help'.

ويظهر سجل الخفي:

DEBU[0173] Calling POST /v1.22/containers/create
DEBU[0173] POST /v1.22/containers/create
DEBU[0173] form data: {"AttachStderr":false,"AttachStdin":false,"AttachStdout":false,"Cmd":["/hyperkube","kubelet","--api-servers=http://localhost:8080","--v=2","--address=0.0.0.0","--enable-server","--hostname-override=172.16.210.87","--config=/etc/kubernetes/manifests-multi","--cluster-dns=10.253.0.10","--cluster-domain=cluster.local","--allow_privileged=true"],"Domainname":"","Entrypoint":null,"Env":[],"HostConfig":{"Binds":["/sys:/sys:ro","/dev:/dev","/var/lib/docker/:/var/lib/docker:rw","/var/lib/kubelet/:/var/lib/kubelet:rw","/var/run:/var/run:rw","/etc/kubernetes/manifests-multi:/etc/kubernetes/manifests-multi:ro","/:/rootfs:ro"],"BlkioDeviceReadBps":null,"BlkioDeviceReadIOps":null,"BlkioDeviceWriteBps":null,"BlkioDeviceWriteIOps":null,"BlkioWeight":0,"BlkioWeightDevice":null,"CapAdd":null,"CapDrop":null,"CgroupParent":"","ConsoleSize":[0,0],"ContainerIDFile":"","CpuPeriod":0,"CpuQuota":0,"CpuShares":0,"CpusetCpus":"","CpusetMems":"","Devices":[],"Dns":[],"DnsOptions":[],"DnsSearch":[],"ExtraHosts":null,"GroupAdd":null,"IpcMode":"","Isolation":"","KernelMemory":0,"Links":null,"LogConfig":{"Config":{},"Type":""},"Memory":0,"MemoryReservation":0,"MemorySwap":0,"MemorySwappiness":-1,"NetworkMode":"host","OomKillDisable":false,"OomScoreAdj":0,"PidMode":"host","PidsLimit":0,"PortBindings":{},"Privileged":true,"PublishAllPorts":false,"ReadonlyRootfs":false,"RestartPolicy":{"MaximumRetryCount":0,"Name":"always"},"SecurityOpt":null,"ShmSize":0,"UTSMode":"","Ulimits":null,"VolumeDriver":"","VolumesFrom":null},"Hostname":"","Image":"gcr.io/google_containers/hyperkube:v1.1.8","Labels":{},"NetworkingConfig":{"EndpointsConfig":{}},"OnBuild":null,"OpenStdin":false,"StdinOnce":false,"StopSignal":"SIGTERM","Tty":false,"User":"","Volumes":{},"WorkingDir":""}
ERRO[0173] Couldn't run auplink before unmount: exit status 22
ERRO[0173] Clean up Error! Cannot destroy container 482957f3e4e92a0ba56d4787449daa5a8708f3b77efe0c603605f35d02057566: nosuchcontainer: No such container: 482957f3e4e92a0ba56d4787449daa5a8708f3b77efe0c603605f35d02057566
ERRO[0173] Handler for POST /v1.22/containers/create returned error: error creating aufs mount to /var/lib/docker/aufs/mnt/f9609c0229baa2cdc6bc07c36970ef4f192431c1b1976766b3ea23d72c355df3-init: invalid argument

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

فتحت رقم 31012 على الأقل للتأكد من عدم تسريب هذه الرسائل تحت أي ظرف من الظروف.
نحتاج بالطبع أيضًا إلى النظر في الأسباب المختلفة للأخطاء busy

كان هذا يعضني على قدر ما أستطيع تذكره. لقد حصلت على نفس النتائج إلى حد كبير كما هو موضح أعلاه عندما قمت بالتبديل إلى برنامج التشغيل overlay2 منذ بضعة أيام وقمت بإلغاء تحديد مجلد aufs تمامًا ( docker system df يقول 1.5Gigs ، df يقول 15Gigs) .

كان لدي حوالي 1T من الاختلافات باستخدام التخزين. بعد إعادة تشغيل برنامج Docker daemon - استعدت حوالي 700 جيجابايت. لذلك أعتقد أن وقف الخوخ الخفي هذه؟

إعادة التشغيل لا تفعل شيئًا بالنسبة لي ، للأسف.

إعادة تشغيل الخدمة لم يساعد. هذه مشكلة خطيرة. لا تؤدي إزالة كل الحاوية / الصور إلى إزالة تلك الاختلافات.

لن يؤدي إيقاف البرنامج الخفي إلى تقليمها.

إذا قمت بإزالة جميع الحاويات ولا يزال لديك diff dirs ، فمن المحتمل أن يكون لديك بعض طبقات rw المسربة.

لقد واجهنا هذه المشكلة للتو. استحوذ /var/lib/docker/aufs/diff على 28 جرامًا ونقل نظام ملفات الجذر إلى 100٪ ، مما تسبب في توقف خادم GitLab عن الاستجابة. نحن نستخدم عامل ميناء لـ GitLab CI. لإصلاح ذلك ، استخدمت بعض الأوامر sogetimaitral المقترحة أعلاه لحذف ملفات temp ، ونحن نعمل على إعادة التشغيل. أعدت تشغيل الخادم وأرسلت التزامًا جديدًا لتشغيل CI ، ويبدو أن كل شيء يعمل كما ينبغي.

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

1. نعم ، يوجد خطأ (كل من وجود مشكلات في الإزالة وأن - يتجاهل فرض rm هذه المشكلات)
2. بشكل عام ، لا ينبغي على المرء أن يكتب الكثير من البيانات إلى الحاوية fs وبدلاً من ذلك يستخدم مجلدًا (حتى حجم التخلص منه). قد يشير اختلاف دير كبير إلى وجود كميات كبيرة من البيانات التي تتم كتابتها في الحاوية fs.

إذا لم تستخدم "--force" عند الإزالة ، فلن تواجه هذه المشكلة (أو على الأقل سترى أن لديك مجموعة من الحاويات "الميتة" وتعرف كيف / ماذا تنظف.).

أنا لا أستخدم عامل الإرساء يدويًا على الإطلاق. نحن نستخدم gitlab-ci-multi-runner . هل يمكن أن يكون خطأ في نهاية GitLab بعد ذلك؟

يبدو (افتراضيًا) أنه يزيل الحاويات بالقوة ؛ https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/dbdbce2848530df299836768c8ea01e209a2fe40/executors/docker/executor_docker.go#L878. يمكن أن يؤدي القيام بذلك إلى فشل إزالة الحاوية التي يتم تجاهلها ، مما يؤدي إلى الاختلافات المعزولة.

حسنًا ، هذا يخبرني أن هذا خطأ في gitlab-ci-multi-runner. هل هذا تفسير صحيح؟ يسعدني إنشاء مشكلة لهم لإصلاح ذلك.

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

إذا كان بإمكان عداء gitlab العمل بشكل صحيح دون إزالة القوة ، فمن المحتمل أن يكون من الجيد تغييره (أو جعله قابلاً للتهيئة)

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

هل يمكن أن يكون عامل ميناء في قضية Docker؟ أنا أبدأ الطائرة بدون طيار بتكوين عامل ميناء.

قررت المضي قدمًا وإرسال مشكلة gitlab-ci-multi-runner فقط لتكرار المطورين في: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

بصراحة ، عملنا على حل هذا الأمر من خلال تشغيل عامل ميناء Spotify gc باستخدام طائرة بدون طيار CI.

المار، مار. 28 ، 2017 في الساعة 3:38 مساءً ، جيفري فيرتشايلد <
[email protected]> escribió:

قررت المضي قدمًا وإرسال مشكلة gitlab-ci-multi-runner فقط إلى
حلقة المطورين في:
https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/docker/issues/22207#issuecomment-289926298 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AC6Wz197zkjWWOlq1-JOibiQP-xJym9Eks5rqYvegaJpZM4IMGt2
.

sedouard شكرا لهذه النصيحة! أدى تشغيل docker -gc كل ساعة من Spotify إلى حل المشكلة بالنسبة لي.

نحصل على هذه المشكلة قيد التشغيل من Gitlab CI (لا يعمل في docker) ، باستخدام أوامر لإنشاء الصور / تشغيل الحاويات ، (وليس تكامل Gitlab CI Docker). نحن لا نجري أي شكل من أشكال الإزالة القسرية ، ببساطة docker run --rm ... و docker rmi image:tag

تحرير : آسف ، في الواقع المشكلة الأصلية هي نفسها. الفرق هو أن تشغيل spotify/docker-gc لا _لا_ يحل المشكلة.

كما ترون أدناه ، لدي 0 صورة ، 0 حاوية ، لا شيء!
أوافق معي docker system info ، لكنه يذكر Dirs: 38 لتخزين aufs.

ذلك يثير الشك! إذا نظرت إلى /var/lib/docker/aufs/diff/ ، فسنلاحظ أن هناك بالفعل 1.7 جيجا بايت من البيانات هناك ، أكثر من 41 دليلاً. وهذا هو صندوقي الشخصي ، على خادم الإنتاج ، يبلغ حجمه 19 غيغابايت.

كيف ننظف هذا؟ استخدام spotify/docker-gc لا يزيل هذه.

philippe@pv-desktop:~$ docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE

philippe@pv-desktop:~$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

philippe@pv-desktop:~$ docker system info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 17.03.1-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 38
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 4ab9917febca54791c5f071a9d1f404867857fcc
runc version: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-72-generic
Operating System: Ubuntu 16.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 31.34 GiB
Name: pv-desktop
ID: 2U5D:CRHS:RUQK:YSJX:ZTRS:HYMV:HO6Q:FDKE:R6PK:HMUN:2EOI:RUWO
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: silex
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

philippe@pv-desktop:~$ ls -alh /var/lib/docker/aufs/diff/
total 276K
drwxr-xr-x 40 root root 116K Apr 13 15:32 .
drwxr-xr-x  5 root root 4.0K Sep 18  2015 ..
drwxr-xr-x  4 root root 4.0K Jun 17  2016 005d00efb0ba949d627ad439aec8c268b5d55759f6e92e51d7828c12e3817147
drwxr-xr-x  8 root root 4.0K May  2  2016 0968e52874bbfaa938ffc869cef1c5b78e2d4f7a670e19ef47f713868b9bfbdf
drwxr-xr-x  4 root root 4.0K Jun 20  2016 188233e6dcc37e2308e69807ffd19aca3e61be367daae921f2bcb15a1d6237d0
drwxr-xr-x  6 root root 4.0K Jun 20  2016 188233e6dcc37e2308e69807ffd19aca3e61be367daae921f2bcb15a1d6237d0-init
drwxr-xr-x 21 root root 4.0K Apr  8  2016 250ecb97108a6d8a8c41f9d2eb61389a228c95f980575e95ee61f9e8629d5180
drwxr-xr-x  2 root root 4.0K Dec 22  2015 291f16f99d9b0bc05100e463dbc007ef816e0cf17b85d20cf51da5eb2b866810
drwxr-xr-x  2 root root 4.0K May  2  2016 3054baaa0b4a7b52da2d25170e9ce4865967f899bdf6d444b571e57be141b712
drwxr-xr-x  2 root root 4.0K Feb  5  2016 369aca82a5c05d17006b9dca3bf92d1de7d39d7cd908ed665ef181649525464e
drwxr-xr-x  3 root root 4.0K Jun 17  2016 3835a1d1dfe755d9d1ada6933a0ea7a4943caf8f3d96eb3d79c8de7ce25954d2
(...strip)

philippe@pv-desktop:~$ du -hs /var/lib/docker/aufs/diff/
1.7G    /var/lib/docker/aufs/diff/

philippe@pv-desktop:~$ docker system prune -a
WARNING! This will remove:
    - all stopped containers
    - all volumes not used by at least one container
    - all networks not used by at least one container
    - all images without at least one container associated to them
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0 B

هل يمكنني بأمان rm -r /var/lib/docker/aufs وإعادة تشغيل docker deamon؟

تشغيل spotify/docker-gc لا ينظف هؤلاء الأيتام.

تحرير : شكرا CVTJNII!

سيكون إيقاف Docker daemon ومحو كل / var / lib / docker أكثر أمانًا. سيؤدي مسح / var / lib / docker / aufs إلى فقد صورك على أي حال ، لذا من الأفضل أن تبدأ بنظافة / var / lib / docker في رأيي. هذا هو "الحل" الذي كنت أستخدمه منذ عدة أشهر لهذه المشكلة الآن.

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

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

@ cpuguy83 : أخبار رائعة ، هل يمكنك شرح ما يجب على المشرف فعله إذا حدث ذلك؟

Silex هذا يعتمد على السبب.
عادة ما يحدث هو أن هناك خطأ device or resource busy بسبب تسرب بعض التحميل إلى الحاوية. إذا كنت تقوم بتشغيل شيء مثل cadvisor ، فهذا ضمان إلى حد كبير حيث تنص التعليمات على تركيب دير docker بأكمله في حاوية cadvisor.

قد يكون هذا أمرًا صعبًا ، فقد تضطر إلى إيقاف الحاوية (الحاويات) المخالفة ثم إزالة الحاوية dead .

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

إصدار Docker 17.06.0-ce ، الإصدار 02c1d87

حاولت إزالة جميع الصور والمجلدات والشبكات والحاويات لكنها لم تساعد.
جربت أيضًا الأوامر:

docker system prune -af
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc:ro spotify/docker-gc

لا تزال ملفات:

root<strong i="11">@Dark</strong>:/var/lib/docker/aufs# ls -la *
diff:
total 92
drwx------ 12 root root 45056 Jul 28 17:28 .
drwx------  5 root root  4096 Jul  9 00:18 ..
drwxr-xr-x  4 root root  4096 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882
drwxr-xr-x  6 root root  4096 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882-init
drwxr-xr-x  5 root root  4096 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd
drwxr-xr-x  6 root root  4096 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd-init
drwxr-xr-x  4 root root  4096 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac
drwxr-xr-x  6 root root  4096 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac-init
drwxr-xr-x  4 root root  4096 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4
drwxr-xr-x  6 root root  4096 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4-init
drwxr-xr-x  6 root root  4096 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb
drwxr-xr-x  6 root root  4096 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb-init

layers:
total 52
drwx------ 2 root root 45056 Jul 28 17:28 .
drwx------ 5 root root  4096 Jul  9 00:18 ..
-rw-r--r-- 1 root root     0 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882
-rw-r--r-- 1 root root     0 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882-init
-rw-r--r-- 1 root root     0 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd
-rw-r--r-- 1 root root     0 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd-init
-rw-r--r-- 1 root root     0 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac
-rw-r--r-- 1 root root     0 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac-init
-rw-r--r-- 1 root root     0 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4
-rw-r--r-- 1 root root     0 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4-init
-rw-r--r-- 1 root root     0 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb
-rw-r--r-- 1 root root     0 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb-init

mnt:
total 92
drwx------ 12 root root 45056 Jul 28 17:28 .
drwx------  5 root root  4096 Jul  9 00:18 ..
drwxr-xr-x  2 root root  4096 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882
drwxr-xr-x  2 root root  4096 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882-init
drwxr-xr-x  2 root root  4096 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd
drwxr-xr-x  2 root root  4096 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd-init
drwxr-xr-x  2 root root  4096 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac
drwxr-xr-x  2 root root  4096 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac-init
drwxr-xr-x  2 root root  4096 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4
drwxr-xr-x  2 root root  4096 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4-init
drwxr-xr-x  2 root root  4096 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb
drwxr-xr-x  2 root root  4096 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb-init

# docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              0                   0                   0B                  0B
Containers          0                   0                   0B                  0B
Local Volumes       0                   0                   0B                  0B

كيف يمكن حذفه؟

@ haos616 حاول إيقاف تشغيل جميع الحاويات أولاً ، ثم قم بتشغيل docker system prune -af .
هذا فعل الخدعة لي.
لم أعمل أثناء تشغيل حاوية.

إذا كانت ترقية من إصدار سابق من docker ، فمن المحتمل أن تكون هذه الاختلافات قد تم إنشاؤها / تركها وراء ذلك الإصدار. لن يزيل Docker 17.06 حاوية إذا فشلت إزالة الطبقات (عند استخدام --force) ؛ الإصدارات القديمة فعلت ذلك ، مما قد يؤدي إلى طبقات معزولة

@ julian-pani لقد فعلت ذلك في البداية لكنه لا يساعد.

# docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              0                   0                   0B                  0B
Containers          0                   0                   0B                  0B
Local Volumes       0                   0                   0B                  0B

thaJeztah لا. لقد قمت بتنظيف Docker منذ شهر أو شهرين. ثم كان الإصدار بالفعل 17.06. لقد استخدمت الأمر docker system prune -af . أزال كل شيء.

تشغيل https://github.com/spotify/docker-gc كحاوية عملت معي ، لكنها ذهبت خطوة إضافية وحذفت بعض صوري المطلوبة أيضًا :(

لذلك قمت بوضع برنامج نصي مغلف صغير على النحو التالي ليكون آمنًا

#!/bin/sh
docker images -q > /etc/docker-gc-exclude    # Save all genuine images as exclude
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc:ro spotify/docker-gc

شكرا مرة أخرى على Spotify

IIUC ، يستدعي البرنامج النصي Spotify docker rm و docker rmi - هل قام بالفعل بإزالة الاختلافات المعزولة؟

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

fuzzygroup 17.06 يجب ألا ينشئ الفروق القديمة بعد.

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

https://gist.github.com/Karreg/84206b9711cbc6d0fbbe77a57f705979

https://stackoverflow.com/q/45798076/562769 يبدو أنه مرتبط. لقد نشرت إصلاحًا سريعًا.

لمعلوماتك ، ما زلت أرى هذا بـ 17.06.1-ce

Containers: 20
 Running: 0
 Paused: 0
 Stopped: 20
Images: 124
Server Version: 17.06.1-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 185
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
runc version: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
init version: 949e6fa
Security Options:
 apparmor
Kernel Version: 4.4.0-83-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 7.796GiB
Name: gitlab-cirunner
ID: PWLR:R6HF:MK3Y:KN5A:AWRV:KHFY:F36D:WASF:7K7B:U7FY:2DJA:DBE2
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

/var/lib/docker/aufs/diff على الكثير من الأدلة مع البادئة -init-removing و -removing :

ffd5477de24b0d9993724e40175185038a62250861516030a33280898243e742-removing
ffd900de0634992e99c022a16775805dfd0ffd1f6c89fece7deb6b1a71c5e38c-init-removing
ffd900de0634992e99c022a16775805dfd0ffd1f6c89fece7deb6b1a71c5e38c-removing

لمعلوماتك ، ما زلت أرى هذا مع 17.06.1-CE

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

ما زلت أرى الفرق اليتيم بقدر ما أستطيع أن أقول. لم يقم docker system prune بإزالتها ولا docker-gc . يبدو أن تشغيل rm -rf /var/lib/docker/aufs/diff/*-removing يدويًا يعمل.

نعم ، لن يقوم عامل الميناء بتنظيف الأيتام القديمة حتى الآن.

تقصد بالعمر تلك التي تم إنشاؤها من إصدار سابق من عامل الميناء مع هذه المشكلة؟

هذا تثبيت جديد لـ Docker قمنا به منذ حوالي أسبوعين ، يجب أن يكون هؤلاء الأيتام قد تم إنشاؤهم منذ ذلك الحين ، لذلك يبدو أن عامل التحميل لا يزال ينشئ هؤلاء الأيتام؟

أعني ، في النصف ساعة الماضية ، حصلت على 112 فرق جديدة مع -removing ، منذ أن قمت بتثبيتها يدويًا.

$ ls /var/lib/docker/aufs/diff/ | grep removing | wc -l
112

لقد قلت "17.06 لم يعد يجب أن ينشئ فرقًا يتيمًا ، لكنه لن ينظف الفروق القديمة بعد." ، لكن بالتأكيد هذا لا يمكن أن يكون صحيحًا ، أم أنني أفتقد شيئًا ما؟ هل هؤلاء الذين تم وضع علامة عليهم بـ -removing يتيمة؟

orf في نواة أحدث ، من غير المتوقع حدوث أي مشكلة على الإطلاق أثناء الإزالة. هل تقوم بتركيب /var/lib/docker في حاوية؟

سوف أتحقق من برنامج تشغيل aufs لمعرفة ما إذا كانت هناك مشكلة معينة تتعلق بالإبلاغ عن إزالة ناجحة عندما لم تكن كذلك بالفعل.

نحن لا نقوم بتركيب /var/lib/docker في حاوية.

$ uname -a
Linux gitlab-cirunner 4.4.0-83-generic #106~14.04.1-Ubuntu SMP Mon Jun 26 18:10:19 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

نحن نشغل 14.04 LTS

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

لأسباب أخرى (شبكات وضع السرب) ، انتقلت إلى 14.04 من Docker
الآلات.
في يوم الاثنين 21 أغسطس 2017 الساعة 8:23 صباحًا أو كتب orf [email protected] :

نحن لا نقوم بتركيب / var / lib / docker في حاوية.

$ uname -a
Linux gitlab-cirunner 4.4.0-83-generic # 106 ~ 14.04.1-Ubuntu SMP الاثنين 26 يونيو 18:10:19 بالتوقيت العالمي المنسق 2017 x86_64 x86_64 x86_64 GNU / Linux

نحن نشغل 14.04 LTS

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/22207#issuecomment-323773033 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AADRIfE2B2HNpbsKyTOj1CwGzulRT2C0ks5saaDPgaJpZM4IMGt2
.

يبدو أن هذا أسوأ مع 17.06.01 م. لقد قمت بتحديث آلة بناء إلى هذا الإصدار وبدأت فورًا في رؤية الدلائل *-init-removing و *-removing المتبقية كجزء من عملية الإنشاء. لقد أوقفت الخدمة ، وأزلت الدليل /var/lib/docker ، وأعدت تشغيل الخدمة ، وبعد بضع نسخ كانت قريبة من مساحة القرص مرة أخرى. أوقفت الخدمة مرة أخرى ، وقمت بتشغيل apt-get purge docker-ce ، وأزلت /var/lib/docker مرة أخرى وقمت بتثبيت الإصدار 17.06.0-ce. عدم الحصول على الدلائل الإضافية في /var/lib/docker/aufs/diff ومساحة القرص تمثل الصور الموجودة على جهاز الإنشاء. لقد قمت بإعادة إنتاج السلوك على جهاز التطوير الخاص بي أيضًا - يبدو أن مجرد إنشاء صورة يؤدي إلى إنشاء هذه الأدلة الإضافية لكل طبقة من طبقات الصورة ، لذا فقد تنفد مساحة القرص بسرعة كبيرة. مرة أخرى ، يبدو أن العودة إلى 17.06.0-ce ليس بها مشكلة لذا سأبقى هناك الآن.

mmanderson شكرا على الإبلاغ. إلقاء نظرة على التغييرات في برنامج تشغيل AUFS.

mmanderson هل لديك أي حاويات في حالة Dead في docker ps -a ؟

جميع خوادم بناء عامل الإرساء الخاصة بي تنفد من المساحة.

لقد قمت بالترقية خلال الأسبوع الماضي أو نحو ذلك إلى إصدار Docker 17.06.1-ce ، بناء 874a737. أعتقد أنه لم يتغير شيء آخر وأن هذه المشكلة إما ظهرت أو تجلت كجزء من عملية الترقية. دليل aufs فرق ضخم ولقد قمت بالفعل بتشذيب جميع الصور والأحجام المتدلية.

الإصدار 22207.txt
@ cpuguy83 لا توجد حاويات في أي دولة. هذا ما فعلته بالكاد لإثبات ذلك مع 17.06.01-ce:

1. بدأ بتثبيت جديد لـ Docker 17.06.01-ce على Ubuntu 16.04.03 LTS (أي أن عامل الإرساء غير مثبت ودليل no / var / lib / docker). بعد التثبيت ، تم التحقق من دليل / var / lib / docker / aufs / diff فارغ.
2. قم بتشغيل docker build باستخدام ملف dockerfile بسيط إلى حد ما يعتمد على ubuntu: الأحدث - كل ما يفعله هو سحب statsd_exporter من github واستخراجه إلى / usr / bin (انظر الملف المرفق).
3. بعد تشغيل الإصدار ، قم بتشغيل docker ps -a لإظهار عدم وجود حاويات في أي حالة. يوجد العديد من المجلدات *-remaining في المجلد /var/lib/docker/aufs/diff .
4. قم بتشغيل docker system df للتحقق من الصور والحاويات والمجلدات. النتيجة

TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              2                   0                   132.7MB             132.7MB (100%)
Containers          0                   0                   0B                  0B
Local Volumes       0                   0                   0B                  0B

1. تشغيل du -sch /var/lib/docker/*/ يظهر 152 /var/lib/docker/aufs/ مقابل
2. قم بتشغيل docker rmi $(docker images -q) لإزالة طبقات الصورة المبنية. تشغيل docker system df بعد هذا يظهر جميع الأصفار. تشغيل du -sch /var/lib/docker/*/ يظهر 152 مليونًا مقابل /var/lib/docker/aufs/ وهناك مجلدات *-remaining لجميع المجلدات التي لم تكن موجودة من قبل مع المجلدات الحالية *-remaining التي لا تزال هناك.

erikh هل هذه هي المشكلة التي تواجهها؟

@ cpuguy83 بعد إزالة تثبيت 17.06.01-ce ، وإزالة دليل / var / lib / docker وتثبيت 17.06.0-ce ، أحاول تشغيل نفس البنية. فشل الإصدار بسبب الخطأ ADD from remote URL's الذي تم إصلاحه في 17.06.01. ومع ذلك ، لا أحصل على أي أدلة *-remaining للخطوات التي اكتملت ، وبعد تنظيف كل شيء باستخدام docker system prune و docker rmi $(docker image -q) الدليل /var/lib/docker/aufs/diff فارغًا مرة أخرى ويتم تحرير المساحة.

شكرا للجميع ، هذا تراجع في 17.06.1 ...
العلاقات العامة لإصلاحها هنا: https://github.com/moby/moby/pull/34587

رائع ، شكرًا على التصحيح السريع @ cpuguy83! / سم مكعب erikh

@ روجا! نعم ، شكرا لك و @ cpuguy83!

شكرًا جزيلاً لك @ Karreg على الممتاز . بعد التخلص من جميع الاختلافات القديمة وتحرير كميات هائلة من مساحة القرص المفقودة مرة أخرى ، فإننا نستخدمها الآن بانتظام لتنظيف أجهزة VM الخاصة بنا قبل تثبيت صور عامل إرساء جديدة. مساعدة كبيرة وحلاً شبه مثالي لهذه المشكلة الآن. @ TP75

يبدو أن شركة Docker، Inc. لديها بعض العقود مع الشركات المصنعة لتخزين بيانات الكمبيوتر.

عمل نص Karreg بشكل جيد بالنسبة لي وقمت بتحرير كل المساحة في دليل diffs.

وجود نفس المشكلة.
تفاصيل مضيف عامل ميناء

الجذر @ UbuntuCont : ~ # معلومات عامل ميناء
الحاويات: 3
الجري: 0
متوقف مؤقتًا: 0
متوقف: 3
الصور: 4
إصدار الخادم: 17.06.1-ce
سائق التخزين: aufs
الجذر Dir: / var / lib / docker / aufs
دعم نظام الملفات: extfs
Dirs: 14
Dirperm1 المدعومة: صحيح
برنامج تشغيل التسجيل: ملف json
برنامج تشغيل Cgroup: cgroupfs
الإضافات:
الحجم: محلي
الشبكة: تراكب فارغ macvlan لمضيف الجسر
السجل: Awslogs fluentd gcplogs gelf journalald json-file logentries splunk syslog
سرب: غير نشط
أوقات التشغيل: runc
وقت التشغيل الافتراضي: runc
ثنائي أولي: docker-init
إصدار الحاوية: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
إصدار runc: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
إصدار init: 949e6fa
خيارات الأمان:
أبارمور
سيكومب
الملف الشخصي: الافتراضي
إصدار النواة: 4.4.0-93-عام
نظام التشغيل: Ubuntu 16.04.3 LTS
OSType: لينكس
العمارة: x86_64
وحدات المعالجة المركزية: 1
إجمالي الذاكرة: 3.358 جيجا بايت
الاسم: UbuntuCont
المعرّف: QQA5: DC5S: C2FL: LCC6: XY6E: V3FR: TRW3: VMOQ: QQKD : AP2M: H3JA: I6VX
Docker Root Dir: / var / lib / docker
وضع التصحيح (العميل): خطأ
وضع التصحيح (الخادم): خطأ
التسجيل: https://index.docker.io/v1/
التجريبية: خطأ
السجلات غير الآمنة:
127.0.0.0 / 8
تمكين الاستعادة الحية: خطأ

root @ UbuntuCont : / var / lib / docker / aufs / diff # ls
031c85352fe85f07fede77dee0ac9dc2c7723177a819e72c534e1399208c95fa
09d53040e7e6798b5987ea76fe4f84f0906785b94a392a72e8e41a66cd9f242d
09d53040e7e6798b5987ea76fe4f84f0906785b94a392a72e8e41a66cd9f242d-init
0fb1ffc90969e9706801e2a18870f3ecd857a58f1094fbb968b3fa873e4cf2e4
10549179bd21a9c7af018d4ef305bb9196413b9662fce333b607104c40f38781
10d86a48e03cabf9af2c765dc84824809f24674ac339e4b9ffe572f50bd26b9c-init-remove
10d86a48e03cabf9af2c765dc84824809f24674ac339e4b9ffe572f50bd26b9c إزالة
2e226946e8e6c2b3613de2afcff4cbb9890b6d9bd365fdda121a51ae96ec5606
2e226946e8e6c2b3613de2afcff4cbb9890b6d9bd365fdda121a51ae96ec5606-init
3601f6953132f557df8b52e03016db406168d3d6511d7ff5c08a90925ea288da-init-remove
3601f6953132f557df8b52e03016db406168d3d6511d7ff5c08a90925ea288da- إزالة
4b29141243aea4e70472f25a34a91267ab19c15071862c53e903b99740603d4c-init-remove
4b29141243aea4e70472f25a34a91267ab19c15071862c53e903b99740603d4c إزالة
520e3fcf82e0fbbb48236dd99b6dee4c5bb9073d768511040c414f205c787dc5-init-remove
520e3fcf82e0fbbb48236dd99b6dee4c5bb9073d768511040c414f205c787dc5 إزالة
59cbb25a4858e7d3eb9146d64ff7602c9abc68509b8f2ccfe3be76681481904f
5d1c661b452efce22fe4e109fad7a672e755c64f538375fda21c23d49e2590f6
605893aba54feee92830d56b6ef1105a4d2166e71bd3b73a584b2afc83319591
63bd53412210f492d72999f9263a290dfee18310aa0494cb92e0d926d423e281-init-remove
63bd53412210f492d72999f9263a290dfee18310aa0494cb92e0d926d423e281-إزالة
72146e759ab65c835e214e99a2037f4b475902fdbe550c46ea0d396fb5ab2779-init-remove
72146e759ab65c835e214e99a2037f4b475902fdbe550c46ea0d396fb5ab2779-إزالة
8147e0b06dcbce4aa7eb86ed74f4ee8301e5fe2ee73c3a80dcb230bd0ddfcc26-init-remove
8147e0b06dcbce4aa7eb86ed74f4ee8301e5fe2ee73c3a80dcb230bd0ddfcc26-إزالة
a72735551217bb1ad01b77dbdbb9b8effa9f41315b0c481f8d74b5606c50deb4
aa58f2000b9f7d1ed2a6b476740c292c3c716e1d4dc04b7718580a490bba5ee8
b552cb853e33a8c758cb664aec70e2c4e85eacff180f56cbfab988a8e10c0174-إزالة
cd80c351b81ed13c4b64d9dfdc20c84f6b01cbb3e26f560faf2b63dae12dec55-init-remove
cd80c351b81ed13c4b64d9dfdc20c84f6b01cbb3e26f560faf2b63dae12dec55-إزالة
fe903be376821b7afee38a016f9765136ecb096c59178156299acb9f629061a2
fe903be376821b7afee38a016f9765136ecb096c59178156299acb9f629061a2-init

kasunsjc يرجى قراءة المشاركات الموجودة فوق

أؤكد أن الترقية إلى 17.06.2-ce قد حلت هذه المشكلة. لم أكن مضطرًا إلى استخدام الدلائل يدويًا (آخر مرة) بعد الترقية.

يبدو أن 17.06.2-ce _ قد أصلح هذا بالنسبة لي أيضًا. لا يوجد المزيد من الدلائل -removing هناك ، حصلت على قدر مناسب من المساحة.

أفترض أن الدلائل -init لدي في aufs/diff ليست ذات صلة (بعضها قديم جدًا). كلهم صغيرون ، لذلك لا يهم.

أدى التحديث إلى 17.07.0 إلى حل المشكلة هنا أيضًا ، ولن يقوم حتى docker system prune --all -f بإزالة الدلائل من قبل ولكن بعد الترقية ، تمت إزالتها تلقائيًا عند إعادة التشغيل.

تم حل تأكيد هذه المشكلة على Ubuntu 16.04 مع 17.06.2-ce. بمجرد تحديثه ، تم إخلاء المساحة.