Re: Bug related to stdin/always/jobcontrol

[Peter Stephenson <p.stephenson@samsung.com>]

On Wed, 14 Sep 2016 20:24:50 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> I think this has to do with fork-to-the-left on pipelines, i.e., in
> the "more normal case" the last process in the superjob is either
> the current shell or the process group leader.  The loop leaves pn
> pointing to the last process, and then the following bit --
> 
>                 if (!jobtab[jn->other].procs && pn)
>                     if (kill(pn->pid, sig) == -1 && errno != ESRCH)
>                         err = -1;
> 
> -- sends that process the signal, except not when there are "other"
> procs, so I don't quite grok that part.

Ah, I think that *is* the sort of thing I'm looking at (as well as in
the normal superjob case).  If that's the right process for this (which
is the bit I didn't really undersand), i.e. what at least at one point
in its life cycle was list_pipe_pid when a subjob was associated with
it, then the presence of processes associated with the "other" job (the
subjob) means we should kick those off instead.  There are then efforts
to ensure this gets restarted when the subjob has exited (that's the bit
that sprang back to life when I realised "other" was a process when used
within the subjob structure, and it's this process it's pointing to).
So I think this does make sense, depsite being a bit hairy and
underdocumented.  I'll add some tentative notes (though they might be
closer to eight- or ninetative).

pws