ANN: capistrano-runit-tasks 0.2.0

I’d like to announce the second release of capistrano-runit-tasks,
available from http://rubyforge.org/projects/cappy-runit/

It now supports:

  • File based templates
  • sv as the service control command in addition to runsvctrl
  • A much simpler interface for creating additional services.

More work still needs to be done though!

== TODO

  • Allow add_service to create more than one directory to be supervised
  • Add task to automate switching from spinner
  • Make which servers the code runs on configurable
  • Make the rails env configurable
  • Allow creation of other files such as log/config
  • Add support for daemontools svc command
  • Make the RAILS_ENV configurable
  • Add helper methods to make linking the services into the master
    service
    directory easier

Chris
(octopod on freenode)

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)

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) ?

Hi Roberto,

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 [1] is an init replacement that has service supervision. It is
compatible with (and uses public domain code from) daemontools [2]
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 :slight_smile: There are situations where runit supervision has
advantages over spawner/reaper though IMHO.

  1. 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.

  1. When you have non fcgi services your app needs to run

For keyref [3], 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
the fcgis.

  1. “Enterprise” environments [4]

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.

Cheers,

Chris

[1] http://smarden.sunsite.dk/runit/
[2] http://cr.yp.to/daemontools.html
[3] http://keyref.octopod.info
[4] http://defendem.com/read/book/1

Chris, thanks for the clarifications

On 3/25/06, Chris McGrath [email protected] wrote:

  1. “Enterprise” environments [4]

I don’t have any experience of using runit in this kind of
enviroment

Runit working great in “enterprise environment”. On the last Rails
meeting here, in Osaka, I made a presentation for using it in our
company:

the slides: [ http://zhesto.railshosting.org/ls5/show/1 ]
the code (mostly shell): [ http://zh.stikipad.com/notes/show/runrails ]

Maybe will help somebody. Enjoy