Running containers die when machine suspended

Summary:
When I suspend my machine, any running containers die with the error:

Error response from daemon: dial unix /var/tmp/com.docker.vsock/00000003.00000948: connect: connection refused

Versions:

  • Docker for Mac: Version 1.11.1-beta11 (build: 6974)
  • OSX: 10.10.5
  • MacBook Air (13-inch, Early 2015)

How to reproduce:

  1. Start a container
  2. Close lid of laptop to suspend
  3. Open lid and log in
  4. Get annoyed that your containers are all dead and you have to restart them…

Is this a bug, a(n un)documented feature, or just an easy fix? Any thoughts?

9 Likes

did you find a fix for this ? its happen me exactly the same, but I have 21.5-inch, Late 2013, and Yosemite, and with the same iMac but with El Capitan its the Same !

Hi @devs

This is still a problem - please help!

$ pinata diagnose -u
OS X: version 10.10.5 (build: 14F1713)
Docker.app: version v1.11.1-beta12
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/20160520-163425.tar.gz
Most specific failure is: No error was detected
Your unique id is: 87389479-4F8F-4632-8BE8-591E5125A816
Please quote this in all correspondence.

I’m seeing this happen while the container and host is running. I’m trying to build a rather large project, but sometime it fails with something like
Error response from daemon: dial unix /Users/dnewel/Library/Containers/com.docker.docker/Data/*00000003.00000948: connect: connection refused
I can restart the contianer and try again, but it doesn’t fail at a particular place…just randomly. No idea why…

Yup @dennisnewel - I’ve seen that too. I think it’s the same behaviour that I’ve seen with the sleep, but I can’t reliably reproduce the random container failures.

BTW - can you please “like” this post so it gets noticed by the devs?

Same here. It’s not easy to reproduce. Tried the build on my host and it went much quicker and had no issues at all. Even on the docker toolbox I had issues. Not sure how, but I’m likely overloading docker in some way…

So, this is still a problem with mac-v1.11.2-beta15

This look to be the relevant lines from the log file:

Jun 14 09:25:54 XYZ.local Docker[29487] <Notice>: System wants to go to sleep Jun 14 09:25:54 XYZ.local Docker[29487] <Notice>: Asking com.docker.hyperkit to freeze vcpus Jun 14 09:25:54 XYZ.local Docker[29487] <Notice>: vcpu 0 waiting for signal to resume Jun 14 09:25:54 XYZ.local Docker[29487] <Notice>: vcpu 1 waiting for signal to resume Jun 14 09:25:54 XYZ.local Docker[29487] <Notice>: vcpu freeze complete: allowing sleep Jun 14 09:32:44 XYZ.local Docker[29487] <Notice>: System wants to wake up Jun 14 09:32:44 XYZ.local Docker[29487] <Notice>: Asking com.docker.hyperkit to thaw vcpus Jun 14 09:32:44 XYZ.local Docker[29487] <Notice>: vcpu 0 received signal, resuming Jun 14 09:32:44 XYZ.local Docker[29487] <Notice>: vcpu 1 received signal, resuming Jun 14 09:32:44 XYZ.local Docker[29485] <Error>: Socket.Datagram.input <<<edited>>>:123: Lwt_bytes.send caught Unix.Unix_error(Unix.ENETDOWN, "send", "") Jun 14 09:32:44 XYZ.local Docker[29485] <Error>: DNS[803b] send failed with Unix.Unix_error(Unix.ENETDOWN, "send", "") Jun 14 09:32:44 XYZ.local Docker[29485] <Error>: DNS[8de7] send failed with Unix.Unix_error(Unix.ENETDOWN, "send", "") Jun 14 09:32:44 XYZ.local Docker[29487] <Notice>: Synchronizing time in VM Jun 14 09:32:49 XYZ.local Docker[29485] <Error>: DNS[803b] recv failed with Lwt.Canceled Jun 14 09:32:49 XYZ.local Docker[29485] <Error>: DNS[8de7] recv failed with Lwt.Canceled Jun 14 09:32:49 XYZ.local Docker[29485] <Error>: DNS[803b] timed out after 5s Jun 14 09:32:49 XYZ.local Docker[29485] <Error>: DNS[8de7] timed out after 5s Jun 14 09:33:38 XYZ.local Docker[29485] <Error>: server loop caught (Failure "Caught EOF on underlying FLOW"): no further requests will be processed Jun 14 09:33:38 XYZ.local Docker[29624] <Notice>: EOF reading packet from Unix domain socket: closing Jun 14 09:33:38 XYZ.local Docker[29624] <Critical>: Failed to read hello from client Jun 14 09:34:24 XYZ.local Docker[29687] <Notice>: EOF reading packet from Unix domain socket: closing Jun 14 09:34:24 XYZ.local Docker[29485] <Error>: server loop caught (Failure "Caught EOF on underlying FLOW"): no further requests will be processed Jun 14 09:34:24 XYZ.local Docker[29687] <Critical>: Failed to read hello from client


Question - how does this 100% reproducible bug NOT make it to the https://beta.docker.com/docs/mac/troubleshoot/#known-issues ???

I am also experiencing this issue. Except I don’t even suspend my laptop, I just lock the screen.

1 Like

Same here. Except that it’s kind of new with beta15. Had not the problem before.
It’s very annoying.

(also don’t know how to file a log as pinata disappeared also in beta15 ? being replaced by the diagnose menu in the docker app, which is kind of useless when it crashed :wink: )

Hi All, I have a Hackintosh and when i install docker for mac on the terminal throw me this Error when I was trying a Docker ps, I discover on my Bios virtual vtx that allow the processor (A I7 4790k in this case) have virtualization ! I enable this feature and it works!
Any Concern Let me know! !

LOL…

Sadly no win here. According to http://apple.stackexchange.com/a/120379:

It is always on in any Mac that has a processor that supports
virtualization. Pretty much any Mac in the last several years does so
you are good to go with this one.

…That was written 2014.

AND checking:
$ sysctl -a | grep machdep.cpu.features | grep VMX
shows that VMX is already part of my machine.

Hi all. I’ve just logged this on GitHub as issue #85 for Docker 1.12.

Please log on to GitHub and support the issue.

Is there already a workaround? (to let docker react again after sleep time)

Hi @cremersstijn - Please go over to Github (see link above!) and raise your questions there. I don’t think the docker team follows these boards… The only way we’re going to get any traction is to keep flagging this on github (please use the ticket for this issue!).

AFAIK - NO, there is still no fix. Apart from using docker-machine and virtualbox which run rock solid on my machine day-in, day-out.