Keeping node.js servers up forever(blog.nodejitsu.com) |
Keeping node.js servers up forever(blog.nodejitsu.com) |
Edit: removed references to "proprietary", as indexzero is correct about meaning of that.
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 ;)
We can extend our process monitor with functionality that would be difficult to implement in those other tools.
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:
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.
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?
meta=document.querySelector('meta[name=viewport]')
meta.parentNode.removeChild(meta)
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.
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.
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.
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.
Last I checked Ryan was saying this was a very bad idea. Has that changed? It's certainly enticing.
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.
I'd much rather have access to a well structured library (node.js) where sockets and http are first class citizens, opposed to being forced into a solution or having to write C or bash.
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.
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.