要让shell脚本跨夜稳定运行，核心是切断与控制终端的关联：nohup屏蔽sighup信号，setsid彻底脱离会话并使父进程变为init；两者可单独或组合使用，推荐关键任务用setsid nohup组合，启动后需验证进程状态和日志输出。
要让 Shell 脚本跨夜稳定运行、不因终端关闭或 SSH 断连而终止，核心是切断它与当前控制终端的物理和会话关联。nohup 和 setsid 各走一条技术路径：nohup 让进程“听见但忽略”挂断信号（SIGHUP），setsid 则让进程“根本不在那个会话里”，从源头规避信号影响。两者可单独使用，也可组合增强可靠性。
nohup：屏蔽挂断信号，适合快速部署
nohup 最直接的作用是让命令对 SIGHUP 信号免疫。它不改变进程的会话归属，只是加了一层信号过滤。
- 基本用法：nohup ./script.sh > output.log 2>&1 & ——重定向标准输出和错误，加 & 放入后台
- 默认日志写入 nohup.out，若不指定重定向，多个 nohup 命令会互相覆盖该文件
- 执行后建议按一次 Enter 确认看到新 shell 提示符，再退出终端，避免因缓冲未刷导致误判
- 适用于调试阶段、短期任务或对会话隔离要求不高的长期服务
setsid：彻底脱离会话，父进程变为 init（PID=1）
setsid 创建一个全新的会话（session），并将目标进程设为该会话的首进程（session leader）。此时进程不再属于原终端控制组（tty group），自然收不到终端发出的 SIGHUP。
- 基本用法：setsid ./script.sh > output.log 2>&1 ——无需加 &，自动后台运行
- 进程的 PPID（父进程 ID）会变成 1（即 init/systemd），可用 ps -o pid,ppid,sess,tty,cmd -p $(pgrep -f "script.sh") 验证
- 比 nohup 更彻底，尤其适合对稳定性要求高、可能遭遇网络抖动或非正常断连的场景
- 注意：某些容器环境或受限 shell 中，setsid 可能不可用，需提前确认命令存在
组合使用：双重保险，应对复杂中断场景
在关键业务脚本（如数据同步、模型训练、反向 Shell）中，可叠加 nohup + setsid，既脱离会话又屏蔽信号，形成冗余防护。
- 推荐写法：setsid nohup ./script.sh > output.log 2>&1 &
- 等效于先用 setsid 换会话，再用 nohup 加信号过滤，实际中极少需要双用，但对容错性敏感的场景值得考虑
- 日志仍由重定向控制，nohup 不再生成 nohup.out，避免干扰
- 不建议无脑套用；多数生产环境单用 setsid 已足够稳健
验证与收尾要点
启动后别急着关终端，先做两件事：
- 用 ps aux | grep script.sh 查看进程是否存在，重点关注 TTS 列是否为空（表示无控制终端）
- 用 tail -f output.log 确认日志实时写入，排除重定向失败
- 手动 exit 或断开 SSH，稍等几秒后重新登录，再查进程是否仍在运行
- 如需停止，用 pkill -f "script.sh" 或记下 PID 后 kill PID
