关键在于脱离终端控制：nohup仅忽略sighup信号，进程仍属原会话；setsid则创建新会话，使进程成为pid 1子进程，彻底脱离终端，更适合长期运行的运维工具。
要让运维工具在终端关闭后持续可靠运行，关键不是“后台启动”，而是“脱离终端控制”。nohup 和 setsid 的作用机制不同，适用场景也有明显区别——选错方法可能导致进程意外退出。
nohup：让进程忽略挂断信号
nohup 的核心是屏蔽 SIGHUP 信号。它不改变进程的会话归属，只是让进程对终端发来的挂断信号无反应。适合轻量、短时或调试阶段的后台任务。
- 标准写法：nohup ./monitor.sh > monitor.log 2>&1 &
- 注意重定向必须显式指定，否则 nohup 默认写入 nohup.out，容易遗漏错误输出
- 进程仍属于原终端的会话和进程组，PPID 是当前 shell 的 PID，不是 1
- 如果终端异常崩溃（如 ssh 强制断连未触发 clean logout），部分系统仍可能发送其他终止信号，nohup 无法防御
setsid：让进程彻底脱离终端会话
setsid 创建全新会话，使进程成为 init（PID 1）的直系子进程，完全不属于原终端的会话、进程组和控制终端。这是更彻底的守护化方式，适合长期运行的运维工具（如日志采集器、健康检查服务）。
- 标准写法：setsid ./backup-tool.sh > /var/log/backup.log 2>&1
- 无需加 &，setsid 默认不阻塞当前终端；若需立即返回控制权，可补上 &
- 执行后用 ps -o pid,ppid,sess,pgid,tty -p $(pgrep -f backup-tool) 验证：PPID 应为 1，TTY 显示 ?，SESS 和 PGID 应与原终端无关
- 不兼容某些需要交互式终端的程序（如含 readline 或 tty 检查的脚本），需提前测试
组合使用与常见避坑点
单独使用 nohup 或 setsid 已能满足大多数需求，但混合使用反而可能引入冗余甚至冲突。例如 nohup setsid cmd & 没有实际增益，还可能因信号处理叠加导致不可预期行为。
- 优先选 setsid：对可靠性要求高的运维工具（如巡检脚本、API 心跳服务），直接用 setsid 启动
- nohup 更适合快速验证或临时任务，尤其当工具本身已做基础守护逻辑（如自行 fork + setsid）时，再套 nohup 反而多余
- 务必重定向 stdout/stderr：无论哪种方式，不重定向会导致文件描述符继承终端，某些环境下仍可能引发写失败或阻塞
- 避免依赖 job 控制（如 jobs/fg/bg）：这些只对当前 shell 的子作业有效，nohup 和 setsid 启动的进程均不在作业列表中
验证是否真正可靠
不能只看进程是否存在，要模拟真实断连场景：
- 用 ssh 连接后运行命令，然后直接关掉本地终端窗口（非正常 logout）
- 等待 1–2 分钟，重新登录，执行 ps -eo pid,ppid,sess,comm | grep your-tool
- 确认 PPID=1、SESS 值与当前终端 sess 不同、TTY 列为 ?
- 检查日志文件是否有持续追加内容，而非只写入开头几行后停止
