OpenShift socket.io : express deprecated app.configure: Check app.get('env') - node.js

After setting client and server side of socket.io, what I think are the right links, now something else sprung up.
My assumption is - I am using an old express version or one that is too new for the code I have?
DEBUG: Program node server.js exited with code 0
DEBUG: Starting child process with 'node server.js' Tue, 29 Jul 2014 13:51:04 GMT express deprecated app.configure: Check app.get('env') in an if statement at server.js:11:5 info: socket.io started warn: error raised: Error: listen EACCES
DEBUG: Program node server.js exited with code 0
DEBUG: Starting child process with 'node server.js' Tue, 29 Jul 2014 13:51:06 GMT express deprecated app.configure: Check app.get('env') in an if statement at server.js:11:5 info: socket.io started warn: error raised: Error: listen EACCES
Any guidance?

For the deprecated function app.configure just use app.use without using app.configure, and for the error Error: listen EACCES check if you have anything listening in the port you are trying to start your server.js

Related

Error deploying a node.js app to Elastic Beanstalk on Amazon Linux 2

I am trying to have a node js app on Elastic Beanstalk.
On Amazon Linux Image the environment gets created and works smooth.In order to get it done I followed the instructions given in the AWS documentation itself. It works on single instance.Also,using Nginx and have terminated HTTPS on the instance by following the info here
The root directory of the app contains:
.ebextensions
index.js
package.json
By following all those instructions step by step given in AWS documentation the environment is created and the app is deployed successfully(For Amazon Linux Image).
However, been trying to deploy it to Amazon Linux 2.And the deployment fails with the Health status for the environment being "DEGRADED".
A snippet of the eb-engine.log:
[INFO]
> grpc#1.24.3 install /var/app/staging/node_modules/grpc
> node-pre-gyp install --fallback-to-build --library=static_library
Failed to execute '/opt/elasticbeanstalk/node-install/node-v10.15.1-linux-x64/bin/node /opt/elasticbeanstalk/node-install/node-v10.15.1-linux-x64/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js configure --fallback-to-build --library=static_library --module=/var/app/staging/node_modules/grpc/src/node/extension_binary/node-v64-linux-x64-glibc/grpc_node.node --module_name=grpc_node --module_path=/var/app/staging/node_modules/grpc/src/node/extension_binary/node-v64-linux-x64-glibc --napi_version=3 --node_abi_napi=napi --napi_build_version=0 --node_napi_label=node-v64' (1)
Snippet of the web.stdout.log:
Sep 13 12:55:31 ip-172-31-1-73 web: > nodetryapp#1.0.0 start /var/app/current
Sep 13 12:55:31 ip-172-31-1-73 web: > node index.js
Sep 13 12:55:31 ip-172-31-1-73 web: [DEFAULT]
Sep 13 12:55:32 ip-172-31-1-73 web: events.js:174
Sep 13 12:55:32 ip-172-31-1-73 web: throw er; // Unhandled 'error' event
Sep 13 12:55:32 ip-172-31-1-73 web: ^
Sep 13 12:55:32 ip-172-31-1-73 web: Error: listen EACCES: permission denied 0.0.0.0:80
Sep 13 12:55:32 ip-172-31-1-73 web: at Server.setupListenHandle [as _listen2] (net.js:1260:19)
Snippet from nginx/error.log:
2020/09/13 13:06:31 [alert] 4023#0: *1021 1024 worker_connections are not enough while connecting to upstream, client: 127.0.0.1, server: , request: "GET /hudson HTTP/1.1", upstream: "http://127.0.0.1:80/hudson", host: "*SOME IP ADDRESS*"
For deploying the app on Amazon Linux 2 Elastic beanstalk the root folder of the app consists of the following files/folders:
.ebextensions/https-instance.config and .ebextensions/https-instance-single.config
.platform/nginx/conf.d/extendnginx.conf (In order to extend the nginx config so as to terminate the https at the instance)
index.js
package.json
The instance type is a Single instance, t2.micro.
You cannot run your application on port 80 and 443 because these ports are exclusive for Nginx/Apache service inside Beanstalk AMI. Instead of using these ports, use 8080 for HTTP connections and 8443 to HTTPS connections.
Yes, now it is working!So followed what #Raul Barreto said in his answer above.
Made the following changes:
The 'port' environment variable is now set to 8080.
In the .platform/nginx/conf.d/extendnginx.conf file added
upstream nodejs {
server 127.0.0.1:8080;
}
instead of
upstream nodejs {
server 127.0.0.1:80;
}

