Bug 1262796 - "docker pull submod/helloapache" does not complete
Summary: "docker pull submod/helloapache" does not complete
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: docker
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lokesh Mandvekar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-14 11:42 UTC by Marius Vollmer
Modified: 2015-12-01 19:11 UTC (History)
11 users (show)

Fixed In Version: docker-1.9.1-2.git78bc3ea.fc23.x86_64
Clone Of:
Environment:
Last Closed: 2015-12-01 19:11:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Marius Vollmer 2015-09-14 11:42:46 UTC
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 13:44:50 UTC
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 14:58:41 UTC
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 15:01:47 UTC
Lokesh we need to rebuild docker-1.8 with go1.4.  Can we do that?

Comment 4 Vincent Batts 2015-09-14 18:48:16 UTC
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 19:01:27 UTC
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 20:06:19 UTC
It builds fine ;-)

`make test` is in progress with it right now

Comment 7 Marius Vollmer 2015-09-15 06:28:28 UTC
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 09:10:02 UTC
> Can you explain why this happens always with certain images, and never with others?

Many layers?

Comment 9 Vincent Batts 2015-09-16 13:23:16 UTC
(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 06:56:00 UTC
Is this maybe fixed now?

Comment 11 Daniel Walsh 2015-09-28 11:22:15 UTC
You should have newer versions of docker to test against.

Comment 12 Daniel Walsh 2015-09-28 18:25:42 UTC
Fixed in docker-1.8.2

Comment 13 Christopher Beland 2015-12-01 19:11:01 UTC
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.