# 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

Ich sollte auch zeigen, dass Docker keine Container, Volumes oder Bilder auflistet:

$ 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

seltsam; vor allem wegen;

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

was nicht mit der Ausgabe von docker images / docker ps übereinstimmt.

Auf welchem ​​Betriebssystem laufen Sie?

Operating System: <unknown>

@tonistiigi eine Idee?

Das war danach. Ich denke, einige Prozesse haben in der Zwischenzeit begonnen.

Der Zustand, auf den ich mich beziehe (den ich jetzt habe), ist:

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

Und ich habe noch:

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

Wir sind auf Ubuntu Lucid mit einem aktualisierten Kernel = /

$ 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

Es scheint ein interessantes Thema.
ist es möglich, eine Möglichkeit zu haben, es zu reproduzieren? @bukzor

Sicher ist es möglich, aber ich weiß nicht wie.
Bitte versuchen Sie, das folgende Skript auf einem Ihrer aktiven Docker-Hosts auszuführen, und sehen Sie, was noch übrig ist.
In unserem Fall bleiben immer viele Unterschiede zurück.

`` `#! bash

! / bin / bash

setze -eu

echo "WARNUNG :: Dies stoppt ALLE Docker-Prozesse und entfernt ALLE Docker-Images."
read -p "Weiter (j / n)?"
if ["$ REPLY"! = "y"]; dann
Echo "Abbruch."
Ausfahrt 1
fi

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

setze -x

Behälter entfernen

Docker ps -q | xdocker stop
Docker ps -aq | xdocker rm

Tags entfernen

Docker-Bilder | sed 1d | grep -v '^'| col 1 2 | sed 's / /: /' | xdocker rmi

Bilder entfernen

Docker-Bilder -q | xdocker rmi
Docker-Bilder -aq | xdocker rmi

Volumes entfernen

Docker-Volume ls -q | xdocker Volumen rm
`` `

Eine Möglichkeit, wie ich das sehe, ist, dass beim Aufheben der Bereitstellung Fehler auftreten. Wenn beispielsweise EBUSY-Fehler auftreten, wurde die Image-Konfiguration wahrscheinlich bereits zuvor gelöscht.

@bukzor Wäre sehr interessant, wenn es einen Reproducer gäbe, der aus einem leeren abruft / ausführt und in einen Zustand versetzt, in dem er nach dem Ausführen Ihres Skripts nicht vollständig bereinigt wird.

Das wäre interessant, klingt aber nach einem ganzen Arbeitstag.
Darauf kann ich mich nicht festlegen.

Hier sind einige weitere Daten bezüglich des (willkürlich ausgewählten) störenden Unterschieds oben, a800 .

`` `#! Sh
$ docker-find a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea | sudo xargs -n1 wc -l | sort -rn

• sudo find / nagel / var / lib / docker '(' -pfad '/ nagel / var / lib / docker / aufs / diff / ' -o -pfad '/ nagel / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -print
• grep a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
• sudo find / nagel / var / lib / docker '(' -pfad '/ nagel / var / lib / docker / aufs / diff / ' -o -pfad '/ nagel / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -type f -print0
• sudo xargs -0 -P20 grep -l a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
  15 / nagel / var / lib / docker / aufs / schichten / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579
  14 / nagel / var / lib / docker / aufs / schichten / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579-init
  13 / nagel / var / lib / docker / aufs / schichten / 993e4988c510ec3ab4f6d139740a059df40585576f8196817e573a9684554c5c
  12 / nagel / var / lib / docker / aufs / schichten / cf9fd1c4a64baa39b6d6d9dac048ad2fff3c3fe13924b07377e767eed230ba9f
  11 / nagel / var / lib / docker / aufs / schichten / 4e6afb958b5ee6dea6d1a886d19fc9c780d4ecc4baeebfbde31f9bb97732d10d
  10 / nagel / var / lib / docker / aufs / schichten / 23ce5a473b101d85f0e9465debe5a0f3b8a2079b99528a797b02052d06bc11d8
  9 / nagel / var / lib / docker / aufs / schichten / 95e68d59a8704f2bb52cc1306ca910ddb7af8956eb7c57970fcf7d8b3d9baddb
  8 / nagel / var / lib / docker / aufs / schichten / ac6b8ff4c0e7b91230ebf4c1caf16f06c1fdceff6111fd58f4ea50fc2dd5050b
  7 / nagel / var / lib / docker / aufs / schichten / fd895b6f56aedf09c48dba97931a34cea863a21175450c31b6ceadde03f7b3da
  6 / nagel / var / lib / docker / aufs / schichten / d5bbef5adf2efb6f15d4f96c4bee21beb955255d1ec17baf35de66e98e6c7328
  5 / nagel / var / lib / docker / aufs / schichten / 9646360df378b88eae6f1d6288439eebd9647d5b9e8a471840d4a9d6ed5d92a4
  4 / nagel / var / lib / docker / aufs / schichten / a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
  0 / nagel / var / lib / docker / 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 / nagel / var / lib / docker '(' -pfad '/ nagel / var / lib / docker / aufs / diff / ' -o -pfad '/ nagel / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -print
• grep --color 'f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 $'
  / Nagel / var / lib / Docker / aufs / Schichten / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579
• sudo find / nagel / var / lib / docker '(' -pfad '/ nagel / var / lib / docker / aufs / diff / ' -o -pfad '/ nagel / 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 / nagel / var / lib / docker '(' -pfad '/ nagel / var / lib / docker / aufs / diff / ' -o -pfad '/ nagel / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -print
• grep --color 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 / parent
• sudo find / nagel / var / lib / docker '(' -pfad '/ nagel / var / lib / docker / aufs / diff / ' -o -pfad '/ nagel / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -type f -print0
• sudo xargs -0 -P20 grep --color -l eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e
  `` `

Gibt es eine Möglichkeit herauszufinden, für welchen Container diese Halterung verwendet wurde?
Das Dokument sagt nur, dass die Mount-ID nicht mehr mit der Container-ID übereinstimmt, was nicht sehr hilfreich ist.
https://docs.docker.com/engine/userguide/storagedriver/aufs-driver/

@bukzor eb809c0321 ist die Container-ID. Was Dokumente bedeuten, ist, dass die aufs-ID (in Ihrem Fall f3286009193f ) keine Container-ID ist.

/ cc @dmcgowan auch

@tonistiigi OK.

Dann hat die Montierung offensichtlich ihren Container überlebt.

Zu welchem ​​Zeitpunkt im Containerlebenszyklus wird die Halterung bereinigt?
Ist dies das temporär beschreibbare aufs für laufende / gestoppte Container?

