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.
Related
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.
I'm running some file management tasks through a node script. The node-windows package is included to allow me to run this script as a windows service. I encountered a serious error this morning when I realized that the service had started a duplicate instance of the same script. This is very bad, it corrupted 24-hrs worth of data because both scripts were trying to process the same data sets and ended up shredding them. I've never seen the windows service allow something like this. Has anyone else had this problem or have any idea what is causing it?
See my comment about node-windows instances.
The real problem, which is data corruption, doesn't have anything to do with node-windows. The node script should have fault tolerance for this. More specifically, it should be implementing file locking, which is a standard practice to prevent this exact scenario.
There are a couple of file locking modules available. lockfile is what npm uses. There is also another project called proper-lockfile, which solves the problem in a slightly different (more Windows-friendly) way.
I have a node.js program that's hanging after completing everything I want it to do. I'm fairly certain it is an open connection somewhere that is keeping the program from exiting. Is there a way to tell/debug what is keeping the program from exiting?
Unnecessary edit: This question is in no way similar to my question: How do I debug Node.js applications? . Thanks for playing tho..
There is an npm module Why is node running module which helps in "Node is running but you don't know why?"
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.
It says on the Node.js about page:
Node exits the event loop when there are no more callbacks to perform.
Is there a way to find out which callbacks are keeping Node from exiting?
You can use process._getActiveHandles() and process._getActiveRequests()
See this discussion in node.js mailing list.
update: there is a good package for this - https://github.com/mafintosh/why-is-node-running
There is a npm module wtfnode to show what keep the nodejs app running when you sends SIGINT (ctrl-c) to it.
It internal uses process._getActiveHandles() as mentioned in #andrey-sidrov's answer. The benefit of using wtfnode is that it provides easy-to-read output.
If you are interested to find out which open connections are still open:
While the process hangs, you can run in mac and linux: netstat -a to search for open ports. It's a good clue that helps me from time to time when it comes to why Jest is hanged.