# 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

Je devrais également montrer que docker ne répertorie aucun conteneur, volume ou image:

$ 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

étrange; surtout à cause de;

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

qui ne correspond pas à la sortie de docker images / docker ps .

Sur quel système d'exploitation utilisez-vous?

Operating System: <unknown>

@tonistiigi une idée?

C'était après. Je suppose que certains processus ont démarré entre-temps.

L'état auquel je fais référence (que j'ai maintenant) est:

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

Et j'ai toujours:

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

Nous sommes sur Ubuntu Lucid avec un noyau mis à jour = /

$ 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

Cela semble une question intéressante.
est-il possible d'avoir moyen de le reproduire? @bukzor

C'est sûrement possible, mais je ne sais pas comment.
Veuillez essayer d'exécuter le script ci-dessous sur l'un de vos hôtes docker actifs et voir ce qu'il en reste.
Dans notre cas, il y a toujours beaucoup de différences laissées pour compte.

`` #! bash

! / bin / bash

set -eu

echo "AVERTISSEMENT :: Cela arrêtera TOUS les processus docker et supprimera TOUTES les images docker."
read -p "Continuer (o / n)?"
if ["$ REPLY"! = "y"]; ensuite
echo "Aborting."
sortie 1
Fi

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

set -x

supprimer des conteneurs

docker ps -q | arrêt xdocker
docker ps -aq | xdocker rm

supprimer les balises

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

supprimer des images

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

supprimer des volumes

volume du docker ls -q | volume xdocker rm
''

Une façon possible de voir cela se produire est que s'il y a des erreurs lors du démontage aufs. Par exemple, s'il y a des erreurs EBUSY, la configuration de l'image a probablement déjà été supprimée auparavant.

@bukzor Ce serait très intéressant s'il y avait un reproducteur qui commencerait à partir d'un répertoire graphique vide, tirerait / exécuterait des images et le mettrait dans un état où il ne nettoie pas complètement après l'exécution de votre script.

Ce serait intéressant, mais cela ressemble à une journée complète de travail.
Je ne peux pas m'engager à ça.

Voici quelques données supplémentaires concernant la différence gênante (sélectionnée arbitrairement) ci-dessus, a800 .

`` #! sh
$ docker-find a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea | sudo xargs -n1 wc -l | trier -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 / clou / var / lib / docker / aufs / couches / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579
  14 / clou / var / lib / docker / aufs / couches / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579-init
  13 / clou / var / lib / docker / aufs / couches / 993e4988c510ec3ab4f6d139740a059df40585576f8196817e573a9684554c5c
  12 / clou / var / lib / docker / aufs / couches / cf9fd1c4a64baa39b6d6d9dac048ad2fff3c3fe13924b07377e767eed230ba9f
  11 / clou / var / lib / docker / aufs / couches / 4e6afb958b5ee6dea6d1a886d19fc9c780d4ecc4baeebfbde31f9bb97732d10d
  10 / clou / var / lib / docker / aufs / couches / 23ce5a473b101d85f0e9465debe5a0f3b8a2079b99528a797b02052d06bc11d8
  9 / clou / var / lib / docker / aufs / couches / 95e68d59a8704f2bb52cc1306ca910ddb7af8956eb7c57970fcf7d8b3d9baddb
  8 / clou / var / lib / docker / aufs / couches / ac6b8ff4c0e7b91230ebf4c1caf16f06c1fdceff6111fd58f4ea50fc2dd5050b
  7 / clou / var / lib / docker / aufs / couches / fd895b6f56aedf09c48dba97931a34cea863a21175450c31b6ceadde03f7b3da
  6 / clou / var / lib / docker / aufs / couches / d5bbef5adf2efb6f15d4f96c4bee21beb955255d1ec17baf35de66e98e6c7328
  5 / clou / var / lib / docker / aufs / couches / 9646360df378b88eae6f1d6288439eebd9647d5b9e8a471840d4a9d6ed5d92a4
  4 / clou / var / lib / docker / aufs / couches / 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 --couleur 'f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 $'
  / nail / var / lib / docker / aufs / couches / 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 --couleur -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 --couleur 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 --couleur -l eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e
  ''

Existe-t-il un moyen de trouver pour quel conteneur ce support a été utilisé?
Le document dit seulement que l'ID de montage n'est plus égal à l'ID du conteneur, ce qui n'est pas très utile.
https://docs.docker.com/engine/userguide/storagedriver/aufs-driver/

@bukzor eb809c0321 est l'identifiant du conteneur. Ce que la documentation signifie, c'est que l'ID aufs ( f3286009193f dans votre cas) n'est pas l'ID du conteneur.

/ cc @dmcgowan aussi

@tonistiigi OK.

Alors évidemment, la monture a survécu à son conteneur.

À quel stade du cycle de vie du conteneur le support est-il nettoyé?
S'agit-il des aufs temporaires accessibles en écriture pour les conteneurs en cours d'exécution / arrêtés?

Le montage @bukzor (rw) est supprimé lors de la suppression du conteneur. Le démontage se produit à l'arrêt du processus du conteneur. Les dossiers de différences sont un endroit où le contenu des calques individuels est stocké, peu importe que le calque soit monté ou non.

@bukzor Le lien entre l'ID aufs et l'ID du conteneur peut être trouvé à image/aufs/layerdb/mounts/<container-id>/mount-id . En connaissant simplement un identifiant aufs, le moyen le plus simple de trouver l'identifiant du conteneur est de grep le répertoire image/aufs/layerdb correspondant. Si rien n'est trouvé, le nettoyage n'a pas été effectué proprement.

Rencontrer un problème similaire.

Nous exécutons quotidiennement CI dans le serveur de démon docker. / var / lib / docker / aufs / diff prend une quantité considérable de capacité de disque, ce qui ne devrait pas être le cas.

