[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bash-bug
Subject:    Re: Strange behaviour when sending SIGTERM to bash
From:       Chet Ramey <chet.ramey () case ! edu>
Date:       2018-03-29 15:29:12
Message-ID: 0945aea2-6a7c-b609-4692-82269bb68448 () case ! edu
[Download RAW message or body]

On 3/28/18 12:52 PM, Martin Schulte wrote:
> Hello,
> 
> I'm running bash under Debian Stretch:
> 
> $ echo $BASH_VERSION 
> 4.4.12(1)-release
> $ trap
> $ echo $$
> 1100
> $ kill 1100
> $ 
> 
> => Looks fine for me
> 
> Then I do a
> 
> kill 1100
> 
> from another session and the bash above terminates.
> 
> => Looks wrong for me

It's readline. The difference between your two cases is that in the second
one, readline gets the signal, and it interrupts the read. Readline handles
the signal, calls the bash signal handler (which does nothing but set a
flag and return), and returns a read error. You really have to return the
error so the signal gets handled properly -- all the signal handler is
allowed to do is to set a flag, and that's all the readline and bash signal
handlers do.

The idea is that terminal emulators (at least in 2011) send SIGTERM or
SIGHUP when you use the close button, and unless readline returns an error,
you get processes looping on a stream of read(2) returning EINTR or EIO.

There is a related discussion beginning at

http://lists.gnu.org/archive/html/bug-bash/2011-03/msg00054.html

Chet
-- 
``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/


[prev in list] [next in list] [prev in thread] [next in thread]