Hi Laurent,
Thanks for this.
I would only add: it is *extremely* unfortunate that service
management frameworks have come to be so conflated with pid 1.
With the focus turned so exclusively on init, many people are losing
sight of the benefits of supervision in general, and portable,
cross-platform, init-agnostic service management in particular.
Wayne
http://b0llix.net/perp/
On Fri, 16 Jan 2015 14:12:07 +0100
Laurent Bercot <ska-supervision_at_skarnet.org> wrote:
> On 16/01/2015 01:05, Steve Litt wrote:
> > http://www.troubleshooters.com/linux/init/features_and_benefits.htm
>
> (I'm lacking sleep and I'm going to talk about systemd. Not a good
> combination. So, apologies in advance for the rant, for the inevitable
> coarse language, and for the very opinionated post.)
>
> Hi Steve,
>
> The main comment that I have to make after reading your document is
> that despite your attempt at impartiality, and avowed liking of
> daemontools- inspired schemes, it is still systemd-centric and biased
> in its favor. Not purposefully, of course, but simply because the
> systemd propaganda machine works, and has already taught you to think
> in systemd terms - which, let it be said openly, are often pure
> marketing bullshit.
>
> Let's dig into some of those.
>
>
> I. Socket activation.
>
> This has to be my new favorite marketing buzzword. Socket
> activation, people. (My sockets are activated. I put my feet into
> them, and now they move. It's awesome.)
> Last summer, I wrote a post about it - and you were in that
> discussion, Steve:
> http://forums.gentoo.org/viewtopic-t-994548-postdays-0-postorder-asc-start-25.html#7581522
>
> The short version of it is that "socket activation", as systemd
> defines it, is a hack that mixes several different already-existing
> concepts in a shaker, and what you get in the end is *worse* than if
> you had nothing at all - but since everything is mixed and confused,
> nobody notices, and systemd can pretend it's doing that wonderful
> thing that no other system does, and people believe it.
> When you think "socket activation", the questions to ask are the
> following. (I wrote answers from the s6 point of view, which mostly
> applies to other supervision suites too.)
>
> Q1. Does the init system work as a super-server pre-opening and
> binding sockets so that daemons do not have to do it themselves ?
>
> A1. It is NOT the freaking init system's job to pre-open sockets.
> Doing so requires the init system to be aware of every single
> socket-listening daemon on the machine, which translates into a
> central registry. And that is how you turn Unix into Microsoft
> Windows. If you need to pre-open and bind sockets all at once, use
> inetd. This is exactly what inetd does, and at least it doesn't
> require running as process 1, or communicating over D-Bus.
> Better, use decent superservers, such as s6-tcpserver or tcpsvd, one
> per service. For Unix domain sockets, which is what systemd focuses on
> (and rightly so), there's s6-ipcserver. Starting those superservers in
> parallel, as any supervision suite can, will end up being just as
> fast as trying to open every possible socket early on in process 1.
> There is no reason at all why a superserver should be tied to an init
> system.
>
> Q2. Does the init system allow you to start processes as soon as the
> sockets are open, before the servers are ready ? This is the much
> touted benefit of socket activation on
> http://0pointer.de/blog/projects/socket-activation.html
>
> A2. HELL NO. WHY ON EARTH WOULD I WANT THAT ?
> - Doing so has a serious reliability cost: if a service ends up
> having issues, but dependent services have been started and are
> assuming that it's working, hilarity will ensue. I mean, you could
> also play Dance Dance Revolution on a mat made of old WWII landmines.
> What could possibly go wrong ?
> - It's especially twisted with logging. Sure, start your daemons
> before the logger is running, no problem. That way, if anything goes
> wrong, you'll have no way of knowing what happened. Have fun
> debugging.
> - The speed benefits are minimal at best. As I wrote in my post,
> daemons can perform their first writes in parallel, but as soon as
> they have to read, they block anyway, waiting for their dependencies.
> The only case where daemons write and never read, and could benefit
> from such a scheme, is... when they write to their logger. And, as we
> just saw, it is a really good idea to write logs before the logger is
> guaranteed operational. This is just not worth it. Simply starting
> all the services as soon as possible in parallel will have the same
> benefits - the kernel will schedule everything to the best of its
> abilities, and there will be no risk of spectacular crashes.
>
> Q3. Does the init system allow you to hold a copy of a bound socket
> for the daemon to retrieve if it has to restart ?
>
> A3. This is what I call "fd-holding", and is the *only* thing of
> value in socket activation. No, supervision suites do not perform
> fd-holding - except, precisely, for communication between a daemon
> and its logger, which is arguably the most important fd to keep open,
> in order to avoid losing logs.
> And for the rest, it's a work in progress. I'm working on a
> fd-holding daemon. s6-ipcserver now supports getting its socket from
> another source (instead of binding it itself); so does s6-tcpserver.
> We will get there. But again, this has nothing to do with an init
> system. A fd-holding daemon can, and should, run as a separate
> service, maintained by the supervision suite, and providing
> fd-holding service to other services that require it; there is no
> reason why it should be tied to process 1. Sure, it could die; tough
> luck. Getting all important services into process 1 to protect them
> from dying isn't a solution: it only makes crashes more lethal.
>
>
> II. Event-based.
>
> I did not understand what you meant by that. Could you please
> clarify ?
>
>
> III. cgroups.
>
> The big fallacy here is that cgroups require specific support from
> the init system and that enabling cgroups is a great feature of
> systemd. It's not. Yet another systemd self-horn-tooting that's
> totally vapid when you dig into it.
> The thing is, supporting cgroups is only an achievement if you have
> a complex, monolithic init system. Or if you like writing parsers for
> configuration files.
> If you have a supervision tree rooted in process 1, supporting
> cgroups is trivial: it's a matter of adding 2 lines of shell at the
> beginning of the run scripts for the services you want to manage a
> cgroup for.
>
> Yes, it could be made easier. There could be a specific
> configuration tool to help people manage their run scripts, and their
> cgroups. I plan on writing one on the long term. That does not mean
> cgroups are not supported
> - on the contrary, having a supervision infrastructure makes using
> cgroups easy as pie, without any specific code for that in the init
> system. Compare to systemd, which has to have specific code for
> everything it does.
>
> (Mmm. Pie.)
>
> For s6 specifically, it was very much a design choice *not* to
> include anything for cgroups, since cgroups are Linux-only and s6
> aims to be portable to other OSes. I plan to write a Linux-specific
> s6-init package in the future, to take cgroups, and other things,
> into account - and also work on specific init documentation, which
> you found lacking because s6 is meant to be a supervision suite and a
> set of tools, not a complete init system - the integrated init system
> will follow at some point.
>
>
> IV. "OS Toolkit".
>
> Providing building blocks for an OS is a very laudable goal, and
> basically what all system software should do. But the terminology
> here is biased: talking about a "toolkit" implies certain notions.
> - A real toolkit provides tools. Independent tools. You can pick any
> hammer to hit the nails you take from your box. That is *not* what
> systemd does: systemd provides systemd-approved hammers to work on
> systemd-approved nails. Just like Apple, or Sony. systemd is as
> proprietary as open source can be, and people feel it and resent it.
> - A software toolkit is supposed to provide *mechanism*, not policy.
> Policy is not a toolkit, it's the recipe to build the house. And
> systemd wants to provide policy as well as mechanism. It is not the
> place of software to provide policy! It's a job for distributions.
> And people felt that really strongly: that is where the main dislike
> for systemd comes from. Captivity of the market, and policy: that is
> the core of the "OS toolkit" issue, and to understand it, I think it
> needs to be made clear that "OS toolkit" is nothing more than a
> propaganda word, and entirely the wrong denomination for systemd.
>
>
> V. Complexity is a cost.
>
> That's something that does not appear in your table, and it's very
> understandable: as a user, you do not see code complexity, and you do
> not care: the stuff just has to work and that's all that's important.
> However, any half-witted engineer (read: not Lennart) knows that the
> more complex a project is, the harder it is to maintain and evolve,
> and QA becomes more expensive. systemd, like gcc, like GNOME, like
> Windows, like SAP, like every complex project that has a lot of users
> and that just has to work, can survive because it has manpower - a lot
> of man-hours are poured into it, just to make sure it works, and
> despite all those resources, sometimes there are still little bumps
> on the road. To me, this is a terrible waste. It's not even that
> complexity has a cost - that's obvious. It's that complexity *is* a
> cost.
>
> runit, s6, perp, nosh: they each have been designed and written by
> *one man*. Even uselessd is the work of one man, or a very small team.
> The complexity of those systems is manageable by one. single. person.
> Any engineer (Sorry. Any half-witted engineer.) can dive into them and
> understand them fully, and keep them alive if the original authors
> disappear. Projects work best at that scale, or at a wee bit higher
> scale: in open source software, small teams are much more efficient
> than large teams.
>
> That counts. Time spent on understanding and evolving the init
> system is time not spent on doing more interesting stuff. If Red Hat
> ditched systemd and put a single dude (or two, for peer review. I'll
> take the job if the other guy is Gerrit or Wayne, or even Jonathan,
> that C++ heathen. You can write me at ska-jobs_at_skarnet.org. Thanks,
> Red Hat.) on the init system, all the manpower could be shifted to
> something productive.
> ... maybe. That's Red Hat we're talking about.
>
> I'll stop babbling for now. Feel free to reproduce all or part of
> this rant for technical or advocacy purposes. If you want to flame,
> praise, or argue with me, please do so privately, unless your
> argument is purely and highly technical. I had to trespass a bit into
> the political because politics and communication are weapons of the
> systemd proponents and need to be recognized as such; I apologize for
> straying.)
>
Received on Fri Jan 16 2015 - 16:01:55 UTC