Sukadev Bhattiprolu <sukadev@xxxxxxxxxxxxxxxxxx> writes: > Daniel Lezcano [daniel.lezcano@xxxxxxx] 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@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers