No. What you can do is write a loop with kill -0 $PID. If this call fails ($? -ne 0), the process has terminated (after your normal kill):

while kill -0 $PID; do 
    sleep 1
done

(kudos to qbolec for the code)

Related:

• What does `kill -0 $pid` in a shell script do?

Your kill command is backwards.

Like many UNIX commands, options that start with a minus must come first, before other arguments.

If you write

kill -INT 0

it sees the -INT as an option, and sends SIGINT to 0 (0 is a special number meaning all processes in the current process group).

But if you write

kill 0 -INT

it sees the 0, decides there's no more options, so uses SIGTERM by default. And sends that to the current process group, the same as if you did

kill -TERM 0 -INT    

(it would also try sending SIGTERM to -INT, which would cause a syntax error, but it sends SIGTERM to 0 first, and never gets that far.)

So your main script is getting a SIGTERM before it gets to run the wait and echo DONE.

Add

trap 'echo got SIGTERM' TERM

at the top, just after

trap 'killall' INT

and run it again to prove this.

As Stephane Chazelas points out, your backgrounded children (process1, etc.) will ignore SIGINT by default.

In any case, I think sending SIGTERM would make more sense.

Finally, I'm not sure whether kill -process group is guaranteed to go to the children first. Ignoring signals while shutting down might be a good idea.

So try this:

#!/bin/bash
trap 'killall' INT

killall() {
    trap '' INT TERM     # ignore INT and TERM while shutting down
    echo "**** Shutting down... ****"     # added double quotes
    kill -TERM 0         # fixed order, send TERM not INT
    wait
    echo DONE
}

./process1 &
./process2 &
./process3 &

cat # wait forever

First, you should know that kill 0 send the signal to all process in current process group. (see kill(1) - Linux man page) My guess is that it is killing more than it should. This is why wait is not waiting, it is being terminated for some reason. My best bet to solve this problem is to iterate over running jobs from jobs -pr killing one by one: this way I assure the signal is sent only to child processes in that moment and nothing more.

To get this to work I did several tests, but I was stuck on sending SIGINT to child processes. They simple don't react to it! Searching the web I've found this answer on Stack Overflow:

https://stackoverflow.com/questions/2524937/how-to-send-a-signal-sigint-from-script-to-script-bash

So the real problem is that you cannot send SIGINT from one script to other, because in non-interactive shells the signal is ignored. I was not able to workaround this issue (using bash -i to call the child script does not to work).

I know you probably want to send SIGINT and wait for the child processes to shutdown gracefully, but if you do not mind to use SIGTERM (or any other signal but SIGINT) this is the best script I wrote:

#!/bin/bash
trap 'killall' INT

killall() {
    echo '**** Shutting down... ****'
    jobs -pr
    for i in $(jobs -pr); do
        kill -TERM $i
    done
    wait
    echo DONE
}

./long.sh &
./long.sh &
./long.sh &

cat # wait forever

To test, I've created this long.sh script:

#!/bin/bash
trap 'killall' TERM

echo "Started... $$" >> file.txt

killall() {
    # shutting down gracefully
    echo "Finished... $$" >> file.txt
    exit # don't forget this!
}

# infinite loop
while true; do echo loop >/dev/null ; done

