How is this directly related to node and not servers in general?
Keeping node.js servers up forever
31–40 of 41 posts
Re: Keeping node.js servers up forever
#32How is this directly related to node and not servers in general?
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.
Re: Keeping node.js servers up forever
#33Off 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?
Just for you: https://gist.github.com/725354
I was thinking about something like:
meta=document.querySelector('meta[name=viewport]')
meta.parentNode.removeChild(meta)
Re: Keeping node.js servers up forever
#34Earlier quoted context omitted.
Just for you: https://gist.github.com/725354
I was thinking about something like: meta=document.querySelector('meta[name=viewport]') meta.parentNode.removeChild(meta) Thanks anyway for your quick response!
Obviously that's fine for your use-case where the querySelector function is available, but it wouldn't work e.g. on Internet Explorer. My version is also more robust when dealing with markup errors, i.e. when there's more than one viewport meta element.
Re: Keeping node.js servers up forever
#35Earlier quoted context omitted.
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.
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 w…
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.
Re: Keeping node.js servers up forever
#36Earlier quoted context omitted.
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.
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 w…
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 " will run a script called "run" in , restarting it if it fails. It also keeps status information around, so you can run "svstat " to check to status, "svc -d " 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 /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.
Re: Keeping node.js servers up forever
#37Earlier quoted context omitted.
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 w…
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 ,…
Does daemontools care anymore? I use "supervise ~/.dotfiles/service | readproctitle ............." to start my user-local services when I log in. Works like a charm.
Re: Keeping node.js servers up forever
#38Earlier quoted context omitted.
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 ,…
Does daemontools care anymore? I use "supervise ~/.dotfiles/service | readproctitle ............." to start my user-local services when I log in. Works like a charm.
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.
Re: Keeping node.js servers up forever
#39What's wrong with good ol' inittab?
Re: Keeping node.js servers up forever
#40When 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…
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.