Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #15948

Re: "wait" loses signals

Path csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From Denys Vlasenko <dvlasenk@redhat.com>
Newsgroups gnu.bash.bug
Subject Re: "wait" loses signals
Date Fri, 21 Feb 2020 15:44:37 +0100
Lines 53
Approved bug-bash@gnu.org
Message-ID <mailman.1363.1582296292.2412.bug-bash@gnu.org> (permalink)
References <750d460d-b8a4-4157-1488-9f4d9f973715@redhat.com> <35034c85-fd5a-5034-a2d5-e3903888069d@case.edu> <cf7adbec-e705-1071-34e1-50f8188f0edc@redhat.com> <d60f1dbc-990d-7291-e075-b67c07f61a86@case.edu> <00620c20-19ea-e71e-dc1b-926847901f82@redhat.com>
NNTP-Posting-Host lists.gnu.org
Mime-Version 1.0
Content-Type text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding 7bit
X-Trace usenet.stanford.edu 1582296292 740 209.51.188.17 (21 Feb 2020 14:44:52 GMT)
X-Complaints-To action@cs.stanford.edu
Cc Harald van Dijk <harald@gigawatt.nl>
To chet.ramey@case.edu, bug-bash@gnu.org
Envelope-to bug-bash@gnu.org
DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582296285; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EmDODuqE5i6oW/O02kb12H4R5eERTzt05p+CuutKbbU=; b=aX8MOoCZDps71bLmHI8bQ+RZc8P0rI32VgKJlFyLn8YSfDZeVyg771x1R9TTzHTTAL8vAL 2vCiQvl4RWIKiEEWB6akoSDXNj2NztX4IIuyjP7cPOWQcwJ0uHq9guB68Z9B+vDomSx7oL Sefmg/be6783X1Ssb9CyNSVcN0IqjSM=
X-MC-Unique A7cUg2aPMnODI9sz-LnD1A-1
User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
In-Reply-To <d60f1dbc-990d-7291-e075-b67c07f61a86@case.edu>
Content-Language en-US
X-Scanned-By MIMEDefang 2.79 on 10.5.11.16
X-Mimecast-Spam-Score 0
X-Mimecast-Originator redhat.com
X-detected-operating-system by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From 205.139.110.120
X-BeenThere bug-bash@gnu.org
X-Mailman-Version 2.1.23
Precedence list
List-Id Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive <https://lists.gnu.org/archive/html/bug-bash>
List-Post <mailto:bug-bash@gnu.org>
List-Help <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
X-Mailman-Original-Message-ID <00620c20-19ea-e71e-dc1b-926847901f82@redhat.com>
X-Mailman-Original-References <750d460d-b8a4-4157-1488-9f4d9f973715@redhat.com> <35034c85-fd5a-5034-a2d5-e3903888069d@case.edu> <cf7adbec-e705-1071-34e1-50f8188f0edc@redhat.com> <d60f1dbc-990d-7291-e075-b67c07f61a86@case.edu>
Xref csiph.com gnu.bash.bug:15948

Show key headers only | View raw


On 2/20/20 4:27 PM, Chet Ramey wrote:
> On 2/20/20 3:02 AM, Denys Vlasenko wrote:
>> On 2/19/20 9:30 PM, Chet Ramey wrote:
>>> On 2/19/20 5:29 AM, Denys Vlasenko wrote:
>>>> A bug report from Harald van Dijk:
>>>>
>>>> test2.sh:
>>>> trap 'kill $!; exit' TERM
>>>> { kill $$; exec sleep 9; } &
>>>> wait $!
>>>>
>>>> The above script ought exit quickly, and not leave a stray
>>>> "sleep" child:
>>>> (1) if "kill $$" signal is delivered before "wait",
>>>> then TERM trap will kill the child, and exit.
>>>
>>> This strikes me as a shaky assumption, dependent on when the shell receives
>>> the SIGTERM and when it runs traps.
>>
>> The undisputable fact is that after shell forks a child
>> to run the "{...} &" subshell, it will receive the SIGTERM signal.
>>
>> And since it has a trap for it, it should be run.
>>
>>> (There's nothing in POSIX that says
>>> when pending traps are processed. Bash runs them after commands.)
>>
>> Yes, and here we are "after command", specifically after "{...} &" command.
>> Since we got a trapped signal, we must run its trap.
> 
> Did you look at the scenario in my message?

What scenario?

As I said, there are just two possibilities:
signal is received before the point when shell checks for received
signals after "{...} &" command;
or signal is received after that point, and thus signal is
considered to be received "inside wait builtin".

In both cases, trap should be run.

> Keep in mind that you can't run the trap out of the signal handler.

Yes, running anything remotely complex out of signal handlers is
a bad idea: signals can arrive somewhere in the middle of stdio, or memory allocation,
or something similarly critical. Reentering one of those can deadlock.

Properly-written programs are careful to record
signal reception in a flag variable, or a pipe, etc,
then return from signal handler, and act on it later, not in a signal handler.

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


Thread

Re: "wait" loses signals Denys Vlasenko <dvlasenk@redhat.com> - 2020-02-21 15:44 +0100

csiph-web