Open tomer-amir-vonage opened 5 years ago
Seems that issue is that the DNS failed to resolve. Is this something that randomly happens or is it reproducible?
It happened randomly, and I haven't been able to reproduce yet... It might have been a temporary network issue, but I would still like to know if there's a way to prevent this from crashing the whole server and just fail that specific request... but this might not be a question for this repo 😕
Is DNS.js your own file or part of express?
I am pretty sure that dns.js
is a core nodejs module for handling DNS
Can you try this?
docker run --rm -it node:10.13.0-alpine node -pe 'require("dns").lookup("www.amazon.com",function(){console.dir(arguments)})'
It happens to me also after upgrading from node:10.15.1-alpine to node:12.1.0-alpine . In my case I set host resolution in docker-compose:
...
extra_hosts:
- "SQL:192.168.1.xxx"
...
alipina will EAI_AGAIN or delays about 5s, using stretch-slim i solved this problem!
I may be wrong, but it looks like this issue from a different alpine based image: https://github.com/gliderlabs/docker-alpine/issues/255
We faced the same issue and figured out the reason. Especially under high load and in Kubernetes environments, random DNS lookup errors occur.
The Callstack Diagram below, explains what happens. In this example, the application is trying to make an HTTP connection to www.example.org/. Hence, the IP must be lookup up, so the lib/dns.js (part of Node) wraps a Node's engine function, which then does the actual lookup, via calling getaddrinfo(). The latter depends on the dynamically linked libc. And there's the problem: Alpine's musl libc does not fully support all features DNS resolving, e.g. when you use multiple DNS servers or search orders.
There are two possible solutions: A) Don't use minimal base images, which don't fully support libc features (e.g. Alpine), but rather switch to Debian, Ubuntu, Ubi, etc. "slim" variants. B) When building the Node.js engine binary, statically link the libc's getaddrinfo() into the binary. This would not use dynamic linked musl libc code.
PS: I guess coding/fixing the musl libc implementation likely will not happen (assuming, as I see contradicting goals)
Getting EAI_AGAIN
error even with bullseye. 🤦🏻♂️
I also got this issue in combination: docker image alpine:3.15
, and alpine repo nodejs
package, an error reason: getaddrinfo EAI_AGAIN
raise randomly.
So, current solution is stop using alpine image?
i have one question if i use debian-slim should i install gcc/g++ manually?
Hi same issue running nodejs:alpine inside Docker:
cause: Error: getaddrinfo EAI_AGAIN api.telegram.org at GetAddrInfoReqWrap.onlookupall [as oncomplete] (node:dns:118:26) { errno: -3001, code: 'EAI_AGAIN', syscall: 'getaddrinfo', hostname: 'api.telegram.org' } }
I am running an express server on AWS Fargate using the
node:10.13.0-alpine
image.A few days ago we had an instance crash, and I found this error in its logs:
Looking online this seems like an alpine issue, but I am not sure, and I am not sure that this is where to fix it, but I was hoping at least for tips on how to fix it for my instance...
Thanks!