Bug 961844 – after reboot cgred does not confine/move users' processes into relevant target...

Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.

Bug 961844 - after reboot cgred does not confine/move users' processes into relevant target...

Summary:	after reboot cgred does not confine/move users' processes into relevant targe...

Status:	CLOSED ERRATA

Aliases:	None

Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	libcgroup (Show other bugs)
Sub Component:
Version:	6.4
Hardware:	x86_64 Linux

Priority	unspecified Severity high
Target Milestone:	rc
Target Release:	---
Assigned To:	Peter Schiffer
QA Contact:	Red Hat Kernel QE team
Docs Contact:

URL:
Whiteboard:
Keywords:	EasyFix, Patch

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2013-05-10 10:22 EDT by lejeczek
Modified:	2014-11-21 10:22 EST (History)
CC List:	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
Add an attachment (proposed patch, testcase, etc.)

External Trackers
Tracker	ID	Priority	Status	Summary	Last Updated
Red Hat Knowledge Base (Solution)	1275263	None	None	None	Never
Red Hat Product Errata	RHBA-2013:1685	normal	SHIPPED_LIVE	libcgroup bug fix and enhancement update	2013-11-20 16:52:29 EST

Groups: 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.