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.)
--
Laurent
Received on Fri Jan 16 2015 - 13:12:07 UTC