Live data from Hacker News

Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God

tech.cueup.com

11–20 of 68 posts

Re: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God

#11
post #8

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…

Daemontools has never let me down. It plays nicely with the OS in that I don't have to muck around with essential system daemons and init scripts, and it corrects all sorts of bad behavior. I run everything with it: python, java (including long-running servers), ruby, perl... Really a fantastic package.

Re: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God

#12
post #11
post #8

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…

Daemontools has never let me down. It plays nicely with the OS in that I don't have to muck around with essential system daemons and init scripts, and it corrects all sorts of bad behavior. I run everything with it: python, java (including long-running servers), ruby, perl... Really a fantastic package.

You could easily have written the exact same thing about Upstart, Systemd, or Runit. :-)

Re: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God

#13
post #12
post #11

Earlier quoted context omitted.

Daemontools has never let me down. It plays nicely with the OS in that I don't have to muck around with essential system daemons and init scripts, and it corrects all sorts of bad behavior. I run everything with it: python, java (including long-running servers), ruby, perl... Really a fantastic package.

You could easily have written the exact same thing about Upstart, Systemd, or Runit. :-)

I think it's a question of which tool you learn first. You learn one, it solves your problems and the rest does it differently, so they're "wrong" or difficult in your eyes.

Re: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God

#14
When I saw the title "vs. God", I thought it was going to include something like "Tup vs. the Eye of Mordor", a whimsical performance comparison between the Tup build system and "The Eye or Mordor" in the guise of a simple script that does no dependency checking because it already knows what has changed: http://gittup.org/tup/tup_vs_mordor.html

Re: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God

#15
post #8

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…

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 doesn't need to affect you if you just want to get a few programs running. Their big selling point, for me, is that one of them is usually the default and the config files are quite easy to write if you're not doing anything elaborate.

Re: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God

#16
Poor man's solution:

    echo 'pidof myapp > /dev/null || su appuser -c "myapp --arguments" &' > ~/check_services.sh
    echo 'exit 0' >> ~/check_services.sh
    chmod 700 ~/check_services.sh
    #Add ~/check_services.sh & to /etc/rc.local for startup
    #Add */1 * * * /root/check_services.sh to crontab

Re: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God

#18
Like others have already said, monit also deserves a mention. Whilst it can start the process for you, it probably doesn't really fall under the same category. It's more about making sure things are running, do not consume too much resources etc.

However, the flexibility of monit beyond process monitoring is really great. Anything from filesystem usage, cpu, memory to monitoring tcp ports, file checksums, you name it. I'm yet to find something you can't do with this little toy, and it's rock solid. I even use it to pull graphite stats[1] and report when certain thresholds are reached, like the percentage of 500s compared to other response codes in my nginx logs.

I also personally like its configuration syntax better than most yaml-like DSLs. It feels almost like writing natural text.

[1]http://blog.gingerlime.com/2013/graphite-alerts-with-monit/

Re: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God

#19

Like others have already said, monit also deserves a mention. Whilst it can start the process for you, it probably doesn't really fall under the same category. It's more about making sure things are running, do not consume too much resources etc. However, the flexibility of monit beyond process monitoring is really great. Anything from filesystem usage, cpu, memory to monitoring tcp ports, file checksums, you name it…

[deleted]

Re: Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God

#20
Hi, author of the post here. The thing that really surprised me, when writing this, was how difficult it was to find the edge of the topic: where does process supervision end, and server monitoring begin? If most of these programs include something for handling logs, are they then also logging software? Where's the boundary between watching processes and gathering metrics on them? Good software is canonically supposed to do one thing well, but it seems like nobody can agree what handles what here. I even started writing sections on logging and server monitoring, before sanity prevailed and I chopped them out.

It's maddening that we have no clear separation of responsibilities for this stuff. And so we end up with things like Upstart's half-hearted logging, because it's not clear where Upstart's job stops.

Post reply on HN