On 07/25/2012 03:05 AM, Chet Ramey wrote:
> 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 (th
On Wed, Jul 25, 2012 at 09:59:28AM +0200, Michael Haubenwallner wrote:
> OTOH, AFAICT, as long as a PID isn't waitpid()ed for, it isn't reused by
> fork().
> However, I'm unable to find that in the POSIX spec.
A process that hasn't been waited for should become a zombie, which
should be sufficien
On 7/25/2012 8:14 AM, Greg Wooledge wrote:
On Wed, Jul 25, 2012 at 09:59:28AM +0200, Michael Haubenwallner wrote:
OTOH, AFAICT, as long as a PID isn't waitpid()ed for, it isn't reused by fork().
However, I'm unable to find that in the POSIX spec.
A process that hasn't been waited for should be
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.
> Th
On 7/25/2012 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 li
On 07/25/2012 02:14 PM, Greg Wooledge wrote:
> On Wed, Jul 25, 2012 at 09:59:28AM +0200, Michael Haubenwallner wrote:
>> OTOH, AFAICT, as long as a PID isn't waitpid()ed for, it isn't reused by
>> fork().
>> However, I'm unable to find that in the POSIX spec.
>
> A process that hasn't been waite
On 7/25/12 3:59 AM, Michael Haubenwallner wrote:
>
> On 07/25/2012 03:05 AM, Chet Ramey wrote:
>> 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 CHIL
On 7/25/12 8:14 AM, Greg Wooledge wrote:
> On Wed, Jul 25, 2012 at 09:59:28AM +0200, Michael Haubenwallner wrote:
>> OTOH, AFAICT, as long as a PID isn't waitpid()ed for, it isn't reused by
>> fork().
>> However, I'm unable to find that in the POSIX spec.
>
> A process that hasn't been waited for
On 07/25/2012 03:20 PM, 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
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
>
On 7/25/12 9:44 AM, Steven W. Orr wrote:
> One thing that just springs to mind: Under AIX, I believe (but don't take
> this as gospel) that PIDs are not strictly ascending. The low byte may
> increment, but it might be another byte in the pid_t that gets the
> increment, and the byte that incremen
On 07/25/2012 04:52 PM, Michael Haubenwallner wrote:
Got it: The value used for js.c_childmax isn't 128, but 1024.
In lib/sh/oslib.c, getmaxchild() prefers sysconf(_SC_CHILD_MAX) over CHILD_MAX
over MAXUPRC.
But sysconf(_SC_CHILD_MAX) does return the number of "processes per real user
id" (si
On 7/25/12 10:11 AM, Michael Haubenwallner wrote:
>
> On 07/25/2012 02:14 PM, Greg Wooledge wrote:
>> On Wed, Jul 25, 2012 at 09:59:28AM +0200, Michael Haubenwallner wrote:
>>> OTOH, AFAICT, as long as a PID isn't waitpid()ed for, it isn't reused by
>>> fork().
>>> However, I'm unable to find tha
Chet Ramey writes:
> 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
On 07/25/2012 04:50 PM, Chet Ramey wrote:
>> The AIX 6.1 I've debugged on has:
>> #define CHILD_MAX 128
>> #define _POSIX_CHILD_MAX 25
>> sysconf(_SC_CHILD_MAX) = 1024
> Bash prefers sysconf(_SC_CHILD_MAX) and will use it over the other
> defines (lib/sh/oslib.c:getmaxchild()). I don't kno
On 7/25/12 11:59 AM, Michael Haubenwallner wrote:
>
> On 07/25/2012 04:50 PM, Chet Ramey wrote:
>>> The AIX 6.1 I've debugged on has:
>>> #define CHILD_MAX 128
>>> #define _POSIX_CHILD_MAX 25
>>> sysconf(_SC_CHILD_MAX) = 1024
>
>> Bash prefers sysconf(_SC_CHILD_MAX) and will use it over the
On 7/25/12 11:33 AM, Andreas Schwab wrote:
> I cannot see how CHILD_MAX is related to pid reuse. CHILD_MAX is a
> per-user limit, but the pid namespace is global. If the shell forks a
> new process, and the pid of it matches one of the previously used pids
> for asynchronous jobs it can surely d
On 7/25/12 10:57 AM, Roman Rakus wrote:
> And there is also a problem when you change the `ulimit -u' value.
> See https://bugzilla.redhat.com/show_bug.cgi?id=832997
It's not clear to me that it's desirable to attempt to remember a
potentially unlimited number of process exit statuses. You have
18 matches
Mail list logo
