[Lxc-users] can't restart container without rebooting entire host, because can't delete cgroups files, tasks is 0

[Brian K. White]

On 11/8/2010 9:25 AM, Daniel Lezcano wrote:
> On 11/05/2010 09:27 PM, Serge E. Hallyn wrote:
>> Quoting Miroslav Lednicky (lednicky at avonet.cz):
>>
>>> Hello,
>>>
>>> 	it is the same problem as I have may be:
>>>
>>> http://sourceforge.net/mailarchive/forum.php?thread_name=4CD297E2.2030806%40avonet.cz&forum_name=lxc-users
>>>
>>> I don't know what can I do with it.
>>>
>>> Server reboot is necessary ...
>>>
>> I fired off a container and did a bunch of ns_exec's under it to create
>> some cgroup subdirectories.  When I powered off the container, lxc did
>> indeed complain about not being able to remove /cgroup/ubuntu1.  I did
>>
>> 	find /cgroup/ubuntu1 -type d -print0 | xargs -0 rmdir
>>
>> which deleted the subdirectories and complainted about not being able
>> to remove ubuntu1 itself.  Then I did 'rmdir /cgroup/ubuntu1' and it
>> worked.
>>
>> So the only problem with my find statement is that it doesn't work
>> depth-first, so you might have to do it a few times to get all of the
>> subdirectories.
>>
>> Daniel, I think it would be worthwhile for lxc, on exiting a container,
>> to do a depth-first search or all directories under the container's
>> cgroup, and rmdir them all.  What do you think?
>>
>
> Yep, agree.

If you want to cheat and assume recent versions of gnu find, it has
-deth which says "processes directories contents before directory 
itself" and -delete, which the man page says implies -depth. So all you 
need is just:

find /cgroup/vps001 -type d -delete

That's it. No error messages and the entire directory /cgroup/vps001 is 
gone afterwards.

But also, since upgrading to kernel 2.6.36 (and already using lxc 0.7.2) 
I haven't had to delete any cgroups manually anyways. It's probably not 
my release_agent because I just noticed I didn't have a working 
release_agent (no output in it's log, probably because the script wasn't 
chmod 755)

It's only been a couple days and only a few starts/stops while working 
on a new start/stop/status init script though.

-- 
bkw