fork() 遇到 fopen() 时的混乱

Question

我发现如果我们在关闭它之前执行 fork()，打开的文件流会变得混乱。众所周知，当父进程和子进程想要修改文件流时，可能会发生并发，即竞争条件。但是，即使子进程从未接触过文件流，它仍然具有未定义的行为。我想知道是否有人可以从子进程被分叉和退出的阶段内核如何处理文件流来解释这一点。

下面是一个奇怪行为的快速sn-p：

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

int main() {
    // Open file
    FILE* fp = fopen("test.txt", "r");

    int count = 0;
    char* buffer = NULL;
    size_t capacity = 0;
    ssize_t line = 0;
    while ( (line = getline(&buffer, &capacity, fp)) != -1 ) {
        if (line > 0 && buffer[line - 1] == '\n') // remove the end '\n'
            buffer[line - 1] = 0;

        pid_t pid = fork();
        if (pid == 0) {
            // fclose(fp); // Magic line here: when you add this, everything is fine
            if (*buffer == '2')
                execlp("xyz", "xyz", NULL);
            else
                execlp("pwd", "pwd", NULL);
            exit(1);
        } else {
            waitpid(pid, NULL, 0);
        }
        count++;
    }
    printf("Loops: %d\n", count);
    return 0;
}

只需将代码复制到一个新文件中（例如 test.c）。并用简单的内容创建一个 .txt 文件 test.txt

1
2
3
4

然后运行

$ gcc test.c && ./a.out

文件中有 4 行。预计循环将读取每一行并准确执行 4 次 (1 2 3 4)。我选择让它在第二个循环中执行无效命令“xyz”。然后，你会发现循环实际上执行了 6 次（1 2 3 4 3 4）！事实是，当执行的所有四个命令都有效时，什么都不会出错。但是如果执行了一个无效的命令，它之后的每个命令都会被执行两次。 （请注意，这种奇怪的行为只发生在 Linux 机器上，我的 Mac OS 运行良好，不确定 Windows。所以问题与平台有关？）

看起来每当我 fork() 时，父级中的文件流不再被承诺为旧 fp（非确定性行为），即使我的子进程没有触及它。

我找到的一个临时解决方案是：子进程中的 fclose(fp)。这将使上述奇怪的行为沉默，但在更复杂的情况下，仍然可以观察到其他事情。如果有人能给我一些关于这个问题的见解，我们将不胜感激。谢谢

Answer 1

正如 cmets 中所说，您需要在调用 exec 之前关闭打开的文件描述符。

在this blogpost（第 4 节）中有一个简洁的代码示例，您可以使用它来确保关闭所有 fd，即使在您并不总是知道当前打开哪些文件的复杂应用程序中也是如此：

for ( i=getdtablesize(); i>2; --i) 
close(i); /* close all descriptors */

（稍作修改以保持标准输入、标准输出、标准错误打开）

这有点骇人听闻，但它确实有效。如果您想避免这种情况，您还可以在您打开的每个文件描述符上设置O_CLOEXEC 标志。因为在使用 fopen 时，您不直接调用 open()，您可以通过向其添加 'e' 标志来完成此操作（使用 glibc >= 2.7 时）：

FILE* fp = fopen("test.txt", "er");

当调用exec*()时，所有带有该标志的文件描述符都会自动关闭。