# 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

Devo também mostrar que o docker não lista contêineres, volumes ou imagens:

$ 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

estranho; especialmente por causa de;

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

que não corresponde à saída de docker images / docker ps .

Em qual sistema operacional você está executando?

Operating System: <unknown>

@tonistiigi alguma ideia?

Isso foi depois. Acho que alguns processos foram iniciados nesse ínterim.

O estado ao qual estou me referindo (eu tenho agora) é:

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

E eu ainda tenho:

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

Estamos no Ubuntu Lucid com um kernel atualizado = /

$ 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 um assunto interessante.
é possível ter maneira de reproduzi-lo? @bukzor

Certamente é possível, mas não sei como.
Tente executar o script abaixo em um de seus hosts docker ativos e veja o que resta.
Em nosso caso, sempre há muitas diferenças deixadas para trás.

`` `#! bash

! / bin / bash

set -eu

echo "AVISO :: Isso interromperá TODOS os processos do docker e removerá TODAS as imagens do docker."
leia -p "Continuar (s / n)?"
if ["$ REPLY"! = "y"]; então
echo "Abortando".
saída 1
fi

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

set -x

remover recipientes

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

remover tags

imagens do docker | sed 1d | grep -v '^'| col 1 2 | sed 's / /: /' | xdocker rmi

remover imagens

imagens do docker -q | xdocker rmi
imagens do docker -aq | xdocker rmi

remover volumes

volume do docker ls -q | volume xdocker rm
`` `

Uma forma possível de ver isso acontecendo é se houver erros na desmontagem do aufs. Por exemplo, se houver erros EBUSY, provavelmente a configuração da imagem já foi excluída antes.

@bukzor Seria muito interessante se houvesse um reprodutor que começasse a partir de um diretório de gráfico vazio, puxasse / executasse imagens e as

Isso seria interessante, mas parece um dia inteiro de trabalho.
Eu não posso me comprometer com isso.

Aqui estão mais alguns dados sobre o diff problemático (selecionado arbitrariamente) acima, 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 / layers / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579
  14 / nail / var / lib / docker / aufs / layers / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579-init
  13 / nail / var / lib / docker / aufs / layers / 993e4988c510ec3ab4f6d139740a059df40585576f8196817e573a9684554c5c
  12 / nail / var / lib / docker / aufs / layers / cf9fd1c4a64baa39b6d6d9dac048ad2fff3c3fe13924b07377e767eed230ba9f
  11 / nail / var / lib / docker / aufs / layers / 4e6afb958b5ee6dea6d1a886d19fc9c780d4ecc4baeebfbde31f9bb97732d10d
  10 / nail / var / lib / docker / aufs / layers / 23ce5a473b101d85f0e9465debe5a0f3b8a2079b99528a797b02052d06bc11d8
  9 / nail / var / lib / docker / aufs / layers / 95e68d59a8704f2bb52cc1306ca910ddb7af8956eb7c57970fcf7d8b3d9baddb
  8 / nail / var / lib / docker / aufs / layers / ac6b8ff4c0e7b91230ebf4c1caf16f06c1fdceff6111fd58f4ea50fc2dd5050b
  7 / nail / var / lib / docker / aufs / layers / fd895b6f56aedf09c48dba97931a34cea863a21175450c31b6ceadde03f7b3da
  6 / nail / var / lib / docker / aufs / layers / d5bbef5adf2efb6f15d4f96c4bee21beb955255d1ec17baf35de66e98e6c7328
  5 / nail / var / lib / docker / aufs / layers / 9646360df378b88eae6f1d6288439eebd9647d5b9e8a471840d4a9d6ed5d92a4
  4 / nail / var / lib / docker / aufs / layers / a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
  0 / nail / var / lib / docker / image / aufs / layerdb / sha256 / d1c659b8e3d0e893e95c8eedc755adcb91a1c2022e1090376b451f7206f9b1c0 / cache-id

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

$ docker-find f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 '$'

• sudo find / nail / var / lib / docker '(' -path '/ nail / var / lib / docker / aufs / diff / ' -o -path '/ nail / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -print
• grep --color 'f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 $'
  / nail / var / lib / docker / aufs / layers / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579
• sudo find / nail / var / lib / docker '(' -path '/ nail / var / lib / docker / aufs / diff / ' -o -path '/ nail / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -type f -print0
• sudo xargs -0 -P20 grep --color -l 'f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 $'
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / mount-id

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

