Update: It was simply an import error in the Pylons app (because $PYTHONPATH is different when running a launchd job) that was causing a fail-respawn cycle. Many thanks for those who told me to look at my logs.
I'm on OS X, trying to set up a launchd job to start and keep alive my pylons application.
I load the job as usual:
sudo launchctl unload /Library/LaunchDaemons/dvlf.plist
4/12/11 6:23:57 PM com.apple.launchd (com.dvlf.pylons) Throttling respawn: Will start in 9 seconds
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
When I've seen "respawning too fast" on SysV init systems (/etc/inittab entries) it's been because the program in question was using the traditional "double fork, then exec" strategy to become a daemon. Many such programs (such as sshd and sylogd) support command line switches (-D for sshd, for example) which instruct them to refrain from
The problem is that init (and presumably launchd) are attempting to monitor the process in order to handle respawning them if/when they exit. When the program attempts to put itself in the background (disconnect itself from the parent process, process group, and all related signal handling) then this is detected as a near immediate exit which requires the respawn. inittab (and, again, presumably launchd) are imposing rate limiting to keep one failing program from keeping the system excessively busy.
The solution to this issue see if you can configure this dvlfs.pylons program to run in the foreground or "don't detach" or "don't daemonize" ... terminology to that effect.