https://blog.margrop.net/tag/setsid/ Recent content in Setsid on 魔都水滴 Hugo zh-CN Mon, 01 Jun 2026 07:00:00 +0800 https://blog.margrop.net/post/setsid-daemon-process-survival/ Mon, 01 Jun 2026 07:00:00 +0800 https://blog.margrop.net/post/setsid-daemon-process-survival/ <blockquote> <p><strong>先说结论</strong></p> <p>你启动了一个后台服务，<code>nohup</code> 用了，<code>&amp;</code> 也加了，日志也重定向了，一切看起来都很正常。但当你关闭终端、断开 SSH，或者——更隐蔽的情况——当自动化工具执行完脚本后，这个进程就悄无声息地消失了。你检查 <code>ps</code>，找不到它；检查端口，也没有监听。如果你遇到过这种情况，你不是一个人。</p> <p><strong>真正的根因不是 SIGHUP——至少不完全是。问题出在进程组和会话的归属关系上。</strong> <code>nohup</code> 只是让进程忽略 SIGHUP 信号，但如果进程所属的会话 leader 被销毁了，终端 IO 断裂了，或者父进程组被一起收割了，进程仍然可能死掉。真正彻底的解决方案是 <code>setsid</code>：它创建一个全新的会话，让进程完全脱离原会话的控制终端，不再属于父 shell 的进程组——因此父 shell 退出时，SIGHUP 根本传播不到它那里去。</p> </blockquote> <p>这篇文章源自一次真实的 CLIProxyAPI 服务排障。服务通过 <code>nohup</code> 启动后，每次自动化脚本执行完毕就消失，管理界面一直报“网络连接失败”。排查后发现是一个隐蔽的 Unix 进程生命周期问题。这类问题在云原生开发机、CI runner、SSH jump host 和容器化工作流里非常常见，但往往因为对进程模型理解不深而被误判为“软件有 bug”。</p> <p>为了不泄露隐私，本文不会出现真实内网地址、真实 token 或路径。所有配置片段使用 <code>&lt;PLACEHOLDER&gt;</code> 占位。</p>