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 -~----------~----~----~----~------~----~------~--~---
