[systemd-devel] systemd and cgroups

[Dominique Michel]

Le Mon, 13 Jan 2014 19:39:57 +0000,
Colin Guthrie <gmane at colin.guthr.ie> a écrit :

> Hello,
> 
> You're approaching this whole thread from a fixed position and
> therefore seem to be seeing *everything* as negative and
> problematic.

Hi,

You are partly right on this. In the mean time, I read other things on
the cgroups and systemd, and I know realize that things are not as bad
I was thinking. I also realize you are working hard to find solutions
to many problems.

> 
> Rather than coming here with problem and looking for a solution,
> you've arrived with a solution already designed and seem to be
> complaining that it won't work.
> 
> There WILL be a solution to your *problem* but it might not be
> achieved via the design you have in mind.
> 
> It could be due to the semantics of how you express the requirement
> means you have to think about the problem differently.

I now understand that. But it was not obvious at all at the time I was
fighting with a randomly freezing system. And nobody at that time was
able to point me on the right direction.

So I must thank the peoples on that list for that.

> 
> Much of what you say below is simply incompatible with the upstream
> kernel single-cgroup manager model that is being pushed. You cannot
> have a "custom cgroup configuration" directly under this model: the
> configuration has to be expressed indirectly as user and administrator
> friendly declarative statements in various unit files which ultimately
> map to cgroup configurations (mostly as an implementation detail).

As a user and administrator, I don't care as long I can make it to suit
my needs.

> 
> 
> > Too late, I shifted the distribution because I was in urgent need
> > of a good working system on that box.
> 
> Well, this has obviously given everyone the time to properly respond
> and help you with your problem. If I didn't know better this whole
> conversation would appear to be just a random complaint FUD email
> rather than one seeking to gain knowledge.

Before I shifted the distribution, I really try hard to make it to work
with systemd, that under a few weeks. That imply this is not a random
complain. But you are right on one thing, as I understand that issue
now, I was not following the right path and I should have contacted
that list at that time.

> 
> >>> Again, the point of the cgroups is to be able to adapt the system
> >>> to any kind of workload, and to have systemd that take control of
> >>> that good and flexible system, and at the same time, doesn't
> >>> provide a way for an user to adapt the default configuration to
> >>> its own need, is just a big design bug, which start with Lennart
> >>> failure to take in account the fact that all users are corner
> >>> cases by definition, because all users are doing different kind
> >>> of works with their computers.
> >>
> >> That's not the goak of cgroups at all, sorry.
> > 
> > Lennart is very clear in his email, "normal" users run a GUI. 
> 
> That is completely untrue. You have read far too much into that
> statement and the examples provided there. Let Lennart answer for
> himself before you make rash generalisations.

Maybe I over reacted, but it is what inspire me the lecture of that
message.

> 
> > So sure, according to that mail, the goal of the crgoup interface of
> > systemd is just to run a GUI
> 
> Completely untrue and certainly not how I read the email.
> 
> > And yes, as I want (my choice) a GUI that is not in my way, I am
> > allergic to a GUI that interfere with a good working system (like
> > gnome and its *kit madness), but that's another issue.
> 
> Yes, it's another issue and one *completely* irrelevant to this
> mailing list. Such negativity in comments is *highly unwelcome* here.
> Please keep it to yourself or for slashdot posts.

Come on, I don't post to slahdot, I just have better things to do.
If I am here, this is because I think it is a problem with the actual
state of systemd, and I also think users must be aware of it if they
want to avoid issues like freezing computers during a migration to
systemd. I was maybe over reacting on a few things, inclusive on
Lennart statement and systemd usability, and I apologize for that, but
the complete and repetitive system freeze I get was 100% real.

> 
> > The fact is that nobody on the Debian forum was able to help me, or
> > even aware of the existence of that documentation. Or they all was
> > in holiday at that time.
> 
> Quite possibly. Complaining that nobody held your hand here is
> somewhat off topic however. It doesn't change the fact that the
> documentation for systemd is extremely extensive and one of the best
> documented open source projects I've ever worked with.

It may be. But it is something new, something that, as my little
experience with it showed me, nobody outside of a little community seam
to know and understand.

