Bug 921328 - The cgred service fails to start with an empty configuration file.
Summary: The cgred service fails to start with an empty configuration file.
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libcgroup
Version: 6.3
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Peter Schiffer
QA Contact: Mike Gahagan
URL:
Whiteboard:
Keywords: Patch
Depends On:
Blocks: 835616 947775 960070
TreeView+ depends on / blocked
 
Reported: 2013-03-14 02:43 UTC by Jamie Duncan
Modified: 2018-12-01 16:48 UTC (History)
6 users (show)

(edit)
Cause: cgred service was refusing to start if it's configuration file was missing or empty. however it was OK if file contained only comments

Consequence: cgred service failed to start with empty configuration file

Fix: remove explicit checks for existence of configuration file

Result: cgred service starts with missing or empty configuration file
Clone Of:
(edit)
Last Closed: 2013-11-21 22:32:44 UTC


Attachments (Terms of Use)
libcgroup-0.37-cgred-empty-config.patch (1.78 KB, patch)
2013-06-19 11:26 UTC, Peter Schiffer
no flags Details | Diff


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

Description Jamie Duncan 2013-03-14 02:43:04 UTC
Description of problem:
If /etc/cgrules.conf is empty (but exists) cgred refuses to start.
If even a comment is present, it starts correctly.

Version-Release number of selected component (if applicable):
libcgroup-0.37-7.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.have an empty or non-existent /etc/cgrules.conf
2.attempt to start cgred service
3.
  
Actual results:
service fails to start 

Expected results:
service should start

Additional info:
# Empty File
Stopping CGroup Rules Engine Daemon...                          [  OK  ]
Starting CGroup Rules Engine Daemon: not configured        [FAILED]

Can you provide the results from

$ ls -l /etc/cgrules.conf

-rw-r--r-- 1 root root 0 Feb 22 18:30 /etc/cgrules.conf

When a comment is placed in /etc/cgrules.conf files (so there is
only one hash mark in the file) the service starts normally

# One hash mark

Stopping CGroup Rules Engine Daemon...                   [  OK  ]
Starting CGroup Rules Engine Daemon:                       [  OK  ]

Comment 3 Peter Schiffer 2013-06-19 11:26:08 UTC
Created attachment 762873 [details]
libcgroup-0.37-cgred-empty-config.patch

Comment 12 Mike Gahagan 2013-09-12 15:52:40 UTC
[root@dhcp137-133 initscript]# rpm -q libcgroup
libcgroup-0.40.rc1-2.el6.x86_64
[root@dhcp137-133 initscript]# rm /etc/cgrules.conf
rm: remove regular file `/etc/cgrules.conf'? y
[root@dhcp137-133 initscript]# service cgred restart # no cgrules.conf
Stopping CGroup Rules Engine Daemon...                     [  OK  ]
Starting CGroup Rules Engine Daemon:                       [  OK  ]
[root@dhcp137-133 initscript]# service cgred start # empty cgrules.conf
Starting CGroup Rules Engine Daemon:                       [  OK  ]
[root@dhcp137-133 initscript]# ps ax | grep cg
   13 ?        S      0:00 [cgroup]
28322 ?        Ss     0:00 /sbin/cgrulesengd -g cgred
28327 pts/2    S+     0:00 grep cg
[root@dhcp137-133 initscript]# service cgred restart # cgrules.conf only comments
Stopping CGroup Rules Engine Daemon...                     [  OK  ]
Starting CGroup Rules Engine Daemon:                       [  OK  ]

Fixed in libcgroup-0.40.rc1-2.el6.x86_64, this can be verified.

Comment 13 errata-xmlrpc 2013-11-21 22:32:44 UTC
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.