Eric W. Biederman [ebiederm@xxxxxxxxxxxx] wrote: | I haven't dug in too deep but right now my concern are user space semantics, | I don't want to wind up with something ugly there because we can not change | it later. The one restriction we are imposing is that SIGINT, SIGTERM etc will not currently kill containter-inits. Only SIGKILL will. But that is good point. Maybe we should document that as a limitation we may remove in the future ? i.e. Its not a feature that container-inits should rely on. Like sysV init, container-init should still SIG_IGN all unhandled signals. If they don't, they may break in the future. | | So if we can write a description of what happens to signals to cinit | that is right 100% of the time. Something we can write a test case | for that tests all of the corner cases and it always get the same | results. I am happy. Yes, I believe we can say that SIGKILL/SIGSTOP from parent are always delivered and no fatal signal from same ns is. | | I don't mind dropping signals early as an optimization, but if it | is just an optimization we can't count on it in cinit. Yes, you have a point. It started out as an optimization, but unwanted signals are either ignored or dropped _always_ (or we have a bug). | | So I would rather deliver less and make user space deal with it, | then deliver more cause problems for user space. The user-semantics appear to be clean now. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers