Simultaneously watch for signals and process exit in Bourne shell

Question

I have a Bourne shell (/bin/sh) script (for portability) that wants to monitor another program. It should start the other program, then wait for it to exit. When the second program exits, it does some final work and exits itself. The catch is that the script needs to also respond to a signals (eg USR2) and do some work when those signals show up.

My naive implementation is:

#! /bin/sh
echo $$
trap 'echo Respond to USR2' USR2
/bin/sleep 120 &
pid=$!
wait $pid
echo $pid exited with $?
echo Doing final cleanup

This doesn't work. If I send the shell SIGUSR2, the trap fires as expected, but wait also finishes, returning 140. The /bin/sleep continues on its merry way. Typical output:

28849
Respond to USR2
28850 exited with 140
Doing final cleanup

This behaviour is consistent between dash and bash, the two Bourne shell derivatives I have convenient access to.

My current work around is to spin loop waiting for the child PID to disappear, probing with kill. Spin looping seems wasteful, and enlarges the window where my script might erroneously be waiting for the wrong process if PIDs are being rapidly reused.

#! /bin/sh
echo $$
trap 'echo Respond to USR2' USR2
/bin/sleep 15 &
pid=$!
while /bin/kill -0 $pid 2> /dev/null; do
    echo waiting...
    sleep 2
done
echo Doing final cleanup

Is there a better solution given my goal of simultaneously waiting for another process to exit and being able to respond to signals?

A posix compliant system always has c98 (or cc) installed... There comes a point where a 'script' that spits out a C file, compiles it, and calls it becomes the easiest portable way of doing things! I'd like to see too if there's a "proper" solution though. — Nicholas Wilson, Jul 20 '12 at 22:11
An unstated goal is to keep this simple, as it's also going to be a template other people base designs on. So I'm interested in minimizing the amount of clever involved. It may be that need a certain amount of clever, but I'm hoping not. If things don't work out, I'll fall back to Perl, which I can reasonably rely on being present on the systems I actually care about. — Alan De Smet, Jul 21 '12 at 00:59
I underspecified my problem. I do need to know how my second program exits, by exit or by signal. The shell isn't going to help me with that. (Thanks to William Pursell for pointing this out.) So for my own needs in this situation, it's off to Perl. I'll flag the answer that best answers my original question in hopes it will be useful to others who who may be able to accept that constraint. — Alan De Smet, Jul 23 '12 at 16:51

William Pursell · Accepted Answer · 2012-07-22T13:56:36.680

You could do:

while wait $pid; test $? -gt 128; do
    kill -0 $pid 2> /dev/null || break;
done

But note the following from the sh standard:

If the exit status of wait is greater than 128, there is no way for the application to know if the waited-for process exited with that value or was killed by a signal. Since most utilities exit with small values, there is seldom any ambiguity. Even in the ambiguous cases, most applications just need to know that the asynchronous job failed; it does not matter whether it detected an error and failed or was killed and did not complete its job normally.

In this case, the ambiguity is slightly different. You don't know if wait was interrupted by the signal or if the child was terminated by a signal.

Accepted as the best I can do in practice. For my own needs, regrettably not good enough; I jumped to another language with better process management. Thanks! — Alan De Smet, Jul 25 '12 at 21:13

Simultaneously watch for signals and process exit in Bourne shell

1 Answers1