
Deploying Node.js with systemd - rubenv
http://savanne.be/articles/deploying-node-js-with-systemd/
======
kronholm
"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).

~~~
rubenv
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.

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

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

------
jat850
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.

~~~
rubenv
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 :-)

~~~
jat850
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.

------
funthree
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

~~~
chad_oliver
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.

~~~
rubenv
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.

~~~
funthree
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...

