[Top][All Lists]

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

Re: Strange behaviour when sending SIGTERM to bash

From: Chet Ramey
Subject: Re: Strange behaviour when sending SIGTERM to bash
Date: Thu, 29 Mar 2018 11:29:12 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

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


``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]