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,
Hi Laurent,
First, thanks for answering me. This email was *precisely* the kind of
feedback I was looking for, and will result in changes to my document.
>
> 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.
:-)
I guess I *did* appear impartial. This is the first time in history
I've been accused of being pro-systemd. Please tell Don Armstrong ---
maybe he'll let me back on Debian-User (just kidding, I'm done with
that mailing list).
>
> 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.
I think I'll remove most of my Socket Activation verbiage and provide a
link to your
http://forums.gentoo.org/viewtopic-t-994548-postdays-0-postorder-asc-start-25.html#7581522
Socket Activation is waaaaaaay above my paygrade, and the less I say
about it, the smarter and more accurate I appear. Thanks for this.
>
>
> II. Event-based.
>
> I did not understand what you meant by that. Could you please
> clarify ?
Once again, this stuff is above my paygrade, but I was generally
looking for a solution to this (probably very rare) problem:
https://lists.debian.org/debian-devel/2012/02/msg01043.html
If kernel process timing is indeterminate, then, unless there are
sufficient sleeps or the run code (./check and the like) can detect a
functional kernel-spawned service, theoretically one would need to have
the kernel tell the init when a kernel-spawned process is up and
running.
Like I said, I've never had any of these problems, but people keep
asking me what my alternative to "event-based" would be.
>
>
> 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.
This is great information. Could you please tell me the two lines? I'll
include them in features_benefits.htm. Also, if these lines use
executables within the cgroup-bin package, I've found that package only
in Debian (Wheezy), so I'm not sure where these executables would be
obtained with other distros.
>
> 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.
Thanks for this succinct way of explaining the situation!
>
>
> 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.
I care, but there's no way I could reliably give a letter grade to the
various inits. We *all* know systemd is more complex than Epoch and the
daemontools type inits, but is Epoch simpler than runit? I don't know,
and I doubt I'd know even after a day of studying the source code of
both.
> 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.
<tinfoil_hat>I doubt quality, simplicity, or easy configurability is Red
Hat's goal. In fact, I think it's quite the opposite.</tinfoil_hat>
>
> I'll stop babbling for now. Feel free to reproduce all or part of
> this rant for technical or advocacy purposes.
Thank you!
> If you want to flame,
> praise, or argue with me, please do so privately, unless your
> argument is purely and highly technical.
Will do.
> 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.)
In my opinion, systemd is pure politics, created for nontechnical
reasons, using Lennart as a proxy. And just to make this clear, just
between you and me, I find systemd despicable.
Thanks for all this great information, Laurent. This is exactly what I
hoped to get when I posted yesterday.
Steve
Steve Litt *
http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
Received on Fri Jan 16 2015 - 15:29:06 UTC