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?
If you get this error with Firebase Cloud Functions, this is due to the limitations of the free tier (outbound networking only allowed to Google services).
Upgrade to the Flame or Blaze plans for it to work.
EAI_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.html
If 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
As 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).
For those who perform thousand or millions of requests per day, and need a solution to this issue:
It's quite normal to get getaddrinfo EAI_AGAIN errors when performing a lot of requests on your server. Node.js itself doesn't perform any DNS caching, it delegates everything DNS related to the OS.
You need to have in mind that every http/https request performs a DNS lookup, this can become quite expensive, to avoid this bottleneck and getaddrinfo errors, you can implement a DNS cache.
http.request (and https) accepts a lookup property which defaults to dns.lookup()
http.get('http://example.com', { lookup: yourLookupImplementation }, response => {
// do something here with response
});
I strongly recommend to use an already tested module, instead of writing a DNS cache yourself, since you'll have to handle TTL correctly, among other things to avoid hard to track bugs.
I personally use cacheable-lookup which is the one that got uses (see dnsCache option).
You can use it on specific requests
const http = require('http');
const CacheableLookup = require('cacheable-lookup');
const cacheable = new CacheableLookup();
http.get('http://example.com', {lookup: cacheable.lookup}, response => {
// Handle the response here
});
or globally
const http = require('http');
const https = require('https');
const CacheableLookup = require('cacheable-lookup');
const cacheable = new CacheableLookup();
cacheable.install(http.globalAgent);
cacheable.install(https.globalAgent);
NOTE: have in mind that if a request is not performed through Node.js http/https module, using .install on the global agent won't have any effect on said request, for example requests made using undici
The 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.
I 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.
I 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 the minio-service using the minio-service hostname. This tells me that minio-service's running service, was not reachable by my server'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.
This is the issue related to hosts file setup.
Add the following line to your hosts file
In Ubuntu: /etc/hosts
127.0.0.1 localhost
In windows: c:\windows\System32\drivers\etc\hosts
127.0.0.1 localhost
In my case the problem was the docker networks ip allocation range, see this post for details
#xerq pointed correctly, here's some more reference
http://www.codingdefined.com/2015/06/nodejs-error-errno-eaiagain.html
i 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!!
In my case, connected to VPN, the error happens when running Ubuntu from inside Windows Terminal but doesn't happen when opening Ubuntu directly from Windows (not from inside the Windows Terminal)
I 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 to us-east-2 for the example.
I 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 the default network, and only visible in the moar network. This meant that the frontend service could no longer proxy requests to backend, 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 the frontend 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 the frontend service was not part of the default network anymore.
Enabled 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 the functions directory, from which you deploy to Firebase.
Related
once i migrated to docker to have a virtual network to simulate an atual network (bridge type with dns which works . the fqdn is resolved correctly to referrring ip) the following errors appeared in the console.log AND no data is displayed on the frontend website.
ERROR Error: NG0901
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://backend:4000/crafts. (Reason: CORS request did not succeed). Status code: (null).
ERROR
Object { headers: {…}, status: 0, statusText: "Unknown Error", url: "http://backend:4000/crafts", ok: false, name: "HttpErrorResponse", message: "Http failure response for http://backend:4000/crafts: 0 Unknown Error", error: error }
thats the browser's (firefox) console.log
i think nginx is doing things with the headers and or the body is empty due to serversides configs with nginx
on local host everything worked out fine
so im on the config of gninx but so far without any success.. i read about similar problems but couldnt find a solution myself OR the answers read didnt work with my setup.
i tries to change the ip to 0.0.0.0 to make it accessable in the network
oh AND im using nodejs expressjs
app.listen(port,ip)
I use a Dockerfile and docker-compose.yml to make the images, i use a powershell script to compose the images
what i suspect to cause the problem is:
backend:
index.js is run anbd looks like that
"use strict";
var __importDefault = (this && this.__importDefault) || function (mod) {
return (mod && mod.__esModule) ? mod : { "default": mod };
};
Object.defineProperty(exports, "__esModule", { value: true });
const express_1 = __importDefault(require("express"));
const Routes_1 = __importDefault(require("./Routes"));
const app = (0, express_1.default)();
app.use(function (req, res, next) {
res.header("Access-Control-Allow-Origin", "*");
res.header("Access-Control-Allow-Headers", "*");
res.header("Access-Control-Allow-Methods", "PUT,POST,GET,DELETE,OPTIONS");
next();
});
// middleswares
app.use(express_1.default.json());
app.use(express_1.default.urlencoded({ extended: false })); //changed to see wheater it would effect the package isssue- should allow
app.use(Routes_1.default);
app.listen(4000,'0.0.0.0'); // or fqdn 'frontend'
console.log('server on port', 4000);
this is generated from index.ts and a build command
the referrring dockerfile:
FROM node:alpine as builder
WORKDIR /app/
COPY . /app/
COPY package.json /app/
COPY package-lock.json /app/
RUN cd /app/
RUN npm install -g
RUN npm update express
RUN npm install pg
FROM nginx:alpine
COPY --from=builder ./app/dist ./usr/share/nginx/html/
EXPOSE 3999-6001
CMD ["nginx", "-g", "daemon off;"]
RUN apk add --update nodejs
RUN apk add --update npm
after the image runs i open the terminal and run in the usr/share/gninx/html directory :
npm i express
npm i pg
node index.js
then I install vim
and edit the nginx.config like that
vi /etc/nginx/nginx.conf
i add a server directory, make it listen to the fqdn 'frontend' or its referring IP and the port 4000
listen ip:port kind of syntax
i add error and access logs earlier on and it doesn't return problems besides sometimes it says that IP are not available. im lacking on the understanding on how to interpret that
the PostgreSQL is also running in a docker container by the default port 5432 and the fqdn database which is also properly resolvable
same as the backend's fqdn
there is so much more stuff that links the short pieces of code that i have.. feel free to request more if interested or if u think it'd be required to find out whats going wrong.
I learnt my lesson..
servers listen to their own IPs, or at their localhost.
so i had a misconception there. though thanks to the pple taking a look inside here.
also a nodejs expressjs server doesn't necessarily need nginx to run on.. node is enough.. for the purpose..
fixing these two things led functionality as designed :)
so this can be closed or used as reminder on these two things:
understanding the conceptional idea of how networks work
AND
understanding the tech-stack being used and how it works
else
/closed
I am fetching videos from the facebook graph api(24*7) using nodejs. My code is working fine but after every 3 or 4 days it stops working and gives the following error: (Ignore the I'm in loop statements)
Error: connect ENETUNREACH 2a03:2990:f015:12:face:b00c:0:2:443 - Local (:::0)
at Object._errnoException (util.js:1003:13)
at _exceptionWithHostPort (util.js.1024:20)
...
Check you internet connection . That solved my problem as ENETUNREACH is a network issue such as host unreachable or your gateway not working .
In my case, I just changed the localhost property to 127.0.0.1 as follows:
var connection = mysql.createConnection({
// host : 'localhost', // localhost causes somehow this error
host: '127.0.0.1',
I had a similar error, I disabled IPv6 on my computer and then the error stopped occurring.
I got the same issue. My problem was I still have the corp proxy settings in npm config. My resolution:
Check if any proxy settings in place
npm config list
Remove them
npm config delete https-proxy
You may have more. But after that, the error's gone.
I have been setting up a server on a Digital Ocean droplet in order to host a couple of Meteor apps. I'm doing everything from scratch so I can learn as much as possible. I am trying to use "Meteor-Up" (mup) to deploy an app, but it is having problem communicating with MongoDB. When I run "mup setup" I get the following error:
Started TaskList: Setup (linux)
[Gibson] - Installing Docker
[Gibson] - Installing Docker: SUCCESS
[Gibson] - Setting up Environment
[Gibson] - Setting up Environment: SUCCESS
[Gibson] - Copying MongoDB configuration
[Gibson] - Copying MongoDB configuration: SUCCESS
[Gibson] - Installing MongoDB
[Gibson] x Installing MongoDB: FAILED
-----------------------------------STDERR-----------------------------------
docker: Error response from daemon: driver failed programming external connectivity on endpoint mongodb (1e188b51b171446cd22d96f40ceab1e696019e5ac33ca713d78827246ae37ec8): Error starting userland proxy: listen tcp 127.0.0.1:27017: bind: address already in use.
-----------------------------------STDOUT-----------------------------------
latest: Pulling from library/mongo
Digest: sha256:beff97308c36f7af664a1d04eb6ed09be1d14c17427065b2ec4b0de90967bb3f
Status: Image is up to date for mongo:latest
mongodb
c17e5ac9e9369b779da4aff639c16578dedbc7c357985f67d6e7b005d9cf3939
----------------------------------------------------------------------------
But I can't get from this any indication of what's going wrong. Is the problem with Mongo, Meteor, mup, or docker?
EDIT:
So far I understand from the message that "mup" is trying to connect to Mongo on port 27017 and is failing, I just don't understand why or how to fix it. I have a database that I want the app to connect to, which I moved onto the server from my local machine using mongodump and mongorestore. The thing I can't solve is how to connect my meteor app to that mongo DB.
It does not just try to connect to mongod, but it installs mongod in a container and tries to bind port 27017 to local interface.
If you already have mongodb installed and prefer to use it instead, you need to disable installation of mongodb in mup.js, mup.json, or whatever configuration file is being used in your version of mup.
First time with linux and meteor up, so sorry if there's a stupid mistake. I try to deploy the meteor example app todos with mupx, and followed the instructions from the readme, but I'm getting the following mistake. (I'm using Ubuntu 14.04 LTS Server ). Thanks for help.
Configuration file : mup.json
Settings file : settings.json
“ Checkout Kadira!
It's the best way to monitor performance of your app.
Visit: https://kadira.io/mup ”
Meteor app path : /home/jan/todos
Using buildOptions : {}
Currently, it is only possible to build iOS apps on an OS X system.
Started TaskList: Deploy app 'todos' (linux)
[h2544161.stratoserver.net] - Uploading bundle
[h2544161.stratoserver.net] - Uploading bundle: SUCCESS
[h2544161.stratoserver.net] - Sending environment variables
[h2544161.stratoserver.net] - Sending environment variables: SUCCESS
[h2544161.stratoserver.net] - Initializing start script
[h2544161.stratoserver.net] - Initializing start script: SUCCESS
[h2544161.stratoserver.net] - Invoking deployment process
Invoking deployment process: FAILED
-----------------------------------STDERR-----------------------------------
Failed to remove container (todos-frontend): Error response from daemon: No such container: todos-frontend
docker: Error response from daemon: failed to create endpoint todos on network bridge: Error starting userland proxy: listen tcp 0.0.0.0:80: bind: address already in use.
-----------------------------------STDOUT-----------------------------------
todos
base: Pulling from meteorhacks/meteord
518dc1482465: Already exists
a3ed95caeb02: Already exists
a3ed95caeb02: Already exists
a3ed95caeb02: Already exists
537c534356b6: Already exists
b65a0e1e554b: Already exists
a3ed95caeb02: Already exists
a3ed95caeb02: Already exists
Digest: sha256:b5a4f6efa98e4070792ed36d33b14385a28e6ceda691a492ee5b9f2431b1515a
Status: Image is up to date for meteorhacks/meteord:base
d6d192579495851d5817288ff89abb69512562d7c2a7075f965484e64583c61b
Failed to remove container (todos-frontend): Error response from daemon: No such container: todos-frontend
docker: Error response from daemon: failed to create endpoint todos on network bridge: Bind for 0.0.0.0:80 failed: port is already allocated.
Just had the same issue,
finally deployed after changing file port number to an unused port in my-deployment mup.json somehow docker service could release ports automatically when it wants. I've used 80, 8000, 8001 so far but I haven't successfully deployed to the same port twice, but reading
credit to this
It seems that different deployments may conflict each other pretty easily. I have no resolution for this.
The Example of Dojo tests run under Intern (https://github.com/theintern/intern-examples/tree/master/dojo-example) does not actually test anything, fails on connect to the Sauce network:
$ npm test
> dojo-intern-example#0.1.0 test /home/bogdanbiv/WebstormProjects/intern-examples/dojo-example
> intern-runner config=tests/intern
Listening on 0.0.0.0:9001
Starting tunnel...
Using no proxy for connecting to Sauce Labs REST API.
**********************************************************
A newer version of Sauce Connect (build 1283) is available!
Download it here:
https://saucelabs.com/downloads/sc-4.3-linux.tar.gz
**********************************************************
Started scproxy on port 49172.
Starting secure remote tunnel VM...
Secure remote tunnel VM provisioned.
Tunnel ID: 2f904e21cf1e4c3e83f63a4b3089127c
Secure remote tunnel VM is now: booting
Secure remote tunnel VM is now: running
Remote tunnel host is: maki76020.miso.saucelabs.com
Using no proxy for connecting to tunnel VM.
Establishing secure TLS connection to tunnel...
Cleaning up.
Finished! Deleting tunnel.
Error: failed to connect to tunnel VM.
Error: failed to connect to tunnel VM.
at reject <node_modules/intern/node_modules/digdug/SauceLabsTunnel.js:353:17>
at readStartupMessage <node_modules/intern/node_modules/digdug/SauceLabsTunnel.js:381:12>
at <node_modules/intern/node_modules/digdug/SauceLabsTunnel.js:434:12>
at Array.some <native>
at Socket.<anonymous> <node_modules/intern/node_modules/digdug/SauceLabsTunnel.js:428:21>
at Socket.EventEmitter.emit <events.js:117:20>
at Socket.<anonymous> <_stream_readable.js:746:14>
at Socket.EventEmitter.emit <events.js:92:17>
at emitReadable_ <_stream_readable.js:408:10>
at emitReadable <_stream_readable.js:404:5>
npm ERR! weird error 1
npm WARN This failure might be due to the use of legacy binary "node"
npm WARN For further explanations, please read
/usr/share/doc/nodejs/README.Debian
npm ERR! not ok code 0
Ok it does complain about having an old Sauce Connect binary, but even after downloading and inserting the path of the newest SC (4.3). I also updated .bin/intern-runner to contain js as a running environment as opposed to the old node command. User and password are the ones from the repository (left them unchanged). I followed the documentation and did uncomment the tunnel in the intern config file.
UPDATE: This problem still occurs. I find it wierd that a proxy is started Started scproxy on port 54687., but, further down, Using no proxy for connecting to tunnel VM.. Aren't these lines supposed to match?
It could be that this mismatch has nothing to do with the original problem? The new Sauce Connect binary is still ignored.
UPDATE: Actually this solution affects only client, local - intern-client config=tests/intern. As a result this solution solves a different problem than the one originally posted. /UPDATE
The problem was that although I executed bower install as documented, the bower components installed in a folder set by the bowerrc global configuration. This was quite different from what the Dojo TodoMVC example required for its components.
Also submitted an issue at https://github.com/theintern/intern-examples/issues/10 and a pull request.