Re: SIGTERM ignored before exec race
On 02/18/2013 02:39 AM, Chet Ramey wrote: > On 2/17/13 7:46 PM, Pádraig Brady wrote: > I notice the following will wait for 5 seconds for the timeout process to end with SIGALRM, rather than immediately due to kill sending the SIGTERM. >>> >>> I think the way to approach this is to change the SIGTERM handling from >>> straight SIG_IGN to a handler installed with SA_RESTART that catches the >>> signal but does nothing with it. >>> >>> That will allow the shell to note whether it receives a SIGTERM between >>> fork and exec and react accordingly. >> >> Thanks for continuing to look at this. >> Just in case you need to consider other options, >> elaborating a bit on my previous suggestion: > > I looked at this, and it ended up being a little more complicated and a > little less flexible than the approach I adopted. > >> Your suggested method I think is to have a handler something like >> the following which should work too, but perhaps with the caveat >> that the exit status of the child before the exec might not have >> the signal bit set. > > No, much simpler. The signal handler just sets a flag. It's only > installed by interactive shells, so the flag never changes in any other > shell. Setting the flag to 0 at appropriate times and checking for > non-zero values at appropriate times is all that's needed. If a child > process finds the flag non-zero, it calls the usual terminating signal > handler, which ends up killing the shell with the same signal. I've confirmed that bash 4.3 alpha doesn't have the issue. Well I can't reproduce easily at least. I didn't notice a NEWS item corresponding to it though. If I wanted to inspect this code change what would be the best approach? thanks, Pádraig.
Re: SIGTERM ignored before exec race
On 3/25/13 10:34 AM, Pádraig Brady wrote: > I've confirmed that bash 4.3 alpha doesn't have the issue. > Well I can't reproduce easily at least. > I didn't notice a NEWS item corresponding to it though. It's not a new feature. There are several items in CHANGES that refer to reworked signal handling. > If I wanted to inspect this code change what would be the best approach? Look for RESET_SIGTERM and CHECK_SIGTERM in the source code (jobs.c and execute_cmd.c, mostly) and trace the code back through quit.h to sig.c. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: SIGTERM ignored before exec race
On 03/25/2013 02:55 PM, Chet Ramey wrote:
> On 3/25/13 10:34 AM, Pádraig Brady wrote:
>
>> I've confirmed that bash 4.3 alpha doesn't have the issue.
>> Well I can't reproduce easily at least.
>> I didn't notice a NEWS item corresponding to it though.
>
> It's not a new feature. There are several items in CHANGES that refer to
> reworked signal handling.
>
>> If I wanted to inspect this code change what would be the best approach?
>
> Look for RESET_SIGTERM and CHECK_SIGTERM in the source code (jobs.c and
> execute_cmd.c, mostly) and trace the code back through quit.h to sig.c.
OK thanks for the pointer.
So the race is narrowed rather than closed?
As we have:
execute_disk_command()
{
int pid = fork();
if (pid == 0) /* child */
{
CHECK_SIGTERM; /* Honor received SIGTERM. */
do stuff;
CHECK_SIGTERM; /* Honor received SIGTERM. */
/* --->SIGTERM still ignored if received here?<--- */
exec(...);
}
thanks,
Pádraig.
"typeset +x var" to a variable exported to a function doesn't remove it from the environment.
Hello,
$ function f { typeset +x x; typeset x=123; echo "$x"; sh -c 'echo "$x"';
}; x=abc f
123
abc
$ echo "$BASH_VERSION"
4.2.45(1)-release
This is inconsistent with a variable defined and exported any other way.
(ksh93/mksh/zsh don't have this issue. Dash doesn't actually export the
variable to the environment in this case, but just "localizes" it, and requires
a separate export.)
--
Dan Douglas
Assignments preceding "declare" affect brace and pathname expansion.
Hi,
$ set -x; foo=bar declare arr=( {1..10} )
+ foo=bar
+ declare 'a=(1)' 'a=(2)' 'a=(3)' 'a=(4)' 'a=(5)'
$ touch xy=foo
$ declare x[y]=*
+ declare 'x[y]=*'
$ foo=bar declare x[y]=*
+ foo=bar
+ declare xy=foo
This isn't the same bug as the earlier a=([n]=*) issue. Each word (the entire
assignment) is subject to globbing. "let", "eval", and possibly other builtins
appear to randomly use this same kind of expansion regardless of whether they
are preceded by an assignment, though I can't think of any uses for it.
Arguments in this case are treated neither as ordinary assignments
nor ordinary expansions.
--
Dan Douglas
A few possible process substitution issues
Hello,
1. Process substitution within array indices.
The difference between (( 1<(2) )) and (( a[1<(2)] )) might be seen as
surprising.
Zsh and ksh don't do this in any arithmetic context AFAICT.
Fun stuff:
# print "moo"
dev=fd=1 _[1<(echo moo >&2)]=
# Fork bomb
${dev[${dev='dev[1>(${dev[dev]})]'}]}
2. EXIT trap doesn't fire when leaving a process substitution.
$ ksh -c '[[ -n $(< <(trap "tee /dev/fd/3" EXIT)) ]] 3>&1 <<&1 <<&1 <<&2); } 2>&1; wait $!; printf 2; }
| cat; echo'
12
$ bash -c '{ { : <(sleep 1; printf 1 >&2); } 2>&1; wait $!; printf 2; }
| cat; echo'
bash: wait: pid 9027 is not a child of this shell
21
At least, this is a confusing error, because that actually is a direct child
of the shell that runs the wait. Process substitutions do set $! in Bash, not
in Zsh.
--
Dan Douglas
