Same thing for me, in the Library/Containers//com.docker.docker/Data/com.docker.driver.amd64-linux/log directory, files have bloated (in particular docker.log to 60 GB).
It happened in the space of ca. 1 week, with a low usage of Docker during the period.
Running on Mac OSX MacBook Air El Capitan 10.11.4
Same thing here. Apparently it happened in just 1 day. I checked my disk space yesterday and it was ok, a few hours later it had ~30GB less. After digging around I found out docker.log was eating 32GB.
Am also seeing this. I stopped Docker and removed the docker.log and dmesg logs (the two that were largest) and restarted. Everything came back up as expected.
Note: I have no idea why my Docker.qcow2 is so big, since I deleted it just two hours ago and now only have one image stocked and no containers running:
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
alpine latest 13e1761bf172 2 weeks ago 4.797 MB
Diagnose data:
pinata diagnose -u
OS X: version 10.11.4 (build: 15E65)
Docker.app: version v1.11.1-beta13
Running diagnostic tests:
[OK] Moby booted
[OK] driver.amd64-linux
[OK] vmnetd
[OK] osxfs
[OK] db
[OK] slirp
[OK] menubar
[OK] environment
[OK] Docker
[OK] VT-x
Similar issue here on my MacBook Pro running OS 10.11.4 upon upgrading to Docker for Mac 1.11.1-beta13. Ate up all (500G) of my free space. Ended up deleting ~/Library/Containers/com.docker.* to resuscitate my computer
I deleted all the logs yesterday, and today (after running a couple containers and pulling one image) my dmesg is 6.0GBs. It’s pretty long:
$ wc -l dmesg
97687872 dmesg
I usually run with a pretty full disk, so I would’ve noticed this before. I think this is something new with the 1.11.1-beta13.
FWIW, my Docker.qcow2 is 25GB today, whereas it was 20GB yesterday. That’s not too alarming, as the virtual size of the disk is 60GBs so it seems reasonable that it’ll grow.
From the contents of dmesg, nothing jumps out at me except it appears the VM is rebooting a lot. A little odd is that the uptime command reports that the VM’s been up for ~10hrs, whereas dmesg was last touched 5 hours ago (with a +3s timestamp). So there’s something fishy going on there…
You are experiencing an unfortunate combination of 2 minor issues that, together, cause an exponential (!) increase in log size, slow, high CPU-use start up times and general sadness. We are working on solving this issue ASAP and will have more to share with you soon. I’m sorry this experience is painful – thanks for bearing with us as we learn from our mistakes.
Thanks, again, for your help. Your understanding regarding this issue is really amazing and unexpected.
Watch this space for updates.
Thanks,
David for the Docker for Mac team
Edit: This issue should now be fixed with Beta 13.1 hotfix. See post below and Beta 13.1 changelog window during update for more details.
It is safe to remove the log files when Docker.app isn’t running. It is probably fine to remove it while it is running as well but we haven’t tested this scenario.
Docker.qcow2 is a sparse block device image that contains the contents of the copy-on-write file system (AUFS over ext4 right now) which contains your images, containers, and volume driver volumes. It is safe to delete if you have no irreplaceable data stored in images, containers, and volume driver volumes.
If you have data you would like to retain, I recommend running containers which export that data over a -v bind mount to OS X before deleting Docker.qcow2.
I just uninstalled the beta and instantly freed up 103GB on my Macbook Pro SSD. This is crazy huge since I have only actively used the beta for maybe 10 images and 5 or so containers.
At some point today it actually looked like it might have been updated the qcow file or something (I could not determine the cause at the time) in the background (while I was not using docker) as my disk space was being devoured quickly. I could watch it counting down to zero.
Things are stable now, after the uninstall. I’d like to get it back on, but I’ll need to hold off for a bit, as I can’t sacrifice that much disk space at the moment, to this.