libcgroup - supplied rc.cgred broken by erroneous patch
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.
libcgroup - supplied rc.cgred broken by erroneous patch
The patch libcgroup.init.diff.gz which is applied when libcgroup package is built is broken. It changes loading of /etc/sysconfig/cgred.conf to loading of $CGRED_CONF which is set to /etc/cgrules.conf. It should instead be loading /etc/cgred.conf which defines various OPTIONS. I guess the confusion is due to there being two configuration files used when rc.cgred is run. The affected part of the patch (right near the top) should really be:
Code:
# Read in configuration options.
-if [ -f "/etc/sysconfig/cgred.conf" ] ; then
- . /etc/sysconfig/cgred.conf
+if [ -f /etc/cgred.conf ] ; then
+ . /etc/cgred.conf
This leads to another configuration issue. When /etc/cgred.conf is now sourced, it defines SOCKET_GROUP="cgred" where cgred is a system group but that group doesn't exist. It could be defined SOCKET_GROUP="" (effectively root group) but it's probably best to have a new system group named cgred. This enables cgexec to be run sgid instead of suid (requires explicit 'chmod 2755 /usr/bin/cgexec' though).
One other related concern is that when "/etc/rc.d/rc.cgconfig stop" is run, it calls /usr/sbin/cgclear. Could this call be made "/usr/sbin/cgclear -l /etc/cgconfig.conf" instead please? Otherwise the whole cgroup file system is removed which is not what is wanted if running "rc.cgconfig restart" because "rc.cgconfig start" assumes that the root of the cgroup filesystem already exists. The cgroup filesystem root is normally created early in rc.S but the plain cgclear removes it (along with anything subsequently added to it) and there's no existing mechanism at the moment to reinstate the root so that "rc.cgconfig start" can add to it.
Working through some container issues, I discovered that the fix to rc.cgred for 14.2 went bad somewhere along the line. Instead of sourcing /etc/cgred.conf, it sources $CGRED_CONF which is set to /etc/cgrules.conf.
I see that it has been corrected in -current; could it be corrected in 14.2 as well please?
Working through some container issues, I discovered that the fix to rc.cgred for 14.2 went bad somewhere along the line. Instead of sourcing /etc/cgred.conf, it sources $CGRED_CONF which is set to /etc/cgrules.conf.
I see that it has been corrected in -current; could it be corrected in 14.2 as well please?
I'm not seeing that here. The init script in 14.2's /patches is identical to the one in -current.
I'm not seeing that here. The init script in 14.2's /patches is identical to the one in -current.
Yes, my mistake. I was working on a fix for 100% cpu usage by cgrulesengd but used the original /source/a/libcgroup directory rather than /patches/source/libgroup.
I'll check the fix against the correct version before posting it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.