Repeated crashes and hanging

Docker Desktop for Mac
1

Expected behavior

docker ps works normally

Actual behavior

docker ps (or docker **) hangs indefinitely.

Information

  • the output of:
    • Moby Menu > Diagnose & Feedback on OSX
      Diagnostic ID: 64A5AE6D-234D-4B63-AF60-97F7FC1CC395
  • a reproducible case if this is a bug, Dockerfiles FTW
  • page URL if this is a docs issue or the name of a man page
  • host distribution and version ( OSX 10.10.x, OSX 10.11.x, Windows, etc )

Steps to reproduce the behavior

I honestly don’t know. It has happened 3 times today, each time I had to restart docker, reboot, or reset to factory defaults. The error did not occur when I did anything in particular. This last time things were going along fine for a while. I went on to another task, then went to check my site again (this is a local Django site), and it was unresponsive. My first check was docker ps, which hung … and made me sad.

  1. …
  2. …
2

I exited Docker for mac, and monitored "ps -ef"
It cleaned up, but not all processes were gone.

$ ps -ef | egrep docker 0 34002 1 0 11:19AM ?? 0:00.02 /Library/PrivilegedHelperTools/com.docker.vmnetd 503 85503 1 0 12:08AM ?? 0:00.06 /Applications/Docker.app/Contents/MacOS/com.docker.osx.hyperkit.linux -watchdog fd:0 503 85504 85503 0 12:08AM ?? 0:00.04 /Applications/Docker.app/Contents/MacOS/com.docker.osx.hyperkit.linux -watchdog fd:0 503 85506 85503 0 12:08AM ?? 0:00.76 com.docker.db --url=file:///Volumes/bnpraid/Users/kutenai/Library/Containers/com.docker.docker/Data/s40 --git /Volumes/bnpraid/Users/kutenai/Library/Containers/com.docker.docker/Data/database 503 85680 83648 0 12:10AM ttys007 0:00.00 egrep docker

Once I restarted, I was able to access docker ps, and use docker-compose up -d

I do hope my report can help to resolve this issue however.

3

This morning, Docker was again “hung”. This appears to be related to time – so that docker will eventually fail.
Sure would like to know why.
I am going to restart it, and turn off a couple of the containres.

I do have some containers that are constantly polling, these are using “gulp watch” for example or “webpack --watch”. I never had this problem before I started using those features… will turn those off and see how long it lasts.