Bug 832997 - ulimit -u does not re-initialize length of bgpids.list
ulimit -u does not re-initialize length of bgpids.list
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: bash (Show other bugs)
6.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Roman Rakus
BaseOS QE - Apps
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-18 07:18 EDT by Jan Stancek
Modified: 2014-01-12 19:14 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-15 07:16:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Stancek 2012-06-18 07:18:21 EDT
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

ulimit -u 8192
for i in `seq 1 $TASKS`; do
        /bin/sleep 1 &
        PID[$i]=$!
done
sleep 1
for i in `seq 1 $TASKS`; do
        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

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:
Comment 2 Roman Rakus 2012-06-18 08:07:47 EDT
(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
Comment 3 Jan Stancek 2012-06-18 09:34:22 EDT
(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 -----
Comment 4 Jan Stancek 2012-06-18 10:05:47 EDT
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 -----
Comment 5 Roman Rakus 2012-06-18 11:11:32 EDT
Ah, now I do understand.

I have to find a siutable place to add
js.c_childmax = getmaxchild ();
or so...
Thanks for the report
Comment 7 Roman Rakus 2012-08-22 08:52:13 EDT
One of the reasonable ways is to set up some maximal value. I will prepare patch for it.
Comment 8 Roman Rakus 2012-08-28 03:28:13 EDT
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.
Comment 9 Roman Rakus 2012-08-28 05:14:25 EDT
Here is the upstream mail with proposed patch:
http://lists.gnu.org/archive/html/bug-bash/2012-08/msg00066.html
Comment 10 Roman Rakus 2012-10-15 07:16:41 EDT
This is not a bug, according to POSIX (see comment #8).

Note You need to log in before you can comment on or make changes to this bug.