当发送到包含子项的 Perl 脚本时，SIGINT (^C) 会发生什么情况？

Question

我有一个可以分叉的 Perl 脚本。

每个分支运行一个外部程序，解析输出，并将输出转换为可存储文件。

然后，父级读入可存储文件，并分析每个子级的总数据，然后继续重复前一个分支，否则父级将停止。

当我发出 ^C 而一些孩子仍在运行外部程序时，到底会发生什么？父 Perl 脚本在前台被调用，并且我认为尽管有分叉，它仍保留在前台。

SIGINT是否传递给所有子进程，即父进程、父进程的子进程以及子进程调用的外部程序？

更新：

我应该补充一点，当我发出 SIGINIT 时，我的脚本子级调用的外部程序似乎确认了该信号并终止。但孩子们，或者也许是家长计划，仍在继续。这对我来说都是不清楚的。

更新2：

关于tchrist的评论，外部程序是用Perl的system()命令调用的。

事实上，tchrist的评论似乎也包含了我一直在寻找的解释。经过更多调试后，根据我的程序的行为，似乎 SIGINT 确实从父级传递到所有子级，并从所有子级传递到其所有子级（外部程序）。

因此，根据 tchrist 的评论，似乎正在发生的事情是 CTRL-C 正在杀死外部程序，导致子级移出 system() 命令 - 仅此而已。

虽然我让我的孩子检查 system() 中调用的退出状态，但我假设 CTRL-C 会杀死从父级开始的所有内容，而不是导致创建更多轮次处理，这就是发生的事情！

解决方案（针对我的问题）：

我只需在父级中为 SIGINT 创建一个信号处理程序。然后，信号处理程序将向每个子级发送 SIGTERM（我认为也会向子级的子级发送 SIGTERM），然后导致父级正常退出。虽然这个有点明显的解决方案可能会解决一些问题，但我想了解我对 SIGINT 在 Perl 中 fork 的行为的误解。

Answer 1

就信号而言，Perl 的内置 system 函数的工作方式与标准 C 库中的 C system(3) 函数类似。如果您使用 Perl 版本的 system() 或管道打开或反引号，则父级（调用 system 的那个而不是被它调用的那个）将忽略任何 SIGINT并在孩子们跑步时发出 SIGQUIT 信号。如果您使用 fork?wait:exec 三重奏的某些变体自行推出，那么您必须自己考虑这些问题。

考虑一下当您使用 system("vi somefile") 并在 vi 中进行长时间搜索时点击 ^C 时会发生什么：只有 vi 接受 (非致命）SIGINT；家长忽略它。这是正确的行为。这就是 C 如此工作的原因，也是 Perl 如此工作的原因。

您必须记住的是，仅仅因为 ^C 向前台进程组中的所有进程（甚至是具有不同有效 UID 或 GID 的进程）发送 SIGINT，并不意味着它会导致所有进程那些进程退出。 ^C 只是一个 SIGINT，意味着中断进程，而不是 SIGKILL，意味着不问任何问题就终止。

有很多种程序，在没有警告的情况下直接杀死是错误的；编辑只是这样的一个例子。邮寄者可能是另一个。对此要格外小心。

许多类型的程序选择性地忽略、捕获或阻止（意味着延迟传递）各种类型的信号。只有 SIGINT 的默认行为是导致进程退出。您可以使用传统操作系统上的此类代码来查明这种情况是否发生，以及实际上是哪个信号导致它发生（除其他外）：

if ($wait_status = system("whatever")) {
    $sig_killed   = $wait_status & 127;
    $did_coredump = $wait_status & 128;
    $exit_status  = $wait_status >>  8;
    # now do something based on that...
}

请仔细注意，^C'd vi，例如，将不会有一个等待状态字，表明它因未捕获的SIGINT而死亡，因为没有一个等待状态字：它捕获了它。

有时你的孩子会背着你生下自己的孩子。凌乱但真实。因此，有时我会以这种方式种族灭绝所有已知和未知的后代：

# scope to temporize (save+restore) any previous value of $SIG{HUP}
{
    local $SIG{HUP} = "IGNORE";
    kill HUP => -$;   # the killpg(getpid(), SIGHUP) syscall
}

这当然不适用于 SIGKILL 或 SIGSTOP，它们不适合被这样忽略。

您可能需要注意的另一件事是，在 5.8 版本之前，Perl 中的信号处理在历史上并不是一种可靠的安全操作。现在是，但这是一个与版本相关的问题。如果您还没有这样做，那么您一定应该阅读 perlipc 联机帮助页 中的延迟信号，也许还有 PERL_SIGNALS 位于 perlrun 联机帮助页 中。

Answer 2

当您在终端窗口（或任何终端）中点击 ^C 时，它将向该终端中的前台进程组发送 SIGINT。现在，当您从命令行启动程序时，它通常位于其自己的进程组中，并且成为前台进程组。默认情况下，当您分叉一个子进程时，它将与父进程位于同一进程组中，因此默认情况下，父进程（从命令行调用的顶级程序）、其所有子进程、子进程的子进程等，以及由其中任何一个（都只是子进程）调用的任何外部程序都将位于同一进程组中，因此都将收到 SIGINT 信号。

但是，如果这些子进程或程序中的任何一个调用 setpgrp 或 setpgid 或 setsid，或者导致进程成为新进程组中的任何其他调用，则这些进程（以及它们在离开前台进程组后启动的任何子进程）将不会接收 SIGINT。

此外，当进程收到 SIGINT 时，它可能不会终止——它可能会忽略该信号，或者可能会捕获该信号并执行完全不同的操作。 SIGINT 的默认信号处理程序会终止进程，但这只是可以覆盖的默认值。

编辑

从您的更新来看，听起来一切都保留在同一个进程组中，因此信号正在传递给每个人，因为孙子（外部程序）正在退出，但孩子们正在捕捉并忽略 SIGINT。根据 tchrist 的评论，这听起来像是 perl 的默认行为。

Answer 3

如果您终止父进程，子进程（以及正在运行的外部程序）仍将运行，直到它们以某种方式终止。如果父进程有一个信号处理程序来捕获 SIGINT，然后杀死进程组（通常是父进程的 pid），则可以避免这种情况。这样，一旦父进程收到 SIGINT，它就会杀死所有的子进程。

因此，要回答您的问题，这完全取决于信号处理程序的实现。根据您的更新，似乎父级确实杀死了它的子级，然后它没有终止自己，而是回去做其他事情（将其视为重置而不是完全关闭/启动组合）。