Cause: cgred service was starting too early in the boot process
Consequence: some services might avoid restriction if started before the cgred service
Fix: lower boot priority of cgred service
Result: all services should be restricted correctly by cgred. Please note, that solution of this problem might change in the future versions of libcgroup.
Description of problem:
.. but suffice to service cgred restart
and it behaves as intended/expected
so, each time system reboots and services start by init and users log in they are not being control
restart cgred and all it a ok
there in no indication in logs that something went wrong at system startup time
Version-Release number of selected component (if applicable):
Steps to Reproduce:
problematic appears to be userdb backend (slapd in my case)
fix is to reorder init, eg:
mv ./rc.d/rc3.d/S14cgred ./rc.d/rc3.d/S28cgred
in other words make sure cgred starts afterwards
or fix is for developers of cgroups to change rationale and reflect it in the code or maybe it's just a minor change
Created attachment 791128 [details]
Confirmed we are now starting cgred later in the boot process so it should start after slapd and related ldap services. Verified using version libcgroup-0.40.rc1-3.el6
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.