$ docker-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
  `` `

Existe alguma maneira de descobrir para qual contêiner essa montagem foi usada?
O documento apenas diz que o ID de montagem não é mais igual ao ID do contêiner, o que não é muito útil.
https://docs.docker.com/engine/userguide/storagedriver/aufs-driver/

@bukzor eb809c0321 é o id do contêiner. O que o docs significa é que o id aufs ( f3286009193f no seu caso) não é o id do contêiner.

/ cc @dmcgowan também

@tonistiigi OK.

Então, obviamente, a montagem sobreviveu ao seu recipiente.

Em que ponto do ciclo de vida do contêiner a montagem é limpa?
Estes são os aufs graváveis ​​temporários para contêineres em execução / interrompidos?

@bukzor (rw) mount é excluído na exclusão do contêiner. A desmontagem ocorre na parada do processo do contêiner. As pastas Diff são um local onde o conteúdo da camada individual é armazenado, não importa se a camada está montada ou não.

@bukzor O link entre o id do aufs e o id do contêiner pode ser encontrado em image/aufs/layerdb/mounts/<container-id>/mount-id . Conhecendo apenas um aufs id, a maneira mais fácil de encontrar o id do contêiner é usar o grep no diretório image/aufs/layerdb para ele. Se nada for encontrado, a limpeza não foi concluída de forma limpa.

Encontrando um problema semelhante.

Estamos executando CI diariamente no servidor docker daemon. / var / lib / docker / aufs / diff requer uma grande quantidade de capacidade do disco, o que não deveria ser.

Ainda 2gb em aufs/diff depois de tentar tudo o que é razoável sugerido aqui ou em tópicos relacionados (incluindo o script bash de @bukzor acima).

Com exceção de uma correção adequada, existe alguma maneira simples de remover as montagens restantes sem remover todas as outras imagens ao mesmo tempo? (Se nenhum contêiner estiver em execução no momento, acho que não deve haver montagens, certo?)

Eu estou experimentando o mesmo problema. Estou usando esta máquina para testar muitos contêineres e, em seguida, confirmar / excluir. Meu diretório / var / lib / docker / aufs tem atualmente 7.9G pesado. Terei que mover este diretório para outro ponto de montagem, porque o armazenamento neste é limitado. :(

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

@mcallaway Tudo em aufs/diff será gravações de fs realizadas em um contêiner.

Eu tenho o mesmo problema. Todos os contêineres que eu tenho estão em estado de execução, mas há muitos diretórios aufs diff que não se relacionam a esses contêineres e se referem a contêineres antigos removidos. Posso removê-los manualmente, mas não é uma opção. Deve haver uma razão para tal comportamento.

Eu uso o k8s 1.3.5 e o docker 1.12.

A corrida de docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc spotify/docker-gc ajudou.

Eu tenho o mesmo problema. Estou usando o Gitlab CI com dind (docker no docker).

IMHO quando a imagem no registro foi atualizada na mesma tag e foi puxada, então o contêiner relacionado foi reiniciado, o contêiner antigo e a imagem não são GCed a menos que você execute spotify/docker-gc

Alguém pode confirmar isso?

@kayrus correto, o docker não assumirá automaticamente que uma imagem "não marcada" também deve ser _removida_. Os contêineres ainda podem estar usando essa imagem e você ainda pode iniciar novos contêineres a partir dessa imagem (referenciando-o por seu ID). Você pode remover imagens "pendentes" usando docker rmi $(docker images -qa -f dangling=true) . Além disso, o docker 1.13 obterá comandos de gerenciamento de dados (consulte https://github.com/docker/docker/pull/26108), que permitem limpar mais facilmente imagens não utilizadas, contêineres, etc.

@thaJeztah /var/lib/docker/aufs/diff/ realmente contém as imagens "não marcadas"?

@kayrus sim, eles fazem parte das imagens (marcados e não marcados)

recebendo um problema semelhante, sem contêineres / imagens / volumes, ~ 13 Gb de 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

O mesmo problema aqui. Eu entendo que o 1.13 pode receber comandos de gerenciamento de dados, mas enquanto isso, eu só quero excluir com segurança o conteúdo deste diretório sem matar o Docker.

Isso é relativamente bloqueador neste ponto.

Mesmo aqui. Ainda sem solução oficial?

Eu mencionei isso algumas vezes no (Docker Community) Slack. Cada vez que um punhado de pessoas executa uma lista de scripts / cmds de coleta de lixo, devo executar como uma solução.

Embora isso tenha ajudado (leia-se: não resolvido - o espaço ainda está quase cheio) nesse ínterim, acho que todos podemos concordar que essa não é a solução ideal a longo prazo.

@jadametz 1.13 tem docker system prune .
Além disso, não tenho certeza de que outra forma o Docker pode ajudar (aberto a sugestões). As imagens não chegam sozinhas ao sistema, mas por meio de pulls, builds, etc.

Em termos de camadas órfãs reais (sem imagens no sistema que as faça referência), precisaremos abordar isso separadamente.

Eu tenho exatamente a mesma questão!

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

Sem imagens, recipientes ou volumes. 42 Gb em aufs / diff

Qualquer coisa para ajudar a limpar este diretório com segurança seria muito útil! Tentei de tudo neste tópico sem sucesso. Obrigado.

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

Obrigado @kayrus, eu realmente tentei isso e aumentou meu uso total do disco ligeiramente e não pareceu fazer nada no diretório aufs / diff.

Eu também tentei docker system prune que não funcionou. E tentei docker rmi $(docker images -qa -f dangling=true) que não encontrou nenhuma imagem para remover.

Para qualquer pessoa interessada, estou usando isso para limpar todos os recipientes, imagens, volumes e aufs antigos:

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

Muita inspiração tirada daqui: 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 Melhor não usar -f ao fazer rm / rmi, pois isso ocultará erros na remoção.
Eu considero a situação atual ... onde -f esconde um erro e então ficamos com algum estado de sobra que é completamente invisível para o usuário ... como um bug.

Também estou vendo isso em uma instalação completamente nova e nada surpreendente:

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 Visto que se trata de uma nova instalação, deseja experimentar? https://github.com/docker/docker/issues/22207#issuecomment -266784433

@adamdry Já apaguei /var/lib/docker/aufs porque estava bloqueando meu trabalho. O que você espera que suas instruções alcancem? Se eles impedirem que o problema ocorra novamente no futuro, posso tentar recriar o problema e seguir suas instruções. No entanto, se o objetivo é apenas liberar espaço, já o consegui.

@robhaswell Sim, foi para liberar espaço em disco, mas tive problemas de acompanhamento ao tentar reconstruir minhas imagens, mas seguindo todas as etapas naquele script, ele resolveu esses problemas.

Durante a construção, se o processo de construção for interrompido durante o processo de construção da camada (que também contém um blob a ser copiado), seguido pela interrupção do contêiner, ele deixa para trás os dados em / var / lib / docker / aufs / diff /. Ele mostrou uma imagem pendente. Limpar também não liberou espaço. É possível incluí-lo como parte da remoção do sistema docker? Apenas excluir os dados do blob dentro desta pasta libera espaço, o que não tenho certeza se causará algum problema ou não.

Versão do Docker: 1.13.0-rc1

Durante a construção, se o processo de construção for interrompido durante o processo de construção da camada (que também contém um blob a ser copiado), seguido pela interrupção do contêiner, ele deixa para trás dados

Essa também pode ser a causa dos meus problemas - eu interrompo muitas compilações.

Durante o docker pull, observamos os dois casos a seguir:

1. se o processo for interrompido quando disser download (que baixa a camada de imagem em / var / lib / docker / tmp /), ele limpa todos os dados dessa pasta
2. Se o processo for interrompido quando disser extração (que suponho ser a extração da camada de tmp para / var / lib / docker / aufs / diff /), ele limpará os dados de blob tmp e diff.

Durante o processo de construção da imagem,

1. Ao interromper o processo ao "Enviando o contexto de construção para o docker daemon" (que copia os dados do blob no meu caso em / var / lib / docker / tmp /), ele permanece lá para sempre e não pode ser limpo por nenhum comando, exceto excluí-lo manualmente. Não tenho certeza de como o apt get updates in image é tratado.
2. Enquanto a camada que contém dados de blob está sendo construída, digamos, uma grande configuração de software, se o processo for interrompido, o contêiner do docker continuará trabalhando na imagem. No meu caso, apenas 1 layer blob data, que já está disponível na pasta tmp, compõe a imagem inteira. Mas, se o contêiner for interrompido usando o comando docker stop, dois casos acontecerão:
   uma. se o processo de montagem ainda estiver acontecendo, ele deixará para trás os dados nas pastas tmp e diff.
   b. Se os dados forem copiados na pasta diff, ele removerá os dados da pasta tmp e deixará os dados na pasta diff e talvez na pasta mount.

Temos um processo de construção automatizado, que precisa de um controle para interromper qualquer processo de construção normalmente. Recentemente, um processo foi interrompido pelo kernel devido a um erro de falta de memória em uma máquina que estava com configuração baixa.

Se uma imagem deve ser construída de 2 camadas, 1 camada é construída e a 2ª interrompida, a poda do sistema Docker parece limpar os dados para o contêiner da camada que foi interrompida e o contêiner parado. Mas não limpa os dados das camadas anteriores em caso de interrupção. Além disso, não refletia o espaço total em disco reivindicado. Executou esses testes no sistema AWS, ubuntu 14.04, x86_64 bits com sistema de arquivos aufs. Executei o teste de poda do docker com docker 1.13.0 rc3 e docker 1.12

@thaJeztah
Por favor, deixe-me saber se eu estou interpretando mal alguma coisa.

Abri um problema para os arquivos /var/lib/docker/tmp que não estão sendo limpos; https://github.com/docker/docker/issues/29486

A poda do sistema Docker parece limpar os dados do contêiner da camada que foi interrompido e o contêiner parado. Mas não limpa os dados das camadas anteriores em caso de interrupção.

Tentei reproduzir essa situação, mas não consegui ver com um caso simples;

Comece com uma instalação limpa e vazia /var/lib/docker , crie um arquivo grande para
teste e um Dockerfile;

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

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

inicie docker build e cancele durante a construção, mas _após_ a construção
o contexto foi enviado;

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

verifique o conteúdo 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/

execute o comando docker system prune para limpar imagens, contêineres;

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

verifique o conteúdo 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/

Vejo que a montagem -init foi deixada para trás, vou verificar se podemos resolver
que (embora seja apenas um diretório vazio)

A única diferença no dockerfile que usei foi (para criar camadas diferentes)
Do princípio
COPIAR ["./bigfile", "randomNoFile1", /]
COPIAR ["./bigfile", "randomNoFile2", /]
EOF

Não tenho certeza se isso faz diferença.

Não, o problema não é sobre as pastas init vazias. No meu caso, foi o blob. No entanto, posso verificar novamente na segunda-feira e atualizar.

Além disso, estava usando um arquivo de 5 GB, criado lendo bytes do dev urandom.
No seu caso, o mesmo arquivo é adicionado 2 vezes. Isso criaria uma camada única e montaria a segunda camada a partir dela ou seriam 2 camadas separadas? No meu caso, são sempre 2 camadas separadas.

@thaJeztah
Obrigado por uma resposta tão rápida sobre o problema. A adição deste recurso seria de grande ajuda!

@ monikakatiyar16 Eu tentei reproduzir isso também cancelando a compilação várias vezes durante os comandos ADD e RUN mas não consegui que nada vazasse para aufs/diff após a exclusão. Não consegui entender qual contêiner você está parando porque os contêineres não deveriam estar em execução durante as operações de ADD/COPY . Se você puder montar um reprodutor que possamos rodar, será muito apreciado.

É possível que eu esteja fazendo algo errado. Como estou viajando no final de semana, irei reproduzi-lo e atualizar todas as informações necessárias aqui na segunda-feira.

@tonistiigi @thaJeztah
Eu sinto que você está certo. Na verdade, não há contêineres listados como ativos e em execução. Em vez disso, existem recipientes mortos. A remoção do sistema Docker não funcionou no meu caso, pode ser porque o processo não foi encerrado com Ctrl + C. Em vez disso, ele continuou rodando em segundo plano. No meu caso, seria esse o motivo, ele não conseguiu remover essas bolhas.

Quando eu interrompo o processo usando Ctrl + C, o processo de construção é encerrado, mas um processo para docker-untar permanece ativo em segundo plano, que continua trabalhando na construção da imagem. (Observação: / var / lib / docker está vinculado a / home / lib / docker para usar os volumes EBS para grandes dados no AWS)

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

Anexei o script que estava usando para criar arquivos grandes e construir a imagem (gc_maxpush_pull.sh)

Também anexado o comportamento do processo de construção para construir uma imagem, interrompendo-o com Ctrl + C (DockerBuild_WOProcessKill) e construir imagem - interrompendo-o com Ctrl + C - matando o processo (DockerBuild_WithProcessKill)

Usando os comandos -

Para criar um arquivo grande: ./gc_maxpush_pull.sh 1 5gblayer 0 512 1

Para construir imagens: ./gc_maxpush_pull.sh 1 5gblayer 1 512 1

DockerBuild.zip

Etapas para replicar:

1. Crie um arquivo grande de 5 GB
2. Inicie o processo de compilação e interrompa-o somente depois que o contexto de envio de compilação terminar e ele estiver realmente copiando o blob.
3. Ele conclui a construção da imagem depois de um tempo e a mostra nas imagens do docker (como no caso 1 anexado por mim - DockerBuild_WOProcessKill)
4. Se o processo for encerrado, ele demorará um pouco e deixará os dados do blob em / diff (que deve ocorrer ao encerrar o processo abruptamente, conforme anexado no arquivo - DockerBuild_WithProcessKill)

Se o que estou presumindo estiver correto, então isso pode não ser um problema com o docker prune, em vez de matar o docker build que de alguma forma não está funcionando para mim.

Existe uma maneira elegante de interromper ou parar o processo de construção da imagem, que também cuida da limpeza dos dados copiados (conforme tratado no docker pull)?

Anteriormente, eu não estava matando o processo. Também estou curioso para saber o que o docker-untar faz e por que ele o monta nas pastas / mnt e / diff e, posteriormente, limpa a pasta / mnt?

Testado com Docker versão 1.12.5, compilação 7392c3b em AWS

informação do docker
Recipientes: 2
Em execução: 0
Pausado: 0
Parado: 2
Imagens: 0
Versão do servidor: 1.12.5
Driver de armazenamento: aufs
Dir raiz: / home / lib / docker / aufs
Sistema de arquivos de backup: extfs
Dirs: 4
Compatível com Dirperm1: falso
Driver de registro: arquivo json
Driver Cgroup: cgroupfs
Plugins:
Volume: local
Rede: host nulo de ponte de sobreposição
Enxame: inativo
Runtimes: runc
Tempo de execução padrão: runc
Opções de segurança: apparmor
Versão do kernel: 3.13.0-105-genérico
Sistema operacional: Ubuntu 14.04.4 LTS
OSType: linux
Arquitetura: x86_64
CPUs: 2
Memória total: 3,859 GiB
Nome: mestre
ID: 2 NQU: D2C5 : 5 WPL: IIDR : P6FO: OAG7: GHW6: ZJMQ: VDHI : B5CI: XFZJ: ZSZM
Docker Root Dir: / home / lib / docker
Modo de depuração (cliente): falso
Modo de depuração (servidor): falso
Registro: https://index.docker.io/v1/
AVISO: Sem suporte para limite de troca
Registros inseguros:
127.0.0.0/8

@ monikakatiyar16 Quando mato manualmente untar processo durante a compilação, recebo Error processing tar file(signal: killed): na saída da compilação. Deixar para trás o contêiner em docker ps -a é o comportamento correto, a mesma coisa acontece em qualquer erro de compilação e permite depurar os problemas que causaram a falha da compilação. No entanto, não tenho nenhum problema em excluir este contêiner e, se eu fizer isso, todos os dados em /var/lib/docker/aufs serão limpos.

@tonistiigi Sim, você está correto. Consegui excluir o volume associado ao contêiner e ele limpou tudo, depois de encerrar o processo docker-untar. A poda do sistema Docker também funciona neste caso.

O problema real que sobrou dos volumes foi o caso, quando, sem encerrar o processo docker-untar, tentei remover o contêiner do docker junto com os volumes - o que gerou o seguinte erro:

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

Logs 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

Parece que a ordem a ser seguida agora para interromper uma compilação do docker é:
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 , pode ser Interrupt docker build > Kill docker untar process > docker system prune -a

Isso parece funcionar perfeitamente. Não há problemas de limpeza; em vez disso, o único problema é o processo docker-untar não ser eliminado junto com o processo docker-build.

Vou pesquisar / atualizar / registrar um novo problema para a interrupção normal da compilação do docker que também interrompe o processo docker-untar junto com ele.

(Foi verificado com docker v1.12.5 e v1.13.0-rc4)

Atualização: ao matar docker-untar durante o envio do contexto de compilação para o daemon do docker, ocorre um erro na compilação: Error response from daemon: Error processing tar file(signal: terminated) , mas durante a cópia de camada não (para mim)

Obrigado por ser tão paciente e por dedicar seu tempo!

Estou vendo /var/lib/docker/aufs aumentar consistentemente em tamanho em um trabalhador do modo docker swarm. Essa coisa é principalmente autônoma sendo gerenciada pelo gerenciador de enxame e muito pouca criação manual de contêiner além de alguns comandos de manutenção aqui e ali.

Eu corro docker exec em contêineres de serviço; não tenho certeza se isso pode ser uma causa.

Minha solução alternativa para resolver isso no meu caso foi iniciar outro trabalhador, definir o nó completo para --availability=drain e mover manualmente algumas montagens de volume.

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

Isso atingiu nosso servidor de CI por muito tempo. Isso precisa ser consertado.

@orf obrigado

O mesmo problema aqui. Nenhum contêiner, volumes e remoção de imagem, comandos de limpeza do nore Docker 1.13 têm qualquer efeito.

Também confirmo que fiz alguns cancelamentos de construção de imagem. Talvez isso deixe pastas que também não podem ser alcançadas.
Vou usar o bom e velho método rm por enquanto, mas isso é claramente um bug.

Os arquivos em / var / lib / docker / aufs / diff preenchem 100% de espaço para o sistema de arquivos / dev / sda1 de 30G

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

Tamanho do sistema de arquivos usado% de uso disponível montado em
udev 14G 0 14G 0% / dev
tmpfs 2.8G 273M 2.5G 10% / corrida
/ dev / sda1 29G 29G 0 100% /
tmpfs 14G 0 14G 0% / dev / shm
tmpfs 5.0M 0 5.0M 0% / executar / bloquear
tmpfs 14G 0 14G 0% / sys / fs / cgroup
/ dev / sdb1 197G 60M 187G 1% / mnt
tmpfs 2.8G 0 2.8G 0% / run / user / 1000

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

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

Também tentei, poda do sistema docker , que não ajudou.

Alguém encontrou uma solução para este problema contínuo de arquivos muito grandes no diff antes que esse bug seja corrigido no código?

Sim, o método já foi fornecido, mas aqui está um trecho de apocalipse que destrói tudo que coloquei no local aqui no trabalho (exceto pastas locais para os volumes). Para colocar o bashrc ou outro arquivo de configuração do bash.

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

func_full-cleanup-docker () {

echo "AVISO: Isso removerá tudo do docker: volumes, contêineres e imagens. Você ousará? [s / N]"
escolha de leitura

if [("$ choice" == "y") -o ("$ choice" == "Y")]
então
sudo echo "> verificação de direitos de sudo [OK]"
tamanho = 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
} `` `

