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.
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.
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
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).
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.
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.
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...
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
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.
Also a lot of enterprise shops use daemontools and runit, because they just fucking scale.