[Lxc-users] veth interface not deleted?

[Fajar A. Nugraha]

On Mon, Sep 30, 2013 at 11:29 PM, Serge Hallyn <serge.hallyn at ubuntu.com>wrote:

> Quoting Serge Hallyn (serge.hallyn at ubuntu.com):
> > Quoting Jäkel, Guido (G.Jaekel at dnb.de):
>


> > > >> By the other hand if I prevent inside the container by
> configuration that eth0 is driven down, then right at the termination of
> the lxc
> > > >>process the ssh terminal quits and also, the veth disappears. Beside
> from the test, I noticed the similar effect on other "in-real-usage"-
> > > >>containers with connection to listeners inside: The veth stays a
> while until theses inbounding connection have died.
> > >
> > > ... , but what causes this "helpful" effect? I guess that the open
> connection are reset, maybe by the stack as a result of closing the network
> namespace. But why this will happen only if the interface was left up
> (which is the anormal case)?
> >
> > You bring up a good point - we should be able to inject a tcp rst to
> > force it to close.  So we may in fact be able to watch for this and
> > fix it from userspace in lxc.  (in fact that may be the only place
> > where it really makes sense to do - since we *know* the container
> > should be dying.)
>
> If someone wants to experiment with this and send a patch with
> a good example of how to test the patch - that would rock.
>

Would injecting tcp rst really be necessary? In my test, doing "ip link
del" on the host side of the interface ALWAYS succeed, no matter what the
state the guest container's interface is.

Serge, do you have the particular commit ids for "lxc.network.script.down"
support? Backporting that would probably be the best step for me to try.

-- 
Fajar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20131001/4cef268c/attachment.html>