mjhjmtu

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?

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

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.

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.

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)

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.