Bug 961844 - after reboot cgred does not confine/move users' processes into relevant target...
after reboot cgred does not confine/move users' processes into relevant targe...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libcgroup (Show other bugs)
6.4
x86_64 Linux
unspecified Severity high
: rc
: ---
Assigned To: Peter Schiffer
Red Hat Kernel QE team
: EasyFix, Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-10 10:22 EDT by lejeczek
Modified: 2014-11-21 10:22 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-21 17:33:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
libcgroup-0.37-cgred-order.patch (527 bytes, patch)
2013-08-27 13:41 EDT, Peter Schiffer
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1275263 None None None Never

  None (edit)
Description lejeczek 2013-05-10 10:22:10 EDT
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):

2.6.32-358.2.1.el6.x86_64
libcgroup-0.37-7.1.el6.x86_64
pam-1.1.1-13.el6.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 2 lejeczek 2013-05-13 10:05:47 EDT
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

regards
Comment 3 Peter Schiffer 2013-08-27 13:41:04 EDT
Created attachment 791128 [details]
libcgroup-0.37-cgred-order.patch
Comment 6 Mike Gahagan 2013-09-19 15:49:51 EDT
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
Comment 7 errata-xmlrpc 2013-11-21 17:33:37 EST
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.

http://rhn.redhat.com/errata/RHBA-2013-1685.html

Note You need to log in before you can comment on or make changes to this bug.