| |||||||||||||
Namespaces in operation, part 4: more on PID namespacesNamespaces in operation, part 4: more on PID namespacesPosted Jan 25, 2013 10:27 UTC (Fri) by andresfreund (subscriber, #69562)In reply to: Namespaces in operation, part 4: more on PID namespaces by sorokin Parent article: Namespaces in operation, part 4: more on PID namespaces
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?
(Log in to post comments)
Namespaces in operation, part 4: more on PID namespaces Posted Jan 25, 2013 10:35 UTC (Fri) by mpr22 (subscriber, #60784) [Link] 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.
|
|||||||||||||