Quoting Daniel Lezcano (daniel.lezc...@free.fr): > On 04/26/2012 07:09 AM, Serge Hallyn wrote: > >From: Serge Hallyn<serge.hal...@ubuntu.com> > > > >Author: Timothy Chen<tnac...@gmail.com> > >Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/980902 > > > >Signed-off-by: Serge Hallyn<serge.hal...@ubuntu.com> > >Cc: Timothy Chen<tnac...@gmail.com> > >--- > > src/lxc/lxc-destroy.in | 1 + > > 1 file changed, 1 insertion(+) > > > >diff --git a/src/lxc/lxc-destroy.in b/src/lxc/lxc-destroy.in > >index b0f2da5..17fa6d6 100644 > >--- a/src/lxc/lxc-destroy.in > >+++ b/src/lxc/lxc-destroy.in > >@@ -87,6 +87,7 @@ lxc-info -n $lxc_name 2>/dev/null | grep -q RUNNING > > if [ $? -eq 0 ]; then > > if [ $force -eq 1 ]; then > > lxc-stop -n $lxc_name > >+ lxc-wait -n $lxc_name -s STOPPED > > else > > echo "Container $lxc_name is running, aborting the deletion." > > exit 1 > > I don't get why this is needed, lxc-stop is synchronous. When the > lxc-stop command exits, we have the guarantee the container has > stopped. If it is not the case, that means there is a problem > somewhere else.
Some of the filesystems may not yet have been auto-umounted when the namespaces were cleaned up, causing the subsequent rm -rf $rootfs to fail. -serge ------------------------------------------------------------------------------ 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