Cannot connect to Node.js application on shared server

I have setup a node.js application and it's running on port 4999, but when I browse to the url www.website.com:4999 I get a This site can’t be reached error in Chrome and Secure Connection Failed in Firefox
The is the code in SSH used to start the node app
[~/public_html/customer_portal]# gulp serv:prod
[13:48:50] Using gulpfile ~/public_html/customer_portal/gulpfile.js
[13:48:50] Starting 'ConcatScripts'...
[13:48:50] Starting 'ConcatCss'...
[13:48:50] Starting 'CopyAssets'...
[13:48:50] Finished 'ConcatCss' after 553 ms
[13:48:50] Starting 'UglyCss'...
[13:48:50] Finished 'CopyAssets' after 855 ms
[13:48:50] Finished 'UglyCss' after 322 ms
[13:48:50] Finished 'ConcatScripts' after 925 ms
[13:48:50] Starting 'UglyScripts'...
[13:49:08] Finished 'UglyScripts' after 18 s
[13:49:08] Starting 'Inject:PROD'...
[13:49:08] gulp-inject 1 files into index.build.ejs.
[13:49:08] gulp-inject 1 files into index.build.ejs.
[13:49:08] Finished 'Inject:PROD' after 218 ms
[13:49:08] Starting 'build:prod'...
[13:49:08] Finished 'build:prod' after 61 μs
[13:49:08] Starting 'serv:prod'...
[13:49:08] Finished 'serv:prod' after 48 ms
livereload[tiny-lr] listening on 35729 ...
Mon, 25 Jul 2016 03:49:09 GMT express-session deprecated undefined saveUninitialized option; provide saveUninitialized option at app.js:58:13
XXX service has been started at port: 4999 !!!
Just compiling the solution we derived from the comment in OP's post.
So OP had tested his nodeJS application locally and now he is wanting to expose it to the world wide web. While OP did not post content of his gulpFile but I am guessing that he is trying to use a development server spin up by gulp to serve his web page. Not impossible, however certainly not recommended.
A better replacement would be to use a real web server like nginx.
See:
https://nginx.org/en/docs/beginners_guide.html
Back to the original problem. The real reason why OP is getting hit by the error This site can’t be reached was probably because his server did not have the required port forwarded, in this case port 4999. To workaround this temporarily would be to update the Gulp file to host the application on port 80 instead.
However I am still dubious about the error message because I would have thought OP should see something like connection refused. Anyway, this is not important.
To sum up, OP should consider fixing his problem by;
install a real web server on his machine
place the application onto the installed web server

Restarted my server and started getting this error: Forever detected script exited with code: 8

I resized my Digital ocean droplet (Permanently) This required I powered off my droplet and then powered on again. When I visit the webpage I get a typical NGINX page saying that I have succesfully installed NGINX, the web app can no longer be seen
I did a mup logs -f to see what is going on and I am continually getting this error.
I am not sure what is wrong and it looks like something is off with my cron jobs but I am not sure what. Any ideas:
error: Forever detected script exited with code: 8
[xxx.xxx.xxx.xx] error: Script restart attempt #75[xxx.xxx.xxx.xx]
[xxx.xxx.xxx.xx] {"line":"63","file":"synced-cron-server.js","message":"SyncedCron: Scheduled \"Email Weekly Todos for Mentors\" next run #Mon Nov 30 2015 07:00:00 GMT-0500 (EST)","time":{"$date":1448741207434},"level":"info"}[xxx.xxx.xxx.xx]
[xxx.xxx.xxx.xx] {"line":"63","file":"synced-cron-server.js","message":"SyncedCron: Scheduled \"Weekly Push Notifications to students\" next run #Sun Nov 29 2015 10:00:00 GMT-0500 (EST)","time":{"$date":1448741207437},"level":"info"}[xxx.xxx.xxx.xx]
[xxx.xxx.xxx.xx]
[xxx.xxx.xxx.xx] events.js:72[xxx.xxx.xxx.xx]
[xxx.xxx.xxx.xx] throw er; // Unhandled 'error' event
[xxx.xxx.xxx.xx] [xxx.xxx.xxx.xx] ^
Error: listen EADDRINUSE
at errnoException (net.js:905:11)
at Server._listen2 (net.js:1043:14)
at listen (net.js:1065:10)
at net.js:1147:9
at dns.js:72:18
at process._tickCallback (node.js:442:13)
error: Forever detected script exited with code: 8[xxx.xxx.xxx.xx]
Any ideas would help a lot
I fixed the issues by setting the app file in sites-enabled folder to listen to port 3000. I think it was listening to 80 by default and conflicting with nginx