Toujours 2gb dans aufs/diff après avoir essayé tout ce qui est raisonnable suggéré ici ou dans les threads connexes (y compris le script bash de

À défaut d'une solution appropriée, existe-t-il un moyen simple de supprimer les supports restants sans supprimer toutes les autres images en même temps? (Si aucun conteneur n'est en cours d'exécution actuellement, je suppose qu'il ne devrait y avoir aucun montage, non?)

Je rencontre le même problème. J'utilise cette machine pour tester de nombreux conteneurs, puis commettre / supprimer. Mon répertoire / var / lib / docker / aufs est actuellement 7.9G lourd. Je vais devoir déplacer ce répertoire vers un autre point de montage, car le stockage sur celui-ci est limité. :(

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

@mcallaway Tout dans aufs/diff va être des écritures fs effectuées dans un conteneur.

J'ai le même problème. Tous les conteneurs que j'ai sont en état de marche, mais il y a beaucoup de répertoires aufs diff qui ne se rapportent pas à ces conteneurs et se rapportent aux anciens conteneurs supprimés. Je peux les supprimer manuellement, mais ce n'est pas une option. Il devrait y avoir une raison à un tel comportement.

J'utilise k8s 1.3.5 et docker 1.12.

L'exécution du docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc spotify/docker-gc aidé.

J'ai le même problème. J'utilise Gitlab CI avec dind (docker dans docker).

IMHO lorsque l'image dans le registre a été mise à jour dans la même balise et qu'elle a été extraite, puis le conteneur associé a été redémarré, l'ancien conteneur et l'image ne sont pas GC sauf si vous exécutez spotify/docker-gc .

Est-ce que quelqu'un d'autre peut confirmer cela?

@kayrus correct, docker ne supposera pas automatiquement qu'une image "non balisée" devrait également être _supprimée_. Les conteneurs peuvent toujours utiliser cette image et vous pouvez toujours démarrer de nouveaux conteneurs à partir de cette image (en la référençant par son ID). Vous pouvez supprimer les images «pendantes» en utilisant docker rmi $(docker images -qa -f dangling=true) . De plus, docker 1.13 obtiendra des commandes de gestion des données (voir https://github.com/docker/docker/pull/26108), qui vous permettent de nettoyer plus facilement les images inutilisées, les conteneurs, etc.

@thaJeztah est-ce que /var/lib/docker/aufs/diff/ contient réellement les images "non marquées"?

@kayrus oui ils font partie des images (tagués et non taggés)

obtenir un problème similaire, pas de conteneurs / images / volumes, ~ 13 Go de différences

$ 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

Même problème ici. Je comprends que 1.13 peut recevoir des commandes de gestion des données, mais en attendant, je veux simplement supprimer en toute sécurité le contenu de ce répertoire sans tuer Docker.

C'est relativement bloquant à ce stade.

Pareil ici. Toujours pas de solution officielle?

J'ai évoqué cela à plusieurs reprises dans (Docker Community) Slack. Chaque fois qu'une poignée de personnes parcourent une liste de scripts / cmds de récupération de place, je devrais exécuter comme solution.

