相关疑难解决方法(0)

我有时会对进程可以接收的所有信号感到困惑。据我了解，一个进程对这些信号中的每一个都有一个默认处理程序（信号处置），但它可以通过调用sigaction().

所以这是我的问题：是什么导致每个信号被发送？我意识到您可以通过-s参数 to手动向正在运行的进程发送信号kill，但是发送这些信号的自然情况是什么？例如，什么时候SIGINT发送？

另外，对可以处理哪些信号有任何限制吗？甚至SIGSEGV可以处理信号并将控制权返回给应用程序吗？

假设我从终端打开了一些程序，并将其stdin和stdout和重定向stderr到三个文件。

即使该程序不再将其输出发送到终端并且不再从终端接收其输入，该程序仍然具有到终端的“链接”。程序与之“链接”的终端称为控制终端，下图说明了这一点：

我的问题是：控制终端的目的是什么，我的猜测是控制终端可以用来向程序发送信号（例如：）Ctrl+C。

控制终端还有其他用途吗？

从我的理解，工作是管道从某一个shell启动的，你可以管理这些作业（fg，bg，按Ctrl-Z）从该壳体内。一个作业可以由多个进程/命令组成。

我的问题是当原始的包含 shell 退出时这些作业会发生什么？假设未设置 huponexit 以便后台进程在 shell 退出后继续运行。

假设我已经做了：

$ run.sh | grep 'abc' &
[1] job_id

然后我退出这个shell。我将进入一个新的 shell 并运行jobs，但显然什么也看不到。但是我可以执行ps aux | grep run.sh并查看此进程的运行情况，我也会执行ps aux | grep grep并查看grep 'abc'运行的进程。

有没有办法只获取完整管道的作业 ID，以便我可以一次性杀死它，或者我是否必须在退出原始 shell 后与另一个 shell 分开杀死所有进程？（我尝试过后者并且它有效，但跟踪所有过程似乎很麻烦。）

终端的输入是否通过 bash 进程路由到当前正在运行的程序中，或者终端是否与 bash 进程“断开连接”并连接到新程序，以防止 bash 拦截或干扰？

bash 只是在后台冻结，等待您开始关闭的程序，还是正在执行某些操作？

当我关闭终端窗口时，我是否向 bash 发送信号，后者又向前台进程发送信号以关闭它们？或者我是否向前台进程发送了一个信号，该信号向上传播到 bash？

我正在尝试为我的宠物操作系统正确模拟 POSIX 信号处理和作业控制，但我不清楚会话领导者退出后会话会发生什么。

我找不到与会话及其进程发生的情况相关的文档，例如，如果一个孩子在几个后台进程和一个不同的前台进程正在运行时杀死了会话领导者。

我的测试表明会话中的所有进程都被杀死了，但是如何？
他们收到特定的信号吗？
这种情况是否在 POSIX 标准中指定？如果是这样，你能提供一些参考吗？