[Lxc-users] veth interface not deleted?

[Petru Ghita]

Hello Fajar,

What I'm doing as a workaround is to wait 10 seconds after a
lxc-shutdown has completed. This alleviates the problem as by that time
it seems the network interfaces get almost always deleted. Nevertheless
sometimes they don't and the following lxc-start won't work. I found so
far, that a lxc-stop manages to get them deleted no matter what in those
cases.

I didn't report the problem myself because I wasn't able to reproduce
it. My opinion on the issue is that it has something to do with CPU load
rather than with network traffic.

I'm running about 30 containers on production with a mix of services
ranging from Zimbras to java application servers. The bug hits me while
on a backup script that first turns off the containers.

Kind regards,
Petru

On 09/13/2013 02:22 AM, Fajar A. Nugraha wrote:
> On Thu, Sep 12, 2013 at 9:46 PM, Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
>> Quoting Fajar A. Nugraha (list at fajar.net):
>>> Any ideas how to troubleshoot this? Is this something related to kernel
>>> version?
>>
>> If the container fails to start at all, then lxc will manually delete
>> the veth.
> 
> The case is the container is already running, and then you stop it.
> Depending on the traffic handled by the container, the veth will
> sometimes not get deleted.
> 
> This becomes a problem later on becase I'm using persistent MAC,
> interface name (lxc.network.veth.pair), and IP address (on the
> container side), so when I start the container later (e.g. lxc-start,
> or when using "init 6" within the container) it fails to start (due to
> conflicting interface name, and even if I don't use persistent name it
> probably won't be able to function properly later due to conflicting
> IP address)
> 
>>  However if we get as far as lxc passing one end of the
>> veth tunnel into the container, then when the container dies the
>> veth should be deleted by the kernel.
> 
> The key word there is "should" :)
> 
>>
>> Have you been using lxc-attach?
> 
> Nope. lxc-start, lxc-stop, lxc-console, and commands inside the
> containers (e.g. shutdown, init 6)
> 
>> I wonder if something is pinning the
>> network namespace so that it isn't deleted.  In that case the veth
>> wouldn't get autoreaped.
> 
> 
> Again, whether this happens or not seems to depend on the network
> traffic. I can reliably reproduce it on our production container
> (obviously I can't do it often or too long), but I'm having problems
> reproducing it on test lab (i.e. how do you reproduce 2000 concurrent
> connections from different clients with  5 Mbps traffic on a test
> lab?).
> 
> I'm open to ideas and suggestions.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20130913/fca22f96/attachment.pgp>