bug-bash
[Top][All Lists]
Advanced

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

Re: Racing condition leads to unstable exit code


From: Luiz Angelo Daros de Luca
Subject: Re: Racing condition leads to unstable exit code
Date: Fri, 30 Sep 2016 14:11:32 +0000

Yes, this is the part that I agree. However, this is the other behavior of bash wait (from bash manual)

"When Bash is waiting for an asynchronous command via the wait builtin, the reception of a signal for which a trap has been set will cause the wait builtin to return immediately with an exit status greater than 128, immediately after which the trap is executed."

The behavior is the same for when parent or child receives the signal. When it's the parent process that received it, child might still be running. It simply breaks the logic of wait. In order to wait until the child exits even when signal was received, I need to implement a new wait command (with some hacks) like this (untested):

usr1(){
    got_signal=true
    Do something...
}

wait2() {
while true; do
    got_signal=false
    wait $*
    exitcode=$?
    $got_signal || return $exitcode
}

trap usr1 USR1

( Child stuff... Send USR1 to parent ) &
wait2 $!


Em sex, 30 de set de 2016 09:45, Chet Ramey <address@hidden> escreveu:
On 9/29/16 10:58 PM, Luiz Angelo Daros de Luca wrote:
> No problem! I already workarounded it using pipe as a semaphore. Thanks!
>
> It's there any chance of changing the 128+signal exit code for wait when
> trap is received?
> It might solve some special usecase which I'm not aware. Wait should always
> returns exit code related to the child process, except for 127.

The shell is required to do this, and it's historical shell behavior.  If
a process is killed by signal N, its exit status is 128+N.  That's how
scripts know their children were killed due to a signal.


> The 128+signal behavior is not even mentioned on wait documentation but on
> signal section! If wait returns 129, I don't know wether child died because
> of signal 1 (128+1) or if it is the current instance that received the
> signal instead.

Posix says:

"When the shell is waiting, by means of the wait utility, for asynchronous
commands to complete, the reception of a signal for which a trap has been
set shall cause the wait utility to return immediately with an exit status
>128, immediately after which the trap associated with that signal shall be
taken."

If you want the shell to be insulated from signals that might be sent to
its children, you either have to use job control, which works for the
keyboard-generated signals that go to process groups, or ignore the signal
using trap to be sure you don't receive it.

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

Luiz Angelo Daros de Luca
address@hidden


reply via email to

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