Eu executei o comando rm -rf para remover os arquivos da pasta diff por enquanto. Provavelmente terá que examinar o script se a pasta diff ocupar todo o espaço do disco novamente.
Espero ver esse problema corrigido no código, em vez de soluções alternativas.

Oi, eu tenho o mesmo problema no docker 1.10.2, estou executando o kubernetes. esta é minha versão 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

Estou tentando rastrear todos os diretórios diff não usados ​​em /var/lib/docker/aufs/diff e /var/lib/docker/aufs/mnt/ analisando os arquivos de camada em /var/lib/docker/image/aufs/imagedb , aqui está o script que usei:

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

Mas encontrei um problema quando paro e reinicio o daemon do docker, parece que faço algum status inconsistente do docker:

/var/log/upstart/docker.log:

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

e quando tento criar novos contêineres por docker run , falha com a mensagem:

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

e o log do daemon mostra:

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

alguém sabe se minha abordagem é correta ou não? e por que o problema ocorre depois que excluo essas pastas?

Abri o # 31012 para, pelo menos, ter certeza de que não vazaremos esses diretórios em nenhuma circunstância.
É claro que também precisamos examinar as várias causas dos erros busy

Isso estava me mordendo desde que me lembro. Obtive praticamente os mesmos resultados descritos acima quando mudei para o driver overlay2 alguns dias atrás e destruí completamente a pasta aufs ( docker system df diz 1.5Gigs, df diz 15Gigs) .

