Process Managers: The Good, the Bad, and the Ugly

For years, I used daemontools (it still runs a bunch of machines) then moved to runit, which follows the same philosophy. Both are excellent tools and have worked extremely well under many different circumstances. Simple tools that do one thing extremely well. Every managed service requires a short, 1 to 3 line, script to actually start the target program, which may, initially, seem off-putting, but actually provides the often missing opportunity to easily customize the program environment.<p>BTW, runit also comes with svlogd and chpst, both of which have frequently proved invaluable. The latter is useful in its own right.<p>Most of the tools discussed either lack flexibility, try to do too much, or simply don't offer any benefits over runit and company.

FWIW, from a few months ago:<p><a href="http://jtimberman.housepub.org/blog/2012/12/29/process-supervision-solved-problem/" rel="nofollow">http://jtimberman.housepub.org/blog/2012/12/29/process-super...</a><p>tl;dr use runit

I've always used (and loved) daemontools / runit (<a href="http://smarden.org/runit/" rel="nofollow">http://smarden.org/runit/</a>) - it's a little bit minimal, but it's well-documented, does what it claims to do, and it's rock-solid.

Was surprised not to see God (<a href="http://godrb.com/" rel="nofollow">http://godrb.com/</a>) here, has it fallen from grace?

The article is a bit wrong about supervisord. You can load environment variables from a defaults file - just use a wrapper script. Eg:<p><pre><code> #!/bin/sh source /etc/myservice/defaults exec celeryd $@ </code></pre> And start that from supervisord.<p>Also, another nice thing, very useful for daemons that spawn their own subprocesses is killasgroup option. This is worth mentioning given the celery examples - celery can and will leave orphan processes around between restarts ...

I swear this is one of the hardest problems in computer science, which is crazy - how hard should it really be to say "run this process, and restart it if it crashes"?

"The convenience of custom commands like /etc/init.d/nginx configtest to check my nginx configuration syntax without affecting the running nginx service is useful enough to keep me from migrating my nginx daemonization to Upstart."<p>Needing to run "nginx -t" instead of "/etc/init.d/nginx configtest" seems like a minor tradeoff for the benefits Upstart provides. It's even shorter to type!

Timely, since I spent some time over the weekend digging into the internals of Supervisor.<p>One of the most interesting features, for me, is that Supervisor has an XML-RPC interface[1], allowing for some creative interaction with supervisor and the processes it manages.<p>[1] <a href="http://supervisord.org/api.html" rel="nofollow">http://supervisord.org/api.html</a>

Another recent comparison: <a href="http://tech.cueup.com/blog/2013/03/08/running-daemons/" rel="nofollow">http://tech.cueup.com/blog/2013/03/08/running-daemons/</a>

Thanks very much for this! It's great to have someone else's insight into several of these.

This is a super helpful writeup on a topic I needed an intro to, thanks so much!

systemd is the way to go. Don't waste time debugging someone's half-baked pile of {shell,Perl,Python} scripts