Re: wait -n misses signaled subprocess

[Chet Ramey]

On 1/28/24 7:19 PM, Steven Pelley wrote:
> Thank you Chet for your thorough reply.
>
> You make a few comments about differences in output (stderr for not
> finding a job, notifications for jobs terminating) and in all cases I
> believe you are correct.  Let's assume job control is disabled.

OK, but remember:

"When job control isn't enabled (usually in a non-interactive shell), the
shell doesn't notify users about terminated background jobs, but it still
removes dead jobs from the jobs list before reading the next command. It
cleans the jobs table of notified jobs at other times, too, to move dead
jobs out of the jobs list and keep it a manageable size."

These exit statuses are still available to `wait pid' (but not `wait -n
pid') as POSIX specfies.

> > > I expect the line ending (BUG) to indicate a return code of 143.
> >
> > It might, if `wait -n' looked for already-notified jobs in the table of
> > saved exit statuses, but it doesn't. Should it, even if the user has
> > already been notified of the status of that job?
>
> When job control is disabled I get this output for the same test (just
> for consistent reference):

The results are consistent with what I described previously.


> There's no user notification of the job terminating because job
> control is disabled.  The "wait -n" returning 127 is the first
> opportunity the shell might have to notify the user of the job. 

So should the shell require the user to periodically run `wait' in a non-
interactive shell without job control to clean dead jobs out of the jobs
list? I don't think so.

> In
> this context I think that "even if the user has already been notified
> of the status of that job" doesn't apply -- the user hasn't been
> notified of the job terminating. 

See above.

> Even so, this behavior differs from a similar example but where the
> first job ends successfully, or at least without being killed by a
> signal.  It still terminates prior to calling "wait -n" (this is from
> Jan 24 but I'll post again to keep everything in a linear thread).
> echo "TEST: EXIT 0 PRIOR TO wait -n @${SECONDS}"
> { sleep 1; echo "child finishing @${SECONDS}"; exit 1; } &
> pid=$!
> echo "child proc $pid @${SECONDS}"
> sleep 2
> wait -n $pid
> echo "wait -n $pid return code $? @${SECONDS}"
>
> output (no job control):
> TEST: EXIT 0 PRIOR TO wait -n @0
> child proc 2779 @0
> child finishing @1
> wait -n 2779 return code 1 @2
>
> It does look in the table of saved exit statuses, returning 1.

It doesn't. In this case, the code path it follows marks the job as dead
but doesn't mark it as notified (since it exited normally), so it's still
in the jobs list when `wait -n' is called, and available for returning.
That's probably a bug there.


> I think the sticking point is the notion of the user being notified of
> the status of a job. 

I think it's whether or not `wait -n pid' behaves the same as `wait pid'
and looks in the list of saved exit statuses if the pid isn't found in a
job in the jobs list.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

OpenPGP_signature.asc
Description: OpenPGP digital signature