> 
> > Anyway, I did read it but was completely unable to make it to work,
> > whatever I try. It is only when I read Lennart email yesterday, I
> > understand why it was not working: systemd is designed to not work
> > with custom cgroup configurations.
> 
> No, systemd is designed to *manage* your custom cgroup configurations.
> It abstracts cgroups away to pretty much an implementation detail. You
> can still get the needed *solution* to your problem.

Nice to hear that.

> 
> > And if it is already stated in the doc that systemd will not work
> > with custom cgroup configurations, you must emphasis more on that
> > issue, so that worried users doesn't miss it, and doesn't waste
> > their time with this.
> 
> Keep in mind that the single-writer principle is still relatively new.
> Everything has to be adapted to it and systemd has moved very quickly
> to match the upstream kernel needs. As time goes on, documentation in
> this area will improve.

What I thing now you must write in the doc, is that for users having an
existing cgroup configuration, they must just forget about it and make
a new configuration from the scratch. If it is already stated, I missed
it and must give you an apologize.

> 
> >>> So, don't say me I could have done this or that, that's not my
> >>> point. My major point is GNU/Linux have always been about choices,
> >>
> >> That's not true at all, it's never been about choices.
> > 
> > Well, you don't need to say anything more, we just don't have the
> > same conception of Free Software. For me, Free Software is about 5
> > fundamental liberties, and liberty is all about choices.
> 
> Your "choice" exists in your ability to view, understand and write the
> code yourself. Whether someone's crazy whim or configuration (not
> necessarily referring to your current requirement) has to be supported
> by every utility in the open source stack is completely different.
> People hear the word "choice" and build up a whole expectation around
> it's dictionary definition to the extent that they presume everyone
> must bend over backwards to support any crazy idea they come up with.
> I'm sorry, but this has never and will never be true.
> 
> http://islinuxaboutchoice.com/

I understand that upstream choices can impact users. It arrived with
one of the software I contribute to, and I get very harsh comment from
one user. After a few emails, her problem was solved and she was happy
again.

> 
> >> If you wish to use your own cgroup configurations, yes, I would
> >> suggest not using systemd.
> > 
> > It is what I have done after formatting and checking my drive. And
> > that's the real problem, systemd is not compatible with custom
> > cgroup configuration. I hope this will change in the future,
> > because this is a choice (again!) I made to use a custom cgroup
> > configuration. And I am sure I am not the only one into a similar
> > case.
> > 
> > As an alternative, systemd should at least provide a setup option
> > for it to not interfere with an existing cgroup configuration.
> 
> This is impossible. The kernel is moving to a single cgroup writer
> and systemd makes extensive use of cgroups internally. Such a setup
> option would be orthogonal to both the kernel and systemd itself.

As I understand it, systemd will rely on the kernel cgroup support to
enable it or not into systemd. So it must be possible to make an
option to disable the cgroups inside systemd even when the kernel
support them. Or I am wrong and systemd will not work without the
kernel cgroups?

> >>  But please work with the kernel cgroup
> >> developers, as the cgroup interface is going to be changing quite a
> >> bit in the future.
> > 
> > OK, I will do it.
> 
> I'm sure if you do, you'll realise that you simply won't be able to
> keep your current solution as is defined now. You will have to adapt
> to getting the same end result via a different path in the end.

I already understand that.

> 
> Good luck with it, but please try to keep an open mind and try not to
> phrase things with an "I've already decided that I'm right and
> everyone else is wrong" kind of attitude. It does not make people
> want to offer advice or reply and you'll ultimately get a negative
> experience. It's a self fulfilling prophesy. If you start off with a
> negative attitude you'll ultimately come away with a negative
> experience. If you come in with an open mind and ask open questions,
> you'll likely find a very engaging and useful discussion forms as a
> result.

I always follow my feelings, and I get a real bad feeling when reading
Lennart message. And maybe I over reacted. But if I took the time to
subscribe to that list and to talk about that, this is because I think
the cgroups are one of the best thing that happened to the kernel from
a very long time. And I care about them.

Dominique

> 
> Col
> 
>