On 2/7/18 3:30 PM, Chet Ramey wrote:
>> Unfortunately, the proposed patch does not fix the case for 32 bit
>> architectures.
>
> That's interesting. It seems to me that the kernel should reject attempts
> to set the maximum number of processes larger than 2**(sizeof (pid_t)).
I looked at this on
On 2/7/18 1:51 PM, Natanael Copa wrote:
> Hi,
>
> On Fri, 8 Dec 2017 08:04:00 -0500
> Chet Ramey wrote:
>
>> On 12/7/17 5:36 PM, Natanael Copa wrote:
>>> This fixes an issue with bash hanging if user process rlimit is too
>>> high.
>>
>> Thanks for the report.
>>
>
> Unfortunately, the propos
Hi,
On Fri, 8 Dec 2017 08:04:00 -0500
Chet Ramey wrote:
> On 12/7/17 5:36 PM, Natanael Copa wrote:
> > This fixes an issue with bash hanging if user process rlimit is too
> > high.
>
> Thanks for the report.
>
Unfortunately, the proposed patch does not fix the case for 32 bit
architectures.
On 12/7/17 5:36 PM, Natanael Copa wrote:
> This fixes an issue with bash hanging if user process rlimit is too
> high.
Thanks for the report.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@c
This fixes an issue with bash hanging if user process rlimit is too
high.
To reproduce:
ulimit -u 9223372036854775807
bash -c 'sleep 1 & wait $!'
---
jobs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/jobs.c b/jobs.c
index fc966036..d203db27 100644
--- a/jobs.c
+++ b/