Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v1.12.0-rc3: Unknown runtime specified default #24343

Closed
oleynikd opened this issue Jul 5, 2016 · 77 comments

Comments

@oleynikd
Copy link

commented Jul 5, 2016

Output of docker version:

Client:
 Version:      1.12.0-rc3
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   91e29e8
 Built:        Sat Jul  2 00:28:53 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.0-rc3
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   91e29e8
 Built:        Sat Jul  2 00:28:53 2016
 OS/Arch:      linux/amd64

Output of docker info:

Containers: 11
 Running: 0
 Paused: 0
 Stopped: 11
Images: 360
Server Version: 1.12.0-rc3
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 383
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay bridge host null
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor seccomp
Kernel Version: 3.19.0-25-generic
Operating System: Ubuntu 14.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 32
Total Memory: 62.89 GiB
Name: blade1
ID: RSHA:2HAV:XE3O:HTPX:3HVW:WXR2:IRBA:HU4A:KH5A:57RK:KGAC:GCSK
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Labels:
 provider=generic
Insecure Registries:
 127.0.0.0/8

Running:

docker-compose up -d

with the same docker-compose file that worked on v1.12.0-rc2 I get this:

Starting blades_redis_1
ERROR: for redis  Unknown runtime specified default
...

For all my containers...
What I missed?

@cpuguy83

This comment has been minimized.

Copy link
Contributor

commented Jul 5, 2016

@cpuguy83 cpuguy83 added this to the 1.12.0 milestone Jul 5, 2016

@oleynikd

This comment has been minimized.

Copy link
Author

commented Jul 5, 2016

Recreating all containers solved the issue 👹

@justinschier

This comment has been minimized.

Copy link

commented Jul 5, 2016

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.

@javawolfpack

This comment has been minimized.

Copy link

commented Jul 5, 2016

That's annoying... Just got this error myself too right after upgrading.

@derosm2

This comment has been minimized.

Copy link

commented Jul 5, 2016

Just came to report the same issue. Was hoping not to have to recreate my existing containers.

@loop0

This comment has been minimized.

Copy link

commented Jul 5, 2016

Same problem here!

@cpuguy83

This comment has been minimized.

Copy link
Contributor

commented Jul 5, 2016

I bet we changed the default between rc2 and rc3, and that default was saved on the container config.

@browningeric

This comment has been minimized.

Copy link

commented Jul 5, 2016

Appears the location of saved container data changed OR the upgrade blew away the old container volumes. At least on my machine.

@cpuguy83

This comment has been minimized.

Copy link
Contributor

commented Jul 5, 2016

The the location of it, but rather the value of a field.

@browningeric

This comment has been minimized.

Copy link

commented Jul 5, 2016

Running docker volume inspect data_container_name outputs something similar to:

[
    {
        "Name": "data_container_name",
        "Driver": "local",
        "Mountpoint": "/var/lib/docker/volumes/data_container_name/_data",
        "Labels": null,
        "Scope": "local"
    }
]

However, the folder /var/lib/docker/volumes/data_container_name/_data does not exist on my machine. Or is there another place that it stores the volumes on mac?

@lielran

This comment has been minimized.

Copy link

commented Jul 5, 2016

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
@cpuguy83

This comment has been minimized.

Copy link
Contributor

commented Jul 5, 2016

@browningeric This has not changed at all. Volumes are stored in the VM, not on your Mac.

@CyrilPeponnet

This comment has been minimized.

Copy link

commented Jul 5, 2016

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.

@jonathan-robertson

This comment has been minimized.

Copy link

commented Jul 5, 2016

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
@victorgama

This comment has been minimized.

Copy link

commented Jul 5, 2016

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
@lielran

This comment has been minimized.

Copy link

commented Jul 5, 2016

what/who is jack anyway ?

maybe Hijack without the first two chars?
docker/compose#3685

@pdougall1

This comment has been minimized.

Copy link

commented Jul 5, 2016

yeah, a quick google showed me this docker/compose#3685

Makes me think jack is really a nice greeting "Hi Jack"

@lielran

This comment has been minimized.

Copy link

commented Jul 5, 2016

💣

screen shot 2016-07-05 at 11 47 54 pm

@rodolfobarretoweb

This comment has been minimized.

Copy link

commented Jul 5, 2016

Same problem here!

@pedrofernandezm

This comment has been minimized.

Copy link

commented Jul 5, 2016

Same issue here. Removing containers and recreating them didn't work for me.

@icecrime

This comment has been minimized.

Copy link
Contributor

commented Jul 5, 2016

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.

@axelx5

This comment has been minimized.

Copy link

commented Jul 5, 2016

Same problem here!

@andymcintosh

This comment has been minimized.

Copy link

commented Jul 5, 2016

Recreating containers left me with the same issue as @victorgama

@rodolfobarretoweb

This comment has been minimized.

Copy link

commented Jul 5, 2016

Reset to factory defaults fix this problem

@djfarrelly

This comment has been minimized.

Copy link

commented Jul 5, 2016

@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
@vladimir-kazan

This comment has been minimized.

Copy link

commented Jul 5, 2016

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

@CyrilPeponnet

This comment has been minimized.

Copy link

commented Jul 5, 2016

@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.

@sungsong88

This comment has been minimized.

Copy link

commented Jul 5, 2016

Same problem here... I had to run 'docker rm' to remove all stopped containers, and then my docker-compose worked.
And of course, my databases is gone too. =p. Thank god I have a dump.

@NotBobTheBuilder

This comment has been minimized.

Copy link

commented Jul 6, 2016

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

@fernandomora

This comment has been minimized.

Copy link

commented Jul 6, 2016

Does build 9996 fix this "Unknown runtime specified default" error without the need to recreate all containers?

