Deploying Node.js with systemd | Hacker News Reader

Deploying Node.js with systemd

savanne.be

72 pointsrubenv11 comments

"Simply starting node on your server is a recipe for disaster. If it crashes (and at some point it will, node code is perfect), your service will be wiped of the internet."

The solution to that in the article seems an awful lot of trouble. You can just use the following in your script to keep it from crashing/exiting whenever there's an exception, warning or whichever:

process.on('uncaughtException', function (err) { //do stuff });

I've used that in a few projects, where it usually sends me an email if something goes wrong. (npm: mailer).

That assumes that node itself will never crash, or that your server will never reboot.

Just keeping it running isn't the main point though: socket activation is great if you want to increase server density. And the whole-system monitoring + resource policies are very nice tools for system administrators.

There's a lot more to systemd and node.js than simply running node.

Good to know, thank you - will definitely have to try it out then!

There is a lot of wealthy information in OPs post. The socket activation will be nice for some QA servers that I have planned.

rubenv - Can you comment at all on using something like monit to watch node processes - we leverage it fairly heavily on our servers but have not really gone through as many steps as you have here. We use upstart to handle starts, stops, and restarts, and monit to watch for crashes.

Monit falls in the category of forever: it's a duplication of your process manager. I think you can do some of these things with upstart as well.

If you are currently running Ubuntu and use upstart, by all means leave it like that: don't fix it if it ain't broken.

But do know that you miss out on some very nice things :-)

It does look that way, yes - some of the stuff you point out looks great and is worthy of consideration. I just was wondering if maybe we were way off base in our mechanisms - we are far from web ops specialists by any means.

Originally we did just purely use upstart to control things but it was pretty dreadful at doing certain things compared to monit, and we have a lot of familiarity with monit from our embedded hardware projects.

socket activation is nice, but i dont think its intention is for something like this. if your app automatically quits after 5 minutes, and it takes a few seconds to start because initialization in node is synchronous, then this is just kind of weird

monit is great because you can get emails if your app goes down, it monitors files and all kinds of other stuff. you could easily use socket activation with monit so that a crashing node process drops as few connections as possible by passing along the fd to another node process, but then if you are going to do this you might as well use cluster and fork your node process.

tldr; many ways to skin a cat, but turning off your node process because it is idle is kind of weird because it has implications for the first visitor, and it shouldnt just be reached for as a standard way of running node

I believe the last slide shows that the restart takes 48 milliseconds, and I get similar results with one of my own processes running on our server. This doesn't seem like a big deal at all.

For large node programs, this approach may require careful optimization of the start process in the same way that we optimize the client-side page loading process.

Chad_oliver is right: the impact is negligible. We wouldn't do it if it would deteriorate the user experience.

There's a lot of great documentation on the systemd site. An exact description of socket activation and its intended use cases is on there as well: this is definitely one of them.

different node processes start up differently, some can take a while. auto-quit after 5 minutes, really? socket activation is helpful for lazily loading things when a system boots up, so everything can be started in parallel and the order that processes come online doesnt matter. its been adapted to all kinds of things and im not saying it wouldnt work in some use cases to conserve resources, but socket activation + auto quit is a bit odd. node actually benefits from running for a long time or from being hit with a lot of requests -- even if your app starts fast you are trading this away among many other things...

Reply on news.ycombinator.com