Cedric Le Goater <clg@fr.ibm.com> writes:

> Hello All,
>
> Eric, in your initial proof of concept on the pid namespace, you were
> defining a child_reaper per pid namespace.
>
> IMO, we can't use init_task as a child_reaper in a pid namespace because we
> will have pid collision which might result in a breakage of the init_task.

The kernel doesn't use init_task (The idle thread) once it starts
init.  Reaping children is the job of pid == 1.

> Here are some questions on the model you intended to follow :
>
> Do you think we should have a child_reaper task per container ?
We have an init per container so yes.

> Could we use a kthread to do the job ?
Definitely not.

> Could that kthread be global to all pid namespace ?
Makes no sense.

> Any completely different idea on the topic ?
Init reaps the children, and I believe there are parts of user space
that depend on this.  We shouldn't change that semantic.

Eric
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers

Eric W. Biederman wrote:
> Cedric Le Goater <clg@fr.ibm.com> writes:
> 
>> Hello All,
>>
>> Eric, in your initial proof of concept on the pid namespace, you were
>> defining a child_reaper per pid namespace.
>>
>> IMO, we can't use init_task as a child_reaper in a pid namespace because we
>> will have pid collision which might result in a breakage of the init_task.
> 
> The kernel doesn't use init_task (The idle thread) once it starts
> init.  Reaping children is the job of pid == 1.

agree.

>> Here are some questions on the model you intended to follow :
>>
>> Do you think we should have a child_reaper task per container ?
> We have an init per container so yes.

hmm, have we always ? what if i don't start an /sbin/init process in my
newly created pid namespace or container. where do I collect all the SIGCHLD ?

>> Could we use a kthread to do the job ?
> Definitely not.

why ?

>> Could that kthread be global to all pid namespace ?
>
> Makes no sense.

if you don't have an init per container, we need to find someone for the job.

>> Any completely different idea on the topic ?
> Init reaps the children, and I believe there are parts of user space
> that depend on this.  We shouldn't change that semantic.

IMHO, the only semantic i see is in the kernel, which needs someone to take
care of sigchld. /sbin/init is a very good candidate bc it collects sigchld
anyway and discards the ones it doesn't know about.

C.

_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers

Cedric Le Goater <clg@fr.ibm.com> writes:

> Hello,
>
> Roman Kagan wrote:
>
> [ ... ]
>
>>> As for the per-container init process, the alternative to always
>>> enforcing a separate init process for every container is to allow an
>>> option of making the process which did the pidspace unshare (or is it
>>> the parent of that process) masquerade as (pidspace=new_container, pid=1).
>> 
>> There's no point enforcing a separate 'init' process in every container.
>> The root of the process tree in a namespace has to be the child reaper
>> for that namespace meaning that
>> 
>> - it is immune to signals, ptracing, etc. from within the pidspace
>> - every process in the pidspace is reparented to it once that process'
>>   parent dies
>> - when it dies the whole pidspace is termiated
>
> That's how i feel also.

Those sound like the correct semantics.  Although terminating all of
it's children in a given pid namespace is an interesting semantic to
implement.  But it seems to be the only sane one.   At least it
is better then the current version where the kernel exits if pid == 1
is terminated.

> The key point here is that the process becoming the init of that pidspace
> is immune to sigchlg : ignores them or garbage collects them or handles EINTR.
>
> If we feel confortable with the above, let's bring back this question to a
>  user space issue : the process doing an unshare of this pidspace must
> handle the sigchld one way or the other.

Sounds good.

I'm not convinced an unshare of a pid namespace is a well defined
operation.  But creating a new pid namespace at clone time certainly
is, and that is what replicates the python example.

Eric
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers

Hello,

Roman Kagan wrote:

[ ... ]

>> As for the per-container init process, the alternative to always
>> enforcing a separate init process for every container is to allow an
>> option of making the process which did the pidspace unshare (or is it
>> the parent of that process) masquerade as (pidspace=new_container, pid=1).
> 
> There's no point enforcing a separate 'init' process in every container.
> The root of the process tree in a namespace has to be the child reaper
> for that namespace meaning that
> 
> - it is immune to signals, ptracing, etc. from within the pidspace
> - every process in the pidspace is reparented to it once that process'
>   parent dies
> - when it dies the whole pidspace is termiated

That's how i feel also.

The key point here is that the process becoming the init of that pidspace
is immune to sigchlg : ignores them or garbage collects them or handles EINTR.

If we feel confortable with the above, let's bring back this question to a
 user space issue : the process doing an unshare of this pidspace must
handle the sigchld one way or the other.

> These are the standard properties of pid == 1 in UNIX.  If it happens to
> be (or execs) /sbin/init then indeed it'll sit in the background
> spawning the usual user processes when necessary, but it doesn't have to
> be.  E.g. I've just run an FC5 machine with init=/usr/bin/python which
> is how your application container would probably look like (the result
> of 'import os; os.system("ps axf")' in python prompt):
> 
>   PID TTY      STAT   TIME COMMAND
>     1 ?        S      0:00 /usr/bin/python
>     2 ?        SN     0:00 [ksoftirqd/0]
>     3 ?        S      0:00 [watchdog/0]
>     4 ?        S<     0:00 [events/0]
>     5 ?        S<     0:00 [khelper]
>     6 ?        S<     0:00 [kthread]
>     8 ?        S<     0:00  \_ [kblockd/0]
>     9 ?        S<     0:00  \_ [kacpid]
>    67 ?        S<     0:00  \_ [khubd]
>   122 ?        S      0:00  \_ [pdflush]
>   123 ?        S      0:00  \_ [pdflush]
>   125 ?        S<     0:00  \_ [aio/0]
>   212 ?        S<     0:00  \_ [kseriod]
>   282 ?        S<     0:00  \_ [kpsmoused]
>   303 ?        S<     0:00  \_ [scsi_eh_0]
>   124 ?        S      0:00 [kswapd0]
>   290 ?        Ss     0:00 /bin/nash /init
>   317 ?        S      0:00 [kjournald]
>   329 ?        R      0:00 sh -c ps axf
>   330 ?        R      0:00  \_ ps axf

yes

> so there's no fundamental difference between "system containers" and
> "application containers".

your example uses python which has a wait() loop sitting somewhere because
it needs to know how to handle processes, like any shell command
interpreter. but yes, it's something like this, with a process 1 knowing
how to handle sigchld.

thanks,

C.

_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers