两次fork才能安全脱离终端：第一次使子进程脱离父进程并调用setsid()创建新会话，第二次确保子进程非会话首进程，彻底杜绝重新获取控制终端的可能。
为什么 fork 两次才能安全脱离终端
直接 fork() 一次后调用 setsid()，子进程虽能成为会话首进程、脱离控制终端，但仍有风险：它可能意外重新获得终端（比如被父进程的终端信号影响），或继承父进程的文件描述符（尤其是 stdin/stdout/stderr）导致日志写入失败或阻塞。真正可靠的守护进程需确保：无控制终端、非会话首进程的子进程（避免再次获取终端）、工作目录与根目录解耦、文件掩码重置。
所以标准做法是 fork 两次：
- 第一次
fork()：让父进程退出，使子进程被 init（或 systemd）收养，彻底脱离 shell 生命周期 - 子进程调用
setsid()：创建新会话，脱离原会话和控制终端 - 第二次
fork()：确保该进程**不是会话首进程**（setsid()后的进程仍是会话首进程，而会话首进程有资格重新打开终端；再 fork 一次后，子进程就不再是会话首进程，彻底失去获取终端的能力）
setsid() 调用前必须先 fork 的原因
setsid() 会失败并返回 -1，如果调用进程已是会话首进程——这正是你 fork 后立刻调用它的前提。父进程（通常是 shell 启动的）必然属于某个会话，且大概率是其会话首进程。不 fork 就直接 setsid()，会触发 EPERM 错误，常见报错：Operation not permitted。
正确顺序只能是：fork() → 子进程 → setsid()。不能反过来，也不能省略 fork。
示例片段（关键检查不可少）：
pid_t pid = fork();
if (pid 0) {
exit(EXIT_SUCCESS); // 父进程退出
}
// 此时是第一次 fork 的子进程
if (setsid() == -1) { // 必须检查
exit(EXIT_FAILURE);
}
守护进程必须关闭并重定向 0/1/2 文件描述符
不处理 stdin（fd 0）、stdout（fd 1）、stderr（fd 2），守护进程可能因写入已关闭的终端而收到 SIGPIPE，或阻塞在 read 上，甚至把日志输出到不可见位置（比如父 shell 的 tty）。Linux 守护规范要求它们必须指向安全目标。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
标准做法是：
- 先用
close(0)、close(1)、close(2)关闭 - 再用
open("/dev/null", O_RDWR)三次：第一次返回 fd 0（stdin），第二次自动获得 fd 1（stdout），第三次得 fd 2（stderr） - 或者更简洁地用
dup2()复制一个已打开的/dev/nullfd 到 0/1/2
注意：不要只重定向 1 和 2 而忽略 0 —— 某些库函数（如 getline() 或某些日志组件）仍可能尝试读 stdin，导致 hang。
chdir("/") 与 umask(0) 是必要但常被跳过的步骤
守护进程的工作目录若保持为启动时的路径，可能导致卸载文件系统失败（“device busy”），尤其当它运行在挂载点下时。chdir("/") 是最稳妥的兜底方案，确保不持有所在文件系统引用。
umask(0) 则是为了消除父进程遗留的掩码影响。例如父进程 umask 是 022，你创建的文件默认权限就是 644；而守护进程往往要生成日志、PID 文件等，需要精确控制权限（比如希望 PID 文件是 644，日志是 600）。显式设为 0，后续用 open() 的 mode 参数按需指定，逻辑更清晰、可预测。
这两个调用位置应在第二次 fork 之后、正式进入主循环之前，且无需检查返回值（chdir("/") 几乎总成功；umask() 总返回旧值，不失败）。
容易被忽略的一点：有些实现会用 chdir("/tmp") 或其他路径代替 chdir("/")，这其实违背了 LSB（Linux Standard Base）建议，也增加了依赖风险——/tmp 可能是 tmpfs 或独立挂载，反而引入不确定性。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
