Bug 294717 – ebuild request for dev-libs/libcgroup

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Andrew Fedorov 2009-11-26 14:31:05 UTC]

libcgroup is a tools and libraries to control and monitor the Linux kernel's new process grouping system.

You can find additional information at http://fedoraproject.org/wiki/Features/ControlGroups

[Comment 1 Tomás Touceda (RETIRED) 2009-11-26 17:12:00 UTC]

This is now in sunrise:

https://overlays.gentoo.org/proj/sunrise/browser/sunrise/dev-libs/libcgroup

Hopefully it will be reviewed in a couple of days

[Comment 2 Andreis Vinogradovs ( slepnoga ) 2009-12-04 13:00:54 UTC]

(In reply to comment #1)
> This is now in sunrise:
> 
> https://overlays.gentoo.org/proj/sunrise/browser/sunrise/dev-libs/libcgroup
> 
> Hopefully it will be reviewed in a couple of days
> 

this ebuild not contain support of cgred daemon.
Plz, see READMI_daemon.

[Comment 3 Andreis Vinogradovs ( slepnoga ) 2010-01-26 18:11:08 UTC]

Created attachment 217486 [details]
fixed libcgroup ebuld

[Comment 4 Elias Probst 2010-08-06 13:47:20 UTC]

Bumping the current 0.34 ebuild which is available through sunrise to the current release 0.36.2 results in this automake error:

**** automake *****
***** PWD: /var/tmp/portage/dev-libs/libcgroup-0.36.2/work/libcgroup-0.36.2
***** automake --add-missing --copy --foreign

src/pam/Makefile.am:5: pamlibdir was already defined in condition TRUE, which includes condition WITH_PAM ...
configure.in:121: ... `pamlibdir' previously defined here
src/pam/Makefile.am:6: `pampamlib_LTLIBRARIES' is used but `pampamlibdir' is undefined
src/pam/Makefile.am:7: variable `pam_cgroup_la_SOURCES' is defined but no program or
src/pam/Makefile.am:7: library has `pam_cgroup_la' as canonical name (possible typo)
src/pam/Makefile.am:9: variable `pam_cgroup_la_LIBADD' is defined but no program or
src/pam/Makefile.am:9: library has `pam_cgroup_la' as canonical name (possible typo)
src/pam/Makefile.am:8: variable `pam_cgroup_la_LDFLAGS' is defined but no program or
src/pam/Makefile.am:8: library has `pam_cgroup_la' as canonical name (possible typo)


This is probably a result of these lines in the ebuild:
    # Install PAM module into correct location
    sed \
        -e "/lib_LTLIBRARIES/ i pamlibdir=$(getpam_mod_dir)" \
        -e 's/lib_LTLIBRARIES/pamlib_LTLIBRARIES/' \
        -e '/pam_cgroup_la_LDFLAGS/ s/$/ -avoid-version -shared/' \
        -i src/pam/Makefile.am || die "sed failed"

[Comment 5 Stijn Tintel 2010-11-20 17:07:51 UTC]

(In reply to comment #4)
> Bumping the current 0.34 ebuild which is available through sunrise to the
> current release 0.36.2 results in this automake error:
> 

This should fix compile (only compile-tested):

--- /var/lib/layman/sunrise/dev-libs/libcgroup/libcgroup-0.34.ebuild    2010-11-20 16:36:43.961757302 +0100
+++ libcgroup-0.36.2.ebuild     2010-11-20 17:58:11.205564901 +0100
@@ -41,10 +41,12 @@
        # Install PAM module into correct location
        sed \
                -e "/lib_LTLIBRARIES/ i pamlibdir=$(getpam_mod_dir)" \
-               -e 's/lib_LTLIBRARIES/pamlib_LTLIBRARIES/' \
                -e '/pam_cgroup_la_LDFLAGS/ s/$/ -avoid-version -shared/' \
                -i src/pam/Makefile.am || die "sed failed"
 
+       sed -i 's/cgroup_dbg(%s)/cgroup_dbg("%s")/' src/lex.c || die "sed failed"
+
+
        eautoreconf
 }
 

[Comment 6 App Deb 2010-11-23 15:52:24 UTC]

(In reply to comment #5)

> This should fix compile (only compile-tested):

Thanks, this seems to work. I have been using v0.36.2 cgconfig/cgred daemons succesfully.


However the init.d/cgconfig script is wrong because it tries to discover or create a "default" group. 

This is not needed because the root directory of each cgroup controller mount is supposed to be the default group. There is no need to create one.

Even if a default group is to be used, the logic in the script is wrong because a line like (example):

*:/usr/bin/emerge    examplecontroller   examplegroup/

Is parsed as a default group, which shouldn't.


I commented out the whole default group functions in the script, and everything seems to work as intended.

[Comment 7 Xake 2010-12-07 21:09:03 UTC]

There has been five updates since this, also any idea if this will hit portage?

[Comment 8 Homer Parker (RETIRED) 2011-01-07 12:28:47 UTC]

Created attachment 259131 [details]
New ebuild

See how this works, it installs ok for me. Still learning it so can't comment on how well it works yet.

[Comment 9 Steve Arnold 2011-03-05 18:13:34 UTC]

A version of this is now in the tree, and after much testing with hparker, the key config tip is not to enable the cgroup namespace subsytem if you want your custom config and/or rules to work (regular namespace options outside the cgroup config are okay).  If you just want the basic vserver config for moving processes into the appropriate VM, then *do* enable the above option.  There are currently no "default" configuration blocks or rules, since custom settings are (mostly) specific to the number of CPUs, size of physical ram, etc.  Feel free to propose a working wildcard rule on a new bug...