[Request for comments] do we still need cgmanager?

Didier Spaier · 02-13-2017, 02:14 PM

Currently a cgmanager daemon is started by default in Slackware 14.2, as /etc/rc.d/rc.cgmanager and /etc/rc.cgproxy are executable by default in Slackware 14.2.

Wondering if that was really necessary, I noticed that not having them executable does not prevent ConsoleKit2 to work.

So if if am correct we do not need these daemons running by default. Do I miss something?

Let's go one step further: do we really need cgmanager? This question needs to be addressed for future Slackware releases, as in https://linuxcontainers.org/ I read this:

Quote:

It has now been deprecated in favor of the CGroup namespace in recent Linux kernels. On older kernels, LXCFS still offers a cgroupfs emulation that can be used instead of cgmanager and is more widely compatible with existing userspace.

so it is doubtful that cgamanager will continue to be maintained.

Actually, as far as I know none of the features of cgmanager or its associated command line tool cgm are unique: all are provided in other ways by stuff provided in the libcgroup package (a few examples on ArchWiki)

Also, even though cgmanager be a recommended dependency of ConsoleKit2, I have rebuilt it after having removed cgmanager and it works as usual: for instance the Python script wm-logout (attached), still allows to graphically reboot or halt as a regular user. This is not surprising as we see this comment in ck-process-group.c in the ConsoleKit2 source:

Code:

/* Note to porters, on Linux, cgroups are used here only to tag the session
 * leader process with a string, the ssid. In doing so, the kernel will
 * also tag any decendants of that process (via clone, fork, whatever) as well.
 * This way even if the process does things like double-forks or forgets to
 * pass along the XDG_SESSION_COOKIE, it and it's decendants always have
 * that ssid so ConsoleKit2 doesn't get confused. We don't need or use
 * anything else with cgroups such as resource management.
 */

The last sentence is similar to a comment made by Lennart Poettering in this blog post written in 2012.

As a conclusion I suggest to either remove or move to pasture the cgmanager package in -current, or at the very least make its startup scripts non executable by default. Thoughts?

Incidentally ConsoleKit2 is supposed to manage multiseat, as does systemd.logind. I would be curious to know of anyone using this multiseat feature through ConsoleKit2. Examples welcome.

Other than that, this rant is worth reading about the big picture.

And the definition of a session by freeedesktop.org in their article about multiseat differ from that found in "man credentials", but I digress.

