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

41–50 of 68 posts

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

#41

Post by pjscott »

justsee wrote: post #27

"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...

If you do what that guys says and use runit, you'll be happy. I use runit, and I am happy with it.

However, I also think you'll be happy with Upstart or Systemd, even if you find them over-engineered and inelegant. They'll do what they need to with minimal configuration, and you're probably already using one of them behind the scenes. Why not use one of them, if you have it sitting right there, already installed and configured?

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

#42

Post by jacques_chester »

pjscott wrote: post #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 suppose…

The tangled world of service monitoring, process monitoring, process launching, configuration management etc etc et bloody c is waiting for a ZFS-style collapsing of multiple fighting tools into a single layer.

I noticed this most of all when I was writing puppet manifests that ... create Upstart scripts.

Why do I have one tool that configures and supervises the bits at rest and a completely different tool that configures and supervises the same bits in flight?

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

#43

Post by bdcravens »

gingerlime wrote: post #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…

+1 to monit. I have an app that does a lot of scraping via Selenium, headless using xvfb and Firefox. If the Selenium scripts fail, Firefox never closes. On an EC2 micro instance, it doesn't take long before 40MB+ FF processes kill other things, like Tomcat (which runs my queue processor). I use monit to watch the root URL, and when it fails, it fires off a handful of scripts that restart the various pieces of the application.

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

#44

Post by tarekmoz »

adambratt wrote: post #38
slurgfest wrote: post #25

I would really like to hear from more people who use Circus in production. It seems interesting.

Tried it and I can tell you it's not production ready. It would randomly go rogue on our production servers and would start falsely detecting a worker crash and start launching more. 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.

Circus author here.

I am interested in any form of feedback on the issues you had. Falsely detecting a work crash sounds very weird and unprobable because Circus uses the system PID list to check on processes - so I wonder what happens in your case.

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

#45

Post by __david__ »

I'll throw my hat in the ring here and point out daemon-manager: http://porkrind.org/daemon-manager/

It was designed to be simple (creating a new daemon conf file is trivial), low over-head (it's very init-ish in function so it needs to not take a lot of memory or processor time), stable (can't crash or it loses track of everything that it launched), and secure (lets you launch your daemons as different users--usually at a lower security level).

I've been using it myself an almost every server I administrate (I wrote it to scratch my own itch) for a couple years now and it's been very stable.

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

#46

Post by jamwt »

pjscott wrote: post #40
jamwt wrote: post #34

Earlier quoted context omitted.

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.

I think that logging should be separate here, so I'm actually okay with built-in logging support being minimal to nonexistent. If you use multilog (from daemontools) it will handle logging to rotated files; if you use svlogd (from runit), it can do the same, and also includes syslog support. If you just log to syslog in the first place, and your syslogd is at all modern, it can also handle writing things to log files…

Yeah, I agree. To this end, I just added support for specifying a logger process, and angel will now pipe stdout/stderr to it ala daemontools. Definitely don't want angel in the business of being a log rotator.

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

#47

Post by jokull »

runit user here. For someone without a strong understanding of UNIX the runit documentation will strike her as a little low level. That being said, the learning curve is steep but short. What’s missing is a blog post that explains UNIX from the point of view of runit. Starting & restarting and logging. It’s actually a good place to start learning more about UNIX.

Zed Shaw has also starting a project of his own to tackle these things. Not sure how it handles multiple unrelated things. Seems to be a good idea to document in understandable Python code, what the requirements are to daemonize a process corrently.

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

#49

Post by naner »

sdfjkl wrote: post #48

My favorite remains BSD style (rc.conf+rc.d/) init - which for some reason receives no mention here. Arch Linux used to have it too, but then inexplicably dumped it. http://www.freebsd.org/cgi/man.cgi?query=rc&sektion=...

Inexplicably? They didn't want to fight against upstream. You'd have to maintain your own scripts for every daemon you supported if you didn't use systemd. Also other software like udev is getting sucked into systemd as well. Arch is a small distro and doesn't have the development power to customize everything.

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

#50

Post by antihero »

One thing I always found annoying is, say I am on a shared host like WebFaction, and I use supervisord to manage my uWSGI (or whatever) instances. What do I do to ensure supervisord itself starts? Current approach is a script run by cron that greps ps for supervisord and if not found, launches it. But that seems rather flakey and unreliable.

Suggestions?

Post reply on HN