# 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にはコンテナー、ボリューム、またはイメージがリストされていないことも示す必要があります。

$ 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

カーネルがアップグレードされたUbuntuLucidを使用しています= /

$ 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

興味深い問題のようです。
それを再現する方法はありますか？ @bukzor

確かに可能ですが、方法がわかりません。
アクティブなDockerホストの1つで以下のスクリプトを実行して、残っているものを確認してください。
私たちの場合、常に多くの差分が残されています。

`` `＃！bash

！/ bin / bash

set -eu

echo "警告::これにより、すべてのDockerプロセスが停止し、すべてのDockerイメージが削除されます。"
-p「続行（y / n）？」を読んでください。
if ["$ REPLY"！= "y"]; その後
エコー「中止」。
出口1
fi

xdocker（）{exec xargs -P10 -r -n1 --verbose docker "$ @"; }

セット-x

コンテナを削除します

docker ps -q | xdocker停止
docker ps -aq | xdocker rm

タグを削除する

Docker画像| sed 1d | grep -v '^'| col 1 2 | sed's / /：/ '| xdocker rmi

画像を削除する

docker images -q | xdocker rmi
docker images -aq | xdocker rmi

ボリュームを削除します

docker volume ls -q | xdockerボリュームrm
`` `

私がこれが起こっているのを見る一つの可能​​な方法は、aufsのアンマウントでエラーが発生した場合です。 たとえば、EBUSYエラーがある場合は、イメージ構成が以前に削除されている可能性があります。

@bukzor空のグラフディレクトリから開始し、画像をプル/実行して、スクリプトの実行後に完全にクリーンアップされない状態にする再現機能があれば、非常に興味深いでしょう。

それは面白いでしょうが、丸一日の仕事のように聞こえます。
私はそれにコミットすることはできません。

上記の（任意に選択された）厄介な差分a800に関するデータをさらにいくつか示します。

`` `＃！sh
$ docker-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 / nail / var / lib / docker / aufs / layers / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579
  14 / nail / var / lib / docker / aufs / layers / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579-init
  13 / nail / var / lib / docker / aufs / layers / 993e4988c510ec3ab4f6d139740a059df40585576f8196817e573a9684554c5c
  12 / nail / var / lib / docker / aufs / layers / cf9fd1c4a64baa39b6d6d9dac048ad2fff3c3fe13924b07377e767eed230ba9f
  11 / nail / var / lib / docker / aufs / layers / 4e6afb958b5ee6dea6d1a886d19fc9c780d4ecc4baeebfbde31f9bb97732d10d
  10 / nail / var / lib / docker / aufs / layers / 23ce5a473b101d85f0e9465debe5a0f3b8a2079b99528a797b02052d06bc11d8
  9 / nail / var / lib / docker / aufs / layers / 95e68d59a8704f2bb52cc1306ca910ddb7af8956eb7c57970fcf7d8b3d9baddb
  8 / nail / var / lib / docker / aufs / layers / ac6b8ff4c0e7b91230ebf4c1caf16f06c1fdceff6111fd58f4ea50fc2dd5050b
  7 / nail / var / lib / docker / aufs / layers / fd895b6f56aedf09c48dba97931a34cea863a21175450c31b6ceadde03f7b3da
  6 / nail / var / lib / docker / aufs / layers / d5bbef5adf2efb6f15d4f96c4bee21beb955255d1ec17baf35de66e98e6c7328
  5 / nail / var / lib / docker / aufs / layers / 9646360df378b88eae6f1d6288439eebd9647d5b9e8a471840d4a9d6ed5d92a4
  4 / nail / var / lib / docker / aufs / layers / a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
  0 / nail / 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 / nail / var / lib / docker '（' -path '/ nail / var / lib / docker / aufs / diff / '-o -path '/ nail / var / lib / docker / aufs / mnt / ' ' ） '-prune -o -print
• grep --color'f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 $ '
  / nail / var / lib / docker / aufs / layers / 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-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 --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 / 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 eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e
  `` `

そのマウントが使用されたコンテナを見つける方法はありますか？
ドキュメントには、マウントIDがコンテナIDと等しくなくなったとだけ書かれているため、あまり役に立ちません。
https://docs.docker.com/engine/userguide/storagedriver/aufs-driver/

@bukzor eb809c0321はコンテナIDです。 ドキュメントの意味するところは、aufs id（あなたの場合はf3286009193f ）はコンテナIDではないということです。

/ cc @ dmcgowanも

@tonistiigiOK 。

その後、明らかにマウントはそのコンテナよりも長生きしました。

コンテナのライフサイクルのどの時点でマウントがクリーンアップされますか？
これは、実行中/停止中のコンテナーの一時的な書き込み可能なaufですか？

