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-j...@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.) -- Laurent