[systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Lennart Poettering]

On Tue, 21.10.14 11:08, Martin Steigerwald (Martin at lichtvoll.de) wrote:

> > systemd as init", but "logind has to depend on the system having cgroup
> > support, and there's no equally good cgroup support available for inits
> > other than systemd". It is possible to provide the relevant cgroup
> > interfaces in or on top of another init, as the systemd-sysv + cgmanager
> > combination attempts to do. But it is not trivial to do, as bugs and
> > implementation delays with that combo have shown, and it's quite likely
> > that there will be more problems in the future. It's not a particularly
> > good idea to use the less-tested and less-reliable systemd-shim instead
> > of the more reliable systemd. Thus the overall result is that yes, it
> > does make sense to switch machines to systemd when you add certain
> > functionality, even if that functionality does not appear to be directly
> > tied to the init system at first glance.
> 
> I can´t point my finger at it why… but I really feel uncomfortable with this 
> tight coupling. I think that the systemd-shim + cgmanager combination may have 
> bugs does not *prove* that such a think isn´t workable.

Well, you can do tons of things, that simple fact doesn't really make
all of them a good idea.

PID1 is supposed to start and maintain services. In our eyes this is
best done with cgroups, because that allows us to keep track of the
service processes, label them, list them, kill them, get notifications
about them. All this functionality is implicitly done by the kernel
for us, we just need to make use of it, with a few mkdir()s and
open()+write()s, awesome! That's why we use it.

Now, of course you can split that out in multiple daemons, but then
you have to do IPC between these daemons. That's already bad enough,
for complexity and stability reasons. However, what's worse is that it
creates a chicken and egg problem: if PID forks of a service like
cgmanager in order to *manage* a service like cgmanager, then you have
a cyclic dependency. You can of course hackishly work around this, but
this would mean to exclude cgmanager from service supervision. And
moreover: for what even? For executing a few mkdir()s and write()s
out-of-process? Really?

Hence: while these things are certainly possible I am strongly of the
opinion that they would be a systematically bad design, and we will
hence not do such a fuckup in systemd. Sorry.

> But due to the design choice of you systemd developers to have it all in one 
> people who do believe that separating different functionality is for the long 
> term benefit of interoperability and avoiding what I´d call vendor lock in, 
> although I clearly see that systemd upstream community isn´t a single vendor 
> as in one company who produces a comercial product.

We are open source. There is no such thing as vendor lockin. You are
just fudding around now. I really don't appreciate what you are
writing here.

This has been discussed a million times before. If you want to discuss
this again then find another forum.

> In other areas where the Linux kernel requires user space helpers things 
> initially have been separated. The whole do it all in once hald daemon was 
> split into udev, libudev, udisks and upower… yet now, systemd and udev is in 
> one upstream again.

I think you misunderstand the history of hal really.

> What speaks against putting the cgroup functionality and other stuff from 
> systemd into shared libraries with clearly defined APIs – which are documented 
> and where the documentation is the reference, not the source code – and 
> allowing it to be used elsewhere?

See above.

Our APIs are actually pretty well documented, in documentation, not
source code. You seem to imply otherwise. What do you want more
documentation for? Can you be more explicit please?

> Then systemd may use it as PID 1, but if someother wants to use it in own 
> project, can use it as well. I consider cgroups as part of the kernel API and 
> I highly dislike the battle on which of the available solutions will get 
> control over it. Actually I still think the API is broke if it cannot allow 
> for mutiple processes accessing it. I don´t know an easy way to fix it, but I 
> think such a kind of API as kernel interface… anyone can read a file, mount a 
> filesystem, open a network socket, set a nice value depending on permissions 
> but when it comes to control groups it is down to "one to rule them all". I 
> can´t help it, but this just seems utterly broke to me.

Well, if you think the cgroup interface is broken, please bring this
up with the kernel folks not us.

> I can´t help it but I don´t consider this to be a sane operating
> system API.

Maybe instead of criticising the kernel folks and us for technical
choices you should really get your hands dirty and try to make it
better?

> > The issue with "I should be able to stay with sysvinit because it worked
> > fine for me" is that keeping sysvinit working is COSTLY. The reason
> > sysvinit used to mostly work was not that it would have been a reliable
> > system - it mostly worked because people kept using a lot of effort to
> > work around and paper over various issues that kept popping up. And
> > there's no justification to keep up that effort for the minority who
> > wants to stay with sysvinit. So, you can keep running your old systems
> > unchanged if you want, but you shouldn't expect to be able to upgrade
> > them or install new software without switching to systemd.
> 
> What you write here basically comes down to a forced adoption. At least this 
> is how I receive what you write.

Forced??? 

We don't force anyone. The technical committees of the various distros
make their choices. If they don't like systemd, then they don't like
it. If they do, they do. We can live with either. But I really don't
see how we as upstream would "force" anything.

How could it even be "forcing"? We provide you something for
free. Take it or leave it. How can you be so impolite to call
something "forcing" if you get it as an optional offer, for free? I
mean, if anything you should be thankful for our work or at least
ignore it, but not be a dick about it.

Lennart

-- 
Lennart Poettering, Red Hat