Daniel Lezcano <[EMAIL PROTECTED]> 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. > 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 >> 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. Eric _______________________________________________ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
