# 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

También debería mostrar que Docker no enumera contenedores, volúmenes o imágenes:

$ 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

extraño; especialmente debido a;

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

que no coincide con la salida de docker images / docker ps .

¿En qué sistema operativo estás ejecutando?

Operating System: <unknown>

@tonistiigi ¿ alguna idea?

Eso fue después. Supongo que algunos procesos se iniciaron mientras tanto.

El estado al que me refiero (que tengo ahora) es:

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

Y todavía tengo:

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

Estamos en Ubuntu Lucid con un kernel actualizado = /

$ 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

Parece un tema interesante.
¿Es posible tener forma de reproducirlo? @bukzor

Seguro que es posible, pero no sé cómo.
Intente ejecutar el siguiente script en uno de sus hosts de Docker activos y vea lo que queda.
En nuestro caso, siempre quedan muchas diferencias.

`` #! bash

! / bin / bash

set -eu

echo "ADVERTENCIA: Esto detendrá TODOS los procesos de la ventana acoplable y eliminará TODAS las imágenes de la ventana acoplable".
read -p "¿Continuar (s / n)?"
if ["$ REPLY"! = "y"]; luego
echo "Aborting".
salida 1
fi

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

set -x

quitar contenedores

docker ps -q | parada xdocker
docker ps -aq | xdocker rm

eliminar etiquetas

imágenes de docker | sed 1d | grep -v '^'| col 1 2 | sed 's / /: /' | xdocker rmi

eliminar imágenes

imágenes de Docker -q | xdocker rmi
imágenes de Docker -aq | xdocker rmi

eliminar volúmenes

docker volume ls -q | xdocker volumen rm
''

Una posible forma en que veo que esto suceda es si hay errores en el desmontaje de aufs. Por ejemplo, si hay errores EBUSY, probablemente la configuración de la imagen ya se haya eliminado antes.

@bukzor Sería muy interesante si hubiera un reproductor que comenzara desde un directorio de gráficos vacío, extraiga / ejecute imágenes y lo ponga en un estado en el que no se limpie completamente después de ejecutar su script.

Sería interesante, pero suena a trabajo de un día completo.
No puedo comprometerme con eso.

Aquí hay más datos sobre el diff problemático (seleccionado arbitrariamente) arriba, a800 .

`` #! sh
$ docker-find 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 / layer / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579
  14 / nail / var / lib / docker / aufs / layer / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579-init
  13 / nail / var / lib / docker / aufs / layer / 993e4988c510ec3ab4f6d139740a059df40585576f8196817e573a9684554c5c
  12 / nail / var / lib / docker / aufs / layer / cf9fd1c4a64baa39b6d6d9dac048ad2fff3c3fe13924b07377e767eed230ba9f
  11 / nail / var / lib / docker / aufs / layer / 4e6afb958b5ee6dea6d1a886d19fc9c780d4ecc4baeebfbde31f9bb97732d10d
  10 / nail / var / lib / docker / aufs / layer / 23ce5a473b101d85f0e9465debe5a0f3b8a2079b99528a797b02052d06bc11d8
  9 / nail / var / lib / docker / aufs / layer / 95e68d59a8704f2bb52cc1306ca910ddb7af8956eb7c57970fcf7d8b3d9baddb
  8 / nail / var / lib / docker / aufs / layer / ac6b8ff4c0e7b91230ebf4c1caf16f06c1fdceff6111fd58f4ea50fc2dd5050b
  7 / nail / var / lib / docker / aufs / layer / fd895b6f56aedf09c48dba97931a34cea863a21175450c31b6ceadde03f7b3da
  6 / nail / var / lib / docker / aufs / layer / d5bbef5adf2efb6f15d4f96c4bee21beb955255d1ec17baf35de66e98e6c7328
  5 / nail / var / lib / docker / aufs / layer / 9646360df378b88eae6f1d6288439eebd9647d5b9e8a471840d4a9d6ed5d92a4
  4 / nail / var / lib / docker / aufs / layer / 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 / layer / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579
• sudo find / nail / var / lib / docker '(' -path '/ nail / var / lib / docker / aufs / diff / ' -o -path '/ nail / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -type f -print0
• sudo xargs -0 -P20 grep --color -l 'f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 $'
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / mount-id

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

$ docker-find eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e

• sudo find / nail / var / lib / docker '(' -path '/ nail / var / lib / docker / aufs / diff / ' -o -path '/ nail / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -print
• grep --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
  ''

¿Hay alguna forma de encontrar para qué contenedor se usó ese soporte?
El documento solo dice que el ID de montaje ya no es igual al ID del contenedor, lo cual no es muy útil.
https://docs.docker.com/engine/userguide/storagedriver/aufs-driver/

@bukzor eb809c0321 es el ID del contenedor. Lo que significa docs es que la identificación de aufs ( f3286009193f en su caso) no es una identificación de contenedor.

/ cc @dmcgowan también

@tonistiigi Está bien.

Entonces, obviamente, la montura ha sobrevivido a su contenedor.

¿En qué momento del ciclo de vida del contenedor se limpia la montura?
¿Son estas las aufs de escritura temporales para contenedores en ejecución / detenidos?

El montaje de @bukzor (rw) se elimina al eliminar el contenedor. El desmontaje ocurre cuando el proceso del contenedor se detiene. Las carpetas de diferencias son un lugar donde se almacenan los contenidos de las capas individuales, no importa si la capa está montada o no.

@bukzor El enlace entre la identificación de aufs y la identificación del contenedor se puede encontrar en image/aufs/layerdb/mounts/<container-id>/mount-id . Con tan solo saber una identificación de aufs, la forma más fácil de encontrar la identificación del contenedor es grep en el directorio image/aufs/layerdb para ella. Si no se encuentra nada, entonces la limpieza no se completó limpiamente.

