Eric W. Biederman wrote: > Daniel Lezcano <dlezcano@xxxxxxxxxx> writes: > >> Perhaps, I am misunderstanding your sentence :) But just in case, let me clarify >> my idea. >> >> If you have a TCP connection with a send queue not empty (the kernel has >> buffered the data the application has sent), when your process exits because the >> last socket write was done in userspace, the TCP socket will be orphan but still >> there taking a ref count on your network namespace. Hence the process and the >> network namespace life cycles is not correlated. This is a correct behavior, it >> is not a bug. > > Agreed, letting the network stack finish sending the last bits of data from > sockets is not a bug. > > The problem I see is having a veth device that exists in a child container, > and the application waiting for the child device to return to the current network > namespace. Since we always return network devices to the initial network namespace > waiting for a device in a child container does not work in a recursive container. > And thus is a bug. I agree. >> Can a process outside of the network namespace look at this directory even if >> there are no more processes running inside the namespace ? > > If you mount it somewhere besides /proc/self/net yes. > > Say: mount --bind /proc/self/net /tmp/net Ok, thanks. >>> That is simple and will work quite nicely in the long term, and gives >>> us a lot more visibility than a simple this namespace has exited bit. >> This is nice :) >> >> Shouldn't you send /proc/net filesystem patch before sending the virtual network >> devices autodestroy patch ? > > Well there is the cheap trick with this patch of waiting until the local end > of veth dies. I actually use veth, macvlan, empty netns and physical. But if you are planning the send netns fs soon, I guess I can live with that a time. Thanks. -- Daniel _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers