Wait for the child process, but get an error: "pid is not a child of this shell"

Question

I write a script to get data from HDFS parrallel, then I wait for these child processes in a for loop, but sometimes it returns "pid is not a child of this shell". sometimes it works well. It is so puzzled. I use "jobs -l" to show all jobs running in the background. I am sure that these pid is a child process of the shell process, and I use "ps aux" to make sure that these pids are marked with assignment to another process. Here is my script.

PID=() FILE=() let serial=0 while read index_tar do echo $index_tar | grep index > /dev/null 2>&1 if [[ $? -ne 0 ]] then continue fi suffix=`printf '%03d' $serial` mkdir input/output_$suffix $HADOOP_HOME/bin/hadoop fs -cat $index_tar | tar zxf - -C input/output_$suffix \ && mv input/output_$suffix/index_* input/output_$suffix/index & PID[$serial]=$! FILE[$serial]=$index_tar let serial++ done < file.list for((i=0;i<$serial;i++)) do wait ${PID[$i]} if [[ $? -ne 0 ]] then LOG "get ${FILE[$i]} failed, PID:${PID[$i]}" exit -1 else LOG "get ${FILE[$i]} success, PID:${PID[$i]}" fi done 

Answer 1

Just find the identifier of the process you want to wait for and replace it with 12345 below the script. Further changes can be made according to your requirements.

 #!/bin/sh PID=12345 while [ -e /proc/$PID ] do echo "Process: $PID is still running" >> /home/parv/waitAndRun.log sleep .6 done echo "Process $PID has finished" >> /home/parv/waitAndRun.log 

/usr/bin/waitingScript.sh

http://iamparv.blogspot.in/2013/10/unix-wait-for-running-process-not-child.html

Answer 2

Either the while loop or the for loop works in a subshell, so you cannot wait for the child of the (parent, outer) shell.

Change , this can happen if the while or for loop is actually

(a) in block {...} (b) participation in the pipeline (for example, for....done|somepipe )

Answer 3

If you are doing this in some kind of container, this condition may be caused by a bug in bash, which is easier to run into in a containerized environment .

From my reading of the bash source (in particular, see the comments on RECYCLES_PIDS and CHILD_MAX in bash-4.2/jobs.c ) bash-4.2/jobs.c that in their efforts to optimize the tracking of background jobs they leave themselves vulnerable to PID aliases ( where the new process can obscure the status of the old); to mitigate this, they shorten their background process history (obviously, as prescribed by POSIX?). If you want to wait for the process to shorten, the shell will not be able to find it in history and assumes that this means that it never knew about it (that is, that it is "not a descendant of this shell").