Bien que ceux-ci aient aidé (lire: non résolus - l'espace est toujours en train de devenir plein) dans l'intervalle, je pense que nous pouvons tous convenir que ce n'est pas la solution idéale à long terme.

@jadametz 1.13 a docker system prune .
Au-delà de cela, je ne sais pas comment Docker peut aider (ouvert à suggestion). Les images ne parviennent pas seulement au système d'elles-mêmes, mais plutôt via des extractions, des builds, etc.

En termes de couches orphelines réelles (aucune image sur le système ne les référençant), nous devrons aborder cela séparément.

J'ai exactement le même problème!

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

Pas d'images, de conteneurs ou de volumes. 42 Go dans aufs / diff

Tout ce qui pourrait aider à effacer ce répertoire en toute sécurité serait très utile! J'ai tout essayé dans ce fil sans aucun succès. Merci.

@adamdry uniquement script tiers: https://github.com/docker/docker/issues/22207#issuecomment -252560212

Merci @kayrus, j'ai effectivement essayé cela et cela a légèrement augmenté mon utilisation totale du disque et ne semble pas faire quoi que ce soit au répertoire aufs / diff.

J'ai aussi essayé docker system prune qui n'a pas fonctionné. Et j'ai essayé docker rmi $(docker images -qa -f dangling=true) qui n'a trouvé aucune image à supprimer.

Pour toute personne intéressée, j'utilise maintenant ceci pour nettoyer tous les conteneurs, images, volumes et anciens aufs:

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

Beaucoup d'inspiration tirée d'ici: 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 Il est préférable de ne pas utiliser -f lors de l'exécution de rm / rmi car cela masquera les erreurs de suppression.
Je considère la situation actuelle ... où -f cache une erreur et puis il nous reste un état restant complètement invisible pour l'utilisateur ... comme un bogue.

Je vois également cela sur une installation complètement nouvelle et sans surprise:

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 Vu qu'il s'agit d'une nouvelle installation, voulez-vous essayer ceci? https://github.com/docker/docker/issues/22207#issuecomment -266784433

@adamdry J'ai déjà supprimé /var/lib/docker/aufs car cela bloquait mon travail. Qu'attendez-vous de vos instructions? S'ils empêchent le problème de se reproduire à l'avenir, je peux essayer de recréer le problème et essayer vos instructions. Cependant, si le but est simplement de libérer de l'espace, je l'ai déjà atteint.

@robhaswell Oui, c'était pour libérer de l'espace disque, mais j'avais des problèmes de suivi en essayant de reconstruire mes images, mais en suivant toutes les étapes de ce script, cela a résolu ces problèmes.

Pendant la construction, si le processus de construction est interrompu pendant le processus de construction de la couche (qui contient également un objet blob à copier), suivi de l'arrêt du conteneur, il laisse des données dans / var / lib / docker / aufs / diff /. Il a montré une image suspendue. Le nettoyer aussi n'a pas libéré l'espace. Est-il possible de l'inclure dans le cadre de l'élagage du système docker? Seule la suppression des données blob dans ce dossier libère de l'espace, ce qui, je ne suis pas sûr, causera un problème ou non.

Version Docker: 1.13.0-rc1

Pendant la construction, si le processus de construction est interrompu pendant le processus de construction de la couche (qui contient également un objet blob à copier), suivi de l'arrêt du conteneur, il laisse des données

Cela pourrait aussi être la cause de mes problèmes - j'interromps beaucoup de builds.

Pendant l'extraction de docker, nous avons observé les deux cas suivants:

1. si le processus est interrompu quand il dit download (qui télécharge la couche d'image dans / var / lib / docker / tmp /), il nettoie toutes les données dans ce dossier
2. Si le processus est interrompu quand il dit extraction (ce qui, je suppose, extrait la couche de tmp vers / var / lib / docker / aufs / diff /), il nettoie les données tmp et diff blob à la fois.

Pendant le processus de création d'image,

1. Lors de l'interruption du processus lors de "Envoi du contexte de construction au démon docker" (qui copie les données blob dans mon cas dans / var / lib / docker / tmp /), il y reste pour toujours et ne peut être nettoyé par aucune commande sauf en le supprimant manuellement. Je ne sais pas comment les mises à jour apt get dans l'image sont gérées.
2. Pendant la construction de la couche contenant des données blob, par exemple une grande configuration logicielle, si le processus est interrompu, le conteneur Docker continue de travailler sur l'image. Dans mon cas, seules les données de blob de couche 1, qui sont déjà disponibles dans le dossier tmp, composent l'image entière. Mais, si le conteneur est arrêté à l'aide de la commande docker stop, deux cas se produisent:
   une. si le processus de montage est toujours en cours, il laissera des données dans le dossier tmp et diff.
   b. Si les données sont copiées dans le dossier diff, cela supprimera les données du dossier tmp et laissera les données dans le dossier diff et peut-être dans le dossier de montage.

Nous avons un processus de construction automatisé, qui a besoin d'un contrôle pour arrêter tout processus de construction en douceur. Récemment, un processus a été tué par le noyau en raison d'une erreur de mémoire insuffisante sur une machine dont la configuration était faible.

Si une image doit être construite à partir de 2 couches, 1 couche est construite et la deuxième est interrompue, l'élagage du système Docker semble nettoyer les données du conteneur de couche qui a été interrompu et le conteneur arrêté. Mais il ne nettoie pas les données des couches précédentes en cas d'interruption. De plus, il ne reflétait pas l'espace disque total réclamé. J'ai effectué ces tests sur AWS, ubuntu 14.04, système x86_64 bits avec le système de fichiers aufs. Ran the docker prune test avec docker 1.13.0 rc3 et docker 1.12

@thaJeztah
S'il vous plaît laissez-moi savoir si j'interprète mal quelque chose.

J'ai ouvert un problème pour les fichiers /var/lib/docker/tmp non nettoyés; https://github.com/docker/docker/issues/29486

L'élagage du système Docker semble nettoyer les données du conteneur de couche qui a été interrompu et le conteneur arrêté. Mais il ne nettoie pas les données des couches précédentes en cas d'interruption.

J'ai essayé de reproduire cette situation, mais je n'ai pas pu voir cela avec un cas simple;

Commencez par une installation propre vide /var/lib/docker , créez un gros fichier pour
testing et 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

démarrer docker build , et annuler pendant la construction, mais _après_ la construction
le contexte a été envoyé;

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

vérifier le contenu 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/

exécutez la commande docker system prune pour nettoyer les images, les conteneurs;

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

vérifier le contenu 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/

Je vois que le montage -init est laissé derrière, je vais vérifier si nous pouvons résoudre
ça (bien que ce ne soit qu'un répertoire vide)

La seule différence dans le fichier docker que j'avais utilisé était (pour créer différentes couches)
De zéro
COPY ["./bigfile", "randomNoFile1", /]
COPY ["./bigfile", "randomNoFile2", /]
EOF

Je ne sais pas si cela fait une différence.

Non, le problème ne concerne pas les dossiers init vides. Dans mon cas, c'était te blob. Cependant, je peux le revérifier lundi et le mettre à jour.

En outre, utilisait un fichier de 5 Go, créé en lisant des octets à partir de dev urandom.
Dans votre cas, le même fichier est ajouté 2 fois. Est-ce que cela créerait une seule couche et monterait la deuxième couche à partir de celle-ci ou serait-ce 2 couches séparées? Dans mon cas, c'est toujours 2 couches séparées.

@thaJeztah
Merci pour une réponse aussi rapide sur la question. L'ajout de cette fonctionnalité serait d'une grande aide!

@ monikakatiyar16 J'ai également essayé de reproduire cela en annulant la compilation plusieurs fois pendant les commandes ADD et RUN mais je n'ai rien pu faire fuir vers aufs/diff après la suppression. Je n'arrivais pas à comprendre quel conteneur vous arrêtez car les conteneurs ne devraient pas être en cours d'exécution pendant les opérations ADD/COPY . Si vous pouviez créer un reproducteur que nous pourrions utiliser, ce serait grandement apprécié.

Il est possible que je fasse quelque chose de mal. Puisque je voyage le week-end, je vais le reproduire et mettre à jour toutes les informations requises ici lundi.

@tonistiigi @thaJeztah
Je sens que tu as raison. Il n'y a en fait aucun conteneur répertorié comme actif et en cours d'exécution. Au lieu de cela, il y a des conteneurs morts. L'élagage du système Docker n'a pas fonctionné dans mon cas, peut-être parce que le processus n'a pas été tué avec Ctrl + C. Au lieu de cela, il a continué à fonctionner en arrière-plan. Dans mon cas, ce serait la raison pour laquelle il ne pouvait pas supprimer ces blobs.

Lorsque j'interromps le processus en utilisant Ctrl + C, le processus de construction est tué, mais un processus pour docker-untar reste actif en arrière-plan, ce qui continue de travailler sur la construction de l'image. (Remarque: / var / lib / docker est lié de manière souple à / home / lib / docker pour utiliser les volumes EBS pour des données volumineuses sur AWS)

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

J'ai joint le script que j'avais utilisé pour créer des fichiers volumineux et construire l'image (gc_maxpush_pull.sh)

Également joint le comportement du processus de construction pour créer une image en l'interrompant avec Ctrl + C (DockerBuild_WOProcessKill) et en construisant l'image - en l'interrompant avec Ctrl + C - en tuant le processus (DockerBuild_WithProcessKill)

Utilisation des commandes -

Pour créer un fichier volumineux: ./gc_maxpush_pull.sh 1 5gblayer 0 512 1

Pour créer des images: ./gc_maxpush_pull.sh 1 5gblayer 1 512 1

DockerBuild.zip

Étapes à suivre pour répliquer:

1. Créez un fichier volumineux de 5 Go
2. Démarrez le processus de génération et interrompez-le uniquement après l'envoi du contexte de génération et la copie de l'objet blob.
3. Il termine la construction de l'image après un certain temps et l'affiche dans les images de docker (comme dans le cas 1 joint par moi - DockerBuild_WOProcessKill)
4. Si le processus est tué, cela prend un certain temps et laisse les données blob dans / diff (ce qu'il devrait sur tuer le processus brusquement comme joint dans le fichier - DockerBuild_WithProcessKill)

Si ce que je suppose est correct, cela peut ne pas être un problème avec le pruneau de docker, mais plutôt avec la suppression de la construction de docker qui ne fonctionne pas pour moi.

Existe-t-il un moyen élégant d'interrompre ou d'arrêter le processus de création d'image, qui prend également en charge le nettoyage des données copiées (comme géré dans docker pull)?

Auparavant, je ne tuais pas le processus. Je suis également curieux de savoir ce que fait docker-untar et pourquoi il le monte dans les dossiers / mnt et / diff et nettoie plus tard le dossier / mnt?

Testé avec Docker version 1.12.5, build 7392c3b sur AWS

informations sur le docker
Conteneurs: 2
Course à pied: 0
En pause: 0
Arrêté: 2
Images: 0
Version du serveur: 1.12.5
Pilote de stockage: aufs
Répertoire racine: / home / lib / docker / aufs
Système de fichiers de sauvegarde: extfs
Dirs: 4
Dirperm1 pris en charge: faux
Pilote de journalisation: fichier json
Pilote Cgroup: cgroupfs
Plugins:
Volume: local
Réseau: hôte nul du pont de superposition
Essaim: inactif
Temps d'exécution: runc
Exécution par défaut: runc
Options de sécurité: apparmor
Version du noyau: 3.13.0-105-generic
Système d'exploitation: Ubuntu 14.04.4 LTS
OSType: linux
Architecture: x86_64
Processeurs: 2
Mémoire totale: 3,859 Gio
Nom: maître
ID: 2 NQU: D2C5 : 5 WPL: IIDR : P6FO: OAG7: GHW6: ZJMQ: VDHI : B5CI: XFZJ: ZSZM
Répertoire racine Docker: / home / lib / docker
Mode de débogage (client): faux
Mode de débogage (serveur): faux
Registre: https://index.docker.io/v1/
AVERTISSEMENT: aucune prise en charge de limite de swap
Registres non sécurisés:
127.0.0.0/8

@ monikakatiyar16 Quand je tue manuellement le processus untar pendant la construction, j'obtiens Error processing tar file(signal: killed): dans la sortie de la construction. Laisser le conteneur dans docker ps -a est le comportement correct, la même chose se produit dans toute erreur de construction et vous permet de déboguer les problèmes qui ont causé l'échec de la construction. Je n'ai aucun problème avec la suppression de ce conteneur et si je fais cela, toutes les données de /var/lib/docker/aufs sont également nettoyées.

@tonistiigi Oui, vous avez raison. J'ai pu supprimer le volume associé au conteneur et tout a été nettoyé après avoir tué le processus docker-untar. L'élagage du système Docker fonctionne également dans ce cas.

Le problème réel qui laissait des volumes était le cas, lorsque, sans tuer le processus docker-untar, j'ai essayé de supprimer le conteneur docker avec les volumes - ce qui a donné l'erreur suivante:

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

Journaux du démon:

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

Il semble que l'ordre à suivre actuellement pour interrompre une construction de docker soit:
Interrupt docker build > Kill docker untar process > remove container and volume : docker rm -v -f $(docker ps -a -q)

Pour docker v1.13.0-rc4 , cela peut être Interrupt docker build > Kill docker untar process > docker system prune -a

Cela semble fonctionner parfaitement. Il n'y a aucun problème de nettoyage, mais le seul problème est que le processus docker-untar n'est pas tué avec le processus docker-build.

Je vais rechercher / mettre à jour / enregistrer un nouveau problème pour une interruption gracieuse de la construction de docker qui arrête également le processus docker-untar avec lui.

(Vérifié avec docker v1.12.5 et v1.13.0-rc4)

Mise à jour: lors de la suppression de docker-untar lors de l'envoi du contexte de construction au démon docker, cela donne une erreur dans la construction: Error response from daemon: Error processing tar file(signal: terminated) , mais lors de la copie de couche, ce n'est pas le cas (pour moi)

Merci d'avoir été si patient et d'avoir donné de votre temps!

Je vois que la taille de /var/lib/docker/aufs augmente régulièrement sur un worker en mode essaim de docker. Cette chose est principalement autonome gérée par le gestionnaire d'essaim et très peu de création manuelle de conteneurs à part quelques commandes de maintenance ici et là.

J'exécute docker exec sur les conteneurs de service; je ne sais pas si cela peut être une cause.

Ma solution de contournement pour résoudre ce problème dans mon cas était de démarrer un autre worker, de définir le nœud complet sur --availability=drain et de déplacer manuellement sur quelques montages de volume.

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

Cela a frappé notre serveur CI depuis des lustres. Cela doit être corrigé.

@orf merci

Même problème ici. Ni la suppression des conteneurs, ni les volumes et les images, ni les commandes de nettoyage de Docker 1.13 n'ont d'effet.

Je confirme également que j'ai fait des annulations de création d'image. Peut-être que cela laisse des dossiers qui ne peuvent pas non plus être accessibles.
Je vais utiliser la bonne vieille méthode rm pour le moment, mais c'est clairement un bogue.

Les fichiers du / var / lib / docker / aufs / diff remplissent 100% d'espace pour le système de fichiers / dev / sda1 de 30G

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

Taille du système de fichiers utilisée Utilisation disponible% monté sur
udev 14G 0 14G 0% / dev
tmpfs 2.8G 273M 2.5G 10% / exécution
/ dev / sda1 29G 29G 0100% /
tmpfs 14G 0 14G 0% / dev / shm
tmpfs 5,0M 0 5,0M 0% / exécution / verrouillage
tmpfs 14G 0 14G 0% / sys / fs / cgroup
/ dev / sdb1 197G 60M 187G 1% / mnt
tmpfs 2.8G 0 2.8G 0% / exécution / utilisateur / 1000

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

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

Également essayé, élaguer le système docker , cela n'a pas aidé.

Quelqu'un a-t-il trouvé une solution à ce problème continu de fichiers très volumineux dans diff avant que ce bogue ne soit corrigé dans le code?

Oui, la méthode a déjà été donnée, mais voici un extrait d'apocalypse qui vient de détruire tout ce que je mets en place ici au travail (sauf les dossiers locaux pour les volumes). Pour mettre dans le bashrc ou un autre fichier de configuration bash.

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

func_full-cleanup-docker () {

echo "AVERTISSEMENT: Cela supprimera tout du docker: volumes, conteneurs et images. Oserez-vous? [y / N]"
lire le choix

if [("$ choice" == "y") -o ("$ choice" == "Y")]
ensuite
sudo echo "> vérification des droits sudo [OK]"
taille = 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
} `` `

J'ai exécuté la commande rm -rf pour supprimer les fichiers du dossier diff pour le moment. Il faudra probablement regarder dans le script si le dossier diff occupe à nouveau tout l'espace disque.
J'espère voir ce problème résolu dans le code, au lieu de contourner le problème.

Salut, j'ai le même problème dans docker 1.10.2, j'exécute kubernetes. c'est ma version 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

J'essaie de suivre tous les répertoires diff inutilisés sous /var/lib/docker/aufs/diff et /var/lib/docker/aufs/mnt/ en analysant les fichiers de couches sous /var/lib/docker/image/aufs/imagedb , voici le script que j'ai utilisé:

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

Mais j'ai rencontré un problème lorsque j'arrête et redémarre le démon docker, il semble que je fasse un état incohérent de 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

et lorsque j'essaie de créer de nouveaux conteneurs par docker run , cela a échoué avec le message:

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

et le journal du démon affiche:

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

est-ce que quelqu'un sait si mon approche est correcte ou non? et pourquoi le problème se produit après avoir supprimé ces dossiers?

J'ai ouvert # 31012 pour au moins m'assurer que nous ne divulguons en aucun cas ces répertoires.
Nous devons bien sûr également examiner les différentes causes des erreurs busy

Cela me mordait d'aussi loin que je m'en souvienne. J'ai eu à peu près les mêmes résultats que ceux décrits ci-dessus lorsque je suis passé au pilote overlay2 a quelques jours et que j'ai complètement détruit le dossier aufs ( docker system df dit 1.5Gigs, df dit 15Gigs) .

J'avais environ 1T de diffs en utilisant le stockage. Après avoir redémarré mon démon docker, j'ai récupéré environ 700 Go. Alors j'imagine que le démon les élague?

Le redémarrage ne fait malheureusement rien pour moi.

Le redémarrage du service n'a pas aidé. C'est un problème sérieux. La suppression de tous les conteneurs / images ne supprime pas ces différences.

Arrêter le démon ne les élaguerait pas.

Si vous supprimez tous les conteneurs et que vous avez toujours diff dirs, vous avez probablement des couches rw qui ont fui.

Nous venons de rencontrer ce problème. /var/lib/docker/aufs/diff pris 28G et a porté notre système de fichiers racine à 100%, ce qui a empêché notre serveur GitLab de répondre. Nous utilisons docker pour GitLab CI. Pour résoudre ce problème, j'ai utilisé certaines des commandes @sogetimaitral suggérées ci-dessus pour supprimer les fichiers temporaires, et nous sommes de retour. J'ai redémarré le serveur et envoyé un nouveau commit pour déclencher CI, et tout semble fonctionner comme il se doit.

Je crains vraiment que cela se reproduise. Quel est le problème ici? Est-ce un bogue de docker qui doit être corrigé?

1. Oui, il y a un bogue (à la fois qu'il y a des problèmes de suppression et que --force on rm ignore ces problèmes)
2. En général, il ne faut pas écrire beaucoup de données dans le conteneur fs et utiliser à la place un volume (même un volume jetable). Un grand diff dir indiquerait que des quantités importantes de données sont écrites dans le conteneur fs.

Si vous n'utilisez pas "--force" lors de la suppression, vous ne rencontreriez pas ce problème (ou du moins vous verriez que vous avez un tas de conteneurs "morts" et que vous savez comment / quoi nettoyer.).

Je n'utilise pas du tout manuellement docker. Nous utilisons gitlab-ci-multi-runner . Serait-ce alors un bogue du côté de GitLab?

Il ressemble (par défaut) à la suppression forcée des conteneurs; https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/dbdbce2848530df299836768c8ea01e209a2fe40/executors/docker/executor_docker.go#L878. Cela peut entraîner des échecs de suppression du conteneur ignorés et conduire à des différences orphelines.

Ok, alors cela me dit qu'il s'agit d'un bogue gitlab-ci-multi-runner. Est-ce une interprétation correcte? Je suis heureux de créer un problème pour qu'ils résolvent ce problème.

C'est une combinaison je suppose; "force" remove facilite la gestion des nettoyages (c'est-à-dire les cas où un conteneur n'est pas encore arrêté, etc.), en même temps (c'est le "bug" @ cpuguy83 mentionné), il peut également masquer des problèmes réels, tels que docker n'a pas réussi à supprimer le système de fichiers des conteneurs (ce qui peut avoir diverses raisons). Avec "force", le conteneur est retiré dans de tels cas. Sans, le conteneur est laissé (mais marqué "mort")

Si le runner gitlab peut fonctionner correctement sans la suppression forcée, ce sera probablement bon de le changer (ou de le rendre configurable)

J'utilise Drone et j'ai le même problème. Je n'ai pas vérifié le code de la suppression des conteneurs, mais je suppose que cela force également la suppression.

Cela pourrait-il être un problème de Docker dans Docker? Je démarre Drone avec docker-compose.

J'ai décidé d'aller de l'avant et de soumettre un problème gitlab-ci-multi-runner juste pour boucler les devs dans: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

Honnêtement, nous avons contourné ce problème en exécutant le docker gc de Spotify avec le drone CI.

El El mar, mar. 28, 2017 à 15h38, Geoffrey Fairchild <
[email protected]> escribió:

J'ai décidé d'aller de l'avant et de soumettre un problème gitlab-ci-multi-runner juste pour
boucle les devs dans:
https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/docker/docker/issues/22207#issuecomment-289926298 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AC6Wz197zkjWWOlq1-JOibiQP-xJym9Eks5rqYvegaJpZM4IMGt2
.

@sedouard Merci pour cette astuce! L'exécution de docker-gc toutes les heures depuis Spotify a résolu le problème pour moi.

Nous obtenons ce problème en cours d'exécution à partir de Gitlab CI (ne fonctionnant pas dans docker), en utilisant des commandes pour créer des images / exécuter des conteneurs (pas l'intégration de Gitlab CI Docker). Nous n'utilisons aucune forme de suppression de force, simplement docker run --rm ... et docker rmi image:tag

EDIT : désolé, en fait le problème d'origine est le même. La différence est que l'exécution de spotify/docker-gc ne résout _pas_ le problème.

Comme vous pouvez le voir ci-dessous, j'ai 0 images, 0 conteneurs, rien!
docker system info est d'accord avec moi, mais mentionne Dirs: 38 pour le stockage aufs.

C'est suspect! Si vous regardez /var/lib/docker/aufs/diff/ , nous voyons qu'il y a en fait 1,7 Go de données, plus de 41 répertoires. Et c'est ma boîte personnelle, sur le serveur de production, c'est 19 Go.

Comment nettoyons-nous cela? l'utilisation de spotify/docker-gc ne les supprime pas.

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

Puis-je en toute sécurité rm -r /var/lib/docker/aufs et redémarrer le docker deamon?

Lancer spotify/docker-gc ne nettoie pas ces orphelins.

EDIT : merci @CVTJNII!

Arrêter le démon Docker et effacer tout / var / lib / docker sera plus sûr. Effacer / var / lib / docker / aufs vous fera perdre vos images de toute façon, il est donc préférable de commencer avec un clean / var / lib / docker à mon avis. C'est la "solution" que j'utilise depuis plusieurs mois pour résoudre ce problème.

À partir de 17.06, il ne devrait plus y avoir de nouvelles différences orphelines.
Au lieu de cela, vous pouvez commencer à voir des conteneurs avec l'état Dead , cela se produit s'il y a eu une erreur lors de la suppression qui n'est pas récupérable et peut nécessiter un administrateur pour la traiter.

De plus, la suppression est un peu plus robuste et moins sujette aux erreurs dues à des conditions de concurrence ou à des montages échoués.

@ cpuguy83 : bonne nouvelle, pouvez-vous expliquer ce que l'administrateur devrait faire si cela se produit?

@Silex Cela dépend de la cause.
Typiquement, ce qui s'est passé, c'est qu'il y a une erreur device or resource busy due à une fuite d'une monture dans un conteneur. Si vous exécutez quelque chose comme cadvisor, c'est à peu près une garantie, comme le disent les instructions, de monter tout le répertoire docker dans le conteneur cadvisor.

Cela peut être délicat, vous devrez peut-être arrêter le ou les conteneurs incriminés, puis supprimer le conteneur dead .

Si vous êtes sur un noyau plus récent (3.15+), il est peu probable que vous voyiez plus le problème, bien qu'il puisse toujours y avoir des cas extrêmes.

Docker version 17.06.0-ce, build 02c1d87

J'ai essayé de supprimer toutes les images, volumes, réseaux et conteneurs, mais cela n'a pas aidé.
Également essayé les commandes:

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

Restent encore des fichiers:

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

Comment peut-il être supprimé?

@ haos616 essayez d'abord d'arrêter tous les conteneurs en cours d'exécution, puis exécutez docker system prune -af .
Cela a fait l'affaire pour moi.
Cela n'a pas fonctionné pendant que j'avais un conteneur en marche.

S'il s'agit d'une mise à niveau d'une version précédente de docker, il est possible que ces différences aient été générées / laissées par cette version. Docker 17.06 ne supprimera pas un conteneur si les couches n'ont pas été supprimées (lors de l'utilisation de --force); les anciennes versions l'ont fait, ce qui pourrait conduire à des couches orphelines

@ julian-pani Je l'ai fait au début mais cela n'aide pas.

# 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 Non. J'ai nettoyé le Docker il y a un ou deux mois. Ensuite, la version était déjà 17.06. J'ai utilisé la commande docker system prune -af . Il a tout enlevé.

Exécuter https://github.com/spotify/docker-gc en tant que conteneur a fonctionné pour moi, mais cela a fait un pas de plus et a également supprimé certaines de mes images requises :(

J'ai donc mis un petit script wrapper comme ci-dessous pour être sûr

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

merci encore à spotify

IIUC, le script spotify appelle simplement docker rm et docker rmi - a-t-il réellement supprimé les différences orphelines?

Juste quelques commentaires pour la communauté, j'ai lu tout cela et aucune des solutions ne semble fonctionner de manière cohérente ou fiable. Ma «solution» consistait simplement à doubler la quantité d'espace disque sur mes instances AWS. Et je sais trop bien que c'est une solution de merde, mais c'est la meilleure solution de contournement que j'ai trouvée aux aufs gonflés de Docker. Cela doit vraiment, vraiment être corrigé.

@fuzzygroup 17.06 ne devrait plus créer de diffs orphelins, mais il ne nettoiera pas encore les anciens.

Je pourrais nettoyer avec ce script. Je ne vois pas pourquoi cela ne fonctionnerait pas, mais qui sait.
Quoi qu'il en soit, ça marche bien pour moi. Il supprimera toutes les images, conteneurs et volumes ... Comme il ne devrait pas fonctionner très souvent, je trouve que c'est un effet secondaire mineur. Mais c'est à vous de l'utiliser ou non.

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

https://stackoverflow.com/q/45798076/562769 semble être lié. J'ai publié une solution rapide.

FYI, toujours en train de voir ceci avec 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 contient de nombreux répertoires avec le préfixe -init-removing et -removing :

ffd5477de24b0d9993724e40175185038a62250861516030a33280898243e742-removing
ffd900de0634992e99c022a16775805dfd0ffd1f6c89fece7deb6b1a71c5e38c-init-removing
ffd900de0634992e99c022a16775805dfd0ffd1f6c89fece7deb6b1a71c5e38c-removing

FYI, toujours en train de voir cela avec 17.06.1-ce

Tu vois toujours quoi, exactement?
Il ne devrait y avoir aucun moyen qu'un répertoire diff puisse fuir, bien que les répertoires diff existent toujours s'ils existaient lors de la mise à niveau, ils existeront toujours.

Je vois toujours des différences orphelines pour autant que je sache. docker system prune ne les a pas supprimés, ni docker-gc . L'exécution manuelle de rm -rf /var/lib/docker/aufs/diff/*-removing semble fonctionner.

Oui, docker ne nettoiera pas encore les anciens répertoires orphelins.

Par ancien, vous entendez ceux créés à partir d'une version précédente de docker avec ce problème?

Il s'agit d'une nouvelle installation de Docker que nous avons faite il y a environ deux semaines, ces orphelins ont dû être créés depuis lors, il semble donc que docker doit toujours créer ces orphelins?

Je veux dire, dans la dernière demi-heure, j'ai eu 112 nouveaux diffs avec -removing , puisque je les ai modifiés manuellement.

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

Vous avez dit "17.06 ne devrait plus créer des différences orphelines, mais il ne nettoiera pas encore les anciens." Ceux marqués avec -removing ne sont-ils pas orphelins?

@orf Sur un noyau plus récent, il est très inattendu d'avoir un problème lors de la suppression. Montez-vous /var/lib/docker dans un conteneur?

Je vais vérifier dans le pilote aufs pour voir s'il y a un problème spécifique avec le signalement d'une suppression réussie alors que ce n'était vraiment pas le cas.

Nous ne montons pas /var/lib/docker dans un conteneur.

$ 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

Nous utilisons 14.04 LTS

Faites-moi savoir s'il y a quelque chose que je peux fournir pour vous aider à déboguer cela.

Pour d'autres raisons (mise en réseau en mode essaim), j'ai quitté le 14.04 pour Docker
Machines.
Le lundi 21 août 2017 à 8h23, orf [email protected] a écrit:

Nous ne montons pas / var / lib / docker dans un conteneur.

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

Nous utilisons 14.04 LTS

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/moby/moby/issues/22207#issuecomment-323773033 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AADRIfE2B2HNpbsKyTOj1CwGzulRT2C0ks5saaDPgaJpZM4IMGt2
.

Cela semble être pire avec 17.06.01-ce. J'ai mis à jour une machine de construction vers cette version et j'ai immédiatement commencé à voir les répertoires *-init-removing et *-removing laissés dans le cadre du processus de construction. J'ai arrêté le service, supprimé le répertoire /var/lib/docker , redémarré le service et, après quelques versions, j'étais à nouveau proche de l'espace disque. J'ai de nouveau arrêté le service, exécuté apt-get purge docker-ce , supprimé /var/lib/docker et installé la version 17.06.0-ce. Ne pas obtenir les répertoires supplémentaires dans /var/lib/docker/aufs/diff et l'espace disque est représentatif des images qui se trouvent sur la machine de construction. J'ai également reproduit le comportement sur ma machine de développement - la simple création d'une image semble créer ces répertoires supplémentaires pour chaque couche de l'image, de sorte que je manquerais d'espace disque très rapidement. Encore une fois, revenir à 17.06.0-ce ne semble pas avoir de problème, donc je vais y rester pour le moment.

@mmanderson Merci d'avoir signalé. Jetez un œil aux changements dans le pilote AUFS.

@mmanderson Avez-vous des conteneurs dans l'état Dead dans docker ps -a ?

Tous mes serveurs de build docker manquent d'espace.

J'ai effectué une mise à niveau au cours de la dernière semaine environ vers la version 17.06.1-ce de Docker, build 874a737. Je pense que rien d’autre n’a changé et que ce problème est apparu ou s’est manifesté dans le cadre du processus de mise à niveau. Le répertoire aufs diff est massif et j'ai déjà élagué toutes les images et les volumes en suspens.

issue-22207.txt
@ cpuguy83 Aucun conteneur dans aucun état. Voici ce que j'ai à peine fait pour le démontrer avec 17.06.01-ce:

1. Démarré avec une nouvelle installation de docker 17.06.01-ce sur Ubuntu 16.04.03 LTS (ie docker non installé et pas de répertoire / var / lib / docker). Après l'installation, un répertoire vide / var / lib / docker / aufs / diff est vérifié.
2. Ran une construction de docker avec un dockerfile assez simple basé sur ubuntu: latest - tout ce qu'il fait est de tirer statsd_exporter de github et de l'extraire dans / usr / bin (voir le fichier joint).
3. Après avoir exécuté la compilation, exécutez docker ps -a pour n'afficher aucun conteneur dans aucun état. Il y a plusieurs dossiers *-remaining dans le dossier /var/lib/docker/aufs/diff .
4. Exécutez docker system df pour vérifier les images, le conteneur et les volumes. Le résultat est

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. Running du -sch /var/lib/docker/*/ montre 152 millions de /var/lib/docker/aufs/ pour
2. Exécutez docker rmi $(docker images -q) pour supprimer les calques d'image créés. Lancer docker system df après cela montre tous les zéros. L'exécution de du -sch /var/lib/docker/*/ montre 152 millions de /var/lib/docker/aufs/ pour *-remaining pour tous les dossiers qui n'en avaient pas auparavant, ainsi que les dossiers *-remaining existants qui Sont toujours là.

@erikh est-ce le problème que vous rencontrez?

@ cpuguy83 Après avoir désinstallé 17.06.01-ce, supprimé le répertoire / var / lib / docker et installé 17.06.0-ce, j'essaye d'exécuter la même compilation. La construction échoue à cause du bogue ADD from remote URL's qui a été corrigé dans 17.06.01. Cependant, je n'obtiens aucun répertoire *-remaining pour les étapes qui se terminent et après avoir tout nettoyé avec docker system prune et docker rmi $(docker image -q) le répertoire /var/lib/docker/aufs/diff est à nouveau vide et l'espace est libéré.

Merci à tous, c'est une régression en 17.06.1 ...
PR à corriger est ici: https://github.com/moby/moby/pull/34587

génial, merci pour le patch rapide @ cpuguy83! / cc @erikh

@rogaha! oui, merci à vous et @ cpuguy83!

Merci beaucoup @Karreg pour votre excellent script . Après avoir éliminé tous les anciens diffs ophaned et libéré d'énormes quantités d'espace disque perdu, nous l'utilisons maintenant régulièrement pour nettoyer nos machines virtuelles avant d'installer de nouvelles images de docker. Une aide précieuse et une solution de contournement presque parfaite pour ce problème maintenant. @ TP75

On dirait que Docker, Inc. a des contrats avec des fabricants de stockage de données informatiques.

Le script de @Karreg a bien fonctionné pour moi et j'ai libéré tout l'espace dans le répertoire diffs.

Avoir le même problème.
Détails de l'hôte Docker

root @ UbuntuCont : ~ # informations sur le docker
Conteneurs: 3
Course à pied: 0
En pause: 0
Arrêté: 3
Images: 4
Version du serveur: 17.06.1-ce
Pilote de stockage: aufs
Répertoire racine: / var / lib / docker / aufs
Système de fichiers de sauvegarde: extfs
Dirs: 14
Dirperm1 pris en charge: vrai
Pilote de journalisation: fichier json
Pilote Cgroup: cgroupfs
Plugins:
Volume: local
Réseau: superposition nulle de l'hôte de pont macvlan
Journal: awslogs fluentd gcplogs gelf journald fichier json entrées de journal splunk syslog
Essaim: inactif
Temps d'exécution: runc
Exécution par défaut: runc
Init Binaire: docker-init
version containerd: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
version runc: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
version initiale: 949e6fa
Options de sécurité:
apparmeur
seccomp
Profil: par défaut
Version du noyau: 4.4.0-93-generic
Système d'exploitation: Ubuntu 16.04.3 LTS
OSType: linux
Architecture: x86_64
Processeurs: 1
Mémoire totale: 3,358 Go
Nom: UbuntuCont
ID: QQA5: DC5S: C2FL: LCC6: XY6E: V3FR: TRW3: VMOQ: QQKD : AP2M: H3JA: I6VX
Répertoire racine Docker: / var / lib / docker
Mode de débogage (client): faux
Mode de débogage (serveur): faux
Registre: https://index.docker.io/v1/
Expérimental: faux
Registres non sécurisés:
127.0.0.0/8
Restauration en direct activée: faux

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

@kasunsjc, veuillez lire les messages juste au-dessus du vôtre.

Je confirme que la mise à niveau vers 17.06.2-ce a résolu ce problème. Je n'ai pas non plus eu à manuellement les répertoires (la dernière fois) après la mise à niveau.

17.06.2-ce _ semble_ avoir corrigé cela pour moi aussi. Plus -removing répertoires

Je suppose que les répertoires -init j'ai dans aufs/diff sont pas liés (certains d'entre eux sont assez anciens). Ils sont tous petits, cependant, cela n'a guère d'importance.

La mise à jour vers 17.07.0 a résolu le problème ici aussi, même docker system prune --all -f ne supprimait pas les répertoires avant mais après la mise à niveau, ils étaient automatiquement supprimés au redémarrage.

La confirmation de ce problème a été résolu sur Ubuntu 16.04 avec 17.06.2-ce. Dès qu'il a été mis à jour, l'espace s'est dégagé.