I think the problem is in TIME_WAIT sockets that can exist without any processes running. But when we do lxc-stop we must be sure that container really stopped, so maybe we need to manually destroy network interfaces rather than rely on kernel namespace destruction logic?<br>
<br><div class="gmail_quote">2010/1/8 Daniel Lezcano <span dir="ltr"><<a href="mailto:daniel.lezcano@free.fr">daniel.lezcano@free.fr</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">Denis Rizaev wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello, i'm running lxc in production for 1 month and noticed bug that<br>
high-loaded veth interfaces are not destroyed after lxc-stop.<br>
This results in errors when we try to start this container again. As<br>
workaround i manually do something like ip link del veth_<container_name>.<br>
I have two high-traffic containers(~10 mbit/s each) and this bug appears on<br>
them. Other six almost idle containers destroying it's veth's interfaces<br>
properly.<br>
  <br>
</blockquote></div></div>
The veth interfaces, as any virtual interfaces in the network namespace are automatically destroyed by the kernel when a network namespace is destroyed.<br>
<br>
The network namespace is destroyed when there is no more ref count on it. And the processes, the sockets, the routes and some more things get a refcount on it when they are created.<br>
<br>
So, you may check if after a long time (at least all tcp timers have expired, so the sockets are destroyed), the interfaces are still there. If this is the case, then the kernel does not release on refcount somewhere and it's probably a kernel bug.<br>

</blockquote></div><br>