bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SIGINT handling during async functions


From: Martin D Kealey
Subject: Re: SIGINT handling during async functions
Date: Sat, 28 Jan 2023 20:56:57 +1000

Firstly, let's just leave aside "POSIX requires this" for a bit. I know
that the requirement is there, and I think it is one of those broken things
that ought to have been dropped from POSIX, or at least reduced to optional
rather than required.

On Tue, 24 Jan 2023 at 07:35, Chet Ramey <chet.ramey@case.edu> wrote:

> On 1/21/23 7:55 AM, Tycho Kirchner wrote:
> > Please consider a script launching several commands in background
> > and waiting for their completion:
>

(note these last 4 words; I suspect they exclude the "common case
experience" of people who think that it's only natural to want to insulate
new daemons from tty signals)


> >
> > cmd1 &
> > cmd2 &
> > wait
> >
> > [...] In my experience, what the user usually wants in such a case is

> to abort cmd1, cmd2 as well as the script having launched them.
>
> Odd, my experience is the opposite. I have run commands asynchronously
> from scripts quite often in my previous lives, with the intent of
> insulating  them from signals.
>

Which behaviour seems "intuitive" probably depends on which of two patterns
one uses more often:
1. create a daemon that is intended to continue running after the script
finishes; or
2. create a number of cooperating parallel processes that are entirely
internal to the script, which *should* exit at or before the end of the
script.

I'm old enough to have used the Bourne shell before it had tty job control,
so I can see why *in the interactive case* it makes sense to prevent tty
signals from affecting any "background" process launched directly from the
interactive shell.

I contend that it's inconsistent for the actions of "nohup" and "&" to NOT
be fully orthogonal.

And I contend that a daemon that unexpectedly dies is much more obvious
than a bunch of internal processes that are unexpectedly left running; you
have to proactively check for orphaned processes, and their continued
action may cause weird bugs.


I haven't encountered an interactive shell in a tty without job control in
the last 35 years. (*1)
I contend that it's past time this POSIX misfeature was retired.

In the meantime, « shopt -s background_without_magic » (*2) gets my vote,
along with incorporating « nohup » as a built-in (so that Bash can
guarantee its behaviour, and add options to improve its internal
orthogonality.).

-Martin

*1: I have very occasionally had interactive single-user shell running on
/dev/console, which doesn't appear to count as a tty because it doesn't
respond to tcsetpgrp.

*2: or perhaps with finer granularity « shopt -u bg_block_signals
bg_null_stdin »


reply via email to

[Prev in Thread] Current Thread [Next in Thread]