Se encuentra con un problema similar.

Ejecutamos CI a diario en el servidor del demonio de la ventana acoplable. / var / lib / docker / aufs / diff requiere bastante capacidad de disco, lo que no debería ser así.

Aún 2gb en aufs/diff después de probar todo lo razonable sugerido aquí o en hilos relacionados (incluido el script bash de

A falta de una solución adecuada, ¿hay alguna forma sencilla de eliminar los soportes sobrantes sin eliminar todas las demás imágenes al mismo tiempo? (Si no hay contenedores en ejecución actualmente, supongo que no debería haber montajes, ¿verdad?)

Estoy experimentando el mismo problema. Estoy usando esta máquina para probar muchos contenedores, luego confirmar / eliminar. Mi directorio / var / lib / docker / aufs pesa actualmente 7,9G. Voy a tener que mover este directorio a otro punto de montaje, porque el almacenamiento en este es limitado. :(

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

@mcallaway Todo en aufs/diff serán escrituras fs realizadas en un contenedor.

Tengo el mismo problema. Todos los contenedores que tengo están en estado de ejecución, pero hay muchos directorios aufs diff que no se relacionan con estos contenedores y se relacionan con contenedores antiguos eliminados. Puedo eliminarlos manualmente, pero no es una opción. Debería haber una razón para tal comportamiento.

Yo uso k8s 1.3.5 y Docker 1.12.

La ejecución de docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc spotify/docker-gc ayudó.

Tengo el mismo problema. Estoy usando Gitlab CI con dind (docker in docker).

En mi humilde opinión, cuando la imagen en el registro se actualizó dentro de la misma etiqueta y se extrajo, luego se reinició el contenedor relacionado, el contenedor antiguo y la imagen no se GCed a menos que ejecute spotify/docker-gc .

puede alguien más confirmar esto?

@kayrus correcto, la docker rmi $(docker images -qa -f dangling=true) . Además, la ventana acoplable 1.13 obtendrá comandos de administración de datos (consulte https://github.com/docker/docker/pull/26108), que le permiten limpiar más fácilmente las imágenes, contenedores, etc.

@thaJeztah, ¿ /var/lib/docker/aufs/diff/ contiene realmente las imágenes "sin etiquetar"?

@kayrus sí, son parte de las imágenes (etiquetadas y no etiquetadas)

obteniendo un problema similar, sin contenedores / imágenes / volúmenes, ~ 13 Gb de diferencias

$ 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

El mismo problema aquí. Entiendo que 1.13 puede obtener comandos de administración de datos, pero mientras tanto, solo quiero eliminar de manera segura el contenido de este directorio sin matar a Docker.

Esto es relativamente bloqueante en este punto.

Aquí igual. ¿Todavía no hay una solución oficial?

Lo mencioné varias veces en (Comunidad Docker) Slack. Cada vez que un puñado de personas revisa una lista de scripts / cmds de recolección de basura, debería ejecutarla como solución.

Si bien esos han ayudado (léase: no resuelto, el espacio todavía se está acercando lentamente) en el ínterin, creo que todos podemos estar de acuerdo en que no es la solución ideal a largo plazo.

@jadametz 1.13 tiene docker system prune .
Más allá de eso, no estoy seguro de qué más puede ayudar Docker (abierto a sugerencias). Las imágenes no solo llegan al sistema por sí mismas, sino a través de extracciones, compilaciones, etc.

En términos de capas huérfanas reales (no hay imágenes en el sistema que hagan referencia a ellas), tendremos que abordar eso por separado.

¡Tengo exactamente el mismo problema!

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

Sin imágenes, contenedores ni volúmenes. 42 Gb en aufs / diff

¡Cualquier cosa que ayude a limpiar este directorio de forma segura sería muy útil! Probé todo en este hilo sin ningún éxito. Gracias.

@adamdry solo script de terceros: https://github.com/docker/docker/issues/22207#issuecomment -252560212

Gracias @kayrus De hecho lo intenté y aumentó ligeramente el uso total de mi disco y no pareció hacer nada en el directorio aufs / diff.

También probé docker system prune que no se ejecutó. Y probé docker rmi $(docker images -qa -f dangling=true) que no encontré ninguna imagen para eliminar.

Para cualquier persona interesada, ahora estoy usando esto para limpiar todos los contenedores, imágenes, volúmenes y aufs antiguos:

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

Mucha inspiración extraída de aquí: 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 Es mejor no usar -f al hacer rm / rmi, ya que ocultará errores en la eliminación.
Considero la situación actual ... donde -f oculta un error y luego nos queda un estado restante que es completamente invisible para el usuario ... como un error.

También veo esto en una instalación completamente nueva y nada sorprendente:

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 Dado que es una nueva instalación, ¿quieres probar esto? https://github.com/docker/docker/issues/22207#issuecomment -266784433

@adamdry Ya /var/lib/docker/aufs porque estaba bloqueando mi trabajo. ¿Qué espera que logren sus instrucciones? Si evitan que el problema vuelva a suceder en el futuro, puedo intentar volver a crear el problema y seguir sus instrucciones. Sin embargo, si el propósito es simplemente liberar espacio, entonces ya lo he logrado.

@robhaswell Sí, fue para liberar espacio en el disco, pero tuve problemas de seguimiento al intentar reconstruir mis imágenes, pero al seguir todos los pasos en ese script resolvió esos problemas.

Durante la compilación, si el proceso de compilación se interrumpe durante el proceso de compilación de la capa (que también contiene un blob para copiar), seguido de detener el contenedor, deja datos en / var / lib / docker / aufs / diff /. Apareció una imagen colgando. Limpiarlo tampoco liberó el espacio. ¿Es posible incluirlo como parte de la poda del sistema Docker? Solo eliminar los datos de blobs dentro de esta carpeta libera espacio, lo que no estoy seguro de que cause algún problema o no.

Versión de Docker: 1.13.0-rc1

Durante la compilación, si el proceso de compilación se interrumpe durante el proceso de compilación de la capa (que también contiene un blob para copiar), seguido de detener el contenedor, deja datos

Esta también podría ser la causa de mis problemas: interrumpo muchas compilaciones.

Durante la extracción de la ventana acoplable, se observaron los siguientes dos casos:

1. si el proceso se interrumpe cuando dice descargar (que descarga la capa de imagen en / var / lib / docker / tmp /), limpia todos los datos en esa carpeta
2. Si el proceso se interrumpe cuando dice extraer (lo que supongo que es extraer la capa de tmp a / var / lib / docker / aufs / diff /), limpia los datos tmp y diff blob ambos.

Durante el proceso de construcción de la imagen,

1. Al interrumpir el proceso al "Enviar contexto de compilación al demonio de la ventana acoplable" (que copia los datos de blob en mi caso en / var / lib / docker / tmp /), permanece allí para siempre y no se puede limpiar con ningún comando, excepto eliminarlo manualmente. No estoy seguro de cómo se manejan las actualizaciones de apt get en la imagen.
2. Mientras se construye la capa que contiene datos de blob, digamos una configuración de software grande, si el proceso se interrumpe, el contenedor de la ventana acoplable sigue trabajando en la imagen. En mi caso, solo los datos de blob de 1 capa, que ya están disponibles en la carpeta tmp, componen la imagen completa. Pero, si el contenedor se detiene usando el comando docker stop, ocurren dos casos:
   una. si el proceso de montaje aún está sucediendo, dejará datos en la carpeta tmp y diff.
   B. Si los datos se copiaron en la carpeta diff, eliminará los datos de la carpeta tmp y dejará los datos en la carpeta diff y tal vez en la carpeta de montaje.

Tenemos un proceso de compilación automatizado, que necesita un control para detener cualquier proceso de compilación correctamente. Recientemente, un proceso fue eliminado por el kernel debido a un error de falta de memoria en una máquina que tenía una configuración baja.

Si se va a construir una imagen de 2 capas, se construye 1 capa y se interrumpe la segunda, la eliminación del sistema Docker parece limpiar los datos del contenedor de la capa que se interrumpió y el contenedor se detuvo. Pero no limpia los datos de las capas anteriores en caso de interrupción. Además, no reflejaba el espacio total en disco reclamado. Ejecuté estas pruebas en AWS, ubuntu 14.04, sistema x86_64 bit con sistema de archivos aufs. Ejecutó la prueba de paso de Docker con Docker 1.13.0 rc3 y Docker 1.12

@thaJeztah
Por favor, avíseme si estoy malinterpretando algo.

Abrí un problema para los archivos /var/lib/docker/tmp que no se estaban limpiando; https://github.com/docker/docker/issues/29486

La poda del sistema Docker parece limpiar los datos del contenedor de la capa que se interrumpió y el contenedor se detuvo. Pero no limpia los datos de las capas anteriores en caso de interrupción.

Traté de reproducir esa situación, pero no pude ver eso con un caso simple;

Comience con una instalación limpia y vacía /var/lib/docker , cree un archivo grande para
testing y un Dockerfile;

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

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

comenzar docker build , y cancelar mientras se construye, pero _después_ de la construcción
se ha enviado el contexto;

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

comprobar el contenido de /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/

ejecute el comando docker system prune para limpiar imágenes, contenedores;

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

comprobar el contenido de /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/

Veo que la montura -init se queda atrás, comprobaré si podemos resolver
eso (aunque es solo un directorio vacío)

La única diferencia en el dockerfile que había usado era (para crear diferentes capas)
DESDE cero
COPIA ["./bigfile", "randomNoFile1", /]
COPIA ["./bigfile", "randomNoFile2", /]
EOF

No estoy seguro de si hace alguna diferencia.

No, el problema no son las carpetas de inicio vacías. En mi caso, fue te blob. Sin embargo, puedo volver a comprobarlo el lunes y actualizarlo.

Además, estaba usando un archivo de 5GB, lo creó leyendo bytes de dev urandom.
En su caso, el mismo archivo se agrega 2 veces. ¿Eso crearía una sola capa y montaría la segunda capa a partir de ella o serían 2 capas separadas? En mi caso, siempre son 2 capas separadas.

@thaJeztah
Gracias por una respuesta tan rápida al problema. ¡La adición de esta función sería de gran ayuda!

@ monikakatiyar16 Intenté reproducir esto también cancelando la compilación varias veces durante los comandos ADD y RUN pero no pude conseguir que nada se filtrara a aufs/diff después de la eliminación. No pude entender qué contenedor está deteniendo porque los contenedores no deberían estar ejecutándose durante las operaciones ADD/COPY . Si puede armar un reproductor que podamos ejecutar, sería muy apreciado.

Es posible que esté haciendo algo mal. Como estoy viajando el fin de semana, lo reproduciré y actualizaré toda la información requerida aquí el lunes.

@tonistiigi @thaJeztah
Siento que tienes razón. En realidad, no hay contenedores que estén listados como activos y en ejecución. En cambio, hay contenedores muertos. La poda del sistema Docker no funcionó en mi caso, podría ser porque el proceso no se mató con Ctrl + C. En cambio, siguió funcionando en segundo plano. En mi caso, esa sería la razón por la que no pudo eliminar esas manchas.

Cuando interrumpo el proceso usando Ctrl + C, el proceso de compilación se mata, pero un proceso para docker-untar permanece vivo en segundo plano, que sigue trabajando en la construcción de la imagen. (Nota: / var / lib / docker tiene un vínculo suave con / home / lib / docker para usar los volúmenes de EBS para datos grandes en AWS)

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

Adjunté el script que había estado usando para crear archivos grandes y construir la imagen (gc_maxpush_pull.sh)

También adjunto el comportamiento del proceso de construcción para construir una imagen, interrumpiéndola con Ctrl + C (DockerBuild_WOProcessKill) y construyendo la imagen, interrumpiéndola con Ctrl + C, matando el proceso (DockerBuild_WithProcessKill)

Usando los comandos -

Para crear un archivo grande: ./gc_maxpush_pull.sh 1 5gblayer 0 512 1

Para construir imágenes: ./gc_maxpush_pull.sh 1 5gblayer 1 512 1

DockerBuild.zip

Pasos para replicar:

1. Crea un archivo grande de 5GB
2. Inicie el proceso de compilación e interrumpa solo después de que haya finalizado el envío del contexto de compilación y se esté copiando el blob.
3. Completa la construcción de la imagen después de un tiempo y la muestra en las imágenes de la ventana acoplable (como en el caso 1 adjunto por mí - DockerBuild_WOProcessKill)
4. Si se mata el proceso, toma un tiempo y deja los datos de blob en / diff (que debería al finalizar el proceso abruptamente como se adjunta en el archivo - DockerBuild_WithProcessKill)

Si lo que estoy asumiendo es correcto, entonces esto podría no ser un problema con la poda de la ventana acoplable, sino con la eliminación de la compilación de la ventana acoplable que de alguna manera no me funciona.

¿Existe una forma elegante de interrumpir o detener el proceso de creación de la imagen, que también se encarga de limpiar los datos copiados (como se maneja en Docker Pull)?

Anteriormente, no estaba matando el proceso. También tengo curiosidad por saber qué hace docker-untar y por qué lo monta en las carpetas / mnt y / diff y luego limpia la carpeta / mnt.

Probé esto con la versión 1.12.5 de Docker, compilación 7392c3b en AWS

información de la ventana acoplable
Contenedores: 2
En ejecución: 0
En pausa: 0
Detenido: 2
Imágenes: 0
Versión del servidor: 1.12.5
Controlador de almacenamiento: aufs
Directorio raíz: / home / lib / docker / aufs
Sistema de archivos de respaldo: extfs
Dirs: 4
Dirperm1 admitido: falso
Controlador de registro: archivo json
Controlador de Cgroup: cgroupfs
Complementos:
Volumen: local
Red: host nulo de puente de superposición
Enjambre: inactivo
Tiempos de ejecución: runc
Tiempo de ejecución predeterminado: runc
Opciones de seguridad: apparmor
Versión de Kernel: 3.13.0-105-generic
Sistema operativo: Ubuntu 14.04.4 LTS
OSType: linux
Arquitectura: x86_64
CPU: 2
Memoria total: 3.859 GiB
Nombre: maestro
ID: 2 NQU: D2C5 : 5 WPL: IIDR : P6FO: OAG7: GHW6: ZJMQ: VDHI : B5CI: XFZJ: ZSZM
Directorio raíz de Docker: / home / lib / docker
Modo de depuración (cliente): falso
Modo de depuración (servidor): falso
Registro: https://index.docker.io/v1/
ADVERTENCIA: Sin soporte de límite de intercambio
Registros inseguros:
127.0.0.0/8

@ monikakatiyar16 Cuando untar durante la compilación, obtengo Error processing tar file(signal: killed): en la salida de la compilación. Dejar atrás el contenedor en docker ps -a es el comportamiento correcto, lo mismo sucede en cualquier error de compilación y le permite depurar los problemas que causaron que la compilación fallara. Sin embargo, no tengo ningún problema para eliminar este contenedor y, si lo hago, todos los datos en /var/lib/docker/aufs se limpian.

@tonistiigi Sí, tienes razón. Pude eliminar el volumen asociado con el contenedor y limpió todo, después de matar el proceso docker-untar. La poda del sistema Docker también funciona en este caso.

El problema real que dejó los volúmenes fue el caso, cuando sin matar el proceso docker-untar, intenté eliminar el contenedor de la ventana acoplable junto con los volúmenes, lo que dio el siguiente error:

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

Registros de demonios:

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

Parece que el orden a seguir en este momento para interrumpir una compilación de Docker es:
Interrupt docker build > Kill docker untar process > remove container and volume : docker rm -v -f $(docker ps -a -q)

Por docker v1.13.0-rc4 , puede ser Interrupt docker build > Kill docker untar process > docker system prune -a

Esto parece funcionar perfectamente. No hay problemas de limpieza, en cambio, el único problema es que el proceso docker-untar no se mata junto con el proceso de construcción de la ventana acoplable.

Buscaré / actualizaré / registraré un nuevo problema para una interrupción elegante de la compilación de la ventana acoplable que también detiene el proceso de la ventana acoplable-untar junto con él.

(Verificado esto con docker v1.12.5 y v1.13.0-rc4)

Actualización: al matar docker-untar mientras se envía el contexto de compilación al demonio de la ventana acoplable, da un error en la compilación: Error response from daemon: Error processing tar file(signal: terminated) , pero durante la copia de capa no lo hace (para mí)

¡Gracias por ser tan paciente y por darnos tu tiempo!

Veo que /var/lib/docker/aufs aumenta constantemente de tamaño en un trabajador en modo enjambre de Docker. Esta cosa es en su mayoría autónoma siendo administrada por el administrador de enjambres y muy poca creación manual de contenedores, aparte de algunos comandos de mantenimiento aquí y allá.

Ejecuto docker exec en contenedores de servicio; No estoy seguro si eso puede ser una causa.

Mi solución para resolver esto en mi caso fue iniciar otro trabajador, configurar el nodo completo en --availability=drain y mover manualmente un par de montajes de volumen.

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

Esto ha afectado a nuestro servidor de CI durante años. Esto necesita ser arreglado.

@orf gracias

El mismo problema aquí. Ni el contenedor, ni los volúmenes ni la eliminación de imágenes, ni los comandos de limpieza de Docker 1.13 tienen ningún efecto.

También confirmo que hice algunas cancelaciones de creación de imágenes. Tal vez eso deje carpetas que tampoco se puedan acceder.
Usaré el viejo método rm por ahora, pero esto es claramente un error.

Los archivos en / var / lib / docker / aufs / diff ocupan el 100% del espacio para el sistema de archivos / dev / sda1 de 30G

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

Tamaño del sistema de archivos utilizado% de uso disponible montado en
udev 14G 0 14G 0% / dev
tmpfs 2.8G 273M 2.5G 10% / ejecución
/ dev / sda1 29G 29G 0100% /
tmpfs 14G 0 14G 0% / dev / shm
tmpfs 5.0M 0 5.0M 0% / ejecutar / bloquear
tmpfs 14G 0 14G 0% / sys / fs / cgroup
/ dev / sdb1 197G 60M 187G 1% / mnt
tmpfs 2.8G 0 2.8G 0% / ejecutar / usuario / 1000

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

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

También probé, poda del sistema docker , que no ayudó.

¿Alguien ha encontrado una solución para este problema continuo de archivos supergrandes en diff antes de que este error se solucione en el código?

Sí, el método ya se ha proporcionado, pero aquí hay un fragmento de apocalipsis que simplemente destruye todo lo que puse aquí en el trabajo (excepto las carpetas locales para los volúmenes). Para poner bashrc u otro archivo de configuración de bash.

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

func_full-cleanup-docker () {

echo "ADVERTENCIA: Esto eliminará todo de la ventana acoplable: volúmenes, contenedores e imágenes. ¿Te atreverás? [s / N]"
leer elección

if [("$ elección" == "y") -o ("$ elección" == "Y")]
luego
sudo echo "> verificación de derechos de sudo [OK]"
tamañoa = 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
} `` `

Ejecuté el comando rm -rf para eliminar los archivos de la carpeta diff por ahora. Probablemente tendrá que buscar en el script si la carpeta diff ocupa de nuevo todo el espacio del disco.
Espero ver este problema solucionado en el código, en lugar de soluciones alternativas.

Hola, tengo el mismo problema en la ventana acoplable 1.10.2, estoy ejecutando kubernetes. esta es mi versión de 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

Estoy tratando de rastrear todo el directorio diff no utilizado en /var/lib/docker/aufs/diff y /var/lib/docker/aufs/mnt/ analizando los archivos de capa en /var/lib/docker/image/aufs/imagedb , aquí está el script que utilicé:

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

Pero encontré un problema cuando detengo y reinicio el demonio de la ventana acoplable, parece que hago un estado inconsistente de la ventana acoplable:

/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

y cuando trato de crear nuevos contenedores por docker run , falló con el mensaje:

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

y el registro del demonio muestra:

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

¿Alguien sabe si mi enfoque es correcto o no? y ¿por qué ocurre el problema después de eliminar esas carpetas?

Abrí # 31012 para al menos asegurarme de que no filtremos estos directorios en ninguna circunstancia.
Por supuesto, también debemos analizar las diversas causas de los errores busy

Esto me estaba mordiendo desde que tengo memoria. Obtuve prácticamente los mismos resultados que los descritos anteriormente cuando cambié al controlador overlay2 hace algunos días y destruí la carpeta aufs por completo ( docker system df dice 1.5Gigs, df dice 15Gigs) .

Tenía alrededor de 1T de diferencias usando almacenamiento. Después de reiniciar mi demonio de la ventana acoplable, recuperé alrededor de 700 GB. Así que supongo que parando al demonio, ¿estas ciruelas?

Reiniciar no hace nada por mí, desafortunadamente.

El reinicio del servicio no ayudó. Este es un problema grave. Eliminar todos los contenedores / imágenes no elimina esas diferencias.

Detener el demonio no los eliminaría.

Si elimina todos los contenedores y todavía tiene diff dirs, es probable que tenga algunas capas rw filtradas.

Acabamos de encontrar este problema. /var/lib/docker/aufs/diff tomó 28G y llevó nuestro sistema de archivos raíz al 100%, lo que provocó que nuestro servidor GitLab dejara de responder. Estamos usando Docker para GitLab CI. Para solucionar este problema, utilicé algunos de los comandos que @sogetimaitral sugirió anteriormente para eliminar los archivos temporales, y volvemos a estar en funcionamiento. Reinicié el servidor y envié una nueva confirmación para activar CI, y todo parece estar funcionando como debería.

Definitivamente me preocupa que esto vuelva a suceder. ¿Cuál es el trato aquí? ¿Es este un error de la ventana acoplable que debe corregirse?

1. Sí, hay un error (tanto que hay problemas en la eliminación como que --force on rm ignora estos problemas)
2. Por lo general, no se debe escribir una gran cantidad de datos en el contenedor fs y, en su lugar, se debe utilizar un volumen (incluso un volumen desechable). Un directorio de diferencias grande indicaría que se están escribiendo cantidades significativas de datos en el contenedor fs.

Si no usa "--force" en la eliminación, no se encontrará con este problema (o al menos verá que tiene un montón de contenedores "muertos" y sabe cómo / qué limpiar).

No estoy usando manualmente Docker en absoluto. Estamos usando gitlab-ci-multi-runner . Entonces, ¿podría ser un error al final de GitLab?

Parece (por defecto) que fuerza la eliminación de contenedores; https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/dbdbce2848530df299836768c8ea01e209a2fe40/executors/docker/executor_docker.go#L878. Si lo hace, puede provocar que se ignoren las fallas en la eliminación del contenedor y que se produzcan diferencias huérfanas.

Ok, eso me dice que se trata de un error de gitlab-ci-multi-runner. ¿Es esa una interpretación correcta? Me complace crear un problema para que lo solucionen.

Supongo que es una combinación; "force" remove facilita el manejo de las limpiezas (es decir, casos en los que un contenedor aún no se ha detenido, etc.), al mismo tiempo (ese es el "error" mencionado por @ cpuguy83 ), también puede ocultar problemas reales, como Docker no pudo eliminar el sistema de archivos de contenedores (lo cual puede tener varias razones). Con "fuerza", el contenedor se retira en tales casos. Sin, el contenedor se deja alrededor (pero marcado como "muerto")

Si el corredor de gitlab puede funcionar correctamente sin la eliminación forzada, probablemente sea bueno cambiarlo (o hacerlo configurable)

Estoy usando Drone y tengo el mismo problema. No verifiqué el código de cómo se eliminan los contenedores, pero supongo que también fuerza las eliminaciones.

¿Podría ser un problema de Docker en Docker? Estoy iniciando Drone con docker-compose.

Decidí seguir adelante y enviar un problema de gitlab-ci-multi-runner solo para incluir a los desarrolladores: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

Honestamente, solucionamos esto ejecutando el docker gc de Spotify con drone CI.

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

Decidí seguir adelante y enviar un problema de gitlab-ci-multi-runner solo para
bucle los desarrolladores en:
https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/docker/issues/22207#issuecomment-289926298 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AC6Wz197zkjWWOlq1-JOibiQP-xJym9Eks5rqYvegaJpZM4IMGt2
.

@sedouard ¡ Gracias por este consejo! Ejecutar docker-gc cada hora desde spotify me resolvió el problema.

Estamos consiguiendo que este problema se ejecute desde Gitlab CI (no se ejecuta en la ventana acoplable), utilizando comandos para crear imágenes / ejecutar contenedores (no la integración de Gitlab CI Docker). No estamos ejecutando ningún tipo de remoción forzada, simplemente docker run --rm ... y docker rmi image:tag

EDITAR : lo siento, en realidad el problema original es el mismo. La diferencia es que ejecutar spotify/docker-gc _no_ soluciona el problema.

Como puede ver a continuación, tengo 0 imágenes, 0 contenedores, ¡nada!
docker system info está Dirs: 38 para el almacenamiento de aufs.

¡Eso es sospechoso! Si observa /var/lib/docker/aufs/diff/ , vemos que en realidad hay 1,7 GB de datos allí, más de 41 directorios. Y esa es mi caja personal, en el servidor de producción son 19 GB.

¿Cómo limpiamos esto? el uso de spotify/docker-gc no los elimina.

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

¿Puedo rm -r /var/lib/docker/aufs seguridad y reiniciar el docker deamon?

Ejecutar spotify/docker-gc no limpia a esos huérfanos.

EDITAR : ¡gracias @CVTJNII!

Detener el demonio de Docker y borrar todo / var / lib / docker será más seguro. Borrar / var / lib / docker / aufs hará que pierdas tus imágenes de todos modos, por lo que es mejor comenzar con un / var / lib / docker limpio en mi opinión. Esta es la "solución" que he estado usando durante varios meses para este problema.

A partir de 17.06 ya no debería haber nuevos diffs huérfanos.
En su lugar, puede comenzar a ver contenedores con el estado Dead , esto sucede si hubo un error durante la eliminación que no es recuperable y puede requerir que un administrador lo solucione.

Además, la extracción es un poco más sólida y menos propensa a errores debido a condiciones de carrera o desmontajes fallidos.

@ cpuguy83 : buenas noticias, ¿puede explicar qué tendría que hacer el administrador si eso sucediera?

@Silex Depende de la causa.
Normalmente, lo que ha sucedido es que hay un error device or resource busy debido a que se filtró una montura en un contenedor. Si está ejecutando algo como ca 0000-, esto es prácticamente una garantía, ya que las instrucciones dicen que debe montar todo el directorio de la ventana acoplable en el contenedor ca went.

Esto puede ser complicado, es posible que deba detener los contenedores infractores y luego eliminar el contenedor dead .

Si está en un kernel más nuevo (3.15+), es poco probable que vuelva a ver el problema, aunque todavía puede haber algunos casos extremos.

Docker, versión 17.06.0-ce, compilación 02c1d87

Intenté eliminar todas las imágenes, volúmenes, redes y contenedores, pero no ayudó.
También probé comandos:

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

Aún quedan archivos:

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

¿Cómo se puede eliminar?

@ haos616 primero intente detener todos los contenedores en ejecución y luego ejecute docker system prune -af .
Esto funcionó para mí.
No funcionó mientras tenía un contenedor en funcionamiento.

Si se trata de una actualización de una versión anterior de la ventana acoplable, es posible que esas diferencias hayan sido generadas / dejadas por esa versión. Docker 17.06 no eliminará un contenedor si las capas no se pudieron eliminar (cuando se usa --force); las versiones anteriores lo hacían, lo que podría llevar a capas huérfanas

@ julian-pani Lo hice al principio pero no ayuda.

# 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 No. Limpié el Docker hace uno o dos meses. Entonces la versión ya era la 17.06. Usé el comando docker system prune -af . Eliminó todo.

Ejecutar https://github.com/spotify/docker-gc como contenedor funcionó para mí, pero fue un paso más y eliminó algunas de mis imágenes requeridas también :(

Así que puse un pequeño script de envoltura como se muestra a continuación para estar seguro

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

gracias de nuevo por Spotify

IIUC, el script de Spotify solo llama a docker rm y docker rmi - ¿realmente eliminó las diferencias huérfanas?

Solo algunos comentarios para la comunidad, he leído todo esto y ninguna de las soluciones parece funcionar de manera consistente o confiable. Mi "solución" fue simplemente duplicar la cantidad de espacio en disco en mis instancias de AWS. Y sé muy bien que es una mala solución, pero es la mejor solución que he encontrado para los aufs hinchados de Docker. Esto realmente, realmente necesita ser arreglado.

@fuzzygroup 17.06 ya no debería crear diferencias huérfanas, pero aún no limpiará las antiguas.

Podría limpiar con este script. No veo por qué no funcionaría, pero quién sabe.
De todos modos, está funcionando bien para mí. Eliminará todas las imágenes, contenedores y volúmenes ... Como no debería ejecutarse con mucha frecuencia, lo encuentro un efecto secundario menor. Pero depende de ti usarlo o no.

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

https://stackoverflow.com/q/45798076/562769 parece estar relacionado. Publiqué una solución rápida.

FYI, sigo viendo esto con 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 contiene muchos directorios con el prefijo -init-removing y -removing :

ffd5477de24b0d9993724e40175185038a62250861516030a33280898243e742-removing
ffd900de0634992e99c022a16775805dfd0ffd1f6c89fece7deb6b1a71c5e38c-init-removing
ffd900de0634992e99c022a16775805dfd0ffd1f6c89fece7deb6b1a71c5e38c-removing

Para su información, sigo viendo esto con 17.06.1-ce

¿Sigues viendo qué, exactamente?
No debería haber ninguna forma de que un directorio diff pueda filtrarse, aunque los directorios diff seguirán existiendo si existieron en la actualización, seguirán existiendo.

Todavía veo diferencias huérfanas por lo que puedo decir. docker system prune no los eliminó, ni docker-gc . La ejecución manual de rm -rf /var/lib/docker/aufs/diff/*-removing parece estar funcionando.

Sí, Docker todavía no limpiará los directorios antiguos huérfanos.

¿Por antiguo te refieres a los creados a partir de una versión anterior de Docker con este problema?

Esta es una nueva instalación de Docker que hicimos hace unas dos semanas, esos huérfanos deben haberse creado desde entonces, por lo que parece que Docker todavía debe estar creando esos huérfanos.

Quiero decir, en la última media hora obtuve 112 nuevas diferencias con -removing , ya que las hice manualmente.

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

Dijiste "17.06 ya no debería crear diferencias huérfanas, pero todavía no limpiará las antiguas", pero seguramente esto no puede ser correcto, ¿o me estoy perdiendo algo? ¿Los etiquetados con -removing no son huérfanos?

@orf En un kernel más nuevo, es muy inesperado tener algún problema durante la eliminación. ¿Está montando /var/lib/docker en un contenedor?

Verificaré el controlador aufs para ver si hay un problema específico allí con el informe de una eliminación exitosa cuando en realidad no lo fue.

No estamos montando /var/lib/docker en un contenedor.

$ 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

Estamos ejecutando 14.04 LTS

Avíseme si hay algo que pueda proporcionar para ayudar a depurar esto.

Por otras razones (redes en modo enjambre) me mudé de 14.04 para Docker
máquinas.
El lunes 21 de agosto de 2017 a las 8:23 a. M. Orf [email protected] escribió:

No estamos montando / var / lib / docker en un contenedor.

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

Estamos ejecutando 14.04 LTS

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/moby/moby/issues/22207#issuecomment-323773033 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AADRIfE2B2HNpbsKyTOj1CwGzulRT2C0ks5saaDPgaJpZM4IMGt2
.

Esto parece ser peor con 17.06.01-ce. Actualicé una máquina de compilación a esta versión e inmediatamente comencé a ver los directorios *-init-removing y *-removing quedaban como parte del proceso de compilación. Detuve el servicio, eliminé el directorio /var/lib/docker , reinicié el servicio y después de algunas compilaciones estaba casi sin espacio en disco nuevamente. Detuve el servicio nuevamente, ejecuté apt-get purge docker-ce , eliminé /var/lib/docker nuevamente e instalé la versión 17.06.0-ce. No obtener los directorios adicionales en /var/lib/docker/aufs/diff y el espacio en disco es representativo de las imágenes que están en la máquina de compilación. También he reproducido el comportamiento en mi máquina de desarrollo: el simple hecho de crear una imagen parece crear estos directorios adicionales para cada capa de la imagen, por lo que me quedaría sin espacio en disco muy rápido. Nuevamente, volver a 17.06.0-ce parece no tener el problema, así que me quedaré allí por ahora.

@mmanderson Gracias por informar. Echando un vistazo a los cambios en el controlador AUFS.

@mmanderson ¿Tiene contenedores en el estado Dead en docker ps -a ?

Todos mis servidores de compilación de Docker se están quedando sin espacio.

Me actualicé en la última semana a la versión 17.06.1-ce de Docker, compilación 874a737. Creo que nada más ha cambiado y que este problema surgió o se manifestó como parte del proceso de actualización. El directorio aufs diff es enorme y ya eliminé todas las imágenes y volúmenes colgantes.

número-22207.txt
@ cpuguy83 No hay contenedores en ningún estado. Esto es lo que apenas hice para demostrar esto con 17.06.01-ce:

1. Comenzó con una nueva instalación de docker 17.06.01-ce en Ubuntu 16.04.03 LTS (es decir, docker no está instalado y no hay directorio / var / lib / docker). Después de la instalación, se verificó un directorio / var / lib / docker / aufs / diff vacío.
2. Ejecuté una compilación de docker con un dockerfile bastante simple basado en ubuntu: latest ; todo lo que hace es extraer statsd_exporter de github y extraerlo en / usr / bin (ver archivo adjunto).
3. Después de ejecutar la compilación, ejecute docker ps -a para no mostrar contenedores en ningún estado. Hay varias carpetas *-remaining en la carpeta /var/lib/docker/aufs/diff .
4. Ejecute docker system df para verificar imágenes, contenedores y volúmenes. El resultado es

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. Ejecutando du -sch /var/lib/docker/*/ muestra 152M por /var/lib/docker/aufs/
2. Ejecute docker rmi $(docker images -q) para eliminar las capas de imagen creadas. Ejecutar docker system df después de esto muestra todos los ceros. Ejecutar du -sch /var/lib/docker/*/ muestra 152M por /var/lib/docker/aufs/ y hay *-remaining carpetas para todas las carpetas que no las tenían antes junto con las carpetas *-remaining que todavía están ahí.

@erikh, ¿ es este el problema que está experimentando?

@ cpuguy83 Después de desinstalar 17.06.01-ce, eliminar el directorio / var / lib / docker e instalar 17.06.0-ce, trato de ejecutar la misma compilación. La compilación falla debido al error ADD from remote URL's que se corrigió en 17.06.01. Sin embargo, no obtengo ningún directorio *-remaining para los pasos que se completan y después de limpiar todo con docker system prune y docker rmi $(docker image -q) el directorio /var/lib/docker/aufs/diff vuelve a estar vacío y el espacio se libera.

Gracias a todos, esta es una regresión en 17.06.1 ...
PR para arreglar está aquí: https://github.com/moby/moby/pull/34587

genial, gracias por el parche rápido @ cpuguy83! / cc @erikh

@rogaha! sí, ¡gracias a ti y a @ cpuguy83!

Muchas gracias @Karreg por tu excelente guión . Después de deshacernos de todos los viejos diffs ophaned y volver a liberar enormes cantidades de espacio perdido en el disco, ahora lo estamos usando regularmente para limpiar nuestras VM antes de instalar nuevas imágenes de docker. Gran ayuda y una solución casi perfecta para este problema ahora. @ TP75

Parece que Docker, Inc. tiene algunos contratos con fabricantes de almacenamiento de datos informáticos.

El script de @Karreg funcionó bien para mí y liberé todo el espacio en el directorio diffs.

Tener el mismo problema.
Detalles del host de Docker

root @ UbuntuCont : ~ # información de la
Contenedores: 3
En ejecución: 0
En pausa: 0
Detenido: 3
Imágenes: 4
Versión del servidor: 17.06.1-ce
Controlador de almacenamiento: aufs
Directorio raíz: / var / lib / docker / aufs
Sistema de archivos de respaldo: extfs
Dirs: 14
Dirperm1 admitido: verdadero
Controlador de registro: archivo json
Controlador de Cgroup: cgroupfs
Complementos:
Volumen: local
Red: superposición nula de macvlan del host del puente
Registro: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Enjambre: inactivo
Tiempos de ejecución: runc
Tiempo de ejecución predeterminado: runc
Init Binary: docker-init
versión en contenedor: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
versión runc: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
versión init: 949e6fa
Opciones de seguridad:
aparición
seccomp
Perfil: predeterminado
Versión de Kernel: 4.4.0-93-generic
Sistema operativo: Ubuntu 16.04.3 LTS
OSType: linux
Arquitectura: x86_64
CPU: 1
Memoria total: 3.358GiB
Nombre: UbuntuCont
ID: QQA5: DC5S: C2FL: LCC6: XY6E: V3FR: TRW3: VMOQ : QQKD: AP2M: H3JA: I6VX
Directorio raíz de Docker: / var / lib / docker
Modo de depuración (cliente): falso
Modo de depuración (servidor): falso
Registro: https://index.docker.io/v1/
Experimental: falso
Registros inseguros:
127.0.0.0/8
Live Restore habilitado: falso

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

@kasunsjc, por favor lea las publicaciones justo encima de la suya.

Confirmo que la actualización a 17.06.2-ce resolvió este problema. Tampoco tuve que hacer manualmente los directorios (la última vez) después de la actualización.

17.06.2-ce _ parece haber arreglado esto para mí también. No más directorios -removing allí, recuperé una cantidad decente de espacio.

Supongo que los directorios -init que tengo en aufs/diff no están relacionados (algunos de ellos son bastante antiguos). Sin embargo, todos son pequeños, por lo que poco importa.

La actualización a 17.07.0 resolvió el problema aquí también, ni siquiera docker system prune --all -f eliminaría los directorios antes, pero después de la actualización se eliminaron automáticamente al reiniciar.

Confirmar que este problema se resolvió en Ubuntu 16.04 con 17.06.2-ce. Tan pronto como se actualizó, el espacio se despejó.