Live data from Hacker News

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

tech.cueup.com

61–68 of 68 posts

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

#61

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…

These projects seem to do a very poor job of presenting themselves. I spent a good deal of time reading about each and have yet to have a really good grasp of what they are for. They seem to be about maintaining a cluster of hardware servers to run arbitrary services with configuration and fail over. Do you know of some decent article, blog post, video, whatever that presents these products, what they are good for an…

I agree wholeheartedly about the failure to communicate clearly. At least one contributing factor to the present situation is the lucrative consulting that exists around these solution types and helps to fund their development. Simply put, if it was that easy, everyone would be doing it (and we'd be out of a job). However, to be fair, things change fast and there does exist a lot of good documentation - just not necessarily perfectly up to date for your scenario. Your assumption is perfectly correct. Have a look at http://www.linbit.com/en/downloads/tech-guides or http://clusterlabs.org/doc/ or try #linux-ha or #linux-cluster on freenode.

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

#62
post #59

I'm amazed at how far the linux world has fallen in the last decade. It is now "normal" for people to run an extra layer of buggy crap software to monitor their buggy crap software and restart it when it crashes. Rather than the long standing unix solution of not using buggy crap software that crashes constantly in the first place.

All that unix software was so great! Apache 1! Woo! bind! Yeah! sendmail! Nice! That's pretty much it! It never crashed and was so secure! Happy times!

Trololol.

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

#63
post #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

Interesting hack, sure, but "poor man solutions" would be interesting if "rich man solutions" cost too much. That is not the case here. For someone that can understand this, runit will take < 10 minutes to learn.

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

#64
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 confi…

This!

Curious for people's thoughts on whether Solaris's SMF (or its general model) fits this bill.

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

#65

Earlier quoted context omitted.

You still have to get, and keep, things running on boxes though. HA does not magically remove that need.

Pacemaker/Corosync functionally replace all of the alternatives discussed.

How so?

Is pacemaker/corosync not more of a replacement for things like keepalived/heartbeatd (often used in conjunction with stonith, drbd), and as a way to run clusters of services?

You still need to launch and run the services themselves with something. (sysV init scripts, etc)

Even a cursory review of the docs seems to imply the same.

http://clusterlabs.org/doc/en-US/Pacemaker/1.1-crmsh/html/Pa...

http://clusterlabs.org/doc/en-US/Pacemaker/1.1-crmsh/html/Pa...

http://clusterlabs.org/doc/en-US/Pacemaker/1.1-crmsh/html/Pa...

I do see a reference to:

  > Version 1 of Heartbeat came with its own style of resource
  > agents and it is highly likely that many people have 
  > written their own agents based on its conventions.  
  > Although deprecated with the release of Heartbeat v2,
  > they were supported by Pacemaker up until the release 
  > of 1.1.8 to enable administrators to continue to use
  > these agents.
...so maybe that is what you were talking about.

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

#66

Earlier quoted context omitted.

Pacemaker/Corosync functionally replace all of the alternatives discussed.

How so? Is pacemaker/corosync not more of a replacement for things like keepalived/heartbeatd (often used in conjunction with stonith, drbd), and as a way to run clusters of services ? You still need to launch and run the services themselves with something. (sysV init scripts, etc) Even a cursory review of the docs seems to imply the same. http://clusterlabs.org/doc/en-US/Pacemaker/1.1-crmsh/html/Pa... http://cluster…

Usually there is a resource agent script that replaces the init script. If not, you just write one. This is a barrier to low-level users, but is not an issue for experienced admins/programmers/devops. The primary community library of such lives here: https://github.com/ClusterLabs/resource-agents/

Resource agent scripts can support master/slave style services (including promotion/demotion) in addition to enabling the cluster to self-manage nontrivial overall system state transitions on a multi-host basis. You define the target running state with a declarative syntax that is replicated to across all nodes.

Heartbeat is an earlier platform that has now been functionally replaced by corosync.

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

#68
1. Keep services running: Runit, even with daemontools differences, is hard to beat.

2. Hard(-ish) resource limits and accounting: LXC w/ cgroups. Almost as good as full paravirtualization (Xen). There are still some issues with limiting resource contention impact between cgroups.

3. Softer resource limits, rogue app restarter: We've heavily modified bluepill because it seemed to lack insight on the needs and challenges of large-scale production ops. Specifically, we've added optional total child process limits (a few issues reported, fixed and even submitted a pull request). It might be useful to add max # of processes, nic bandwidth, iops and couple other checks.

Also worth considering:

4. Status monitoring: Icinga

5. Performance: collectd

6. Entropy injection: Chaos Monkey

Post reply on HN