- This topic is empty.
-
AuthorPosts
-
October 21, 2016 at 5:11 am #9263thomasreggiParticipant
My server threw this today, which is a Node.js error I’ve never seen before:
Error: getaddrinfo EAI_AGAIN my-store.myshopify.com:443 at Object.exports._errnoException (util.js:870:11) at errnoException (dns.js:32:15) at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:78:26)
I’m wondering if this is related to the DynDns DDOS attack which affected Shopify and many other services today. Here’s an article about that.
My main question is what does
dns.js
do? What part of node is it a part of? How can I recreate this error with a different domain?October 21, 2016 at 5:40 am #9278xerqParticipantEAI_AGAIN is a DNS lookup timed out error, means it is a network connectivity error or proxy related error.
My main question is what does dns.js do?
- The dns.js is there for node to get ip address of the domain(in brief).
Some more info:
http://www.codingdefined.com/2015/06/nodejs-error-errno-eaiagain.htmlNovember 30, 2017 at 12:00 pm #9266mateenParticipant@xerq pointed correctly, here’s some more reference
http://www.codingdefined.com/2015/06/nodejs-error-errno-eaiagain.htmli got the same error, i solved it by updating “hosts” file present under this location in windows os
C:\Windows\System32\drivers\etc
Hope it helps!!
July 30, 2018 at 5:49 am #9270radhe9254ParticipantThis is the issue related to hosts file setup.
Add the following line to your hosts file
In Ubuntu: /etc/hosts127.0.0.1 localhost
In windows: c:\windows\System32\drivers\etc\hosts
127.0.0.1 localhost
November 7, 2018 at 7:20 am #9272martin-bramwellParticipantThe OP’s error specifies a host (
my-store.myshopify.com
).
The error I encountered is the same in all respects except that no domain is specified.My solution may help others who are drawn here by the title “Error: getaddrinfo EAI_AGAIN”
I encountered the error when trying to serve a NodeJs & VueJs app from a different VM from where the code was developed originally.
The file
vue.config.js
read :module.exports = { devServer: { host: 'tstvm01', port: 3030, }, };
When served on the original machine the start up output is :
App running at: - Local: http://tstvm01:3030/ - Network: http://tstvm01:3030/
Using the same settings on a VM
tstvm07
got me a very similar error to the one the OP describes:INFO Starting development server... 10% building modules 1/1 modules 0 activeevents.js:183 throw er; // Unhandled 'error' event ^ Error: getaddrinfo EAI_AGAIN at Object._errnoException (util.js:1022:11) at errnoException (dns.js:55:15) at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:92:26)
If it ain’t already obvious, changing
vue.config.js
to read …module.exports = { devServer: { host: 'tstvm07', port: 3030, }, };
… solved the problem.
March 12, 2019 at 11:10 am #9277bastienParticipantFebruary 14, 2020 at 1:14 am #9271john-rixParticipantI started getting this error (different stack trace though) after making a trivial update to my GraphQL API application that is operated inside a docker container. For whatever reason, the container was having difficulty resolving a back-end service being used by the API.
After poking around to see if some change had been made in the docker base image I was building from (node:13-alpine, incidentally), I decided to try the oldest computer science trick of rebooting… I stopped and started the docker container and all went back to normal.
Clearly, this isn’t a meaningful solution to the underlying problem – I am merely posting this since it did clear up the issue for me without going too deep down rabbit holes.
March 30, 2020 at 12:47 pm #9265igor-jankovicParticipantI had a same problem with AWS and Serverless. I tried with
eu-central-1
region and it didn’t work so I had to change it tous-east-2
for the example.May 22, 2020 at 12:51 pm #9276diego-p.-steinerParticipantIf you get this error from within a docker container, e.g. when running
npm install
inside of an alpine container, the cause could be that the network changed since the container was started.To solve this, just stop and restart the container
docker-compose down docker-compose up
Source: https://github.com/moby/moby/issues/32106#issuecomment-578725551
October 7, 2020 at 2:43 am #9275mikemaccanaParticipantAs xerq’s excellent answer explains, this is a DNS timeout issue.
I wanted to contribute another possible answer for those of you using Windows Subsystem for Linux – there are some cases where something seems to be askew in the client OS after Windows resumes from sleep. Restarting the host OS will fix these issues (it’s also likely restarting the WSL service will do the same).
November 29, 2020 at 5:26 am #9264daniel-danieleckiParticipantEnabled Blaze and it still doesn’t work?
Most probably you need to set
.env
from the right path,require('dotenv').config({ path: __dirname + './../.env' });
won’t work (or any other path). Simply put the.env
file in thefunctions
directory, from which you deploy toFirebase
.February 8, 2021 at 10:28 am #9267mbessonParticipantIn my case the problem was the docker networks ip allocation range, see this post for details
November 18, 2021 at 8:38 am #9273johnParticipantI was having this issue on docker-compose. Turns out I forgot to add my custom isolated named network to my service which couldn’t be found.
TLDR; Make sure, in your compose file, you have your custom-networks defined on both services that need to talk to each other.
My error looked like this:
Error: getaddrinfo EAI_AGAIN minio-service
. The error was coming from my server’s backend when making a call to theminio-service
using theminio-service
hostname. This tells me thatminio-service
‘s running service, was not reachable by myserver
‘s running service. The way I was able to fix this issue is I changed the minio-service in my docker-compose from this:- docker-compose.yml
version: "3.8" # ... services: server: # ... networks: my-network: # ... minio-service: # ... (missing networks: section) # ... networks: my-network:
To include my custom isolated named network, like this:
- docker-compose.yml
version: "3.8" # ... services: server: # ... networks: my-network: # ... minio-service: # ... networks: my-network: # ... # ... networks: my-network:
More details on docker-compose networking can be found here.
December 21, 2021 at 6:46 am #9268ricardo-stands-with-ukraineParticipantJuly 21, 2022 at 5:47 am #9269smac89ParticipantI was getting this error after I recently added a new
network
to my docker-compose file.I initially had these services:
services: frontend: depends_on: - backend ports: - 3005:3000 backend: ports: - 8005:8000
I decided to add a new network which hosts other services I wanted my
frontend
service to have access to, so I did this:networks: moar: name: moar-network attachable: true services: frontend: networks: - moar depends_on: - backend ports: - 3005:3000 backend: ports: - 8005:8000
Unfortunately, the above made it so that my
frontend
service was no longer visible on thedefault
network, and only visible in themoar
network. This meant that thefrontend
service could no longer proxy requests tobackend
, therefore I was getting errors like:Error occured while trying to proxy to: localhost:3005/graphql/
The solution is to add the
default
network to thefrontend
service’s network list, like so:networks: moar: name: moar-network attachable: true services: frontend: networks: - moar - default # here depends_on: - backend ports: - 3005:3000 backend: ports: - 8005:8000
Now we’re peachy!
One last thing, if you want to see which services are running within a given network, you can use the
docker network inspect <network_name>
command to do so. This is what helped me discover that thefrontend
service was not part of the default network anymore. -
AuthorPosts
- You must be logged in to reply to this topic.