Re: pid namespace bug ?

[Sukadev Bhattiprolu <sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]

Daniel Lezcano [daniel.lezcano-GANU6spQydw@public.gmane.org] wrote:
>> Besides a realistic container-init would block such signals, in which case
>> the complexity in the kernel could be viewed as unnecessary.
>>   
>
> I am not sure it is good to have the pid 1 immune against signals sent  
> from outside of the container.

cinit is only immune to unhandled signals that terminate/stop the cinit.
If a handler is defined for SIGINT, a SIGINT from parent-ns will still be
delivered but a SIGINT from a descendant of cinit will be ignored.

> From the POV of the parent process, the container init is like any other 
> process and it may want to kill it with a signal (for notification or 
> just terminate instead of killing it).
>
> If the container init is a real init pid, these signals will be blocked  
> but if we launch something different, eg a 'sleep', Ctrl+C won't work.  
> eg: lxc-start -n foo sleep 3600 is not interruptible.

Yes it is annoying, but a mysleep.c that defines a handler which exits
on SIGINT/SIGSEGV/SIGTERM/SIGQUIT.., should still work as expected.
(if not, it is a bug).

>
> That's a bit annoying if we need to plug the container with batch  
> managers or use them with HPC jobs.
>
>
>
>