[Request for comments] do we still need cgmanager?
1 Attachment(s)
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:
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 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. |
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/ |
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 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? |
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?
|
libvirt and docker are other softwares using cgroups that need to be eventually tested.
|
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.
|
[Duplicate post]
|
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).
chris |
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.
|
Hi,
Quote:
I have all rc.cg* disabled since day 1: Code:
$ ls -l rc.cg* 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 |
@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.
chris |
Quote:
|
Quote:
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 |
All times are GMT -5. The time now is 07:21 PM. |