Description of problem:
docker pull submod/helloapache
seems to download all the bits but never finishes. The same happens for the "submod/atomicapp" image. Other images such as "busybox" can be pulled without issues.
Interrupting the hung "docker pull" and then executing "docker images" shows that the image has not been given a name:
# docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
<none> <none> ef54e4f90619 2 weeks ago 255.4 MB
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. docker pull submod/helloapache
Docker downloads some stuff and then hangs forever.
Docker either finishes the pull or produces an error message.
I have seen this behaviour before and I believe it is reported at docker, not sure what the fix is.
this is likely the concurrency issue from docker-1.8 built with go1.5
Not a but in go1.5, but poor concurrency patterns in docker, that are expressed by improvements in go1.5.
docker-1.8 needs to pin to go1.4
Lokesh we need to rebuild docker-1.8 with go1.4. Can we do that?
has commits for docker-1.8 to be compiled with go1.5 and not hit this concurrency issue.
Ok I just pushed a new version of fedora-1.8 packages to git, with your cherry pick changes.
Vincent could you take a look.
It builds fine ;-)
`make test` is in progress with it right now
Thanks for the quick reaction!
Can you explain why this happens always with certain images, and never with others?
> Can you explain why this happens always with certain images, and never with others?
(In reply to Marius Vollmer from comment #7)
> Can you explain why this happens always with certain images, and never with
I've not found the consistency consistent ;-)
Some days it will block on every image, other days it might make it through a few.
Is this maybe fixed now?
You should have newer versions of docker to test against.
Fixed in docker-1.8.2
Tested with docker-1.9.1-2.git78bc3ea.fc23.x86_64 and I can pull submod/helloapache and submod/atomicapp with no problems.