Hello, everyone.

I am a bit confused about how cgroups are configured in Slackware.

In rc.S, there are two places where things are done with cgroups:

/etc/rc.d/rc.S
**** Mounts the v1 controllers at lines 51-74
**** Starts cgmanager/cgproxy at lines 375-378
**** Starts libcgroup services at lines 380-384

libcgroup's /etc/cgconfig.conf file permits a mount{ } option, which allows to specify mounts in the config file and manipulate them in runtime (more or less ;-)).

What is the purpose of the lines 51-74 then?

So far I have only found that manual part can parse /proc/cgroups , but those are only v1 controllers, so I'd still think that using the libcgroup interface would be more flexible (and liberating for the main initialization script).

So why does rc.S have to mount cgroups manually?

My take on this is that cgmanager is obsolete. I have already stated that two years ago:
https://www.linuxquestions.org/quest...ml#post5704374
https://www.linuxquestions.org/questions/slackware-14/[request-for-comments]-do-we-still-need-cgmanager-4175599676/

Just my opinion, of course.

An experienced opinion is a useful thing.

Libcg didn't have updates since 2014, and neither of them seem to support cgroups v2.

My thinking sketch is here: https://gitlab.com/Lockywolf/linuxbu...ups-manual.txt

If you have suggestions, those are most welcome.

1 members found this post helpful.

I use this one as per dockerd requirements.

don't know why i should use it

1 members found this post helpful.

I think this is a good question.

I mean, there is plenty literature regarding how cgroups help managing resources between competing containers. But why are all these cgroup controllers mounted by default in Slackware, in rc.S?

Couldn't they be mounted in some rc.d/rc.cgroup script that could be set executable, like other rc scripts, by people actually using them?

Or are they actually always used by default, (independently of any container) by something I don't know?

If you read the document I posted a link to, you may find some more usages for them, besides containers.

But I don't think they are used by anything in a fresh Slackware installation.

Personally, I don't like the idea of splitting more stuff out of rc.S.

There are already examples like rc.loop whose existence is IMO completely unnecessary. Separate rc.* for daemons (services) that need to be stopped/started by admins is perfectly reasonable, but I'm not a fan of splitting out other stuff. I'd much rather see a rc.conf/rc.conf.local mechanism added in order to allow people to configure the behaviour of the main rc scripts without having to hack on them.

I read your 'Reading-cgroups-manual' document. Very insightful.

Yes, this was my core question. I wonder if they are used by some "desktop" stuff I don't know and don't use (polkit, consolekit, others?) -- maybe like you suggest in your document?

Agreed. My main point wasn't to specifically put the cgroup controllers mounting stuff in a rc.d script and only there.

I see in rc.S many optional functions started only some /etc file is there (eg. LVM), or if some rc.d script is executable (eg. FUSE). I was wondering if mounting cgroups controllers was optional or not.

In case it is optional, I think it could be controlled in a similar way (could be an executable rc.d script, some /etc conf file, or as you suggest, in a global rc.conf file.

I hope people routinely using cgroups will contribute to the thread and just tell us what they use them for.

We have a small problem with libcgroups.

In Slackware's rc.cgconfig, line 106 says:
Where $CONFIG_FILE is /etc/cgconfig.conf

While, indeed /etc/cgconfig.conf should be loaded by default, as the man page says, there is another default source of configuration which needs to be loaded:

The man pages 'man cgconfigparser' and 'man cgconfig.conf' say it like this:


It would be nice to add this option to -current.

Patch:

1 members found this post helpful.