moby: `pull` gets stuck waiting for a layer

Output of docker version:

Client:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.6.2
 Git commit:   5604cbe
 Built:        Wed Apr 27 15:27:26 UTC 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   5604cbe
 Built:        Wed Apr 27 00:34:20 2016
 OS/Arch:      linux/amd64

Output of docker info:

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 1.11.1
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 2
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge null host
Kernel Version: 4.4.8-boot2docker
Operating System: Boot2Docker 1.11.1 (TCL 7.0); HEAD : 7954f54 - Wed Apr 27 16:36:45 UTC 2016
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 3.858 GiB
Name: default
ID: Y4GM:7ZGQ:XL7U:BGRR:R6ZR:7SDJ:P4WX:ENZD:6KCV:CYS7:TBM2:4FUZ
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug mode (client): false
Debug mode (server): true
 File Descriptors: 30
 Goroutines: 152
 System Time: 2016-05-09T12:25:32.911333681Z
 EventsListeners: 0
Registry: https://index.docker.io/v1/
Labels:
 provider=virtualbox

Additional environment details (AWS, VirtualBox, physical, etc.):

Steps to reproduce the issue:

  1. Have a lot of layers to pull. (For example, my docker-compose.yml file has six images, some with fairly many layers, like rabbitmq:3.5.7-management.)
  2. Do docker-compose pull. Note that sometimes, but not always, pull gets stuck waiting for a layer.
  3. Restart the docker machine.
  4. Do docker pull manually for all the images you need. Note that sometimes, but not always, pull gets stuck waiting for a layer (thus demonstrating the problem isn’t with docker compose).

Describe the results you received:

3.5.7-management: Pulling from library/rabbitmq
d4bce7fd68df: Downloading 50.86 MB/51.35 MB
a3ed95caeb02: Download complete
c0330dd9a641: Download complete
55756666188f: Download complete
c14677369432: Download complete
26af78564017: Download complete
bd6129eb0c93: Download complete
5effe88cea3c: Download complete
c393a181c961: Download complete
76ed1a563002: Download complete
be99def8c8f1: Download complete
281661af86b4: Download complete
bc1e7dd06368: Download complete
4a321db4bb32: Download complete
c3ed9562f00a: Download complete

That first layer, d4bce7fd68df, has been at 50.86 MB for about 8 minutes now. I’ve attempted to wait this out before. The longest I waited was over an hour.

Describe the results you expected:

Ideally, the pull should simply not hang. Barring that, it should die with an error so that I can understand the problem and work on automations for working around it.

Additional information you deem important (e.g. issue happens only occasionally):

This issue does not happen on every pull, and it doesn’t happen on the same layers every time. It happens more frequently on my home network than it does at work, but it has happened in both places. Restarting the entire docker machine (docker-machine restart default) is more effective at kicking the can than just killing and restarting the pull itself.

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 3
  • Comments: 27 (19 by maintainers)

Most upvoted comments

Docker for Windows (beta). Happening a lot pulling from GitLab.

Happens quite often for us at company. Multiple daemon restarts helps for a while.

@samdark @Redundancy if using Docker for Windows, if you haven’t already, can you please run the built-in diagnostics and open issues with details that reproduces the problem (eg. what image are you pulling and so on) on the Docker for Windows issue tracker: https://github.com/docker/for-win/issues/new

Having the same issue. Docker for Windows.

@schmunk42 I see you mention vagrant working, but perhaps worth checking https://github.com/docker/docker/issues/27734 (and https://www.virtualbox.org/ticket/16084)