Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

tech.cueup.com

Post reply on HN
Print view View original

21–30 of 68 posts

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

#21

Post by contingencies »

Amazed 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 highly flexible daemon migration and monitoring functionality you aren't likely to find anywhere else, for free, and for any imaginable service. (Actually you can monitor anything with it, including hardware. Check it out.)

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

#22

Post by misiti3780 »

I have been using supervisor with my django apps for the past 2 years. I have no real complaints, and actually like how you can easily add new processes with a single conf file and then type

supervisorctl update to start the new deamon without having to restart the whole supervisor process over again ...

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

#23

Post by pjscott »

misiti3780 wrote: post #22

I have been using supervisor with my django apps for the past 2 years. I have no real complaints, and actually like how you can easily add new processes with a single conf file and then type supervisorctl update to start the new deamon without having to restart the whole supervisor process over again ...

Just FYI, that feature is shared by all the alternatives mentioned in the article. (The exception would be runit, which has one supervisor process per service, thus making the issue moot.)

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

#24

Post by rubyrescue »

highly 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 environment and it's flakier, environment variables are missing, etc. Also monit takes a long time to notice things are down, and doesn't start things right away on boot.

Finally if you don't boot your services with monit, you booted them with something else meaning that when a restart occurs, you're starting a service in a different environment than you booted in. weird.

so, let monit check health of things, let runit start and stop things.

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

#26

Post by rektide »

Systemd has socket activation, where it opens sockets and passes them to applications.

But the maintainers seem to have sub-zero interest in passing said listening sockets to multiple applications, which I'm sorry to see not be available. I'm thankful for this article, because it discusses Supervisord and Circus's willingness to do some pooled program handling.

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

#27

Post by justsee »

"Process Supervision: Solved Problem" [0] is a great rundown too (from one of the Chef Opscode guys).

His recommendation is to use runit (based on djb's daemontools).

He recommends against using Bluepill, God, Foreman, supervisor and others.

[0] http://jtimberman.housepub.org/blog/2012/12/29/process-super...

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

#28

Post by sandGorgon »

rubyrescue wrote: post #24

highly 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

#29

Post by sigil »

pjscott wrote: post #15
mrweasel wrote: 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 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 will produce orphans otherwise. (I have some patches to daemontools-encore that do this on a per-service basis.)

The svlogd program from runit also looks nicer than multilog. I've tried to like tai64, I really have, but I'd rather just have human AND machine readable timestamps from the get go.

I like that service dependencies aren't statically declared in runit, but rather something you can block on in your ./run file.

[1] http://untroubled.org/daemontools-encore/

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

#30

Post by sigil »

"The one caveat to be aware of is that Runit expects daemons not to fork."

Nitpick: it's fine if your daemon forks, it just shouldn't background itself, which is different.

A nice succinct implementation of daemonization lives in the BSD sources: https://github.com/DragonFlyBSD/DragonFlyBSD/blob/master/lib...

But don't do this in your code ;) Do use a service manager to do this for you. Programs which lack a foreground option are harder to test and interact with due to the action-at-a-distance -- one of my chief objections with init.d-style service management over what I'll call daemontools-style service management. Nearly all popular daemons will have an option to stay in foreground for this reason. The only exceptional case that comes to mind is nginx, which does have a foreground option, but you'll lose zero-downtime upgrades if you use it (due to some extreme cleverness).

Post reply on HN