In this last script I did not use sleep function because it creates a new process that was staying on memory even after the script finishes. In your script, you can call new processes but you should assure to broadcast the SIGTERM (or any other signal you've used) to all of them.

To wait for any process to finish

Linux (doesn't work on Alpine, where ash doesn't support tail --pid):

tail --pid=$pid -f /dev/null

Darwin (requires that $pid has open files):

lsof -p $pid +r 1 &>/dev/null

With timeout (seconds)

Linux:

timeout $timeout tail --pid=$pid -f /dev/null

Darwin (requires that $pid has open files):

lsof -p $pid +r 1m%s -t | grep -qm1 $(date -v+${timeout}S +%s 2>/dev/null || echo INF)

The problem with repeatedly killing a process is that you've got a race condition with new process creation. It's not particularly likely, but it's possible that the process will exit and a new process start up with the same PID while you're sleeping.

Why are you having to repeatedly kill the process? If it's because the process will exit, but it may take some time to quit after receiving the signal, you could use wait:

 kill $PID
 wait $PID

In an ideal system, you'd never have to repeat a kill or issue kill -9 $PID. If you do have to, you might want to consider fixing whatever it is that you're running so you don't have to. In the meantime, you will probably not hit the race condition, and you can guard against it by (say) checking the timestamp of /proc/$PID/ just before killing the process. That's bad hackiness, though.

There is the timeout command. You would use it like

timeout -k 5 make brusselator.tst

Maybe you would like to see also if it exited successfully, failed or was killed because it timed out.

timeout -k 5 make brusselator.tst && echo OK || echo Failed, status $?

If the command times out, and --preserve-status is not set, then command exits with status 124. Different status would mean that make failed for different reason before timing out.

Let me start by saying, you could just inline all the stuff you have in scannew, since you're waiting anyway, unless you intend to scan again at some other point in your script. It's really the call to wc that you're concerned might take too long, which, if it does, you can just terminate it. This is a simple way to set that up using trap which allows you to capture signals sent to a process and set your own handler for it:

#! /usr/bin/env bash

# print a line just before we run our subshell, so we know when that happens
printf "Lets do something foolish...\n"

# trap SIGINT since it will be sent to the entire process group and we only
# want the subshell killed
trap "" SIGINT

# run something that takes ages to complete
BAD_IDEA=$( trap "exit 1" SIGINT; ls -laR / )

# remove the trap because we might want to actually terminate the script
# after this point
trap - SIGINT

# if the script gets here, we know only `ls` got killed
printf "Got here! Only 'ls' got killed.\n"

exit 0

However, if you want to retain the way you do things, with scannew being a function run as a background job, it takes a bit more work.

Since you want user input, the proper way to do it is to use read, but we still need the script to go on if scannew completes and not just wait for user input forever. read makes this a bit tricky, because bash waits for the current command to complete before allowing traps to work on signals. The only solution to this that I know of, without refactoring the entire script, is to put read in a while true loop and give it a timeout of 1 second, using read -t 1. This way, it'll always take at least a second for the process to finish, but that may be acceptable in a circumstance like yours where you essentially want to run a polling daemon that lists usb devices.

#! /usr/bin/env bash

function slow_background_work {
    # condition can be anything of course
    # for testing purposes, we're just checking if the variable has anything in it
    while [[ -z $BAD_IDEA ]]
    do
        BAD_IDEA=$( ls -laR / 2>&1 | wc )
    done

    # `$$` normally gives us our own PID
    # but in a subshell, it is inherited and thus
    # gives the parent's PID
    printf "\nI'm done!\n"
    kill -s SIGUSR1 -- $$
    return 0
}

# trap SIGUSR1, which we're expecting from the background job
# once it's done with the work we gave it
trap "break" SIGUSR1

slow_background_work &

while true
do
    # rewinding the line with printf instead of the prompt string because
    # read doesn't understand backslash escapes in the prompt string
    printf "\r"
    # must check return value instead of the variable
    # because a return value of 0 always means there was
    # input of _some_ sort, including <enter> and <space>
    # otherwise, it's really tricky to test the empty variable
    # since read apparently defines it even if it doesn't get input
    read -st1 -n1 -p "prompt: " useless_variable && {
                              printf "Keypress! Quick, kill the background job w/ fire!\n"
                              # make sure we don't die as we kill our only child
                              trap "" SIGINT
                              kill -s SIGINT -- "$!"
                              trap - SIGINT
                              break
                            }
done

trap - SIGUSR1

printf "Welcome to the start of the rest of your script.\n"

exit 0

Of course, if what you actually want is a daemon that watches for changes in the number of usb devices or something, you should look into systemd which might provide something more elegant.

If you have no other processes you are waiting for, a wait with no arguments will wait for all background jobs to finish. I often use constructs like

for i in *; do md5sum $i & done
wait

This will however break if your script has any other background tasks, but you can wrap it in a subshell like

(for i in *; do md5sum $i & done; wait) & all_md5sum=$!
...
wait $all_md5sum

wait also (optionally) takes the PID of the process to wait for, and with $! you get the PID of the last command launched in the background. Modify the loop to store the PID of each spawned sub-process into an array, and then loop again waiting on each PID.

# run processes and store pids in array
pids=()
for i in $n_procs; do
    ./procs[${i}] &
    pids[${i}]=$!
done

# wait for all pids
for pid in ${pids[*]}; do
    wait $pid
done

The problem is that all commands are executed from the first line to the last in order. So as @Scott Stensland mentoined you have to put it into background via & (ampersand) to make the timer start.

And furthermore I think getting the PID of your app via searching through process names is a dangerous practice since you might accidentally kill a program which contains the string app in its name. So a safer way is to use the variable ! to get the PID . So your modified script should now looks like this :

while (true); do
  ./app &
  app_pid=$!
  sleep 3600
  kill $app_pid
  sleep 60
done

When you put a process into background via & it goes into the job list of the parent bash process , and via ! you can get the PID of the last job.So it's safe.