Tive cerca de 1T de diffs usando armazenamento. Depois de reiniciar meu daemon do docker - recuperei cerca de 700 GB. Então eu acho que parar o daemon poda isso?

Reiniciar não faz nada para mim, infelizmente.

Reiniciar o serviço não ajudou. Este é um problema sério. Remover todos os contêineres / imagens não remove esses diffs.

Parar o daemon não os eliminaria.

Se você remover todos os contêineres e ainda tiver diff dirs, é provável que haja algumas camadas rw vazadas.

Acabamos de encontrar esse problema. /var/lib/docker/aufs/diff pegou 28G e levou nosso sistema de arquivos raiz a 100%, o que fez com que nosso servidor GitLab parasse de responder. Estamos usando o docker para GitLab CI. Para corrigir isso, usei alguns dos comandos @sogetimaitral sugeridos acima para excluir os arquivos temporários e estamos de volta ao funcionamento. Eu reiniciei o servidor e enviei um novo commit para acionar o CI, e tudo parece estar funcionando como deveria.

Estou definitivamente preocupado que isso aconteça novamente. Qual é o problema aqui? É um bug do docker que precisa ser corrigido?

1. Sim, há um bug (que há problemas na remoção e que --force on rm ignora esses problemas)
2. Geralmente, não se deve gravar muitos dados no contêiner fs e, em vez disso, usar um volume (mesmo um volume descartável). Um dir diff grande indicaria que há uma quantidade significativa de dados sendo gravados no contêiner fs.

