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.
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.
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 use foreman to run my node.js applications on the production servers (ubuntu server 12).
Foreman has a great tool to create scripts for upstart.
The problem is that when I reboot a server, my application (managed by foreman) is launched before redis-server and I've to build some tricks in order to wait for a valid connection.
The ideal solution will be to start redis-server earlier, and hen the node application when all is started.
Boot configuration :
redis-server is launched by /etc/init.d/redis-server and is /etc/rc2.d/S20redis-server
my node application is started with /etc/init/stocks-streamer*.conf files
My question is : how would you change the boot order of my node application?
I want to wait for redis-server before my application starts but when I do this, it doesn't start :
start on (started redis-server)
I imagine that it's because no events are sent from init.d scripts to upstart but perhaps there is a way I don't know ?
Thanks by advance for your help !
Perhaps you should have redis be started by foreman instead, so you can better control all the dependencies of your app.
Or make sure foreman start much later than redis (make sure foreman's link in /etc/rc2.d is listed later than S20*.
One more alternative: have redis server also be started by upstart, this is likely going to help upstart manage the dependencies.
There are explanations on how to do this here: https://gist.github.com/bdotdub/714533
And I suggest using "Start must precede another service" instead (http://upstart.ubuntu.com/cookbook/#start-must-precede-another-service) so that redis gets started when you start your own service.
Since this question has no accepted answer, and given I just had the same problem here, I figured I would provide another solution. The question could be re-stated as:
How do I make an upstart job wait on an init.d script?
As the OP says in the question, it's possible to emit an upstart event when the init.d script is started. This way, the upstart job can have a simple start on started SCRIPT_NAME declaration.
In my case, using a custom CentOS-based distribution, my /etc/rc.d/rc is in charge of executing the sysvinit (init.d) scripts. That script is fully upstart aware, and so emits upstart events for each sysvinit script that is started/stopped.
In other words, the /etc/rc.d/rc script has something like this (simplified to leave the juicy stuff):
for i in /etc/rc$runlevel.d/S* ; do
subsys=${i#/etc/rc$runlevel.d/S??}
initctl emit --quiet starting JOB=$subsys
$i start
initctl emit --quiet started JOB=$subsys
done
I imagine you need to take a look at your scripts and add the event emission where you think it's suitable. In my case, the emission was already there.
You can wait for several events in an upstart job. See this question for how to find out what events are available (I haven't found a better documentation to be honest).
In particular the trick to grep -r emit seems very useful.
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.
Is there a universally accepted means of deamonizing (and of course, later communicating through signals or some abstraction thereon) a node script?
That is, is there a Node equivalent of:
if (fork())
// parent process, die
exit(1);
// we're a daemon
The following is a list of ways to run Node as a background daemon on
different platforms:
nodejs-autorestart manages a Node instance on Linux which uses Upstart (Ubuntu, Debian, and so on).
fugue watches a Node server, restarting it if it crashes.
forever is a small commandline Node script which ensures a script will run "forever".
node-init is a Node script which turns your Node application into a LSB-compliant init script. LSB being a specification of Linux
compatibility.
There is not a built-in way to do this in Node. Take a look at Writing Daemon's in JavaScript with Node.js for one implementation (warning: this is relatively old and Node moves fast--I haven't tested it. :)
Upstart works well for me, though I'm having an issue when I serve over https. Here's the tutorial I used:
http://kevin.vanzonneveld.net/techblog/article/run_nodejs_as_a_service_on_ubuntu_karmic/
You can use node's process object to send/handle signals.
As others have pointed out there really isn't a way to do this in Node directly. You really need to run it using foreverjs. The reason you need to run it using a monitor like forever, is because error thrown by your code will often result in the entire Node process to quit and exit. A monitor will look for this occurring and restart the process immediately.
It is also important to note that while the process is restarting, your server will not respond to request so plan ahead if you expect this to be a problem and make sure that you have a few servers processes running under a load-balancer.