Unable to stop a bash script with Ctrl+C

Question

I wrote a simple bash script with a loop for printing the date and ping to a remote machine:

#!/bin/bash
while true; do
    #     *** DATE: Thu Sep 17 10:17:50 CEST 2015  ***
    echo -e "\n*** DATE:" `date` " ***";
    echo "********************************************"
    ping -c5 $1;
done

When I run it from a terminal I am not able to stop it with Ctrl+C. It seems it sends the ^C to the terminal, but the script does not stop.

MacAir:~ tomas$ ping-tester.bash www.google.com

*** DATE: Thu Sep 17 23:58:42 CEST 2015  ***
********************************************
PING www.google.com (216.58.211.228): 56 data bytes
64 bytes from 216.58.211.228: icmp_seq=0 ttl=55 time=39.195 ms
64 bytes from 216.58.211.228: icmp_seq=1 ttl=55 time=37.759 ms
^C                                                          <= That is Ctrl+C press
--- www.google.com ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 40.887/59.699/78.510/18.812 ms

*** DATE: Thu Sep 17 23:58:48 CEST 2015  ***
********************************************
PING www.google.com (216.58.211.196): 56 data bytes
64 bytes from 216.58.211.196: icmp_seq=0 ttl=55 time=37.460 ms
64 bytes from 216.58.211.196: icmp_seq=1 ttl=55 time=37.371 ms

No matter how many times I press it or how fast I do it. I am not able to stop it.
Make the test and realize by yourself.

As a side solution, I am stopping it with Ctrl+Z, that stops it and then kill %1.

What is exactly happening here with ^C?

Answer 1

What happens is that both bash and ping receive the SIGINT (bash being not interactive, both ping and bash run in the same process group which has been created and set as the terminal's foreground process group by the interactive shell you ran that script from).

However, bash handles that SIGINT asynchronously, only after the currently running command has exited. bash only exits upon receiving that SIGINT if the currently running command dies of a SIGINT (i.e. its exit status indicates that it has been killed by SIGINT).

$ bash -c 'sh -c "trap exit\ 0 INT; sleep 10; :"; echo here'
^Chere

Above, bash, sh and sleep receive SIGINT when I press Ctrl-C, but sh exits normally with a 0 exit code, so bash ignores the SIGINT, which is why we see "here".

ping, at least the one from iputils, behaves like that. When interrupted, it prints statistics and exits with a 0 or 1 exit status depending on whether or not its pings were replied. So, when you press Ctrl-C while ping is running, bash notes that you've pressed Ctrl-C in its SIGINT handlers, but since ping exits normally, bash does not exit.

If you add a sleep 1 in that loop and press Ctrl-C while sleep is running, because sleep has no special handler on SIGINT, it will die and report to bash that it died of a SIGINT, and in that case bash will exit (it will actually kill itself with SIGINT so as to report the interruption to its parent).

As to why bash behaves like that, I'm not sure and I note the behaviour is not always deterministic. I've just asked the question on the bash development mailing list (Update: @Jilles has now nailed down the reason in his answer).

The only other shell I found that behave similarly is ksh93 (Update, as mentioned by @Jilles, so does FreeBSD sh). There, SIGINT seems to be plainly ignored. And ksh93 exits whenever a command is killed by SIGINT.

You get the same behaviour as bash above but also:

ksh -c 'sh -c "kill -INT \$\$"; echo test'

Doesn't output "test". That is, it exits (by killing itself with SIGINT there) if the command it was waiting for dies of SIGINT, even if it, itself didn't receive that SIGINT.

A work around would be to do add a:

trap 'exit 130' INT

At the top of the script to force bash to exit upon receiving a SIGINT (note that in any case, SIGINT won't be processed synchronously, only after the currently running command has exited).

Ideally, we'd want to report to our parent that we died of a SIGINT (so that if it's another bash script for instance, that bash script is also interrupted). Doing an exit 130 is not the same as dying of SIGINT (though some shells will set $? to same value for both cases), however it's often used to report a death by SIGINT (on systems where SIGINT is 2 which is most).

However for bash, ksh93 or FreeBSD sh, that doesn't work. That 130 exit status is not considered as a death by SIGINT and a parent script would not abort there.

So, a possibly better alternative would be to kill ourself with SIGINT upon receiving SIGINT:

trap '
  trap - INT # restore default INT handler
  kill -s INT "$$"
' INT

Answer 2

The explanation is that bash implements WCE (wait and cooperative exit) for SIGINT and SIGQUIT per http://www.cons.org/cracauer/sigint.html. That means that if bash receives SIGINT or SIGQUIT while waiting for a process to exit, it will wait until the process exits and will exit itself if the process exited on that signal. This ensures that programs that use SIGINT or SIGQUIT in their user interface will work as expected (if the signal did not cause the program to terminate, the script will continue normally).

A downside appears with programs that catch SIGINT or SIGQUIT but then terminate because of it but using a normal exit() instead of by resending the signal to themselves. It may not be possible to interrupt scripts that call such programs. I think the real fix there is in such programs such as ping and ping6.

Similar behaviour is implemented by ksh93 and FreeBSD's /bin/sh, but not by most other shells.

Answer 3

The terminal notices the control-c and sends an INT signal to the foreground process group, which here includes the shell, as ping has not created a new foreground process group. This is easy to verify by trapping INT.

#! /bin/bash
trap 'echo oh, I am slain; exit' INT
while true; do
  ping -c5 127.0.0.1
done

If the command being run has created a new foreground process group, then the control-c will go to that process group, and not to the shell. In that case, the shell will need to inspect exit codes, as it will not be signalled by the terminal.

(INT handling in shells can be fabulously complicated, by the way, as the shell sometimes needs to ignore the signal, and sometimes not. Source dive if curious, or ponder: tail -f /etc/passwd; echo foo)

Answer 4

As you surmise, this is due to the SIGINT being sent to the subordinate process, and the shell continuing on after that process exits.

To handle this in a better way, you can check the exit status of the commands which are running. The Unix return code encodes both the method by which a process exited (system call or signal) and what value was passed to exit() or what signal terminated the process. This is all rather complicated, but the quickest way of using it is to know that a process that was terminated by signal will have a non-zero return code. Thus, if you check the return code in your script, you can exit yourself if the child process was terminated, removing the need for inelegancies like unnecessary sleep calls. A quick way to do this throughout your script is to use set -e, though it may require a few tweaks for commands whose exit status is an expected nonzero.

Answer 5

Well, I tried to add a sleep 1 to the bash script, and bang!
Now I'm able to stop it with two Ctrl+C.

When pressing Ctrl+C, a SIGINT signal is sent to the process currently executed, which command was run inside the loop. Then, the subshell process continues executing the next command in the loop, that starts another process. To be able to stop the script it is necessary to send two SIGINT signals, one to interrupt the current command in execution and one to interrupt the subshell process.

In the script without the sleep call, pressing Ctrl+C really fast and many times does not seem to work, and it is not possible to exit the loop. My guess is that pressing twice is not enough fast to make it just in the right moment between the interruption of current executed process and the start of the next one. Every Ctrl+C pressed will send a SIGINT to a process executed inside the loop, but neither to the subshell.

In the script with sleep 1, this call will suspend the execution for one second, and when interrupted by the first Ctrl+C (first SIGINT), the subshell will take more time to execute the next command. So now, the second Ctrl+C (second SIGINT) will go to the subshell, and the script execution will end.

Answer 6

If anybody's interested in a fix for this bash feature, and not so much in the philosophy behind it, here is a proposal:

Don't run the problematic command directly, but from a wrapper which a) waits for it to terminate b) doesn't mess with signals and c) does not implement the WCE mechanism itself, but simply dies upon receiving a SIGINT.

