Let's forget about your traps for a moment (which aren't well implemented, I'm sorry to say).

When you launch that script from an interactive shell prompt, it, all of its non-interactive subshells, and any external commands it executes will run as part of the same process group. When you press ctrl-c, the system will send SIGINT to every single process in that terminal's foreground process group (which includes scp). You should expect scp to be killed.

Except for one very important thing: when running a process as part of an asynchronous list (backgrounded, as you're doing with scp), it inherits a signal mask which ignores SIGINT (and I think SIGQUIT as well). So, if scp is running asynchronously, and such processes are setup by their shells to ignore SIGINT, why is it terminating when it receives SIGINT? Most probably, scp is modifying its inherited sigmask.

I don't know which implementation you are using, but a quick peek at OpenSSH's scp.c turns up a couple instances of "signal(SIGINT, killchild);".

If I am correct, and the issue is that scp is modifying its sigmask to terminate upon receipt of SIGINT, try running it in a different process group. This way, when ctrl-c sends SIGINT to every process in the foreground group, scp will not be signaled, as it's not a member. One way of accomplishing this is to invoke an interactive shell from your script.

Code:

# Instead of joining the current process group...
scp large.tar.gz server:/tmp/ &

# ... let's start another process group
sh -ic 'scp large.tar.gz server:/tmp/' &

Regarding your traps, note that since SIGINT is being sent directly to each process in the process group, you cannot use sh signal handlers to modify the signal handling behavior of other processes (including subshells). The only signal handling modification that you can make that is inheritable, by subshells and external utilities, is setting a signal to be ignored (using `trap '' SIGINT`).

Also, in your code, once the signal handler is entered, to handle the arrival of a particular signal, the script is stuck in the signal handler until a different signal interrupts the wait (since the current signal will be ignored so long as its handler is executing); at which point, if the newly-received signal is being trapped, the script is again stuck, in yet another instance of the signal handler. If you send the same signal more than once, you'll see that it only prints the message the first time.

Assuming you actually even need a signal handler to accomplish what you're trying to do (which you don't, if you just want to set some signals to be ignored), it would be a good idea to remove the wait from signal_exit and use a while loop in testFunction to resume waiting if wait is interrupted by a signal.

I sincerely hope that this post was helpful to you.

Regards,
Alister