Oh, and a good article about usage of control groups for resources management (not just managing control groups, but actually using the resources' management features they allow) is Fedora's Resource Management Guide.

Thanks in advance for your comments.

ponce · 02-13-2017, 02:45 PM

as I have understood it, but I may be wrong, it's still needed at least for cgroup controllers mounts where systemd is not available

https://s3hh.wordpress.com/2016/06/1...her-cgmanager/

Didier Spaier · 02-13-2017, 03:15 PM

Well, I don't think so.

In slackware, the root cgroup is mounted on /sys/fs/cgroup, that gathers all controllers:

Code:

didier[~]$ ls -1 /sys/fs/cgroup
blkio
cpu
cpuacct
cpuset
devices
freezer
memory
net_cls
net_prio
perf_event
pids
didier[~]$

Then, creating a control group for ponce and attach it to, say the memory controller is just a matter of "mkdir /sys/fs/cgroup/memory/ponce". Alternatively you can use cgcreate for that (that allows to attach several controllers to ponce in one command and set parameters).

PS Then one can use cgset or just an "echo" command to set one of the "tunable" parameters.

PPS Thanks for the link anyway Matteo. I missed this one. Oh, and while I am at it: is anyone aware of a SlackBuild @ SBo that depend on cgmanager?

Didier Spaier · 02-13-2017, 03:46 PM

I forgot to mention lxc, that has cgmanager a optional dependency. Building it with "--enable-cgmanager=no" works, but as I never used it maybe some kind soul would like to build it that way, install it and check that everything that previously worked still does?

ponce · 02-14-2017, 02:17 AM

libvirt and docker are other softwares using cgroups that need to be eventually tested.

Didier Spaier · 02-14-2017, 03:29 PM

I had a look at libvirt. It has lxc as optional dep (will be picked up as lxc is shipped in a full Slackware installation, default = auto and Robby's SlackBuild does not set it otherwise), other than that if I read correctly it uses the cgroup kernel API directly, not cgmanager (files util/vircgroup.{c,h}. So I assume that if lxc works as expected without cgmanager, libvirt should as well. Now let me have a look at docker.

Didier Spaier · 02-14-2017, 05:23 PM

[Duplicate post]

Didier Spaier · 02-14-2017, 05:35 PM

I downloaded docker, most recent release 1.13.1 (newer than the one built from SBo).

A look at vendor/github.com/opencontainers/runc/libcontainer/cgroups/utils.go, for instance, makes pretty obvious (even seeing a go source file for the first time ever) that the cgroup-v1 kernel API is used, not cgmanager.

So I assume that cgmanager is not needed by docker.

chris.willing · 02-14-2017, 07:45 PM

My comment/request is to not rush to remove cgmanager. I use its cgm command to set up the user environment at login to enable use of unprivileged containers as described here http://www.darlo.tv/lxc/setup-unpriv-slackware.html. I haven't seen an alternative mechanism described for Slackware - not that it isn't possible, just that I haven't seen it. It's probably possible for me to change from the cgm commands to cgcreate & friends in libcgroup but I'm not sure how long it will take to figure out. It's one thing to say 'here is how the new commands work', but another quite separate thing to arrange the new commands to set up users' environments automagically i.e. without extensive user intervention. Note that we don't have pam & systemd like the systems on which all these tools are developed (and howtos are written).

chris

Didier Spaier · 02-15-2017, 03:35 AM

Thanks for your input Chris. I will answer when I will have fully understood this topic and hopefully found practical ways of replacing cgm commands.

atelszewski · 02-15-2017, 12:36 PM

Hi,

Quote:

Originally Posted by Didier Spaier

Currently a cgmanager daemon is started by default in Slackware 14.2, as /etc/rc.d/rc.cgmanager and /etc/rc.cgproxy are executable by default in Slackware 14.2.

Wondering if that was really necessary, I noticed that not having them executable does not prevent ConsoleKit2 to work.

Can you name something that should fail to work if ConsoleKit2 fails to work?

I have all rc.cg* disabled since day 1:

Code:

$ ls -l rc.cg*
-rw-r--r-- 1 root root 4895 Aug 25  2014 rc.cgconfig
-rw-r--r-- 1 root root 1462 Dec 15  2015 rc.cgmanager
-rw-r--r-- 1 root root 1270 Dec 15  2015 rc.cgproxy
-rw-r--r-- 1 root root 3333 Aug 25  2014 rc.cgred

and I haven't seen any inconveniences.
I'm working mostly under WM/DE and my user account seems to have the access to everything it needs.

The same seems to apply to LXC/libvirt, although I'm no expert in LXC at all.
I created basic LXC container(?) using virt-manager and it worked fine (to my knowledge).

--
Best regards,
Andrzej Telszewski

upnort · 02-15-2017, 05:22 PM

@Didier Spaier: I have no comment about your original post. I only am adding that I concur with atelszewski. I never had any of the 4 cg* rc.d scripts enabled.

chris.willing · 02-15-2017, 06:49 PM

I have several scripts in /etc/rc.d that have never been executable - implying that I have no use for them. That doesn't lead me to advocate for the removal of the packages which provide them.

chris

upnort · 02-15-2017, 07:15 PM

Quote:

That doesn't lead me to advocate for the removal of the packages which provide them.

That was not my intent. Only that my system runs without those services.

chris.willing · 02-15-2017, 07:37 PM

Quote:

Originally Posted by upnort

That was not my intent. Only that my system runs without those services.

The intent to remove (or at least disable by default) an "unused" service is how/why this thread started. I'm not implying any intent on your part in particular (I didn't quote your post).

However since there are now appearing posts confirming systems running satisfactorily without such "unused" service(s), I'm concerned that non-use by some (even many) users should, by itself, be the reason for removing a package.

chris