[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] A terminating signal has to complete a bash process

From: Chet Ramey
Subject: Re: [PATCH] A terminating signal has to complete a bash process
Date: Tue, 1 May 2018 10:40:18 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 4/30/18 6:05 PM, Andrei Vagin wrote:
> bash sets a handler for all terminating signals, which saves history,
> executes traps, sets a default signal handler and re-sends the same
> signal to itself. It expects that this signal will kill it.
> Unfortunately it doesn't work in Linux, when a bash script is executed as
> an init process in a pid namespaces, because all signals to the init
> process, what are sent from the current pid namespace, are ignored.
> man 7 pid_namespaces
>   Only signals for which the "init" process has established a signal han‐
>   dler can be sent to the "init" process by  other  members  of  the  PID
>   namespace.   This restriction applies even to privileged processes, and
>   prevents other members of the PID namespace from  accidentally  killing
>   the "init" process.
> Chet Ramey suggested to add a call to exit() after the kill(). This
> patch adds this call for signals, which do not result in a core dump.
> For other signals, a null pointer is dereferenced to get a core file.

What's the value of a core dump from a different signal in this case?

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://tiswww.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]