Re: Want way to run background processes with SIGINT unignored

[Linda Walsh]

Chet Ramey wrote:
> On 10/9/15 2:42 PM, Ian Jackson wrote:
> > However, it would be very easy for bash to provide an option (via `set
> > -o' perhaps) to disable this behaviour.  That is, to allow SIGINT to
> > be delivered normally to child processes.
>
> I'm restricting non-standard options to `shopt' to avoid any possible
> conflict with future posix changes.
---
Thats a straw-man excuse if I ever heard one: use a "bash_"
prefix to any new options.  But, still, if you think even that
that might collide w/future posix choices, then don't use shopt
at all: use "bashopt" with bash-defined options and usage.
Either way, that should allay your worries on that front.


> > With such an option, scripts which run on modern systems and which
> > attempt to parallelise their work, would be able to arrange that ^C
> > properly cleans up the whole process group, rather than leaving the
> > background tasks running (doing needless work and perhaps causing
> > lossage).
----
        I pointed this out as a serious regression in 4.3 as bash
makes steps to really screw up async/realtime children handling
work in:

 Subj: REGRESSION: signal handlers not running in real-time
 Url:   https://lists.gnu.org/archive/html/bug-bash/2015-07/msg00138.html

I warned that as computing is going towards more parallelism, his
breakage of real-time handling was going to be more costly and 
harmful for using bash as system-control scripting language.

> >  2. In the child, reset SIGINT and SIGQUIT to the values found at
> >     shell startup.  That is, uninstall trap handlers.  This is what
> >     most ordinary scripts will want, because they don't want the trap
> >     handler running in both parent and child.  It's the same as is
> >     done for all other signals, and for all signals in non-background
> >     subshells and subprocesses.
----
The problem of unreliable signals and handling them had (at least)
two branches of solutions: one was a BSD solution adopted by
POSIX, who's behavior you see in bash, that resets signal-handlers
to default values before calling the handler.  

The other solution steered around legacy compatibility
issues and created the 'sigaction' commands.  It was designed
by mostly SysV descendants who were looking to support
reliable and real-time signal handling and delivery, similar
to requirements placed on interrupt handling.  They mostly
left signal alone for compatibility reasons.

Unfortunately the BSD crowd also wanted a sigaction -- 
but built it as a wrapper around signal -- resulting in
incompatible semantics and behaviors. Later lobbing by BSD
in an environment mostly bereft of remaining SysV based
vendors, voted their version into the new POSIX standard.
Linux still kept the SysV standards, because Linus has been
heavy-handed in supporting technical correctness over
popular standard and vendor wants that he felt would 
degrade linux quality.  

However, Gnu has, over the years, coincident with waning
patience toward many of Stallman's rigid attitudes has moved
toward more corporate acceptance via sponsorship.  One of
those conformance points was conforming the new POSIX's
mandatory and changing "compatibility"[sic] standards.
Thus with glibc2, linux users got the broken wrapper
version, by default on linux -- as the wrapper was the
default in any code that had _BSD_ or _GNU_ SOURCE defined
in the headers or code -- which includes bash.

Too many race conditions in the older standard led to the
current reversion to default POSIX behavior of "unsetting"
(or resetting) default SIG handlers before calling the handler.
This lead to the tactical-nuke fix on Signals in 4.3 of
resetting, disabling and postponing all of them.  As chet
stated on this list, there were too many restrictions in what
you could do in a BSD/POSIX/GNU signal handler, so the only
way to wipe out the current and future problems was by 
removing options for reliable signal handling and the
realtime semantics.

It does open up a new, but remote possibility for a different
class of vulnerabilities, with a known problems on
some systems that could result in system hangs and D-of-S
problems.

In short -- not only is only another bad step for 
bash in its usability as a system control script language.
Inconsistent and unreliable error handling is already present
in the current bash, as I mentioned only yesterday in regards
to the unreliability of the 'type' command in finding commands
and designed to be functional, yet, with so many 
examples to the contrary (not to mention, NOT being
POSIX conforming in regards to err-status codes return
on failure.


bash as I posted recently, So it's growing harder and harder
to work around its increasing limitations.