@cpuguy83

This comment has been minimized.

Copy link
Contributor

commented Jul 6, 2016

The hijack, or rather "jack" issue is completely separate. It is specific to docker4mac/win. You either must downgrade or wait for a patch.

@dlgoodchild

This comment has been minimized.

Copy link

commented Jul 6, 2016

Downgrading seems to have been the only solution for our team also.

@Dynom

This comment has been minimized.

Copy link

commented Jul 6, 2016

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

@trentmswanson

This comment has been minimized.

Copy link

commented Jul 6, 2016

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.

@cpuguy83

This comment has been minimized.

Copy link
Contributor

commented Jul 6, 2016

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

@ivancevich

This comment has been minimized.

Copy link

commented Jul 6, 2016

FYI, I've installed the latest Version 1.12.0-rc3-beta18 (build: 9996) ec40b14c72adc0bff3b01fa8886dae7f2eee1541 on OS X 10.11.5 (15F34) and I still get Error response from daemon: Unknown runtime specified default. Had to recreate all containers as well.

@antipin

This comment has been minimized.

Copy link

commented Jul 6, 2016

Docker version 1.12.0-rc3, build 91e29e8, experimental

Reseted to factory defaults, rebuild all images

Still has it:

Creating api_data_1
Creating api_db_1
Creating api_api_1
Attaching to api_data_1, api_db_1, api_api_1
db_1    | jack is incompatible with use of CloseNotifier in same ServeHTTP call
api_1   | jack is incompatible with use of CloseNotifier in same ServeHTTP call
data_1  | jack is incompatible with use of CloseNotifier in same ServeHTTP call
api_data_1 exited with code 0
@MicahZoltu

This comment has been minimized.

Copy link
Contributor

commented Jul 6, 2016

How does one get the new version? When I tell Docker for Mac to check for updates it says it has the latest at 1.12.0-rc3-beta18 but when I look at Docker > About it says 1.12.0-rc3-beta18 (build: 9969).

@cpuguy83

This comment has been minimized.

Copy link
Contributor

commented Jul 6, 2016

@Zoltu It's been pulled and beta17 is what's currently "latest".

@tylfin

This comment has been minimized.

Copy link

commented Jul 6, 2016

Version 1.12.0-rc3-beta18 (build: 9996) having the same error

ERROR: for db  Unknown runtime specified default
ERROR: Encountered errors while bringing up the project.
@cpuguy83

This comment has been minimized.

Copy link
Contributor

commented Jul 6, 2016

@tylfin See the comments above. To "fix" the problem, you must re-create containers that are having the issue.
For compose, this means using --force-recreate

@krihelis

This comment has been minimized.

Copy link

commented Jul 6, 2016

I have just upgraded to the latest version 1.12.0-rc3-beta18 (build: 9996), but I'm still not sure about the containers recreation workaround.
How do I recreate the containers? Can someone please add the exact commands that I need to run?

@antipin

This comment has been minimized.

Copy link

commented Jul 6, 2016

@krihelis uninstall it (Preferences -> Uninstall) and download beta-17 from offsite https://download.docker.com/mac/beta/Docker.dmg

@krihelis

This comment has been minimized.

Copy link

commented Jul 6, 2016

@antipin, what about the containers? Will they be removed?

@antipin

This comment has been minimized.

Copy link

commented Jul 6, 2016

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

@cpuguy83

This comment has been minimized.

Copy link
Contributor

commented Jul 6, 2016

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!

@alexgorbatchev

This comment has been minimized.

Copy link

commented Jul 7, 2016

beta 18 also completely broke my env... downloading beta 17 and doing a full reset fixed my issue

@DannyMoerkerke

This comment has been minimized.

Copy link

commented Jul 8, 2016

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

@zedd45

This comment has been minimized.

Copy link

commented Jul 8, 2016

I was able to run docker-compose -f file.ext up --force-recreate after rebooting my Mac, and it "just worked."

OS X: 10.11.5
Docker: Version 1.12.0-rc3-beta18 (build: 9996)
ec40b14c72adc0bff3b01fa8886dae7f2eee1541

@ajaali

This comment has been minimized.

Copy link

commented Jul 9, 2016

I got the previous version of docker from my Trash folder "Docker (9779)"
Steps:

  1. Move Docker (9779) from Trash to Desktop
  2. Right click on the Docker (9779) icon and click on "show package contents"
  3. Go to the Contents->MacOS folder
  4. Run Docker
@dlgoodchild

This comment has been minimized.

Copy link

commented Jul 9, 2016

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.

@ajaali

This comment has been minimized.

Copy link

commented Jul 9, 2016

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.

@jfscoertzen

This comment has been minimized.

Copy link

commented Jul 11, 2016

I replaced docker with an old version on my mac and it worked again. Remember to keep your old downloads.

@thaJeztah

This comment has been minimized.

Copy link
Member

commented Jul 11, 2016

@jfscoertzen @ajaali please have a look at #24343 (comment). Reverting to an older version of docker is not a solution here, because RC2 used a runtime name that will not be used in the GA release. Re-creating containers that were started using RC2, or updating their config using the steps explained in #24343 (comment) is the right solution.

@qxhy123

This comment has been minimized.

Copy link

commented Jul 12, 2016

same here.

@immatt2015

This comment has been minimized.

Copy link

commented Jul 13, 2016

same problem

@cpuguy83

This comment has been minimized.

Copy link
Contributor

commented Jul 13, 2016

@qxhy123 @immatt2015 Please read the thread, specifically: #24343 (comment)

To remediate the issue you'll either need to recreate your containers or run #24343 (comment)

I'm locking this issue as this is all that can be done.

@moby moby locked and limited conversation to collaborators Jul 13, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
You can’t perform that action at this time.