On 3/23/18 4:34 AM, Andrei Vagin wrote:
> On Thu, Mar 22, 2018 at 6:25 PM, Chet Ramey <chet.ra...@case.edu> wrote:
>> On 3/22/18 3:38 PM, Andrei Vagin wrote:
>>
>>> I am thinking how to fix this issue properly. Here are a few points:
>>> * bash should know that signals are ignored if a process is the init
>>> process in a pid namespace.
>>
>> Why should it know this? It's not documented, not portable, and conflicts
>> with the way signals are documented to behave. This is a situation-specific
>> problem.
>
> It is "documented" in many places. For exmaple:
> https://lwn.net/Articles/532748/
I'm glad you put quotes around "documented" before referring to some
random article.
>>> * user and kernel signals (SEGV, SIGFPE, SIGBUS, etc) are handled
>>> differently
>>
>> Fatal signals (signals whose default disposition is to exit the process)
>> are pretty much handled identically.
>
> Let's I try to elaborate what I mean.
Bash handles fatal signals identically. I understand that the Linux kernel
changes signal delivery behavior under certain circumstances.
>>> * bash should not return back from termsig_sighandler(), if it has
>>> sent a signal to itself.
>>
>> That suggests that the easiest way to solve the problem is to add a call
>> to exit() after the kill().
>
> You are right with one exception. We expect that the kernel generates
> a core dump file, if a process was killed by SIGSEGV, SIGBUS, SIGFPE,
> etc.
>
> For these signals, we probably can dereference an invalid pointer
> instead of calling exit().
If you'd like to submit a patch that does that, I'll take a look.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
