search

docker / cli

The Docker CLI
Apache License 2.0
4.85k stars 1.91k forks source link

ERROR: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:35711->[::1]:53: read: connection refused #2618

Closed hessam94 closed 10 months ago

hessam94 commented 4 years ago

hi, I installed docker on Android and sudo docker version works fine and shows Client and Server available. but any kind of command , such as hello-world, pull, push, build, etc returns me this error. this is my command sudo docker build -t img1 . ERROR: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:35711->[::1]:53: read: connection refused

i am working on Android and do not have systemd, systemctl to start restart service, i used dockerd to start daemon and it started with no error i am not sure if there is any firewall proxy on android, how can i evaluate it? please help me i really need it

thaJeztah commented 4 years ago

looks like it's trying to connect to IPv6 localhost for DNS resolution.

note that Android is currently not a supported platform for Docker (at least very much untested).

Does it work if you configure the host to use (e.g.) 8.8.8.8 as primary DNS server (not sure how it's configured in your environment, on linux it would usually be done through /etc/resolv.conf

hessam94 commented 4 years ago

Hello again, tried to set DNS on android, by sudo setprop dns1 8.8.8.8 and sudo setprop dns1 8.8.4.4 . and getprop also returns correctly. but still have connection refuse problem. there is not /etc/resolv.conf on android9 !!! no idea how to solve this problem , i have limited time, please help me. thanks

hessam94 commented 4 years ago

I took this screen shot after setting my DNS, any Idea guys?? Screenshot_20200703-174541

lemmy04 commented 3 years ago

I'm having the same issue on openSUSE Leap 15.2, but only on the first attempt to pull an image after boot. my /etc/resolv.conf is fine, configured by DHCP.

What happens here is the docker daemon trying to contact ::1 as nameserver, via IPv6, and totally ignores what is actually configured in /etc/resolv.conf... why?

lemmy04 commented 3 years ago

Interesting detail:

after the first fail the issue "repairs itself" - after waiting for ...maybe a minute or so the next attempt to pull an image works. But if I try again right after the first fail, it fails again. On the other hand, it does not matter how long the system has been up - the first pull fails, the next one fails if tried too soon afte the fail, then it works until reboot.

Someone please explain o.0

hessam94 commented 3 years ago

have you set nameserver 8.8.8.8 nameserver 8.8.4.4 in your /etc/resolv.conf?

lemmy04 commented 3 years ago

i already said that my /etc/resolv.conf is fine - everyting else and their dog is perfectly able to resolve hostnames. You do realize that with the settings that you suggest the system will be unable to resolve hostnames for local adresses?

Anyway, I found something: the systems here that show this problem all run NetworkManager for the network, the ones that dont have static (manually) configured network. So .. I changed the start of the docker unit file to include "NetworkManager-wait-online.service" in the "After=" line, and nof the problem doesn't happen anymore. Seems that when dockerd is "normally" started, networkmanager isn't up yet so docker can'T find the DNS in /etc/resolv.conf, and just assumes ::1 instead. But on the second try it uses what's in resolv.conf by then, which is the properly configured dns.

mkozjak commented 3 years ago

Just saw this on aarch64, Debian Buster. This is a wreck.

davewood commented 3 years ago

had the same error and kept re-running the command docker-compose up db which attempts to pull the mariadb container. I didnt change a thing and the 5th try succeeded.

pie-r commented 3 years ago

re-trying N times, each time it works.

Now I tried to set the nameserver 8.8.8.8

cdauth commented 3 years ago

Same problem on Arch Linux. Rerunning the command helps, usually it succeeds with the 2nd or 3rd try.

andreaagongora commented 3 years ago

Same problem on Arch Linux. Rerunning the command helps, usually it succeeds with the 2nd or 3rd try.

Hi, what command helps did you use?, I have the same error in Arch linux

cdauth commented 3 years ago

It usually happens to me when I'm pulling an image using docker-compose pull. I just rerun the command again and again until it works by itself.

GavinFF-SS commented 3 years ago

having same issue just uninstalled pihole and set my pi to use google dns and Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 127.0.0.1:53: read udp 127.0.0.1:40185->127.0.0.1:53: read: connection refused error

muuvmuuv commented 3 years ago

Having some kind of the same, and I am able to resolve the address, just docker cannot:

error: Error response from daemon: Get https://registry-1.docker.io/v2/: proxyconnect tcp: dial tcp 192.168.65.1:3128: connect: network is unreachable

I am on a Mac mini M1 with the latest OS and Docker installed. Resetting Docker to factory defaults resolve the problem but enabling the new virtualization framework produces the error again.

joeky888 commented 3 years ago

I have found a solution for snapcraft installation of docker (sudo snap install docker), tested on Archlinux.

sudo snap disable docker
sudo snap enable docker

If it still doesn't work for you, see if upgrading to the edge branch can help.

sudo snap refresh docker --edge # Don't do this in the production environment
paulcalabro commented 3 years ago

@muuvmuuv 's fix worked for me as well.

darrentmorgan commented 3 years ago

Weird.. MX Linux, same issue. Retry 3 minutes later with no changes, works fine.

Uzer1 commented 3 years ago

It was the same for me on Windows 8.1 with 'timeout' at the end. I changed DNS to Google's and it worked. 8.8.8.8 8.8.4.4

stuntpig commented 2 years ago

I am getting this same error. I have tried pretty much everything in this post. Any ideas would be super helpful.

I'm having an issue when I run our make local command that none of the other developers on my team are having. I'm on a Mac M1 machine. One other dev is also on an M1 and our setup works fine for him. This is happening on multiple repositories. So I'm assuming I have a global setting messed up somehow.

Here is the error I am getting that I don't fully understand...

=> ERROR [dealers_app internal] load metadata for docker.io/library/golang:alpine                                                      0.1s
 => CANCELED [dealers_nginx internal] load metadata for docker.io/library/nginx:1.15.2-alpine                                           0.0s
------
 > [dealers_app internal] load metadata for docker.io/library/golang:alpine:
failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0: failed to create LLB definition: failed to authorize: rpc error: code = Unknown desc = failed to fetch anonymous token: Get "https://auth.docker.io/token?scope=repository%3Alibrary%2Fgolang%3Apull&service=registry.docker.io": dial tcp: lookup auth.docker.io on [::1]:53: read udp [::1]:61456->[::1]:53: read: connection refused
make: *** [app] Error 17
Stuff that I have tried.

Any thoughts would be great!

docker-compose.yml

version: "3.3"

services:
  dealers-app:
    container_name: ${APP_NAME}_app
    image: ${APP_NAME}_app
    build:
      context: .
      dockerfile: docker/app.local.Dockerfile
    environment:
      VIRTUAL_HOST: ${APP_NAME}-app
      HTTPS_METHOD: noredirect
    env_file:
      - .env
    ports:
      - 80
    expose:
      - ${APP_PORT}
    volumes:
      - .:/go/src/app
      - ${GOPATH}/pkg/mod:/go/pkg/mod
  dealers-nginx:
    container_name: ${APP_NAME}_nginx
    image: ${APP_NAME}_nginx
    build:
      context: .
      dockerfile: docker/nginx/nginx.Dockerfile
    environment:
      VIRTUAL_HOST: ${APP_NAME}.test
      HSTS: "off"
      HTTPS_METHOD: noredirect
      APP_DOMAIN: ${APP_NAME} ${APP_NAME}.test
      APP_HOST: ${APP_NAME}-app
      APP_PORT: ${APP_PORT}
networks:
  default:
    external:
      name: development

Makefile

PROJECT_NAME := dealers

.DEFAULT := help
.PHONY: local down reset app all-reset nginx nginx-reset

help:
    @echo '# Dev Targets'
    @echo
    @echo '    local            build the application containers/services locally'
    @echo '    down             tear down the application containers/services locally'
    @echo '    reset            rebuild the application container and restart the service'
    @echo
    @echo '    all-reset        reset the application containers/services'
    @echo '    app              build the application container'
    @echo '    nginx            build the nginx container'
    @echo '    nginx-reset      rebuild the nginx container and restart the service'
    @echo
    @echo '    help             show this help message'
    @echo

local: app nginx
    docker compose up -d --force-recreate \
    && docker compose logs -f

down:
    docker compose down -v

all-reset: down local

reset: app
    docker compose up -d --force-recreate ${PROJECT_NAME}-app \
    && docker compose logs -f

app:
    docker compose build ${PROJECT_NAME}-app

nginx:
    docker compose build ${PROJECT_NAME}-nginx

nginx-reset: nginx
    docker compose up -d --force-recreate ${PROJECT_NAME}-nginx

Dockerfile

FROM golang:alpine as build

RUN apk add --no-cache git

ENV GOPRIVATE gitlab.com/companynameishere-software-development

RUN go install github.com/githubnemo/CompileDaemon@latest \
    && chmod +x /go/bin/CompileDaemon

WORKDIR /go/src/app

ADD ../.netrc /root/.netrc

ENTRYPOINT CompileDaemon --build="go build -o main"
ca-d commented 2 years ago

Am currently experiencing the same issue on 64 bit x86 Void Linux

lanzer commented 2 years ago

i already said that my /etc/resolv.conf is fine - everyting else and their dog is perfectly able to resolve hostnames. You do realize that with the settings that you suggest the system will be unable to resolve hostnames for local adresses?

Anyway, I found something: the systems here that show this problem all run NetworkManager for the network, the ones that dont have static (manually) configured network. So .. I changed the start of the docker unit file to include "NetworkManager-wait-online.service" in the "After=" line, and nof the problem doesn't happen anymore. Seems that when dockerd is "normally" started, networkmanager isn't up yet so docker can'T find the DNS in /etc/resolv.conf, and just assumes ::1 instead. But on the second try it uses what's in resolv.conf by then, which is the properly configured dns.

This happened to me while trying to install Home Assistant on Debian 11.2

Docker tried to make network calls before network interface is ready, causing the install script to fail.

Solution: run "systemctl cat docker.service" , and it will tell you where the docker service file is located. edit /lib/systemd/system/docker.service with your favorite text editor append "NetworkManager-wait-online.service" to line 4, that line should start with the word "After=" run "systemctl daemon-reload" to update your changes to the service file.

Allteran commented 2 years ago

I have found a solution for snapcraft installation of docker (sudo snap install docker), tested on Archlinux.

sudo snap disable docker
sudo snap enable docker

Manjaro Linux here. Thanks a lot! Only your solution helped me.

chriswyatt commented 2 years ago

For me, it was because I forgot to symlink /etc/resolv.conf; however the problem was specific to my particular set-up: https://wiki.archlinux.org/title/Systemd-resolved . I hadn't had any DNS issues up to this point, so it took me a while to figure it out.

fromage9747 commented 2 years ago

I am using an LXC Container in Proxmox with Docker running on it. Confirmed that when adding: nameserver 8.8.8.8 nameserver 8.8.4.4 to /etc/resolv.conf the issue is resolved.

Cheers.

iamLazyCode commented 2 years ago

It was the same for me on Windows 8.1 with 'timeout' at the end. I changed DNS to Google's and it worked. 8.8.8.8 8.8.4.4

i am on windows 11 with this error , any one please help

image

brunom63 commented 2 years ago

i already said that my /etc/resolv.conf is fine - everyting else and their dog is perfectly able to resolve hostnames. You do realize that with the settings that you suggest the system will be unable to resolve hostnames for local adresses? Anyway, I found something: the systems here that show this problem all run NetworkManager for the network, the ones that dont have static (manually) configured network. So .. I changed the start of the docker unit file to include "NetworkManager-wait-online.service" in the "After=" line, and nof the problem doesn't happen anymore. Seems that when dockerd is "normally" started, networkmanager isn't up yet so docker can'T find the DNS in /etc/resolv.conf, and just assumes ::1 instead. But on the second try it uses what's in resolv.conf by then, which is the properly configured dns.

This happened to me while trying to install Home Assistant on Debian 11.2

Docker tried to make network calls before network interface is ready, causing the install script to fail.

Solution: run "systemctl cat docker.service" , and it will tell you where the docker service file is located. edit /lib/systemd/system/docker.service with your favorite text editor append "NetworkManager-wait-online.service" to line 4, that line should start with the word "After=" run "systemctl daemon-reload" to update your changes to the service file.

You're a genius! This is the definite solution for Debian. Worked on Debian 10 and 11.

hoftherose commented 1 year ago

Solution: run "systemctl cat docker.service" , and it will tell you where the docker service file is located. edit /lib/systemd/system/docker.service with your favorite text editor append "NetworkManager-wait-online.service" to line 4, that line should start with the word "After=" run "systemctl daemon-reload" to update your changes to the service file.

This solved it for me, was getting this error in KinD and simply had to recreate to get it to reflect the changes.

sam-thibault commented 10 months ago

This is an old issue. I will resolve it since a solution is described above.

cdauth commented 10 months ago

The solution described above sounds to me like a workaround and not like a solution.

The issue seems like docker is somehow caching the DNS resolution information when it starts and does not refresh it later when a command is run. The workaround described above will solve the problem that docker apparently caches the DNS resolution info when it is not even there yet because no network is connected yet. But I strongly suspect that the underlying issue will still cause errors when for example the DNS resolution information changes while docker is running, for example when connecting to a new network.

thaJeztah commented 10 months ago

It looks like this ticket has collected assorted issues with DNS, not all of those identical (but may result in similar outcome), and I'm not sure if there's a "single solution" for all of these, if at all.

This ticket looks to be about DNS resolution failures during docker push and docker pull; these errors originate from the daemon, which is not maintained in this repository (this repository contains the source-code for the docker CLI client).

w.r.t. the fix mentions (adding NetworkManager-wait-online.service service to the After rule); I don't think we can ship that as a general solution; NetworkManager may not be installed on the system, and I don't think we can add all possible combinations of other software in the list. Starting with https://github.com/moby/moby/commit/dfa4e77d8202f5c682056b59be3111eccddfb09a (https://github.com/moby/moby/pull/30210), the systemd unit has network.online.target both as After and Wants, which should indicate that networking is available, but it's possible that other software modifies /etc/resolv.conf (and related files), which could interfere. Depending on your setup, it may be needed to make changes in systemd configuration to account for these, as it may not be possible to ship these configurations as a default.

I'll close this ticket, as this issue looks to be related to the daemon, which is not maintained in this repository, and because there's potentially multiple issues being conflated here, which makes it difficult to track.

If you have specific details about your situation, and possible solutions that can be included as a default, feel free to open a new ticket with those details included in https://githuib.com/moby/moby/issues.

chaitu236 commented 10 months ago

Documenting one more instance of this issue and our findings in case it helps anyone who stumbles into it

docker is written in go and uses golang's APIs for network calls. golang has its own implementation of DNS resolver but can also use operating system's DNS resolver. On Linux machines, golang's DNS resolver is used as default. There is a bug in older versions of golang's DNS resolver here.

    conf.dnsConfig = systemConf().resolv
    if conf.dnsConfig == nil {
        conf.dnsConfig = dnsReadConfig("/etc/resolv.conf")
    }
    conf.lastChecked = time.Now()

The if condition can never be true and dnsConfiguration is not re-read from /etc/resolv.conf. So on the first network call, the same DNS configuration that existed during program startup is used. Only network calls made 5 seconds after this first call trigger a re-read of /etc/resolv.conf.

In our case, when docker daemon is started networking is still not up completely. IP address is not yet assigned and /etc/resolv.conf is empty. So DNS configuration is initialized to some defaults and the first docker pull ends up using these even if by that point /etc/resolv.conf is updated.

There are a few ways to workaround this

I see that newer versions of docker use golang versions that contain the fix but I don't know if most distros picked up the versions that contain the fix.