[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Signal ignore flags unexpectedly reset after "trap ... EXIT"
From: |
Isaac To |
Subject: |
Re: Signal ignore flags unexpectedly reset after "trap ... EXIT" |
Date: |
Fri, 18 Oct 2019 22:49:32 +0800 |
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.
>
>