# 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

Saya juga harus menunjukkan bahwa buruh pelabuhan tidak mencantumkan kontainer, volume, atau gambar:

$ 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

aneh; terutama karena;

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

yang tidak cocok dengan keluaran docker images / docker ps .

Sistem operasi apa yang Anda jalankan?

Operating System: <unknown>

@tonistiigi ada ide?

Itu sesudahnya. Saya kira beberapa proses dimulai sementara itu.

Status yang saya maksud (yang saya miliki sekarang) adalah:

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

Dan saya masih memiliki:

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

Kami menggunakan Ubuntu Lucid dengan kernel yang ditingkatkan = /

$ 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

Sepertinya masalah yang menarik.
apakah mungkin ada cara untuk mereproduksinya? @bukor

Memang mungkin, tapi saya tidak tahu caranya.
Silakan coba menjalankan skrip di bawah ini pada salah satu host galangan aktif Anda dan lihat apa yang tersisa.
Dalam kasus kami, selalu ada banyak perbedaan yang tertinggal.

`` #! pesta

! / bin / bash

set -eu

echo "PERINGATAN :: Ini akan menghentikan SEMUA proses buruh pelabuhan dan menghapus SEMUA gambar buruh pelabuhan."
baca -p "Lanjutkan (y / n)?"
jika ["$ REPLY"! = "y"]; kemudian
echo "Membatalkan".
keluar 1
fi

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

set -x

pindahkan kontainer

buruh pelabuhan ps -q | xdocker berhenti
buruh pelabuhan ps -aq | xdocker rm

hapus tag

gambar buruh pelabuhan | sed 1d | grep -v '^'| col 1 2 | sed 's / /: /' | xdocker rmi

hapus gambar

gambar buruh pelabuhan -q | xdocker rmi
gambar buruh pelabuhan -aq | xdocker rmi

hapus volume

volume buruh pelabuhan ls -q | xdocker volume rm
``

Salah satu cara yang mungkin saya lihat ini terjadi adalah jika ada kesalahan pada aufs unmounting. Misalnya, jika ada kesalahan EBUSY maka kemungkinan konfigurasi gambar telah dihapus sebelumnya.

@bukzor Akan sangat menarik jika ada pembuat ulang yang akan mulai dari direktori grafik kosong, tarik / jalankan gambar dan masukkan ke dalam keadaan di mana ia tidak sepenuhnya bersih setelah menjalankan skrip Anda.

Itu akan menarik, tapi kedengarannya seperti pekerjaan sehari penuh.
Saya tidak bisa berkomitmen untuk itu.

Berikut ini beberapa data lainnya mengenai diff merepotkan (dipilih secara sewenang-wenang) di atas, a800 .

`` #! sh
$ buruh pelabuhan-temukan a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea | sudo xargs -n1 wc -l | sort -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 / buruh pelabuhan / aufs / lapisan / 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 / buruh pelabuhan / image / aufs / layerdb / sha256 / d1c659b8e3d0e893e95c8eedc755adcb91a1c2022e1090376b451f7206f9b1c0 / cache-id

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

$ buruh pelabuhan-temukan 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 --warna '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 --warna -l 'f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 $'
  / nail / var / lib / buruh pelabuhan / 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:

$ buruh pelabuhan-temukan 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 - warna eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e
  / nail / var / lib / buruh pelabuhan / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e
  / nail / var / lib / buruh pelabuhan / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / mount-id
  / nail / var / lib / buruh pelabuhan / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / init-id
  / nail / var / lib / buruh pelabuhan / 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 --warna -l eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e
  ``

Apakah ada cara untuk menemukan container yang digunakan untuk mount?
Doc hanya mengatakan ID pemasangan tidak lagi sama dengan ID penampung, yang tidak terlalu membantu.
https://docs.docker.com/engine/userguide/storagedriver/aufs-driver/

@bukzor eb809c0321 adalah id kontainer. Apa yang dimaksud dokumen adalah bahwa aufs id ( f3286009193f dalam kasus Anda) bukan container id.

/ cc @dmcgowan juga

@sistigi OK.

Maka jelas mount telah hidup lebih lama dari kontainernya.

Pada titik mana dalam siklus hidup kontainer dudukan dibersihkan?
Apakah ini auf sementara yang dapat ditulis untuk menjalankan / menghentikan kontainer?

Mount @bukzor (rw) dihapus saat kontainer dihapus. Lepas terjadi saat proses penampung berhenti. Folder diff adalah tempat di mana konten lapisan individu disimpan, tidak masalah apakah lapisan tersebut dipasang atau tidak.

@bukzor Link antara aufs id dan container id dapat ditemukan di image/aufs/layerdb/mounts/<container-id>/mount-id . Dari sekedar mengetahui id aufs, cara termudah untuk menemukan id kontainer adalah dengan grep direktori image/aufs/layerdb untuknya. Jika tidak ada yang ditemukan, maka pembersihan tidak selesai dengan bersih.

Mengalami masalah serupa.

Kami menjalankan CI harian di server daemon buruh pelabuhan. / var / lib / docker / aufs / diff membutuhkan kapasitas disk yang cukup tinggi, yang seharusnya tidak demikian.

Masih 2gb dalam aufs/diff setelah mencoba semua yang disarankan di sini atau di utas terkait (termasuk skrip bash @bukzor di atas).

Singkatnya, perbaikan yang tepat, apakah ada cara mudah untuk menghapus sisa tunggangan tanpa menghapus semua gambar lain pada saat yang bersamaan? (Jika tidak ada kontainer yang berjalan saat ini, saya kira seharusnya tidak ada tunggangan, bukan?)

