Closed iamcaleberic closed 6 years ago
To reproduce
Dockerfile (docker build .)
FROM alpine:latest
RUN echo -e 'http://dl-cdn.alpinelinux.org/alpine/edge/main\nhttp://dl-cdn.alpinelinux.org/alpine/edge/community\nhttp://dl-cdn.alpinelinux.org/alpine/edge/testing' > /etc/apk/repositories
RUN apk --update add --no-cache openssh-client \
curl \
git \
nodejs \
nodejs-npm \
yarn \
python \
python-dev \
py-pip \
build-base
RUN yarn --version
RUN yarn init -y
RUN yarn add chai
# or anything else
[..]
Step 4/6 : RUN yarn --version
---> Running in 98924f337e41
1.9.4
Removing intermediate container 98924f337e41
---> 862e77432ac6
Step 5/6 : RUN yarn init -y
---> Running in ece925f161f1
yarn init v1.9.4
warning The yes flag has been set. This will automatically answer yes to all questions, which may have security implications.
success Saved package.json
Done in 0.07s.
Removing intermediate container ece925f161f1
---> 0cb37c2919be
Step 6/6 : RUN yarn add chai
---> Running in bbdb53c194a4
yarn add v1.9.4
info No lockfile found.
[1/4] Resolving packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/chai: getaddrinfo EADDRNOTAVAIL registry.yarnpkg.com:443".
info If you think this is a bug, please open a bug report with the information provided in "/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.
The command '/bin/sh -c yarn add chai' returned a non-zero code: 1
The yarn command run correctly inside the OSX terminal, however it does not inside a (alpine linux) docker container shell running on the same host. This was working yesterday.
Trace: Error: getaddrinfo EADDRNOTAVAIL registry.yarnpkg.com:443 at Object._errnoException (util.js:1003:13) at errnoException (dns.js:60:15) at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:97:26)
I'm seeing this too. It seems to be a problem unrelated to yarn though:
node -e "require('https').get('https://api.nasa.gov/planetary/apod?api_key=DEMO_KEY').on('error', err => console.log('Error: ' + err.message))"
Error: getaddrinfo EADDRNOTAVAIL api.nasa.gov:443
So it looks as though node is broken on alpine-edge.
I have tested this on older alpine node image where it works so my suspicion is something in alpine updates is triggering the NPM registry problem
On Sun, Sep 16, 2018 at 3:41 PM Aslak Hellesøy notifications@github.com wrote:
I'm seeing this too. It seems to be a problem unrelated to yarn though:
node -e "require('https').get('https://api.nasa.gov/planetary/apod?api_key=DEMO_KEY').on('error', err => console.log('Er ror: ' + err.message))"
So it looks as though node is broken on alpine-edge.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/yarnpkg/yarn/issues/6384#issuecomment-421846368, or mute the thread https://github.com/notifications/unsubscribe-auth/AKbNlTZHYTpUmcgJoADdU1mQjeSP9HXVks5ubtN8gaJpZM4WnKWb .
I tried this on base alpine 3.7 and it works, however it breaks once I runapk upgrade --update-cache --available
which apparently brings in some recent update/patch causing this breakage.
@pdhar-tibco my example above demonstrates that the http stdlib doesn’t work. It can’t connect anywhere.
What makes you think this is related to nom, yarn or the registry?
I have come to the same conclusion as I was able to run npm on alpine without updated packages. Some update broke this recently coinciding with the npm registry outage.
On Tue, Sep 18, 2018 at 12:39 PM Aslak Hellesøy notifications@github.com wrote:
@pdhar-tibco https://github.com/pdhar-tibco my example above demonstrates that the http stdlib doesn’t work. It can’t connect anywhere.
What makes you think this is related to nom, yarn or the registry?
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/yarnpkg/yarn/issues/6384#issuecomment-422522450, or mute the thread https://github.com/notifications/unsubscribe-auth/AKbNlaApgTCBeWiHuRGXUhZlN7Qg1fabks5ucUvzgaJpZM4WnKWb .
I think I have found the problem. It is coming from a update of musl-utils package (1.1.18-r3 -> 1.1.20-r1).
-Pranab
On Sep 18, 2018, at 12:44 PM, Pranab Dhar pdhar@tibco.com wrote:
I have come to the same conclusion as I was able to run npm on alpine without updated packages. Some update broke this recently coinciding with the npm registry outage.
On Tue, Sep 18, 2018 at 12:39 PM Aslak Hellesøy <notifications@github.com mailto:notifications@github.com> wrote: @pdhar-tibco https://github.com/pdhar-tibco my example above demonstrates that the http stdlib doesn’t work. It can’t connect anywhere.
What makes you think this is related to nom, yarn or the registry?
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/yarnpkg/yarn/issues/6384#issuecomment-422522450, or mute the thread https://github.com/notifications/unsubscribe-auth/AKbNlaApgTCBeWiHuRGXUhZlN7Qg1fabks5ucUvzgaJpZM4WnKWb.
Are you sure it's the musl-utils package that broke it? musl-utils actually has nothing to do with musl; it's an alpine package that provides portable replacements for a few things that were historically packaged with glibc and uclibc.
It's almost certainly the updated musl package, not musl-utils, affecting it; the relevant change is the new AI_ADDRCONFIG feature. For some reason, attempting to connect a udp socket to either 127.0.0.1 or ::1 (v4 or v6) is producing EADDRNOTAVAIL. Can you check for any network configuration that might be causing this? It's only documented (in the linux man page for connect) to happen if the entire port range configured in /proc/sys/net/ipv4/ip_local_port_range is exhausted. Maybe Docker is doing something weird that causes it to happen under other conditions.
I observed that after eliminating musl-utils I was able to run npm. I agree it can be docker also but this behavior was noticed even older versions of docker too which eliminated docker as participant.
On Tue, Sep 18, 2018 at 7:58 PM richfelker notifications@github.com wrote:
It's almost certainly the updated musl package, not musl-utils, affecting it; the relevant change is the new AI_ADDRCONFIG feature. For some reason, attempting to connect a udp socket to either 127.0.0.1 or ::1 (v4 or v6) is producing EADDRNOTAVAIL. Can you check for any network configuration that might be causing this? It's only documented (in the linux man page for connect) to happen if the entire port range configured in /proc/sys/net/ipv4/ip_local_port_range is exhausted. Maybe Docker is doing something weird that causes it to happen under other conditions.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/yarnpkg/yarn/issues/6384#issuecomment-422632292, or mute the thread https://github.com/notifications/unsubscribe-auth/AKbNlTrEbqSBN7kdza1WJEtFRW71GeDZks5ucbLRgaJpZM4WnKWb .
I don't mean to say there's a new regression in Docker. I mean the issue is an interaction of some aspect of the Docker network configuration with the new AI_ADDRCONFIG support in musl 1.1.20.
Please try running this C program inside the Docker container using strace and posting the strace output:
I can reproduce the issue.
/ # ./check_gai_regression
System error [Address not available]
/ # strace ./check_gai_regression
execve("./check_gai_regression", ["./check_gai_regression"], 0x7ffd13bd6690 /* 6 vars */) = 0
arch_prctl(ARCH_SET_FS, 0x7f8417631b88) = 0
set_tid_address(0x7f8417631bc8) = 15
mprotect(0x7f841762e000, 4096, PROT_READ) = 0
mprotect(0x55ba5c7d8000, 4096, PROT_READ) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_UDP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(65535), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
close(3) = 0
socket(AF_INET6, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_UDP) = 3
connect(3, {sa_family=AF_INET6, sin6_port=htons(65535), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 EADDRNOTAVAIL (Address not available)
close(3) = 0
ioctl(1, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
writev(1, [{iov_base="System error [Address not availa"..., iov_len=35}, {iov_base="]\n", iov_len=2}], 2System error [Address not available]
) = 37
exit_group(0) = ?
+++ exited with 0 +++
/ #
Yes, I can too now. It happens when the address ::1 is not configured on lo and there's no default route for ipv6. I had tested both of these configurations separately before but not together. This seems to be a bug in the Linux documentation too since EADDRNOTAVAIL is not documented for this purpose. I'll prepare a patch for musl; I need to check because it looks like there may be a few more errors we should consider here as indications that the address family being probed is not configured.
I've pushed a fix to musl that should address this issue. Hopefully Alpine will pick up the patch soon. https://git.musl-libc.org/cgit/musl/commit/?id=f381c118b2d4f7d914481d3cdc830ce41369b002
Until it's fixed, a simple workaround would be ifconfig lo ::1
or equivalently ip addr add ::1 dev lo
Thanks a lot. Our build with latest is working again as of yesterday. Maybe @iamcaleberic can confirm.
Thanks all the commands are running normally. Will go ahead and close this.
Do you want to request a feature or report a bug? Bug
What is the current behavior?
yarn install
it throwsgetaddrinfo EADDRNOTAVAIL registry.yarnpkg.com:443