Se você não usar "--force" na remoção, você não encontrará esse problema (ou pelo menos verá que tem um monte de containers "mortos" e sabe como / o que limpar).

Não estou usando o docker manualmente. Estamos usando gitlab-ci-multi-runner . Poderia ser um bug no final do GitLab então?

Parece (por padrão) que força a remoção de contêineres; https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/dbdbce2848530df299836768c8ea01e209a2fe40/executors/docker/executor_docker.go#L878. Fazer isso pode resultar em falhas na remoção do contêiner sendo ignorado, levando aos diffs órfãos.

Ok, então isso me diz que este é um bug do gitlab-ci-multi-runner. Esta é uma interpretação correta? Estou feliz em criar um problema para eles corrigirem isso.

É uma combinação, eu acho; A remoção "forçada" torna mais fácil lidar com limpezas (ou seja, casos em que um contêiner ainda não foi interrompido, etc), ao mesmo tempo (esse é o "bug" @ cpuguy83 mencionado), também pode ocultar problemas reais, como falha do docker ao remover o sistema de arquivos de contêineres (o que pode ter vários motivos). Com "força", o recipiente é retirado nesses casos. Sem, o contêiner é deixado ao redor (mas marcado como "morto")

Se o gitlab runner pode funcionar corretamente sem a remoção forçada, provavelmente será bom mudar (ou torná-lo configurável)

