Quoting Arun M (arunmahadevai...@gmail.com): > Hi, > > I updated to lxc-0.8.0-rc2 and after that I observe dangling cgroups > (/cgroup/PID) in the filesystem after lxc-execute terminates. > > I am using ns_cgroup.
Which kernel are you on? The ns cgroup is no longer available since over a year ago. > Looks like a process is spawned in a new namespace but lxc-fails to remove > the cgroup directory. Can you show 'ps -ef'? If you can identify the process that won't die, can you see what it's doing (strace -f -o outfile -p $pid) ? My only guess would be that the container_reboot_supported() function, which gets cloned, is for some reason not dying. Except no, that can't be it, because this change actually moves that clone() to the monitor task, so it wouldn't be pinning the cgroup. Can you check whether your container is mounting a private /var or /run? My theory is that the initial task is never killed because you are relying on the utmp watcher (being on an older kernel), and the container is using a utmp that the monitor can't see. > After a long time these dangling cgroups collide with new PIDs and > lxc-execute fails with "File exists". > > Apparently caused due to commit - > http://lxc.git.sourceforge.net/git/gitweb.cgi?p=lxc/lxc;a=commit;h=69182a318c3ba35f56a88891cabad25d9f7985b6 > > This problem does not happen if I go to an earlier revision. > > Thanks, > Arun ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
