From: "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Daniel Lezcano <dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
Cc: Linux Containers
<containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>,
"Eric W. Biederman"
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Subject: Re: C/R minisummit notes (namespace naming)
Date: Fri, 25 Jul 2008 14:34:58 -0500 [thread overview]
Message-ID: <20080725193458.GA12356@us.ibm.com> (raw)
In-Reply-To: <488A28E4.6080902-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
Quoting Daniel Lezcano (dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org):
> Serge E. Hallyn wrote:
>> Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
>>> 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?
-serge
next prev parent reply other threads:[~2008-07-25 19:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-23 11:30 C/R minisummit notes Daniel Lezcano
[not found] ` <4887163F.5090801-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-07-23 14:20 ` Eric W. Biederman
2008-07-23 18:55 ` Oren Laadan
[not found] ` <48877EA7.1050206-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-07-23 20:18 ` Serge E. Hallyn
2008-07-23 20:23 ` [Devel] " Denis V. Lunev
2008-07-23 20:24 ` Daniel Lezcano
2008-07-23 21:18 ` Serge E. Hallyn
[not found] ` <20080723211818.GA10295-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-07-23 21:38 ` Oren Laadan
[not found] ` <4887A4CC.5070009-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-07-24 1:41 ` sukadev-r/Jw6+rmf7HQT0dZR+AlfA
[not found] ` <20080724014122.GA23105-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-07-24 3:26 ` Serge E. Hallyn
[not found] ` <20080724032616.GB9839-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-07-24 9:58 ` Eric W. Biederman
2008-07-24 9:55 ` C/R minisummit notes (namespace naming) Eric W. Biederman
[not found] ` <m1zlo7a9nq.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-07-25 19:13 ` Serge E. Hallyn
[not found] ` <20080725191356.GE28136-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-07-25 19:26 ` Daniel Lezcano
[not found] ` <488A28E4.6080902-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-07-25 19:34 ` Serge E. Hallyn [this message]
[not found] ` <20080725193458.GA12356-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-07-25 19:52 ` Oren Laadan
2008-07-25 20:09 ` Daniel Lezcano
[not found] ` <488A32FC.7020803-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-07-26 7:32 ` Eric W. Biederman
2008-07-24 20:28 ` C/R minisummit notes Oren Laadan
[not found] ` <4888E5D3.807-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-07-25 2:14 ` Daniel Lezcano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080725193458.GA12356@us.ibm.com \
--to=serue-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.