Re: Change in SIGTERM behaviour in bash 4.3 when using readline

From	Chet Ramey <chet.ramey@case.edu>
Newsgroups	gnu.bash.bug
Subject	Re: Change in SIGTERM behaviour in bash 4.3 when using readline
Date	2020-03-04 15:43 -0500
Message-ID	<mailman.2051.1583354622.2412.bug-bash@gnu.org> (permalink)
References	<20200304181824.GA394387@chrisdown.name> <20200304192918.GB394387@chrisdown.name> <20200304193834.GC394387@chrisdown.name> <564361ee-9f98-adca-ccfe-97c8ed11ff2a@case.edu>

Show all headers | View raw

On 3/4/20 2:38 PM, Chris Down wrote:
> Chris Down writes:
>> I'm not quite sure how best to handle this, maybe setting SIG_IGN as the
>> default signal handler for interactive shells if there's nothing to
>> inherit? This is one of those cases where SA_RESTART doesn't quite mimic
>> SIG_IGN...
> 
> This seems too simple, so I assume it's going to cause other problems, but:
> 
> ---
>  jobs.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/jobs.c b/jobs.c
> index e157c38f..a57b7082 100644
> --- a/jobs.c
> +++ b/jobs.c
> @@ -4584,6 +4584,7 @@ initialize_job_signals ()
>    if (interactive)
>      {
>        set_signal_handler (SIGINT, sigint_sighandler);
> +      set_signal_handler (SIGTERM, SIG_IGN);

This is how the code used to read, before I added the do-nothing signal
handler as a result of

https://lists.gnu.org/archive/html/bug-bash/2013-02/msg00020.html

There is another way to do it by blocking signals, and a comment in the
code indicates that I considered using it for SIGTERM at the time.

Ignoring the signal is what caused the race condition in the first place.

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

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: Change in SIGTERM behaviour in bash 4.3 when using readline Chet Ramey <chet.ramey@case.edu> - 2020-03-04 15:43 -0500

csiph-web