I have been using forverjs for my server but for some reason the server stopped and the server didn't restart again. Is foreverjs reliable?
Should i use any other libs?
Found there are many libs like pm2, nodemon, upstart, systemd, nginx. Which one should ensure my application running all the time. also can these tools handle large loads of requests?
There are multiple questions within your question to analyze.
Is foreverjs reliable?
forever is a very popular package. As seen on GitHub, it has 75 contributors and 636 commits. This question is mainly opinion-based, but 9/10 (maybe 10/10) experienced developers would say it's reliable for it's purpose (I expand below).
Should i use any other libs?
Reliability is achieved through sturdy software design and not just packages you choose. I have used forever and pm2 production processes for years without any problems on their end. They include great features for reliability, such as attempting to restart your application if it crashes. Packages are not supposed to fix terminal bugs in your code.
Found there are many libs like pm2, nodemon, upstart, systemd, nginx.
Which one should ensure my application running all the time.
This can be found through reading their GitHub descriptions. I use nodemon for quickly testing code as it's written. For example, I start the nodemon process and it begins my Node.js process. When I edit my code and press save, the Node.js process is automatically stopped and restarted with the new code. nodemon should not be used alone for a long-running production server, since it will stop when you exit your shell. pm2 and forever are effective libraries and you can investigate upstart, systemd, and nginx if necessary.
Regarding #Kalana Demel's answer, I consider using forever to run nodemon as using forever in my explanation above.
how to ensure my application is reliable all the time
For an overall answer to your question, you should be writing tests to ensure your code is reliable. If you've written effective unit and integration tests, choosing a package to run the process will be trivial (and not related to reliability), since you should not expect it to crash.
nodemon is a good option, you can use a combination of forever and nodemon using,
forever start -c nodemon app.js
Also in my experience forever is very reliable, try
forever logs app.js
to see what exactly caused the error
pm2 is good option in these cases, I personally use pm2 in all my node.js servers, it provides alot of more important functionalities in comparison to others.
One of the best thing about it can be easily integrated with keymetrics/newrelic for analytics of the server.
Also pm2 will give you cpu/memory usage, you can even configure the restart limit and interval.
Related
In the past couple of years NodeJS became a major player in the server landscape - and I really find it hard to believe that there is no decent way to have nodejs run as a service on a linux box. On Windows we have iisnode - but for non Windows environments the forever package is suggested as the way to go - instead of a real solution.
Is there maybe a servicized version of nodejs out there that I could not locate?
There isn't a "servicized" version of Node.js available in the sense you are thinking. Keeping your Node application running (for example in the event of a fatal error) is up to you entirely.
As suggested in the first comment, this is fairly subjective, but really there are two big packages (and one or two alternative methods) for making a service out of your Node application. As you've mentioned, forever is a popular choice. If you've never taken a look at pm2, I suggest doing so, as it offers some services that forever does not. Alternatively, you could search for information on supervisord, which I've had success with in the past. Finally, daemonizing Node with upstart is something to look at if the others don't fit well for you.
I have multiple node.js apps running at my VPS, and I access to it through ssh. Right now I start them in the way:
nohup node server.js
That looks good but I get whole logs to nohup.out, and what's more important and not efficient is about restarting of stopping them.
If I do ps -A | grep node I will get an output like:
9172 ? 00:00:01 node
9178 ? 00:00:00 node
...
So, how can I identify them?
I also knew about nodemon and it's great! But however logging out ssh breaks the magic.
I think maybe some more advanced tools would help out. What's the best approach for this?
Just in case, I use Nginx on top (port 80) and do reverse proxy, but I'd be ok changing that.
One solution (there are many) is pm2: https://github.com/Unitech/pm2
It's a process manager for node, and comes with a variety of features, some of which include the ability to spread your app across multiple CPU cores while providing an easy TTY management view of the applications. It also has the ability to reload the apps without stopping them.
If the readme's not sufficient, I found this post useful in understanding the basics: http://devo.ps/blog/2013/06/26/goodbye-node-forever-hello-pm2.html
You can run nodemon under --quiet mode and it'll suppress all nodemon output (and keep your logging working).
I am looking to daemonize my Node.js application. What's the difference between upstart and forever? Also, are there other packages I might want to considering looking at?
As pointed out in the comments, upstart will be used to start the forever script, since upstart has hooks for system events (like shutdown and startup of your server).
The other differences are:
Upstart was developed for Linux, while forever is platform-independent.
Forever is specific to nodejs, and has some pretty cool features with regards to restarting your server after it crashes, and logging.
Forever is sufficient for development environment, while upstart is necessary if you need to have some control over how your server is stopped. For example, on shutdown, the forever process would simply get killed, but, with an upstart script, you can collect logs and notify the admin.
Upstart allows you to add other monitoring tools, like Monit.
Among the available other solutions, you can try daemon, which is equivalent to forever.
I would disagree with #leorex with regards to upstart setup. Check out this blog post for an excellent example.
upstart is a general utility for daemonizing an application. Forever is designed for Node.js. For most purposes, forever is better for Node.js applications as it is simpler, tuned towards node.js and easy to configure. Just try a few tutorials on upstart and you will agree with me.
The main difference in objective is that upstart is designed to start an application on system boot. Forever doesn't have that and instead is focused on keeping a node.js script running despite crashes (most likely unhandled exceptions). You will be wise to combine the two .. i.e. start forever yourscript.js from upstart (on system boot).
That said you will need to look at your platform specific version of upstart equivalent. Upstart was never on windows and is now deprecated for ubuntu / debian : http://www.markshuttleworth.com/archives/1316
In 2017, alternatives could be :
pm2. Robust, strong community, production-grade solution. Can manage non-node scripts as well. My personal choice.
StrongLoop (slc). Node-only. Production-oriented as well, includes build/packaging, deployment to docker, load-balancing and profiling, but is more recent. Looks promising.
Here is a (maybe biased) comparison of both with Forever.
according to many articles, the best way to handle uncaught exceptions in a node.js app is let the process crash and than restart it. This avoids to have our application in a unstable state.
I think it can be done with an external process like a watchdog (sometimes called angel process).
What is the best way to do this in a linux system? At first glance a bash script checking the node process state every n seconds could be a possible solution.
Thank in advance, any suggestion will be really appreciated.
Node.js Best Practice Exception Handling
http://shapeshed.com/uncaught-exceptions-in-node/
http://debuggable.com/posts/node-js-dealing-with-uncaught-exceptions:4c933d54-1428-443c-928d-4e1ecbdd56cb
There are a handful of solutions like the watchdog/angel process you mention. The one you most often hear thrown around is "forever". It's available via npm.
To install, just: npm install -g forever
Then when you want to run your app: forever app.js instead of node app.js
I have successfully used supervisord, I think it fits your purpose very well. It's not node-specific and you can use it virtually with anything that won't detach from the console.
And with the events feature, it gives a nice flexible tool for all kinds of scenarios.
I am a node.js developer. I use Amazon ec2 to deploy my node.js apps.
I want to have my node.js service running permanently - restarted if it fails for any reason.
I came across 2 tools . Forever and Upstart
Is there any advantages of using one over the other ?
Is there any other tool which is better ?
Upstart is a system service controller, similar to SysV Init and will start/stop/restart essentially any service registered for it, Node.js-based or not, and it will also automatically start services on system start for you. But Upstart is essentially specific to Ubuntu, and Upstart-specific services won't run on other Linux distros.
Upstart has a SysV Init compatibility layer that you could target,instead, to maintain as broad of a compatibility layer as possible.
Forever is a Node.js application that monitors and restarts other Node.js applications as needed, and as defined by its configuration JSON. Lots of options and fine-grained control over your service without the effort that would be needed to duplicate it in a custom SysV Init script. However, Forever isn't a system service, so if the server is restarted, you'll have to manually start your forever scripts again.
Beyond that, if all you need is something that will restart your script if/when it crashes, and you don't care about it starting automatically on system start, all you need is a bash script as simple as:
#!/bin/bash
while true
do
node ./myScript.js
done
Just to correct a misleading statement in the accepted answer...it is not true that upstart is an Ubuntu-only technology. See:
https://serverfault.com/questions/291546/centos-6-and-upstart
http://searchenterpriselinux.techtarget.com/tip/RHEL-6-ditches-System-V-init-for-Upstart-What-Linux-admins-need-to-know
http://en.wikipedia.org/wiki/Upstart#Adoption
With that, I think it is a much more compelling solution.