Estou usando o Drone e tenho o mesmo problema. Não verifiquei o código de como os contêineres são removidos, mas acho que a remoção forçada também.

Poderia ser um problema do Docker no Docker? Estou começando Drone com docker-compose.

Decidi ir em frente e enviar um problema gitlab-ci-multi-runner apenas para colocar os desenvolvedores em: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

Honestamente, contornamos isso executando o docker gc do Spotify com o drone CI.

El El mar, mar. 28 de 2017 às 15:38, Geoffrey Fairchild <
notificaçõ[email protected]> escribió:

Decidi ir em frente e enviar um problema gitlab-ci-multi-runner apenas para
loop os devs em:
https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/docker/issues/22207#issuecomment-289926298 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AC6Wz197zkjWWOlq1-JOibiQP-xJym9Eks5rqYvegaJpZM4IMGt2
.

@sedouard Obrigado por esta dica! Executar docker-gc por hora a partir do spotify resolveu o problema para mim.

Estamos recebendo esse problema em execução no Gitlab CI (não em execução no docker), usando comandos para criar imagens / executar contêineres (não na integração do Gitlab CI Docker). Não estamos executando nenhuma forma de remoção de força, simplesmente docker run --rm ... e docker rmi image:tag

EDIT : desculpe, na verdade o problema original é o mesmo. A diferença é que executar spotify/docker-gc _não_ corrige o problema.

Como você pode ver abaixo, eu tenho 0 imagens, 0 contêineres, nada!
docker system info concorda comigo, mas menciona Dirs: 38 para o armazenamento aufs.

Isso é suspeito! Se você olhar para /var/lib/docker/aufs/diff/ , veremos que há na verdade 1,7 GB de dados lá, mais de 41 diretórios. E essa é minha caixa pessoal, no servidor de produção é de 19 GB.

Como podemos limpar isso? usar spotify/docker-gc não os remove.

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

Posso rm -r /var/lib/docker/aufs com segurança e reiniciar o docker deamon?

Executar spotify/docker-gc não limpa esses órfãos.

EDIT : obrigado @CVTJNII!

Parar o daemon do Docker e apagar todo o / var / lib / docker será mais seguro. Apagar / var / lib / docker / aufs fará com que você perca suas imagens de qualquer maneira, então é melhor começar com um / var / lib / docker limpo na minha opinião. Esta é a "solução" que venho usando há vários meses para esse problema.

A partir de 17.06, não deve haver mais nenhum novo diffs órfão.
Em vez disso, você pode começar a ver os contêineres com o estado Dead , isso acontece se houver um erro durante a remoção que não pode ser recuperado e pode exigir que um administrador resolva o problema.

Além disso, a remoção é um pouco mais robusta e menos sujeita a erros devido a condições de corrida ou desmontagem com falha.

@ cpuguy83 : ótimas notícias, você pode explicar o que o administrador precisará fazer se isso acontecer?

@Silex Depende da causa.
Normalmente, o que acontece é que há um erro device or resource busy devido a algum suporte vazar para um contêiner. Se você estiver executando algo como o cadvisor, isso é praticamente uma garantia, pois as instruções dizem para montar o diretório docker inteiro no contêiner do cadvisor.

Isso pode ser complicado, você pode ter que parar os contêineres ofensivos e, em seguida, remover o contêiner dead .

Se você estiver em um kernel mais novo (3.15+), é improvável que você veja o problema mais, embora ainda possa haver algum caso extremo.

Docker versão 17.06.0-ce, compilação 02c1d87

Tentei remover todas as imagens, volumes, redes e containers, mas não adiantou.
Comandos também experimentados:

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

Ainda permanecem arquivos:

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

Como pode ser excluído?

@ haos616 tente primeiro interromper todos os contêineres em execução e, em seguida, execute docker system prune -af .
Isso funcionou para mim.
Não funcionou enquanto eu tinha um contêiner em execução.

Se for uma atualização de uma versão anterior do docker, é possível que esses diffs tenham sido gerados / deixados para trás por essa versão. O Docker 17.06 não removerá um contêiner se as camadas falharem ao serem removidas (ao usar --force); versões mais antigas sim, o que poderia levar a camadas órfãs

