守护进程必须是孤儿进程，因为只有成为孤儿才能脱离终端控制、避免信号干扰，并由init/systemd统一接管生命周期；通过两次fork和setsid()实现彻底会话脱离与僵尸进程规避。
守护进程必须是孤儿进程，这不是设计偏好，而是机制必需。核心原因在于：只有成为孤儿进程，才能彻底脱离终端控制、避免被信号干扰，并由 init/systemd 统一接管生命周期。
脱离会话与终端控制
普通子进程继承父进程的会话（session）和控制终端（tty）。只要父进程还在前台运行，子进程就可能收到 SIGHUP、SIGINT 等终端相关信号，也可能因终端关闭而意外终止。
成为孤儿进程后，内核会将其交给 PID=1 的 init 或 systemd 进程。这个过程天然触发会话脱离——因为 init/systemd 本身没有控制终端，也不属于任何用户会话。子进程随之失去 tty 关联，不再响应 Ctrl+C、挂起（SIGTSTP）或终端断开（SIGHUP）等信号。
规避进程组限制
Linux 中，只有会话首进程（session leader）才能调用 setsid() 创建新会话。而一个普通进程若已是某个会话的成员，再次调用 setsid() 会失败。
通过先 fork 出子进程、再让父进程退出，子进程自动变成孤儿，同时失去原有会话归属。此时它不再是任何会话的成员，就能安全调用 setsid()，真正独立为一个新会话的首进程——这是守护进程不被终端牵制的关键一步。
由 init/systemd 完成终态回收
守护进程需长期运行，但最终总会退出。若它仍有普通父进程，该父进程就必须显式调用 wait() 回收其退出状态；否则子进程终止后会变成僵尸进程。
而 init 或 systemd 是系统中唯一被内核特别保障的“终极父进程”：它持续运行、永不退出，且内核确保所有孤儿进程都归其管理。一旦守护进程成为孤儿，它退出时的状态将由 init/systemd 自动 wait() 清理，完全避免僵尸风险。
两次 fork 的真实作用
标准守护进程实现中常采用两次 fork，目的不是“制造孤儿”，而是防止进程意外获得会话领导权：
- 第一次 fork：子进程脱离原始父进程，成为孤儿，获得脱离终端的基础条件
- 调用 setsid()：创建新会话，成为会话首进程，彻底断开终端
- 第二次 fork：新子进程不再会话首进程（因父进程已是会话首进程），从而无法重新打开终端（POSIX 规定仅会话首进程可打开控制终端）
这第二层隔离，堵死了守护进程未来被误关联到终端的最后可能性。
