Bug 1262796 - "docker pull submod/helloapache" does not complete
"docker pull submod/helloapache" does not complete
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: docker (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lokesh Mandvekar
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-14 07:42 EDT by Marius Vollmer
Modified: 2015-12-01 14:11 EST (History)
11 users (show)

See Also:
Fixed In Version: docker-1.9.1-2.git78bc3ea.fc23.x86_64
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-01 14:11:01 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marius Vollmer 2015-09-14 07:42:46 EDT
Description of problem:

Executing 

    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):

docker-1.8.2-1.gitf1db8f2.fc23.x86_64

How reproducible:

Always

Steps to Reproduce:
1. docker pull submod/helloapache

Actual results:
Docker downloads some stuff and then hangs forever.

Expected results:
Docker either finishes the pull or produces an error message.
Comment 1 Daniel Walsh 2015-09-14 09:44:50 EDT
I have seen this behaviour before and I believe it is reported at docker, not sure what the fix is.
Comment 2 Vincent Batts 2015-09-14 10:58:41 EDT
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
Comment 3 Daniel Walsh 2015-09-14 11:01:47 EDT
Lokesh we need to rebuild docker-1.8 with go1.4.  Can we do that?
Comment 4 Vincent Batts 2015-09-14 14:48:16 EDT
https://github.com/vbatts/docker/commits/vbatts-1.8.2-cherry-pick
has commits for docker-1.8 to be compiled with go1.5 and not hit this concurrency issue.
Comment 5 Daniel Walsh 2015-09-14 15:01:27 EDT
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.

https://github.com/docker/docker/compare/v1.8.2...rhatdan:fedora-1.8
Comment 6 Vincent Batts 2015-09-14 16:06:19 EDT
It builds fine ;-)

`make test` is in progress with it right now
Comment 7 Marius Vollmer 2015-09-15 02:28:28 EDT
Thanks for the quick reaction!

Can you explain why this happens always with certain images, and never with others?
Comment 8 Stef Walter 2015-09-15 05:10:02 EDT
> Can you explain why this happens always with certain images, and never with others?

Many layers?
Comment 9 Vincent Batts 2015-09-16 09:23:16 EDT
(In reply to Marius Vollmer from comment #7)
> Can you explain why this happens always with certain images, and never with
> others?

I've not found the consistency consistent ;-)

Some days it will block on every image, other days it might make it through a few.
Comment 10 Marius Vollmer 2015-09-28 02:56:00 EDT
Is this maybe fixed now?
Comment 11 Daniel Walsh 2015-09-28 07:22:15 EDT
You should have newer versions of docker to test against.
Comment 12 Daniel Walsh 2015-09-28 14:25:42 EDT
Fixed in docker-1.8.2
Comment 13 Christopher Beland 2015-12-01 14:11:01 EST
Tested with docker-1.9.1-2.git78bc3ea.fc23.x86_64 and I can pull submod/helloapache and submod/atomicapp with no problems.

Note You need to log in before you can comment on or make changes to this bug.