@bukzor （rw）マウントは、コンテナーの削除時に削除されます。 アンマウントは、コンテナプロセスの停止時に発生します。 差分フォルダは、個々のレイヤーのコンテンツが保存される場所であり、レイヤーがマウントされているかどうかは関係ありません。

@bukzor aufs idとコンテナIDの間のリンクは、 image/aufs/layerdb/mounts/<container-id>/mount-idます。 aufs idを知っているだけで、コンテナIDを見つける最も簡単な方法は、そのためのimage/aufs/layerdbディレクトリをgrepすることです。 何も見つからない場合は、クリーンアップが正常に完了していません。

同様の問題が発生しています。

Dockerデーモンサーバーで毎日CIを実行しています。 / var / lib / docker / aufs / diffは、かなりの量のディスク容量を必要としますが、そうすべきではありません。

ここまたは関連するスレッド（上記の@bukzorのbashスクリプトを含む）で提案された合理的なすべてを試した後でも、 aufs/diff 2gb 。

適切な修正がない場合、他のすべてのイメージを同時に削除せずに、残ったマウントを削除する簡単な方法はありますか？ （現在実行中のコンテナがない場合、マウントはないはずですよね？）

同じ問題が発生しています。 私はこのマシンを使用して多くのコンテナーをテストしてから、コミット/削除しています。 私の/ var / lib / docker / aufsディレクトリは現在7.9G重いです。 このディレクトリのストレージは限られているため、このディレクトリを別のマウントポイントに移動する必要があります。 :(

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

@mcallaway aufs/diff内のすべては、コンテナーで実行されるfs書き込みになります。

同じ問題があります。 私が持っているすべてのコンテナは実行状態ですが、これらのコンテナに関連せず、古い削除されたコンテナに関連するaufsdiffディレクトリがたくさんあります。 手動で削除することはできますが、オプションではありません。 そのような振る舞いには理由があるはずです。

k8s1.3.5とdocker1.12を使用しています。

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc spotify/docker-gc役に立ちました。

同じ問題があります。 dind（dockerのdocker）でGitlabCIを使用しています。

レジストリ内のイメージが同じタグ内で更新されてプルされた後、関連するコンテナが再起動され、 spotify/docker-gcを実行しない限り、古いコンテナとイメージはGCされません。

他の誰かがこれを確認できますか？

@kayrusは正解docker rmi $(docker images -qa -f dangling=true)を使用して、「ぶら下がっている」画像を削除できます。 また、docker 1.13はデータ管理コマンド（https://github.com/docker/docker/pull/26108を参照）を取得します。これにより、未使用のイメージやコンテナーなどをより簡単にクリーンアップできます。

@thaJeztah /var/lib/docker/aufs/diff/には実際に「タグなし」の画像が含まれていますか？

@kayrusはい、それらは画像の一部です（タグ付きおよびタグなし）

同様の問題が発生し、コンテナ/画像/ボリュームがなく、最大13Gbの差分が表示されます

$ 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 Community）Slackで何度か取り上げました。 少数の人がガベージコレクションスクリプト/コマンドのリストを実行するたびに、解決策として実行する必要があります。

それらは暫定的に助けてくれましたが（読んでください：解決されていません-スペースはまだいっぱいに向かって忍び寄っています）、それは理想的な長期的な修正ではないことに私たちは皆同意できると思います。

@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

イメージ、コンテナー、またはボリュームはありません。 aufs / diffで42Gb

このディレクトリを安全にクリアするのに役立つものは何でも非常に役立ちます！ このスレッドのすべてを試しましたが、成功しませんでした。 ありがとう。

@adamdryのみのサードパーティスクリプト： https ：

@kayrusに感謝します。実際に試してみましたが、ディスクの合計使用量がわずかに増加し、aufs / diffディレクトリに対して何も実行されていないようです。

実行されなかったdocker system pruneも試しました。 そして、削除する画像が見つからなかったdocker rmi $(docker images -qa -f dangling=true)を試しました。

興味のある人のために、私は今これを使ってすべてのコンテナ、イメージ、ボリューム、古いaufをクリーンアップしています：

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

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 rm / rmiを実行するときに-f使用しないことをお勧めします。これにより、削除のエラーが非表示になります。
私は現在の状況を考慮します... -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 /にデータが残ります。 ぶら下がっている画像が表示されました。 それをきれいにすることもスペースを解放しませんでした。 Dockerシステムのプルーニングの一部として含めることは可能ですか？ このフォルダ内のblobデータを削除するだけでスペースが解放されますが、問題が発生するかどうかはわかりません。

Dockerバージョン：1.13.0-rc1

ビルド中に、レイヤービルドプロセス（コピーされるBLOBも含まれます）中にビルドプロセスが中断された後、コンテナーが停止すると、データが残ります。

これも私の問題の原因である可能性があります-私は多くのビルドを中断します。

Dockerのプル中に、次の2つのケースを観察しました。

1. ダウンロード（/ var / lib / docker / tmp /内のイメージレイヤーをダウンロードする）と表示されたときにプロセスが中断された場合、そのフォルダー内のすべてのデータがクリーンアップされます。
2. 抽出（tmpから/ var / lib / docker / aufs / diff /へのレイヤーの抽出だと思います）と表示されたときにプロセスが中断された場合、tmpデータとdiffblobデータの両方がクリーンアップされます。

イメージビルドプロセス中に、

1. 「ビルドコンテキストをdockerデーモンに送信する」（私の場合は/ var / lib / docker / tmp /にblobデータをコピーする）時にプロセスを中断すると、プロセスは永久に残り、手動で削除する以外のコマンドでクリーンアップすることはできません。 画像のaptgetupdatesがどのように処理されるのかわかりません。
2. 大規模なソフトウェアセットアップなど、blobデータを含むレイヤーが構築されている間、プロセスが中断された場合、Dockerコンテナーはイメージで作業を続けます。 私の場合、画像全体を構成するのは、tmpフォルダーで既に使用可能な1層のBLOBデータのみです。 ただし、docker stopコマンドを使用してコンテナーを停止すると、次の2つのケースが発生します。
   a。 マウントプロセスがまだ行われている場合は、tmpおよびdiffフォルダーにデータが残ります。
   b。 データがdiffフォルダーにコピーされた場合、tmpフォルダーからデータが削除され、diffフォルダーとマウントフォルダーにデータが残ります。

自動化されたビルドプロセスがあり、ビルドプロセスを適切に停止するための制御が必要です。 最近、構成が低いマシンでメモリ不足エラーが発生したため、プロセスがカーネルによって強制終了されました。

1つのイメージが2つのレイヤーで構築され、1つのレイヤーが構築され、2つ目のイメージが中断される場合、Dockerシステムのプルーニングは、中断されてコンテナーが停止したレイヤーのコンテナーのデータをクリーンアップするようです。 ただし、割り込みが発生した場合、前のレイヤーのデータはクリーンアップされません。 また、要求された合計ディスク容量を反映していませんでした。 AWS、ubuntu 14.04、aufsファイルシステムを備えたx86_64ビットシステムでこれらのテストを実行しました。 docker 1.13.0rc3とdocker1.12を使用してdockerpruneテストを実行しました

@thaJeztah
私が何かを誤解している場合は私に知らせてください。

/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マウントが残っているのはわかりますが、解決できるかどうかを確認します
それ（それはただの空のディレクトリですが）

私が使用したdockerfileの唯一の違いは（異なるレイヤーを作成するため）でした
ゼロから
COPY ["./bigfile"、 "randomNoFile1"、/]
COPY ["./bigfile"、 "randomNoFile2"、/]
EOF

それが違いを生むかどうかはわかりません。

いいえ、問題は空のinitフォルダーに関するものではありません。 私の場合、それはteblobでした。 ただし、月曜日に再確認して更新することはできます。

また、5GBのファイルを使用していて、devurandomからバイトを読み取って作成しました。
あなたの場合、同じファイルが2回追加されます。 それは単一のレイヤーを作成し、そこから2番目のレイヤーをマウントしますか、それとも2つの別々のレイヤーになりますか？ 私の場合、常に2つの別々のレイヤーです。

@thaJeztah
この問題について迅速に対応していただき、ありがとうございます。 この機能の追加は大いに役立ちます！

@ monikakatiyar16 ADD RUNコマンドとaufs/diffにリークするものがありませんでした。 ADD/COPY操作中にコンテナーを実行するべきではないため、停止しているコンテナーを完全に理解できません

私が何か間違ったことをしている可能性があります。 私は週末に旅行しているので、それを複製し、月曜日にここで必要なすべての情報を更新します。

@tonistiigi @thaJeztah
私はあなたが正しいと感じます。 実際には、アクティブで実行中としてリストされているコンテナーはありません。 代わりに、死んだコンテナがあります。 私の場合、Dockerシステムのプルーニングは機能しませんでした。これは、プロセスがCtrl + Cで強制終了されなかったことが原因である可能性があります。 代わりに、バックグラウンドで実行し続けました。 私の場合、それが理由であり、それらのブロブを削除できませんでした。

Ctrl + Cを使用してプロセスを中断すると、ビルドプロセスは強制終了されますが、docker-untarのプロセスはバックグラウンドで存続し、イメージのビルドに引き続き取り組んでいます。 （注：/ var / lib / dockerは/ home / lib / dockerにソフトリンクされており、AWS上の大きなデータにEBSボリュームを使用します）

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. 5GBの大きなファイルを作成します
2. ビルドプロセスを開始し、ビルドコンテキストの送信が終了し、実際にblobをコピーした後でのみ中断します。
3. しばらくするとイメージのビルドが完了し、Dockerイメージに表示されます（私が添付したケース1のように-DockerBuild_WOProcessKill）
4. プロセスが強制終了されると、しばらく時間がかかり、blobデータが/ diffに残ります（ファイルに添付されているように、プロセスを突然強制終了する必要があります-DockerBuild_WithProcessKill）

私が想定していることが正しければ、これはdocker pruneの問題ではなく、dockerbuildの強制終了で問題が発生する可能性があります。

イメージのビルドプロセスを中断または停止する適切な方法はありますか？これは、コピーされたデータのクリーンアップも処理します（docker pullで処理されます）。

以前は、プロセスを強制終了していませんでした。 また、docker-untarが何をするのか、なぜそれを/ mntフォルダーと/ diffフォルダーの両方にマウントし、後で/ mntフォルダーをクリーンアップするのかについても興味がありますか？

Dockerバージョン1.12.5でこれをテストし、AWSで7392c3bをビルドします

Docker情報
コンテナ：2
実行中：0
一時停止：0
停止：2
画像：0
サーバーバージョン：1.12.5
ストレージドライバー：aufs
ルートディレクトリ：/ home / lib / docker / aufs
バッキングファイルシステム：extfs
Dirs：4
サポートされているDirperm1：false
ロギングドライバー：json-file
Cgroupドライバー：cgroupfs
プラグイン：
ボリューム：ローカル
ネットワーク：オーバーレイブリッジヌルホスト
群れ：非アクティブ
ランタイム：runc
デフォルトのランタイム：runc
セキュリティオプション：apparmor
カーネルバージョン：3.13.0-105-generic
オペレーティングシステム：Ubuntu 14.04.4 LTS
OSType：linux
アーキテクチャ：x86_64
CPU：2
総メモリ：3.859 GiB
名前：マスター
ID：2 NQU：D2C5 ：5 WPL：IIDR ：P6FO：OAG7：GHW6： ZJMQ：VDHI ：B5CI： XFZJ：ZSZM
Dockerルートディレクトリ：/ home / lib / docker
デバッグモード（クライアント）：false
デバッグモード（サーバー）：false
レジストリ： https ：
警告：スワップ制限はサポートされていません
安全でないレジストリ：
127.0.0.0/8

@ monikakatiyar16ビルド中にuntarプロセスを手動で強制終了すると、ビルド出力にError processing tar file(signal: killed):れます。 docker ps -aコンテナを残しておくのは正しい動作です。ビルドエラーでも同じことが起こり、ビルドが失敗する原因となった問題をデバッグできます。 ただし、このコンテナを削除しても問題はありません。削除すると、 /var/lib/docker/aufs内のすべてのデータもクリーンアップされます。

@tonistiigiはい、その通りです。 docker-untarプロセスを強制終了した後、コンテナーに関連付けられているボリュームを削除でき、すべてがクリーンアップされました。 この場合、Dockerシステムのプルーニングも機能します。

ボリュームを残した実際の問題は、docker-untarプロセスを強制終了せずに、ボリュームと一緒にdockerコンテナーを削除しようとした場合でした。これにより、次のエラーが発生しました。

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

Dockerビルドを中断するために今従うべき順序は次のようです：
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-buildプロセスと一緒にdocker-untarプロセスが強制終了されないことです。

新しい問題を検索/更新/ログに記録して、Dockerビルドの正常な割り込みを探します。これにより、Docker-untarプロセスも停止します。

（docker v1.12.5およびv1.13.0-rc4でこれを確認しました）

更新：dockerデーモンにビルドコンテキストを送信しているときにdocker-untarを強制終了すると、ビルドでエラーが発生します： Error response from daemon: Error processing tar file(signal: terminated) 、しかしレイヤーコピー中にはエラーが発生しません（私にとって）

とても辛抱強く、時間を割いてくれてありがとう！

Dockerスウォームモードのワーカーで/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 Docker1.13クリーンアップコマンドは効果がありません。

また、イメージビルドのキャンセルを行ったことも確認しました。 たぶん、それは到達できないフォルダも残します。
今は古き良きrmメソッドを使用しますが、これは明らかにバグです。

/ var / lib / docker / aufs / diff内のファイルは、30Gの/ dev / sda1ファイルシステムの100％のスペースを埋めます

root @ Ubuntu ：/ var / lib / docker / aufs / diff＃df -h

使用されているファイルシステムのサイズ使用率使用率
udev 14G 0 14G 0％/ dev
tmpfs 2.8G 273M 2.5G 10％/ run
/ dev / sda1 29G 29G 0100％/
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>'
ショー

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

また、 docker system pruneを試しましたが、役に立ちませんでした。

このバグがコードで修正される前に、diff内の超大型ファイルのこの進行中の問題の解決策を誰かが見つけましたか？

はい、メソッドはすでに提供されていますが、ここに私が職場で配置したすべてのもの（ボリュームのローカルフォルダーを除く）を破壊する黙示録スニペットがあります。 bashrcまたは別のbash構成ファイルを配置します。

`` `
エイリアスdocker-full-cleanup = 'func_full-cleanup-docker'

func_full-cleanup-docker（）{

echo "警告：これにより、Dockerからボリューム、コンテナー、イメージのすべてが削除されます。あえてしますか？[y / N]"
選択肢を読む

if [（ "$ choice" == "y"）-o（ "$ choice" == "Y"）]
その後
sudo echo "> sudo rights check [OK]"
sizea = 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
} `` `

今のところ、rm-rfコマンドを実行してdiffフォルダーからファイルを削除しました。 おそらく、diffフォルダーが再びdisスペース全体を占める場合は、スクリプトを調べる必要があります。
回避策ではなく、コードでこの問題が修正されることを期待しています。

こんにちは、docker1.10.2でも同じ問題が発生しています。kubernetesを実行しています。 これは私のDockerバージョンです：

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

/var/lib/docker/image/aufs/imagedb下のレイヤーファイルを分析して、 /var/lib/docker/aufs/diffと/var/lib/docker/aufs/mnt/下のすべての未使用のdiffディレクトリを追跡しようとしています。使用したスクリプトは次のとおりです。

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

しかし、dockerデーモンを停止して再起動すると、問題が発生しました。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

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

私のアプローチが正しいかどうか誰かが知っていますか？ これらのフォルダを削除した後に問題が発生するのはなぜですか？

少なくともこれらのdirがどのような状況でも漏れないようにするために、＃31012を開きました。
もちろん、 busyエラーのさまざまな原因も調べる必要があります

私が覚えている限り、これは私を噛みました。 数日前にoverlay2ドライバーに切り替えて、aufsフォルダーを完全に削除したとき（ docker system dfは1.5Gigs、 dfは15Gigs）、上記とほぼ同じ結果が得られました。 。

ストレージを使用して約1Tの差分がありました。 Dockerデーモンを再起動した後-約700GBを回復しました。 だから私はデーモンを停止するとこれらを取り除くと思いますか？

残念ながら、再起動しても何も起こりません。

サービスの再起動は役に立ちませんでした。 これは深刻な問題です。 すべてのコンテナ/イメージを削除しても、それらの差分は削除されません。

デーモンを停止しても、これらは削除されません。

すべてのコンテナを削除してもdiffディレクトリが残っている場合は、rwレイヤーがリークしている可能性があります。

この問題が発生しました。 /var/lib/docker/aufs/diffは28Gを使用し、ルートファイルシステムを100％にしたため、GitLabサーバーが応答を停止しました。 GitLabCIにはdockerを使用しています。 これを修正するために、上記で提案したコマンド@sogetimaitralのいくつかを使用して一時ファイルを削除し、バックアップして実行しています。 サーバーを再起動し、CIをトリガーするために新しいコミットを送信しましたが、すべてが正常に機能しているように見えます。

私は間違いなくこれが再び起こるのではないかと心配しています。 ここでの取引は何ですか？ これは修正が必要なDockerのバグですか？

1. はい、バグがあります（削除に問題があり、-force on rmがこれらの問題を無視することの両方）
2. 一般に、コンテナfsに大量のデータを書き込むのではなく、ボリューム（使い捨てボリュームであっても）を使用する必要があります。 大きなdiffdirは、コンテナfsに大量のデータが書き込まれていることを示します。

削除時に「--force」を使用しない場合、この問題は発生しません（または、少なくとも、「デッド」コンテナが多数あり、クリーンアップする方法/内容を知っていることがわかります）。

Dockerを手動で使用しているわけではありません。 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」removeを使用すると、クリーンアップ（つまり、コンテナーがまだ停止されていない場合など）の処理が容易になり、同時に（前述の「バグ」 @ cpuguy83 ）、次のような実際の問題を非表示にすることもできます。 dockerがコンテナーファイルシステムの削除に失敗しました（さまざまな理由が考えられます）。 このような場合、「力」でコンテナを取り外します。 ない場合、コンテナはそのままになります（ただし、「デッド」とマークされます）

gitlabランナーが強制的に削除せずに正しく機能できる場合は、変更する（または構成可能にする）とよいでしょう。

私はドローンを使用していますが、同じ問題があります。 コンテナがどのように削除されるかをコードで確認しませんでしたが、強制的に削除することもあると思います。

Docker in Dockerの問題でしょうか？ Docker-composeでドローンを始めています。

：私は、中に開発者が先に行くと、ちょうどループにgitlab-CI-マルチランナーの問題を提出することを決めたhttps://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

正直なところ、ドローンCIでSpotifyのdockergcを実行することでこれを回避しました。

エルエルマール、マール。 2017年28日午後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このヒントをありがとう！ Spotifyから1時間ごとに

この問題は、Gitlab CI（dockerでは実行されていません）から実行され、コマンドを使用してイメージを構築/コンテナーを実行します（Gitlab CI Docker統合ではありません）。 docker run --rm ...とdocker rmi image:tagだけで、いかなる形式の強制除去も実行していません。

編集：申し訳ありませんが、実際には元の問題は同じです。 違いは、 spotify/docker-gcを実行しても、問題が修正されないことです。

以下に示すように、画像は0、コンテナは0、何もありません。
docker system infoは私に同意しますが、aufsストレージのDirs: 38について言及しています。

それは疑わしいです！ /var/lib/docker/aufs/diff/を見ると、実際には、41個のディレクトリに1.7GBのデータがあることがわかります。 これが私の個人用ボックスです。本番サーバーでは19GBです。

これをどのように掃除しますか？ 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デーモンを再起動できますか？

spotify/docker-gcしても、それらの孤児はクリーンアップされません。

編集：@CVTJNIIに感謝します！

Dockerデーモンを停止し、/ var / lib / dockerをすべて消去する方が安全です。 / var / lib / docker / aufsを消去すると、とにかく画像が失われるため、私の意見では、クリーンな/ var / lib / dockerから始めることをお勧めします。 これは、私がこの問題のために数ヶ月間使用してきた「解決策」です。

17.06以降、新しい孤立した差分はなくなります。
代わりに、状態がDeadコンテナーが表示される場合があります。これは、削除中に回復不能なエラーが発生し、管理者がそれに対処する必要がある場合に発生します。

さらに、取り外しはもう少し堅牢で、競合状態やアンマウントの失敗によるエラーが発生しにくくなります。

@ cpuguy83 ：すばらしいニュースです。それが発生した場合、管理者が何をする必要があるか説明できますか？

@Silex原因によります。
通常、発生したのは、一部のマウントがコンテナにリークされたためにdevice or resource busyエラーが発生したことです。 cadvisorのようなものを実行している場合、docker dir全体を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からのアップグレードの場合、それらの差分がそのバージョンによって生成/取り残された可能性があります。 レイヤーの削除に失敗した場合（--forceを使用する場合）、Docker17.06はコンテナーを削除しません。 古いバージョンでは、孤立したレイヤーにつながる可能性がありました

@ 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いいえ。1、2か月前に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インスタンスのディスクスペースの量を2倍にすることでした。 そして、私はそれがくだらない修正であることをよく知っていますが、Dockerの肥大化したaufに対して私が見つけた最良の回避策です。 これは本当に、本当に修正する必要があります。

@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でこれをまだ見ています

まだ何を見ているのですか？
diff dirがリークする可能性はありませんが、diff dirはアップグレード時に存在した場合でも存在しますが、引き続き存在します。

私が知る限り、孤立した差分がまだ表示されています。 docker system pruneはそれらを削除せず、 docker-gcも削除しませんrm -rf /var/lib/docker/aufs/diff/*-removing手動で実行すると機能しているようです。

はい、dockerは古い孤立したdirをまだクリーンアップしません。

古いとは、この問題で以前のバージョンのDockerから作成されたものを意味しますか？

これは、約2週間前に行ったDockerの新規インストールです。これらのオーファンはそれ以降に作成されている必要があるため、dockerはまだこれらのオーファンを作成している必要がありますか？

つまり、過去30分間に、手動でrmしたため、 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.04LTSを実行しています

これをデバッグするために提供できるものがあれば教えてください。

他の理由（スウォームモードネットワーキング）で、Docker用に14.04から移動しました
マシン。
月、2017年8月21日には8:23でORF [email protected]書きました：

/ 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.04LTSを実行しています

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/moby/moby/issues/22207#issuecomment-323773033 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AADRIfE2B2HNpbsKyTOj1CwGzulRT2C0ks5saaDPgaJpZM4IMGt2
。

これは17.06.01-ceで悪化しているようです。 ビルドマシンをこのバージョンに更新すると、すぐにビルドプロセスの一部として*-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 docker ps -a Dead状態のコンテナはありますか？

すべてのDockerビルドサーバーのスペースが不足しています。

先週かそこらでDockerバージョン17.06.1-ce、ビルド874a737にアップグレードしました。 他に何も変わっておらず、この問題はアップグレードプロセスの一部として発生または顕在化したと思います。 aufs diffディレクトリは巨大で、私はすでにすべての画像とぶら下がっているボリュームを剪定しました。

issue-22207.txt
@ cpuguy83どの状態のコンテナもありません。 17.06.01-ceでこれを実証するために私がかろうじて行ったことは次のとおりです。

1. Ubuntu 16.04.03LTSへのdocker17.06.01-ceの新規インストールから開始しました（つまり、dockerがインストールされておらず、/ var / lib / dockerディレクトリもありません）。 インストール後、空の/ var / lib / docker / aufs / diffディレクトリを確認しました。
2. ubuntu：latestに基づく非常に単純なdockerfileを使用してdockerビルドを実行しました。これは、githubからstatsd_exporterをプルして、/ usr / binに抽出するだけです（添付ファイルを参照）。
3. ビルドを実行した後、 docker ps -aを実行して、どの状態のコンテナーも表示しません。 /var/lib/docker/aufs/diffフォルダーにはいくつかの*-remainingフォルダーがあります。
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/*/を実行すると、 /var/lib/docker/aufs/ 5200 du -sch /var/lib/docker/*/表示されます
2. docker rmi $(docker images -q)を実行して、ビルドされたイメージレイヤーを削除します。 この後にdocker system df実行すると、すべてゼロが表示されます。 du -sch /var/lib/docker/*/を実行すると、 /var/lib/docker/aufs/ 5200 *-remaining表示され、以前はそれらがなかったすべてのフォルダーに*-remainingフォルダーもあります。まだそこにあります。

@erikhこれはあなたが経験している問題ですか？

@ cpuguy83 17.06.01-ceをアンインストールし、/ var / lib / dockerディレクトリを削除し、17.06.0-ceをインストールした後、同じビルドを実行しようとします。 17.06.01で修正されたADD from remote URL'sバグが原因で、ビルドが失敗します。 ただし、完了したステップの*-remainingディレクトリが取得されず、 docker system pruneとdocker rmi $(docker image -q)すべてをクリーンアップした後、 /var/lib/docker/aufs/diffディレクトリが再び空になります。スペースが解放されます。

おかげさまで、これは17.06.1でのリグレッションです...
修正するPRはここにあります： https ：

素晴らしい、クイックパッチ@ cpuguy83をありがとう！ / cc @erikh

@rogaha！ はい、あなたと@ cpuguy83に感謝します！

素晴らしいスクリプトをありがとう@Karreg 。 古いophaneddiffをすべて取り除き、失われた大量のディスクスペースを再び解放した後、新しいDockerイメージをインストールする前にVMをクリーンアップするために定期的に使用しています。 現在、この問題に対する大きな助けとほぼ完璧な回避策があります。 @ TP75

Docker、Inc。はコンピューターデータストレージメーカーといくつかの契約を結んでいるようです。

@Karregのスクリプトは私にとっては問題

同じ問題を抱えています。
Dockerホストの詳細

root @ UbuntuCont ：〜＃
コンテナ：3
実行中：0
一時停止：0
停止：3
画像：4
サーバーバージョン：17.06.1-ce
ストレージドライバー：aufs
ルートディレクトリ：/ var / lib / docker / aufs
バッキングファイルシステム：extfs
Dirs：14
サポートされているDirperm1：true
ロギングドライバー：json-file
Cgroupドライバー：cgroupfs
プラグイン：
ボリューム：ローカル
ネットワーク：ブリッジホストmacvlannullオーバーレイ
ログ：awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
群れ：非アクティブ
ランタイム：runc
デフォルトのランタイム：runc
Initバイナリ：docker-init
コンテナバージョン：6e23458c129b551d5c9871e5174f6b1b7f6d1170
runcバージョン：810190ceaa507aa2727d7ae6f4790c76ec150bd2
初期化バージョン：949e6fa
セキュリティオプション：
apparmor
seccomp
プロファイル：デフォルト
カーネルバージョン：4.4.0-93-generic
オペレーティングシステム：Ubuntu 16.04.3 LTS
OSType：linux
アーキテクチャ：x86_64
CPU：1
総メモリ：3.358GiB
名前：UbuntuCont
ID：QQA5：DC5S：C2FL：LCC6：XY6E：V3FR：TRW3： VMOQ：QQKD ：AP2M：H3JA：I6VX
Dockerルートディレクトリ：/ var / lib / docker
デバッグモード（クライアント）：false
デバッグモード（サーバー）：false
レジストリ： https ：
実験的：誤り
安全でないレジストリ：
127.0.0.0/8
ライブ復元が有効：false

root @ UbuntuCont ：/ var / lib /
031c85352fe85f07fede77dee0ac9dc2c7723177a819e72c534e1399208c95fa
09d53040e7e6798b5987ea76fe4f84f0906785b94a392a72e8e41a66cd9f242d
09d53040e7e6798b5987ea76fe4f84f0906785b94a392a72e8e41a66cd9f242d-init
0fb1ffc90969e9706801e2a18870f3ecd857a58f1094fbb968b3fa873e4cf2e4
10549179bd21a9c7af018d4ef305bb9196413b9662fce333b607104c40f38781
10d86a48e03cabf9af2c765dc84824809f24674ac339e4b9ffe572f50bd26b9c-init-削除
10d86a48e03cabf9af2c765dc84824809f24674ac339e4b9ffe572f50bd26b9c-削除
2e226946e8e6c2b3613de2afcff4cbb9890b6d9bd365fdda121a51ae96ec5606
2e226946e8e6c2b3613de2afcff4cbb9890b6d9bd365fdda121a51ae96ec5606-init
3601f6953132f557df8b52e03016db406168d3d6511d7ff5c08a90925ea288da-init-削除
3601f6953132f557df8b52e03016db406168d3d6511d7ff5c08a90925ea288da-削除
4b29141243aea4e70472f25a34a91267ab19c15071862c53e903b99740603d4c-init-削除
4b29141243aea4e70472f25a34a91267ab19c15071862c53e903b99740603d4c-削除
520e3fcf82e0fbbb48236dd99b6dee4c5bb9073d768511040c414f205c787dc5-init-削除
520e3fcf82e0fbbb48236dd99b6dee4c5bb9073d768511040c414f205c787dc5-削除
59cbb25a4858e7d3eb9146d64ff7602c9abc68509b8f2ccfe3be76681481904f
5d1c661b452efce22fe4e109fad7a672e755c64f538375fda21c23d49e2590f6
605893aba54feee92830d56b6ef1105a4d2166e71bd3b73a584b2afc83319591
63bd53412210f492d72999f9263a290dfee18310aa0494cb92e0d926d423e281-init-削除
63bd53412210f492d72999f9263a290dfee18310aa0494cb92e0d926d423e281-削除
72146e759ab65c835e214e99a2037f4b475902fdbe550c46ea0d396fb5ab2779-init-削除
72146e759ab65c835e214e99a2037f4b475902fdbe550c46ea0d396fb5ab2779-削除
8147e0b06dcbce4aa7eb86ed74f4ee8301e5fe2ee73c3a80dcb230bd0ddfcc26-init-削除
8147e0b06dcbce4aa7eb86ed74f4ee8301e5fe2ee73c3a80dcb230bd0ddfcc26-削除
a72735551217bb1ad01b77dbdbb9b8effa9f41315b0c481f8d74b5606c50deb4
aa58f2000b9f7d1ed2a6b476740c292c3c716e1d4dc04b7718580a490bba5ee8
b552cb853e33a8c758cb664aec70e2c4e85eacff180f56cbfab988a8e10c0174-削除
cd80c351b81ed13c4b64d9dfdc20c84f6b01cbb3e26f560faf2b63dae12dec55-init-削除
cd80c351b81ed13c4b64d9dfdc20c84f6b01cbb3e26f560faf2b63dae12dec55-削除
fe903be376821b7afee38a016f9765136ecb096c59178156299acb9f629061a2
fe903be376821b7afee38a016f9765136ecb096c59178156299acb9f629061a2-init

@kasunsjcあなたのすぐ上の投稿を読んでください。

17.06.2へのアップグレードを確認します-ceはこの問題を解決しました。 アップグレード後も（前回）手動でディレクトリを作成する必要はありませんでした。

17.06.2-ceは、私にもこれを修正したようです。 そこに-removingディレクトリはもうありません、まともな量のスペースを取り戻しました。

aufs/diffある-initディレクトリは無関係だと思います（それらのいくつかはかなり古いです）。 しかし、それらはすべて小さいので、それはほとんど問題ではありません。

17.07.0にアップデートすると、ここでも問題が解決しました。 docker system prune --all -fさえ、以前はディレクトリが削除されません

この問題の確認は、Ubuntu16.04と17.06.2-ceで解決されました。 更新されるとすぐに、スペースがクリアされました。