I still prefer Bernsteins daemon-tools. I first used them when I had to deploy qmail and now I use them to manage Python webapplications. The default logging option is a bit weird, but the simplicity is a real winner for me. I don't like Upstart, I don't agree that it's "admirably simple to use", it needlessly complex. For what I do, I don't need or want to care about runlevels, I always want respawning and I don't l…
Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God
31–40 of 68 posts
Re: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God
#32Earlier quoted context omitted.
Runit is very similar in design to Daemontools, but it seems generally more featureful and better maintained. If you like one, chances are you'll like the other. (Also, daemontools' licensing is no longer an issue; it's been public domain since 2007.) I do take issue with your characterization of Upstart and Systemd as needlessly complex; almost all of that complexity is for their role as init.d replacements, and doe…
As a diehard daemontools user this comment made me take another look at runit. Just to be clear, runit is one of several forks of daemontools. Another one is daemontools-encore [1]. There are a couple nice runit features that stock daemontools lacks. The ability to run each service in a separate process session with "runsvdir -P" is a big one. If your ./run file consists of a pipeline, bouncing the service with TERM…
Re: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God
#33I still prefer Bernsteins daemon-tools. I first used them when I had to deploy qmail and now I use them to manage Python webapplications. The default logging option is a bit weird, but the simplicity is a real winner for me. I don't like Upstart, I don't agree that it's "admirably simple to use", it needlessly complex. For what I do, I don't need or want to care about runlevels, I always want respawning and I don't l…
I agree with liking the simplicity of daemontools. I haved used it for a while, and it has served me well. I like that logging is split. I often run the log script as just a logger instance to get stdout to syslog.
Upstart is.... Not my favorite.
runit is nice. Like daemontools with manages and a few extra flags/features.
Re: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God
#34Anyone have any experience with Bump's Angel?
Re: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God
#35Amazed to see so many simple responses in this thread given that the single-system paradigm is sort-of heading out of date now (manual Unix systems administration is arguably a dying horse). For any serious (ie. highly available) systems, a major option that should be under discussion is Pacemaker/Corosync. http://clusterlabs.org/ It's a pain to learn, easy to screw up, non-trivial to test exhaustively, but provides…
Re: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God
#36Earlier quoted context omitted.
As a diehard daemontools user this comment made me take another look at runit. Just to be clear, runit is one of several forks of daemontools. Another one is daemontools-encore [1]. There are a couple nice runit features that stock daemontools lacks. The ability to run each service in a separate process session with "runsvdir -P" is a big one. If your ./run file consists of a pipeline, bouncing the service with TERM…
runit also has man pages.
http://smarden.org/pape/djb/manpages/
The manpages are installed by default in every system I use -- debian, ubuntu, MacPorts, and FreeBSD ports.
Re: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God
#37Earlier quoted context omitted.
runit also has man pages.
daemontools also has manpages, thanks to Garrit Pape, the author of runit ;) http://smarden.org/pape/djb/manpages/ The manpages are installed by default in every system I use -- debian, ubuntu, MacPorts, and FreeBSD ports.
Re: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God
#38I would really like to hear from more people who use Circus in production. It seems interesting.
It took us a long time to trace it down and we quickly switched to runit and supervisor on a few servers. All of our problems went away.
Re: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God
#39highly recommend runit + monit. The beauty of runit is the ./run script is easy to run by hand to test. The beauty of monit is it can watch things like http urls and ports, and if something goes wrong, monit executes sv down myservice; sv up myservice. (sv is the actual launcher-thingy of runit) If you use monit without runit, you end up in this weird world where monit starts and stops things in a very odd environmen…
are you using ruby with rhnit? which server (mongrel, thin, etc) do you recommend for playing nice with runit - which the OP mentioned has a problem with fork.
Re: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God
#40Anyone have any experience with Bump's Angel?
Angel author here. It works very well for us and some others, but it must be said it is not as featureful as most of these. For example, it provides no assistance for log rotation (you'd need to do this via a shell pipeline with multilog or similar) and does not have a "control interface" (zmq socket etc) of any kind.
Or you can do something event more radical, like using fluentd[1], which looks really useful and well-designed. I like having this decision decoupled from the process manager. So, I would not count that as a strike against Angel.