Shell – Starting an interactive shell as an asynchronous process (signal delivery)

shellshell-scriptsignals

Consider this short script. It sets up two signal handlers; one for USR1 and another for USR2. Then it starts an interactive shell session.

#!/bin/sh

sigusr1_handler () {
    variable=1
    printf "SIGUSR1: variable is now %d\n" "$variable"
}

sigusr2_handler () {
    variable=2
    printf "SIGUSR2: variable is now %d\n" "$variable"
}

variable=0

printf "At beginning, variable is %d\n" "$variable"

trap 'sigusr1_handler' USR1
trap 'sigusr2_handler' USR2

/bin/sh

printf "At end, variable is %d\n" "$variable"

Running it:

$ ./script.sh
At beginning, variable is 0
$ kill -s USR1 $PPID
$ kill -s USR2 $PPID
$ kill -s USR1 $PPID
$ exit
SIGUSR1: variable is now 1
SIGUSR2: variable is now 2
At end, variable is 2

The first thing I noticed is that the parent shell is not handling the signals until the child shell terminates. I found that this is documented by POSIX, so I'm at fault for not reading the documentation properly.

The second thing I noticed was that signal aren't queued up. That may be really basic knowledge, but it had escaped me. I assume that while the child process is executing, the generated signals are pending, and if a pending signal is generated again, it is simply ignored.

My issue is that I need to have the signals delivered to the signal handlers of the parent process while the interactive shell (the child process) is running. I need this because I want to make decisions based on the value $variable after the termination of the child process, and if signals are generated in the same order as in the interactive session above, $variable must have the value 1 at the end of the script.

So my naïve solution was to start the child process as an asynchronous background job:

/bin/sh &
wait

(I know I need to check the return value of wait in case of signal delivery, but I'll set that up later.)

This does not work. The child process exits immediately:

$ sh -x script.sh
+ variable=0
+ printf At beginning, variable is %d\n 0
At beginning, variable is 0
+ trap sigusr1_handler USR1
+ trap sigusr2_handler USR2
+ wait
+ /bin/sh
+ printf At end, variable is %d\n 0
At end, variable is 0

(It looks like the wait is executed before the shell in the trace output above, but I am doing it in the correct order in the script.)

Using /bin/sh -i & changes nothing. I made further attempts with /bin/sh -s and redirecting /dev/stdin into it, and combinations of these (-i -s), but to no avail.

So now my question is thus: How may I start an interactive shell from a script as an asynchronous foreground process (i.e. accepting input as any interactive shell) so that its parent process may have signals delivered as soon as they are generated? Or, is another design possible?

Best Answer

Satō Katsura's comment answers my question adequately:

It's system-dependent whether signals are queued or not. There is no guarantee signals are delivered in a certain order. Signals of the same type may be delivered in the same order they are generated, but that also is system-dependent (f.i. it's true on Linux). Use pipes for command channels if you need to send more than one kind of command.

Related Solutions

Shell – What should interactive shells do in orphaned process groups

I agree with your analysis and I agree it sounds like you have to detect whether your process group is orphaned or not.

