[lxc-users] [BUG] lxc-destroy destroying wrong containers

[Christian Brauner]

On Tue, Nov 10, 2015 at 10:02:00PM +0900, Tomasz Chmielewski wrote:
> On 2015-11-10 20:29, Christian Brauner wrote:
> 
> >This may not have something to do with lxc-destroy but with how clones
> >work. Can
> >you only proceed up to step 2) you listed:
> >
> >        > 2) clone it - but before the command returns, press ctrl+c (say,
> >you
> >        > realized you used a wrong name and want to interrupt):
> >        >
> >        > # lxc-clone -B dir testvm012d testvm13d
> >        > [ctrl+c]
> >
> >and immediately afterwards check whether the rootfs of the original
> >container
> >testvm012d is still present?
> 
> Step 4 shows the original container is still intact:
> 
> # du -⁠sh testvm012d testvm13d
> 462M    testvm012d
> 11M     testvm13d
> 
> 
> So it must be lxc-destroy.

Yes, it is lxc-destroy but lxc-destroy does it exactly what it is expected to
do. The cause is the incomplete clone: When you clone a container config of the
original container gets copied. After the clone (copying the storage etc.)
succeeds the config is updated. That means before the config is updated the
config of your clone still contains the rootfs path to the original container.
You can verify this by doing:

        # lxc-clone -B dir testvm012d testvm13d
        [ctrl+c]

and checking

        YOUR-FAVOURITE editor testvm13d/config

it should still contain

        lxc.rootfs = /path/to/testvm012d/rootfs

in contrast to when the copy of the rootfs of the original container succeeds.
Then it will contain:

        lxc.rootfs = /path/to/testvm13d/rootfs

(lxc-devel might be a good place to determine whether this is a bug or not.)

Christian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20151110/e19e23cb/attachment.sig>