On 02/14/2011 07:33 PM, Milan Zamazal wrote:
> On a Debian 6.0 machine, I've got a certain container that can't be
> started again once it was stopped:
>
>    # lxc-start -n blackbird
>    lxc-start: Device or resource busy - failed to remove previous cgroup 
> '/cgroup/blackbird'
>    lxc-start: failed to spawn 'blackbird'
>    lxc-start: Device or resource busy - failed to remove cgroup 
> '/cgroup/blackbird'
>
> The container seems to be stopped completely but the /cgroup/blackbird/
> directory is indeed non-empty.  There are some subdirectories with
> numeric names there but I can't find any processes with such numbers in
> the system nor any other processes related to the container.  The only
> way to get rid of it is to reboot the host.
>
> Is there a way to force removal of the cgroup?  Or is there a way to
> find out what keeps the cgroup busy?

It is probable you have an application creating new namespaces in the 
container. That's triggering a new cgroup creation which is nested with 
the container's one. This is a kernel feature (removed for the next 
kernel version).

There are several solutions :

  * fix this behavior in lxc where we will recursively remove the cgroup 
directories
  * simply do rm -rf /cgroup/blackbird (don't care about the errors).

As a quick fix, I suggest you look what application created the new 
namespace. Launch your container and then look at 
/cgroup/blackbird/1234/tasks and look for the command line associated 
with the pid in this file. I suspect vsftpd could be the culprit. If 
this is the case, there is an option to disable the namespace creation.

http://www.mail-archive.com/[email protected]/msg01110.html

Hope that helps.

   -- Daniel

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Lxc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lxc-users

Reply via email to