Saya mengalami masalah yang sama. Saya menggunakan mesin ini untuk menguji banyak kontainer, lalu komit / hapus. Direktori / var / lib / docker / aufs saya saat ini berat 7,9G. Saya harus memindahkan direktori ini ke mount point lain, karena penyimpanan yang satu ini terbatas. :(

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

@mcallaway Semua yang ada di aufs/diff akan dilakukan fs penulisan dalam sebuah wadah.

Saya memiliki masalah yang sama. Semua kontainer yang saya miliki dalam keadaan berjalan, tetapi ada banyak direktori aufs diff yang tidak berhubungan dengan kontainer ini dan berhubungan dengan kontainer lama yang dihapus. Saya dapat menghapusnya secara manual, tetapi itu bukan pilihan. Harus ada alasan untuk perilaku seperti itu.

Saya menggunakan k8s 1.3.5 dan buruh pelabuhan 1.12.

Menjalankan docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc spotify/docker-gc membantu.

Saya memiliki masalah yang sama. Saya menggunakan Gitlab CI dengan dind (buruh pelabuhan di buruh pelabuhan).

IMHO ketika gambar dalam registri diperbarui dalam tag yang sama dan ditarik, kemudian penampung terkait dimulai ulang, penampung lama dan gambar tidak digabungkan kecuali Anda menjalankan spotify/docker-gc .

Bisakah orang lain mengkonfirmasi ini?

@kayrus benar, buruh pelabuhan tidak akan secara otomatis menganggap bahwa gambar "tanpa tag" juga harus _removed_. Penampung masih bisa menggunakan gambar itu, dan Anda masih bisa memulai penampung baru dari gambar itu (mereferensikannya dengan ID-nya). Anda dapat menghapus gambar "menjuntai" menggunakan docker rmi $(docker images -qa -f dangling=true) . Selain itu, buruh pelabuhan 1.13 akan mendapatkan perintah manajemen data (lihat https://github.com/docker/docker/pull/26108), yang memungkinkan Anda untuk lebih mudah membersihkan gambar yang tidak digunakan, wadah, dll.

@thaJeztah apakah /var/lib/docker/aufs/diff/ sebenarnya berisi gambar "tanpa tanda"?

@kayrus ya mereka adalah bagian dari gambar (diberi tag, dan tidak diberi tag)

mendapatkan masalah serupa, tidak ada kontainer / gambar / volume, ~ 13Gb dari diffs

$ 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

Masalah yang sama di sini. Saya mengerti 1.13 mungkin mendapatkan perintah manajemen data tetapi sementara itu, saya hanya ingin menghapus konten direktori ini dengan aman tanpa mematikan Docker.

Ini relatif menghalangi saat ini.

Sama disini. Masih belum ada solusi resmi?

Saya telah membahas ini beberapa kali di (Komunitas Docker) Slack. Setiap kali segelintir orang menjalankan daftar skrip / cmds pengumpulan sampah, saya harus menjalankannya sebagai solusi.

Sementara itu telah membantu (baca: tidak terpecahkan - ruang masih merayap menuju penuh) untuk sementara, saya pikir kita semua bisa setuju bahwa itu bukan perbaikan jangka panjang yang ideal.

@jadametz 1.13 memiliki docker system prune .
Selain itu, saya tidak yakin bagaimana lagi Docker dapat membantu (terbuka untuk saran). Gambar tidak hanya sampai ke sistemnya sendiri, tetapi melalui tarikan, build, dll.

Dalam hal lapisan yatim piatu yang sebenarnya (tidak ada gambar di sistem yang mereferensikannya), kita perlu mengatasinya secara terpisah.

Saya memiliki masalah yang persis sama!

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

Tidak ada gambar, wadah atau volume. 42 Gb dalam aufs / diff

Apa pun untuk membantu membersihkan direktori ini dengan aman akan sangat berguna! Mencoba semuanya di utas ini tanpa hasil. Terima kasih.

@adamdry hanya skrip pihak ketiga: https://github.com/docker/docker/issues/22207#issuecomment -252560212

Terima kasih @kayrus Saya memang mencobanya dan itu meningkatkan penggunaan disk total saya sedikit dan tampaknya tidak melakukan apa pun ke direktori aufs / diff.

Saya juga mencoba docker system prune yang tidak berjalan. Dan saya mencoba docker rmi $(docker images -qa -f dangling=true) yang tidak menemukan gambar untuk dihapus.

Bagi siapa pun yang tertarik, saya sekarang menggunakan ini untuk membersihkan semua kontainer, gambar, volume, dan auf lama:

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

Banyak inspirasi diambil dari sini: 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 Sebaiknya tidak menggunakan -f saat melakukan rm / rmi karena akan menyembunyikan kesalahan dalam penghapusan.
Saya mempertimbangkan situasi saat ini ... di mana -f menyembunyikan kesalahan dan kemudian kita dibiarkan dengan beberapa status tersisa yang sama sekali tidak terlihat oleh pengguna ... sebagai bug.

Saya juga melihat ini pada instalasi yang benar-benar baru dan tidak mengejutkan:

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 Karena ini adalah pemasangan baru, apakah Anda ingin mencoba ini? https://github.com/docker/docker/issues/22207#issuecomment -266784433

@adamdry Saya sudah menghapus /var/lib/docker/aufs karena memblokir pekerjaan saya. Apa yang Anda harapkan dari instruksi Anda? Jika mereka menghentikan masalah agar tidak terjadi lagi di masa mendatang, saya dapat mencoba membuat ulang masalah tersebut dan mencoba instruksi Anda. Namun jika tujuannya hanya untuk membebaskan ruang maka saya sudah mencapainya.

@robhaswell Ya itu untuk mengosongkan ruang disk tetapi saya memiliki masalah tindak lanjut ketika mencoba membangun kembali gambar saya tetapi dengan mengikuti semua langkah dalam skrip itu menyelesaikan masalah tersebut.

Selama build, jika proses build terputus selama proses build lapisan (yang juga berisi blob yang akan disalin), diikuti dengan menghentikan container, data akan tertinggal di / var / lib / docker / aufs / diff /. Itu menunjukkan gambar yang menggantung. Membersihkannya juga tidak membebaskan ruang. Apakah mungkin untuk memasukkannya sebagai bagian dari pemangkasan sistem buruh pelabuhan? Hanya menghapus data blob di dalam folder ini akan membebaskan ruang, yang saya tidak yakin akan menyebabkan masalah atau tidak.

Versi Docker: 1.13.0-rc1

Selama pembuatan, jika proses pembangunan terganggu selama proses pembangunan lapisan (yang juga berisi blob untuk disalin), diikuti dengan menghentikan penampung, itu meninggalkan data

Ini juga bisa menjadi penyebab masalah saya - saya mengganggu banyak bangunan.

Selama buruh pelabuhan menarik, mengamati dua kasus berikut:

1. jika proses terputus ketika dikatakan unduh (yang mengunduh lapisan gambar di / var / lib / docker / tmp /), itu membersihkan semua data di folder itu
2. Jika proses terputus ketika dikatakan mengekstrak (yang saya kira mengekstrak lapisan dari tmp ke / var / lib / docker / aufs / diff /), itu membersihkan data tmp dan diff blob keduanya.

Selama proses pembuatan gambar,

1. Saat mengganggu proses saat "Mengirim konteks build ke daemon buruh pelabuhan" (yang menyalin data blob dalam kasus saya di / var / lib / docker / tmp /), itu tetap di sana selamanya dan tidak dapat dibersihkan dengan perintah apa pun kecuali menghapusnya secara manual. Saya tidak yakin bagaimana apt get update dalam gambar ditangani.
2. Saat lapisan sedang dibangun yang berisi data blob, katakanlah pengaturan perangkat lunak besar, jika prosesnya terganggu, penampung buruh pelabuhan terus bekerja pada gambar. Dalam kasus saya, hanya 1 lapisan data blob, yang sudah tersedia di folder tmp, yang membentuk keseluruhan gambar. Namun, jika container dihentikan menggunakan perintah docker stop, dua kasus terjadi:
   Sebuah. jika proses mount masih terjadi, data akan tertinggal di folder tmp dan diff.
   b. Jika data disalin dalam folder diff, itu akan menghapus data dari folder tmp dan meninggalkan data di folder diff dan mungkin folder mount.

Kami memiliki proses build otomatis, yang membutuhkan kontrol untuk menghentikan proses build apa pun dengan baik. Baru-baru ini, sebuah proses terbunuh oleh kernel karena kesalahan kehabisan memori pada mesin yang konfigurasinya rendah.

Jika satu gambar akan dibangun dari 2 lapisan, 1 lapisan dibuat dan yang kedua terputus, pemangkasan sistem Docker tampaknya membersihkan data untuk penampung lapisan yang terputus dan penampung dihentikan. Tetapi itu tidak membersihkan data dari lapisan sebelumnya jika terjadi interupsi. Selain itu, ini tidak mencerminkan total ruang disk yang diklaim. Menjalankan pengujian ini pada sistem bit AWS, ubuntu 14.04, x86_64 dengan sistem file aufs. Menjalankan uji pangkas buruh pelabuhan dengan buruh pelabuhan 1.13.0 rc3 dan buruh pelabuhan 1.12

@bayu_joo
Tolong beri tahu saya jika saya salah menafsirkan sesuatu.

Saya membuka masalah untuk file /var/lib/docker/tmp tidak dibersihkan; https://github.com/docker/docker/issues/29486

Pemangkasan sistem Docker tampaknya membersihkan data untuk penampung lapisan yang terputus dan penampung dihentikan. Tetapi itu tidak membersihkan data dari lapisan sebelumnya jika terjadi interupsi.

Saya mencoba mereproduksi situasi itu, tetapi tidak dapat melihatnya dengan kasus sederhana;

Mulailah dengan instalasi bersih kosong /var/lib/docker , buat file besar untuk
pengujian, dan Dockerfile;

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

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

mulai docker build , dan batalkan saat membangun, tetapi _setelah_ pembuatan
konteks telah dikirim;

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

periksa konten /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/

jalankan perintah docker system prune untuk membersihkan gambar, kontainer;

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

periksa konten /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/

Saya melihat bahwa mount -init tertinggal, saya akan memeriksa apakah kita dapat menyelesaikannya
itu (meskipun itu hanya direktori kosong)

Satu-satunya perbedaan dalam dockerfile yang saya gunakan adalah (untuk membuat lapisan yang berbeda)
DARI awal
SALIN ["./bigfile", "randomNoFile1", /]
SALIN ["./bigfile", "randomNoFile2", /]
EOF

Saya tidak yakin apakah itu membuat perbedaan.

Tidak, masalahnya bukan pada folder init yang kosong. Dalam kasus saya, itu adalah te blob. Namun, saya dapat memeriksanya kembali pada hari Senin dan memperbarui.

Juga, menggunakan file 5GB, dibuat dengan membaca byte dari dev urandom.
Dalam kasus Anda, file yang sama ditambahkan 2 kali. Apakah itu akan membuat satu lapisan dan memasang lapisan ke-2 darinya atau apakah itu akan menjadi 2 lapisan terpisah? Dalam kasus saya, selalu ada 2 lapisan terpisah.

@bayu_joo
Terima kasih atas tanggapan yang cepat tentang masalah ini. Penambahan fitur ini akan sangat membantu!

@ monikakatiyar16 Saya mencoba untuk mereproduksi ini juga dengan membatalkan build beberapa kali selama perintah ADD dan RUN tetapi tidak bisa membuat apa pun bocor ke aufs/diff setelah penghapusan. Saya tidak begitu mengerti penampung apa yang Anda hentikan karena penampung tidak boleh berjalan selama operasi ADD/COPY . Jika Anda dapat mengumpulkan reproduksi yang dapat kami jalankan, itu akan sangat kami hargai.

Mungkin saja saya melakukan sesuatu yang salah. Karena saya bepergian pada akhir pekan, saya akan memperbanyaknya dan memperbarui semua info yang diperlukan di sini pada hari Senin.

@tonistiigi @thaJeztah
Saya merasa Anda benar. Sebenarnya tidak ada kontainer yang terdaftar sebagai aktif dan berjalan. Sebaliknya ada kontainer mati. Pemangkasan sistem Docker tidak berfungsi dalam kasus saya, mungkin karena prosesnya tidak terbunuh dengan Ctrl + C. Sebaliknya, itu terus berjalan di latar belakang. Dalam kasus saya, itulah alasannya, itu tidak dapat menghapus gumpalan itu.

Ketika saya menghentikan proses menggunakan Ctrl + C, proses pembuatan akan terhenti, tetapi proses untuk buruh pelabuhan tetap hidup di latar belakang, yang terus bekerja untuk membangun gambar. (Catatan: / var / lib / docker ditautkan secara lunak ke / home / lib / docker untuk menggunakan volume EBS untuk data besar di AWS)

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

Saya telah melampirkan skrip yang telah saya gunakan untuk membuat file besar dan membangun gambar (gc_maxpush_pull.sh)

Lampirkan juga perilaku proses build untuk membangun image-interupsi dengan Ctrl + C (DockerBuild_WOProcessKill) dan membangun image -menginterupsi dengan Ctrl + C - mematikan proses (DockerBuild_WithProcessKill)

Menggunakan perintah -

Untuk membuat file besar: ./gc_maxpush_pull.sh 1 5gblayer 0 512 1

Untuk membuat gambar: ./gc_maxpush_pull.sh 1 5gblayer 1 512 1

DockerBuild.zip

Langkah-langkah untuk mereplikasi:

1. Buat file besar 5GB
2. Mulai proses build dan hentikan hanya setelah Mengirim konteks build selesai dan blob benar-benar disalin.
3. Ini menyelesaikan pembuatan gambar setelah beberapa saat dan menampilkannya di gambar buruh pelabuhan (seperti dalam kasus 1 yang saya lampirkan - DockerBuild_WOProcessKill)
4. Jika proses dimatikan, dibutuhkan beberapa saat dan meninggalkan data blob di / diff (yang seharusnya mematikan proses secara tiba-tiba seperti yang dilampirkan dalam file - DockerBuild_WithProcessKill)

Jika apa yang saya asumsikan benar, maka ini mungkin bukan masalah dengan pemangkasan buruh pelabuhan, alih-alih dengan pembunuhan buruh pelabuhan yang entah bagaimana tidak berfungsi untuk saya.

Adakah cara yang baik untuk menginterupsi atau menghentikan proses image build, yang juga menangani pembersihan data yang disalin (seperti yang ditangani dalam docker pull)?

Sebelumnya, saya tidak menghentikan proses tersebut. Saya juga ingin tahu apa yang dilakukan oleh docker-untar dan mengapa ia me-mount ke / mnt dan / diff folder keduanya dan kemudian membersihkan folder / mnt?

Menguji ini dengan Docker versi 1.12.5, membangun 7392c3b di AWS

info buruh pelabuhan
Wadah: 2
Tayang: 0
Dijeda: 0
Berhenti: 2
Gambar: 0
Versi Server: 1.12.5
Driver Penyimpanan: aufs
Root Dir: / home / lib / docker / aufs
Sistem File Dukungan: extfs
Sutradara: 4
Dirperm1 Didukung: false
Driver Logging: json-file
Pengemudi Cgroup: cgroupfs
Plugin:
Volume: lokal
Jaringan: overlay jembatan null host
Swarm: tidak aktif
Durasi: runc
Waktu Proses Default: runc
Opsi Keamanan: apparmor
Versi Kernel: 3.13.0-105-generik
Sistem Operasi: Ubuntu 14.04.4 LTS
OSType: linux
Arsitektur: x86_64
CPU: 2
Memori Total: 3,859 GiB
Nama: master
ID: 2 NQU: D2C5 : 5 WPL: IIDR : P6FO: OAG7: GHW6: ZJMQ: VDHI : B5CI: XFZJ: ZSZM
Docker Root Dir: / home / lib / docker
Mode Debug (klien): salah
Mode Debug (server): salah
Registri: https://index.docker.io/v1/
PERINGATAN: Tidak ada dukungan batas swap
Registri Tidak Aman:
127.0.0.0/8

@ monikakatiyar16 Ketika saya secara manual mematikan proses untar selama proses pembuatan, saya mendapatkan Error processing tar file(signal: killed): dalam keluaran build. Meninggalkan container di docker ps -a adalah perilaku yang benar, hal yang sama terjadi pada error build apa pun dan memungkinkan Anda men-debug masalah yang menyebabkan build gagal. Saya tidak punya masalah dengan menghapus kontainer ini dan jika saya melakukan itu semua data di /var/lib/docker/aufs juga dibersihkan.

@tonistiigi Ya, Anda benar. Saya dapat menghapus volume yang terkait dengan wadah dan itu membersihkan semuanya, setelah mematikan proses buruh pelabuhan-untar. Pemangkasan sistem Docker juga berfungsi dalam kasus ini.

Masalah sebenarnya yang tersisa volume adalah kasusnya, ketika tanpa mematikan proses buruh pelabuhan-untar, saya mencoba menghapus kontainer buruh pelabuhan bersama dengan volume - yang memberikan kesalahan berikut:

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

Log daemon:

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

Tampaknya urutan yang sekarang harus diikuti untuk menginterupsi build buruh pelabuhan adalah:
Interrupt docker build > Kill docker untar process > remove container and volume : docker rm -v -f $(docker ps -a -q)

Untuk docker v1.13.0-rc4 , bisa jadi Interrupt docker build > Kill docker untar process > docker system prune -a

Ini sepertinya bekerja dengan sempurna. Tidak ada masalah pembersihan, sebagai gantinya satu-satunya masalah adalah proses docker-untar tidak dimatikan bersama dengan proses pembuatan buruh pelabuhan.

Saya akan mencari / memperbarui / mencatat masalah baru untuk interupsi anggun dari build buruh pelabuhan yang juga menghentikan proses docker-untar bersamanya.

(Diverifikasi ini dengan docker v1.12.5 dan v1.13.0-rc4)

Pembaruan: Saat membunuh docker-untar saat Mengirim konteks build ke daemon docker, ini memberikan kesalahan dalam build: Error response from daemon: Error processing tar file(signal: terminated) , tetapi selama salin lapisan tidak (untuk saya)

Terima kasih telah bersabar dan meluangkan waktu Anda!

Saya melihat /var/lib/docker/aufs secara konsisten bertambah besar ukurannya pada pekerja mode gerombolan buruh pelabuhan. Hal ini sebagian besar otonom dikelola oleh swarm manager dan sangat sedikit pembuatan kontainer manual selain dari beberapa perintah pemeliharaan di sana-sini.

Saya menjalankan docker exec pada wadah layanan; tidak yakin apakah itu mungkin menjadi penyebabnya.

Solusi saya untuk menyelesaikan ini dalam kasus saya adalah memulai pekerja lain, mengatur simpul penuh ke --availability=drain dan secara manual memindahkan beberapa tunggangan volume.

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

Ini telah menghantam server CI kami selama berabad-abad. Ini perlu diperbaiki.

@orf terima kasih

Masalah yang sama di sini. Baik kontainer, volume, dan penghapusan gambar, atau perintah pembersihan Docker 1.13 tidak memiliki efek apa pun.

Saya juga mengonfirmasi bahwa saya melakukan beberapa pembatalan pembuatan gambar. Mungkin itu meninggalkan folder yang tidak bisa digapai juga.
Saya akan menggunakan metode rm lama yang baik untuk saat ini, tetapi ini jelas bug.

File di / var / lib / docker / aufs / diff mengisi 100% ruang untuk / dev / sda1 filesystem 30G

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

Ukuran Sistem File Digunakan Tersedia Penggunaan% Terpasang
udev 14G 0 14G 0% / dev
tmpfs 2.8G 273M 2.5G 10% / berjalan
/ 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 / pengguna / 1000

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

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

Juga mencoba, sistem buruh pelabuhan memangkas , itu tidak membantu.

Adakah yang menemukan solusi untuk masalah file super besar yang sedang berlangsung di diff sebelum bug ini diperbaiki dalam kode?

Ya, metodenya telah diberikan, tetapi di sini adalah cuplikan kiamat yang hanya menghancurkan semua yang saya tempatkan di sini di tempat kerja (kecuali folder lokal untuk volume). Untuk dimasukkan ke dalam bashrc atau file konfigurasi bash lainnya.

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

func_full-cleanup-docker () {

echo "PERINGATAN: Ini akan menghapus semua dari buruh pelabuhan: volume, kontainer dan gambar. Berani? [y / T]"
pilihan baca

if [("$ choice" == "y") -o ("$ choice" == "Y")]
kemudian
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
} ``

Saya menjalankan perintah rm -rf untuk menghapus file dari folder diff untuk saat ini. Mungkin harus memeriksa skrip jika folder diff menempati seluruh ruang disk lagi.
Berharap untuk melihat masalah ini diperbaiki dalam kode, alih-alih mengatasinya.

Hai, saya memiliki masalah yang sama di buruh pelabuhan 1.10.2, saya menjalankan kubernetes. ini adalah versi buruh pelabuhan saya:

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

Saya mencoba melacak semua direktori diff yang tidak digunakan di bawah /var/lib/docker/aufs/diff dan /var/lib/docker/aufs/mnt/ dengan menganalisis file lapisan di bawah /var/lib/docker/image/aufs/imagedb , berikut ini skrip yang saya gunakan:

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

Tapi saya menemui masalah ketika saya berhenti dan me-restart daemon buruh pelabuhan, sepertinya saya membuat beberapa status buruh pelabuhan tidak konsisten:

/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

dan ketika saya mencoba membuat penampung baru dengan docker run , gagal dengan pesan:

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

dan daemon log menunjukkan:

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

apakah ada yang tahu apakah pendekatan saya benar atau tidak? dan mengapa masalah terjadi setelah saya menghapus folder tersebut?

Saya membuka # 31012 untuk setidaknya memastikan kami tidak membocorkan direktori ini dalam keadaan apa pun.
Kita tentunya juga perlu melihat berbagai penyebab kesalahan busy

Ini menggigit saya selama saya bisa ingat. Saya mendapatkan hasil yang hampir sama seperti yang dijelaskan di atas ketika saya beralih ke overlay2 driver beberapa hari yang lalu dan nuked folder aufs sepenuhnya ( docker system df mengatakan 1.5Gigs, df mengatakan 15Gigs) .

Saya memiliki sekitar 1T diff menggunakan penyimpanan. Setelah me-restart daemon buruh pelabuhan saya - Saya memulihkan sekitar 700GB. Jadi saya kira menghentikan daemon memangkas ini?

Sayangnya, memulai ulang tidak melakukan apa-apa bagi saya.

Layanan restart tidak membantu. Ini masalah serius. Menghapus semua wadah / gambar tidak menghapus perbedaan itu.

Menghentikan daemon tidak akan memangkas ini.

Jika Anda menghapus semua penampung dan Anda masih memiliki diff dirs, kemungkinan Anda memiliki beberapa lapisan rw yang bocor.

Kami baru saja mengalami masalah ini. /var/lib/docker/aufs/diff menggunakan 28G dan mengambil sistem file root kami ke 100%, yang menyebabkan server GitLab kami berhenti merespons. Kami menggunakan buruh pelabuhan untuk GitLab CI. Untuk memperbaikinya, saya menggunakan beberapa perintah @sogetimaitral yang disarankan di atas untuk menghapus file temp, dan kami kembali aktif dan berjalan. Saya me-restart server dan mengirim komit baru untuk memicu CI, dan semuanya tampak berfungsi sebagaimana mestinya.

Saya sangat khawatir ini akan terjadi lagi. Apa masalahnya di sini? Apakah ini bug buruh pelabuhan yang perlu diperbaiki?

1. Ya, ada bug (keduanya ada masalah saat penghapusan dan --force on rm mengabaikan masalah ini)
2. Umumnya seseorang tidak boleh menulis banyak data ke wadah fs dan sebaliknya menggunakan volume (bahkan volume yang dibuang). Sebuah diff dir yang besar akan menunjukkan bahwa ada sejumlah besar data yang sedang ditulis ke wadah fs.

Jika Anda tidak menggunakan "--force" saat dihapus, Anda tidak akan mengalami masalah ini (atau setidaknya Anda akan melihat Anda memiliki banyak kontainer "mati" dan tahu bagaimana / apa yang harus dibersihkan.).

Saya sama sekali tidak menggunakan buruh pelabuhan secara manual. Kami menggunakan gitlab-ci-multi-runner . Mungkinkah itu bug di akhir GitLab?

Sepertinya (secara default) kontainer itu menghapus paksa; https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/dbdbce2848530df299836768c8ea01e209a2fe40/executors/docker/executor_docker.go#L878. Melakukannya dapat mengakibatkan kegagalan untuk menghapus penampung yang diabaikan, dan menyebabkan perbedaan yang tidak terpenuhi.

Oke, itu memberi tahu saya bahwa ini adalah bug gitlab-ci-multi-runner. Apakah itu interpretasi yang benar? Saya senang membuat masalah bagi mereka untuk memperbaikinya.

Ini kombinasi yang kurasa; penghapusan "paksa" mempermudah menangani pembersihan (yaitu, kasus di mana penampung belum dihentikan, dll), pada saat yang sama (itu adalah "bug" @ cpuguy83 yang disebutkan), ini juga dapat menyembunyikan masalah yang sebenarnya, seperti buruh pelabuhan gagal menghapus filesystem container (yang dapat disebabkan oleh berbagai alasan). Dengan "kekuatan", wadah akan dihapus dalam kasus seperti itu. Tanpa, kontainer dibiarkan (tapi bertanda "mati")

Jika pelari gitlab dapat berfungsi dengan benar tanpa melepas paksa, itu mungkin bagus untuk diubah (atau membuatnya dapat dikonfigurasi)

Saya menggunakan Drone dan memiliki masalah yang sama. Saya tidak memeriksa kode bagaimana kontainer dihapus, tetapi saya rasa itu juga dihapus paksa.

Mungkinkah itu masalah Docker di Docker? Saya memulai Drone dengan docker-compose.

Saya memutuskan untuk melanjutkan dan mengirimkan masalah gitlab-ci-multi-runner hanya untuk mengulang pengembang di: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

Sejujurnya kami mengatasi ini dengan menjalankan docker gc Spotify dengan drone CI.

El El mar, mar. 28, 2017 pukul 15.38, Geoffrey Fairchild <
[email protected]> escribió:

Saya memutuskan untuk melanjutkan dan mengirimkan masalah gitlab-ci-multi-runner hanya untuk
putar devs di:
https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/22207#issuecomment-289926298 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AC6Wz197zkjWWOlq1-JOibiQP-xJym9Eks5rqYvegaJpZM4IMGt2
.

@sedouard Terima kasih atas tip ini! Menjalankan docker-gc setiap jam dari spotify memecahkan masalah bagi saya.

Kami mendapatkan masalah ini berjalan dari Gitlab CI (tidak berjalan di buruh pelabuhan), menggunakan perintah untuk membangun image / menjalankan kontainer, (bukan integrasi Gitlab CI Docker). Kami tidak menjalankan pemindahan paksa dalam bentuk apa pun, cukup docker run --rm ... dan docker rmi image:tag

EDIT : maaf, sebenarnya masalah aslinya sama. Perbedaannya adalah menjalankan spotify/docker-gc tidak _not_ memperbaiki masalah.

Seperti yang Anda lihat di bawah, saya punya 0 gambar, 0 kontainer, tidak ada!
docker system info setuju dengan saya, tetapi menyebutkan Dirs: 38 untuk penyimpanan aufs.

Itu mencurigakan! Jika Anda melihat /var/lib/docker/aufs/diff/ , kami melihat bahwa sebenarnya ada 1,7 GB data di sana, lebih dari 41 direktori. Dan itu kotak pribadi saya, di server produksi itu 19 GB.

Bagaimana kita membersihkan ini? menggunakan spotify/docker-gc tidak menghapus ini.

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

Dapatkah saya dengan aman rm -r /var/lib/docker/aufs dan memulai ulang docker deamon?

Menjalankan spotify/docker-gc tidak membersihkan anak yatim piatu itu.

EDIT : terima kasih @CVTJNII!

Menghentikan daemon Docker dan menghapus semua / var / lib / docker akan lebih aman. Menghapus / var / lib / docker / aufs akan menyebabkan Anda kehilangan gambar Anda, jadi lebih baik memulai dengan clean / var / lib / docker menurut saya. Ini adalah "solusi" yang telah saya gunakan selama beberapa bulan untuk masalah ini sekarang.

Dimulai dengan 17,06 seharusnya ada lagi diffs yatim baru.
Sebaliknya, Anda mungkin mulai melihat penampung dengan status Dead , ini terjadi jika ada kesalahan selama penghapusan yang tidak dapat dipulihkan dan mungkin memerlukan admin untuk menanganinya.

Selain itu, penghapusan sedikit lebih kuat, dan tidak terlalu rentan terhadap kesalahan karena kondisi balapan atau pelepasan yang gagal.

@ cpuguy83 : berita bagus, dapatkah Anda menjelaskan apa yang harus dilakukan admin jika itu terjadi?

@Silex Itu tergantung pada penyebabnya.
Biasanya yang terjadi adalah kesalahan device or resource busy karena beberapa mount bocor ke dalam container. Jika Anda menjalankan sesuatu seperti cadvisor ini cukup banyak jaminan seperti instruksi yang dikatakan untuk memasang seluruh direktori buruh pelabuhan ke dalam wadah cadvisor.

Ini bisa jadi rumit, Anda mungkin harus menghentikan penampung yang melanggar, lalu menghapus penampung dead .

Jika Anda menggunakan kernel yang lebih baru (3.15+), sepertinya Anda tidak akan melihat masalah lagi, meskipun mungkin masih ada beberapa kasus edge.

Docker versi 17.06.0-ce, build 02c1d87

Saya mencoba menghapus semua gambar, volume, jaringan, dan kontainer tetapi tidak membantu.
Juga mencoba perintah:

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

Masih ada file:

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

Bagaimana cara menghapusnya?

@ haos616 coba hentikan dulu semua container yang sedang berjalan, lalu jalankan docker system prune -af .
Ini berhasil untuk saya.
Tidak berfungsi saat saya menjalankan wadah.

Jika ini adalah peningkatan dari versi buruh pelabuhan sebelumnya, mungkin perbedaan tersebut dihasilkan / ditinggalkan oleh versi itu. Docker 17.06 tidak akan menghapus kontainer jika lapisan gagal dihapus (saat menggunakan --force); versi lama melakukannya, yang dapat menyebabkan lapisan yatim piatu

@ julian-pani Saya melakukannya di awal tetapi tidak membantu.

# 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 Tidak. Saya membersihkan Docker satu atau dua bulan yang lalu. Maka versinya sudah 17.06. Saya menggunakan perintah docker system prune -af . Itu menghapus segalanya.

Menjalankan https://github.com/spotify/docker-gc sebagai penampung berfungsi untuk saya, tetapi ini melangkah lebih jauh dan menghapus beberapa gambar yang saya butuhkan juga :(

Jadi saya sudah memasang script pembungkus kecil seperti di bawah ini agar aman

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

terima kasih sekali lagi untuk spotify

IIUC, skrip spotify memanggil docker rm dan docker rmi - apakah itu benar-benar menghapus perbedaan yatim piatu?

Hanya beberapa umpan balik untuk komunitas, saya telah membaca semua ini dan tidak ada solusi yang benar-benar berfungsi secara konsisten atau andal. "Perbaikan" saya hanyalah menggandakan jumlah ruang disk pada instans AWS saya. Dan saya tahu betul itu perbaikan yang jelek tapi ini adalah solusi terbaik yang saya temukan untuk aufs Docker yang membengkak. Ini benar-benar perlu diperbaiki.

@fuzzygroup 17.06 seharusnya tidak lagi membuat

Saya bisa membersihkan dengan skrip ini. Saya tidak melihat mengapa itu tidak berhasil, tetapi siapa yang tahu.
Bagaimanapun itu bekerja dengan baik untuk saya. Ini akan menghapus semua gambar, kontainer, dan volume ... Karena seharusnya tidak berjalan terlalu sering, saya menganggapnya sebagai efek samping kecil. Tetapi terserah Anda untuk menggunakannya atau tidak.

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

https://stackoverflow.com/q/45798076/562769 tampaknya terkait. Saya telah memposting perbaikan cepat.

FYI, masih melihat ini dengan 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 berisi banyak direktori dengan awalan -init-removing dan -removing :

ffd5477de24b0d9993724e40175185038a62250861516030a33280898243e742-removing
ffd900de0634992e99c022a16775805dfd0ffd1f6c89fece7deb6b1a71c5e38c-init-removing
ffd900de0634992e99c022a16775805dfd0ffd1f6c89fece7deb6b1a71c5e38c-removing

FYI, masih melihat ini dengan 17.06.1-ce

Masih melihat apa sebenarnya?
Seharusnya tidak ada cara bagaimana sebuah dir diff dapat bocor, meskipun dir diff akan tetap ada jika mereka ada saat pemutakhiran, mereka akan tetap ada.

Masih melihat perbedaan yatim piatu sejauh yang saya tahu. docker system prune tidak menghapusnya, begitu pula docker-gc . Menjalankan rm -rf /var/lib/docker/aufs/diff/*-removing secara manual sepertinya berhasil.

Ya, buruh pelabuhan belum akan membersihkan dirs yatim piatu.

Yang Anda maksud dengan lama yang Anda buat dari versi buruh pelabuhan sebelumnya dengan masalah ini?

Ini adalah penginstalan baru Docker yang kami lakukan sekitar dua minggu yang lalu, anak yatim piatu itu pasti sudah dibuat sejak saat itu, jadi tampaknya buruh pelabuhan masih menciptakan yatim piatu itu?

Maksud saya, dalam setengah jam terakhir saya mendapatkan 112 diff baru dengan -removing , karena saya melakukannya secara manual.

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

Anda berkata "17.06 seharusnya tidak lagi membuat perbedaan yatim piatu, tetapi belum membersihkan yang lama.", Tapi tentunya ini tidak benar, atau saya melewatkan sesuatu? Apakah mereka yang diberi tag -removing tidak yatim piatu?

@orf Pada kernel yang lebih baru, sangat tidak terduga untuk memiliki masalah apa pun selama penghapusan. Apakah Anda memasang /var/lib/docker ke dalam wadah?

Saya akan memeriksa driver aufs untuk melihat apakah ada masalah khusus di sana dengan melaporkan penghapusan yang berhasil padahal sebenarnya tidak.

Kami tidak memasang /var/lib/docker ke dalam wadah.

$ 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

Kami menjalankan 14,04 LTS

Beri tahu saya jika ada yang bisa saya berikan untuk membantu men-debug ini.

Untuk alasan lain (jaringan mode swarm) saya pindah 14.04 untuk Docker
mesin.
Pada hari Senin, 21 Agustus 2017 jam 8:23 pagi orf [email protected] menulis:

Kami tidak memasang / var / lib / buruh pelabuhan ke dalam sebuah wadah.

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

Kami menjalankan 14,04 LTS

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/moby/moby/issues/22207#issuecomment-323773033 , atau nonaktifkan
utasnya
https://github.com/notifications/unsubscribe-auth/AADRIfE2B2HNpbsKyTOj1CwGzulRT2C0ks5saaDPgaJpZM4IMGt2
.

Ini tampaknya menjadi lebih buruk dengan 17.06.01-ce. Saya memperbarui mesin build ke versi ini dan segera mulai melihat direktori *-init-removing dan *-removing tersisa sebagai bagian dari proses build. Saya menghentikan layanan, menghapus direktori /var/lib/docker , memulai ulang layanan dan setelah beberapa build hampir kehabisan ruang disk lagi. Saya menghentikan layanan lagi, menjalankan apt-get purge docker-ce , menghapus /var/lib/docker lagi dan menginstal versi 17.06.0-ce. Tidak mendapatkan direktori tambahan dalam /var/lib/docker/aufs/diff dan ruang disk mewakili gambar yang ada di mesin build. Saya telah mereproduksi perilaku pada mesin pengembangan saya juga - hanya dengan membuat gambar tampaknya membuat direktori tambahan ini untuk setiap lapisan gambar sehingga saya akan kehabisan ruang disk dengan sangat cepat. Sekali lagi, kembali ke 17.06.0-ce tampaknya tidak ada masalah, jadi saya akan tetap di sana untuk saat ini.

@mmanderson Terima kasih telah melaporkan. Perhatikan perubahan pada driver AUFS.

@mmanderson Apakah Anda memiliki kontainer di negara bagian Dead di docker ps -a ?

Semua server pembuat galangan kapal saya kehabisan ruang.

Saya telah meningkatkan dalam seminggu terakhir atau lebih ke versi Docker 17.06.1-ce, membangun 874a737. Saya yakin tidak ada lagi yang berubah dan masalah ini muncul atau terwujud sebagai bagian dari proses peningkatan. Direktori aufs diff sangat besar dan saya sudah memangkas semua gambar dan volume yang menggantung.

masalah-22207.txt
@ cpuguy83 Tidak ada kontainer di negara bagian mana pun. Inilah yang baru saja saya lakukan untuk mendemonstrasikan ini dengan 17.06.01-ce:

1. Dimulai dengan penginstalan baru buruh pelabuhan 17.06.01-ce di Ubuntu 16.04.03 LTS (mis. Buruh pelabuhan tidak diinstal dan tidak ada direktori / var / lib / buruh pelabuhan). Setelah instalasi diverifikasi direktori kosong / var / lib / docker / aufs / diff.
2. Menjalankan build buruh pelabuhan dengan file dock yang cukup sederhana berdasarkan ubuntu: terbaru - yang dilakukannya hanyalah menarik statsd_exporter dari github dan mengekstraknya ke / usr / bin (lihat file terlampir).
3. Setelah menjalankan build, jalankan docker ps -a untuk tidak menampilkan container dalam kondisi apa pun. Ada beberapa folder *-remaining di dalam folder /var/lib/docker/aufs/diff .
4. Jalankan docker system df untuk memverifikasi gambar, kontainer, dan volume. Hasilnya adalah

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. Menjalankan du -sch /var/lib/docker/*/ menunjukkan 152 juta untuk /var/lib/docker/aufs/
2. Jalankan docker rmi $(docker images -q) untuk menghapus lapisan gambar yang dibangun. Menjalankan docker system df setelah ini menunjukkan semua nol. Menjalankan du -sch /var/lib/docker/*/ menunjukkan 152 juta untuk /var/lib/docker/aufs/ dan ada *-remaining folder untuk semua folder yang tidak memilikinya sebelumnya bersama dengan folder *-remaining yang ada. masih ada.

@erikh apakah ini masalah yang Anda alami?

@ cpuguy83 Setelah menghapus instalasi 17.06.01-ce, menghapus direktori / var / lib / docker dan menginstal 17.06.0-ce, saya mencoba menjalankan build yang sama. Build gagal karena bug ADD from remote URL's yang diperbaiki pada 17.06.01. Namun saya tidak mendapatkan direktori *-remaining untuk langkah-langkah yang diselesaikan dan setelah membersihkan semuanya dengan docker system prune dan docker rmi $(docker image -q) /var/lib/docker/aufs/diff direktori

Terima kasih semuanya, ini adalah regresi di 17.06.1 ...
PR untuk diperbaiki ada di sini: https://github.com/moby/moby/pull/34587

luar biasa, terima kasih untuk patch cepatnya @ cpuguy83! / cc @erikh

@rogaha! ya, terima kasih untuk Anda dan @ cpuguy83!

Terima kasih banyak @Karreg atas naskah Anda yang

Sepertinya Docker, Inc. memiliki beberapa kontrak dengan produsen penyimpanan data komputer.

Skrip @Karreg bekerja dengan baik untuk saya dan saya membebaskan semua ruang di direktori diffs.

Mengalami masalah yang sama.
Detail Host Docker

root @ UbuntuCont : ~ # info buruh pelabuhan
Wadah: 3
Tayang: 0
Dijeda: 0
Berhenti: 3
Gambar: 4
Versi Server: 17.06.1-ce
Driver Penyimpanan: aufs
Root Dir: / var / lib / docker / aufs
Sistem File Dukungan: extfs
Sutradara: 14
Dirperm1 Didukung: true
Driver Logging: json-file
Pengemudi Cgroup: cgroupfs
Plugin:
Volume: lokal
Jaringan: jembatan tuan rumah macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: tidak aktif
Durasi: runc
Waktu Proses Default: runc
Biner Init: buruh pelabuhan-init
versi containerd: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
versi runc: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
versi init: 949e6fa
Pilihan Keamanan:
apparmor
seccomp
Profil: default
Versi Kernel: 4.4.0-93-generik
Sistem Operasi: Ubuntu 16.04.3 LTS
OSType: linux
Arsitektur: x86_64
CPU: 1
Total Memori: 3.358GiB
Nama: UbuntuCont
ID: QQA5: DC5S: C2FL: LCC6: XY6E: V3FR: TRW3: VMOQ: QQKD : AP2M: H3JA: I6VX
Docker Root Dir: / var / lib / docker
Mode Debug (klien): salah
Mode Debug (server): salah
Registri: https://index.docker.io/v1/
Eksperimental: salah
Registri Tidak Aman:
127.0.0.0/8
Live Restore Diaktifkan: false

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

@kasunsjc silahkan baca posting di atas milik Anda.

Saya mengonfirmasi bahwa peningkatan ke 17.06.2-ce memecahkan masalah ini. Saya juga tidak perlu manual direktori (terakhir kali) setelah upgrade.

17.06.2-ce _appears_ telah memperbaikinya untuk saya juga. Tidak ada lagi direktori -removing di sana, dapatkan kembali ruang yang cukup.

Saya berasumsi bahwa direktori -init saya miliki di aufs/diff tidak berhubungan (beberapa di antaranya sudah cukup lama). Mereka semua kecil, jadi itu tidak masalah.

Memperbarui ke 17.07.0 juga menyelesaikan masalah di sini, bahkan docker system prune --all -f akan menghapus direktori sebelumnya, tetapi setelah memutakhirkan, direktori tersebut dihapus otomatis saat reboot.

Mengonfirmasi masalah ini telah diselesaikan di Ubuntu 16.04 dengan 17.06.2-ce. Segera setelah diperbarui, ruang kosong.