• Could not connect to Twitter

Running ShowMeDo as a daemonised process using daemontools

We’ve used daemontools to daemonise our TurboGears server under FreeBSD here at zettai.net. daemontools was installed, we just needed to hook into the system. Since this took a bit of time to figure out if I give some pointers then, hopefully, future TGers won’t have the same hassle. I used the lighttpd configuration for serving over port 80, it worked fine.

daemontools is a collection of tools for managing UNIX services.

supervise monitors a service. It starts the service and restarts the service if it dies. Setting up a new service is easy: all supervise needs is a directory with a run script that runs the service.

There’s an overview of daemontools here, and a tutorial here.

We’ve linked our source directory from /service using
cd /service
ln -s /directory/to/src/showmedo

and inside /directory/to/src/showmedo we have a run script containing
#!/bin/sh
exec /usr/local/bin/softlimit setuidgid www python /directory/to/src/showmedo/showmedo-start.py

I also had to modify the showmedo-start.py file to include the following just after line 7’s 'import sys'
import os
os.environ['PYTHON_EGG_CACHE'] = '/usr/local/www/.python-eggs'
from a note here. /usr/local/www/.python-eggs has permissions 755 and is owned by www.

Let us know if this helps you out?

Please share:
  • DZone
  • del.icio.us
  • Reddit
  • Furl
  • Ma.gnolia
  • email
  • StumbleUpon
  • Technorati
  • TwitThis
  • Slashdot
If you enjoyed this post, make sure you subscribe to my RSS feed!

Related posts:

  1. ShowMeDo up and running on new server
  2. We’re getting there
  3. Python to the Rescue
  4. Compiling LAME on RedHat
  5. Using non-Python files with py2exe

3 comments to Running ShowMeDo as a daemonised process using daemontools

  • Oliver Crow

    I tried to setup daemontools to supervise a TurboGears (v0.8.8) application on FreeBSD 5.4. I installed the sysutils/daemontools port (v0.76), and put my service and run file in the default location (/var/service).

    Problems arise when using daemontools if the TurboGears/CherryPy autoreload feature is turned on. This is the default for the TurboGears dev.cfg. CherryPy starts two processes, one of which serves web requests (the child process) and the other monitors and restarts it (the parent process).

    Using daemontools “svc -d” command to bring the service down sends the the parent process a SIGTERM signal which kills it, but the child process doesn’t die … it continues to serve web requests. The problem is that each time you bring the service down and up, you create another extra web server process, and of course only the original one can bind to the socket port and serve web pages.

    Shouldn’t CherryPy catch SIGTERM and cleanup it’s own child process?

  • Administrator

    Sorry Oliver, I don’t know the answer to that. When I’m changing things I unlink the symlink, kill the supervise process and then kill the python TG process.

    After that I work on the run script and the code until everything is good, then I re-link the symlink. I haven’t tried “svc -d”. Please post a follow-up if you get a fix?

    Regards, Ian.

  • Oliver Crow

    Thanks for the followup, Ian. I’ve openned a TurboGears ticket to track the issue:
    http://trac.turbogears.org/turbogears/ticket/405