Comment by rjzzleep | Hacker News Reader

Comment by rjzzleep | Hacker News Reader

Parent Full thread

I don't see a boycott happening. Not unless someone steps in to write an alternative init system, which solves some of the issues openrc and systemd solve, but without systemd's baggage.

taking the discussion out of the opinion level to a more factual level(eg. i like the boot speed of my archlinux machine but the whole consolekit(why did we get that to begin with ?)/logind/ridiculousness, logging and service files vs. startx and grep /var/log is annoying to say the least, but as i said subjective)

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. let me bring a few examples:

https://bugs.freedesktop.org/show_bug.cgi?id=76935

> That is the expected current behaviour, "debug" can cause "too many" messages to be useful anymore if things are broken.

or this one, systemd segfaulting with cgroups off:

https://bugs.freedesktop.org/show_bug.cgi?id=74589

Lennart:

> To make this work we'd need a patch, as nobody of us tests this.

There were a few other recent ones. When your new init system consistently takes down your operating syste, because of stupid bugs, and the lead developers say we don't care, and even block efforts to fix these issues, you should indeed worry.

https://plus.google.com/111049168280159033135/posts/Kd57G8s1...

In fact Greg KH jumped in to play daddy, and wrote a patch where tom gunderson commented that that patch would not be merged as it's not clear what problem it solves.

edit: some say openrc is the one. here's a comparison:

https://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems

> 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 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

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

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

> 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.

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.

> 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.

Reply on news.ycombinator.com