Meteor deploy error on meteor host

I have an app without database functionality today I added some simple sitemap code with Mongo collection to app and test it locally all of things worked well but when I deployed application to meteor hosting with meteor deploy command my app crashed. I give this detail from meteor logs command:
[Wed Jun 24 2015 08:01:42 GMT+0000 (UTC)] WARNING MongoError: auth fails
at Object.Future.wait
(/meteor/dev_bundles/0.4.18/lib/node_modules/fibers/future.js:398:15)
at new MongoConnection (packages/mongo/mongo_driver.js:213:1)
at new MongoInternals.RemoteCollectionDriver
(packages/mongo/remote_collection_driver.js:4:1)
at Object.<anonymous> (packages/mongo/remote_collection_driver.js:38:1)
at Object.defaultRemoteCollectionDriver
(packages/underscore/underscore.js:750:1)
at new Mongo.Collection (packages/mongo/collection.js:98:1)
at app/server/sitemap.js:1:44
at app/server/sitemap.js:22:3
at
/meteor/containers/9d7d4183-ba55-fb30-3eb2-d6bceabe37e2/bundle/programs/server/boot.js:222:10
at Array.forEach (native)
- - - - -
at Object.toError
(/meteor/containers/9d7d4183-ba55-fb30-3eb2-d6bceabe37e2/bundle/programs/server/npm/mongo/node_modules/mongodb/lib/mongodb/utils.js:114:11)
at
/meteor/containers/9d7d4183-ba55-fb30-3eb2-d6bceabe37e2/bundle/programs/server/npm/mongo/node_modules/mongodb/lib/mongodb/db.js:1194:31
at
/meteor/containers/9d7d4183-ba55-fb30-3eb2-d6bceabe37e2/bundle/programs/server/npm/mongo/node_modules/mongodb/lib/mongodb/db.js:1903:9
at Server.Base._callHandler
(/meteor/containers/9d7d4183-ba55-fb30-3eb2-d6bceabe37e2/bundle/programs/server/npm/mongo/node_modules/mongodb/lib/mongodb/connection/base.js:453:41)
at
/meteor/containers/9d7d4183-ba55-fb30-3eb2-d6bceabe37e2/bundle/programs/server/npm/mongo/node_modules/mongodb/lib/mongodb/connection/server.js:487:18
at [object Object].MongoReply.parseBody
(/meteor/containers/9d7d4183-ba55-fb30-3eb2-d6bceabe37e2/bundle/programs/server/npm/mongo/node_modules/mongodb/lib/mongodb/responses/mongo_reply.js:68:5)
at [object Object].<anonymous>
(/meteor/containers/9d7d4183-ba55-fb30-3eb2-d6bceabe37e2/bundle/programs/server/npm/mongo/node_modules/mongodb/lib/mongodb/connection/server.js:445:20)
at [object Object].emit (events.js:95:17)
at [object Object].<anonymous>
(/meteor/containers/9d7d4183-ba55-fb30-3eb2-d6bceabe37e2/bundle/programs/server/npm/mongo/node_modules/mongodb/lib/mongodb/connection/connection_pool.js:207:13)
at [object Object].emit (events.js:98:17)
[Wed Jun 24 2015 08:01:42 GMT+0000 (UTC)] ERROR Application crashed with code:
8
[Wed Jun 24 2015 08:01:42 GMT+0000 (UTC)] INFO STATUS running -> waiting
[Wed Jun 24 2015 08:01:45 GMT+0000 (UTC)] INFO HIT / 89.165.17.140
And this is my sitemap.xml code:
Pages = new Mongo.Collection("pages");
// https://atmospherejs.com/gadicohen/sitemaps
sitemaps.add('/sitemap.xml', function() {
var out = [], pages = Pages.find().fetch();
out.push({
page: '/',
lastmod: new Date(),
changefreq: 'always'
});
_.each(pages, function(page) {
out.push({
page: page.url,
lastmod: page.lastUpdated,
changefreq: 'weekly'
});
});
return out;
});
Please guide me how to fix this issue on deployment. On the local machine all things working right. )-:
After two days there is still a problem. My site is still not available and this is error:
This site has crashed.
Site administrators can examine the logs with:
meteor logs example.com
Retrying in x seconds...
It seems to be an error in the way the deploy scripts set up your deployment that has nothing to do with your code. To fix it, the app must first be deleted then re-deployed (or simply deployed under a different name):
meteor deploy xxx --delete
meteor deploy xxx

