On 01/19, Sukadev Bhattiprolu wrote: > > Oleg Nesterov [oleg@xxxxxxxxxx] wrote: > | On 01/17, Sukadev Bhattiprolu wrote: > | > > | > Init processes ignore SIG_DFL signals unless they are from an ancestor > | > namespace. Ensure /proc/pid/status correcly reports these signals. > | > | This is the user-visible change, and I don't really understand why do we > | need it. > > This discussion came up earlier, with Bastian and Roland and my understanding > was that we should fix the SigIgn line in /proc/pid/status - so I had added > a TODO for this patchset. Hmm. I must admit I don't understand what this patch buys us. Admin should know that init is special and can't be killed by the SIG_DFL signal. Now we change the contents if pid/status, and every user-visible change should have a good reason, imho. > | Imho, this patch can confuse the user-space. Why should we report that, > | say, SIGCONT is ignored by the global init? > > But it is ignored right ? Following this logic, we can report that, say, SIG_DFL'ed SIGWINCH is always ignored by any task, not only by init? > Also, if user space looks at the SigIgn line and assumes that SIGKILL or > SIGUSR1 will kill init, user space can still be confused when it doesn't > really kill - no ? yes, but this is oddity is very old. But, otoh, SIGCHLD. There is a huge difference between SIG_IGN and SIG_DFL in that case, why should we hide it? More generally, why should we hide from admin what init does with signals? > So, should I just post separately or drop altogether ? I guess you already see that personally I dislike this patch ;) At least I'd ask you to not mix it with this series. But perhaps I am wrong, I can't "prove" this change is not good, I'd be ready to agree with majority. Oleg. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers