On Thu, Sep 12, 2013 at 9:46 PM, Serge Hallyn <serge.hal...@ubuntu.com> wrote: > Quoting Fajar A. Nugraha (l...@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. -- Fajar ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
