为什么vim成为孤立进程会崩溃？

如何解决为什么vim成为孤立进程会崩溃？

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>

int main()
{
    int pid = fork();
    
    if (pid) {
        sleep(5);
        // wait(NULL); // works fine when waited for it.
    } else {
        execlp("vim","vim",(char *)NULL);
    }
}

当我运行这段代码时，vim会正常运行，然后在5秒钟后崩溃（即其父级退出时）。当我等待它时（即不让它成为孤立进程），代码可以正常工作。

为什么在这里成为孤立进程会成为问题？这是vim特有的吗？

为什么这甚至是vim可见的东西？我以为只有父母知道孩子何时死亡。但是在这里，我看到孩子以某种方式注意到它被收养的时候，发生了一些事情，并以某种方式使其崩溃。当父母也去世时，孩子的流程会得到通知吗？

运行此代码时，崩溃后得到以下输出：

Vim: Error reading input,exiting...
Vim: preserving files...
Vim: Finished.

解决方法

这实际上是因为 shell 正在执行执行分叉Vim的二进制文件！

当外壳程序运行前台命令时，它将创建一个新的进程组，并使其成为连接到该外壳程序的终端的前台进程组。在bash 5.0中，您可以在give_terminal_to()中找到转移此职责的代码，该代码使用tcsetpgrp()来设置前台进程组。

必须正确设置终端的前台进程组，以便在前台运行的程序可以从终端获取信号（例如，Ctrl + C发送中断信号，Ctrl + Z发送终端停止信号（以暂停该过程），并以Vim等全屏程序通常采用的方式更改终端设置。 （前台进程组的主题对此问题有点超出范围，因为它在响应中发挥了作用，所以在这里只提及它。）

当Shell执行的进程（更确切地说是管道）终止时，Shell将使用相同的give_terminal_to()代码并通过 shell 调用它，以收回前台进程组。 >的进程组。

这通常很好，因为在执行的管道完成时，该进程组上通常没有进程，或者如果有进程，它们通常不保留在终端上（例如，如果您从外壳启动后台守护程序，该守护程序通常会关闭stdin / stdout / stderr流以放弃对终端的访问。）

但是，您建议的设置并非如此，Vim仍连接到终端和前台进程组的一部分。当父进程退出时，shell假定流水线已完成，它将把前台进程组重新设置回自己，从前一个前台进程组（即Vim所在的位置）“窃取”它。因此，下次Vim尝试从终端读取时，读取将失败，并且Vim将退出并显示您报告的消息。

一种自己查看退出的父进程本身不会影响Vim的方法是通过strace运行它。例如，使用以下命令（假设./vim-launcher是您的二进制文件）：

$ strace -f -o /tmp/vim-launcher.strace ./vim-launcher

由于strace的{​​{1}}选项正在运行，所以它也将在启动Vim时开始跟踪。 Shell将执行-f（而不是strace），因此它的前台管道仅在vim-launcher停止运行时结束。并且strace在Vim退出之前不会停止运行。即使已重新初始化为Vim，Vim仍可以在5秒钟内正常工作。

daemontools中曾经有一个fghack tool，它完成了相同的阻塞任务，直到所有分叉的孩子都退出为止。它可以通过创建一个新管道并由其生成的进程继承该管道来实现，而这种方式将被所有其他派生子节点自动继承。这样，它可能会阻塞，直到关闭该管道文件描述符的所有副本为止，这通常仅在所有进程退出时才会发生（除非后台进程竭尽全力关闭所有继承的文件描述符，但这实际上表明它们没有这样做）。不想被跟踪，到那时他们很可能已经放弃了对终端的访问。）