Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Isaac To <isaac.to@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: Signal ignore flags unexpectedly reset after "trap ... EXIT"
Date: Fri, 18 Oct 2019 22:49:32 +0800
Lines: 167
Approved: bug-bash@gnu.org
Message-ID: <mailman.1105.1571410194.9715.bug-bash@gnu.org>
References: <CAOArY3X4VXAkmoCh0vsRZuHsJpw=jOF4_uLocsap1bG+QpK1iQ@mail.gmail.com> <CAOArY3WqmFFT4K4J2uzaEuS3ZcdZ69fwWV5Yj0WcHfr5TAm_qQ@mail.gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
In-Reply-To: <CAOArY3X4VXAkmoCh0vsRZuHsJpw=jOF4_uLocsap1bG+QpK1iQ@mail.gmail.com>
Precedence: list
Xref: csiph.com gnu.bash.bug:15518

Dear Chet,

I read your reply in the mailing list archive.  Thanks a lot for the
explanation, I get much better ideas about what the shell wants to do for
me after reading it.  Sorry that I have to reply to my own message rather
than yours.  I'll subscribe to the mailing list to ensure that this is not
needed any more.

Reading your response carefully I think you get most of the things you say
you didn't get.  For others, I want to add one comment:

> trap '' USR1
> > grep SigIgn /proc/$BASHPID/status
>
> Presumably this reflects it; I don't know how to interpret the output.
>

This is a bitmask containing ignored signals, where signal n is represented
by value (1 << (n - 1)).  The 200 is signal 10, i.e., USR1.

Then I want to explain what I consider a bug:

> (
> >     echo subshell $BASHPID
> >     grep SigIgn /proc/$BASHPID/status
>
> After setting all the caught signals back to SIG_DFL, this shell, call it
> pid 811, sets SIGUSR1 to SIG_IGN, since that is the disposition it had when
> its parent was started. This happens before pretty much anything else.
> ...
> Let's say this process has pid 813. In this subshell, there shouldn't be
> any ignored signals after the shell initializes (it's interactive), but it
> does this lazily.
>

If it should be set to SIG_DFL once anything about signals have to be done,
why it even attempt to reset it to SIG_IGN after the subshell initialize?
And, I cannot say that bringing an ignored signal back alive in the name of
"exit handling" is a "correct behavior"...


> I get exactly the same results in bash-4.4 running on RHEL7.
>

I'd like to confirm your results: when I run it once again in my Ubuntu 18
with bash 4.4 I see the same results.  After reading your messages I can do
simpler checks of the behaviour.  First, I test 3 different versions of
bash by running:

   - A: Ubuntu 19.04, bash 5.0.3(1)-release
   - B: Debian 4.9.189-3, bash 4.4.12(1)-release (Same results on 4.4.20 of
   Ubuntu 18.04.3)
   - C: CentOS Linux release 7.7.1908, bash 4.2.46(2)-release

Here are the tests:

$ trap '' USR1
$ (trap true EXIT; grep Ign /proc/$BASHPID/status)

I see:

A: SigIgn: 0000000000000200
B: SigIgn: 0000000000000200
C: SigIgn: 0000000000000200

So it is not that within subshells of interactive shells, once you trap
EXIT you get the signal handler reset.  In all the above cases it didn't
happen.

Then I test it by running:

$ trap '' USR1
$ (trap true EXIT; (grep Ign /proc/$BASHPID/status) )

For this, I get:

A: SigIgn: 0000000000000200
B: SigIgn: 0000000000000200
C: SigIgn: 0000000000000000

This is the actual reason why I have my complex test case in the previous
mail: in my deployment there is an error, and I go back to a convenient
machine running like (C) and try to reproduce it.  I suddenly end up with
something that causes an error.

Then here is what is inspired by your reply:

$ trap '' USR1
$ bash
$ (trap true EXIT; grep Ign /proc/$BASHPID/status)

For this:

A: SigIgn: 0000000000000000
B: SigIgn: 0000000000000000
C: SigIgn: 0000000000000200

This is the behaviour I was reporting.  The thing is, the behaviour is
undocumented, and even if you want to document it you don't know how to do
so.

On Tue, Oct 15, 2019 at 5:22 PM Isaac To <isaac.to@gmail.com> wrote:

> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2
> -fdebug-prefix-map=/build/bash-LQgi2O/bash-5.0=. -fstack-protector-strong
> -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security
> uname output: Linux superposition 5.0.0-25-generic #26-Ubuntu SMP Thu Aug
> 1 12:04:58 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 5.0
> Patch Level: 3
> Release Status: release
>
> Description:
>
> When trying to write a program and start it in an initrc script, I
> observed a strange behavior: if a subshell is started by a subshell of that
> script, and the inner subshell runs "trap ... EXIT", it unsets the signal
> ignore flag of other signals.  I'm not sure whether this should be called a
> bug, or whether it is a problem caused by my own configuration.  Anyway
> here is how I reproduce my problem.
>
> Repeat-By:
>
> $ cat t.sh
> echo t $BASHPID
> trap '' USR1
> grep SigIgn /proc/$BASHPID/status
> bash --rcfile t2.sh
> $ cat t2.sh
> echo t2 $BASHPID
> grep SigIgn /proc/$BASHPID/status
> (
>     echo subshell $BASHPID
>     grep SigIgn /proc/$BASHPID/status
>     (
>         echo subsubshell $BASHPID
>         grep SigIgn /proc/$BASHPID/status
>         echo trap $BASHPID
>         trap 'echo hello' EXIT
>         grep SigIgn /proc/$BASHPID/status
>     )
> )
> $ ./t.sh
> t 15141
> SigIgn: 0000000000000204
> t2 15143
> SigIgn: 0000000000380004
> subshell 15145
> SigIgn: 0000000000000200
> subsubshell 15147
> SigIgn: 0000000000000200
> trap 15147
> SigIgn: 0000000000000000
> hello
> $
>
> Note that the final SigIgn flag is completely reset, which is what I won't
> expect.  The same problem won't occur if --rcfile is not used in t.sh.  And
> the problem also didn't show up in bash 4.4.
>
>