@ julian-pani Eu fiz isso no começo, mas não ajuda.

# 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 Não. Limpei o Docker um ou dois meses atrás. Então a versão já era 17.06. Usei o comando docker system prune -af . Ele removeu tudo.

Executar https://github.com/spotify/docker-gc como um contêiner funcionou para mim, mas foi um passo a mais e excluiu algumas das minhas imagens necessárias :(

Então eu coloquei um pequeno script de wrapper como abaixo para ser

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

obrigado novamente ao spotify

IIUC, o script do spotify apenas chama docker rm e docker rmi - ele realmente removeu diffs órfãos?

Apenas alguns comentários para a comunidade. Li tudo isso e nenhuma das soluções parece funcionar de forma consistente ou confiável. Minha "correção" foi simplesmente dobrar a quantidade de espaço em disco em minhas instâncias do AWS. E eu sei muito bem que isso é uma solução ruim, mas é a melhor solução que encontrei para os aufs inchados de Docker. Isso realmente precisa ser consertado.

@fuzzygroup 17.06 não deve mais criar diffs órfãos, mas não limpará os antigos ainda.

Eu poderia limpar com este script. Não vejo por que não funcionaria, mas quem sabe.
De qualquer forma, está funcionando bem para mim. Ele excluirá todas as imagens, contêineres e volumes ... Como não deve ser executado com frequência, acho que é um efeito colateral menor. Mas depende de você usá-lo ou não.

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

https://stackoverflow.com/q/45798076/562769 parece estar relacionado. Publiquei uma solução rápida.

Para sua informação, ainda estou vendo isso com 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 contém muitos diretórios com os prefixos -init-removing e -removing :

ffd5477de24b0d9993724e40175185038a62250861516030a33280898243e742-removing
ffd900de0634992e99c022a16775805dfd0ffd1f6c89fece7deb6b1a71c5e38c-init-removing
ffd900de0634992e99c022a16775805dfd0ffd1f6c89fece7deb6b1a71c5e38c-removing

Para sua informação, ainda vejo isso com 17.06.1-ce

Ainda está vendo o quê, exatamente?
Não deve haver nenhuma maneira de um diretório diff vazar, embora os dirs diff ainda existam se eles existiram na atualização, eles ainda existirão.

