[Request for comments] do we still need cgmanager?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
[Request for comments] do we still need cgmanager?
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.
Last edited by Didier Spaier; 02-15-2017 at 04:22 AM.
Reason: Typos fixed, again.
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?
Last edited by Didier Spaier; 02-13-2017 at 04:51 PM.
Reason: PPS added.
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?
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.
Last edited by Didier Spaier; 02-14-2017 at 05:51 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.
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).
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).
@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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.