As quick solution, let's move control groups back to /cgroup (= Fedora 13 style). Proper solution will be in F15, I don't want to mess F14 in this part of release cycle.

Or setup cgconfig to mount tmpfs at /sys/fs/cgroup if it is not mounted there already. That is the position recommended by the kernel and we should be mounting there.

This is certainly valid option, patches are welcome. The init script must be super-reliable, not mounting additional tmpfs when not needed, not unmounting it when it is still needed and there are lot of corner cases when things may go wrong. I will be out of office for most of the next two weeks (i.e. till F14 deadline 2010-10-18). While I am able to implement it, I am afraid someone else must test it and fix possible bugs. In addition, three weeks before release is really not good time to experiment in F14! We should have caught this earlier.

so how about we rollback the systemd changse, since its tested well without them and push the systemd specific changes in F15?

I agree with the rollback to F13 behavior.

libcgroup-0.36.2-5.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/libcgroup-0.36.2-5.fc14

libcgroup-0.36.2-5.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update libcgroup'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/libcgroup-0.36.2-5.fc14

libcgroup-0.36.2-5.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

# rpm -qa | grep cgroup
libcgroup-0.36.2-5.fc14.x86_64
[root@Osier ~]# service cgconfig start
Starting cgconfig service: Failed to parse /etc/cgconfig.co[FAILED]

cat /etc/cgconfig.conf 
#
#  Copyright IBM Corporation. 2007
#
#  Authors:	Balbir Singh <balbir.ibm.com>
#  This program is free software; you can redistribute it and/or modify it
#  under the terms of version 2.1 of the GNU Lesser General Public License
#  as published by the Free Software Foundation.
#
#  This program is distributed in the hope that it would be useful, but
#  WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#
# See man cgconfig.conf for further details.
#
# By default, mount all separately controllers
# to /cgroup/<controller name>

mount {
	cpuset	= /cgroup/cpuset;
	cpu	= /cgroup/cpu;
	cpuacct	= /cgroup/cpuacct;
	memory	= /cgroup/memory;
	devices	= /cgroup/devices;
	freezer	= /cgroup/freezer;
	net_cls	= /cgroup/net_cls;
	ns	= /cgroup/ns;
	blkio	= /cgroup/blkio;
}


Problem still exists

Hello,
please can you attach here the output of:
$ cat /proc/cgroups

sure, quick response, :-)

#cat /proc/cgroups 
#subsys_name	hierarchy	num_cgroups	enabled
cpuset	1	1	1
ns	8	3	1
cpu	2	1	1
cpuacct	3	1	1
memory	4	1	1
devices	5	1	1
freezer	6	1	1
net_cls	7	1	1
blkio	9	1	1

You have already mounted cgroups thus the start failed, if you remove the existing hierarchies (stop the service or use cgclear), then it will works ok. Please try this method and write ere the result.

Can you do the following,

cgclear
cgconfigparser -l /etc/cgconfig.conf

If it fails, please run cgclear followed by the strace of cgconfigparser and share the same please.

Are you using systemd by any chance?

(In reply to comment #13)
> Can you do the following,
> 
> cgclear
> cgconfigparser -l /etc/cgconfig.conf
> 
> If it fails, please run cgclear followed by the strace of cgconfigparser and
> share the same please.

Thanks

yes, it works, what I have on my system is only: systemd-units.x86_64, still curious why it failed when starting.

Hello Osier,
please repopen this bug and attach here strace wanted in comment 13, if the problem appears again. Now I'm closing this bug because of insufficient data.