bash 使用陷阱 SIGCHLD 重新启动子进程？

Question

我在脚本中看到监控程序使用“ps”或“服务状态(在 Linux 上)”定期检查进程状态，或者在 C/C++ 中 fork 并等待进程...

我想知道是否可以将 bash 与 trap 一起使用并在收到 SIGCLD 时重新启动子进程？

我已经用下面的想法在 RedHat Linux 上测试了一个基本套件(当然它没有用......)

#!/bin/bash
set -o monitor # can someone explain this? discussion on Internet say this is needed
trap startProcess SIGCHLD
startProcess() { 
  /path/to/another/bash/script.sh & # the one to restart
  while [ 1 ]
  do
    sleep 60
  done
}
startProcess

正在启动的 bash 脚本只是休眠几秒钟，然后暂时退出。

观察到的几个问题:

• 当 shell 在前台启动时，SIGCHLD 只会被处理一次。陷阱复位信号处理是否像 signal() 一样？
• 脚本及其子脚本似乎对 SIGINT 免疫，这意味着它们不能被 ^C 停止
• 因为无法关闭，所以我关闭了终端。剧本似乎是HUP，留下了很多僵尸 child 。
• 在后台运行时，脚本导致终端死机

...无论如何，这根本行不通。我不得不说我对这个话题知之甚少。有人可以建议或提供一些工作示例吗？是否有用于此类用途的脚本？

那么在 bash 中使用 wait 怎么样？

谢谢

Answer 1

我可以尝试回答你的一些问题，但不是所有基于我的知道。

1. set -o monitor 行(或等效的 set -m)打开作业控制，它仅在交互式 shell 中默认打开。这似乎需要发送 SIGCHLD。但是，作业控制更多一种交互式功能，并不是真的要在 shell 脚本中使用(另请参见 this question)。

   另请记住，这可能不是您打算做的因为一旦启用作业控制，SIGCHLD 将被发送给 every存在的外部命令(例如，每次运行 ls 或 grep 或任何东西，当该命令完成并且您的陷阱时，SIGCHLD 将触发将运行)。

2. 我怀疑 SIGCHLD 陷阱似乎只运行一次的原因是因为你的陷阱处理程序包含一个前台无限循环，所以你的脚本卡在陷阱处理程序中。似乎没有意义无论如何到那个循环，所以你可以简单地删除它。

3. 脚本对 SIGINT 的“免疫力”似乎是启用作业控制(监视器部分)。我的直觉是打开作业控制，运行脚本的 bash 子实例不再终止本身响应 SIGINT，而是将 SIGINT 传递给它的前台子进程。在您的脚本中， ^C 即 SIGINT就像其他编程语言中的 continue 语句一样在这种情况下，由于 SIGINT 只会杀死当前正在运行的 sleep 60，于是 while 循环将立即运行一个新的 sleep 60。

4. 当我尝试运行您的脚本然后终止它时(从另一个终端)，我最终得到的只是两个杂散的 sleep 过程。

5. 后台脚本也为我杀死了我的 shell，尽管行为不是非常一致(有时会发生立即，其他时候根本没有)。似乎键入其他任何键比 enter 导致 EOF 以某种方式发送。即使在终端之后退出脚本继续在后台运行。我不知道这是怎么回事。

更具体地说明您想要完成的事情会有所帮助。如果您只需要一个命令在您的生命周期内连续运行脚本，你可以在后台运行一个无限循环，比如

while true; do
    some-command
    echo some-command finished
    echo restarting some-command ...
done &

注意 done 之后的 &。

对于其他任务，wait 可能比使用作业控制更好在 shell 脚本中。同样，这取决于您到底在尝试什么做。