Re: [lxc-users] [BUG] lxc-destroy destroying wrong containers
Quoting Christian Brauner (christian.brau...@mailbox.org): > On Tue, 10 Nov 2015 14:19:41 +0900, Tomasz Chmielewski : > > lxc-destroy may be destroying wrong containers! > > > > To reproduce: > > > > 1) have a container you want to clone - here, testvm012d: > > > > # lxc-ls -f > > NAMESTATEIPV4 > > IPV6 GROUPS AUTOSTART > > --- > > testvm012d STOPPED - > > - - NO > > > > > > 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] > > > > > > 3) lxc-ls will now show two containers: > > > > # lxc-ls -f > > NAMESTATEIPV4 > > IPV6 GROUPS AUTOSTART > > --- > > testvm012d STOPPED - > > - - NO > > testvm13d STOPPED - > > - - NO > > > > > > 4) we can see that the "interrupted" container was not fully copied - let's > > remove it then with lxc-destroy: > > > > # du -sh testvm012d testvm13d > > 462Mtestvm012d > > 11M testvm13d > > > > # lxc-destroy -n testvm13d > > > > # echo $? > > 0 > > > > > > 5) as expected, lxc-ls only lists the original container now: > > > > # lxc-ls -f > > NAMESTATEIPV4 > > IPV6 GROUPS AUTOSTART > > --- > > testvm012d STOPPED - > > - - NO > > > > > > 6) unfortunately rootfs for the original container is gone: > > > > # du -sh testvm012d > > 4.0Ktestvm012d > > > > # ls testvm012d/ > > config > 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? Sorry, this was in the deferred queue for some reason, and I just let it through. Presumably you saw the fix hit the mailing list yesterday. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] [BUG] lxc-destroy destroying wrong containers
On Tue, 10 Nov 2015 14:19:41 +0900, Tomasz Chmielewski : > lxc-destroy may be destroying wrong containers! > > To reproduce: > > 1) have a container you want to clone - here, testvm012d: > > # lxc-ls -f > NAMESTATEIPV4 > IPV6 GROUPS AUTOSTART > --- > testvm012d STOPPED - > - - NO > > > 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] > > > 3) lxc-ls will now show two containers: > > # lxc-ls -f > NAMESTATEIPV4 > IPV6 GROUPS AUTOSTART > --- > testvm012d STOPPED - > - - NO > testvm13d STOPPED - > - - NO > > > 4) we can see that the "interrupted" container was not fully copied - let's > remove it then with lxc-destroy: > > # du -sh testvm012d testvm13d > 462Mtestvm012d > 11M testvm13d > > # lxc-destroy -n testvm13d > > # echo $? > 0 > > > 5) as expected, lxc-ls only lists the original container now: > > # lxc-ls -f > NAMESTATEIPV4 > IPV6 GROUPS AUTOSTART > --- > testvm012d STOPPED - > - - NO > > > 6) unfortunately rootfs for the original container is gone: > > # du -sh testvm012d > 4.0Ktestvm012d > > # ls testvm012d/ > config 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? Christian signature.asc Description: PGP signature ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] [BUG] lxc-destroy destroying wrong containers
Quoting Tomasz Chmielewski (t...@virtall.com): > On 2015-11-11 07:28, Serge Hallyn wrote: > >Hi, > > > >as I think was mentioned elsewhere I suspect this is a bug in the > >clone code. > >Could you open a github issue at github.com/lxc/lxc/issues and > >assign it to > >me? > > Added: > > https://github.com/lxc/lxc/issues/694 Thanks! ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] [BUG] lxc-destroy destroying wrong containers
On 2015-11-11 07:28, Serge Hallyn wrote: Hi, as I think was mentioned elsewhere I suspect this is a bug in the clone code. Could you open a github issue at github.com/lxc/lxc/issues and assign it to me? Added: https://github.com/lxc/lxc/issues/694 -- Tomasz Chmielewski http://wpkg.org ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] [BUG] lxc-destroy destroying wrong containers
Hi, as I think was mentioned elsewhere I suspect this is a bug in the clone code. Could you open a github issue at github.com/lxc/lxc/issues and assign it to me? thanks, -serge ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] [BUG] lxc-destroy destroying wrong containers
This is obviously a bug and counterintuitive, unless you are a martian. On Tue, Nov 10, 2015 at 9:02 AM, Bostjan Skufca wrote: > > Looks like lxc-clone should copy the config file at the very end, after > > rootfs. > > +1 > > > Use cp analogy for example (with behaviour that most users got used to > expect in the last few decades): > > cp -pR dir1 dir2 > # (cp gets interrupted for some reason, ctrl+c or whatever, ok, I need > to start again) > rm -rf dir2 > cp -pR dir1 dir2 > > The last thing you would expect is: > cp: cannot stat ‘dir1’: No such file or directory > > Right? > So, taking user's existing knowledge and shell habits into account, > this most certainly is a bug in lxc-clone. > > b. > ___ > lxc-users mailing list > lxc-users@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-users > ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] [BUG] lxc-destroy destroying wrong containers
> Looks like lxc-clone should copy the config file at the very end, after > rootfs. +1 Use cp analogy for example (with behaviour that most users got used to expect in the last few decades): cp -pR dir1 dir2 # (cp gets interrupted for some reason, ctrl+c or whatever, ok, I need to start again) rm -rf dir2 cp -pR dir1 dir2 The last thing you would expect is: cp: cannot stat ‘dir1’: No such file or directory Right? So, taking user's existing knowledge and shell habits into account, this most certainly is a bug in lxc-clone. b. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] [BUG] lxc-destroy destroying wrong containers
On 2015-11-10 22:47, Christian Brauner wrote: 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.) Looks like lxc-clone should copy the config file at the very end, after rootfs. Tomasz Chmielewski http://wpkg.org ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] [BUG] lxc-destroy destroying wrong containers
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 > 462Mtestvm012d > 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 signature.asc Description: PGP signature ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] [BUG] lxc-destroy destroying wrong containers
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 462Mtestvm012d 11M testvm13d So it must be lxc-destroy. Tomasz Chmielewski http://wpkg.org ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
[lxc-users] [BUG] lxc-destroy destroying wrong containers
lxc-destroy may be destroying wrong containers! To reproduce: 1) have a container you want to clone - here, testvm012d: # lxc-ls -f NAMESTATEIPV4 IPV6 GROUPS AUTOSTART --- testvm012d STOPPED - - - NO 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] 3) lxc-ls will now show two containers: # lxc-ls -f NAMESTATEIPV4 IPV6 GROUPS AUTOSTART --- testvm012d STOPPED - - - NO testvm13d STOPPED - - - NO 4) we can see that the "interrupted" container was not fully copied - let's remove it then with lxc-destroy: # du -sh testvm012d testvm13d 462Mtestvm012d 11M testvm13d # lxc-destroy -n testvm13d # echo $? 0 5) as expected, lxc-ls only lists the original container now: # lxc-ls -f NAMESTATEIPV4 IPV6 GROUPS AUTOSTART --- testvm012d STOPPED - - - NO 6) unfortunately rootfs for the original container is gone: # du -sh testvm012d 4.0Ktestvm012d # ls testvm012d/ config If it matters, my containers are in /srv/lxc/, symlinked from /var/lib/lxc/ Tomasz Chmielewski http://wpkg.org ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
