well if supervisord is not supported in python2.6 then I may have to switch to something else which would be a real bummer I really liked the way supervisor does things. In any event I think I'll take a look at runit just to get acquainted with it Jose
Jared Rhine wrote: > On 03/29/2009 01:17 PM, Jose Galvez wrote: > >> Max also mentions upstartn, whats the advantage to that over using the >> system V script? >> > > Two advantages are obvious: automatic restart and a dramatically > shorter amount of config needed to get running. > > While supervisord, monit, etc seems to be more popular, I've been > using "runit" everywhere for years and have succeeded in converting a > number of people to its use. runit is basically an open-source, > maintained version of DJB's daemontools. daemontools I guess is open- > source now, but DJB's previous "can't distribute this code if it has > been modified" killed it as a viable project. > > runit's configuration looks much more like upstart than supervisord; > here's one of my production pylons runit start scripts: > > ----- > > #!/bin/sh > > > > exec 2>&1 > > PY=/usr/local/python > export PYTHONPATH=$PY/lib/python2.5/site-packages > > cd /home/tsm > exec chpst -u tsm:tsm $PY/bin/paster serve --reload tsm-prod.ini > > ----- > > Another start script: > > ----- > > #!/bin/sh > exec 2>&1 > exec chpst -u bots:bots -/ /home/eggdrop ./eggrop -n ./eggdrop.conf > > ----- > > (The "exec 2>&1" is to capture stderr output; runit arranges to > capture all stdout of the program and put it into automatically- > rotated log files. upstart can do basically the same using "upstart- > logd".) > > I like runit over upstart, even where upstart is available because 1) > it's available on all unixes and already in most distro package > managers; 2) it uses just scripts and files, not a custom config > language for dependencies/pre-start/post-stop scripts; 3) by default, > it doesn't replace init(1), just adds itself to init. But I would use > upstart probably if it was easily available everywhere I admined. > > Near as I can see, upstart is a reimplementation of ideas long ago > nailed by daemontools and runit, but with a need to back-support SysV > runlevels, a custom config language (instead of some specific > conventions), more direct support for service dependencies, and some > Ubuntu specifics. > > Someone asked if upstart was going to replace SysV startup (at least > on ubuntu). That's their intent; I dunno how successful they will be. > I've had no problems mixing and matching "startup/supervision" > systems, so I don't see a real need for it to be "either/or". I have > many servers with a variety of supervision systems; I tend not to > place Apache under runit (it's easy) because Apache works fine out of > the box on Debian and I haven't had Apache die on me in probably a > decade. > > In general, I like all the "run in foreground" approaches (runit, > daemontools, upstart, supervisord). It's just safer to assume each > layer will die eventually, and arrange for there to be direct > supervision all the way back to init(1). @reboot techniques make me > nervous, though that's also a handy approach. > > Note that it's a really good idea to actual monitor the resulting > service, not just the process id. In this way, monit (or nagios/ > whatever) configured to monitor the actual HTTP port and try a restart > if that fails is more reliable than just "restart if the process > dies". This is because it's possible for the web app process to be > running, but something has broken (database connection, permissions, > etc) that keeps it from actually serving HTTP. > > I might use a great solution like ngnix+mod_wsgi in production for > great performance, but it'd end up having ngnix monitored by runit. > > -- Jared > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
