[dockerd] Force usage of cgo DNS resolver #89
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Go's runtime (and dockerd inherits this) uses own DNS resolver implementation by default on Linux. It has been observed that there are some DNS resolution issues when executing ```docker pull``` after first boot. Consider the following script: ``` admin@r-boxer-sw01:~$ while :; do date; cat /etc/resolv.conf; ping -c 1 harbor.mellanox.com; docker pull harbor.mellanox.com/sonic/cpu-report:1.0.0 ; sleep 1; done Fri 03 Feb 2023 10:06:22 AM UTC nameserver 10.211.0.124 nameserver 10.211.0.121 nameserver 10.7.77.135 search mtr.labs.mlnx labs.mlnx mlnx lab.mtl.com mtl.com PING harbor.mellanox.com (10.7.1.117) 56(84) bytes of data. 64 bytes from harbor.mtl.labs.mlnx (10.7.1.117): icmp_seq=1 ttl=53 time=5.99 ms --- harbor.mellanox.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 5.989/5.989/5.989/0.000 ms Error response from daemon: Get "https://harbor.mellanox.com/v2/": dial tcp: lookup harbor.mellanox.com on [::1]:53: read udp [::1]:57245->[::1]:53: read: connection refused Fri 03 Feb 2023 10:06:23 AM UTC nameserver 10.211.0.124 nameserver 10.211.0.121 nameserver 10.7.77.135 search mtr.labs.mlnx labs.mlnx mlnx lab.mtl.com mtl.com PING harbor.mellanox.com (10.7.1.117) 56(84) bytes of data. 64 bytes from harbor.mtl.labs.mlnx (10.7.1.117): icmp_seq=1 ttl=53 time=5.56 ms --- harbor.mellanox.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 5.561/5.561/5.561/0.000 ms Error response from daemon: Get "https://harbor.mellanox.com/v2/": dial tcp: lookup harbor.mellanox.com on [::1]:53: read udp [::1]:53299->[::1]:53: read: connection refused Fri 03 Feb 2023 10:06:24 AM UTC nameserver 10.211.0.124 nameserver 10.211.0.121 nameserver 10.7.77.135 search mtr.labs.mlnx labs.mlnx mlnx lab.mtl.com mtl.com PING harbor.mellanox.com (10.7.1.117) 56(84) bytes of data. 64 bytes from harbor.mtl.labs.mlnx (10.7.1.117): icmp_seq=1 ttl=53 time=5.78 ms --- harbor.mellanox.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 5.783/5.783/5.783/0.000 ms Error response from daemon: Get "https://harbor.mellanox.com/v2/": dial tcp: lookup harbor.mellanox.com on [::1]:53: read udp [::1]:55765->[::1]:53: read: connection refused Fri 03 Feb 2023 10:06:25 AM UTC nameserver 10.211.0.124 nameserver 10.211.0.121 nameserver 10.7.77.135 search mtr.labs.mlnx labs.mlnx mlnx lab.mtl.com mtl.com PING harbor.mellanox.com (10.7.1.117) 56(84) bytes of data. 64 bytes from harbor.mtl.labs.mlnx (10.7.1.117): icmp_seq=1 ttl=53 time=7.17 ms --- harbor.mellanox.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 7.171/7.171/7.171/0.000 ms Error response from daemon: Get "https://harbor.mellanox.com/v2/": dial tcp: lookup harbor.mellanox.com on [::1]:53: read udp [::1]:44877->[::1]:53: read: connection refused Fri 03 Feb 2023 10:06:26 AM UTC nameserver 10.211.0.124 nameserver 10.211.0.121 nameserver 10.7.77.135 search mtr.labs.mlnx labs.mlnx mlnx lab.mtl.com mtl.com PING harbor.mellanox.com (10.7.1.117) 56(84) bytes of data. 64 bytes from harbor.mtl.labs.mlnx (10.7.1.117): icmp_seq=1 ttl=53 time=5.66 ms --- harbor.mellanox.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 5.656/5.656/5.656/0.000 ms Error response from daemon: Get "https://harbor.mellanox.com/v2/": dial tcp: lookup harbor.mellanox.com on [::1]:53: read udp [::1]:54604->[::1]:53: read: connection refused Fri 03 Feb 2023 10:06:27 AM UTC nameserver 10.211.0.124 nameserver 10.211.0.121 nameserver 10.7.77.135 search mtr.labs.mlnx labs.mlnx mlnx lab.mtl.com mtl.com PING harbor.mellanox.com (10.7.1.117) 56(84) bytes of data. 64 bytes from harbor.mtl.labs.mlnx (10.7.1.117): icmp_seq=1 ttl=53 time=8.22 ms --- harbor.mellanox.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 8.223/8.223/8.223/0.000 ms 1.0.0: Pulling from sonic/cpu-report 004f1eed87df: Downloading [===================> ] 19.3MB/50.43MB 5d6f1e8117db: Download complete 48c2faf66abe: Download complete 234b70d0479d: Downloading [=========> ] 9.363MB/51.84MB 6fa07a00e2f0: Downloading [==> ] 9.51MB/192.4MB 04a31b4508b8: Waiting e11ae5168189: Waiting 8861a99744cb: Waiting d59580d95305: Waiting 12b1523494c1: Waiting d1a4b09e9dbc: Waiting 99f41c3f014f: Waiting ``` While /etc/resolv.conf has the correct content and ping (and any other utility that uses libc's DNS resolution implementation) works correctly docker is unable to resolve the hostname and falls back to default [::1]:53. This started to happen after PR sonic-net#13516 has been merged. As you can see from the log, dockerd is able to pick up the correct /etc/resolv.conf only after 5 sec since first try. This seems to be somehow related to the logic in Go's DNS resolver https://github.com/golang/go/blob/master/src/net/dnsclient_unix.go#L385. There have been issues like that reported in docker like: - docker/cli#2299 - docker/cli#2618 - moby/moby#22398 Since this starts to happen after inclusion of resolvconf package by above mentioned PR and the fact I can't see any problem with that (ping, nslookup, etc. works) the choice is made to force dockerd to use cgo (libc) resolver. Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
volodymyrsamotiy
approved these changes
Feb 3, 2023
stepanblyschak
pushed a commit
that referenced
this pull request
Feb 13, 2023
[sonic-linkmgrd][202012] submodule update 0839af2 Longxiang Lyu Wed Jun 15 08:46:21 2022 +0800 [202012] Fix IP header checksum in handleSendSwitchCommand (#89) afc4972 Jing Zhang Wed Jun 1 10:33:12 2022 -0700 Revert "Update log level for mux probing and mux state chance (#23)" (#85) ed52d0a Longxiang Lyu Tue May 31 10:28:30 2022 +0800 Add a command line option to store logs into a separate file (#83) sign-off: Jing Zhang zhangjing@microsoft.com
stepanblyschak
pushed a commit
that referenced
this pull request
Dec 5, 2023
…utomatically (sonic-net#17330) #### Why I did it src/sonic-host-services ``` * 445ec8b - (HEAD -> master, origin/master, origin/HEAD) Revert "Add support to make determine/process reboot-cause services restartable (#86)" (#89) (31 hours ago) [anamehra] ``` #### How I did it #### How to verify it #### Description for the changelog
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Go's runtime (and dockerd inherits this) uses own DNS resolver implementation by default on Linux. It has been observed that there are some DNS resolution issues when executing
docker pullafter first boot.Consider the following script:
While /etc/resolv.conf has the correct content and ping (and any other utility that uses libc's DNS resolution implementation) works correctly docker is unable to resolve the hostname and falls back to default [::1]:53. This started to happen after PR sonic-net#12592 has been merged. As you can see from the log, dockerd is able to pick up the correct /etc/resolv.conf only after 5 sec since first try. This seems to be somehow related to the logic in Go's DNS resolver https://github.com/golang/go/blob/master/src/net/dnsclient_unix.go#L385.
There have been issues like that reported in docker like which are still open, not fixed or closed due to inactivity or age:
Since this starts to happen after above mentioned PR and the fact I can't see any problem with that (ping, nslookup, etc. works) the choice is made to force dockerd to use cgo (libc) resolver.
Signed-off-by: Stepan Blyschak stepanb@nvidia.com
Why I did it
To fix an issue that dockerd fails to resolve registry address
How I did it
Added environment variable to force dockerd to use cgo resolver
How to verify it
First boot the system, do "docker pull"
Which release branch to backport (provide reason below if selected)
Description for the changelog
Ensure to add label/tag for the feature raised. example - PR#2174 under sonic-utilities repo. where, Generic Config and Update feature has been labelled as GCU.
Link to config_db schema for YANG module changes
A picture of a cute animal (not mandatory but encouraged)