Re: posix command search and execution
On Fri, Nov 10, 2023 at 08:07:31PM -0500, Chet Ramey wrote: > On 11/9/23 11:17 AM, Mike Jonkmans wrote: > > On Thu, Nov 09, 2023 at 10:12:06PM +0700, Robert Elz wrote: > > > > On Ubuntu 22.04 `getconf path' returns /bin:/usr/bin > > and these are symlinked. > Then that's an issue to take up with Debian/Ubuntu, right? If they're > symlinked by the distro, then getconf PATH should only return one of them. Yes, that would be more efficient than a shell checking for symlinks in PATH. I'll try to convince them. -- Regards, Mike Jonkmans
Re: posix command search and execution
On Sat, Nov 11, 2023 at 09:14:41AM +0100, Mike Jonkmans wrote: > On Fri, Nov 10, 2023 at 08:07:31PM -0500, Chet Ramey wrote: > > On 11/9/23 11:17 AM, Mike Jonkmans wrote: > > > On Thu, Nov 09, 2023 at 10:12:06PM +0700, Robert Elz wrote: > > > > > > On Ubuntu 22.04 `getconf path' returns /bin:/usr/bin > > > and these are symlinked. > > Then that's an issue to take up with Debian/Ubuntu, right? If they're > > symlinked by the distro, then getconf PATH should only return one of them. > > Yes, that would be more efficient than a shell checking for symlinks in PATH. > > I'll try to convince them. Good luck with that. The problem with "usrmerge" in Debian is that it's still optional. There are Debian infrastructure systems (virtual machines especially) that don't use it. Therefore, simply changing the static answer in confstr(3) across all Debian systems would be incorrect. They would need to make it check the actual /bin to see whether it's a symbolic link to usr/bin, and give an answer accordingly. It's a lot less work to just leave it as is.
FEATURE REQUEST : shell option to automatically terminate child processes on parent death
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: Linux zinc 6.6.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 08
Nov 2023 16:05:38 + x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.2 Patch
Level: 21
Release Status: release
Description:
Hi,
I would like to suggest a new shell option to ensure child processes are
automatically killed when the parent dies.
Right now, it's already possible to emulate this feature by setting a
trap to kill all child processes on exit (trap "kill 0" EXIT), but
obviously it doesn't work if the process is terminated by a signal that
cannot be caught (like SIGKILL).
On Linux, it can be done by setting the PR_SET_PDEATHSIG flag to
propagate the parent termination signal to the child, regardless of
whether the signal can be caught or not.
The rationale for this feature is that scripts spawning background
processes to listen to various events (udev events, window manager
events, etc) often leave orphan processes behind when terminated forcefully.
I've attached a proof-of-concept patch.diff --git a/builtins/shopt.def b/builtins/shopt.def
index ba97e702..5ecabde4 100644
--- a/builtins/shopt.def
+++ b/builtins/shopt.def
@@ -83,6 +83,7 @@ extern int extended_quote;
extern int check_window_size;
extern int glob_ignore_case, match_ignore_case;
extern int hup_on_exit;
+extern int no_reparent;
extern int xpg_echo;
extern int gnu_error_format;
extern int check_jobs_at_exit;
@@ -247,6 +248,7 @@ static struct {
{ "nocaseglob", &glob_ignore_case, (shopt_set_func_t *)NULL },
{ "nocasematch", &match_ignore_case, (shopt_set_func_t *)NULL },
{ "noexpand_translation", &singlequote_translations, (shopt_set_func_t *)NULL },
+ { "noreparent", &no_reparent, (shopt_set_func_t *)NULL },
{ "nullglob", &allow_null_glob_expansion, (shopt_set_func_t *)NULL },
{ "patsub_replacement", &patsub_replacement, (shopt_set_func_t *)NULL },
#if defined (PROGRAMMABLE_COMPLETION)
@@ -365,6 +367,7 @@ reset_shopt_options ()
glob_star = 0;
gnu_error_format = 0;
hup_on_exit = 0;
+ no_reparent = 0;
inherit_errexit = 0;
interactive_comments = 1;
lastpipe_opt = 0;
diff --git a/jobs.c b/jobs.c
index b96230fa..572e599c 100644
--- a/jobs.c
+++ b/jobs.c
@@ -65,6 +65,8 @@
# include
#endif /* hpux && !TERMIOS_TTY_DRIVER */
+#include
+
#include "bashansi.h"
#include "bashintl.h"
#include "shell.h"
@@ -221,6 +223,8 @@ PROCESS *the_pipeline = (PROCESS *)NULL;
/* If this is non-zero, do job control. */
int job_control = 1;
+int no_reparent = 0;
+
/* Are we running in background? (terminal_pgrp != shell_pgrp) */
int running_in_background = 0;
@@ -2223,6 +2227,9 @@ make_child (command, flags)
/* Restore top-level signal mask, including unblocking SIGTERM */
restore_sigmask ();
+
+ if (no_reparent && prctl(PR_SET_PDEATHSIG, SIGTERM))
+ sys_error("prctl");
if (job_control)
{
Re: posix command search and execution
On Sat, Nov 11, 2023 at 08:31:14AM -0500, Greg Wooledge wrote: > On Sat, Nov 11, 2023 at 09:14:41AM +0100, Mike Jonkmans wrote: > > On Fri, Nov 10, 2023 at 08:07:31PM -0500, Chet Ramey wrote: > > > On 11/9/23 11:17 AM, Mike Jonkmans wrote: > > > > On Thu, Nov 09, 2023 at 10:12:06PM +0700, Robert Elz wrote: > > > > > > > > On Ubuntu 22.04 `getconf path' returns /bin:/usr/bin > > > > and these are symlinked. > > > Then that's an issue to take up with Debian/Ubuntu, right? If they're > > > symlinked by the distro, then getconf PATH should only return one of them. > > > > Yes, that would be more efficient than a shell checking for symlinks in > > PATH. > > > > I'll try to convince them. > > Good luck with that. The problem with "usrmerge" in Debian is that > it's still optional. There are Debian infrastructure systems (virtual > machines especially) that don't use it. Therefore, simply changing > the static answer in confstr(3) across all Debian systems would be > incorrect. They would need to make it check the actual /bin to see > whether it's a symbolic link to usr/bin, and give an answer accordingly. > > It's a lot less work to just leave it as is. Thanks for the warning. I'll leave them alone then. -- Regards, Mike Jonkmans
Re: FEATURE REQUEST : shell option to automatically terminate child processes on parent death
I support this feature. On Sat, Nov 11, 2023, 11:29 AM Corto Beau wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 > uname output: Linux zinc 6.6.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 08 > Nov 2023 16:05:38 + x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.2 Patch > Level: 21 > Release Status: release > > Description: > Hi, > > I would like to suggest a new shell option to ensure child processes are > automatically killed when the parent dies. > > Right now, it's already possible to emulate this feature by setting a > trap to kill all child processes on exit (trap "kill 0" EXIT), but > obviously it doesn't work if the process is terminated by a signal that > cannot be caught (like SIGKILL). > > On Linux, it can be done by setting the PR_SET_PDEATHSIG flag to > propagate the parent termination signal to the child, regardless of > whether the signal can be caught or not. > > The rationale for this feature is that scripts spawning background > processes to listen to various events (udev events, window manager > events, etc) often leave orphan processes behind when terminated > forcefully. > > I've attached a proof-of-concept patch.
Re: FEATURE REQUEST : shell option to automatically terminate child processes on parent death
On Saturday, November 11, 2023, Corto Beau wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 > uname output: Linux zinc 6.6.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 08 Nov > 2023 16:05:38 + x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.2 Patch > Level: 21 > Release Status: release > > Description: > Hi, > > I would like to suggest a new shell option to ensure child processes are > automatically killed when the parent dies. > > Right now, it's already possible to emulate this feature by setting a trap > to kill all child processes on exit (trap "kill 0" EXIT), but obviously it > doesn't work if the process is terminated by a signal that cannot be caught > (like SIGKILL). > > On Linux, it can be done by setting the PR_SET_PDEATHSIG flag to propagate > the parent termination signal to the child, regardless of whether the > signal can be caught or not. > > The rationale for this feature is that scripts spawning background > processes to listen to various events (udev events, window manager events, > etc) often leave orphan processes behind when terminated forcefully. > > I've attached a proof-of-concept patch. I think it'd make more sense to implement this as a loadable builtin. -- Oğuz
Re: FEATURE REQUEST : shell option to automatically terminate child processes on parent death
Do you mean something like a "fork_noreparent" builtin that would call make_child and set PDEATHSIG afterwards, or a "noreparent" builtin that the child would have to call ? I do agree that it wouldn't make sense to implement the later as a shell option, but this particular use of prctl is subject to a race condition that can only be avoided by comparing the PID of the parent before calling fork and after calling prctl (in case the process got reparented before setting PDEATHSIG), because checking for ppid = 1 is not enough on systems like Linux where the process might have been reparented by a subreaper. On 11/11/2023 20:49, Oğuz wrote: On Saturday, November 11, 2023, Corto Beau wrote: Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 uname output: Linux zinc 6.6.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 08 Nov 2023 16:05:38 + x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.2 Patch Level: 21 Release Status: release Description: Hi, I would like to suggest a new shell option to ensure child processes are automatically killed when the parent dies. Right now, it's already possible to emulate this feature by setting a trap to kill all child processes on exit (trap "kill 0" EXIT), but obviously it doesn't work if the process is terminated by a signal that cannot be caught (like SIGKILL). On Linux, it can be done by setting the PR_SET_PDEATHSIG flag to propagate the parent termination signal to the child, regardless of whether the signal can be caught or not. The rationale for this feature is that scripts spawning background processes to listen to various events (udev events, window manager events, etc) often leave orphan processes behind when terminated forcefully. I've attached a proof-of-concept patch. I think it'd make more sense to implement this as a loadable builtin. -- Oğuz
Re: FEATURE REQUEST : shell option to automatically terminate child processes on parent death
I think that a loadable builtin might be overkill for the second case, because one could write a wrapper program to set PDEATHSIG and call execve on the command-line arguments. This way you'd just have to run "noreparent foo" instead of writing a shell function that calls the noreparent builtin and exec into the child afterwards. It wouldn't allow to unset the flag though, but I can't think of a use-case for that. It would also eliminate the need for a "fork_noreparent" builtin because "noreparent foo &" would do just that. On the other hand, the shell option to automatically set PDEATHSIG on all newly created children allows to enable this behavior without prefixing every line with "noreparent". I would understand if this use-case was considered too narrow though. On 11/11/2023 21:32, Corto Beau wrote: Do you mean something like a "fork_noreparent" builtin that would call make_child and set PDEATHSIG afterwards, or a "noreparent" builtin that the child would have to call ? I do agree that it wouldn't make sense to implement the later as a shell option, but this particular use of prctl is subject to a race condition that can only be avoided by comparing the PID of the parent before calling fork and after calling prctl (in case the process got reparented before setting PDEATHSIG), because checking for ppid = 1 is not enough on systems like Linux where the process might have been reparented by a subreaper. On 11/11/2023 20:49, Oğuz wrote: On Saturday, November 11, 2023, Corto Beau wrote: Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 uname output: Linux zinc 6.6.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 08 Nov 2023 16:05:38 + x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.2 Patch Level: 21 Release Status: release Description: Hi, I would like to suggest a new shell option to ensure child processes are automatically killed when the parent dies. Right now, it's already possible to emulate this feature by setting a trap to kill all child processes on exit (trap "kill 0" EXIT), but obviously it doesn't work if the process is terminated by a signal that cannot be caught (like SIGKILL). On Linux, it can be done by setting the PR_SET_PDEATHSIG flag to propagate the parent termination signal to the child, regardless of whether the signal can be caught or not. The rationale for this feature is that scripts spawning background processes to listen to various events (udev events, window manager events, etc) often leave orphan processes behind when terminated forcefully. I've attached a proof-of-concept patch. I think it'd make more sense to implement this as a loadable builtin. -- Oğuz
Bash manual - possible minor formatting issue
Hello, I think there may be a minor formatting issue in the set builtin section of the Bash manual (https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html). In the description of the "x" option, the second "for" in the first sentence is formatted as inline code but I believe it should be formatted as regular text. So instead of "arithmetic `for` commands" I believe it should be "arithmetic for commands" all in regular text. If I am mistaken then please ignore this email. I have also attached a screenshot. [image.png] Regards, Greg
Re: Bash manual - possible minor formatting issue
On Sat, Nov 11, 2023 at 08:05:18PM +, Greg wrote: > Hello, > > I think there may be a minor formatting issue in the set builtin section of > the Bash manual > (https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html). In > the description of the "x" option, the second "for" in the first sentence is > formatted as inline code but I believe it should be formatted as regular text. > > So instead of "arithmetic `for` commands" I believe it should be > "arithmetic for commands" all in regular text. If I am mistaken then please > ignore this email. > > I have also attached a screenshot. > > [image.png] > > Regards, > Greg This is not an error. The "arithmetic `for` command" is a "for" command on the form for (( i=0; i<10; ++i )); do ... done ... as opposed to the "for" command on the form for i in some list; do ... done -- Andreas (Kusalananda) Kähäri Uppsala, Sweden .
Re: FEATURE REQUEST : shell option to automatically terminate child processes on parent death
Except a wrapper program would be subject to the race condition I mentioned in my own message. Sorry for the noise. On 11/11/2023 21:54, Corto Beau wrote: I think that a loadable builtin might be overkill for the second case, because one could write a wrapper program to set PDEATHSIG and call execve on the command-line arguments. This way you'd just have to run "noreparent foo" instead of writing a shell function that calls the noreparent builtin and exec into the child afterwards. It wouldn't allow to unset the flag though, but I can't think of a use-case for that. It would also eliminate the need for a "fork_noreparent" builtin because "noreparent foo &" would do just that. On the other hand, the shell option to automatically set PDEATHSIG on all newly created children allows to enable this behavior without prefixing every line with "noreparent". I would understand if this use-case was considered too narrow though. On 11/11/2023 21:32, Corto Beau wrote: Do you mean something like a "fork_noreparent" builtin that would call make_child and set PDEATHSIG afterwards, or a "noreparent" builtin that the child would have to call ? I do agree that it wouldn't make sense to implement the later as a shell option, but this particular use of prctl is subject to a race condition that can only be avoided by comparing the PID of the parent before calling fork and after calling prctl (in case the process got reparented before setting PDEATHSIG), because checking for ppid = 1 is not enough on systems like Linux where the process might have been reparented by a subreaper. On 11/11/2023 20:49, Oğuz wrote: On Saturday, November 11, 2023, Corto Beau wrote: Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 uname output: Linux zinc 6.6.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 08 Nov 2023 16:05:38 + x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.2 Patch Level: 21 Release Status: release Description: Hi, I would like to suggest a new shell option to ensure child processes are automatically killed when the parent dies. Right now, it's already possible to emulate this feature by setting a trap to kill all child processes on exit (trap "kill 0" EXIT), but obviously it doesn't work if the process is terminated by a signal that cannot be caught (like SIGKILL). On Linux, it can be done by setting the PR_SET_PDEATHSIG flag to propagate the parent termination signal to the child, regardless of whether the signal can be caught or not. The rationale for this feature is that scripts spawning background processes to listen to various events (udev events, window manager events, etc) often leave orphan processes behind when terminated forcefully. I've attached a proof-of-concept patch. I think it'd make more sense to implement this as a loadable builtin. -- Oğuz
Re: FEATURE REQUEST : shell option to automatically terminate child processes on parent death
On Saturday, November 11, 2023, Corto Beau wrote: > Do you mean something like a "fork_noreparent" builtin that would call > make_child and set PDEATHSIG afterwards, or a "noreparent" builtin that the > child would have to call ? > I don't have a preference for either. I oppose it being a shell option because first, it's a single function call that works on only one target platform; and second, its effect doesn't seem to stick. If I'm not missing anything, if I enable the proposed noreparent option in a shell and run a command, and that command forks, its children won't receive the death signal when the shell dies. It doesn't make any sense. Unless there is a way to make it stick and affect all descendants of the shell process, I don't think this would be very useful as a loadable builtin either. -- Oğuz
