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

Runit – a Unix init scheme with service supervision

smarden.org

Post reply on HN
Print view View original

41–50 of 69 posts

Re: Runit – a Unix init scheme with service supervision

#41

Post by general_failure »

freshhawk wrote: post #32
paulsmith wrote: post #4

Earlier quoted context omitted.

Not only is it simple and does the do-the-one-thing-well thing well, which is true, it's also _correct_. It's hard to overstate how valuable runit is in production because of that. It does the right thing with regard to clearing the environment, detaching from controlling terminal, logging, and many other subtle aspects of operating a service. I never worry about runit.

Back when I changed from supervisord to runit my life was substantially improved. That correctness means way fewer emergency maintenance ops issues in production.

What is wrong with supervisord?

Re: Runit – a Unix init scheme with service supervision

#43

Post by kragen »

davexunit wrote: post #10

I use GNU dmd instead. Simple and very extensible with Scheme. I use it as PID 1 on 2 of my machines, but I use another instance of it as a user service manager on all of my machines. I've also been meaning to replace runit with dmd in Phusion's passenger-docker image to get something more hackable. https://gnu.org/s/dmd

Having dynamic memory allocation, let alone garbage collection, in my pid 1 doesn't sounds like a great idea.

(I know, as long as I'm using Linux, I'm stuck with dynamic memory allocation in the fucking kernel. I don't have a plan for how to fix that yet.)

(Also, thank you so much for all your help with Guix this last week!)

Re: Runit – a Unix init scheme with service supervision

#44

Post by clebio »

JoshTriplett wrote: post #9
clebio wrote: post #5

Given the other glowing comments, maybe this would be a place to ask: should I bother with Upstart, or Systemd? I see Shuttleworth announced the move to systemd, but it's not available on Ubuntu 14.04 servers right now. I'm writing provisioning for our production fleet, what should I use? The vagaries of the OS wars make something like Runit tempting.

Depends heavily on what you need to provision, and whether you can select your provisioned environment based on what you want to support. Upstart is, at this point, effectively dead for any future distribution. However, if you want to support existing Ubuntu LTS distributions for the remainder of their lifetime, you'll need to handle it. Similarly, if you want to support the current rounds of enterprise distributions…

I appreciate the detailed reply, and the others as well. To address your questions and some of the others:

We can generally pin our entire fleet against whatever we want -- until we can't. One particular (very large, very important) dependency currently requires CentOS 6.5. Go figure.

As much as possible, I want to treat infrastructure as a commodity, so catering to specific versions (even LTR versions) breaks that goal. As another reply notes, if we lock in at Ubuntu 12.04 and it's predictable, that's excellent.

As another mentions, Upstart was easy to get a handle of quickly. As an aside, it bugs me that the (otherwise excellent and detailed) Upstart docs don't seem to mention that all of Upstart is now deprecated. Hence the original confusion! In general I don't want flexibility (not first and foremost), I want simple and consistent.

Re: Runit – a Unix init scheme with service supervision

#45

Post by Spiritus »

kragen wrote: post #42

I use runit. It's great. (Daemontools didn't have the ability to sleep for 30 seconds after my daemons crashed at startup because, like, some filesystem wasn't mounted or something.)

How did you manage that? We currently have a problem with crashing services using up all system resources trying to constantly restart. Or better yet, exponential backoff.

Re: Runit – a Unix init scheme with service supervision

#46

Post by JoshTriplett »

clebio wrote: post #44
JoshTriplett wrote: post #9

Earlier quoted context omitted.

Depends heavily on what you need to provision, and whether you can select your provisioned environment based on what you want to support. Upstart is, at this point, effectively dead for any future distribution. However, if you want to support existing Ubuntu LTS distributions for the remainder of their lifetime, you'll need to handle it. Similarly, if you want to support the current rounds of enterprise distributions…

I appreciate the detailed reply, and the others as well. To address your questions and some of the others: We can generally pin our entire fleet against whatever we want -- until we can't. One particular (very large, very important) dependency currently requires CentOS 6.5. Go figure. As much as possible, I want to treat infrastructure as a commodity, so catering to specific versions (even LTR versions) breaks that g…

> One particular (very large, very important) dependency currently requires CentOS 6.5.

What dependency is that? And can you run it in a single-purpose virtual machine, rather than directly on real hardware, to make it easier to manage?

> As much as possible, I want to treat infrastructure as a commodity, so catering to specific versions (even LTR versions) breaks that goal. As another reply notes, if we lock in at Ubuntu 12.04 and it's predictable, that's excellent.

You definitely don't want to cater to specific versions any more than you have to; ideally you want as few versions across your entire fleet as you can. If you could get it down to just CentOS and the latest version of some up-to-date distribution, that would help; if you could make CentOS a virtual machine under that same up-to-date distribution, that's even better, insofar as you can then manage all the physical machines identically.

> As another mentions, Upstart was easy to get a handle of quickly. As an aside, it bugs me that the (otherwise excellent and detailed) Upstart docs don't seem to mention that all of Upstart is now deprecated. Hence the original confusion!

The Upstart docs aren't going to say that Upstart is deprecated. It's more a view of the Linux distribution ecosystem as a whole: the one distribution that primarily drove upstart usage and adoption is switching to systemd, so there won't be further momentum or resources behind upstart in the future. That doesn't make it instantly obsolete, but it does mean that starting a new project today around upstart is a bad idea.

(In fairness, there's one other notable distribution using upstart as well, namely Chrome OS; however, that's a bit of a special case in several ways, and in any case I hope to change that in the future.)

Re: Runit – a Unix init scheme with service supervision

#47

Post by cathexis »

dkubb wrote: post #37
edwintorok wrote: post #19

There is a good comparison/documentation of what an init system like runit should do and why on the S6 site: http://skarnet.org/software/s6/why.html http://skarnet.org/software/s6/overview.html Runit has the advantage that it is packaged in Debian and you can start using it right away.

Do you have any experience with S6? Do you know how it compares to runit?

I've used s6 a lot, though not as an init replacement in any systems that matter. As a supervisor I think it's great. For basic stuff (root process supervising supervisors supervising daemons) the two are basically identical with some superficial differences. For wider ranging stuff s6 is really good since it has a bunch of ancillary programs that solve a lot of serious issues in full system supervision (readyness notification vs polling in a run script, ucspi socket handing, etc).

Re: Runit – a Unix init scheme with service supervision

#48

Post by ploxiln »

Spiritus wrote: post #45
kragen wrote: post #42

I use runit. It's great. (Daemontools didn't have the ability to sleep for 30 seconds after my daemons crashed at startup because, like, some filesystem wasn't mounted or something.)

How did you manage that? We currently have a problem with crashing services using up all system resources trying to constantly restart. Or better yet, exponential backoff.

In the recent past I worked at a place that used daemontools extensively. We used a wrapper shell script which would do the restart loop detection, then exec the actual process to run. If it detected X restarts in Y seconds (by echoing the unix timestamp to a restart log and checking it) it would "svc -d $(dirname $0)" (or something like that) and exit.

We also had a monitoring service (nagios) that would check if any services "auto-downed" on any servers and alert us.

Re: Runit – a Unix init scheme with service supervision

#49

Post by not_with_retard »

clebio wrote: post #5

Given the other glowing comments, maybe this would be a place to ask: should I bother with Upstart, or Systemd? I see Shuttleworth announced the move to systemd, but it's not available on Ubuntu 14.04 servers right now. I'm writing provisioning for our production fleet, what should I use? The vagaries of the OS wars make something like Runit tempting.

The creator of Upstart said he fucked up on the design, and to use systemd, so... yeah.

Re: Runit – a Unix init scheme with service supervision

#50

Post by not_with_retard »

icebraining wrote: post #21
clebio wrote: post #5

Given the other glowing comments, maybe this would be a place to ask: should I bother with Upstart, or Systemd? I see Shuttleworth announced the move to systemd, but it's not available on Ubuntu 14.04 servers right now. I'm writing provisioning for our production fleet, what should I use? The vagaries of the OS wars make something like Runit tempting.

Unless you have particular needs, I'd say go with Upstart. You can learn how to write a service config file in half an hour, and in our experience (running a dozen Ubuntu 12.04 for three years), it's been very stable.

Upstart is dead since the creator said he fucked up on the design, and to use systemd.
Post reply on HN