linux - 什么时候处理信号以及为什么某些信息会卡住？

Question

1. 打开名为“termA”的终端，并使用/bin/bash callback.sh 运行创建的文件callback.sh。

   cat  callback.sh
   #!/bin/bash
   myCallback() {
       echo "callback function called at $(date)"
   }
   trap myCallback SIGUSR1
   sleep 20 
   

2. 打开一个名为“termB”的新终端并运行:

   pkill -USR1  -f  callback.sh
   

termA 中 20 秒后显示如下内容；它永远不会立即显示在 termA 中:

callback function called at Mon Nov 19 08:21:52 HKT 2018

结论验证了当 Bash 在前台执行外部命令时，它不会处理接收到的任何信号，直到前台进程终止(参见 signal trap )。

在 callback.sh 中做一点改动:

cat  callback.sh
#!/bin/bash
myCallback() {
    echo "callback function called at $(date)"
}
trap myCallback SIGUSR1
while true; do
    read -p  "please input something for foo: " foo
done

添加一个无限 while 循环并删除 sleep 20。

1. 打开名为“termA”的终端并使用/bin/bash callback.sh 运行创建的文件callback.sh；第一次，信息会立即弹出。

   please input something for foo: 
   

2. 打开一个名为“termB”的新终端并运行pkill -USR1 -f callback.sh；第一次，信息会立即在 termA 中弹出。

   callback function called at Mon Nov 19 09:07:14 HKT 2018
   

问题 1: callback.sh 包含无限 while 循环。这如何解释以下内容？

it does not handle any signals received until the foreground process terminates

在这种情况下，前台进程永远不会终止。

进入termB，第二次运行pkill -USR1 -f callback.sh。

callback function called at Mon Nov 19 09:07:14 HKT 2018

上面的信息再次在 termA 中立即弹出。

问题 2: 没有 please input something for foo: 显示在 termA，转到termB，第三次运行pkill -USR1 -f callback.sh，以下信息再次显示在 termA 中。

callback function called at Mon Nov 19 09:07:24 HKT 2018

仍然没有 please input something for foo: 显示在 termA 中。
为什么信息 please input something for foo: 卡住了？

Answer 1

在解释你的问题之前，先了解一下如何使用 read 的背景知识命令有效。它从 stdin 中读取输入数据直到 EOF遇到。调用电话是安全的 read从磁盘文件读取时，命令是非阻塞的。但是当stdin已连接到终端，命令将阻塞，直到用户键入内容。

信号处理程序如何工作？

有关信号处理工作原理的简单说明。请参阅 C 中的以下片段它只作用于 SIGINT (又名 CTRL+C)

#include <stdio.h>
#include <signal.h>

/* signal handler definition */
void signal_handler(int signum){
  printf("Hello World!\n");
}

int main(){
  //Handle SIGINT with a signal handler
  signal(SIGINT, signal_handler);
  //loop forever!
  while(1);
}

它将注册信号处理程序，然后进入无限循环。当我们点击 Ctrl-C , 我们都同意信号处理程序 signal_handler()应该执行 "Hello World!"打印到屏幕，但程序处于无限循环中。为了打印"Hello World!"一定是它打破了执行信号处理程序的循环，对吧？所以它应该退出循环以及程序。让我们看看:

gcc -Wall -o sighdl.o signal.c
./sighdl.o 
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!

如输出所示，每次我们发出 Ctrl-C , "Hello World!"打印，但程序返回到无限循环。只有在发出 SIGQUIT 之后用 Ctrl-\ 发出信号程序真的退出了吗？取决于你的ulimit设置，它会转储一个核心或打印出接收到的信号编号。

虽然循环将退出的解释是合理的，但它没有考虑信号处理的主要原因，即异步事件处理。这意味着信号处理程序的行为超出了程序控制的标准流程；事实上，整个程序都保存在一个上下文中，并且会创建一个新的上下文来仅供信号处理程序在其中执行。一旦信号处理程序完成其操作，上下文就会切换回来并开始正常的执行流程(即while(1) ).

回答你的问题，

The conclusion verified that When bash is executing an external command in the foreground, it does not handle any signals received until the foreground process terminates

这里要注意的关键是外部命令部分。在第一种情况下，sleep是一个外部进程，但在第二种情况下，read是 shell 本身的内置。所以在这两种情况下，信号向这两者的传播是不同的

type read
read is a shell builtin
type sleep
sleep is /usr/bin/sleep

1.Open a terminal,named termA ,and run the created file callback.sh with /bin/bash callback.sh for first time,the info pop up instantly.

是的，这种行为是意料之中的。因为此时只定义了函数，将trap handler注册到函数myCallback并且脚本中尚未收到信号。随着执行顺序的进行，来自 read 的消息第一次抛出提示。

2.Open a new terminal ,named termB and run pkill -USR1 -f callback.sh first time,the info pop up instantly in termA

是的，而 read命令正在等待字符串，后跟 Enter 键，表示 EOF ，它接收到一个信号 SIGUSR1从另一个终端，当前执行上下文被保存并且控制被切换到信号处理程序，该信号处理程序打印带有当前日期的字符串。

一旦处理程序完成执行，上下文就会恢复到 while read 循环命令仍在等待输入字符串。直到 read命令成功，所有后续信号陷阱将只打印信号处理程序中的字符串。

Go on in termB,run pkill -USR1 -f callback.sh the second time.

与前面解释的一样，read命令在你的 while 循环中没有完成一次，只有当它成功读取一个字符串时，循环的下一次迭代才会开始并抛出一个新的提示消息。

---

图片来源:Michael KerrisK 的 Linux 编程接口(interface)