Re: SIGINT handling during async functions

[Robert Elz]

    Date:        Fri, 13 Jan 2023 08:29:25 +0100
    From:        Tycho Kirchner <tychokirchner@mail.de>
    Message-ID:  <6df2fd46-18e8-775d-a670-bd29ffdf3e11@mail.de>

  | However, did you actually actually put the short snippets into a script,

No, I didn't, and now I have, I see what you mean, bash does look to
be doing something wrong wrt the state of the signals in the subshell
it forks (sometimes).   That's weird.

  | ______________________________________
  | bash -c 'echo first; trap -p' & wait
  | { bash -c 'echo second; trap -p'; } & wait
  | { trap -p >/dev/null; bash -c 'echo third; trap -p'; } & wait
  | ______________________________________

  | $ ./test.sh
  | first
  | trap -- '' SIGINT
  | trap -- '' SIGQUIT

In that case, you're running bash -c asynchronously (in the background),
so SIGINT and SIGQUIT are ignored, the child bash starts in that environment,
the trap -p shows that those signals remain ignored, all is behaving as it
should.

  | second

But that one is wrong, running the same thing, inside a group, should
change nothing at all.   The group (if it is actually run at all, since
it contains only one command in this case, it could simply be optimised
away, which would produce identical code to execute as the first case,
though that's not required) is run as a subshell (async), which means it
(the subshell created) should have SIGINT and SIGQUIT ignored, just the
same as in the first case.  Nothing should be changing that when
that group invokes bash -c, so those signals should be remaining ignored
when that process is invoked (that it happens to be another instance of
bash is irrelevant for that), so that bash should start in the same state
as the one in the first test.   Yet it clearly doesn't.

Note that it is the bash running the script that is doing odd things, not
the "bash -c" invoked within it.   Run the script with a different shell
(bosh, zsh, ksh93, dash, the FreeBSD and NetBSD shells) and everything
acts the same (the script still running "bash -c ...") for all 3 tests
(though some shells require removing the '-p' arg to trap in the 3rd case,
at least in the versions I have, as they do not (yet, in the versions I
have anyway) support "trap -p".   That changes nothing when the script is
run with bash, (using just "trap" there instead of "trap -p") so I mostly
left it that way.    [Aside: bosh also ignores SIGTTIN in an async command
(when job control is disabled) which is probably a good idea, but isn't
required by anything, but that difference is irrelevant here - it ignores
it in all 3 cases, along with SIGINT and SIGQUIT]

  | third
  | trap -- '' SIGINT

And that one is even stranger.   For some reason in this case, when invoked
(the trap -p sending its results to /dev/null in your script is actually
writing that same output - only SIGINT is being ignored there, which explains
why only SIGINT is ignored inside the "bash -c" though why having a trap
command there is making that kind of difference (it does mean that the
group cannot simply be optimised away however), apparently causing only SIGINT
to be ignored (since it wasn't in the 2nd case, though both it and SIGQUIT
should have been) I can't guess.

You're quite correct, this is all badly broken.   And note, it has been
broken (just not quite the same way) for a very long time:

jacaranda$ bash2 /tmp/test.sh
first
trap -- '' SIGINT
trap -- '' SIGQUIT
second
third

That's different, but still broken, but actually better than bash 5,
since at least the results from the 2nd and 3rd tests are the same, the
added trap command in the 3rd test is changing nothing  (In all cases,
for all tests, the "bash -c" invoked inside the script is bash5 - but
since that simple code is doing exactly what it should, that's irrelevant,
that could be replaced by any shell that supports "trap -p").

  | So, even in this simple case, differences are observable.

Yes, they are.   Apologies for my hasty response, I was concentrating on
the wrong issues (as some kind of explanation - it was the early hours of
the morning, for me, I should have been asleep, but I just had to read mail
one more time...)

And just for the record, I'm running bash 5.2.15(1)-release on NetBSD 10.99.1
(amd64 processor - or x86_64 if you prefer - same as yours, just different OS).

The bash2 I ran was 2.05b.0(1)-release

kre