Re: `wait` triggers an infinite loop when used in an EXIT trap

Things seem a little more subtle:

In order do make some light on this, ther's my version:

    #!/bin/bash
    
    jobs=()
    
    cleanup() {
        echo "PID: $$ CMD: $BASH_COMMAND"
        kill -- "${jobs[@]}"
        wait
    }
    
    trap cleanup EXIT
    
    true & jobs+=($!)
    true & jobs+=($!)
    true & jobs+=($!)
    true & jobs+=($!)
    true & jobs+=($!)
    
    # trap cleanup EXIT
    
    declare -p jobs

Run on Debian Trixie (bash 5.2.15(1)-release), when `trap` is defined
before `true` commands, I often (but not always) see:

    declare -a jobs=([0]="253085" [1]="253086" [2]="253087" [3]="253088" [4]="253089")
    PID: 253084 CMD: declare -p jobs
    trapChilds.sh: line 7: kill: (253085) - No such process
    trapChilds.sh: line 7: kill: (253086) - No such process
    trapChilds.sh: line 7: kill: (253087) - No such process
    PID: 253084 CMD: true
    trapChilds.sh: line 7: kill: (253085) - No such process
    trapChilds.sh: line 7: kill: (253086) - No such process
    trapChilds.sh: line 7: kill: (253087) - No such process

Where `cleanup` was run two times! Seem to be trigger by one of `true`
command's EXIT signal.

( $BASH_COMMAND should contain `declare -p` !)

When run on 5.3.9(1)-release, I see sometime:

    declare -a jobs=([0]="254729" [1]="254730" [2]="254731" [3]="254732" [4]="254733")
    PID: 254727 CMD: declare -p jobs
    trapChilds.sh: line 7: kill: (254729) - No such process
    trapChilds.sh: line 7: kill: (254730) - No such process
    trapChilds.sh: line 7: kill: (254731) - No such process
    trapChilds.sh: line 7: kill: (254732) - No such process
    trapChilds.sh: line 7: kill: (254733) - No such process

But some other time: 

    declare -a jobs=([0]="254707" [1]="254708" [2]="254709" [3]="254710" [4]="254711")
    PID: 254705 CMD: declare -p jobs
    trapChilds.sh: line 7: kill: (254707) - No such process
    trapChilds.sh: line 7: kill: (254710) - No such process
    PID: 254705 CMD: true
    PID: 254705 CMD: true
    trapChilds.sh: line 7: kill: (254707) - No such process
    trapChilds.sh: line 7: kill: (254707) - No such process
    trapChilds.sh: line 7: kill: (254710) - No such process
    trapChilds.sh: line 8: wait: pid 254708 is not a child of this shell
    trapChilds.sh: line 8: wait: pid 254708 is not a child of this shell
    trapChilds.sh: line 8: wait: pid 254708 is not a child of^C

I had to hit Ctrl+C!

Note: If the trap is defined AFTER last `true` was ran, everything work fine.

Le Mon, Jan 05, 2026 at 11:50:24AM -0500, Chet Ramey a écrit :
> On 1/2/26 2:23 PM, Aleksey Covacevice wrote:
> 
> > Bash Version: 5.3
> > Patch Level: 8
> > Release Status: release
> > 
> > Description:
> >      `wait` triggers an infinite "pid is not a child of this shell" loop when
> >      used in an EXIT trap.
> > 
> > Repeat-By:
> >      Run the following:
> > ....
> >      Ocasionally bash loops at `wait` claiming some "pid is not a child of
> >      this shell". (It doesn't happen if `kill` is not used.)
> 
> Consider this sequence of events. The parent shell forks the last
> asynchronous process and adds it to the jobs array (setting the
> value of $! and adding it to the list of background jobs the shell
> maintains). It then exits and runs its exit trap before the child process
> runs and resets its EXIT trap handler. The parent shell, as part of its
> EXIT trap, kills the last asynchronous child, which still has an active
> EXIT trap, with a SIGTERM. Since the shell is not interactive, SIGTERM is
> a fatal signal. That asynchronous child shell exits, running its EXIT trap.
> 
> The child process, which has an active EXIT trap, has inherited the jobs
> array, the list of background processes, and the value of $! from its
> parent. When it runs its EXIT trap, it will try to wait for all of the
> background jobs it inherited, none of which are its children. You should
> get at least one error message when this happens.
> 
> The loop happens because it keeps trying to wait for these processes that
> are not its children. I'll have to figure out why that's happening --
> probably because it's trying to wait for "all background pids" and not
> doing the right error checks.

-- 
 Félix Hauri  -  <[email protected]>  -  http://www.f-hauri.ch