为什么将 SIGTTOU 信号传递给进程？答案

【问题标题】：Why is SIGTTOU signal being delivered to the process?为什么将 SIGTTOU 信号传递给进程？
【发布时间】：2021-03-15 07:59:23
【问题描述】：

我试图构建一个在 ZSH shell 中运行的交互式 shell。任何命令都将在它自己的进程组中执行（因此我使用tcsetpgrp 调用使其成为前台进程组，一旦执行命令，交互式shell 将成为前台进程组）。但是我观察到，在我的代码执行过程中，我收到了一个 SIGTTOU 信号，据我所知，当后台进程尝试写入终端时，该信号就会传递。对于下面的示例，如果有人可以解释上述信号的原因，那将非常有帮助。

最小的可重现示例

#include <sys/types.h>
#include <termios.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>
int main()
{
    for(;;){
        printf(">Network shell\n");   
        int par = getpid();
        int child = fork();
        if(child == 0){
            int c2 = fork();
            if(c2 == 0){
                char * args[2];
                args[0]="/bin/ls";
                args[1] = NULL;
                execv(args[0], args);
            }
            else{
                wait(NULL);
                tcsetpgrp(STDIN_FILENO, par); //done to bring previous process group back to foreground
                tcsetpgrp(STDOUT_FILENO, par);
            }


        }
        else{
            setpgid(child, child);
            tcsetpgrp(STDIN_FILENO, child);
            tcsetpgrp(STDOUT_FILENO, child);

            wait(NULL);
        }


    }

}

这是我在终端上看到的输出：

【问题讨论】：

标签： c shell signals job-control

【解决方案1】：

你的/bin/ls 写入标准输出，由于它的标准输出没有被重定向，它写入终端。

【讨论】：

/bin/ls 写入标准输出，但当前执行命令的进程是前台进程组的一部分，因此我认为它不应该引发 SIGTTOU 信号。
在“第一次”分叉之后，您处于原始“主”进程的子进程中，在第二次分叉之后，您处于前一个进程的子进程中。您有两个进程（两个 else 块，即原始父进程和第一个子进程），它们都想用 tcsetpgrp 接管终端。
@ANIRUDHBUVANESH ：至于信号，我认为属于c2 案例的else 块作为原始主进程的子进程运行，因此在后台运行。但是当后台进程正在执行tcsetpgrp 时，这会导致向其他后台进程发送 SIGTTOU。
第一个 fork 后的tcsetpgrp 将新创建的进程组作为前台，第二个 fork 后的tcsetpgrp 将原始进程组带回前台。您是否暗示过同步问题？您能否详细说明为什么您认为 c2 中的 else 块作为主进程的子进程运行，它不是作为新进程组中的组长运行在其中吗
第一次fork后，child进程中child为0； else 块仍然是主要进程。因此，c2 fork 本身因此在第一个子进程内运行并包含一个新子进程（c2==0 分支）。 c2-child 不是作为主进程的直接子进程运行，而是作为其子进程运行。