Ainda estou vendo diferenças órfãs, tanto quanto posso dizer. docker system prune não os removeu, nem docker-gc . A execução manual de rm -rf /var/lib/docker/aufs/diff/*-removing parece estar funcionando.

Sim, o docker ainda não limpará antigos dirs órfãos.

Por antigo, você quer dizer aqueles criados a partir de uma versão anterior do docker com este problema?

Esta é uma nova instalação do Docker que fizemos cerca de duas semanas atrás. Esses órfãos devem ter sido criados desde então, então parece que o docker ainda deve estar criando esses órfãos?

Quer dizer, na última meia hora eu tenho 112 novos diffs com -removing , já que eu os rmei manualmente.

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

Você disse "17.06 não deveria mais criar diffs órfãos, mas não limpará os antigos ainda.", Mas certamente isso não pode estar correto, ou estou faltando alguma coisa? Aqueles marcados com -removing não são órfãos?

@orf Em um kernel mais novo, é altamente inesperado ter qualquer problema durante a remoção. Você está montando /var/lib/docker em um contêiner?

Vou verificar o driver do aufs para ver se há um problema específico com ele relatando uma remoção bem-sucedida quando na verdade não era.

Não estamos montando /var/lib/docker em um contêiner.

$ 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 executando 14.04 LTS

Deixe-me saber se houver algo que eu possa fornecer para ajudar a depurar isso.

Por outros motivos (rede no modo swarm) mudei 14.04 para o Docker
máquinas.
Em segunda-feira, 21 de agosto de 2017 às 8:23 AM orf [email protected] escreveu:

Não estamos montando / var / lib / docker em um contêiner.

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

Estamos executando 14.04 LTS

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/moby/moby/issues/22207#issuecomment-323773033 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AADRIfE2B2HNpbsKyTOj1CwGzulRT2C0ks5saaDPgaJpZM4IMGt2
.

Isso parece ser pior com 17.06.01-ce. Eu atualizei uma máquina de construção para esta versão e imediatamente comecei a ver os diretórios *-init-removing e *-removing restantes como parte do processo de construção. Parei o serviço, removi o diretório /var/lib/docker , reiniciei o serviço e, após algumas compilações, estava quase sem espaço em disco novamente. Parei o serviço novamente, executei apt-get purge docker-ce , removi /var/lib/docker novamente e instalei a versão 17.06.0-ce. Não obter os diretórios extras em /var/lib/docker/aufs/diff e o espaço em disco é representativo das imagens que estão na máquina de construção. Eu reproduzi o comportamento em minha máquina de desenvolvimento também - apenas construir uma imagem parece criar esses diretórios extras para cada camada da imagem, então eu ficaria sem espaço em disco muito rápido. Novamente, reverter para 17.06.0-ce parece não ter problemas, então vou ficar lá por enquanto.

@mmanderson Obrigado por relatar. Dando uma olhada nas mudanças no driver AUFS.

@mmanderson Você tem algum contêiner no estado Dead em docker ps -a ?

Todos os meus servidores de compilação docker estão ficando sem espaço.

Fiz upgrade na última semana ou mais para o Docker versão 17.06.1-ce, compilação 874a737. Acredito que nada mais mudou e que esse problema surgiu ou se manifestou como parte do processo de atualização. O diretório aufs diff é enorme e já limpei todas as imagens e volumes pendentes.

issue-22207.txt
@ cpuguy83 Nenhum contêiner em qualquer estado. Aqui está o que eu mal fiz para demonstrar isso com 17.06.01-ce:

1. Iniciado com uma nova instalação do docker 17.06.01-ce no Ubuntu 16.04.03 LTS (ou seja, docker não instalado e sem diretório / var / lib / docker). Após a instalação, foi verificado um diretório / var / lib / docker / aufs / diff vazio.
2. Rodou um docker build com um dockerfile bastante simples baseado no ubuntu: latest - tudo o que ele faz é puxar statsd_exporter do github e extraí-lo em / usr / bin (veja o arquivo anexado).
3. Depois de executar a construção, execute docker ps -a para não mostrar nenhum contêiner em qualquer estado. Existem várias pastas *-remaining na pasta /var/lib/docker/aufs/diff .
4. Execute docker system df para verificar imagens, contêineres e volumes. O resultado é

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. Executando du -sch /var/lib/docker/*/ mostra 152 milhões para /var/lib/docker/aufs/
2. Execute docker rmi $(docker images -q) para remover as camadas de imagem construídas. Executar docker system df depois disso mostra todos os zeros. Executar du -sch /var/lib/docker/*/ mostra 152 milhões para /var/lib/docker/aufs/ e há *-remaining pastas para todas as pastas que não as tinham antes, juntamente com as pastas *-remaining que Ainda estão lá.

@erikh é esse o problema que você está enfrentando?

@ cpuguy83 Depois de desinstalar o 17.06.01-ce, remover o diretório / var / lib / docker e instalar o 17.06.0-ce, tento executar a mesma compilação. A compilação falha devido ao bug ADD from remote URL's que foi corrigido em 17.06.01. No entanto, não recebo nenhum diretório *-remaining para as etapas concluídas e depois de limpar tudo com docker system prune e docker rmi $(docker image -q) o diretório /var/lib/docker/aufs/diff está novamente vazio e o espaço é liberado.

Obrigado a todos, isso é uma regressão em 17.06.1 ...
O PR para corrigir está aqui: https://github.com/moby/moby/pull/34587

incrível, obrigado pelo patch rápido @ cpuguy83! / cc @erikh

@rogaha! sim, obrigado a você e @ cpuguy83!

Muito obrigado @Karreg pelo seu excelente script . Depois de nos livrar de todos os antigos diffs ophanos e liberar grandes quantidades de espaço em disco perdido novamente, estamos usando-o agora regularmente para limpar nossas VMs antes de instalar novas imagens do docker. Grande ajuda e uma solução quase perfeita para esse problema agora. @ TP75

Parece que a Docker, Inc. tem alguns contratos com fabricantes de armazenamento de dados de computador.

O script de @Karreg funcionou bem para mim e

Tendo o mesmo problema.
Detalhes do Docker Host

root @ UbuntuCont : ~ # docker info
Recipientes: 3
Em execução: 0
Pausado: 0
Parado: 3
Imagens: 4
Versão do servidor: 17.06.1-ce
Driver de armazenamento: aufs
Dir raiz: / var / lib / docker / aufs
Sistema de arquivos de backup: extfs
Dirs: 14
Compatível com Dirperm1: verdadeiro
Driver de registro: arquivo json
Driver Cgroup: cgroupfs
Plugins:
Volume: local
Rede: sobreposição nula do host de ponte macvlan
Log: awslogs fluentd gcplogs gelf journald arquivo json logentries splunk syslog
Enxame: inativo
Runtimes: runc
Tempo de execução padrão: runc
Init Binary: docker-init
versão containerd: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
versão runc: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
versão init: 949e6fa
Opções de segurança:
apparmor
seccomp
Perfil: padrão
Versão do kernel: 4.4.0-93-genérico
Sistema operacional: Ubuntu 16.04.3 LTS
OSType: linux
Arquitetura: x86_64
CPUs: 1
Memória Total: 3.358GiB
Nome: UbuntuCont
ID: QQA5: DC5S: C2FL: LCC6: XY6E: V3FR: TRW3: VMOQ: QQKD : AP2M: H3JA: I6VX
Docker Root Dir: / var / lib / docker
Modo de depuração (cliente): falso
Modo de depuração (servidor): falso
Registro: https://index.docker.io/v1/
Experimental: falso
Registros inseguros:
127.0.0.0/8
Live Restore Enabled: false

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

@kasunsjc por favor leia os posts logo acima do seu.

Confirmo que a atualização para 17.06.2-ce resolveu este problema. Eu não tive que manualmente os diretórios (última vez) após a atualização.

17.06.2-ce _parece_ ter corrigido isso para mim também. Não há mais diretórios -removing lá, tenho uma quantidade decente de espaço de volta.

Estou assumindo que os -init diretórios que tenho em aufs/diff não estão relacionados (alguns deles são bem antigos). Eles são todos pequenos, porém, isso pouco importa.

Atualizar para 17.07.0 também resolveu o problema aqui, nem mesmo docker system prune --all -f removeria os diretórios antes, mas após a atualização, eles foram removidos automaticamente na reinicialização.

A confirmação de que esse problema foi resolvido no Ubuntu 16.04 com 17.06.2-ce. Assim que foi atualizado, o espaço foi liberado.