Unexpected EOF is not really unexpected with dockers default timeout on pulls

Ahoi,

first and foremost, i want to say that i’ve probably read all topics about unexpected EOF on the interwebs already and it was quite frustrating to never see a real solution.

Most of the unexpected EOF issues probably occur because of firewalls, proxy servers or whatever else that makes the download of the layers unexpectedly slow for the docker daemon.

I’ve this issue too. But only with larger layers and i can never download these layers because our corporate proxy sends a very very slow data stream until it’s done scanning the files.

On RHEL when we’re using yum for example, we need to add to lines to the yum.conf

minrate=1
timeout=500

minrate lowers the expected data transfer speed to a very low threshold, so our download speed during the scan process of the proxy doesn’t result in a timeout on yum’s end.
timeout isn’t as important here, since minrate already does the job most of the time.

Anyhow, i cannot find an option to increase the timeout of pull commands for the docker daemon. If there is could anyone please push me into the right direction or has any other solution on hand?

I would really appreciate an answer :slight_smile:

Not an expert on docker pull requests but --max-concurrent-downloads set to 1 may help with timeout issues. Or, a workaround is that you can get the image somehow to the computer and then do a docker load command on it.

Thanks for the Reply David!

Yea i figured the manual method already but the max-concurrent-downloads is new to me, will try that out!