Such a wrapper could be made with awk + its system() function.

$ while true; do awk 'BEGIN{system("ping -c5 localhost")}'; done
PING localhost(localhost (::1)) 56 data bytes
64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.082 ms
64 bytes from localhost (::1): icmp_seq=2 ttl=64 time=0.087 ms
^C
--- localhost ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1022ms
rtt min/avg/max/mdev = 0.082/0.084/0.087/0.009 ms
[3]-  Terminated              ping -c5 localhost

Put in a script like OP's:

#!/bin/bash
while true; do
        echo -e "\n*** DATE:" `date` " ***";
        echo "********************************************"
        awk 'BEGIN{system(ARGV[1])}' "ping -c5 ${1-localhost}"
done

Answer 7

Try this:

#!/bin/bash
while true; do
   echo "Ctrl-c works during sleep 5"
   sleep 5
   echo "But not during ping -c 5"
   ping -c 5 127.0.0.1
done

Now change the first line to:

#!/bin/sh

and try again - see if the ping is now interruptible.

Answer 8

pgrep -f process_name > any_file_name
sed -i 's/^/kill /' any_file_name
chmod 777 any_file_name
./any_file_name

for example pgrep -f firefox will grep the PID of running firefox and will save this PID to a file called any_file_name. 'sed' command will add the kill in the beginning of the PID number in 'any_file_name' file. Third line will any_file_name file executable. Now forth line will kill the PID available in the file any_file_name. Writing the above four lines in a file and executing that file can do the Control-C. Working absolutely fine for me.

Answer 9

You are a victim of a well known bash bug. Bash does jobcontrol for scripts which is a mistake.

What happens is that bash runs the external programs in a different process group than it uses for the script itself. As the TTY processgroup is set to the processgroup of the current foreground process, only this foreground process is killed and the loop in the shell script continues.

To verify: Fetch and compile a recent Bourne Shell that implements pgrp(1) as a builtin program, then add a /bin/sleep 100 (or /usr/bin/sleep depending on your platform) to the script loop and then start the Bourne Shell. After you used ps(1) to obtain the process IDs for the sleep command and the bash that runs the script, call pgrp <pid> and replace "< pid >" by the process ID of the sleep and the bash that runs the script. You will see different process group IDs. Now call something like pgrp < /dev/pts/7 (replace the tty name by the tty used by the script) to obtain the current tty process group. The TTY process group equals the process group of the sleep command.

To fix: use a different shell.

The recent Bourne Shell sources are in my schily tools package which you can find here:

http://sourceforge.net/projects/schilytools/files/