Bug 832997

(In reply to comment #0)
> Description of problem:
> ulimit -u has no immediate effect on length of list, which is storing status
> of background processes. 
> 
> Example:
> ----- cut -----
> ulimit -u 1024
> cat > /tmp/test.sh <<\EOF
> #!/bin/bash
> TASKS=4096
tasks=4096
Better use lowercase variable names
> 
> ulimit -u 8192
> for i in `seq 1 $TASKS`; do
for (( i=1; i<= $tasks; i++)); do
>         /bin/sleep 1 &
>         PID[$i]=$!
> done
> sleep 1
> for i in `seq 1 $TASKS`; do
same as above
>         wait ${PID[$i]};
> done
> EOF
> chmod a+x /tmp/test.sh
> /tmp/test.sh
> ----- cut -----
> 
> Output is flooded with:
> /tmp/test.sh: line 11: wait: pid XXXXX is not a child of this shell
And what do you expect? Child processes ended bevore you call wait on them. You call sleep for 1 second on every child processes. Then you sleep the main process for 1 second, so all (ok, not all of them, but most of them) child processes are done, because they were sleeping for one second also. And then you want to wait for child processes, but most of them already are not existing.
> 
> Version-Release number of selected component (if applicable):
> bash-4.1.2-3.el6.x86_64
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1. run snippet above
> 
> Actual results:
> bash does not update maximum length of bgpids.list when new value is set via
> ulimit -u 
> 
> Expected results:
> ulimit -u should update maximum length of bgpids.list and snippet above
> should complete without errors
> 
> Additional info:

[root@RHEL6 ~]# cat t.sh 
#!/bin/bash
ulimit -u
ulimit -u 8192
ulimit -u
[root@RHEL6 ~]# bash t.sh 
1024
8192
[root@RHEL6 ~]# ulimit -u
1024

(In reply to comment #2)
> And what do you expect? Child processes ended bevore you call wait on them.
> You call sleep for 1 second on every child processes. Then you sleep the
> main process for 1 second, so all (ok, not all of them, but most of them)
> child processes are done, because they were sleeping for one second also.
> And then you want to wait for child processes, but most of them already are
> not existing.

I'm expecting that calling 'wait' on process that has ended should still return exit code, which seems to work fine:
# cp &
[1] 1815
# sleep 5
# wait 1815
# echo $?
1

Anyway, if you insist on starting wait prior to any process being terminated, here is modified example:

----- cut -----
ulimit -u 1024
cat > /tmp/test.sh <<\EOF
#!/bin/bash
tasks=4096

ulimit -u 8192
for (( i=1; i<= $tasks; i++)); do
        /bin/sleep 999 &
        pid[$i]=$!
done
for (( i=1; i<= $tasks; i++)); do
        wait ${pid[$i]};
done
EOF
chmod a+x /tmp/test.sh
/tmp/test.sh &
# wait a bit until all sleeps are started
sleep 10
killall sleep
----- cut -----

Waiting on all in single wait (as opposed to sequential wait) makes no difference:
----- cut -----
ulimit -u 1024
cat > /tmp/test.sh <<\EOF
#!/bin/bash
tasks=4096

ulimit -u 8192
for (( i=1; i<= $tasks; i++)); do
        /bin/sleep 999 &
        pid[$i]=$!
        all_pids="$all_pids ${pid[i]}"
done
wait $all_pids;
EOF
chmod a+x /tmp/test.sh
/tmp/test.sh &
# wait a bit until all sleeps are started
sleep 10
killall sleep
----- cut -----

Ah, now I do understand.

I have to find a siutable place to add
js.c_childmax = getmaxchild ();
or so...
Thanks for the report

One of the reasonable ways is to set up some maximal value. I will prepare patch for it.

According to the POSIX, it's not reasonable to change system variables and values:
"""
This runtime facility is not meant to provide ever-changing values that applications have to check multiple times. The values are seen as changing no more frequently than once per system initialization, such as by a system administrator or operator with an automatic configuration program. This volume of POSIX.1-2008 specifies that they shall not change within the lifetime of the process.
"""
(from http://pubs.opengroup.org/onlinepubs/9699919799/functions/sysconf.html)

I sent a patch upstream which enables posibility to set forced number of remembered statuses.

Here is the upstream mail with proposed patch:
http://lists.gnu.org/archive/html/bug-bash/2012-08/msg00066.html

This is not a bug, according to POSIX (see comment #8).