Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

lxc-destroy destroys a wrong container (bug in lxc-clone) #694

Closed
tchwpkgorg opened this issue Nov 11, 2015 · 2 comments
Closed

lxc-destroy destroys a wrong container (bug in lxc-clone) #694

tchwpkgorg opened this issue Nov 11, 2015 · 2 comments
Assignees
@hallyn

Comments

@tchwpkgorg
Copy link

lxc-destroy will destroy a wrong container if lxc-clone -B dir was interrupted (ctrl+c).

Mailing list report with a way to reproduce: https://lists.linuxcontainers.org/pipermail/lxc-users/2015-November/010419.html
@brauner
Copy link
Member

brauner commented Nov 11, 2015

For completeness sake:
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

@hallyn hallyn self-assigned this Nov 11, 2015
@hallyn
Copy link
Member

hallyn commented Nov 11, 2015

At one point this was handled right. It regressed when the unexpanded_config was introduced, because the rootfs was cleared (temporarily) in the old container's lxc_conf, not in its unexpanded config.

@hallyn hallyn closed this as completed in 5eea90e Nov 17, 2015
ksperis pushed a commit to ksperis/lxc that referenced this issue Dec 13, 2015
@hallyn @ksperis
clone: clear the rootfs out of unexpanded config
9f6072c 
Closes lxc#694

When we start cloning container c1 to c2, we first save c1's
configuration in c2's as a starting point.  We long ago cleared
out the lxc.rootfs entry before saving it, so that if we are
killed before we update the rootfs, c2's rootfs doesn't point
to c1's.  Because then lxc-destroy -n c2 would delete c1's rootfs.

But when we introduced the unexpanded_config, we didn't update
this code to clear the rootfs out of the unexpanded_config, which
is what now actually gets saved in write_config().

Do so.

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
z-image pushed a commit to z-image/lxc that referenced this issue Oct 16, 2016
@hallyn @stgraber
clone: clear the rootfs out of unexpanded config
12cb3ad 
Closes lxc#694

When we start cloning container c1 to c2, we first save c1's
configuration in c2's as a starting point.  We long ago cleared
out the lxc.rootfs entry before saving it, so that if we are
killed before we update the rootfs, c2's rootfs doesn't point
to c1's.  Because then lxc-destroy -n c2 would delete c1's rootfs.

But when we introduced the unexpanded_config, we didn't update
this code to clear the rootfs out of the unexpanded_config, which
is what now actually gets saved in write_config().

Do so.

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Stéphane Graber <stgraber@ubuntu.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@hallyn hallyn

Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@hallyn @tchwpkgorg @brauner