receiving SIGHCHLD if job control is disabled - expected behavior?
Hello, The code in question is set +m echo $BASH_VERSION echo $SHELLOPTS trap 'echo =SIGCHLD=' 18 sleep 1 echo done Bash 5 output: 5.0.17(1)-release braceexpand:hashall:interactive-comments =SIGCHLD= done Bash 4 output: 4.4.19(1)-release braceexpand:hashall:interactive-comments done I was trying to find a relevant note in changelog and I found this in CHANGES: n. The SIGCHLD trap is run once for each exiting child process even if job control is not enabled when the shell is in Posix mode. and this in CWRU/changelog: - waitchld: run SIGCHLD trap for each child exited even if job control is not enabled when in Posix mode. Prompted by an austin-group-l discussion I was trying to find the discussion and the closest thing I found was https://www.mail-archive.com/austin-group-l@opengroup.org/msg00898.html As a side note, another interesting bit I found is that if I replace the 'sleep 1' with 'read' I will not get SIGCHLD in bash 5. My understanding is that this is intentional change, but I would like to kindly ask if you could confirm it. Thank you -- Vlad
Re: receiving SIGHCHLD if job control is disabled - expected behavior?
On 10/1/21 4:24 AM, Vladimir Marek wrote: Hello, The code in question is set +m echo $BASH_VERSION echo $SHELLOPTS trap 'echo =SIGCHLD=' 18 sleep 1 echo done Bash 5 output: 5.0.17(1)-release braceexpand:hashall:interactive-comments =SIGCHLD= done Bash 4 output: 4.4.19(1)-release braceexpand:hashall:interactive-comments done I was trying to find a relevant note in changelog and I found this in CHANGES: n. The SIGCHLD trap is run once for each exiting child process even if job control is not enabled when the shell is in Posix mode. and this in CWRU/changelog: - waitchld: run SIGCHLD trap for each child exited even if job control is not enabled when in Posix mode. Prompted by an austin-group-l discussion I was trying to find the discussion and the closest thing I found was https://www.mail-archive.com/austin-group-l@opengroup.org/msg00898.html That's the one. A SIGCHLD is generated when a child process dies, whether or not the shell currently has job control active, since monitor mode is basically about process groups. You can trap any signal, including SIGCHLD, so why not make it as reliable as you can? It's useful to be able to guarantee that you'll get a SIGCHLD trap for each child exiting, to do exactly the sort of counting that was the subject of that discussion, so I made that work whether or not monitor mode is enabled. The documentation, even though it talks about this feature in the JOB CONTROL section, never made any distinction. As a side note, another interesting bit I found is that if I replace the 'sleep 1' with 'read' I will not get SIGCHLD in bash 5. Well, of course (?). `read' is a builtin, no child process is created, and so the shell doesn't get a SIGCHLD. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: EXIT trap is not executed after an exec failure in a non-interactive shell
On 9/30/21 7:24 PM, Mark March wrote: If execfail is set, a failed exec does not cause a non-interactive shell to exit, but it seems to reset the EXIT trap: Yes. When the shell runs `exec', it assumes the execed program will overlay the shell process. To make that happen transparently, it has to undo things it has done: it ends job control and restores the original process groups, it restores the signal dispositions that it got from its parent, and it clears other shell state like the EXIT trap. If the exec fails, it tries to restore some things as well as it can, but it doesn't try to restore any traps. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [External] : Re: receiving SIGHCHLD if job control is disabled - expected behavior?
On Fri, Oct 01, 2021 at 09:39:50AM -0400, Chet Ramey wrote: > On 10/1/21 4:24 AM, Vladimir Marek wrote: > > Hello, > > > > The code in question is > > > > set +m > > echo $BASH_VERSION > > echo $SHELLOPTS > > trap 'echo =SIGCHLD=' 18 > > sleep 1 > > echo done > > > > > > Bash 5 output: > > 5.0.17(1)-release > > braceexpand:hashall:interactive-comments > > =SIGCHLD= > > done > > > > > > Bash 4 output: > > 4.4.19(1)-release > > braceexpand:hashall:interactive-comments > > done > > > > > > > > I was trying to find a relevant note in changelog and I found this in > > CHANGES: > > > > n. The SIGCHLD trap is run once for each exiting child process even if job > > control is not enabled when the shell is in Posix mode. > > > > and this in CWRU/changelog: > > > > - waitchld: run SIGCHLD trap for each child exited even if job > > control > >is not enabled when in Posix mode. Prompted by an austin-group-l > >discussion > > > > I was trying to find the discussion and the closest thing I found was > > > > https://urldefense.com/v3/__https://www.mail-archive.com/austin-group-l@opengroup.org/msg00898.html__;!!ACWV5N9M2RV99hQ!armiksAJmuzyNkkBHbfa18QJRpAVznB58TP1DqCZ76ejwxGwRLeLm3yLz4VknKozRUA$ > > That's the one. > > A SIGCHLD is generated when a child process dies, whether or not the shell > currently has job control active, since monitor mode is basically about > process groups. You can trap any signal, including SIGCHLD, so why not > make it as reliable as you can? > > It's useful to be able to guarantee that you'll get a SIGCHLD trap for > each child exiting, to do exactly the sort of counting that was the subject > of that discussion, so I made that work whether or not monitor mode is > enabled. > > The documentation, even though it talks about this feature in the JOB > CONTROL section, never made any distinction. Thank you, that makes sense. > > As a side note, another interesting bit I found is that if I replace the > > 'sleep 1' with 'read' I will not get SIGCHLD in bash 5. > > Well, of course (?). `read' is a builtin, no child process is created, and > so the shell doesn't get a SIGCHLD. Ah, of course :) Thank you -- Vlad
Re: EXIT trap is not executed after an exec failure in a non-interactive shell
Date:Fri, 1 Oct 2021 09:59:44 -0400 From:Chet Ramey Message-ID: | Yes. When the shell runs `exec', it assumes the execed program will overlay | the shell process. To make that happen transparently, it has to undo things | it has done: it ends job control and restores the original process groups, | it restores the signal dispositions that it got from its parent, All that is reasonable, but | and it clears other shell state like the EXIT trap. this looks like a bug to me, and pointless anyway. If the exec succeeds there is no more shell, so its state no longer exists, cleared or not, so in that case, clearing it was just wasting time. If the exec fails, all the rest can easily be undone, but unless it was saved elsewhere (which would be bizarre indeed) shell state that's been cleared cannot be recovered. That is, signals should be restored, traps should be left alone - and then if the shell is not simply going to exit when the exec fails, the traps indicate how the signals should be restored. Is the jobs table part of the shell state that is cleared? If so, and the shell isn't exiting, that sounds like a real problem. If it isn't, what's the distinction (apart from needing an internal routine to restore signals ignoring the trap settings, which is just code). How about shell variables, are all of those "cleared" too? kre
Re: EXIT trap is not executed after an exec failure in a non-interactive shell
Ok, thank you for clarifying. There is nothing in the documentation about this behavior as far as I can tell. I would suggest adding a line about traps getting reset after a failed exec to the paragraph on 'execfail'. -Mark On Friday, October 1, 2021, 07:02:34 AM PDT, Chet Ramey wrote: On 9/30/21 7:24 PM, Mark March wrote: > If execfail is set, a failed exec does not cause a non-interactive shell to > exit, but it seems to reset the EXIT trap: Yes. When the shell runs `exec', it assumes the execed program will overlay the shell process. To make that happen transparently, it has to undo things it has done: it ends job control and restores the original process groups, it restores the signal dispositions that it got from its parent, and it clears other shell state like the EXIT trap. If the exec fails, it tries to restore some things as well as it can, but it doesn't try to restore any traps. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
