Home / ubuntu / Questions / 508844
Accepted
wilhil
Asked: 2014-08-09 17:33:38 +0800 CST

Why does hitting Control + C when in an application launched from a script, break the script?

  • 772

To jump straight in:

while true; do
    #---  MENU LOGIC HERE, stick response in $MENUEXIT

    #----Deal with responses here

    if [ $S1 == $MENUEXIT ];
    then
            tail -f /path-to-file
    else
            sleep 2
    fi
done

I've tried to keep this as simple as possible, if you need more, let me know.

Basically, I am sticking a menu in a loop, so, if there is incorrect user input or a command finishes, it is meant to re-display the menu.

It worked fine, until I added the tail command.

If I choose the tail option from the menu, the tail command gets launched fine - but, if I hit Ctrl + C, I would like tail to terminate and the menu to be displayed, but it instead both terminates tail AND the script.

I have tried various things such as continues/traps and more, but, I have hit a brick wall and would like some help please?!

bash

1 Answers

  1. Best Answer

    When you send a signal like SIGINT (CtrlC) or SIGSTOP (CtrlZ) from a terminal, the signal is sent to the foreground process group. That is, the group comprising of the foreground job (your script), and any child processes it has in the foreground (the tail command). This causes all these processes to exit (or do whatever it is they do by handling the signal). You can test the difference by sending a signal using the kill command:

    In one terminal, execute this script (I'm calling it test in the following commands):

    #! /bin/bash

while true
do
    if [[ $1 = a ]]
    then
        yes 
    else
        echo no
        sleep 2
    fi
done

    In another, execute these commands:

    pstree -ps $(pgrep -f test)
pkill -f test
pstree -ps $(pgrep -f yes)

    The output of the commands would be something like this:

    init(1)───lightdm(1032)───lightdm(1154)───init(1173)───x-terminal-emul(17009)───bash(24262)───test.sh(24996)───yes(24997)
# No output for pkill
init(1)───lightdm(1032)───lightdm(1154)───init(1173)───yes(24997)

    (The actual numbers and programs may vary, but the first init will always have pid 1.)
    As you can see, the yes command wasn't killed, and got attached to init because its parent was killed. It's still merrily printing ys on the first terminal. So kill it with pkill -f yes. Now repeat the experiment, with one change. Instead of pkill -f test, do:

    kill -INT -25165 
# Use the pid of test.sh given in parentheses in the output of pstree 
# instead of 25165

    Note the leading -. In Linux, for the kill command, -25165 is the process group, whose leader has pid 25165. Thus, this command is the equivalent of sending an interrupt from the terminal.

    Of course, the exact behaviour depends on the configuration of the TTY, the login shell and so on. This is as far as my understanding goes. Further reading:

    I suggest:

    1. Sending the tail to the background
    2. Trap the signal
    3. Kill the background process.
    4. Remove the trap

    An example:

    #! /bin/bash

kill_jobs ()
{
    kill %1
}

while true
do
    if [[ $1 = "a" ]]
    then
        trap kill_jobs INT
        tail -f /var/log/syslog &
        wait %%
        shift #You don't need to shift, I just didn't want loop tail on this example
        trap - INT
    else
        echo some output
        sleep 2
    fi
done

    This can become very powerful, by using different functions for trapping, and each doing their own clean up work.

    • 7