[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fwd: Re: bash sometimes don't wait for children process]

From: Roman Rakus
Subject: [Fwd: Re: bash sometimes don't wait for children process]
Date: Mon, 20 Oct 2008 17:34:07 +0200
User-agent: Thunderbird (X11/20080723)

--- Begin Message --- Subject: Re: bash sometimes don't wait for children process Date: Mon, 20 Oct 2008 17:29:44 +0200 User-agent: Thunderbird (X11/20080723)
Chet Ramey wrote:
Roman Rakus wrote:

To see if we created a process in execute_simple_command that we need
to wait for.  The presence of non-Unix systems that tend to recycle
pids quickly (or allocate at random from a small pool) makes the check
unreliable, so we call wait_for every time.
Yes, but don't we see it if already_making_children is set to 1?

That's not what that variable means.

Yes, kernel will give you that pid, if pid numbers  are out of 32768 (or
number set in /proc/sys/kernel/pidmax).
I think, if we define RECYCLE_PIDS we will solve this problem and don't
introduce any other.

If Linux behaves that way, then defining RECYCLES_PIDS is appropriate --
that's why it was introduced.  Unix systems don't work that way, which
is why it's not enabled by default.

This makes it difficult to meet the Posix requirement that the shell keep
the last CHILD_MAX exit statuses, but there is language that allows
overwriting in the face of this kind of pid reuse.

Hi again,
after short discussion with one kernel guy this looks like linux kernel bug. It's reproducible only on older kernel. Kernel shouldn't allow you to run more then pid_max processes, therefor this not affect bash. Thank you for your time Chet.

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]