Docker Beta filled up my drive with logs for no apparent reason

Expected behavior

Docker does not fill up my drive with logs

Actual behavior

Docker fills up my drive with logs

Information

This morning, with the Docker beta running in the background, my hard drive suddenly went from ~28GB free to totally full within 30 minutes of me turning on my computer and working on non-Docker related tasks.

Logs were all in this folder: /Users/ycarmon/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log

  • the output of:
    • pinata diagnose -u on OSX:

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
Docker logs are being collected into /tmp/20160526-101009.tar.gz
Most specific failure is: No error was detected
Your unique id is: 7B77F56D-6973-4665-BF0D-0FDB5D1D05EC
Please quote this in all correspondence.

  • host distribution and version: Mac OS X 10.11.4 (15E65)
3 Likes

Hi,
same Problem here

During a few hours :

LG:log streacs$ du -hs *
16M acpid.log
24G dmesg
76G docker.log
16K messages
1.5M messages.0
11M proxy-vsockd.log
8.3G vsudd.log
0B wtmp

LG:log streacs$ 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
Docker logs are being collected into /tmp/20160526-191245.tar.gz
Most specific failure is: No error was detected
Your unique id is: A3433CD4-53BA-4983-9E3C-5FBD51B8B2E3
Please quote this in all correspondence.

+1 here:

du -sh * 64K console-ring 4.0K hypervisor.pid 0B lock 65G log 4.0K mac.0 4.0K nic1.uuid 4.0K pid 4.0K tty

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
pinata diagnose hangs after VT-x, perhaps copying and zipping log files.

Just had the same thing happen. OS warned me about low disk space. Tracked it down to docker logs. Ran piñata diagnose and it hung as well.

–EDIT: removed redirection to another ticket. I wrongfully picked a ticket that I thought related, but it wasn’t.

Same here…

du -sh *
 41G	Docker.qcow2
 64K	console-ring
4.0K	hypervisor.pid
  0B	lock
603M	log
4.0K	mac.0
4.0K	nic1.uuid
4.0K	pid
4.0K	tty

Confirm the same here

du -sh * 14G Docker.qcow2 64K console-ring 4.0K hypervisor.pid 0B lock 9.0G log 4.0K mac.0 4.0K nic1.uuid 4.0K pid 4.0K tty 4.0K xhyve.args

Looks like by default the docker log level is set to debug:

$ pinata get daemon
{"storage-driver":"aufs","debug":true}

Setting debug to false greatly reduces the rate that the logs fill up at least…

$ pinata set daemon '{"storage-driver":"aufs","debug":false}'
daemon.json -> {"storage-driver":"aufs","debug":false}
$ pinata restart
2 Likes

@abrown 's fix worked for me… Before restarting the daemon I backed up, compressed and deleted the three log files in my docker data directory. (~/Library/Containers/com.docker.docker/Data/*.log). Then I restarted the daemon with the debug feature off.

Same problem for me, I just delete log+image and restart my mac caused by a low memory (thanks swap) and docker taking 72G for vm image and ~60G for logs (half of my disk just for Docker)

Hello everyone,

This should have been fixed by the Beta 13.1 hotfix released on Saturday. Please update and let us know if you still see the issue.

Thanks,

David