[jasonkester]

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.

[jrockway]

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.

[jasonkester]

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.

[jrockway]

Yeah, exactly. I have not looked at the app described in the article, but daemontools is a set of programs that let you manage persistent processes. "supervise <directory>" will run a script called "run" in <directory>, restarting it if it fails. It also keeps status information around, so you can run "svstat <directory>" to check to status, "svc -d <directory>" to kill it, etc.

On top of that is svscan, which will look for service directories in a directory, and will start a supervise instance for each. It will also start a supervise instance for <directory>/log if it exists, piping the output of the supervised script to the logging process.

In this way, you just need to write a service that writes log messages to stdout, and it will handle log rotation and process management. It's really a nice system, although apparently rather unpopular. I guess it's more fun to write your own logging and daemonization code, rather than let a very small C program that has existed unchanged for 10 years do it. Or something.

[silentbicycle]

Erlang has heart (http://www.erlang.org/doc/man/heart.html) for similar reasons. Of course, it also has distribution, for when the whole computer it's running on dies.

I use runit (http://smarden.org/runit/) instead of daemontools (same sort of thing, but a bit less opinionated about e.g. where it gets installed). Rather than expecting every daemon to implement its own supervisor, logging system, etc. correctly, just use one of those.

[jrockway]

Does daemontools care anymore? I use "supervise ~/.dotfiles/service | readproctitle ............." to start my user-local services when I log in. Works like a charm.

[silentbicycle]

It's been a while since I installed daemontools. IIRC it created a bunch of root directories (e.g. /commands). There was also an OpenBSD port for runit already.

[lacker]

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.