I have this node.js accounts app that I'm trying to implement a mongoDB database onto, but it seems to have errors when I upload it to cpanel. My mongoDB url is in this format: mongodb+srv://:#. After some experimenting, turning the Node.js version to ^14 caused errors to stop, but the app still wouldn't run (going to the url reslted in a 503 error, this is the current state of the server).
github: https://github.com/codingtuba/accounts.aimedtuba/tree/mongodb
before mongo DB: https://github.com/codingtuba/accounts.aimedtuba
On Windows 10 PowerShell as admin, trying to deploy a Meteor app using mup, onto a VPS Ubuntu 20.04.2 LTS, all went good but failed to start meteor, as show in the bottom of the print out. I "think" that it is because this sentence at the end;
Error starting userland proxy: listen tcp4 0.0.0.0:80: bind: address already in use.
Server reports:
root#server:~# netstat -tulpn | grep --color :80
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 231/apache2
Any idea how to fix this issue where I need Apache to be running as well as nodeJs? Thank you
Update:
The following is the output of mup deploy --verbose, followed by the file mup.js
C:\my-app-dir\.deploy>mup deploy --verbose
Active Connections
Proto Local Address Foreign Address State
TCP 127.0.0.1:49675 LAPTOP-OLT811G5:49676 ESTABLISHED
TCP 127.0.0.1:49676 LAPTOP-OLT811G5:49675 ESTABLISHED
TCP 127.0.0.1:50151 LAPTOP-OLT811G5:50152 ESTABLISHED
TCP 127.0.0.1:50152 LAPTOP-OLT811G5:50151 ESTABLISHED
TCP 127.0.0.1:50154 LAPTOP-OLT811G5:50155 ESTABLISHED
TCP 127.0.0.1:50155 LAPTOP-OLT811G5:50154 ESTABLISHED
TCP 127.0.0.1:50160 LAPTOP-OLT811G5:50161 ESTABLISHED
TCP 127.0.0.1:50161 LAPTOP-OLT811G5:50160 ESTABLISHED
TCP 127.0.0.1:52367 LAPTOP-OLT811G5:52368 ESTABLISHED
[185.148.129.235] - Pushing Meteor App Bundle to the Server: SUCCESS
[185.148.129.235] - Prepare BundlePTOP-OLT811G5:52800 ESTABLISHED
Updating base image52800 LAPTOP-OLT811G5:52799 ESTABLISHED
node-12-base: Pulling from abernix/meteord811G5:55366 ESTABLISHED
Digest: sha256:79c9c29c028fd72320fa1af5e2bab1147db3c206a9d807e9bdb3fb2110660c1a
Status: Image is up to date for abernix/meteord:node-12-baseLISHED
docker.io/abernix/meteord:node-12-base-OLT811G5:60241 ESTABLISHED
Preparing for docker build LAPTOP-OLT811G5:64587 ESTABLISHED
Creating Dockerfile64587 LAPTOP-OLT811G5:64586 ESTABLISHED
Finished creating Dockerfile LAPTOP-OLT811G5:65122 ESTABLISHED
Building image.0.1:65122 LAPTOP-OLT811G5:65121 ESTABLISHED
Sending build context to Docker daemon 128.6MB:65151 ESTABLISHED
Step 1/7 : FROM abernix/meteord:node-12-base1G5:65150 ESTABLISHED
# Executing 1 build trigger 40.119.211.203:https ESTABLISHED
---> Using cache0.67:52400 142.250.4.188:5228 ESTABLISHED
---> 65200bf0c802.67:52422 40.119.211.203:https ESTABLISHED
Step 2/7 : RUN mkdir /built_app || true216-3-76:https ESTABLISHED
---> Using cache0.67:52447 syd15s17-in-f3:https ESTABLISHED
---> 641135f006a7.67:52449 syd09s14-in-f14:https ESTABLISHED
Step 3/7 : ARG ROOT_URL="http://185.148.129.235.static.a2webhosting.com"
---> Using cache0.67:52625 151.101.193.69:https ESTABLISHED
---> 51449bdf1771Documents\meteor\apps\audio\.deploy> mup deploy --verbose
Step 4/7 : ARG MONGO_URL="mongodb://mongodb:27017/audio"
---> Using cache
---> 9e90ec530e62Pushing Meteor App
Step 5/7 : ARG MONGO_OPLOG_URL="mongodb://mongodb/local"ver
---> Using cache
---> be34137de50b
Step 6/7 : COPY ./ /built_app
---> Using cache
---> c23d46e03e72
Step 7/7 : RUN cd /built_app/programs/server && npm install --unsafe-perm
---> Using cache
---> fccd4584401f
[Warning] One or more build-args [NODE_VERSION] were not consumed
Successfully built fccd4584401f
Successfully tagged mup-audio:build
real 0m9.804s
user 0m0.769s
sys 0m1.010s
Tagged latest
Deleted Images:
deleted: sha256:e869f38ad6f15504fdacb6c286dd7904521f4bf2eb00f699fdefb4fa4d4857e1
deleted: sha256:538b72c0548dcc8e1def78d335a34e448d611ed55105cfcd132f1dc7bfe12ac7
deleted: sha256:16b87889c911fdaeb4225509b676468f9c7df9208fd3e17c075c08646b840c51
deleted: sha256:f2b507302cb528f88d72a8837d74b1d523f60426b0dda43fcb0369f9bf1eef27
Total reclaimed space: 139.4MB
[185.148.129.235] - Prepare Bundle: SUCCESS
Started TaskList: Configuring App
[185.148.129.235] - Pushing the Startup Script
[185.148.129.235] - Pushing the Startup Script: SUCCESS
[185.148.129.235] - Sending Environment Variables
[185.148.129.235] - Sending Environment Variables: SUCCESS
Started TaskList: Start Meteor
[185.148.129.235] - Start Meteor
using image
removing last
Image mup-audio:latest
Volume
Removing docker containers. Errors about nonexistent endpoints and containers are normal.
audio
Error response from daemon: endpoint audio not found
Error: No such container: audio-frontend
Error response from daemon: endpoint audio-frontend not found
Error: No such container: audio-nginx-letsencrypt
Error response from daemon: endpoint audio-nginx-letsencrypt not found
Error: No such container: audio-nginx-proxy
Error response from daemon: endpoint audio-nginx-proxy not found
Finished removing docker containers
e63e684acf2ba89117a8ee7c4a53c28ca08cd5fdeacc8c7b368689fcd36172b1
docker: Error response from daemon: driver failed programming external connectivity on endpoint audio (6dcafd574d2116c25d289cc71e15c41112b53a049a52c6481ecd20e51ec8414c): Error starting userland proxy: listen tcp4 0.0.0.0:80: bind: address already in use.
[185.148.129.235] x Start Meteor: FAILED
------------------------------------STDERR------------------------------------
Removing docker containers. Errors about nonexistent endpoints and containers are normal.
Error response from daemon: endpoint audio not found
Error: No such container: audio-frontend
Error response from daemon: endpoint audio-frontend not found
Error: No such container: audio-nginx-letsencrypt
Error response from daemon: endpoint audio-nginx-letsencrypt not found
Error: No such container: audio-nginx-proxy
Error response from daemon: endpoint audio-nginx-proxy not found
Finished removing docker containers
docker: Error response from daemon: driver failed programming external connectivity on endpoint audio (6dcafd574d2116c25d289cc71e15c41112b53a049a52c6481ecd20e51ec8414c): Error starting userland proxy: listen tcp4 0.0.0.0:80: bind: address already in use.
------------------------------------STDOUT------------------------------------
using image
removing last
Image mup-audio:latest
Volume
audio
e63e684acf2ba89117a8ee7c4a53c28ca08cd5fdeacc8c7b368689fcd36172b1
------------------------------------------------------------------------------
******************************************************************************
//mup.js
module.exports = {
servers: {
one: {
host: '185.148.129.235',
username: 'root',
password: 'abcdefghij',
opts: {
port: 7822
}
}
},
app: {
name: 'audio',
path: '../',
servers: {
one: {},
},
buildOptions: {
serverOnly: true,
},
env: {
ROOT_URL: 'http://185.148.129.235.static.a2webhosting.com',
MONGO_URL: 'mongodb://mongodb/meteor',
MONGO_OPLOG_URL: 'mongodb://mongodb/local',
},
docker: {
image: 'abernix/meteord:node-12-base',
},
enableUploadProgressBar: true
},
mongo: {
version: '3.4.1',
servers: {
one: {}
}
},
};
Since the Ubuntu VPS had Apache2 server listening on port 80, and mup makes the same port number for the docker-containing-meteor-app to listen on. I needed to stop the Apache2 systemctl stop apache2, then mup deploy worked and now the meteor app is accessable on the browser.
Now I need to find out how to use nginx as a proxy for the meteor app.
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.
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.
I am currently running a basic website on an amazon EC2 t1.micro instance.
The application is built using sails.js / node.js and is booted up using pm2.
After a while I get the following message in the errors log file and the server crashes:
FATAL ERROR: Committing semi space failed. Allocation failed - process out of memory
Could somebody help me with this issue?
Have I misconfigured something?
I am running:
Node version 5.9.0
NPM 3.7.3