On 24 Mar 2006, at 23:16, Roberto S. wrote:
Chris, can you give a little highlevel overview about this
project ? I am asking becaues people with java backgorund might
think this has to do with unit tests (junit)
Runit  is an init replacement that has service supervision. It is
compatible with (and uses public domain code from) daemontools 
from Daniel J. Bernstien but released under a BSD license rather than
the license Bernstein uses. You don’t have to replace init to use
runit, you can just use it for service supervision which is how I’m
using it at the moment.
I was using daedalus for process-monitoring until textdrive did not
allow to run it anymore (don’t remember why). How does capistrano-
runit-tasks compare to daedalus (if at all) ?
They work in different ways. If my memory is correct, daedalus works
by scanning the process list using the data you supply, and
performing different kinds of action depending on what is sees there.
i.e. It’s a separate process from the processes it’s monitoring. With
runit, the processes being monitored are child processes of runit
itself (or rather runsvdir/runsv which do the actual monitoring) so
it notices when it’s child dies and restarts it. From what I
remember at the time, TextDrive banned daedalus as people were
putting up apps that were dying and restarting constantly, putting
load on the servers (I could be wrong on that though). Runit wouldn’t
stop this happening, a bad app is a bad app no matter how many times
you restart it There are situations where runit supervision has
advantages over spawner/reaper though IMHO.
- Low memory environments (such as a VPS)
If you’re running on a VPS, you want to leave as much memory as
possible for your database / webserver / fcgis. The more memory you
have free, the more fcgis you can fit in before you need to move to a
dedicated box. While Rails 1.1 removes the spinner so you only need
the spawner running, runit is tiny in comparison leaving more memory
for your app. I run a few (low traffic) rails apps on my VPS and
having spinner/spawner running for each of them was causing swapping
and load. Since moving to runit I’m, not swapping anymore and the
load has gone down by 2. If you’re just running the one app, you only
need one spawner so you might decide your VPS can handle it, but if
you’ve got a couple of apps going I’d recommend runit.
- When you have non fcgi services your app needs to run
For keyref , I have a mailer script that looks through the
database for new PDFs to generate, then generates and mails them.
This can’t be supervised by spawner/reaper so I needed another way of
doing it. Originally I used the ruby daemonize library and had a
mailer_controller script which could be used to stop/start/restart
the service. With runit, I didn’t need the controller script, and can
use the same supervision interface to control the mailer as I use for
- “Enterprise” environments 
I don’t have any experience of using runit in this kind of
enviroment, and I don’t think capistrano-runit-tasks is ready for
this yet, but I hope to make it useful in this situation in the near
future. I’m including this here for completeness.
In summary, if you’re just running a rails app on it’s own box and
the spawner is working fine, it’s probably not worth moving to runit
unless you want to move your whole system over to it. However for
very small and very large environments I think there’s a case for it.
Hope this helps.