There is no comparison to daemontools yet because I’ve never used it. Runit seem to be running at entire different level and monit… also never tried (seems to be too complex and underpowered).
Disclaimer: in this post there’s no religion involved. ‘god’ mentioned here is a ruby gems that is just happen to be named god (seriously, this is not how you should name your program – googling for it results in too much noise)
[ god | supervisord ]
Installation/Upgrade
God can be installed easily using gem which, as I said before, is an excellent ruby module manager. It can install several versions of same gem, upgrade, uninstall, cleanup gems easily.
OTOH, installing supervisor will either: pray so you can upgrade/uninstall it later (as there is no easy/clean upgrade/uninstall functionality), install (compile) entire python distribution on another folder so you can just nuke that folder when fail happen, or pray so your current OS’ package manager has supervisord (ArchLinux and FreeBSD have. The FreeBSD one is still in testing though).
Overall I found installing god is much easier than supervisord.
Compatibility
Both has poll based, but IIUC only god has event-based management. Not available on Solaris yet though.
Other than that both are pretty much compatible with *BSD/Solaris/Linux/OSX
Configuration
In short: god is complex (powerful), supervisord is simple (less powerful).
In god, you have complete control of how you want your services started/stopped/restarted, how you want the service is – running as daemon (with PID) or let god daemonize it, resource monitor, etc (more later). But it has one problem: configuration is non-trivial. Most of time it is copypasta-fest. And getting/ensuring services running correctly is another problem.
supervisord is simple to configure (one of my service only has two lines) but it provides much less flexibility.
Overall I’d say if you don’t need advanced configuration with god you can stick with supervisord.
Features
Both can automatize homogenous group processes (ie. 5 instances of mongrel serving on different ports as cluster).
With god you can have complete control of your services. Custom commands can be set to stop/start/restart services. It can daemonize processes and gives pidfile automatically.
Further than that, god has monitoring capabilities. CPU/memory usage is directly available and fully controllable.
Killing ‘god’ process (in forced way) doesn’t kill the services. It can be either a good or bad thing, depends on how you look at it.
Simplicity is the first thing comes to mind when reading the documentation. And it is indeed simple. Except for advanced monitoring which doesn’t seem to be trivially possible with it. Custom restart and stop command isn’t possible (other than changing the signal type for stopping process), monitoring processes’ CPU usage doesn’t seem to be immediately possible and memory usage monitoring adds three more lines to configuration.
My favorite feature of supervisord is its ability to spawn fastcgi processes. It can basically replace spawn-fcgi (with monitoring, of course) and, just as spawn-fcgi, can spawn several fastcgi processes and bind them in one port or socket. This is one feature I find missing in all other monitoring tools.
Other feature I find highly useful is supervisorctl. Basically a ‘command line’ version of Microsoft’s services.msc. Upon running it you can control every processes and add/remove services in one command (adding service need another shell running symlinking/updating configuration files, though).
Performance
Starting supervisord is under one second while god can take a while to load. God also uses more memory and cpu. Other than that I don’t see another difference between the two.
Problems
Both have its own problem.
God, as mentioned before, is heavier. Last time I heard it seems to be still having problem with memory leak. Personally I’ve seen god uses over 100 MB of memory (and weird enough few minutes later dropped to 30-something MB). Note that supervisord uses less than 20MB of memory.
In supervisord, there is one thing that absolutely should never be done (as of 3.0a7): add/remove/update fastcgi service. Basically it doesn’t unbind the port used and updating the service sometimes broken. And it doesn’t notify if there’s error in fastcgi process and either gives cryptic and useless error message or shows no error message at all. Update: the fix will be in next version (3.0a8?).
Conclusion
god is good if you need advanced monitoring features. I most likely will need them but it’s still missing supervisord’s fastcgi spawning capability.
supervisord, as mentioned above, is fast, simple and can spawn/monitor fastcgi processes.
One solution would be to use god as main monitoring tools and let supervisord/spawn-fcgi spawn fastcgi processes… 😀
[ god | supervisord ]
FYI, I fixed the bug you mentioned with dynamically reloading a fastcgi config in supervisord and it is commited in the trunk (http://lists.supervisord.org/pipermail/supervisor-checkins/2009-September/000210.html). I had contributed the FastCGI spawning code to supervisord before the dynamic config reloading was implemented.
I know – I saw you in the mailing list.