Docker Community Forums

Share and learn in the Docker community.

`docker pull` can't resume when killed with spotty internet


(Cole Mickens) #1

Expected behavior

docker pull can be ctrl-cd and executed again and docker daemon will continue where it left off.

Actual behavior

I’m on Gogo right now (it’s slow and spotty). I try to pull an image. It gets some percentage of the way done and then just stops. If I kill the docker pull invocation and then try to run it again, it picks up where it left off but it never proceeds further than where I killed it. I have to actually restart Docker in macOS (aka the VM) before it will pull anything. Of course, that starts the layer over, so I’m basically unable to ever get the layer (until I land at least).

Information

  • the output of:
    • Moby Menu > Diagnose & Feedback on OSX
Docker for Mac: version: mac-v1.11.2-beta15
OS X: version 10.11.5 (build: 15F34)
logs: /tmp/20160618-190819.tar.gz
failure: No error was detected
[OK]     docker-cli
[OK]     app
[OK]     menubar
[OK]     virtualization
[OK]     system
[OK]     osxfs
[OK]     db
[OK]     slirp
[OK]     moby-console
[OK]     logs
[OK]     vmnetd
[OK]     env
[OK]     moby
[OK]     driver.amd64-linux
  • a reproducible case if this is a bug, Dockerfiles FTW
    n/a
  • page URL if this is a docs issue or the name of a man page
    n/a
  • host distribution and version ( OSX 10.10.x, OSX 10.11.x, Windows, etc )
    OS X 10.11.5 (15F34)

Steps to reproduce the behavior

  1. Start a docker image pull with fairly slow/spotty internet.
  2. Wait until the download stalls and stops (even though other Internet works).
  3. Ctrl-c the docker pull
  4. Start the docker pull again
  5. Notice that it doesn’t ever proceed past where it was when you killed it.

Meta

It’d be nice if I could open the forums without clobbering my clipboard (re: “Copy diag id to clipboard and open forum” button). Plus this template doesn’t even ask for the Diagnostics ID.

And my Diagnostic ID is 8337D04F-39A8-42F9-83C3-994544794087.


(Nagu) #2

me too. this is the output i get when i try to redo a pull on an image that was earlier interrupted due to bad internet connection:

docker@default:~$ docker pull jupyter/minimal-notebook
Using default tag: latest
latest: Pulling from jupyter/minimal-notebook
8b87079b7a06: Already exists
a3ed95caeb02: Already exists
b7837d46e7ab: Already exists
662ca9fe7b05: Already exists
97953f27b77a: Already exists
a1d35087ecd0: Already exists
c4db12d2b839: Already exists
b322dbef1dd0: Already exists
67eb38a48022: Already exists
e0ffb6fc1d47: Already exists
9475bfdcc016: Already exists
77e33b354adc: Already exists
ab0a9f379c27: Already exists
3b283206c60e: Already exists
df886c3898cb: Downloading [=================================>                 ]   412 MB/615.1 MB
docker@default:~$ 

the interrupted download can never seem to be able to go past the 412MB mark.
my environment:
docker-toolbox: 1.10.3
host: windows 7


(Hosseinagha) #3

I think I’m going to stop using docker because of this.
This is not logical at all having to re download a 2GB docker image every time.


(Nick Reilingh) #4

+1 from me, but I’m actually using Docker for Windows inside a VMware Fusion on a Mac. I don’t know if that’s what’s causing the spotty connection (I get the same thing happening whether I’m using bridged or NAT networking), or if my host machine would have the same problem. Since I’m trying to download a windows container, I can’t actually use a docker pull on the image from the mac side, so right now I’ve spun up an AWS EC2 instance for the sole purpose of pulling this image, doing a docker save to a tar file, and then transferring it to my VM through other means.

Just to be clear, the behavior we are seeing is that any fully loaded fs layers are not re-downloaded, but if a layer stalls and is cancelled, it will ALWAYS restart from the beginning instead of resuming where it left off. I can usually download between 20-100 MB at a time successfully, but this windows layer is 4GB so I’m just never getting anywhere close.