LinuxQuestions.org - libcgroup - supplied rc.cgred broken by erroneous patch

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - libcgroup - supplied rc.cgred broken by erroneous patch (https://www.linuxquestions.org/questions/slackware-14/libcgroup-supplied-rc-cgred-broken-by-erroneous-patch-4175600724/)

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.

Thanks,
chris

Thanks, I see the fixes in -current's ChangeLog.txt Feb 28.

Any chance of applying them to 14.2 as well? Unless -current is becoming stable next week, of course :)

chris

Quote:

Originally Posted by chris.willing (Post 5677456)

Any chance of applying them to 14.2 as well?

Done.

Quote:

Unless -current is becoming stable next week, of course :)

Nope, probably not. :-)

Quote:

Originally Posted by volkerdi (Post 5677700)

Done.

Thanks, I see the new libcgroup package for 14.2 but not the etc package (for additional cgred group).

chris

Quote:

Originally Posted by chris.willing (Post 5677768)

Thanks, I see the new libcgroup package for 14.2 but not the etc package (for additional cgred group).

The 14.2 packages do not add a new group, but do have the other fixes.

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?

chris

Quote:

Originally Posted by chris.willing (Post 5862044)

I'm not seeing that here. The init script in 14.2's /patches is identical to the one in -current.

Quote:

Originally Posted by volkerdi (Post 5862236)

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.

chris