howto: get return code from background process?

[Lynn Osburn]

Env: ksh on 10.20, 11.0 AND 11i
I need to be able to have a script launch several processes as background jobs, and then check the return codes from those background jobs for errors as they finish. The "parent" script need to handle the child error checking asynchronously; this means it can't just 'wait', as it has other stuff to do in the meantime.

metacode:
- launch 3 jobs in the background
- keep an eye on them, checking return code of any that complete
- meanwhile, continue executing other steps in main script
Thanks for your ideas and consctructive criticism
-Lynn

[James R. Ferguson]

Hi:

Consider:

As you launch your background processes capture their pid via $! as:

# ./mything1 &
# MYPID1=$!

Have the background process write their exit status into a file named with their pid as:

/tmp/sh.${MYPID}

For example:

# ( hostname > /tmp/sh.$!;date >> /tmp/sh.$!; echo $? >> /tmp/sh.$! ) &

If your background processes can be coded to catch signals, make sure that a file with an appropriate exit status is created on a fault or a kill signal.

In your parent shell, periodically test for the presence of the file's extracting the exit status as needed. If the file isn't available, continue processing.

If needed, in your parent process, use:

# kill -0

...to test whether or not one of your background jobs is still viable when you have exhausted all other work and need to decide whether to continue to wait for background completion or not. Take action as appropriate.

Regards!

...JRF...

[A. Clay Stephenson]

Hi:

Perl has some really neat ways to synchronize processes including all the traditional IPC methods (semaphores, messages, and shared memory) in addition to sockets for synchronizing across the network. If you restrict the problem to the shell then James' solution should work.

Regards, Clay

[Lynn Osburn]

Clay, unfortunately we can't assume that Perl is present on all the machines where this script must run, else I'd be writing in it Perl. We'll be running this on a wide variety of machines of various ages and O/S versions.

James, the sticking point with your concept (and I wasn't clear on this when I wrote the original post) is that the background processes will change as the script runs, which makes knowing about the temp filename messier.

Think of this as a "dispatcher" program handing off work to "workers" who do their single task, report status, and then are assigned a new task. The number of tasks is not known at compile time and may vary from run to run. The tasks are structured so that they can be run/completed in any order; there is no interdependency between task elements. We desire to NOT have a group of workers in "lock step" where the first worker to finish then loafs until the last of the group is done.
The number of workers is a runtime option as well. We have all of the code roughed in and running except for the error checking function.

Thanks in advance for the wear-and-tear on your brain cells.
-Lynn