Force docker client to retry pulling layers

Archive Open Source Registry API
1

According to the API document,

If an 502, 503 or 504 error is received, the client should assume that the download can proceed due to a temporary condition, honoring the appropriate retry mechanism. Other 5xx errors should be treated as terminal.

However docker pull does not honor this.

Using default tag: latest
latest: Pulling from library/elasticsearch
cd0a524342ef: Already exists
e39c3ffe4133: Pulling fs layer
aac3320edf40: Pulling fs layer
4d9e109682f7: Pulling fs layer
0a59efcf9553: Waiting
43a404e523e0: Waiting
806f07b1dce8: Waiting
97180523aa1a: Waiting
aa1f5d9e6a71: Waiting
6614709b45b0: Waiting
57c789d0d832: Waiting
ff71476adf84: Waiting
b25e5bf09b66: Waiting
e63a496f6878: Waiting
error pulling image configuration: received unexpected HTTP status: 503 Service Unavailable```

The implementation does not seem to follow the API spec. [1][2]

Is there a way in HTTP to notify the daemon to retry?


[1] https://github.com/docker/distribution/blob/717134d7c22e4638e170a61362c75fab0db1ccb5/registry/client/errors.go#L41

[2]https://github.com/moby/moby/blob/254fc83cba90ed79c78f4cb0cb33aeeaff492798/distribution/errors.go#L144
2

Hello there,

It’s either that their backend has a problem or your connection has problems.
Anyway, please do try removing all your images first and retrying:
docker rmi $(docker images -q)

**WARNING: Do not use that command if you have images that you want to retain. If so, please remove the image in your own style

Regards,
CrAzYz_ (Zypeth)

3

I used a proxy to mock 503 http status when the daemon fetches each layer, so it is not about connection. It is surprising to see that the docker daemon to not actually retry. @zypeth

4

Hello there,

Well, that’s smart of you. But in general, if a web server has already reported a 503, it shouldn’t retry again as it causes more connections to be opened and more chaos for it to handle.

I personally don’t think it is a bug or error.

Regards,
CrAzYz_ (Zypeth)

5

503 responses can contain a header to let the client know how much time to wait before retrying, but it seems that the server and client don’t use it.