[Devel] Re: [PATCH 1/3] Signal semantics for /sbin/init

[Oleg Nesterov]

On 09/14, Daniel Pittman wrote:
>
> Oleg Nesterov <oleg at tv-sign.ru> 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 at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers