[Devel] Re: pid namespace bug ?

[Ferenc Wagner]

Sukadev Bhattiprolu <sukadev at linux.vnet.ibm.com> writes:

> Daniel Lezcano [daniel.lezcano at free.fr] wrote:
>
>> Ferenc Wagner wrote:
>>
>>> That is, the jailed sleep process could be killed by SIGKILL only, even
>>> though (according to strace) SIGTERM was delivered and it isn't handled
>>> specially.  Why does this happen?
>
> Yes, SIGKILL is the only reliable way to terminate a container-init.
> container-init needs to be immune to signals from within the container
> but be open to receiving signals from parent container.  These requirements
> complicate the implementation of allowing SIGINT/SIGTERM etc to
> container-init from parent container.
>
> Besides a realistic container-init would block such signals, in which case
> the complexity in the kernel could be viewed as unnecessary.

For full-system containers this is acceptable, but for running batch
jobs this may prove problematic.  Is this behaviour documented somewhere?
Is this specific to SIGINT/SIGTERM or are other signals affected as well?
They are used for communication (job control) with the container running
the job.  Such batch jobs are typically run under the supervision of
some kind of "shepherd" process, which acts as "init" for the job
environment; in my case it's the container-init.  It's the reaper or
possible orphaned processes and the same time it communicates with the
job scheduler (outside of the container) via signals.  So I'd consider
at least some kernel complexity necessary for Linux containers becoming
a viable tool for batch job segregation.
-- 
Thanks,
Feri.
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers