Re: Checking executability for asynchronous commands

[Robert Elz]

    Date:        Tue, 29 Dec 2020 10:23:07 -0500
    From:        Chet Ramey <chet.ramey@case.edu>
    Message-ID:  <a750789b-e929-c8cc-db29-342eddbfb4d9@case.edu>

  | Bash will save some number of exit statuses corresponding to terminated
  | asynchronous child processes, and those statuses are retrievable using
  | `wait'. That number varies -- POSIX says you need to save at least
  | CHILD_MAX statuses, but bash will look at its nproc resource limit (using
  | sysconf(3)) and try to save that many, up to a max of 32K in bash-5.1. This
  | will be sufficient in most cases.

The interesting case (for shell authors, in practice this rarely, if ever,
actually happens) is how to handle the case where the shell has collected
(waited for) the status from a child process, but the script has yet to
fetch it (that status is one of those being saved).   Then, during that
interval it is possible for the same pid to be assigned by the kernel for
some other process - and that other process might be a child of the same shell.
If that child is a fg process (never moved to bg) there's no real problem, but
if it is a bg process, and its pid is exported via $! then there can be a
real problem, as the script no longer has any safe documented and simple
way to distinguish the two processes (they will have different %n job numbers,
but scripts don't usually even consider such things).

I have considered have the shell (the one I maintain, not bash) check (both
parent and child) after a fork, and abort the child immediately, and simply
try the fork again, if the system assigns a pid which would cause a problem
like that - but never bothered to actually write the code (both parent and
child after the fork can run the same test, in parallel, so there's no issue
knowing what happened or what to do next .. the vfork case is similarly easy).
It has never been a high priority as, in practice, the issue just doesn't arise.

kre