Namespaces in operation, part 4: more on PID namespaces [LWN.net]

Namespaces in operation, part 4: more on PID namespaces

Posted Jan 25, 2013 10:00 UTC (Fri) by sorokin (guest, #88478)
Parent article: Namespaces in operation, part 4: more on PID namespaces

"The only signals that can be delivered to init are those for which the process has established a signal handler; all other signals are ignored"

Looks like some dirty hack. Why init process can not disable signals itself?

to post comments

Namespaces in operation, part 4: more on PID namespaces

Posted Jan 25, 2013 10:27 UTC (Fri) by andresfreund (subscriber, #69562) [Link] (2 responses)

I can think of three reasons, the first being that establishing the signal handlers takes some time. the second is that the list of signals you know might not be exhaustive, especially some time later. The third I am not sure about and I am too lazy to check the code right now but does that perhaps include signal handlers you can't block yourself?

Namespaces in operation, part 4: more on PID namespaces

Posted Jan 25, 2013 10:35 UTC (Fri) by mpr22 (subscriber, #60784) [Link] (1 responses)

I would hope so. (The easy way to check is to sit in front of a machine you don't mind having crash, and try sending SIGKILL to PID 1.)

Namespaces in operation, part 4: more on PID namespaces

Posted Jan 25, 2013 18:07 UTC (Fri) by ebiederm (subscriber, #35028) [Link]

Yes SIGKILL and SIGSTOP are the biggies.

The reason for ignoring the others is that is the way things have worked for "init" processes as far back in the linux history as I have looked, and maintaining backwards compatibility is important.