On Fri, 16 Jan 2015 14:12:07 +0100 Laurent Bercot <[email protected]> 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 [email protected]. 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
