Download URLs for Beta 17, in case anyone wants to go back: Mac: https://download.docker.com/mac/beta/1.12.0.9779/Docker.dmg Win: https://download.docker.com/win/beta/1.12.0.5022/InstallDocker.msi

I agree with @oleynikd - I had to run docker-compose down -v to remove the old containers, then when I brought the containers back up, everything started working again.

I’ve create a hack to work-around this problem for people who really can’t re-create their containers. First, you must be on 1.12-rc3 (so beta 18 of docker4mac). If you have downgraded this will not help you. If you are not on docker 1.12-rc3 this will make it so your containers will not start!!!

Simply run docker run --rm -v /var/lib/docker:/docker cpuguy83/docker112rc3-runtimefix:rc3 and then restart docker. You must restart docker afterwards otherwise the changes will not take affect*. Source is here: https://github.com/cpuguy83/docker112rc3-runtimefix

From the repo:

First and foremost, this tool is a HACK. It is offered without guarantee or support! It modifies files generally considered private to the docker daemon!

💣

Thank for the reports: the issue is acknowledged. We had a breaking change between 1.12.0-RC2 and 1.12.0-RC3 (introduced by #23775).

We’re discussing what’s the best way forward here. In the meantime, recreating your containers will solve the issue.

Recreating all containers solved the issue 👹

I try to reset to factory defaults, remove and buil again. But I get the same issue when a try to run

http: Hijack is incompatible with use of CloseNotifier in same ServeHTTP call

I’m using OS X

related issues: https://github.com/docker/engine-api/issues/303 https://github.com/docker/docker/issues/12845

Attempted to stop, remove and recreate containers as @puddingfactory mentioned, but docker-compose up still brings this error:

jack is incompatible with use of CloseNotifier in same ServeHTTP call

Reset to factory defaults fix this problem

As someone whose osx username is jack this was an extremely confusing issue

same issue after upgrade to Version 1.12.0-rc3-beta18 (build: 9969)

Starting hibob_redis_1
Starting hibob_elasticsearch_1
Starting hibob_postgres_1

ERROR: for elasticsearch  Unknown runtime specified default

ERROR: for redis  Unknown runtime specified default

ERROR: for postgres  Unknown runtime specified default
ERROR: Encountered errors while bringing up the project.
ERROR: Encountered errors while bringing up the project.

same images running fine via docker run …

also docker-compose down or docker rm -f $(docker ps -qa) did remove the old images and now i get this errors:

Creating hibob_redis_1
Creating hibob_elasticsearch_1
Creating hibob_postgres_1
Attaching to hibob_redis_1, hibob_postgres_1, hibob_elasticsearch_1
redis_1          | jack is incompatible with use of CloseNotifier in same ServeHTTP call
postgres_1       | jack is incompatible with use of CloseNotifier in same ServeHTTP call
elasticsearch_1  | jack is incompatible with use of CloseNotifier in same ServeHTTP call

Recreating containers left me with the same issue as @victorgama

Is there a way at least to retrieve the data inside the old containers?

EDIT: Restoring from the trash works for me. At least I will be able to save data.

It is unfortunate that the latest version didn’t work, yes, but we are on a beta program here; the risk should be well understood. Also, if you’re potentially going to lose data, I suspect you’re not using containers in the most ideal way. You should mount you vulnerable data as a volume on the host so you aren’t at risk of losing anything.

A new fix is out (Version 1.12.0-rc3-beta18 (build: 9996)) Thanks for working this fast guys!

Just updated to beta 18, docker-compose down -v solved it for me.

Also experienced this issue. Docker should have release circles like Microsoft has for Windows and make their developers use the build first, so that, problems like this one get rectified before the build is released to the public.

So, looking in more details, it’s clear that this change is due to #23775. We’ll be discussing if this requires an extra patch to prevent errors for unknown runtimes. Discussion has started in #24345 for those interested.

That being said, in the particular case of the Docker 4 Mac Beta, there is unfortunately nothing we can do but advise to recreate your containers. Indeed, Docker 4 Mac is still a beta, and as part of it we made the deliberate choice to distribute the RC builds of the Docker Engine. Although we work hard to make sure all releases are fully backward-compatible, it is not the case for RC releases. The ability to iterate fast during code freeze, sometimes in a non backward-compatible manner, and collect feedback from you (thanks!) is necessary for us to ship the best possible stable version in the end.

I’m closing this as a it is pointing at an incompatibility between two successive RC, which is not guaranteed. Obviously, incompatibility between two successive stable releases would have been considered a bug.

In case you’d want to revert to the previous Docker 4 Mac Beta:

Mac: https://download.docker.com/mac/beta/1.12.0.9779/Docker.dmg Win: https://download.docker.com/win/beta/1.12.0.5022/InstallDocker.msi

Thanks again for the reports.

Same issue on OSX, recreating contains did not solve the issuel. However my error is missing the “Hi” in the word Hijack

db1       | jack is incompatible with use of CloseNotifier in same ServeHTTP call
mirth1  | jack is incompatible with use of CloseNotifier in same ServeHTTP call
stunnel1    | jack is incompatible with use of CloseNotifier in same ServeHTTP call

@dfarrell07 I found it simpler to restore the old one from the trash 😃 but yeah I was also looking at data volume just in case.

@CyrilPeponnet You can use docker inspect to find your existing containers data volume and mount that volume by name into a new container with the same image. Helped me bring my dev mongo container back up and dump the data from the new container. Example:

docker run --name mongobak -v a52847d484b6375a674debe8a3fa011ef8a8069d0139952648e5063085d66b51:/data/db -P mongo:2.6.8

Same problem here!

I just installed Version 1.12.0-rc3-beta18 (build: 9996) and this seems to have caused the problem for me here Error response from daemon: Unknown runtime specified default. Had to delete/re-create and all is well now.

@krihelis I have downgraded. You find the old version in your trash.

I reset to factory defaults, then tried docker-compose up again, watched containers download, then saw the issue persist. Let me see if I can find a little bit to cut-and-paste:

Pulling rethinkdb (float/rethinkdb:latest)...
latest: Pulling from float/rethinkdb
c02c7df4a131: Pull complete
a3ed95caeb02: Pull complete
4acc5a0bbe02: Pull complete
e2c4c079e657: Pull complete
93563bc74311: Pull complete
76e91ce8b6dc: Pull complete
Digest: sha256:babb90d8d4e124ec873218bb5a7f8e8980d6f791e37d6615eff76e7aa60b8ace
Status: Downloaded newer image for float/rethinkdb:latest
Pulling rethinkdbproxy (float/rethinkdb_proxy:latest)...
latest: Pulling from float/rethinkdb_proxy
c02c7df4a131: Already exists
a3ed95caeb02: Already exists
4acc5a0bbe02: Already exists
e2c4c079e657: Already exists
93563bc74311: Already exists
76e91ce8b6dc: Already exists
Digest: sha256:742ee109cdb654fb30dcffa7e0b4537679a768f17d74e37f8dd8a93e81d99db9
Status: Downloaded newer image for float/rethinkdb_proxy:latest

… (more containers downloading)

rethinkdb_1       | jack is incompatible with use of CloseNotifier in same ServeHTTP call
rethinkdbproxy_1  | jack is incompatible with use of CloseNotifier in same ServeHTTP call

Again, this was after a reset to factory defaults (hence, the containers downloading).

Reset to factory defaults DOES NOT fix problem with debian:wheezy based container.

ugh, same here (not using docker compose) after updating to 1.12.0-rc3

$ docker start myredis
Error response from daemon: Unknown runtime specified default
Error: failed to start containers: myredis

$ docker ps -a | grep myredis
49e433d0c3d2        redis               "docker-entrypoint.sh"    13 days ago         Exited (0) About an hour ago                       myredis

Here’s what I did to delete all of my containers and then I recreated just the one I needed right now. _Ref: https://coderwall.com/p/ewk0mq/stop-remove-all-docker-containers_

1. Stop all containers: docker stop $(docker ps -a -q)
2. Delete all containers: docker rm $(docker ps -a -q)
3. Recreated my REDIS container: docker run --name myredis -d -p 6379:6379 redis

dlgoodchild, I do agree with both your points, and its just frustration and panic at losing my dev databases and having to start again. Sorry. I edited my previous post to only include the useful information.

@krihelis unfortunately yes, but what’s the big deal to rebuild them?

Yes, the new build is specifically for fixing the “Hijack is incompatible with use of Close Notifier” issue, which is specific to docker4mac/windows.

The issue that the OP posted here is not fixed and is just a breaking change between Docker 1.12-RC2 and 1.12-RC3

Recreation “doesn’t work for me” either, however the containers do actually get started! This is my current work-around:

$ docker-compose up --force-recreate
Starting projectx_postgres_1
Starting projectx_recommendation_1
Starting projectx_users_1
Starting projectx_pre_1
Starting projectx_eventlog_1
Starting projectx_web_1
Starting projectx_photo_1
Starting projectx_imaginary_1
Attaching to projectx_web_1, projectx_recommendation_1, projectx_eventlog_1, projectx_postgres_1, projectx_pre_1, projectx_photo_1, projectx_users_1, projectx_imaginary_1
web_1             | jack is incompatible with use of CloseNotifier in same ServeHTTP call
recommendation_1  | jack is incompatible with use of CloseNotifier in same ServeHTTP call
eventlog_1        | jack is incompatible with use of CloseNotifier in same ServeHTTP call
postgres_1        | jack is incompatible with use of CloseNotifier in same ServeHTTP call
pre_1             | jack is incompatible with use of CloseNotifier in same ServeHTTP call
photo_1           | jack is incompatible with use of CloseNotifier in same ServeHTTP call
users_1           | jack is incompatible with use of CloseNotifier in same ServeHTTP call
imaginary_1       | jack is incompatible with use of CloseNotifier in same ServeHTTP call
^CGracefully stopping... (press Ctrl+C again to force)
Stopping projectx_users_1 ... done
Stopping projectx_web_1 ... done
Stopping projectx_recommendation_1 ... done
Stopping projectx_eventlog_1 ... done
Stopping projectx_photo_1 ... done
Stopping projectx_imaginary_1 ... done
Stopping projectx_postgres_1 ... done
Stopping projectx_pre_1 ... done

The work-around

$ docker-compose up -d
Starting projectx_postgres_1
Starting projectx_recommendation_1
Starting projectx_users_1
Starting projectx_pre_1
Starting projectx_eventlog_1
Starting projectx_web_1
Starting projectx_photo_1
Starting projectx_imaginary_1

$ docker-compose logs

This put me roughly in the same situation. The containers are actually running, I can connect to it and everything, but the logs won’t be attached like when you normally just run docker-compse up.

The Mac link in https://github.com/docker/docker/issues/24343#issuecomment-230623542 worked for me. Just recreating the containers via first removing via docker rm didn’t work.

Had to quit docker before dragging the app from the dmg into applications and restarting.

Then had to run docker-compose up --force-recreate to get around the ‘runc’ related error.

yeah, a quick google showed me this https://github.com/docker/compose/issues/3685

Makes me think jack is really a nice greeting “Hi Jack”