有如下shell 脚本 pingoo.sh

#!/bin/bash
while true
do     
    ping 127.0.0.1
done;

$> pingoo.sh

键盘键入 ctrl +c(^c)
ooooops!
你会发现无论你按多少次都无法终止该脚本的运行.

使用ps 命令找到进程树

$> ps -j f
 PID  PGID   SID TTY      STAT   TIME COMMAND
21994 21994 21994 pts/29   Ss     0:00 /bin/bash
28833 28833 21994 pts/29   S+     0:00  \_ /bin/bash ./pingoo.sh
28834 28833 21994 pts/29   S+     0:00      \_ ping 127.0.0.1

STAT 进程状态标志:
S: 可中断的sleep,
s: session leader;
+: 前台进程;

首先要明确一个重要假设：当用户按下Ctrl c 时, 他是要终止前台进城组的运行, 出发进程注册了自定义的信号处理函数;

但是如果子进程capture sigint， 则 shell 会假设用户通过发送sigint 使子进程做特定工作（比如ping的统计信息）， 也就说用户发送sigint的目的并不是结束前台进程组， 而是触发特定动作；ping 就是这类安装了自定义的信号处理函数的进程;

当你按下ctrl c后发生了什么?

ctrl +c 被终端驱动程序解释为 sigint 信号， 由kernel 发送给 前台进程组 . ping 进程 capture 该信号， 调用信号处理函数。 同时， ping的父进程也收到sigint信号(父进程处理interruptible sleep 状态, 也就出出于wait系统调用中)， 父进程被迫退出wait系统调用,检查退出原因(是否是EINTR,也就是中断的系统调用),然后通过WIFSIGNALED宏可以判断子进程是否注册了信号处理函数 。如果 注册了信号处理函数,capture sigint， 父进程继续运行（当前例子是开始下一次循环）； 如果是子进程是因收到sigint信号终止的（按照default 方式处理sigint）， 父进程会终止运行.

当用户键入ctrl+c后，tty driver 产生SIGINT信号给前台进程, pingoo.sh和其子进程 都看见sigint信号，（他们是前台进程组成员）。 ping.sh作为父进程处于waitpid blocking状态， 收到sigint 后waitpid 立即返回 -1， 设置errorno为 EINTR。同时 bash要求child 立即死亡（也就是sigint的默认动作 terminate）。最后设置 child_caught_sigint = 0， bash 随后会根据该flag 退出;

如果child capture signal，设置 child_caught_sigint = 1; bash 根据该flag 不退出， 因为子进程capture sigint后， 触发信号处理函数。 其信号处理函数需要做特定处理，如果子进程退出，则 父进程会受到 sigchld 信号，父进程会认为子进程正常退出， 循环继续。

源代码解析：

bash 4.3.3: jobs.c

1. waitpid
   pid<-1 等待进程组识别码为 pid 绝对值的任何子进程。
   pid=-1 等待任何子进程,相当于 wait()。
   pid=0 等待进程组识别码与目前进程相同的任何子进程。
   pid>0 等待任何子进程识别码为 pid 的子进程。

Process-Completion-Status

2. WIFSIGNALED:
   This macro returns a nonzero value if the child process terminated because it received a signal that was not handled.
3. WTERMSIG:
   If WIFSIGNALED is true of <var style="background-color: inherit;">status</var>, this macro returns the signal number of the signal that terminated the child process

  /* If waitpid returns -1/EINTR and the shell saw a SIGINT, then we
     assume the child has blocked or handled SIGINT.  In that case, we
     require the child to actually die due to SIGINT to act on the
     SIGINT we received; otherwise we assume the child handled it and
     let it go. */
// status = waitpid（pid）， pid <0 
      if (pid < 0 && errno == EINTR && wait_sigint_received)
    child_caught_sigint = 1;  //waitpid被 sigint中断，立即 假设此时 子进程也 capture signit 

      if (pid <= 0)
    continue;    /* jumps right to the test */

      /* If the child process did die due to SIGINT, forget our assumption
     that it caught or otherwise handled it. */
      if (WIFSIGNALED (status) && WTERMSIG (status) == SIGINT)
        child_caught_sigint = 0; 

  if (JOBSTATE (job) == JDEAD)
    {
      /* If we're running a shell script and we get a SIGINT with a
     SIGINT trap handler, but the foreground job handles it and
     does not exit due to SIGINT, run the trap handler but do not
     otherwise act as if we got the interrupt. */
// wait_sigint_received :  wait 阻塞中收到sigint，
// child_caught_sigint ： 子进程 capture sigint
// IS_FOREGROUND ： 前台进程组
// interactive_shell ： 交互shell？
// signal_is_trapped : 
      if (wait_sigint_received && interactive_shell == 0 &&
      child_caught_sigint && IS_FOREGROUND (job) &&
      signal_is_trapped (SIGINT))
    {
      int old_frozen;
      wait_sigint_received = 0;
      last_command_exit_value = process_exit_status (child->status);

      old_frozen = jobs_list_frozen;
      jobs_list_frozen = 1;
      tstatus = maybe_call_trap_handler (SIGINT); // 
      jobs_list_frozen = old_frozen;
    }

如何终止该脚本的运行呢:

$> kill -9 28833 28834

一定要先杀死父进程