Keeping node.js servers up forever

http://blog.nodejitsu.com/keep-a-nodejs-server-up-with-forever

by maraksquires • 16 years ago

84 37 16 years ago

blog.nodejitsu.com

Forever a node.

substack• 16 years ago

I like how there's a command line interface plus an application interface, so I can tie forever process management into my web interface and backend control interface. Right now the processes are just sitting in a `while true` bash loop.

indexzero4• 16 years ago

Thanks. If you dig in a little deeper you can see I use optimist for the CLI parsing :)

In the next version I'd like to expose a web service and also have hooks for doing things like sending emails when forever restarts a process.

todd3834• 16 years ago

I have been using supervisord to solve this problem. It doesn't care what language your app was written in and works very well.

dkasper• 16 years ago

Just deployed this now. Took all of roughly 10 seconds to setup and working beautifully. I've used supervisor in the past, and this was definitely easier.

gruseom2• 16 years ago

By using the 'http' module we can run a stand-alone web server in node.js without the need for a separate server like Apache or nginx.

Last I checked Ryan was saying this was a very bad idea. Has that changed? It's certainly enticing.

indexzero4• 16 years ago

When did you last check with him? I've been running w/o a separate server (effectively) for ~3 months.

gruseom2• 16 years ago

Oh, I just meant last I checked on blogs and such (not with him personally). IIRC, his main reason for advising against it was that there were too many security holes. This was in a video talk from several months ago if not longer. I'm curious to know if conditions have changed.

intranation2• 16 years ago

This reminds me of the bad old days of Rails, when every man and his dog had some random hacky and myopic solution to keep Rails and Mongrel running. Just say no to Node/Rails/whatever specific-stuff, kids--use system level tools for running processes.

Edit: removed references to "proprietary", as indexzero is correct about meaning of that.

indexzero4• 16 years ago

That's a strange usage for "proprietary" since it's all free and open source (MIT). Either way, the nodejs child_process module is really just a light weight wrapper to execvp():

http://linux.die.net/man/3/execvp

I haven't dug through the source for tools like monit, daemontools, but I'm sure near the metal they're using POSIX or similar system APIs.

EDIT: There's really no reason Forever has to be node specific, I actually say that in the article:

"Honestly, it's a one line fix here (https://github.com/indexzero/forever/blob/master/lib/forever...), but I'm not sure if users want to put 'node' in-front of every command."

I'll file your comment as a +1 for that feature ;)

viraptor2• 16 years ago

I just have to wonder - after listing all those projects which already do this job and do it well... Why create / use `forever` which didn't get the same exposure to the production environments yet?

maraksquires2• 16 years ago

Well, we can call native node.js code from our process monitor now.

We can extend our process monitor with functionality that would be difficult to implement in those other tools.

intranation2• 16 years ago

Any examples of when this would be desirable? Seems to me that monitoring and running tools should just, you know, monitor and run things. Separation of concerns.

indexzero4• 16 years ago

@intranation Just to toss out a scenario: Lets say under high traffic your application hits an edge case and starts to crash very frequently. Suppose you want to receive an email, SMS, or IM when something like this happens as a devops person.

Would you consider that a valid concern of process monitoring?

Planned features to Forever include this from the command line, but if you use it from node directly one could implement that feature now:

https://github.com/indexzero/forever

Skywing• 16 years ago

bookmarked. thank you.

jacquesm• 16 years ago

This leads to a very bad practice though, which is to cause bugs to be left laying around in production systems. You should really form the habit of analyzing such crashes, getting to the root cause of the problem and making sure that it never ever happens again.

It's good to have a system like this in place, but it should be used as an insurance policy against unknown bugs, not as a way to work around known and reproducible ones.

Kilimanjaro2• 16 years ago

Off topic, but I like to read blogs on my ipad while in bed and I hate it when authors fuck up with the meta viewport tag.

If I want to double tap to zoom in, because my eyes are not the same as 20 years ago, just let me do that, ok?

Sounded snob? maybe. Sounded reasonable? hell yes.

Btw, is there a bookmarklet to remove the meta viewport tag available somewhere?

ionfish2• 16 years ago

Just for you: https://gist.github.com/725354

Kilimanjaro2• 16 years ago

I was thinking about something like:

    meta=document.querySelector('meta[name=viewport]')
    meta.parentNode.removeChild(meta)

Thanks anyway for your quick response!

jasonkester2• 16 years ago

When I see a blog post like this, it serves more to raise doubts about Node.js than anything else.

Before today, I had been considering Node for an upcoming product. Now I read that people are actually building and releasing software to work around the fact that Node.js servers regularly incapacitate themselves. Really? Like it just goes down and doesn't know how to cycle itself? Ouch. That translates to me as "Don't go anywhere near Node.js until they get it stable."

So yeah, I'm sure this is a great way to shore up your system. Buy I'm going to think twice before investing time in a system that needs shoring up.

jrockway3• 16 years ago

More of a safety mechanism than anything else. I use daemontools to run qmail, and qmail has never crashed. But if it did, I would still want to receive my email, even though it's "horrible" that qmail could crash.

Sometimes the safest way to handle an error is to kill the process and start a new one. Starting recovery from a known-good state is better than starting from a known-bad one.

jasonkester2• 16 years ago

Seems reasonable enough. From the tone of the post, it sounded like crashing was a fairly common thing to happen with Node.js, and that it didn't cycle itself.

Coming from the context of IIS/ASP.NET, which hasn't yet crashed on me (at least not without cycling itself harmlessly) in the 10 years I've been running sites on it, the possibility that you'd need to worry about such things seemed a bit novel.

So basically what you're saying is that it just follows the Unix philosophy and doesn't run its own daemon to cycle it if it falls down. That doesn't sound anywhere near as unreasonable.

lacker• 16 years ago

Criticizing node.js for not knowing how to restart itself is like criticizing Python for not knowing how to restart itself. node.js is an interpreter, it doesn't implement every part of a production stack.

I don't use Forever, but I use upstart with respawn which is similar, and I use it to monitor not just node.js daemons but also ones written in python, bash, and whatever else. Monitoring software is a reasonable part of a stable production system; it indicates a healthy ecosystem rather than a deficient one.

zbanks• 16 years ago

Oddly enough, the site is down.

jimmyjazz14• 16 years ago

daemontools is a beautiful thing, personally I think its a much better idea to have a general purpose tool for this kind of thing. I'm not sure why everyone feels the need to reinvent the wheel when it comes to managing background services.

waratuman• 16 years ago

Use Upstart.

richcollins• 16 years ago

How is this directly related to node and not servers in general?

iclelland• 16 years ago

The application described in the article is specifically written to interface with Node.js servers. It keeps those processes running, and restarts them as needed. It is not a general process monitor.

mkrecny• 16 years ago

What's wrong with good ol' inittab?

Keeping node.js servers up forever

Related Stories