Shell Programming and Scripting

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

Hi Alister,
thanks for this complete explanation.

I tired running scp in another process group as you mention, i.e.

Code:

sh -ic 'scp large.tar.gz server:/tmp/' &

but I have the impression that it does the exact opposite of what I expected: when I hit ctrl+c,
- the scp stops
- rest of the script is executed ( echo "COPY END")
- my trap function "signal_exit" is not executed

Hi, Robert:

For the moment, I suggest forgetting about the trap and simplify your script as much as possible. Whether or not you have a trap in place, every process in the terminal's foreground process group will be sent SIGINT when you press control-c. Your trap in a sh cannot prevent that.

While testing with the following, I discovered a flaw in my proposed solution.

Code:

#!/bin/bash

echo COPY START
# sh -ic 'scp large.tar.gz server:/tmp/' &
sh -ic 'sleep 5' &
sleep 2
ps -t $(tty) -o pid,ppid,pgid,stat,command
wait
echo COPY END

My results:

Code:

$ ./robertford.sh
COPY START
  PID  PPID  PGID STAT COMMAND
 3896   478  3896 Ss   login -pf xxxxx
 3897  3896  3897 S    -bash
 5278  3897  5278 S    /bin/bash ./robertford.sh
 5279  5278  5279 S+   sleep 5
 5282  5278  5278 R    ps -t /dev/ttyp2 -o pid
COPY END

Note that sleep is in a different process group 5279 while the shell script invoked from the command line is in process group 5278. Unfortunately, the "+" in the STAT column means that it's in the foreground group, so it will receive the SIGINT still. I overlooked that in my earlier reply. I'm sorry.

By the way, the fact that the original script's process group is no longer in the foreground is the reason that your trap was not triggered; that sh was not sent SIGINT.

Have you checked scp's logs? While my proposed solution did not work, I believe that the analysis of the problem is sound. scp logs should indicate if it is aborting the transfer due to a signal (if necessary, set verbosity to maximum).

I look forward to hearing how this turns out; so if you resolve it (whether with my recommendation, someone else's, or your own insight), please post back with problem/solution details.

Regards,
Alister

Would

Code:

/bin/bash -lc 'command goes here'

not work? -l == act as if it were a login, meaning it creates a new process tree?
I believe it calls setsid() and creates a new separate process group.
My bash is v 2.05 which does not support the -l option. Correct me if I'm wrong on this, please.

Tinkering a bit more with my prior attempt at a workaround...

Since by default an interactive shell will put a pipeline in a new process group and make that new group the foreground group, if we want to prevent the progress group created by the -c argument to the subshell from taking the foreground, it must be backgrounded. However, without a wait, there will be nothing for the main script to wait on. So, the following may be the best we can do:

Code:

#!/bin/bash

echo COPY START
# sh -ic 'scp large.tar.gz server:/tmp/ & wait' &
sh -ic 'sleep 15 & wait' &
ps -t $(tty) -o pid,ppid,pgid,stat,command
wait
echo COPY END

Test run:

Code:

$ ./robertford.sh
COPY START
[1] 5418
  PID  PPID  PGID STAT COMMAND
 3896   478  3896 Ss   login -pf xxxxx
 3897  3896  3897 S    -bash
 5415  3897  5415 S    /bin/bash ./robertford.sh
 5416  5415  5416 S+   sh -ic sleep 15 & wait
 5418  5416  5418 S    sleep 15
 5420  5415  5415 R    ps -t /dev/ttyp2 -o pid
^C
COPY END

The interactive subshell will execute in a different process group and will become the foreground process group. control-c will be sent to it and any other members of that group. However, the backgrounded pipeline (in this case, sleep 15, ultimately it should be your scp command) is run in another process group which is at last not in the foreground.

Cheers,
Alister

---------- Post updated at 12:39 PM ---------- Previous update was at 11:36 AM ----------

I tested it with the same script I used in my previous post, but it doesn't even create a new process group. I'm assuming that without the -i option, -c renders it a non-interactive shell, despite the -l/--login options (I tried both).

I believe that session creation for interactive use is handled by the login process before it execs the user's shell.

A quick peek at the process list of a few systems, using different default login shells (debian-bash, osx-bash, openbsd-ksh) shows:

debian and osx: -bash login shells are not session leaders (each terminal with a logged in user has a login process associated with it that is the session leader).

openbsd: -ksh login shells are session leaders (there's no login process for those terminals).

Without looking at the source or examining a process trace, one cannot be absolutely certain, but it seems to me that differences in login implementations determine whether or not a user's login shell will be a session leader. The shell's themselves never seem to attempt to become a session leader (in the openbsd case, `ksh -l` will not yield a session leader, which is why I assume it's set up that way by the login process that exec'd it).

Regards,
Alister