@bukzor (rw) mount wird beim Löschen des Containers gelöscht. Das Aufheben der Bereitstellung erfolgt beim Stoppen des Containerprozesses. Diff-Ordner sind ein Ort, an dem die einzelnen Ebeneninhalte gespeichert werden. Es spielt keine Rolle, ob die Ebene bereitgestellt ist oder nicht.

@bukzor Der Link zwischen der aufs-ID und der Container-ID befindet sich unter image/aufs/layerdb/mounts/<container-id>/mount-id . Wenn Sie nur eine aufs-ID kennen, können Sie die Container-ID am einfachsten finden, indem Sie das Verzeichnis image/aufs/layerdb durchsuchen. Wenn nichts gefunden wird, wurde die Bereinigung nicht sauber abgeschlossen.

Ähnliches Problem.

Wir führen täglich CI auf dem Docker-Daemon-Server aus. / var / lib / docker / aufs / diff beansprucht ziemlich viel Festplattenkapazität, was es nicht sein sollte.

Immer noch 2gb in aufs/diff nachdem Sie alles Vernünftige ausprobiert haben, was hier oder in verwandten Threads vorgeschlagen wurde (einschließlich des Bash-Skripts von

Gibt es eine einfache Möglichkeit, die verbleibenden Halterungen zu entfernen, ohne alle anderen Bilder gleichzeitig zu entfernen? (Wenn derzeit keine Container ausgeführt werden, sollte es wohl keine Halterungen geben, oder?)

Ich habe das gleiche Problem. Ich benutze diese Maschine, um viele Container zu testen und dann festzuschreiben / zu löschen. Mein Verzeichnis / var / lib / docker / aufs ist derzeit 7,9 G schwer. Ich muss dieses Verzeichnis an einen anderen Mount-Punkt verschieben, da der Speicherplatz in diesem Verzeichnis begrenzt ist. :((

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

@mcallaway Alles in aufs/diff werden fs-Schreibvorgänge sein, die in einem Container ausgeführt werden.

Ich habe das gleiche Problem. Alle Container, die ich habe, sind im laufenden Zustand, aber es gibt viele aufs diff-Verzeichnisse, die sich nicht auf diese Container und auf alte entfernte Container beziehen. Ich kann sie manuell entfernen, aber es ist keine Option. Es sollte einen Grund für ein solches Verhalten geben.

Ich benutze k8s 1.3.5 und Docker 1.12.

Das Ausführen des docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc spotify/docker-gc geholfen.

Ich habe das gleiche Problem. Ich benutze Gitlab CI mit dind (Docker in Docker).

IMHO, wenn das Bild in der Registrierung innerhalb desselben Tags aktualisiert und abgerufen wurde, wurde der zugehörige Container neu gestartet. Der alte Container und das Bild werden nicht gced, es sei denn, Sie führen spotify/docker-gc .

Kann jemand anderes dies bestätigen?

@ Kayrus richtig, Docker geht nicht automatisch davon aus, dass ein "nicht getaggtes" Bild auch _removed_ sein sollte. Container verwenden dieses Image möglicherweise weiterhin, und Sie können weiterhin neue Container von diesem Image aus starten (indem Sie anhand der ID darauf verweisen). Sie können "baumelnde" Bilder mit docker rmi $(docker images -qa -f dangling=true) entfernen. Außerdem erhält Docker 1.13 Datenverwaltungsbefehle (siehe https://github.com/docker/docker/pull/26108), mit denen Sie nicht verwendete Bilder, Container usw. einfacher bereinigen können.

@thaJeztah enthält /var/lib/docker/aufs/diff/ tatsächlich die "nicht getaggten" Bilder?

@ Kayrus Ja, sie sind Teil der Bilder (markiert und nicht markiert)

ein ähnliches Problem bekommen, keine Container / Bilder / Volumes, ~ 13 GB Unterschiede

$ 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

Gleiches Problem hier. Ich verstehe, dass 1.13 möglicherweise Datenverwaltungsbefehle erhält, aber in der Zwischenzeit möchte ich nur den Inhalt dieses Verzeichnisses sicher löschen, ohne Docker zu beenden.

Dies ist zu diesem Zeitpunkt relativ blockierend.

Hier gilt das gleiche. Immer noch keine offizielle Lösung?

Ich habe dies in (Docker Community) Slack ein paar Mal angesprochen. Jedes Mal, wenn eine Handvoll Leute eine Liste von Garbage Collection-Skripten / cmds durchläuft, sollte ich sie als Lösung ausführen.

Während diese in der Zwischenzeit geholfen haben (sprich: nicht gelöst - der Raum schleicht sich immer noch in Richtung voll), können wir uns alle einig sein, dass dies nicht die ideale langfristige Lösung ist.

@jadametz 1.13 hat docker system prune .
Darüber hinaus bin ich mir nicht sicher, wie Docker sonst noch helfen kann (offen für Vorschläge). Die Bilder gelangen nicht nur von alleine zum System, sondern auch durch Pulls, Builds usw.

In Bezug auf tatsächlich verwaiste Ebenen (keine Bilder auf dem System, die auf sie verweisen) müssen wir dies separat behandeln.

Ich habe genau das gleiche Problem!

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

Keine Bilder, Container oder Volumes. 42 GB in aufs / diff

Alles, was dazu beiträgt, dieses Verzeichnis sicher zu löschen, wäre sehr nützlich! Versuchte alles in diesem Thread ohne Erfolg. Vielen Dank.

@adamdry nur Skript von Drittanbietern: https://github.com/docker/docker/issues/22207#issuecomment -252560212

Danke @kayrus, ich habe das tatsächlich versucht und es hat meine gesamte Festplattennutzung leicht erhöht und schien nichts mit dem Verzeichnis aufs / diff zu tun zu haben.

Ich habe auch docker system prune ausprobiert, das nicht lief. Und ich habe docker rmi $(docker images -qa -f dangling=true) ausprobiert,

Für alle Interessierten verwende ich dies jetzt, um alle Container, Bilder, Volumes und alten aufs zu bereinigen:

### 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 ###

Viele Inspirationen von hier: 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 Verwenden Sie am besten nicht -f wenn Sie rm / rmi ausführen, da dadurch Fehler beim Entfernen ausgeblendet werden .
Ich betrachte die aktuelle Situation ... in der -f einen Fehler verbirgt und wir dann einen Reststatus haben, der für den Benutzer völlig unsichtbar ist ... als Fehler.

Ich sehe dies auch bei einer völlig neuen und nicht überraschenden Installation:

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 Da es sich um eine Neuinstallation handelt, möchten Sie dies versuchen? https://github.com/docker/docker/issues/22207#issuecomment -266784433

@adamdry Ich habe bereits /var/lib/docker/aufs gelöscht, da dies meine Arbeit blockiert hat. Was erwarten Sie von Ihren Anweisungen? Wenn sie verhindern, dass das Problem in Zukunft erneut auftritt, kann ich versuchen, das Problem neu zu erstellen und Ihre Anweisungen zu befolgen. Wenn der Zweck jedoch nur darin besteht, den Speicherplatz freizugeben, habe ich das bereits erreicht.

@robhaswell Ja, es ging darum, Speicherplatz

Wenn der Build-Prozess während des Builds während des Layer-Build-Prozesses (der auch einen zu kopierenden Blob enthält) unterbrochen wird und anschließend der Container gestoppt wird, bleiben Daten in / var / lib / docker / aufs / diff / zurück. Es zeigte sich ein baumelndes Bild. Auch das Aufräumen hat den Platz nicht freigegeben. Ist es möglich, es als Teil der Docker-System-Bereinigung aufzunehmen? Nur das Löschen der Blob-Daten in diesem Ordner gibt Speicherplatz frei, von dem ich nicht sicher bin, ob er Probleme verursacht oder nicht.

Docker-Version: 1.13.0-rc1

Wenn der Build-Prozess während des Builds während des Layer-Build-Prozesses (der auch einen zu kopierenden Blob enthält) unterbrochen wird und anschließend der Container gestoppt wird, bleiben Daten zurück

Dies könnte auch die Ursache meiner Probleme sein - ich unterbreche viele Builds.

Beim Andockenziehen wurden die folgenden zwei Fälle beobachtet:

1. Wenn der Prozess unterbrochen wird, während Download angezeigt wird (wodurch die Bildebene in / var / lib / docker / tmp / heruntergeladen wird), werden alle Daten in diesem Ordner bereinigt
2. Wenn der Prozess unterbrochen wird, wenn das Extrahieren angezeigt wird (was vermutlich das Extrahieren der Ebene von tmp nach / var / lib / docker / aufs / diff / bedeutet), werden sowohl die tmp- als auch die diff-Blob-Daten bereinigt.

Während des Image-Erstellungsprozesses

1. Beim Unterbrechen des Prozesses beim Senden des Build-Kontexts an den Docker-Daemon (der in meinem Fall Blob-Daten in / var / lib / docker / tmp / kopiert) bleibt er für immer dort und kann nur durch manuelles Löschen durch einen Befehl bereinigt werden. Ich bin nicht sicher, wie die apt Updates im Bild bekommen werden behandelt.
2. Während der Erstellung der Ebene, die Blob-Daten enthält, z. B. ein umfangreiches Software-Setup, arbeitet der Docker-Container weiter an dem Image, wenn der Prozess unterbrochen wird. In meinem Fall bilden nur 1-Layer-Blob-Daten, die bereits im tmp-Ordner verfügbar sind, das gesamte Bild. Wenn der Container jedoch mit dem Docker-Stopp-Befehl gestoppt wird, treten zwei Fälle auf:
   ein. Wenn der Mount-Prozess noch ausgeführt wird, bleiben Daten im Ordner tmp und diff zurück.
   b. Wenn die Daten in den diff-Ordner kopiert werden, werden die Daten aus dem tmp-Ordner entfernt und die Daten im diff-Ordner und möglicherweise im Mount-Ordner belassen.

Wir haben einen automatisierten Erstellungsprozess, der eine Steuerung benötigt, um jeden Erstellungsprozess ordnungsgemäß zu stoppen. Kürzlich wurde ein Prozess vom Kernel aufgrund eines Speichermangels auf einem Computer mit geringer Konfiguration abgebrochen.

Wenn ein Bild aus 2 Ebenen erstellt werden soll, eine Ebene erstellt und die zweite unterbrochen wird, scheint die Docker-Systembereinigung die Daten für den Container der Ebene zu bereinigen, der unterbrochen und der Container gestoppt wurde. Im Falle eines Interrupts werden die Daten der vorherigen Ebenen jedoch nicht bereinigt. Außerdem spiegelte es nicht den gesamten beanspruchten Speicherplatz wider. Diese Tests wurden auf einem AWS, Ubuntu 14.04, x86_64-Bit-System mit aufs-Dateisystem ausgeführt. Führen Sie den Docker-Prune-Test mit Docker 1.13.0 rc3 und Docker 1.12 durch

@ thaJeztah
Bitte lassen Sie mich wissen, wenn ich etwas falsch interpretiere.

Ich habe ein Problem für die /var/lib/docker/tmp -Dateien geöffnet, die nicht bereinigt werden. https://github.com/docker/docker/issues/29486

Docker System Prune scheint die Daten für den Container der Ebene zu bereinigen, der unterbrochen und der Container gestoppt wurde. Im Falle eines Interrupts werden die Daten der vorherigen Ebenen jedoch nicht bereinigt.

Ich habe versucht, diese Situation zu reproduzieren, konnte dies aber mit einem einfachen Fall nicht erkennen.

Beginnen Sie mit einer Neuinstallation leer /var/lib/docker , erstellen Sie eine große Datei für
Testen und eine Docker-Datei;

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

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

Starten Sie docker build und brechen Sie das Erstellen ab, aber nach dem Erstellen
Kontext wurde gesendet;

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

Überprüfen Sie den Inhalt von /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/

Führen Sie den Befehl docker system prune , um Bilder und Container zu bereinigen.

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

Überprüfen Sie den Inhalt von /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/

Ich sehe, dass das -init Mount zurückgelassen wird. Ich werde prüfen, ob wir es lösen können
das (obwohl es nur ein leeres Verzeichnis ist)

Der einzige Unterschied in der Docker-Datei, die ich verwendet hatte, war (verschiedene Ebenen zu erstellen)
Von Grund auf neu
COPY ["./bigfile", "randomNoFile1", /]
COPY ["./bigfile", "randomNoFile2", /]
EOF

Ich bin mir nicht sicher, ob es einen Unterschied macht.

Nein, das Problem betrifft nicht die leeren Init-Ordner. In meinem Fall war es der Blob. Ich kann es jedoch am Montag erneut überprüfen und aktualisieren.

Außerdem wurde eine 5-GB-Datei verwendet, die durch Lesen von Bytes aus dev urandom erstellt wurde.
In Ihrem Fall wird dieselbe Datei zweimal hinzugefügt. Würde das eine einzelne Schicht erzeugen und die zweite Schicht daraus montieren oder wären es zwei separate Schichten? In meinem Fall sind es immer 2 separate Schichten.

@ thaJeztah
Vielen Dank für eine so schnelle Antwort auf das Problem. Das Hinzufügen dieser Funktion wäre eine große Hilfe!

@ monikakatiyar16 Ich habe versucht, dies ebenfalls zu reproduzieren, ADD und RUN abgebrochen habe, konnte aber nach dem Löschen nichts auf aufs/diff lecken lassen. Ich konnte nicht ganz verstehen, welchen Container Sie anhalten, da Container während der Operationen ADD/COPY werden sollten. Wenn Sie einen Wiedergabegerät zusammenstellen können, den wir betreiben könnten, wäre dies sehr dankbar.

Es ist möglich, dass ich etwas falsch mache. Da ich am Wochenende unterwegs bin, werde ich es reproduzieren und am Montag alle erforderlichen Informationen hier aktualisieren.

@tonistiigi @thaJeztah
Ich fühle, dass du recht hast. Es gibt tatsächlich keine Container, die als aktiv und aktiv aufgeführt sind. Stattdessen gibt es tote Container. Die Docker-Systembereinigung hat in meinem Fall nicht funktioniert, möglicherweise, weil der Prozess mit Strg + C nicht abgebrochen wurde. Stattdessen lief es im Hintergrund weiter. In meinem Fall wäre dies der Grund, warum diese Blobs nicht entfernt werden konnten.

Wenn ich den Prozess mit Strg + C unterbreche, wird der Erstellungsprozess abgebrochen, aber im Hintergrund bleibt ein Prozess für Docker-Untar aktiv, der weiter daran arbeitet, das Image zu erstellen. (Hinweis: / var / lib / docker ist mit / home / lib / docker weich verknüpft, um die EBS-Volumes für große Datenmengen in AWS zu verwenden.)

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

Ich habe das Skript angehängt, mit dem ich große Dateien erstellt und das Image erstellt habe (gc_maxpush_pull.sh).

Außerdem wurde das Verhalten des Erstellungsprozesses zum Erstellen eines Bildes angehängt, das es mit Strg + C (DockerBuild_WOProcessKill) unterbricht, und das Erstellen eines Bildes, das es mit Strg + C unterbricht - Beenden des Prozesses (DockerBuild_WithProcessKill).

Verwenden der Befehle -

So erstellen Sie eine große Datei: ./gc_maxpush_pull.sh 1 5gblayer 0 512 1

So erstellen Sie Bilder: ./gc_maxpush_pull.sh 1 5gblayer 1 512 1

DockerBuild.zip

Zu replizierende Schritte:

1. Erstellen Sie eine große Datei mit 5 GB
2. Starten Sie den Erstellungsprozess und unterbrechen Sie ihn erst, nachdem das Senden des Erstellungskontexts beendet ist und der Blob tatsächlich kopiert wird.
3. Nach einer Weile ist das Erstellen des Bildes abgeschlossen und es wird in Docker-Bildern angezeigt (wie in Fall 1, der von mir angehängt wurde - DockerBuild_WOProcessKill).
4. Wenn der Prozess abgebrochen wird, dauert es eine Weile und belässt die Blob-Daten in / diff (was beim plötzlichen Beenden des Prozesses abrupt sein sollte, wie in der Datei - DockerBuild_WithProcessKill angehängt).

Wenn das, was ich annehme, richtig ist, ist dies möglicherweise kein Problem mit der Docker-Bereinigung, sondern mit dem Beenden des Docker-Builds, das für mich irgendwie nicht funktioniert.

Gibt es eine sinnvolle Möglichkeit, den Build-Image-Prozess zu unterbrechen oder zu stoppen, bei der auch die kopierten Daten bereinigt werden (wie beim Docker-Pull behandelt)?

Zuvor habe ich den Prozess nicht beendet. Ich bin auch neugierig, was Docker-Untar macht und warum es in den Ordnern / mnt und / diff und später im Ordner / mnt bereinigt wird.

Getestet mit Docker Version 1.12.5, Build 7392c3b auf AWS

Docker-Info
Behälter: 2
Laufen: 0
Angehalten: 0
Gestoppt: 2
Bilder: 0
Serverversion: 1.12.5
Speichertreiber: aufs
Root Dir: / home / lib / docker / aufs
Sichern des Dateisystems: extfs
Dirs: 4
Dirperm1 Unterstützt: false
Protokollierungstreiber: JSON-Datei
Cgroup-Treiber: cgroupfs
Plugins:
Lautstärke: lokal
Netzwerk: Overlay-Bridge-Null-Host
Schwarm: inaktiv
Laufzeit: runc
Standardlaufzeit: runc
Sicherheitsoptionen: Apparmor
Kernel-Version: 3.13.0-105-generic
Betriebssystem: Ubuntu 14.04.4 LTS
OSType: Linux
Architektur: x86_64
CPUs: 2
Gesamtspeicher: 3,859 GiB
Name: Meister
ID: 2 NQU: D2C5 : 5 WPL: IIDR : P6FO: OAG7: GHW6: ZJMQ: VDHI : B5CI: XFZJ: ZSZM
Docker-Stammverzeichnis: / home / lib / docker
Debug-Modus (Client): false
Debug-Modus (Server): false
Registrierung: https://index.docker.io/v1/
WARNUNG: Keine Unterstützung für Swap-Limits
Unsichere Register:
127.0.0.0/8

@ monikakatiyar16 Wenn ich den Prozess untar während des Builds manuell Error processing tar file(signal: killed): in der Build-Ausgabe. Das Zurücklassen des Containers in docker ps -a ist das richtige Verhalten. Dasselbe passiert bei jedem Build-Fehler und ermöglicht das Debuggen der Probleme, die zum Fehlschlagen des Builds geführt haben. Ich habe jedoch kein Problem damit, diesen Container zu löschen, und wenn ich das tue, werden auch alle Daten in /var/lib/docker/aufs bereinigt.

@tonistiigi Ja du bist richtig. Ich konnte das mit dem Container verknüpfte Volume löschen und alles bereinigen, nachdem der Docker-Untar-Prozess abgebrochen wurde. Die Docker-Systembereinigung funktioniert auch in diesem Fall.

Das eigentliche Problem, das Volumes übrig ließ, war der Fall, als ich ohne den Docker-Untar-Prozess zu beenden versuchte, den Docker-Container zusammen mit den Volumes zu entfernen - was den folgenden Fehler ergab:

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

Daemon-Protokolle:

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

Es scheint, dass die derzeitige Reihenfolge zum Unterbrechen eines Docker-Builds wie folgt lautet:
Interrupt docker build > Kill docker untar process > remove container and volume : docker rm -v -f $(docker ps -a -q)

Für docker v1.13.0-rc4 kann es Interrupt docker build > Kill docker untar process > docker system prune -a

Dies scheint perfekt zu funktionieren. Es gibt keine Probleme bei der Bereinigung. Stattdessen besteht das einzige Problem darin, dass der Docker-Untar-Prozess nicht zusammen mit dem Docker-Build-Prozess beendet wird.

Ich werde ein neues Problem nach einer ordnungsgemäßen Unterbrechung des Docker-Builds suchen / aktualisieren / protokollieren, das auch den Docker-Untar-Prozess stoppt.

(Dies wurde mit Docker v1.12.5 und v1.13.0-rc4 überprüft.)

Update: Beim Beenden von Docker-Untar beim Senden des Build-Kontexts an den Docker-Daemon wird ein Fehler beim Erstellen angezeigt: Error response from daemon: Error processing tar file(signal: terminated) , beim Kopieren der Ebene jedoch nicht (für mich)

Danke, dass du so geduldig bist und dir Zeit gibst!

Ich sehe, dass /var/lib/docker/aufs bei einem Docker-Schwarmmodus-Arbeiter stetig an Größe zunimmt. Diese Sache ist größtenteils autonom und wird vom Schwarmmanager verwaltet. Abgesehen von einigen Wartungsbefehlen hier und da wird nur sehr wenig manuell Container erstellt.

Ich führe docker exec auf Service-Containern aus. Ich bin mir nicht sicher, ob dies eine Ursache sein kann.

Meine Problemumgehung, um dies in meinem Fall zu beheben, bestand darin, einen anderen Worker zu starten, den vollständigen Knoten auf --availability=drain und manuell über ein paar Volume-Mounts zu wechseln.

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

Dies hat unseren CI-Server seit Ewigkeiten getroffen. Dies muss behoben werden.

@orf danke

Gleiches Problem hier. Weder Container-, Volume- noch Image-Entfernungs- oder Docker 1.13-Bereinigungsbefehle haben Auswirkungen.

Ich bestätige auch, dass ich einige Image-Build-Abbrüche durchgeführt habe. Vielleicht bleiben Ordner übrig, die auch nicht erreichbar sind.
Ich werde vorerst die gute alte rm-Methode verwenden, aber das ist eindeutig ein Fehler.

Dateien im Verzeichnis / var / lib / docker / aufs / diff füllen 100% des Speicherplatzes für das Dateisystem / dev / sda1 von 30G aus

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

Verwendete Dateisystemgröße Verfügbar Verwenden Sie% Mounted on
udev 14G 0 14G 0% / dev
tmpfs 2,8 G 273 M 2,5 G 10% / Lauf
/ dev / sda1 29G 29G 0 100% /
tmpfs 14G 0 14G 0% / dev / shm
tmpfs 5.0M 0 5.0M 0% / run / lock
tmpfs 14G 0 14G 0% / sys / fs / cgroup
/ dev / sdb1 197G 60M 187G 1% / mnt
tmpfs 2.8G 0 2.8G 0% / run / user / 1000

du -h -d 1 / var / lib / docker / aufs / diff | grep '[0-9] G>'
zeigt an

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

Auch versucht, Docker-System beschneiden , das hat nicht geholfen.

Hat jemand eine Lösung für dieses anhaltende Problem mit super großen Dateien in diff gefunden, bevor dieser Fehler im Code behoben wurde?

Ja, die Methode wurde bereits angegeben, aber hier ist ein Apokalypse-Ausschnitt, der einfach alles zerstört, was ich hier bei der Arbeit eingerichtet habe (außer lokalen Ordnern für die Volumes). Zum Einfügen der bashrc- oder einer anderen bash-Konfigurationsdatei.

`` `
alias docker-full-cleanup = 'func_full-cleanup-docker'

func_full-cleanup-docker () {

echo "WARNUNG: Dadurch wird alles aus dem Docker entfernt: Volumes, Container und Bilder. Wagen Sie es? [J / N]"
Wahl lesen

if [("$ choice" == "y") -o ("$ choice" == "Y")]
dann
sudo echo "> sudo rights check [OK]"
Größe = 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"

fi
} `` `

Ich habe den Befehl rm -rf ausgeführt, um die Dateien vorerst aus dem Diff-Ordner zu entfernen. Möglicherweise muss das Skript überprüft werden, wenn der Diff-Ordner wieder den gesamten Speicherplatz belegt.
Wir hoffen, dass dieses Problem im Code behoben wird, anstatt es zu umgehen.

Hallo, ich habe das gleiche Problem in Docker 1.10.2, ich verwende Kubernetes. Dies ist meine Docker-Version:

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

Ich versuche, alle nicht verwendeten Diff-Verzeichnisse unter /var/lib/docker/aufs/diff und /var/lib/docker/aufs/mnt/ zu verfolgen, indem ich Layer-Dateien unter /var/lib/docker/image/aufs/imagedb analysiere. Hier ist das Skript, das ich verwendet habe:

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

Aber ich habe ein Problem festgestellt, als ich den Docker-Daemon gestoppt und neu gestartet habe. Anscheinend habe ich einen inkonsistenten Status von Docker:

/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

und wenn ich versuche, neue Container mit docker run zu erstellen, ist dies mit der folgenden Meldung fehlgeschlagen:

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

und das Daemon-Protokoll zeigt:

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

Weiß jemand, ob mein Ansatz richtig ist oder nicht? und warum tritt das Problem auf, nachdem ich diese Ordner gelöscht habe?

Ich habe # 31012 geöffnet, um zumindest sicherzustellen, dass diese Verzeichnisse unter keinen Umständen durchgesickert sind.
Wir müssen uns natürlich auch die verschiedenen Ursachen der busy -Fehler ansehen

Das hat mich gebissen, solange ich mich erinnern kann. Ich habe so ziemlich die gleichen Ergebnisse wie oben beschrieben erzielt, als ich vor einigen Tagen zum Treiber overlay2 gewechselt und den aufs-Ordner vollständig gelöscht habe ( docker system df sagt 1,5 Gigs, df sagt 15 Gigs) .

Ich hatte ungefähr 1T Unterschiede bei der Verwendung von Speicher. Nach dem Neustart meines Docker-Daemons habe ich ungefähr 700 GB wiederhergestellt. Also denke ich, dass das Stoppen der Daemon-Pflaumen diese?

Ein Neustart bringt mir leider nichts.

Service-Neustart hat nicht geholfen. Dies ist ein ernstes Problem. Durch das Entfernen aller Container / Bilder werden diese Unterschiede nicht entfernt.

Das Stoppen des Daemons würde diese nicht beschneiden.

Wenn Sie alle Container entfernen und immer noch diff dirs haben, haben Sie wahrscheinlich einige durchgesickerte rw-Schichten.

Wir sind gerade auf dieses Problem gestoßen. /var/lib/docker/aufs/diff hat 28G in Anspruch genommen und unser Root-Dateisystem auf 100% gebracht, was dazu führte, dass unser GitLab-Server nicht mehr reagierte. Wir verwenden Docker für GitLab CI. Um dies zu beheben, habe ich einige der oben vorgeschlagenen Befehle betriebsbereit . Ich habe den Server neu gestartet und ein neues Commit gesendet, um CI auszulösen, und alles scheint so zu funktionieren, wie es sollte.

Ich bin definitiv besorgt, dass dies wieder passieren wird. Was ist hier los? Ist dies ein Docker-Fehler, der behoben werden muss?

1. Ja, es gibt einen Fehler (sowohl, dass es Probleme beim Entfernen gibt als auch, dass --force on rm diese Probleme ignoriert).
2. Im Allgemeinen sollte man nicht viele Daten in den Container fs schreiben und stattdessen ein Volume (sogar ein Wegwerf-Volume) verwenden. Ein großes Diff-Verzeichnis würde anzeigen, dass signifikante Datenmengen in den Container fs geschrieben werden.

Wenn Sie beim Entfernen nicht "--force" verwenden, tritt dieses Problem nicht auf (oder Sie sehen zumindest, dass Sie eine Reihe "toter" Container haben und wissen, wie / was zu bereinigen ist).

Ich benutze Docker überhaupt nicht manuell. Wir verwenden Gitlab-Ci-Multi-Runner . Könnte es dann ein Fehler am Ende von GitLab sein?

Es sieht so aus, als würde es (standardmäßig) Container zwangsweise entfernen. https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/dbdbce2848530df299836768c8ea01e209a2fe40/executors/docker/executor_docker.go#L878. Dies kann dazu führen, dass Fehler beim Entfernen des Containers ignoriert werden und zu verwaisten Unterschieden führen.

Ok, dann sagt mir das, dass dies ein Gitlab-Ci-Multi-Runner-Fehler ist. Ist das eine richtige Interpretation? Ich freue mich, ein Problem für sie zu erstellen, um dies zu beheben.

Es ist eine Kombination, denke ich; "force" remove erleichtert die Handhabung von Bereinigungen (dh Fälle, in denen ein Container noch nicht gestoppt ist usw.) und kann gleichzeitig (das ist der erwähnte "Fehler" @ cpuguy83 ) auch tatsächliche Probleme verbergen, z Docker kann das Container-Dateisystem nicht entfernen (was verschiedene Gründe haben kann). Mit "Kraft" wird in solchen Fällen der Behälter entfernt. Ohne bleibt der Container herum (aber als "tot" markiert)

Wenn der Gitlab-Läufer ohne Entfernen der Kraft ordnungsgemäß funktionieren kann, ist es wahrscheinlich gut, ihn zu ändern (oder konfigurierbar zu machen).

Ich benutze Drone und habe das gleiche Problem. Ich habe den Code nicht überprüft, wie Container entfernt werden, aber ich denke, er erzwingt auch das Entfernen.

Könnte es sich um ein Docker in Docker-Problem handeln? Ich starte Drone mit Docker-Compose.

Ich habe mich entschlossen, ein Gitlab-Ci-Multi-Runner-Problem einzureichen, um die Entwickler einzuschleifen: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

Ehrlich gesagt haben wir das umgangen, indem wir Spotify's Docker GC mit Drone CI ausgeführt haben.

El El mar, mar. 28, 2017 a las 3:38 PM, Geoffrey Fairchild <
[email protected]> escribió:

Ich beschloss, ein Gitlab-Ci-Multi-Runner-Problem nur bei einzureichen
Schleife die Entwickler in:
https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/docker/docker/issues/22207#issuecomment-289926298 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AC6Wz197zkjWWOlq1-JOibiQP-xJym9Eks5rqYvegaJpZM4IMGt2
.

@sedouard Danke für diesen Tipp! Das stündliche -gc von spotify aus löste das Problem für mich.

Dieses Problem wird von Gitlab CI (nicht im Docker ausgeführt) ausgeführt, wobei Befehle zum Erstellen von Images / Ausführen von Containern verwendet werden (keine Gitlab CI Docker-Integration). Wir führen keine Form der Kraftentfernung durch, einfach docker run --rm ... und docker rmi image:tag

EDIT : Entschuldigung, eigentlich ist das ursprüngliche Problem das gleiche. Der Unterschied besteht darin, dass das Ausführen von spotify/docker-gc das Problem nicht behebt.

Wie Sie unten sehen können, habe ich 0 Bilder, 0 Container, nichts!
docker system info stimmt mir zu, erwähnt aber Dirs: 38 für den aufs-Speicher.

Das ist verdächtig! Wenn Sie sich /var/lib/docker/aufs/diff/ ansehen, sehen wir, dass dort tatsächlich 1,7 GB Daten vorhanden sind, über 41 Verzeichnisse. Und das ist meine persönliche Box, auf dem Produktionsserver sind es 19 GB.

Wie reinigen wir das? Wenn Sie spotify/docker-gc verwenden, werden diese nicht entfernt.

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

Kann ich sicher rm -r /var/lib/docker/aufs und das Docker-Deamon neu starten?

Wenn Sie spotify/docker-gc ausführen, werden diese Waisenkinder nicht gereinigt.

EDIT : danke @CVTJNII!

Das Stoppen des Docker-Daemons und das Löschen von / var / lib / docker ist sicherer. Wenn Sie / var / lib / docker / aufs löschen, verlieren Sie Ihre Bilder trotzdem. Meiner Meinung nach ist es besser, mit einem sauberen / var / lib / docker zu beginnen. Dies ist die "Lösung", die ich seit einigen Monaten für dieses Problem verwende.

Ab 17.06 sollte es keine neuen verwaisten Unterschiede mehr geben.
Stattdessen werden möglicherweise Container mit dem Status Dead angezeigt. Dies tritt auf, wenn beim Entfernen ein Fehler aufgetreten ist, der nicht wiederhergestellt werden kann und möglicherweise einen Administrator benötigt, um damit umzugehen.

Darüber hinaus ist das Entfernen etwas robuster und weniger fehleranfällig aufgrund von Rennbedingungen oder fehlgeschlagenen Unmounts.

@ cpuguy83 : Tolle Neuigkeiten, können Sie erklären, was der Administrator in diesem

@Silex Es kommt auf die Ursache an.
In der Regel ist ein device or resource busy -Fehler aufgetreten, weil ein Mount in einen Container gelangt ist. Wenn Sie so etwas wie Cadvisor ausführen, ist dies so ziemlich eine Garantie, da in den Anweisungen angegeben ist, dass das gesamte Docker-Verzeichnis in den Cadvisor-Container eingebunden werden soll.

Dies kann schwierig sein. Möglicherweise müssen Sie die betreffenden Container stoppen und dann den Container dead entfernen.

Wenn Sie sich auf einem neueren Kernel (3.15+) befinden, ist es unwahrscheinlich, dass Sie das Problem mehr sehen, obwohl es möglicherweise immer noch einen Randfall gibt.

Docker Version 17.06.0-ce, Build 02c1d87

Ich habe versucht, alle Bilder, Volumes, Netzwerke und Container zu entfernen, aber es hat nicht geholfen.
Auch versuchte Befehle:

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

Bleiben noch Dateien:

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

Wie kann es gelöscht werden?

@ haos616 Versuchen Sie zuerst, alle laufenden Container zu stoppen, und führen Sie dann docker system prune -af .
Das hat den Trick für mich getan.
Hat nicht funktioniert, während ein Container lief.

Wenn es sich um ein Upgrade von einer früheren Docker-Version handelt, wurden diese Unterschiede möglicherweise von dieser Version generiert / zurückgelassen. Docker 17.06 entfernt keinen Container, wenn Ebenen nicht entfernt werden konnten (bei Verwendung von --force). ältere Versionen taten dies, was zu verwaisten Schichten führen konnte

@ julian-pani Ich habe es am Anfang gemacht, aber es hilft nicht.

# 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 Nein. Ich habe den Docker vor ein oder zwei Monaten gereinigt. Dann war die Version schon 17.06. Ich habe den Befehl docker system prune -af . Es hat alles entfernt.

Das Ausführen von https://github.com/spotify/docker-gc als Container hat für mich funktioniert, aber es ging noch einen Schritt weiter und löschte auch einige meiner erforderlichen Bilder :(

Deshalb habe ich aus Sicherheitsgründen ein kleines Wrapper-Skript wie folgt eingefügt

#!/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

Nochmals vielen Dank an spotify

IIUC, das Spotify-Skript ruft nur docker rm und docker rmi - hat es tatsächlich verwaiste Unterschiede entfernt?

Nur ein paar Rückmeldungen für die Community, ich habe das alles durchgelesen und keine der Lösungen scheint tatsächlich konsistent oder zuverlässig zu funktionieren. Mein "Fix" bestand einfach darin, den Speicherplatz auf meinen AWS-Instanzen zu verdoppeln. Und ich weiß nur zu gut, dass das eine beschissene Lösung ist, aber es ist die beste Problemumgehung, die ich für Dockers aufgeblähte aufs gefunden habe. Dies muss wirklich behoben werden.

@fuzzygroup 17.06 sollte keine verwaisten Diffs mehr erstellen, aber die alten werden noch nicht bereinigt.

Ich könnte mit diesem Skript aufräumen. Ich verstehe nicht, warum es nicht funktionieren würde, aber wer weiß.
Auf jeden Fall funktioniert es gut für mich. Es werden alle Bilder, Container und Volumes gelöscht ... Da es nicht sehr oft ausgeführt werden sollte, empfinde ich es als geringfügigen Nebeneffekt. Aber es liegt an Ihnen, es zu benutzen oder nicht.

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

https://stackoverflow.com/q/45798076/562769 scheint verwandt zu sein. Ich habe eine schnelle Lösung veröffentlicht.

Zu Ihrer Information, ich sehe das immer noch mit 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 enthält viele Verzeichnisse mit den -init-removing und -removing :

ffd5477de24b0d9993724e40175185038a62250861516030a33280898243e742-removing
ffd900de0634992e99c022a16775805dfd0ffd1f6c89fece7deb6b1a71c5e38c-init-removing
ffd900de0634992e99c022a16775805dfd0ffd1f6c89fece7deb6b1a71c5e38c-removing

Zu Ihrer Information, ich sehe dies immer noch mit 17.06.1-ce

Siehst du immer noch was genau?
Es sollte keine Möglichkeit geben, dass ein Diff-Verzeichnis ausläuft, obwohl Diff-Verzeichnisse weiterhin vorhanden sind, wenn sie beim Upgrade vorhanden waren, sind sie weiterhin vorhanden.

Soweit ich das beurteilen kann, sehe ich immer noch verwaiste Unterschiede. docker system prune hat sie nicht entfernt, docker-gc . Das manuelle Ausführen von rm -rf /var/lib/docker/aufs/diff/*-removing scheint zu funktionieren.

Ja, Docker räumt noch keine alten verwaisten Verzeichnisse auf.

Mit alt meinen Sie diejenigen, die mit diesem Problem aus einer früheren Docker-Version erstellt wurden?

Dies ist eine Neuinstallation von Docker, die wir vor ungefähr zwei Wochen durchgeführt haben. Diese Waisen müssen seitdem erstellt worden sein. Es scheint also, dass Docker diese Waisen noch erstellen muss.

Ich meine, in der letzten halben Stunde habe ich 112 neue Unterschiede mit -removing , da ich sie manuell bearbeitet habe.

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

Sie sagten "17.06 sollte keine verwaisten Diffs mehr erstellen, aber die alten werden noch nicht bereinigt.", Aber das kann doch nicht richtig sein, oder fehlt mir etwas? Sind die mit -removing nicht verwaist?

@orf Auf einem neueren Kernel ist es höchst unerwartet, dass beim Entfernen überhaupt ein Problem /var/lib/docker in einen Container?

Ich werde im aufs-Treiber nachsehen, ob es dort ein bestimmtes Problem gibt, bei dem eine erfolgreiche Entfernung gemeldet wird, wenn dies wirklich nicht der Fall war.

Wir montieren /var/lib/docker in einen Container.

$ 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

Wir laufen 14.04 LTS

Lassen Sie mich wissen, ob ich etwas zum Debuggen bereitstellen kann.

Aus anderen Gründen (Netzwerk im Schwarmmodus) habe ich 14.04 für Docker verlassen
Maschinen.
Am Montag, den 21. August 2017 um 08:23 Uhr schrieb orf [email protected] :

Wir mounten / var / lib / docker nicht in einen Container.

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

Wir laufen 14.04 LTS

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/moby/moby/issues/22207#issuecomment-323773033 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/AADRIfE2B2HNpbsKyTOj1CwGzulRT2C0ks5saaDPgaJpZM4IMGt2
.

Dies scheint mit 17.06.01-ce schlimmer zu sein. Ich habe eine Build-Maschine auf diese Version aktualisiert und sofort die Verzeichnisse *-init-removing und *-removing als Teil des Build-Prozesses angezeigt. Ich habe den Dienst gestoppt, das Verzeichnis /var/lib/docker , den Dienst neu gestartet und nach einigen Builds war fast kein Speicherplatz mehr verfügbar. Ich habe den Dienst erneut beendet, apt-get purge docker-ce , /var/lib/docker erneut entfernt und die Version 17.06.0-ce installiert. Das Nichtabrufen der zusätzlichen Verzeichnisse in /var/lib/docker/aufs/diff und des Speicherplatzes ist repräsentativ für Images, die sich auf dem Buildcomputer befinden. Ich habe das Verhalten auch auf meinem Entwicklungscomputer reproduziert. Wenn Sie nur ein Image erstellen, werden diese zusätzlichen Verzeichnisse für jede Ebene des Images erstellt, sodass mir schnell der Speicherplatz ausgeht. Wiederum scheint das Zurücksetzen auf 17.06.0-ce kein Problem zu haben, also werde ich vorerst dort bleiben.

@mmanderson Danke für die Berichterstattung. Sehen Sie sich die Änderungen im AUFS-Treiber an.

@mmanderson Haben Sie Container im Dead in docker ps -a ?

Allen meinen Docker-Build-Servern geht der Speicherplatz aus.

Ich habe in der letzten Woche ein Upgrade auf Docker Version 17.06.1-ce, Build 874a737, durchgeführt. Ich glaube, dass sich nichts anderes geändert hat und dass dieses Problem im Rahmen des Upgrade-Prozesses aufgetreten ist oder sich manifestiert hat. Das aufs diff Verzeichnis ist riesig und ich habe bereits alle Bilder und baumelnden Volumes beschnitten.

issue-22207.txt
@ cpuguy83 Keine Container in irgendeinem Zustand. Folgendes habe ich gerade erst getan, um dies mit 17.06.01-ce zu demonstrieren:

1. Begonnen mit einer Neuinstallation von Docker 17.06.01-ce unter Ubuntu 16.04.03 LTS (dh Docker nicht installiert und kein Verzeichnis / var / lib / docker). Nach der Installation wurde ein leeres Verzeichnis / var / lib / docker / aufs / diff überprüft.
2. Hat einen Docker-Build mit einer ziemlich einfachen Docker-Datei ausgeführt, die auf Ubuntu basiert
3. Führen Sie nach dem Ausführen des Builds docker ps -a , um keine Container in einem Status anzuzeigen. Es gibt mehr *-remaining Ordner in dem /var/lib/docker/aufs/diff Ordnern.
4. Führen Sie docker system df , um Bilder, Container und Volumes zu überprüfen. Ergebnis ist

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. Wenn Sie du -sch /var/lib/docker/*/ ausführen, werden 152 /var/lib/docker/aufs/ für
2. Führen Sie docker rmi $(docker images -q) , um die erstellten Bildebenen zu entfernen. Wenn Sie danach docker system df ausführen, werden alle Nullen angezeigt. Wenn Sie du -sch /var/lib/docker/*/ ausführen, werden 152 /var/lib/docker/aufs/ für *-remaining Ordner für alle Ordner, die sie zuvor nicht hatten, zusammen mit den vorhandenen *-remaining Ordnern, die sind noch da.

@erikh ist dies das Problem, das Sie haben?

@ cpuguy83 Nach der Deinstallation von 17.06.01-ce, dem Entfernen des Verzeichnisses / var / lib / docker und der Installation von 17.06.0-ce versuche ich, denselben Build auszuführen. Der Build schlägt aufgrund des Fehlers ADD from remote URL's fehl, der am 17.06.01 behoben wurde. Ich erhalte jedoch keine *-remaining -Verzeichnisse für die Schritte, die ausgeführt werden, und nachdem alles mit docker system prune und docker rmi $(docker image -q) /var/lib/docker/aufs/diff Verzeichnis

Vielen Dank an alle, dies ist eine Regression in 17.06.1 ...
PR zu beheben ist hier: https://github.com/moby/moby/pull/34587

super, danke für den schnellen patch @ cpuguy83! / cc @erikh

@rogaha! ja, danke dir und @ cpuguy83!

Vielen Dank @Karreg für Ihr hervorragendes Skript . Nachdem wir alle alten verwaisten Unterschiede beseitigt und wieder große Mengen an verlorenem Speicherplatz freigegeben haben, verwenden wir ihn jetzt regelmäßig, um unsere VMs zu bereinigen, bevor neue Docker-Images installiert werden. Große Hilfe und eine nahezu perfekte Problemumgehung für dieses Problem. @ TP75

Anscheinend hat Docker, Inc. einige Verträge mit Herstellern von Computerdatenspeichern.

Das Skript von

Das gleiche Problem haben.
Docker-Host-Details

root @ UbuntuCont : ~ # Docker-Informationen
Behälter: 3
Laufen: 0
Angehalten: 0
Gestoppt: 3
Bilder: 4
Serverversion: 17.06.1-ce
Speichertreiber: aufs
Root Dir: / var / lib / docker / aufs
Sichern des Dateisystems: extfs
Regie: 14
Dirperm1 Unterstützt: true
Protokollierungstreiber: JSON-Datei
Cgroup-Treiber: cgroupfs
Plugins:
Lautstärke: lokal
Netzwerk: Bridge-Host-Macvlan-Null-Overlay
Protokoll: awslogs fließend gcplogs gelf journald json-file logentries splunk syslog
Schwarm: inaktiv
Laufzeit: runc
Standardlaufzeit: runc
Init Binary: Docker-Init
Containerd-Version: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
runc version: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
Init-Version: 949e6fa
Sicherheitsoptionen:
Apparmor
seccomp
Profil: Standard
Kernel-Version: 4.4.0-93-generic
Betriebssystem: Ubuntu 16.04.3 LTS
OSType: Linux
Architektur: x86_64
CPUs: 1
Gesamtspeicher: 3,358 GB
Name: UbuntuCont
ID: QQA5: DC5S: C2FL: LCC6: XY6E: V3FR: TRW3: VMOQ: QQKD : AP2M: H3JA: I6VX
Docker-Stammverzeichnis: / var / lib / docker
Debug-Modus (Client): false
Debug-Modus (Server): false
Registrierung: https://index.docker.io/v1/
Experimentell: falsch
Unsichere Register:
127.0.0.0/8
Live-Wiederherstellung aktiviert: false

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

@kasunsjc Bitte lesen Sie die Beiträge direkt über Ihren.

Ich bestätige, dass ein Upgrade auf 17.06.2-ce dieses Problem behoben hat. Ich musste die Verzeichnisse auch nicht (letztes Mal) nach dem Upgrade manuell erstellen.

17.06.2-ce scheint dies auch für mich behoben zu haben. Keine -removing Verzeichnisse mehr drin, haben eine anständige Menge an Speicherplatz zurück.

Ich gehe davon aus, dass die -init -Verzeichnisse, die ich in aufs/diff nichts miteinander zu tun haben (einige von ihnen sind ziemlich alt). Sie sind jedoch alle klein, daher spielt es kaum eine Rolle.

Das Update auf 17.07.0 löste das Problem auch hier. Nicht einmal docker system prune --all -f entfernte die Verzeichnisse vor, aber nach dem Upgrade wurden sie beim Neustart automatisch entfernt.

Die Bestätigung dieses Problems wurde unter Ubuntu 16.04 mit 17.06.2-ce behoben. Sobald es aktualisiert wurde, wurde der Platz geräumt.