On 7/24/12 12:54 PM, Michael Haubenwallner wrote:
>> (What
>> would you expect bash to do about it in the first place?) It may also
>> interest you to know that there are some operating systems that use
>> random PID allocation, instead of sequential (OpenBSD for example).
>
> PID randomisation isn't a problem at all, as long as a previously used PID
> is not reused too early.
And that's the problem. Bash assumes that there's a PID space at least as
large as CHILD_MAX, and that the kernel will use all of it before reusing
any PID in the space. Posix says that shells must remember up to CHILD_MAX
statuses of terminated asynchronous children (the description of `wait'),
so implicitly the kernel is not allowed to reuse process IDs until it has
exhausted CHILD_MAX PIDs. The description of fork() doesn't mention this,
however. The Posix fork() requirement that the PID returned can't
correspond to an existing process or process group is not sufficient to
satisfy the requirement on `wait'.
Bash holds on to the status of all terminated processes, not just
background ones, and only checks for the presence of a newly-forked PID
in that list if the list size exceeds CHILD_MAX. One of the results of
defining RECYCLES_PIDS is that the check is performed on every created
process.
I'd be interested in knowing the value of CHILD_MAX (or even `ulimit -c')
on the system where you're seeing this problem.
The case where last_made_pid is equal to last_pid is a problem only when
the PID space is extremely small -- on the order of, say, 4 -- as long as
the kernel behaves as described above.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