Node.js stopped with "Sending SIGTERM to child" for no reason

This problem is pretty much the same issue posted on https://www.openshift.com/forums/openshift/nodejs-process-stopping-for-no-reason. Unfortunately it remains unanswered.
Today my Node.js app stopped few times with DEBUG: Sending SIGTERM to child... on the logfile. No more, no less. My application is a very simple single-page app with single AJAX endpoint, serving 1k-2k pageviews per day. It has been running well for days without any problem.
I use these modules:
express
body-parser
request
cheerio
-- Update:
I'm using one small gear. 512MB mem, 1 GB storage
Excerpts from log file (~/app-root/logs/nodejs.log)
Thu Jul 17 2014 09:12:52 GMT-0400 (EDT) <redacted app log message>
Thu Jul 17 2014 09:13:09 GMT-0400 (EDT) <redacted app log message>
Thu Jul 17 2014 09:14:33 GMT-0400 (EDT) <redacted app log message>
DEBUG: Sending SIGTERM to child...
#### below are the log entries after issuing "ctl_app restart"
DEBUG: Running node-supervisor with
DEBUG: program 'server.js'
DEBUG: --watch '/var/lib/openshift/redacted/app-root/data/.nodewatch'
DEBUG: --ignore 'undefined'
DEBUG: --extensions 'node|js|coffee'
DEBUG: --exec 'node'
DEBUG: Starting child process with 'node server.js'
Stats from oo-cgroup-read, as suggested by #niharvey. A bit too long, so I put it on http://pastebin.com/c31gCHGZ. Apparently I use too much memory: memory.failcnt 40583. I suppose Node.js is automatically (?) restarted on memory overusage events, but in this case it's not. I had to restart manually.
I forgot that I have an idle MySQL cartridge installed, now removed.
-- Update #2
The app crashed again just now. Value of memory.failcnt stays same (full stats on http://pastebin.com/LqbBVpV9), so it's not memory problem (?). But there are differences in the log file. The app seems restarted, but failed. After ctl_app restart it works as intented.
Thu Jul 17 2014 22:14:46 GMT-0400 (EDT) <redacted app log message>
Thu Jul 17 2014 22:15:03 GMT-0400 (EDT) <redacted app log message>
DEBUG: Sending SIGTERM to child...
==> app-root/logs/nodejs.log-20140714113010 <==
at Function.Module.runMain (module.js:497:10)
DEBUG: Program node server.js exited with code 8
DEBUG: Starting child process with 'node server.js'
module.js:340
throw err;
^
Error: Cannot find module 'body-parser'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
To simulate this problem on your local machine run your server with supervisor in one terminal window:
supervisor server.js
Then from another terminal use the kill command
kill process_id#
The kill command with no parameters sends a SIGTERM message to the application. If supervisor receives a SIGTERM it will stop immediately.
The sample code from the sample application provided by OpenShift listens to 12 different unix signals and exits. It could be that someone at OpenShift is manually killing the process because the application is not listening to a signal that was intended to reboot it. I'm adding this code to my application to see if the behavior is more stable.
function terminator(sig){
if (typeof sig === "string") {
console.log('%s: Received %s - terminating sample app ...',
Date(Date.now()), sig);
process.exit(1);
}
console.log('%s: Node server stopped.', Date(Date.now()) );
};
process.on('exit', function() { terminator(); });
['SIGHUP', 'SIGINT', 'SIGQUIT', 'SIGILL', 'SIGTRAP', 'SIGABRT',
'SIGBUS', 'SIGFPE', 'SIGUSR1', 'SIGSEGV', 'SIGUSR2', 'SIGTERM'
].forEach(function(element, index, array) {
process.on(element, function() { terminator(element); });
});
Usually this is because your app became idle. When you ssh into the app you should see something like:
*** This gear has been temporarily unidled. To keep it active, access
*** your app # http://abc.rhcloud.com/
You can try to use a scheduled ping to keep the app alive.
I had this same issue. I deleted the gear and created a new one. The new one has been running for a few days and doesn't seem to have the issue.
[Update]
After a few days, the issue appeared on my new gear.

Resources