On 09/14, Daniel Pittman wrote: > > Oleg Nesterov <oleg@xxxxxxxxxx> writes: > > On 09/13, Cedric Le Goater wrote: > >> Oleg Nesterov wrote: > > [...] > > >> To respect the current init semantic, > > > > The current init semantic is broken in many ways ;) > > Yup. They sure are, but they are pretty set in stone by now. :) > > >> shouldn't we discard any unblockable signal (STOP and KILL) sent by a > >> process to its pid namespace init process ? Then, all other signals > >> should be handled appropriately by the pid namespace init. > > > > Yes, I think you are probably right, this should be enough in > > practice. After all, only root can send the signal to /sbin/init. On > > my machine, /proc/1/status shows that init doesn't have a handler for > > non-ignored SIGUNUSED == 31, though. > > > > But who knows? The kernel promises some guarantees, it is not good to > > break them. Perhaps some strange non-standard environment may suffer. > > In this case "strange non-standard environments" would mean anyone > running the 'upstart' daemon from recent Ubuntu -- it depends on the > current kernel semantics. Just curious, could you tell more? What "current kernel semantics" do you mean? Do you mean that the 'upstart' daemon sends the unhandled signal to init? Oleg. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
