Quoting Michael H. Warfield (m...@wittsend.com): > On Tue, 2011-05-31 at 14:00 -0500, Serge Hallyn wrote: > > Quoting Ramez Hanna (rha...@informatiq.org): > > > On Tue, May 31, 2011 at 5:38 PM, Serge Hallyn > > > <serge.hal...@canonical.com>wrote: > > > > > > > Quoting Daniel Lezcano (daniel.lezc...@free.fr): > > > > > On 05/31/2011 01:44 PM, Ramez Hanna wrote: > > > > > > On Tue, May 31, 2011 at 2:07 PM, Daniel > > > > > > Lezcano<daniel.lezc...@free.fr > > > > >wrote: > > > > > > > > > > > >> On 05/31/2011 12:33 PM, Ramez Hanna wrote: > > > > > >> > > > > > >>> it seems that lxc cannot handle cgroups when capabilities are not > > > > > >>> all > > > > in > > > > > >>> the > > > > > >>> same mount > > > > > >>> it fails now because it cannot write the devices.deny in the > > > > > >>> cgroup > > > > > >>> if i comment out all the lxc.cgroup.devices lines in the config of > > > > the > > > > > >>> container then i can actually start it > > > > > >>> > > > > > >>> I would think that the way lxc identifies the cgroup mount might > > > > > >>> be > > > > the > > > > > >>> part > > > > > >>> that needs patching > > > > > >>> > > > > > >> Thanks for investigating. > > > > > >> > > > > > >> The main problem is lxc is cgroup agnostic, so we should find a > > > > solution > > > > > >> where we don't break that. > > > > > >> > > > > > >> Maybe one solution would be to collect all the mount points found > > > > > >> for > > > > the > > > > > >> cgroup and try to find the right path when writing or reading from > > > > > >> one > > > > > >> cgroup file. > > > > > >> > > > > > > that is what i had in mind, tried looking into the code but my C > > > > > > skills > > > > are > > > > > > next to zero > > > > > > > > > > > >> Does systemd run lxc within a cgroup which is not the root cgroup ? > > > > > >> > > > > > >> the lxc-start command would run under $user/master/ > > > > > > (/sys/fs/cgroup/systemd/$user/$master) > > > > > > and the container itself would run under $container_name > > > > > > (/sys/fs/cgroup/systemd/$container_name) > > > > > > so it would run the container in the root cgroup > > > > > > > > > > ouch ! I have to install systemd on a test machine to check how > > > > > systemd > > > > > plays with the cgroup. > > > > > I don't think the cgroup created by lxc should escape the cgroup the > > > > > command is assigned to. > > > > > > > > Another similar - and easier to setup - thing we need to address is > > > > running > > > > on a system with libcgroup installed. > > > > > > > > For both, I assume it'll basically come down to: > > > > > > > > 1. figure out the path of the cgroup we are in for each cgroup we care > > > > about > > > > 2. create new child cgroup for ourselves in each of the above paths > > > > whic > > > > is unique > > > > 3. track those through the lifetime of the container > > > > > > > > So it just slightly complicates what's being done now. > > > > > > > > -serge > > > > > > > how does libcgroup change things? does it also mount cgroup on different > > > points ? > > > Yes, in whatever way you ask it to. > > I noticed this a couple of clicks back. Maybe even F13 where I had > libcgroup installed and it was mounting things, initially, in /cgroup > (or some such) before the kernel dudes created the mountpoint > in /sys/fs/cgroup. I got burned by it, even back then, and had to > disable libcgroup and do the manual mount stuff in fstab. That was back > months ago when we were having the controversy over whether cgroups > should be mounted under /cgroup or /dev/cgroup or /var/lib/cgroup > or /var/run/cgroup. I thought I raised the whole issue that these > things were in a hierarchy and not a flat mount even back then. Now > it's under the /sys/fs/cgroup mount point and we need to deal with this, > now. I've had to disable the devices.{allow|deny} options on several of > my host machines at this point. Is anyone working on a solution?
Not that I know of. I don't think it's fundamentally hard, though it may get a bit dicy in principle. Just find the mountpoint for each cgroup, and change each set/get in the lxc code to use the right mountpoint. Is this something you have time to take a stab at? > Daniel mentioned getting systemd running on a system but it's more > fundamental than that. Like you say, even setting up and enabling > libcgroup is going to be problematical and we need to play nicey nicey > with the other kids in the sandbox. > > Regards, > Mike > > > -serge > > > > ------------------------------------------------------------------------------ > > Simplify data backup and recovery for your virtual environment with > > vRanger. > > Installation's a snap, and flexible recovery options mean your data is safe, > > secure and there when you need it. Data protection magic? > > Nope - It's vRanger. Get your free trial download today. > > http://p.sf.net/sfu/quest-sfdev2dev > > _______________________________________________ > > Lxc-users mailing list > > Lxc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/lxc-users > > > > -- > Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com > /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ > NIC whois: MHW9 | An optimist believes we live in the best of all > PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it! ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users