tcsetattr is also meant to return EIO if the process group is orphaned (and we're not blocking/ignoring SIGTTOU. That might be a less intrusive way than a read on the terminal.

Note that you can reproduce it with:

(bash<&1 &)

You need the redirection otherwise stdin is redirected to /dev/null when running a command in the background.

(bash<&1 & sleep 2)

Gives even weirder behaviour, as because you end up with two shells reading from the terminal. They are ignoring SIGTTIN and the new one is not detecting, once it's started that it is no longer in the foreground process group.

ksh93's solution is not so bad: only go up to 20 times (instead of infinite) through that loop before giving up.

Shell – Preventing propagation of SIGINT to Parent Process

(Inspired by Gilles's answer)

With the ISIG flag set, the only way for the Child script to get SIGINT without its parent getting SIGINT is for it to be in its own process group. This can be accomplished with the set -m option.

If you turn on the -m option in the Child shell script, it will perform job control without being interactive. This will cause it to run stuff in a separate process group, preventing the parent from receiving the SIGINT when the INTR character is read.

Here is the POSIX description of the -m option:

-m This option shall be supported if the implementation supports the User Portability Utilities option. All jobs shall be run in their own process groups. Immediately before the shell issues a prompt after completion of the background job, a message reporting the exit status of the background job shall be written to standard error. If a foreground job stops, the shell shall write a message to standard error to that effect, formatted as described by the jobs utility. In addition, if a job changes status other than exiting (for example, if it stops for input or output or is stopped by a SIGSTOP signal), the shell shall write a similar message immediately prior to writing the next prompt. This option is enabled by default for interactive shells.

The -m option is similar to -i, but it doesn't alter the shell's behavior nearly as much as -i does.

Example:

the Parent script:

#!/bin/sh

trap 'echo "PARENT: caught SIGINT; exiting"; exit 1' INT

echo "PARENT: pid=$$"
echo "PARENT: Spawning child..."
./Child
echo "PARENT: child returned"
echo "PARENT: exiting normally"

the Child script:

#!/bin/sh -m
#         ^^        
# notice the -m option above!

trap 'echo "CHILD: caught SIGINT; exiting"; exit 1' INT

echo "CHILD: pid=$$"
echo "CHILD: hit enter to exit"
read foo
echo "CHILD: exiting normally"

This is what happens when you hit Control+C while Child is waiting for input:

$ ./Parent
PARENT: pid=12233
PARENT: Spawning child...
CHILD: pid=12234
CHILD: hit enter to exit
^CCHILD: caught SIGINT; exiting
PARENT: child returned
PARENT: exiting normally

Notice how the parent's SIGINT handler is never executed.

Alternatively, if you'd rather modify Parent instead of Child, you can do this:

the Parent script:

#!/bin/sh

trap 'echo "PARENT: caught SIGINT; exiting"; exit 1' INT

echo "PARENT: pid=$$"
echo "PARENT: Spawning child..."
sh -m ./Child  # or 'sh -m -c ./Child' if Child isn't a shell script
echo "PARENT: child returned"
echo "PARENT: exiting normally"

the Child script (normal; no need for -m):

#!/bin/sh

trap 'echo "CHILD: caught SIGINT; exiting"; exit 1' INT

echo "CHILD: pid=$$"
echo "CHILD: hit enter to exit"
read foo
echo "CHILD: exiting normally"

Alternative ideas

Modify the other processes in the foreground process group to ignore SIGINT for the duration of Child. This doesn't address your question, but it may get you what you want.
Modify Child to:
1. Use stty -g to back up the current terminal settings.
2. Run stty -isig to not generate signals with the INTR, QUIT, and SUSP characters.
3. In the background, read the terminal input and send the signals yourself as appropriate (e.g., run kill -QUIT 0 when Control+\ is read, kill -INT $$ when Control+C is read). This is not trivial, and it may not be possible to get this to work smoothly if the Child script or anything it runs is meant to be interactive.
4. Restore the terminal settings before exiting (ideally from a trap on EXIT).
Same as #2 except rather than running stty -isig, wait for the user to hit Enter or some other non-special key before killing Child.

Write your own setpgid utility in C, Python, Perl, etc. that you can use to call setpgid(). Here's a crude C implementation:

#define _XOPEN_SOURCE 700
#include <unistd.h>
#include <signal.h>

int
main(int argc, char *argv[])
{
    // todo: add error checking
    void (*backup)(int);
    setpgid(0, 0);
    backup = signal(SIGTTOU, SIG_IGN);
    tcsetpgrp(0, getpid());
    signal(SIGTTOU, backup);
    execvp(argv[1], argv + 1);
    return 1;
}

Example usage from Child:

#!/bin/sh

[ "${DID_SETPGID}" = true ] || {
    # restart self after calling setpgid(0, 0)
    exec env DID_SETPGID=true setpgid "$0" "$@"
    # exec failed if control reached this point
    exit 1
}
unset DID_SETPGID

# do stuff here

Best Answer

Related Solutions

Shell – What should interactive shells do in orphaned process groups

Shell – Preventing propagation of SIGINT to Parent Process

Alternative ideas

Related Question