PeterB Posted October 23, 2014 Share Posted October 23, 2014 For the second time in two weeks, all my docker containers have gone missing after a powercut. Dockerman shows no entries in the top 'Containers' section. When I try to re-add from the 'my-container_name, I get the following error message: root@localhost:# /usr/bin/docker run -d --name="MariaDB" --net="bridge" -e TZ="Asia/Singapore" -p 3306:3306/tcp -v "/mnt/user/mysql/":"/db":rw needo/mariadb 0e2bbfe74da7011beac243f202d8b4bf0924885fb59e970a7b55f8c665e0d9c5 2014/10/23 17:53:44 Error response from daemon: Cannot start container 0e2bbfe74da7011beac243f202d8b4bf0924885fb59e970a7b55f8c665e0d9c5: Cannot find child for /MariaDB The command failed. I can post a system log, but I don't see anything obvious in there. Is there anywhere else I should be looking for docker log messages? If I enter the command from the dockerman message window: /usr/bin/docker run -d --name="MariaDB" --net="bridge" -e TZ="Asia/Singapore" -p 3306:3306/tcp -v "/mnt/user/mysql/":"/db":rw needo/mariadb then the container does show up in the dockerman window, but without a name, and not running. If I click the 'Start' button. there is some text activity at the bottom of the window, but the container doesn't start, and the 'Status/Log' shows 'None', while 'Status' shows 'N/A'. Can anyone advise on debugging this problem? Even though these 'nameless' containers are displayed by dockerman, they do not show in a 'docker ps' command. If I try to remove these nameless containers with DockerMan, I get the following output: root@localhost:# /usr/bin/docker rm -f Usage: docker rm [OPTIONS] CONTAINER [CONTAINER...] Remove one or more containers -f, --force=false Force the removal of a running container (uses SIGKILL) -l, --link=false Remove the specified link and not the underlying container -v, --volumes=false Remove the volumes associated with the container The command failed. Sometimes when I attempt to start one of these missing containers, I get the following error reported: 2014/10/23 18:15:08 Error response from daemon: Insertion failed because database is full: database or disk is full I'm not sure what database or disk this message is referring to. Eventually, after much playing with 'docker' commands I eventually get my containers running again - but I wish I knew what was causing this problem, and how to stop it occuring. It would also be helpful to know what is the correct way to restore everything when the problem does occur. One oddity I've just noticed: docker images shows the following: root@Tower:~# docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE binhex/arch-deluge latest 4371e7493f88 9 days ago 1.124 GB binhex/arch-minidlna latest f5def0f3c425 9 days ago 950.3 MB binhex/arch-couchpotato latest 7dd9988affce 9 days ago 985.9 MB archlinux-minidlna latest 83e46175366f 6 weeks ago 620.7 MB archlinux/update latest a5a5fbe589dc 6 weeks ago 438.8 MB gfjardim/logitechmediaserver latest 9ea52a152291 6 weeks ago 882.5 MB phusion/baseimage 0.9.13 bc840bd687e3 8 weeks ago 411.8 MB phusion/baseimage latest bc840bd687e3 8 weeks ago 411.8 MB base/archlinux 2014.07.03 ea234cde99e6 3 months ago 282.9 MB base/archlinux 2014.04.01 56c61f5c2920 3 months ago 293.3 MB base/archlinux latest dce0559daa1b 3 months ago 282.9 MB needo/mariadb latest 566c91aa7b1e 3 months ago 590.6 MB root@Tower:~# ... twelve images listed. Yet docker info shows: root@Tower:~# docker info Containers: 6 Images: 92 Storage Driver: btrfs Execution Driver: native-0.2 Kernel Version: 3.16.3-unRAID Operating System: Slackware 14.1 root@Tower:~# ... 92 images??? Where did they come from, and why aren't they listed by the docker images command. How do I get rid of them? Similarly, docker info reports six containers, yet docker ps only shows the two which have names of the total six listed by DockerMan. Is it possible that DockerMan is creating new images everytime the system restarts? Might those be filling the btrfs loopback device? I've just stopped docker, extended the docker.img from 25 to 30GB. Now I can re-add the containers from the my-* entries. However, the containers now start with silly names, eg distracted_fermi, pensive_mestorf ... Quote Link to comment
binhex Posted October 23, 2014 Share Posted October 23, 2014 Hi Peter quick couple of points you can view ALL containers using docker ps -a the silly names are due to docker thinking you didn't specify a name for the container and thus it generates one for you. Quote Link to comment
binhex Posted October 23, 2014 Share Posted October 23, 2014 In the short term you can backup your IMG file, just stop docker using ui before you do so then restore it if you get issues Quote Link to comment
binhex Posted October 23, 2014 Share Posted October 23, 2014 92 images at a guess are probably the layers for each image Quote Link to comment
binhex Posted October 23, 2014 Share Posted October 23, 2014 An interesting post, maybe your not alone http://lime-technology.com/forum/index.php?topic=35929.0 Quote Link to comment
PeterB Posted October 23, 2014 Author Share Posted October 23, 2014 Hi Peter quick couple of points you can view ALL containers using docker ps -a the silly names are due to docker thinking you didn't specify a name for the container and thus it generates one for you. Okay, well ps -a only lists my five active comtainers. Following that, I tried images -a and that lists a whole raft of images - mostly unnamed. root@Tower:~# docker images -a REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE binhex/arch-deluge latest 4371e7493f88 10 days ago 1.124 GB <none> <none> e7f624569566 10 days ago 1.124 GB <none> <none> 3d3a7c14471b 10 days ago 1.124 GB <none> <none> bc2b99be8723 10 days ago 1.124 GB <none> <none> 847aee0b7d36 10 days ago 1.124 GB <none> <none> 6d667a155803 10 days ago 1.124 GB <none> <none> 0fc2b25d8fd3 10 days ago 1.124 GB <none> <none> 6959ba7d8734 10 days ago 1.124 GB <none> <none> f5def0f3c425 10 days ago 950.3 MB <none> <none> 33b14c7b83f4 10 days ago 950.3 MB <none> <none> ac3dd770621e 10 days ago 950.3 MB <none> <none> c31e297ed434 10 days ago 950.3 MB binhex/arch-couchpotato latest 7dd9988affce 10 days ago 985.9 MB <none> <none> 37fe89ca4311 10 days ago 985.9 MB <none> <none> 796d65feaed5 10 days ago 985.9 MB <none> <none> de7297ba1b9a 10 days ago 985.9 MB <none> <none> c83197f95dde 10 days ago 985.9 MB <none> <none> 4d7573216a55 10 days ago 985.9 MB <none> <none> a2cd9596b615 10 days ago 670.4 MB <none> <none> 04f19be08c97 10 days ago 670.4 MB <none> <none> 751bf43d0ac8 10 days ago 670.4 MB <none> <none> c80b32754920 10 days ago 670.4 MB <none> <none> 35de85633ce8 10 days ago 670.4 MB <none> <none> 2d071adbff87 10 days ago 670.4 MB <none> <none> 3fa6acd3a09b 10 days ago 670.4 MB <none> <none> c4a6220304cf 10 days ago 670.4 MB <none> <none> ca249e062aba 10 days ago 670.4 MB <none> <none> 945a8f4ddfee 10 days ago 670.4 MB <none> <none> be0c39494b67 10 days ago 670.4 MB <none> <none> 78fd09e4ab8a 10 days ago 670.4 MB <none> <none> 4abfd0ffcf56 10 days ago 282.9 MB archlinux-minidlna latest 83e46175366f 6 weeks ago 620.7 MB archlinux/update latest a5a5fbe589dc 6 weeks ago 438.8 MB gfjardim/logitechmediaserver latest 9ea52a152291 6 weeks ago 882.5 MB <none> <none> 264c797efbd6 6 weeks ago 882.5 MB <none> <none> 7083cccf9410 6 weeks ago 882.5 MB <none> <none> 1885aab59a73 6 weeks ago 882.5 MB <none> <none> 22d8accc7466 6 weeks ago 882.5 MB <none> <none> 8b8e27d4ab9d 6 weeks ago 882.5 MB <none> <none> 139730af9d31 6 weeks ago 882.5 MB <none> <none> 56a5f1224e35 6 weeks ago 882.5 MB <none> <none> eb5ecb019744 6 weeks ago 590.6 MB <none> <none> b97ee6c89486 6 weeks ago 471.7 MB <none> <none> 8b9f05fd773c 6 weeks ago 471.7 MB <none> <none> d1f85dd2812a 6 weeks ago 470 MB <none> <none> 2a49b33066a3 6 weeks ago 391.1 MB <none> <none> fb9309dfbeef 6 weeks ago 391.1 MB <none> <none> 5d6c978b5f70 6 weeks ago 391.1 MB <none> <none> c84da966b728 6 weeks ago 391 MB <none> <none> e0b30803a309 6 weeks ago 391 MB <none> <none> 6506d5658a8c 6 weeks ago 391 MB <none> <none> 8ff7325794df 6 weeks ago 391 MB <none> <none> ed61bf5a8b91 6 weeks ago 391 MB <none> <none> 73735a4b9ab9 6 weeks ago 391 MB <none> <none> d7479b4401f9 6 weeks ago 391 MB phusion/baseimage 0.9.13 bc840bd687e3 8 weeks ago 411.8 MB phusion/baseimage latest bc840bd687e3 8 weeks ago 411.8 MB <none> <none> fda076a542f2 8 weeks ago 411.8 MB <none> <none> 6220a87c91ac 8 weeks ago 266 MB base/archlinux 2014.07.03 ea234cde99e6 3 months ago 282.9 MB <none> <none> b7d6e7c1e21a 3 months ago 0 B base/archlinux 2014.04.01 56c61f5c2920 3 months ago 293.3 MB <none> <none> 23255e5de05e 3 months ago 0 B base/archlinux latest dce0559daa1b 3 months ago 282.9 MB <none> <none> 9b0516337e5a 3 months ago 0 B needo/mariadb latest 566c91aa7b1e 3 months ago 590.6 MB <none> <none> fede856341ad 3 months ago 590.6 MB <none> <none> 864b9f0054e7 3 months ago 590.6 MB <none> <none> 23c87de41786 3 months ago 590.6 MB <none> <none> 5d7fe409bfe4 3 months ago 590.6 MB <none> <none> da7bfdf0e1b6 3 months ago 590.6 MB <none> <none> 6470f811e73f 3 months ago 590.6 MB <none> <none> 594f8b77e732 3 months ago 590.6 MB <none> <none> 9243c9adab8b 3 months ago 590.6 MB <none> <none> ee0b1941d320 3 months ago 590.6 MB <none> <none> 4fe585a340e7 3 months ago 590.6 MB <none> <none> 31bfb552afaf 3 months ago 468.4 MB <none> <none> 56b9543fe345 3 months ago 391 MB <none> <none> 776eac27ad9d 3 months ago 391 MB <none> <none> 4132f6005419 3 months ago 391 MB <none> <none> 7418ba5f7369 3 months ago 391 MB <none> <none> 30867c4ff0fd 3 months ago 391 MB <none> <none> dabfc8a44cb5 4 months ago 391 MB <none> <none> 37fd06241067 4 months ago 391 MB <none> <none> 68bde466ffab 4 months ago 266 MB <none> <none> 5cbfee875b7b 5 months ago 266 MB <none> <none> afc7fc2f17c1 5 months ago 266 MB <none> <none> 82c9a6741336 5 months ago 266 MB <none> <none> 99ec81b80c55 6 months ago 266 MB <none> <none> 4d26dd3ebc1c 6 months ago 192.7 MB <none> <none> d4010efcfd86 6 months ago 192.7 MB <none> <none> 5e66087f3ffe 6 months ago 192.5 MB <none> <none> 511136ea3c5a 16 months ago 0 B root@Tower:~# Interestingly, my minidlna container is now shown as using an image which doesn't have a name! What is very puzzling is the fact that I've had to increase my btrfs partition from 15GB to 30GB in the last three weeks, simply in order to get my five comtainers running again. In that time I've not added any new containers, but there may have been a few upgrades. I will try deleting some of the unidentifyable images and see what happens. Quote Link to comment
eroz Posted October 23, 2014 Share Posted October 23, 2014 You can run this docker rm $(docker ps -aq) to remove all containers. And then docker rmi $(docker images -a | grep "^<none>" | awk '{print $3}') to remove all empty/untagged images. And then try again. Quote Link to comment
PeterB Posted October 24, 2014 Author Share Posted October 24, 2014 Thanks for the response. You can run this docker rm $(docker ps -aq) to remove all containers. Okay, this worked. All containers are gone. And then docker rmi $(docker images -a | grep "^<none>" | awk '{print $3}') to remove all empty/untagged images. And then try again. This didn't do a lot: root@Tower:~# docker rmi $(docker images -a | grep "^<none>" | awk '{print $3}') Error response from daemon: Conflict, e7f624569566 wasn't deleted Error response from daemon: Conflict, 3d3a7c14471b wasn't deleted Error response from daemon: Conflict, bc2b99be8723 wasn't deleted Error response from daemon: Conflict, 847aee0b7d36 wasn't deleted Error response from daemon: Conflict, 6d667a155803 wasn't deleted Error response from daemon: Conflict, 0fc2b25d8fd3 wasn't deleted Error response from daemon: Conflict, 6959ba7d8734 wasn't deleted Error response from daemon: Conflict, 37fe89ca4311 wasn't deleted Error response from daemon: Conflict, 796d65feaed5 wasn't deleted Error response from daemon: Conflict, de7297ba1b9a wasn't deleted Error response from daemon: Conflict, c83197f95dde wasn't deleted Error response from daemon: Conflict, 4d7573216a55 wasn't deleted Error response from daemon: Conflict, c80b32754920 wasn't deleted Error response from daemon: Conflict, 35de85633ce8 wasn't deleted Error response from daemon: Conflict, 2d071adbff87 wasn't deleted Error response from daemon: Conflict, 3fa6acd3a09b wasn't deleted Error response from daemon: Conflict, c4a6220304cf wasn't deleted Error response from daemon: Conflict, ca249e062aba wasn't deleted Error response from daemon: Conflict, 945a8f4ddfee wasn't deleted Error response from daemon: Conflict, be0c39494b67 wasn't deleted Error response from daemon: Conflict, 78fd09e4ab8a wasn't deleted Error response from daemon: Conflict, 4abfd0ffcf56 wasn't deleted Error response from daemon: Conflict, 264c797efbd6 wasn't deleted Error response from daemon: Conflict, 7083cccf9410 wasn't deleted Error response from daemon: Conflict, 1885aab59a73 wasn't deleted Error response from daemon: Conflict, 22d8accc7466 wasn't deleted Error response from daemon: Conflict, 8b8e27d4ab9d wasn't deleted Error response from daemon: Conflict, 139730af9d31 wasn't deleted Error response from daemon: Conflict, 56a5f1224e35 wasn't deleted Error response from daemon: Conflict, eb5ecb019744 wasn't deleted Error response from daemon: Conflict, b97ee6c89486 wasn't deleted Error response from daemon: Conflict, 8b9f05fd773c wasn't deleted Error response from daemon: Conflict, d1f85dd2812a wasn't deleted Error response from daemon: Conflict, 2a49b33066a3 wasn't deleted Error response from daemon: Conflict, fb9309dfbeef wasn't deleted Error response from daemon: Conflict, 5d6c978b5f70 wasn't deleted Error response from daemon: Conflict, c84da966b728 wasn't deleted Error response from daemon: Conflict, e0b30803a309 wasn't deleted Error response from daemon: Conflict, 6506d5658a8c wasn't deleted Error response from daemon: Conflict, 8ff7325794df wasn't deleted Error response from daemon: Conflict, ed61bf5a8b91 wasn't deleted Error response from daemon: Conflict, 73735a4b9ab9 wasn't deleted Error response from daemon: Conflict, d7479b4401f9 wasn't deleted Error response from daemon: Conflict, fda076a542f2 wasn't deleted Error response from daemon: Conflict, 6220a87c91ac wasn't deleted Error response from daemon: Conflict, b7d6e7c1e21a wasn't deleted Error response from daemon: Conflict, 23255e5de05e wasn't deleted Error response from daemon: Conflict, 9b0516337e5a wasn't deleted Error response from daemon: Conflict, fede856341ad wasn't deleted Error response from daemon: Conflict, 864b9f0054e7 wasn't deleted Error response from daemon: Conflict, 23c87de41786 wasn't deleted Error response from daemon: Conflict, 5d7fe409bfe4 wasn't deleted Error response from daemon: Conflict, da7bfdf0e1b6 wasn't deleted Error response from daemon: Conflict, 6470f811e73f wasn't deleted Error response from daemon: Conflict, 594f8b77e732 wasn't deleted Error response from daemon: Conflict, 9243c9adab8b wasn't deleted Error response from daemon: Conflict, ee0b1941d320 wasn't deleted Error response from daemon: Conflict, 4fe585a340e7 wasn't deleted Error response from daemon: Conflict, 31bfb552afaf wasn't deleted Error response from daemon: Conflict, 56b9543fe345 wasn't deleted Error response from daemon: Conflict, 776eac27ad9d wasn't deleted Error response from daemon: Conflict, 4132f6005419 wasn't deleted Error response from daemon: Conflict, 7418ba5f7369 wasn't deleted Error response from daemon: Conflict, 30867c4ff0fd wasn't deleted Error response from daemon: Conflict, dabfc8a44cb5 wasn't deleted Error response from daemon: Conflict, 37fd06241067 wasn't deleted Error response from daemon: Conflict, 68bde466ffab wasn't deleted Error response from daemon: Conflict, 5cbfee875b7b wasn't deleted Error response from daemon: Conflict, afc7fc2f17c1 wasn't deleted Error response from daemon: Conflict, 82c9a6741336 wasn't deleted Error response from daemon: Conflict, 99ec81b80c55 wasn't deleted Error response from daemon: Conflict, d4010efcfd86 wasn't deleted Error response from daemon: Conflict, 4d26dd3ebc1c wasn't deleted Error response from daemon: Conflict, 5e66087f3ffe wasn't deleted Error response from daemon: Conflict, 511136ea3c5a wasn't deleted 2014/10/24 08:58:14 Error: failed to remove one or more images root@Tower:~# Quote Link to comment
eroz Posted October 24, 2014 Share Posted October 24, 2014 Thanks for the response. You can run this docker rm $(docker ps -aq) to remove all containers. Okay, this worked. All containers are gone. And then docker rmi $(docker images -a | grep "^<none>" | awk '{print $3}') to remove all empty/untagged images. And then try again. This didn't do a lot: root@Tower:~# docker rmi $(docker images -a | grep "^<none>" | awk '{print $3}') Error response from daemon: Conflict, e7f624569566 wasn't deleted Error response from daemon: Conflict, 3d3a7c14471b wasn't deleted Error response from daemon: Conflict, bc2b99be8723 wasn't deleted Error response from daemon: Conflict, 847aee0b7d36 wasn't deleted Error response from daemon: Conflict, 6d667a155803 wasn't deleted Error response from daemon: Conflict, 0fc2b25d8fd3 wasn't deleted Error response from daemon: Conflict, 6959ba7d8734 wasn't deleted Error response from daemon: Conflict, 37fe89ca4311 wasn't deleted Error response from daemon: Conflict, 796d65feaed5 wasn't deleted Error response from daemon: Conflict, de7297ba1b9a wasn't deleted Error response from daemon: Conflict, c83197f95dde wasn't deleted Error response from daemon: Conflict, 4d7573216a55 wasn't deleted Error response from daemon: Conflict, c80b32754920 wasn't deleted Error response from daemon: Conflict, 35de85633ce8 wasn't deleted Error response from daemon: Conflict, 2d071adbff87 wasn't deleted Error response from daemon: Conflict, 3fa6acd3a09b wasn't deleted Error response from daemon: Conflict, c4a6220304cf wasn't deleted Error response from daemon: Conflict, ca249e062aba wasn't deleted Error response from daemon: Conflict, 945a8f4ddfee wasn't deleted Error response from daemon: Conflict, be0c39494b67 wasn't deleted Error response from daemon: Conflict, 78fd09e4ab8a wasn't deleted Error response from daemon: Conflict, 4abfd0ffcf56 wasn't deleted Error response from daemon: Conflict, 264c797efbd6 wasn't deleted Error response from daemon: Conflict, 7083cccf9410 wasn't deleted Error response from daemon: Conflict, 1885aab59a73 wasn't deleted Error response from daemon: Conflict, 22d8accc7466 wasn't deleted Error response from daemon: Conflict, 8b8e27d4ab9d wasn't deleted Error response from daemon: Conflict, 139730af9d31 wasn't deleted Error response from daemon: Conflict, 56a5f1224e35 wasn't deleted Error response from daemon: Conflict, eb5ecb019744 wasn't deleted Error response from daemon: Conflict, b97ee6c89486 wasn't deleted Error response from daemon: Conflict, 8b9f05fd773c wasn't deleted Error response from daemon: Conflict, d1f85dd2812a wasn't deleted Error response from daemon: Conflict, 2a49b33066a3 wasn't deleted Error response from daemon: Conflict, fb9309dfbeef wasn't deleted Error response from daemon: Conflict, 5d6c978b5f70 wasn't deleted Error response from daemon: Conflict, c84da966b728 wasn't deleted Error response from daemon: Conflict, e0b30803a309 wasn't deleted Error response from daemon: Conflict, 6506d5658a8c wasn't deleted Error response from daemon: Conflict, 8ff7325794df wasn't deleted Error response from daemon: Conflict, ed61bf5a8b91 wasn't deleted Error response from daemon: Conflict, 73735a4b9ab9 wasn't deleted Error response from daemon: Conflict, d7479b4401f9 wasn't deleted Error response from daemon: Conflict, fda076a542f2 wasn't deleted Error response from daemon: Conflict, 6220a87c91ac wasn't deleted Error response from daemon: Conflict, b7d6e7c1e21a wasn't deleted Error response from daemon: Conflict, 23255e5de05e wasn't deleted Error response from daemon: Conflict, 9b0516337e5a wasn't deleted Error response from daemon: Conflict, fede856341ad wasn't deleted Error response from daemon: Conflict, 864b9f0054e7 wasn't deleted Error response from daemon: Conflict, 23c87de41786 wasn't deleted Error response from daemon: Conflict, 5d7fe409bfe4 wasn't deleted Error response from daemon: Conflict, da7bfdf0e1b6 wasn't deleted Error response from daemon: Conflict, 6470f811e73f wasn't deleted Error response from daemon: Conflict, 594f8b77e732 wasn't deleted Error response from daemon: Conflict, 9243c9adab8b wasn't deleted Error response from daemon: Conflict, ee0b1941d320 wasn't deleted Error response from daemon: Conflict, 4fe585a340e7 wasn't deleted Error response from daemon: Conflict, 31bfb552afaf wasn't deleted Error response from daemon: Conflict, 56b9543fe345 wasn't deleted Error response from daemon: Conflict, 776eac27ad9d wasn't deleted Error response from daemon: Conflict, 4132f6005419 wasn't deleted Error response from daemon: Conflict, 7418ba5f7369 wasn't deleted Error response from daemon: Conflict, 30867c4ff0fd wasn't deleted Error response from daemon: Conflict, dabfc8a44cb5 wasn't deleted Error response from daemon: Conflict, 37fd06241067 wasn't deleted Error response from daemon: Conflict, 68bde466ffab wasn't deleted Error response from daemon: Conflict, 5cbfee875b7b wasn't deleted Error response from daemon: Conflict, afc7fc2f17c1 wasn't deleted Error response from daemon: Conflict, 82c9a6741336 wasn't deleted Error response from daemon: Conflict, 99ec81b80c55 wasn't deleted Error response from daemon: Conflict, d4010efcfd86 wasn't deleted Error response from daemon: Conflict, 4d26dd3ebc1c wasn't deleted Error response from daemon: Conflict, 5e66087f3ffe wasn't deleted Error response from daemon: Conflict, 511136ea3c5a wasn't deleted 2014/10/24 08:58:14 Error: failed to remove one or more images root@Tower:~# Try thisdocker rmi $(docker images -q) Quote Link to comment
PeterB Posted October 24, 2014 Author Share Posted October 24, 2014 Try thisdocker rmi $(docker images -q) Well, that deleted (or untagged?) all the named (used?) images, but left all the unnamed ones untouched. What is noticeable is that my btrfs loopback device is still showing 26GB used, out of 30GB ... for just 5 containers. Quote Link to comment
eroz Posted October 24, 2014 Share Posted October 24, 2014 Try thisdocker rmi $(docker images -q) Well, that deleted (or untagged?) all the named (used?) images, but left all the unnamed ones untouched. What is noticeable is that my btrfs loopback device is still showing 26GB used, out of 30GB ... for just 5 containers. Getting closer....try this to remove the dangling or the images labeled as none. docker rmi $(docker images -q --filter "dangling=true") Quote Link to comment
PeterB Posted October 24, 2014 Author Share Posted October 24, 2014 Many thanks for all your helpful input, Eroz. May I ask how you've acquired all this intimate knowledge about docker - I would love to learn! Getting closer....try this to remove the dangling or the images labeled as none. docker rmi $(docker images -q --filter "dangling=true") Well, it would appear that there are no dangling images, so the rmi command returned an error.: root@Tower:~# docker images --filter "dangling=true" REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE root@Tower:~# I do notice that, somewhere along the way, the number of images reported by docker info, dropped from 92 to 83 - a step in the right direction, I'm sure, but that may be because I've removed one docker which I was no longer using.. My questions, therefore, are: 1) In a normal functioning docker system, should there be any unnamed images? 2) In a normal functioning docker system, is it acceptable that there be 83 images (78 of them unnamed) to support five running containers? 3) In a normal functioning docker system, is it reasonable that the btrfs docker.img should need 26MB/30MB to support five running containers? 4) Why should a perfectly running system be shutdown under apcupsd control and on restart report that the docker.img is full? i) Would that be caused by docker, or caused by btrfs? 5) I'm sure that there are many more questions to be asked/answered, but I'll stop there for now. Quote Link to comment
eroz Posted October 24, 2014 Share Posted October 24, 2014 It looks like you only ran part of the command. Hopefully it works, but the part in the parenthesis should have listed the "none" images and there first part to remove them. docker rmi $(docker images -q --filter "dangling=true") if that doesn't work try adding sudo at the beginning. Just learning by reading the docker user guide. Quote Link to comment
eroz Posted October 24, 2014 Share Posted October 24, 2014 My questions, therefore, are: 1) In a normal functioning docker system, should there be any unnamed images? 2) In a normal functioning docker system, is it acceptable that there be 83 images (78 of them unnamed) to support five running containers? 3) In a normal functioning docker system, is it reasonable that the btrfs docker.img should need 26MB/30MB to support five running containers? 4) Why should a perfectly running system be shutdown under apcupsd control and on restart report that the docker.img is full? i) Would that be caused by docker, or caused by btrfs? 5) I'm sure that there are many more questions to be asked/answered, but I'll stop there for now. I'll try to answer what I know. 1)No, all images should be named. Here is what docker says about it. These images occur when a new build of an image takes the repo:tag away from the image ID, leaving it untagged. 2) No, not sure how you got that many. Possibly from running the docker run command on a container that you have edited and not fully stopping the container first. 3) Not sure. 4) Not sure. Possibly a btrfs issue since it's the docker.img Quote Link to comment
PeterB Posted October 24, 2014 Author Share Posted October 24, 2014 It looks like you only ran part of the command. Hopefully it works, but the part in the parenthesis should have listed the "none" images and there first part to remove them. Sorry, I ran the whole command first time: root@Tower:~# docker rmi $(docker images -q --filter "dangling=true") Usage: docker rmi IMAGE [iMAGE...] Remove one or more images -f, --force=false Force removal of the image --no-prune=false Do not delete untagged parents root@Tower:~# - when that returned an error implying that no image had been specified, I ran the filtered list of images to prove that it returned nothing. Quote Link to comment
PeterB Posted October 24, 2014 Author Share Posted October 24, 2014 My questions, therefore, are: 1) In a normal functioning docker system, should there be any unnamed images? I'll try to answer what I know. 1)No, all images should be named. Here is what docker says about it. These images occur when a new build of an image takes the repo:tag away from the image ID, leaving it untagged. Okay, I tried deleting a couple of the unnamed (untagged?) images explicitly. That returned the error : root@Tower:~# docker rmi 511136ea3c5a Error response from daemon: Conflict, 511136ea3c5a wasn't deleted 2014/10/24 13:22:29 Error: failed to remove one or more images root@Tower:~# I googled this error, and found advice to run the following command : root@Tower:~# docker images -tree Warning: '-tree' is deprecated, it will be removed soon. See usage. ??511136ea3c5a Virtual Size: 0 B ??9b0516337e5a Virtual Size: 0 B ? ??dce0559daa1b Virtual Size: 282.9 MB ? ??4abfd0ffcf56 Virtual Size: 282.9 MB ? ??78fd09e4ab8a Virtual Size: 670.4 MB ? ??be0c39494b67 Virtual Size: 670.4 MB ? ??945a8f4ddfee Virtual Size: 670.4 MB ? ??ca249e062aba Virtual Size: 670.4 MB ? ??751bf43d0ac8 Virtual Size: 670.4 MB ? ? ??04f19be08c97 Virtual Size: 670.4 MB ? ? ??a2cd9596b615 Virtual Size: 670.4 MB ? ? ??c31e297ed434 Virtual Size: 950.3 MB ? ? ??ac3dd770621e Virtual Size: 950.3 MB ? ? ??33b14c7b83f4 Virtual Size: 950.3 MB ? ? ??f5def0f3c425 Virtual Size: 950.3 MB Tags: binhex/arch-minidlna:latest ? ??35de85633ce8 Virtual Size: 670.4 MB ? ? ??c80b32754920 Virtual Size: 670.4 MB ? ? ??6959ba7d8734 Virtual Size: 1.124 GB ? ? ??0fc2b25d8fd3 Virtual Size: 1.124 GB ? ? ??6d667a155803 Virtual Size: 1.124 GB ? ? ??847aee0b7d36 Virtual Size: 1.124 GB ? ? ??bc2b99be8723 Virtual Size: 1.124 GB ? ? ??3d3a7c14471b Virtual Size: 1.124 GB ? ? ??e7f624569566 Virtual Size: 1.124 GB ? ? ??4371e7493f88 Virtual Size: 1.124 GB Tags: binhex/arch-deluge:latest ? ??c4a6220304cf Virtual Size: 670.4 MB ? ??3fa6acd3a09b Virtual Size: 670.4 MB ? ??2d071adbff87 Virtual Size: 670.4 MB ? ??4d7573216a55 Virtual Size: 985.9 MB ? ??c83197f95dde Virtual Size: 985.9 MB ? ??de7297ba1b9a Virtual Size: 985.9 MB ? ??796d65feaed5 Virtual Size: 985.9 MB ? ??37fe89ca4311 Virtual Size: 985.9 MB ? ??7dd9988affce Virtual Size: 985.9 MB Tags: binhex/arch-couchpotato:latest ??5e66087f3ffe Virtual Size: 192.5 MB ??4d26dd3ebc1c Virtual Size: 192.7 MB ??d4010efcfd86 Virtual Size: 192.7 MB ??99ec81b80c55 Virtual Size: 266 MB ??82c9a6741336 Virtual Size: 266 MB ??5cbfee875b7b Virtual Size: 266 MB ??afc7fc2f17c1 Virtual Size: 266 MB ??68bde466ffab Virtual Size: 266 MB ??37fd06241067 Virtual Size: 391 MB ??dabfc8a44cb5 Virtual Size: 391 MB ??d7479b4401f9 Virtual Size: 391 MB ? ??73735a4b9ab9 Virtual Size: 391 MB ? ??ed61bf5a8b91 Virtual Size: 391 MB ? ??8ff7325794df Virtual Size: 391 MB ? ??6506d5658a8c Virtual Size: 391 MB ? ??e0b30803a309 Virtual Size: 391 MB ? ??c84da966b728 Virtual Size: 391 MB ? ??5d6c978b5f70 Virtual Size: 391.1 MB ? ??fb9309dfbeef Virtual Size: 391.1 MB ? ??2a49b33066a3 Virtual Size: 391.1 MB ? ??d1f85dd2812a Virtual Size: 470 MB ? ??8b9f05fd773c Virtual Size: 471.7 MB ? ??b97ee6c89486 Virtual Size: 471.7 MB ? ??eb5ecb019744 Virtual Size: 590.6 MB ? ??56a5f1224e35 Virtual Size: 882.5 MB ? ??139730af9d31 Virtual Size: 882.5 MB ? ??8b8e27d4ab9d Virtual Size: 882.5 MB ? ??22d8accc7466 Virtual Size: 882.5 MB ? ??1885aab59a73 Virtual Size: 882.5 MB ? ??7083cccf9410 Virtual Size: 882.5 MB ? ??264c797efbd6 Virtual Size: 882.5 MB ? ??9ea52a152291 Virtual Size: 882.5 MB Tags: gfjardim/logitechmediaserver:latest ??30867c4ff0fd Virtual Size: 391 MB ??7418ba5f7369 Virtual Size: 391 MB ??4132f6005419 Virtual Size: 391 MB ??776eac27ad9d Virtual Size: 391 MB ??56b9543fe345 Virtual Size: 391 MB ??31bfb552afaf Virtual Size: 468.4 MB ??4fe585a340e7 Virtual Size: 590.6 MB ??ee0b1941d320 Virtual Size: 590.6 MB ??9243c9adab8b Virtual Size: 590.6 MB ??594f8b77e732 Virtual Size: 590.6 MB ??6470f811e73f Virtual Size: 590.6 MB ??da7bfdf0e1b6 Virtual Size: 590.6 MB ??5d7fe409bfe4 Virtual Size: 590.6 MB ??23c87de41786 Virtual Size: 590.6 MB ??864b9f0054e7 Virtual Size: 590.6 MB ??fede856341ad Virtual Size: 590.6 MB ??566c91aa7b1e Virtual Size: 590.6 MB Tags: needo/mariadb:latest root@Tower:~# Now I'm not sure what to think - should those untagged images be present or not? Quote Link to comment
binhex Posted October 24, 2014 Share Posted October 24, 2014 ok that tree command is displaying each layer for each image, so you most definitely dont want to be attempting to delete any layers as it just wont let you do that, instead you want to be focusing on deleting the entire image. try the following, this forces a stop of all containers (i know you said you delete them all, but just incase), it then removes all containers, and then deletes ALL docker images:- docker stop $(docker ps -a -q) docker rm $(docker ps -a -q) docker rmi $(docker images -a -q) to confirm you are clean then run:- docker ps -a docker images both should come back empty. if either aren't empty then do the following replacing <> with the container/image id docker rm <container id> docker rmi <image id> just to show you what my working system looks like if i issue a "docker images -a":- REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE binhex/arch-madsonic latest 249c53f23ef7 46 hours ago 1.123 GB <none> <none> 9881e268084f 46 hours ago 1.123 GB <none> <none> 4a71de5d9b4b 46 hours ago 1.123 GB <none> <none> e8e29f4de318 46 hours ago 1.123 GB <none> <none> 29e20ddcf5d2 46 hours ago 1.123 GB <none> <none> c81fbcd216ba 46 hours ago 1.123 GB <none> <none> 5e3225e25cff 46 hours ago 1.123 GB <none> <none> df23e84dcbec 46 hours ago 1.123 GB <none> <none> 0f542fff1f42 46 hours ago 779.4 MB <none> <none> 67abe5863460 46 hours ago 779.4 MB <none> <none> 0ebc7f6febe3 46 hours ago 779.4 MB <none> <none> 21a1dfbb075c 46 hours ago 725.6 MB <none> <none> f2e7f771ca26 46 hours ago 670.4 MB binhex/arch-teamspeak latest 510f7e83bac2 8 days ago 952.8 MB <none> <none> d018ff392a0a 8 days ago 952.8 MB <none> <none> 0568919b5642 8 days ago 952.8 MB <none> <none> 08425e12961e 8 days ago 670.4 MB <none> <none> ef31ea0454bd 8 days ago 670.4 MB <none> <none> ab1ff9e662f5 8 days ago 670.4 MB <none> <none> 782b5bb91785 8 days ago 670.4 MB <none> <none> f7469a54a3a3 8 days ago 670.4 MB binhex/arch-plex latest 4ab356702dac 9 days ago 1.376 GB <none> <none> f5ede300ed78 9 days ago 1.376 GB <none> <none> 3edb67a15c83 9 days ago 1.376 GB <none> <none> 028687cd03f4 9 days ago 1.376 GB <none> <none> a14d10c226c5 9 days ago 1.376 GB <none> <none> a6d558419760 9 days ago 1.376 GB <none> <none> dc08e98a860b 9 days ago 670.4 MB <none> <none> d3a9f7100639 9 days ago 670.4 MB <none> <none> dc439da8cd60 9 days ago 670.4 MB binhex/arch-deluge latest 4371e7493f88 10 days ago 1.124 GB <none> <none> e7f624569566 10 days ago 1.124 GB <none> <none> 3d3a7c14471b 10 days ago 1.124 GB <none> <none> bc2b99be8723 10 days ago 1.124 GB <none> <none> 847aee0b7d36 10 days ago 1.124 GB <none> <none> 6d667a155803 10 days ago 1.124 GB <none> <none> 0fc2b25d8fd3 10 days ago 1.124 GB <none> <none> 6959ba7d8734 10 days ago 1.124 GB binhex/arch-minidlna latest f5def0f3c425 10 days ago 950.3 MB <none> <none> 33b14c7b83f4 10 days ago 950.3 MB <none> <none> ac3dd770621e 10 days ago 950.3 MB <none> <none> c31e297ed434 10 days ago 950.3 MB binhex/arch-sickbeard latest e6e9677549cf 10 days ago 959.6 MB <none> <none> 9ee25f6be170 10 days ago 959.6 MB <none> <none> 5d1c918b244f 10 days ago 959.6 MB <none> <none> 7861a8a2ebf6 10 days ago 959.6 MB <none> <none> 8c16d1233936 10 days ago 959.6 MB <none> <none> d75d8ed9846f 10 days ago 959.6 MB binhex/arch-get-iplayer latest 2d565331261b 10 days ago 946.4 MB <none> <none> 5ab0f87afdb4 10 days ago 946.4 MB <none> <none> 1ddd14e150df 10 days ago 946.4 MB <none> <none> b8c8212870a9 10 days ago 946.4 MB binhex/arch-sabnzbd latest c565f602b2fb 10 days ago 1.109 GB <none> <none> 487aa4157ce3 10 days ago 1.109 GB <none> <none> b54a48aa0a1c 10 days ago 1.109 GB <none> <none> 1b8ed7abb0ca 10 days ago 1.109 GB <none> <none> 1293c2ca0a56 10 days ago 1.109 GB <none> <none> cb5f75dadbb3 10 days ago 1.109 GB <none> <none> 015bfdd44c7f 10 days ago 1.075 GB <none> <none> b59964ae1506 10 days ago 1.075 GB <none> <none> e4ad9075609d 10 days ago 1.075 GB <none> <none> a01043f438a6 10 days ago 670.4 MB <none> <none> 4318fc6cb4a3 10 days ago 670.4 MB <none> <none> 94a4017348c7 10 days ago 670.4 MB <none> <none> a2cd9596b615 10 days ago 670.4 MB <none> <none> 04f19be08c97 10 days ago 670.4 MB <none> <none> 751bf43d0ac8 10 days ago 670.4 MB <none> <none> 4045badcf8ce 10 days ago 670.4 MB <none> <none> cf365f5ea996 10 days ago 670.4 MB <none> <none> 8f29bd7e366d 10 days ago 670.4 MB <none> <none> d7079e8f7d53 10 days ago 670.4 MB <none> <none> c80b32754920 10 days ago 670.4 MB <none> <none> 35de85633ce8 10 days ago 670.4 MB <none> <none> ca249e062aba 10 days ago 670.4 MB <none> <none> 945a8f4ddfee 10 days ago 670.4 MB <none> <none> be0c39494b67 10 days ago 670.4 MB <none> <none> 78fd09e4ab8a 10 days ago 670.4 MB <none> <none> 4abfd0ffcf56 10 days ago 282.9 MB <none> <none> 7526a0d9280a 2 weeks ago 1.075 GB <none> <none> 9c138d6dfcf4 2 weeks ago 1.075 GB <none> <none> 6cf76f41c6f4 2 weeks ago 1.075 GB <none> <none> e0b63941078c 2 weeks ago 1.075 GB <none> <none> 56d8cd36fc6a 2 weeks ago 1.075 GB <none> <none> 2ec09e735685 2 weeks ago 1.075 GB <none> <none> 718d7fe65f10 2 weeks ago 1.075 GB <none> <none> 12569924a741 2 weeks ago 858.8 MB <none> <none> 6f423beb4163 2 weeks ago 858.8 MB <none> <none> 7d8ff87b4a26 2 weeks ago 858.8 MB <none> <none> a01e05494de5 2 weeks ago 858.8 MB <none> <none> dbf0b44faede 2 weeks ago 858.8 MB <none> <none> bc3b6842a2de 2 weeks ago 858.8 MB <none> <none> f4eead7fbbac 2 weeks ago 858.8 MB <none> <none> 4634883ec472 2 weeks ago 666.4 MB <none> <none> 333e1ace96c2 2 weeks ago 576.6 MB <none> <none> aa3b011f7820 2 weeks ago 284.5 MB <none> <none> ca01360c4d6e 2 weeks ago 284.5 MB <none> <none> 6ed9ec3230d7 2 weeks ago 282.9 MB <none> <none> e6a8c1cfd818 2 weeks ago 282.9 MB <none> <none> 596e2041219f 2 weeks ago 282.9 MB <none> <none> 4ebdd2a1fb9a 2 weeks ago 282.9 MB <none> <none> 80bb8dbe95e4 2 weeks ago 282.9 MB binhex/arch-moviegrabber latest 2ca686522f9d 9 weeks ago 865.4 MB <none> <none> b78cbe081952 9 weeks ago 865.4 MB <none> <none> bf83f7486eb0 9 weeks ago 865.4 MB <none> <none> 238fa3c13b30 9 weeks ago 865.4 MB <none> <none> 37b99931b7dd 9 weeks ago 865.4 MB <none> <none> b90416a89802 9 weeks ago 858.9 MB <none> <none> 4c0758a36ed8 9 weeks ago 852.4 MB <none> <none> 0950de96b2d9 9 weeks ago 852.4 MB <none> <none> 291a5f278766 9 weeks ago 852.4 MB <none> <none> cc47659236b6 9 weeks ago 852.4 MB <none> <none> 33ff1a7c9090 9 weeks ago 852.4 MB <none> <none> 58736d5894e2 9 weeks ago 852.4 MB <none> <none> 535ea0e03f97 9 weeks ago 852.4 MB <none> <none> 6a4ac514d3c8 9 weeks ago 845.9 MB <none> <none> 0ce59235f32a 9 weeks ago 839.5 MB <none> <none> dd76dfcafece 9 weeks ago 837.6 MB <none> <none> 06a28934cb03 9 weeks ago 837.6 MB <none> <none> fb1d29f4e5bf 9 weeks ago 828.9 MB <none> <none> 1987304f7191 9 weeks ago 824.6 MB <none> <none> a31908ff8a65 11 weeks ago 824.6 MB <none> <none> 08c2c584c866 11 weeks ago 824.6 MB <none> <none> f4d3408fc6dd 11 weeks ago 824.6 MB <none> <none> 661b49e55bd8 11 weeks ago 824.6 MB <none> <none> e6373c3bbf15 11 weeks ago 824.6 MB <none> <none> 9fbfca95f460 11 weeks ago 824.6 MB <none> <none> f08490c592ee 11 weeks ago 824.5 MB <none> <none> 513eb4cb2743 11 weeks ago 614.2 MB <none> <none> f688131cab19 11 weeks ago 614.2 MB <none> <none> b33bcba28400 11 weeks ago 614.2 MB <none> <none> f3848d76d4d5 11 weeks ago 614.2 MB <none> <none> 15faf6161539 11 weeks ago 614.2 MB <none> <none> cb68462657a1 11 weeks ago 614.2 MB <none> <none> 14de356389e0 11 weeks ago 614.2 MB <none> <none> 5c0e38ca9540 11 weeks ago 421.5 MB <none> <none> 615c2fe1016c 11 weeks ago 331.9 MB <none> <none> 7a35f84f4019 11 weeks ago 284.5 MB <none> <none> 0d1402c2605d 11 weeks ago 284.5 MB <none> <none> 84be809346ab 11 weeks ago 282.9 MB <none> <none> 91b6793bab67 11 weeks ago 282.9 MB <none> <none> 108a3b59ae2d 11 weeks ago 282.9 MB <none> <none> e71e29647563 11 weeks ago 282.9 MB <none> <none> a5e1361c4512 11 weeks ago 282.9 MB <none> <none> dce0559daa1b 3 months ago 282.9 MB <none> <none> 9b0516337e5a 3 months ago 0 B <none> <none> 511136ea3c5a 16 months ago 0 B so as you can see i have lots of layers in there with a name of none interspersed with the names of the images and indeed if i run a docker info command:- root@Tower:~# docker info Containers: 9 Images: 146 Storage Driver: btrfs Execution Driver: native-0.2 Kernel Version: 3.16.3-unRAID Operating System: Slackware 14.1 i have 146 images, as i suspected that really aught not to be called images in my opinion and should instead be labelled as "Layers" instead, but hey maybe docker sees every layer as an image, who knows?!!, all i can tell you is in my experience this is "normal" and can be ignored, "docker images" is the "real" view of what you have on your system. just to be clear, and PLEASE excuse me if this is too basic for you, each image is built from layers, these layers are defined via the "run" and "add" commands in a dockerfile (possibly other commands trigger an additional layer too) so for every "run ...." in a dockerfile creates an additional layer, if you add up all layers together you then get the finished image (as can be seen when you do a docker pull or docker run). i have actually just recently "flattened" by layers by editing my dockerfiles to use just one run command, this reduces time to download and size of the final image, thus if you do a docker pull of any of my docker images you should now see a few small layers and then one larger layer. i really hope the above helps you out peter!. Quote Link to comment
PeterB Posted October 24, 2014 Author Share Posted October 24, 2014 i have 146 images, as i suspected that really aught not to be called images in my opinion and should instead be labelled as "Layers" instead, but hey maybe docker sees every layer as an image, who knows?!!, all i can tell you is in my experience this is "normal" and can be ignored, "docker images" is the "real" view of what you have on your system. Hey, thanks for all the useful info. So, what I see on my system is to be expected. How big is your docker.img, then. Do you have to keep increasing it every so often, even if you don't add more containers? I can see that if I add up the sizes of all those images, it comes to somewhat more than 30GB, so the COW must be working. I guess that I should just quit worrying then, and increase my docker.img to 100GB - but I don't understand why the size required keeps increasing. It's just a little unnerving when, after the third powercut of the day, the dockers fail to start, when they've been fine on the previous two occasions. Either I need to make the docker.img huge, or keep any eye on it and increase the size pre-emptively - it'll be a lot less hassle than having to reload all my containers. Quote Link to comment
binhex Posted October 24, 2014 Share Posted October 24, 2014 but I don't understand why the size required keeps increasing. the docker images will increase "a bit" as things like internal logs for applications are created, but you shouldnt be seeing a massive increase in size, if you are then there is something wrong with one or more docker images, my advise it to screenshot the sizes from the docker images command, and then compare day on day and you should see which are the culprits. to give you some idea, i have currently got 9 docker containers running, i noticed on a clean pull from a newly created docker.img file by used space was around 8GB, a week later and its now sitting at 12GB, but i havent seen it move since, so i think its stabilised at that size (logs full and rotating now??). if you have any images now left can you post the output from "docker images" Quote Link to comment
PeterB Posted October 24, 2014 Author Share Posted October 24, 2014 but I don't understand why the size required keeps increasing. the docker images will increase "a bit" as things like internal logs for applications are created, but you shouldnt be seeing a massive increase in size, if you are then there is something wrong with one or more docker images, my advise it to screenshot the sizes from the docker images command, and then compare day on day and you should see which are the culprits. Massive increase - like 5GB in a week ... with 5 containers. Three of the images are yours, so they cannot be suspect .... to give you some idea, i have currently got 9 docker containers running, i noticed on a clean pull from a newly created docker.img file by used space was around 8GB, a week later and its now sitting at 12GB, but i havent seen it move since, so i think its stabilised at that size (logs full and rotating now??). 12GB total requrement for nine dockers? Hmmm. That's a bit different to my 26GB for five dockers. Label: none uuid: cbe47d47-ae50-4cd8-8e6b-53764ba8c9fa Total devices 1 FS bytes used 22.22GiB devid 1 size 30.00GiB used 26.00GiB path /dev/loop8 Btrfs v3.16.1 if you have any images now left can you post the output from "docker images" Sure: root@Tower:~# docker images -a REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE binhex/arch-deluge latest 4371e7493f88 11 days ago 1.124 GB <none> <none> e7f624569566 11 days ago 1.124 GB <none> <none> 3d3a7c14471b 11 days ago 1.124 GB <none> <none> bc2b99be8723 11 days ago 1.124 GB <none> <none> 847aee0b7d36 11 days ago 1.124 GB <none> <none> 6d667a155803 11 days ago 1.124 GB <none> <none> 0fc2b25d8fd3 11 days ago 1.124 GB <none> <none> 6959ba7d8734 11 days ago 1.124 GB binhex/arch-minidlna latest f5def0f3c425 11 days ago 950.3 MB <none> <none> 33b14c7b83f4 11 days ago 950.3 MB <none> <none> ac3dd770621e 11 days ago 950.3 MB <none> <none> c31e297ed434 11 days ago 950.3 MB binhex/arch-couchpotato latest 7dd9988affce 11 days ago 985.9 MB <none> <none> 37fe89ca4311 11 days ago 985.9 MB <none> <none> 796d65feaed5 11 days ago 985.9 MB <none> <none> de7297ba1b9a 11 days ago 985.9 MB <none> <none> c83197f95dde 11 days ago 985.9 MB <none> <none> 4d7573216a55 11 days ago 985.9 MB <none> <none> a2cd9596b615 11 days ago 670.4 MB <none> <none> 04f19be08c97 11 days ago 670.4 MB <none> <none> 751bf43d0ac8 11 days ago 670.4 MB <none> <none> c80b32754920 11 days ago 670.4 MB <none> <none> 35de85633ce8 11 days ago 670.4 MB <none> <none> 2d071adbff87 11 days ago 670.4 MB <none> <none> 3fa6acd3a09b 11 days ago 670.4 MB <none> <none> c4a6220304cf 11 days ago 670.4 MB <none> <none> ca249e062aba 11 days ago 670.4 MB <none> <none> 945a8f4ddfee 11 days ago 670.4 MB <none> <none> be0c39494b67 11 days ago 670.4 MB <none> <none> 78fd09e4ab8a 11 days ago 670.4 MB <none> <none> 4abfd0ffcf56 11 days ago 282.9 MB gfjardim/logitechmediaserver latest 9ea52a152291 6 weeks ago 882.5 MB <none> <none> 264c797efbd6 6 weeks ago 882.5 MB <none> <none> 7083cccf9410 6 weeks ago 882.5 MB <none> <none> 1885aab59a73 6 weeks ago 882.5 MB <none> <none> 22d8accc7466 6 weeks ago 882.5 MB <none> <none> 8b8e27d4ab9d 6 weeks ago 882.5 MB <none> <none> 139730af9d31 6 weeks ago 882.5 MB <none> <none> 56a5f1224e35 6 weeks ago 882.5 MB <none> <none> eb5ecb019744 6 weeks ago 590.6 MB <none> <none> b97ee6c89486 6 weeks ago 471.7 MB <none> <none> 8b9f05fd773c 6 weeks ago 471.7 MB <none> <none> d1f85dd2812a 6 weeks ago 470 MB <none> <none> 2a49b33066a3 6 weeks ago 391.1 MB <none> <none> fb9309dfbeef 6 weeks ago 391.1 MB <none> <none> 5d6c978b5f70 6 weeks ago 391.1 MB <none> <none> c84da966b728 6 weeks ago 391 MB <none> <none> e0b30803a309 6 weeks ago 391 MB <none> <none> 6506d5658a8c 6 weeks ago 391 MB <none> <none> 8ff7325794df 6 weeks ago 391 MB <none> <none> ed61bf5a8b91 6 weeks ago 391 MB <none> <none> 73735a4b9ab9 6 weeks ago 391 MB <none> <none> d7479b4401f9 6 weeks ago 391 MB <none> <none> dce0559daa1b 3 months ago 282.9 MB <none> <none> 9b0516337e5a 3 months ago 0 B needo/mariadb latest 566c91aa7b1e 3 months ago 590.6 MB <none> <none> fede856341ad 3 months ago 590.6 MB <none> <none> 864b9f0054e7 3 months ago 590.6 MB <none> <none> 23c87de41786 3 months ago 590.6 MB <none> <none> 5d7fe409bfe4 3 months ago 590.6 MB <none> <none> da7bfdf0e1b6 3 months ago 590.6 MB <none> <none> 6470f811e73f 3 months ago 590.6 MB <none> <none> 594f8b77e732 3 months ago 590.6 MB <none> <none> 9243c9adab8b 3 months ago 590.6 MB <none> <none> ee0b1941d320 3 months ago 590.6 MB <none> <none> 4fe585a340e7 3 months ago 590.6 MB <none> <none> 31bfb552afaf 3 months ago 468.4 MB <none> <none> 56b9543fe345 3 months ago 391 MB <none> <none> 776eac27ad9d 3 months ago 391 MB <none> <none> 4132f6005419 3 months ago 391 MB <none> <none> 7418ba5f7369 3 months ago 391 MB <none> <none> 30867c4ff0fd 3 months ago 391 MB <none> <none> dabfc8a44cb5 4 months ago 391 MB <none> <none> 37fd06241067 4 months ago 391 MB <none> <none> 68bde466ffab 4 months ago 266 MB <none> <none> afc7fc2f17c1 5 months ago 266 MB <none> <none> 82c9a6741336 5 months ago 266 MB <none> <none> 5cbfee875b7b 5 months ago 266 MB <none> <none> 99ec81b80c55 6 months ago 266 MB <none> <none> 4d26dd3ebc1c 6 months ago 192.7 MB <none> <none> d4010efcfd86 6 months ago 192.7 MB <none> <none> 5e66087f3ffe 6 months ago 192.5 MB <none> <none> 511136ea3c5a 16 months ago 0 B root@Tower:~# Quote Link to comment
binhex Posted October 24, 2014 Share Posted October 24, 2014 Can you just run docker images without the a flag it should give a clearer picture Quote Link to comment
PeterB Posted October 24, 2014 Author Share Posted October 24, 2014 root@Tower:~# docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE binhex/arch-deluge latest 4371e7493f88 11 days ago 1.124 GB binhex/arch-minidlna latest f5def0f3c425 11 days ago 950.3 MB binhex/arch-couchpotato latest 7dd9988affce 11 days ago 985.9 MB gfjardim/logitechmediaserver latest 9ea52a152291 6 weeks ago 882.5 MB needo/mariadb latest 566c91aa7b1e 3 months ago 590.6 MB root@Tower:~# Quote Link to comment
binhex Posted October 24, 2014 Share Posted October 24, 2014 Hmm nothing wrong with that, you must have some strange corruption going on in your docker IMG file. What if you go poking about in the docker IMG mount point, any large files? This might need jonp to help diagnose exactly what s going on, my gut feeling is that docker loop mounted images do not like dirty shutdowns! Quote Link to comment
PeterB Posted January 28, 2016 Author Share Posted January 28, 2016 I've just had reason to look back at this thread, and realised that I never came back to post a resolution. The problem arose because the docker image file was full and the dockers failed to start because they couldn't create new files within the image filing system. The simple solution was to expand the docker image file. The longer-term solution was to address a problem with the docker which was generating a large number of log messages, written to the image filing system. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.