> on a factual level we have ridiculous bugs specifically caused by systemd that take down your system, and the lead developers saying either i don't care or it's by design.

Agreed. This is a big worry. When the lead developers of something this important sound this callous, I start getting concerned.

runit (from daemontools) might not start things up in parallel, but it's a whole lot simpler and reliable. Phusion uses it instead of upstart in their base docker VM.

Also a lot of enterprise shops use daemontools and runit, because they just fucking scale.

I'm from Phusion.

Runit is great as a tool to manage your own daemons. But as a general init system for distributions? Not so much. Just take a look at the /sbin/my_init system that we wrote for baseimage-docker and what kind of functionality it adds on top of Runit, to give you an idea of why Runit by itself is not enough. Runit also performs no dependency management (i.e. starting one service before another) so it's quite painful in certain situations. For example, if you have a background queue daemon that depends on PostgreSQL, then you have to manually make sure that the daemon is not started until PostgreSQL is available. Otherwise you get tons of useless error messages as your daemon keeps getting restarted.

No problem, just wrote a tool for that:

    waitport [-u] port [timeout (float)] # -u = UDP instead of TCP


    go get   github.com/steakknife/my_init/waitport
    go build github.com/steakknife/my_init/waitport
    # creates waitport bin here

Renamed to https://github.com/steakknife/devops_toolchain to avoid confusion.

A collection of individual tools that can be cherry-picked to solve nitty-gritty problems.

I concur, runit absolutely rocks. Haven't tried systemd yet, I wonder if the two play nice together (if they don't, it won't be runits' fault, that's for sure).

Might try the old-school daemontools, even though the commands are a bit different, it might be less work to get something going.

From your other comments I can tell you're a seasoned daemontools user, so let me just put in a quick plug for daemontools-encore [1]. Like runit, daemontools-encore can now run services in separate process groups with setsid(1). Why is this so darn important? Well, under classic daemontools a ./run file with a pipeline in it -- or really anything that forked -- would spin off orphans every time you did `svc -t|-k`. Very bad stuff to deal with in a production environment.

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

Yup, it's one of those annoying things that makes run scripts more complicated. I rewrote phusion's runit setuser helper in Go because it didn't set all the right env vars.

https://raw.githubusercontent.com/steakknife/my_init/master/...

Huh, looks pretty similar to envuidgid(8) from daemontools. [1]

Another plug for daemontools-encore (last one I promise). The setuidgid(8) program in classic daemontools doesn't set supplementary groups, and a lot of people I know just end up just using sudo in their run files. If you use daemontools-encore though, you can just use `setuidgid -s` instead.

PS. Really, daemontools-encore should imo be called daemontools 1.x, but you know how djb feels about forks of his projects...

[1] http://cr.yp.to/daemontools/envuidgid.html

The problem as per the Phusion blog article is that the runit and possibly daemontools equivalent commands don't set all env vars: HOME, USER, GID & UID, it only calls setgid() & setuid() IIRC. (envuidgid only sets UID and GID[0]) This causes breakage for lots of apps that end up inheriting root's env instead. :(

Here's the go version I wrote, so there's no need for dep on Python/Ruby/etc on the target system:

    setuser USERNAME COMMAND [args...]

    # how to build it
    go get   github.com/steakknife/my_init/setuser
    go build github.com/steakknife/my_init/setuser
    # creates setuser exe here

[0] FR issue submitted as https://github.com/bruceg/daemontools-encore/issues/18

Maintainers either will or won't accept that forks are the sincerest form of flattery.

> base docker VM

you serious? criticizing systemd by promoting a totally new and un-tested software written by a single (for-profit) company.

> Also a lot of enterprise shops use daemontools and runit

provably not true. most enterprise shops run RHEL/CentOS which, to keep support contracts, runs sysvinit or in RHEL/CentOS 6.x ran Upstart. RHEL/CentOS 7 uses systemd and is not going to look back. Don't forget, the "serious" distros have used sysvinit for a very long time. Then they tried out Canonical's Upstart for a bit and decided it was not a step forward, but rather a step to the side. Now they have landed on systemd for very good reasons.

No, sorry, but you don't know what you're talking about.

daemontools is battled tested. We used it at Stanford on thousands of boxes. I used at a lot of shops, one in SF for example had 40k boxes (CentOS) and 6 ops staff, deployed via CFEngine. Heroku uses daemontools. On and on. Daemontools is mostly used when there is no desire/time to replace the existing init completely.

runit also scales amazingly well, even though it's more work to deploy.

Upstart is too unpredictable (flapping) and sysvinit doesn't do supervising very well, which is why important services are deployed with daemontools/runit.

> solves some of the issues openrc and systemd solve, but without systemd's baggage.

I thought OpenRC was that init system? Or what systemd baggage comes with it?

OpenRC is better than sysvinit, but still isn't the best. However in terms of technology, systemd is the best init system available. The main problems are the developer attitudes and architectural decisions they've made (big blob, work with me or nothing).

Openrc does not provide a pid 1 init implementation. On most openrc systems sysvinit launces openrc to handle service startup.