创建守护进程时，是否必须绑定0、1、2文件描述符到/dev/null？

《UNIX环境高级编程》（APUE，图13.1）中提到，创建守护进程时，在关闭所有打开的文件描述符后，需要将描述符0、1、2关联到/dev/null，示例代码如下：

/*
* Close all open file descriptors.
*/
if (rl.rlim_max == RLIM_INFINITY)
    rl.rlim_max = 1024;
for (i = 0; i < rl.rlim_max; i++)
    close(i);
/*
* Attach file descriptors 0, 1, and 2 to /dev/null.
*/
fd0 = open("/dev/null", O_RDWR);
fd1 = dup(0);
fd2 = dup(0);

问题：是否必须将文件描述符0、1、2关联到/dev/null，还是可以让它们保持未关联状态？

回答 #

不是硬性要求，但强烈建议这么做，核心原因有这几点：

• 避免意外崩溃或异常：后续代码（甚至依赖的第三方库）可能会默认使用stdin、stdout、stderr做I/O操作，如果这些描述符未关联，会触发EBADF（无效文件描述符）错误。很多程序没处理这种场景，直接就崩了，或者出现莫名其妙的行为。
• 切断与终端的绑定：守护进程的核心是脱离终端后台运行，如果fd0/1/2还挂着原终端，可能会意外持有终端资源，导致终端无法正常退出，或者守护进程被终端发送的信号（比如SIGHUP）干扰。
• 遵循行业规范：将标准I/O重定向到/dev/null是UNIX守护进程的常规操作，其他开发者接手代码时不会产生疑惑，也能保证程序在不同类UNIX系统上行为一致。
• 避免无意义输出污染：如果程序有未清理的调试日志、错误信息，写到/dev/null会直接丢弃，不会误写到其他文件或者设备里。

要是真的让fd0/1/2保持未关联状态，理论上能跑，但会埋下很多隐性bug——比如某个依赖库突然加了一行printf，进程可能就因为EBADF错误挂掉，排查起来还费时间。

内容的提问来源于stack exchange，提问作者tahzibi.jafar