On 7/25/12 9:20 AM, Michael Haubenwallner wrote:
>
> On 07/25/2012 09:59 AM, Michael Haubenwallner wrote:
>> On 07/25/2012 03:05 AM, Chet Ramey wrote:
>>> 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.
>
>> The AIX 6.1 I've debugged on has:
>> #define CHILD_MAX 128
>
>> I'm going to run this build job with 'truss -t kfork' again, to eventually
>> find
>> some too small count of different PIDs before PID-recycling by the kernel...
>
> Tracing shows:
>
> The minimum fork count (including grand-childs to any depth) before PID
> recycling starts
> looks like 255 (once), but usually 256 and more.
>
> However, one process does see a PID recycled after *at least* 128 forks,
> that is exactly the value of CHILD_MAX.
>
> First thought is of some off-by-one bug, but reducing js.c_childmax in jobs.c
> (2 times)
> by one doesn't help.
It wouldn't. Bash prefers sysconf(_SC_CHILD_MAX) to the CHILD_MAX define,
and those two are apparently different. You could replace js.c_childmax
in tests against its value (three places in jobs.c) with CHILD_MAX and
see whether that makes a difference.
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/
