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

21–30 of 69 posts

Re: Runit – a Unix init scheme with service supervision

#21

Post by icebraining »

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.

Re: Runit – a Unix init scheme with service supervision

#22

Post by icebraining »

vezzy-fnord wrote: post #12
bitwize wrote: post #7

Earlier quoted context omitted.

Many people still think that it's a 3-way horse race between sysvinit, Upstart, and systemd (which systemd has all but won). The Debian technical committee certainly acted like that was the case last year.

A lot of people further neglect all the prior art in init replacements before those. The simpleinit dependency mechanism, depinit, initng, minit, daemond, Seth Nickell's GNOME experiments, eINIT, cinit and so forth. Instead, the way it was presented in public is that the Linux distros had been battling with brittle sysvinit scripts (true, but also largely self-inflicted) for so long until systemd came in to heroicall…

What apathy? Ubuntu and Fedora had already switched to Upstart, and Gentoo to OpenRC, due to the problems identified with sysvinit.

Re: Runit – a Unix init scheme with service supervision

#23

Post by vezzy-fnord »

icebraining wrote: post #22
vezzy-fnord wrote: post #12

Earlier quoted context omitted.

A lot of people further neglect all the prior art in init replacements before those. The simpleinit dependency mechanism, depinit, initng, minit, daemond, Seth Nickell's GNOME experiments, eINIT, cinit and so forth. Instead, the way it was presented in public is that the Linux distros had been battling with brittle sysvinit scripts (true, but also largely self-inflicted) for so long until systemd came in to heroicall…

What apathy? Ubuntu and Fedora had already switched to Upstart, and Gentoo to OpenRC, due to the problems identified with sysvinit.

OpenRC isn't an init daemon. It's only a process management framework, hence the name. It's usually used in conjunction with sysvinit as PID1. OpenRC was originally motivated by replacing the older baselayout scripts, from what I recall.

Upstart didn't come about until later from many of the alternatives I listed, and its origins were mostly in response to launchd. It was quite rudimentary initially. [1]

[1] https://wiki.ubuntu.com/ReplacementInit

Re: Runit – a Unix init scheme with service supervision

#24

Post by stephen-mw »

Runit is the default system daemon for Phusion's baseimage-docker Ubuntu image[0]. I've used it in a basic manner and have been very happy with it.

For containers it hits a real sweet spot: lightweight and easy to use within a limited scope of processes.

[0] https://github.com/phusion/baseimage-docker

Re: Runit – a Unix init scheme with service supervision

#25

Post by icebraining »

vezzy-fnord wrote: post #23
icebraining wrote: post #22

Earlier quoted context omitted.

What apathy? Ubuntu and Fedora had already switched to Upstart, and Gentoo to OpenRC, due to the problems identified with sysvinit.

OpenRC isn't an init daemon. It's only a process management framework, hence the name. It's usually used in conjunction with sysvinit as PID1. OpenRC was originally motivated by replacing the older baselayout scripts, from what I recall. Upstart didn't come about until later from many of the alternatives I listed, and its origins were mostly in response to launchd. It was quite rudimentary initially. [1] [1] https://…

I never said or meant that Upstart wasn't younger than those alternatives. What I disagree with was the idea that there was much apathy and then a sudden crisis when systemd appeared. The development and adoption of Upstart and OpenRC (even if the latter isn't an init daemon, it's still an alternative to the init system) by some of the biggest distros contradicts that claim.

Re: Runit – a Unix init scheme with service supervision

#26

Post by ori_b »

dap wrote: post #17
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.

> Not only is it simple and does the do-the-one-thing-well thing well, which is true, it's also _correct_. How does it address the "who-watches-the-watcher" problem typically associated with service restarting?

Make it simple and obviously correct, and don't crash.

Re: Runit – a Unix init scheme with service supervision

#27

Post by lisivka »

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.

Use CentOS7 with systemd. I have much less problems and annoyances with CentOS on my own servers. They are _small_ (large problems are always addressed fast) but their number is huge. I know solution for every problem I face on Ubuntu, because I started to use Linux in 1998, but they are already _fixed_ in CentOS. Working on Ubuntu I feel like I returned back in time for few years.

Re: Runit – a Unix init scheme with service supervision

#28

Post by dap »

ori_b wrote: post #26
dap wrote: post #17

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_. How does it address the "who-watches-the-watcher" problem typically associated with service restarting?

Make it simple and obviously correct, and don't crash.

Just don't make any mistakes? Was that a joke?

There are many reasons a process can die that are outside of its control, including signals from outside the process, handled (but uncorrectable) memory errors, and the OOM killer (on Linux). Besides that, it seems like a major design shortcoming if fatal errors in any particular program (however critical and however simple that program may be) can be unrecoverable for the whole system.

It's definitely possible to solve this problem rigorously and completely, though I don't know of a way to do it without support from the kernel. On illumos systems, the service restarter ("svc.startd") provides a complex restart policy for user-defined services. I believe the restarter itself is restarted blindly by init, and init is restarted blindly by the kernel. If the kernel dies, the whole system is rebooted. In this way, if any software component in the chain of restarters fails, the system still converges to the correct state.

Re: Runit – a Unix init scheme with service supervision

#29

Post by ori_b »

dap wrote: post #28
ori_b wrote: post #26

Earlier quoted context omitted.

Make it simple and obviously correct, and don't crash.

Just don't make any mistakes? Was that a joke? There are many reasons a process can die that are outside of its control, including signals from outside the process, handled (but uncorrectable) memory errors, and the OOM killer (on Linux). Besides that, it seems like a major design shortcoming if fatal errors in any particular program (however critical and however simple that program may be) can be unrecoverable for t…

What if init doesn't exit, and just hangs? What if it just goes crazy and starts erronously restarting your processes? There are more failure modes than simply crashing.

At some point, you just have to assume that some critical components are working correctly. Adding complexity just makes it harder to reason about it, or, depending on how paranoid you are, prove it.

Re: Runit – a Unix init scheme with service supervision

#30

Post by dap »

ori_b wrote: post #29
dap wrote: post #28

Earlier quoted context omitted.

Just don't make any mistakes? Was that a joke? There are many reasons a process can die that are outside of its control, including signals from outside the process, handled (but uncorrectable) memory errors, and the OOM killer (on Linux). Besides that, it seems like a major design shortcoming if fatal errors in any particular program (however critical and however simple that program may be) can be unrecoverable for t…

What if init doesn't exit, and just hangs? What if it just goes crazy and starts erronously restarting your processes? There are more failure modes than simply crashing. At some point, you just have to assume that some critical components are working correctly. Adding complexity just makes it harder to reason about it, or, depending on how paranoid you are, prove it.

That's a slippery slope argument: because we can't solve the halting problem or verify program correctness, we shouldn't try to handle crashes, either?

Agreed on minimizing complexity. The only part of the chain I described that's very complex is svc.startd, and that's largely to support rich configuration.

Also don't mistake my position for saying that quality isn't important. Rather, just that perfection is not a reasonable constraint.

Post reply on HN