C/R minisummit notes (namespace naming)

Daniel Lezcano dlezcano at fr.ibm.com
Fri Jul 25 13:09:32 PDT 2008


Serge E. Hallyn wrote:
> Quoting Daniel Lezcano (dlezcano at fr.ibm.com):
>> Serge E. Hallyn wrote:
>>> Quoting Eric W. Biederman (ebiederm at xmission.com):
>>>> Currently we have three possibilities on how to name pid namespaces.
>>>> - indirect via processes
>>>> - pids
>>>> - names in the filesystem
>>>>
>>>> We discussed this a bit in the hallway track and pids are look like the way
>>>> to go. Pavel has a patch in progress to help sort this out.
>>>>
>>>> The practical problem we have today is that we need a way to wait for the network
>>>> namespace in particular and namespaces in general to exit.
>>>>
>>>> At a first glance waitid(P_NS, <pid>,....) looks like a useful way to achieve
>>>> this.  After looking at wait a bit more it really is fundamentally just an exit
>>>> status reaper of zombies, that has the option of blocking when the zombies
>>>> do not yet exist.  In any kind of event loop you would wait for SIGCHLD either
>>>> as a signal or with signalfd.
>>>>
>>>> So how shall we wait for a namespace to exit?  My brainstorm tonight suggests
>>>> inotify_add_watch(ifd, "/proc/ns/<pid>", IN_DELETE);
>>>>
>>>> Eric
>>> I'm sorry, I'm still not quite clear on...
>>>
>>> Why?
>>>
>>> You care about when the tasks exit, and you care about when network
>>> devices, for instance, need to be deleted (which you can presumably
>>> get uevents for, when they get moved back into init_net_ns).
>>>
>>> Why do you care when the struct net actually gets deleted?
>> IMO, if we consider a container being an aggregation of different  
>> namespaces, we should consider the container dies when all the  
>> namespaces are dead.
>>
>> One good example is an application ran inside a container and doing a  
>> bulk data writing over the network. When the application finish its last  
>>  call to "send" it will exits. At this point, there is no more processes 
>> running inside the container but we can not consider the container is 
>> dead because there are still some pending datas in the socket to be 
>> delivered to the peer.
>>
>> Eric will post a patch to automatically destroy the virtual devices when  
>> the netns is destroyed, so there is no way to know if a network  
>> namespace is dead or not as the uevent socket will not deliver an event  
>> outside of the container.
> 
> My question remains: who cares?

The container implementation in userspace. Let's imagine it sets some 
routes outside of the container to route the traffic to the container. 
It should remove these routes when the container dies. And the container 
should be considered as dead when the network has died and not when the 
last process of the container exits.


More information about the Containers mailing list