Linux后台运行教程：nohup使用详解

本文深入解析了 Linux 中 `nohup` 的真实作用与常见误区：它仅忽略 SIGHUP 信号，并不等同于后台运行，真正实现可靠后台执行需严格配合 `&`、完整输出重定向（如 `> ./output.log 2>&1`）并规避 TTY 依赖、权限问题和工作目录陷阱；文章还对比了 `setsid`、`disown`、`systemd --user` 和 `tmux` 等更健壮的替代方案，帮助读者告别“断开 SSH 后进程莫名消失”的困扰，掌握生产环境长期稳定运行脚本的核心实践。

nohup 本身不等于“后台运行”，它只负责忽略 SIGHUP；真正让进程脱离终端控制，必须配合 & 或其他机制。

nohup ./script.sh & 为什么有时仍会退出？

常见现象：执行 nohup ./script.sh & 后断开 SSH，进程却消失了。

• 根本原因不是 nohup 失效，而是 shell 在退出时对子作业（job）做了清理 —— 如果该作业仍属于当前 shell 的 job table（即没被“剥离”），shell 会主动发送 SIGHUP 给它，哪怕它已用 nohup 忽略了信号，但某些程序（尤其带交互逻辑的）可能在收到 SIGHUP 后自行退出
• 更隐蔽的问题：脚本里用了 read、sudo、ssh 等需要 TTY 的命令，nohup 不会自动分配伪终端，导致这些命令立即失败或挂起
• 输出重定向缺失时，nohup.out 若不可写（比如当前目录权限不足），nohup 会直接报错退出，返回码为 125 或 126

正确写法：输出重定向 + 显式后台 + 避免 TTY 依赖

这是最稳妥、可复现的最小可靠组合：

nohup ./script.sh > ./output.log 2>&1 &

• > ./output.log：强制指定 stdout 输出路径，避免写入 nohup.out 带来的权限/路径不确定性
• 2>&1：把 stderr 合并进 stdout，统一记录，方便排查
• 末尾的 &：确保命令真正进入后台，否则 nohup 会前台阻塞等待（尤其当脚本不自动退出时）
• 不要省略空格：nohup./script.sh 是错误写法，nohup 会把它当做一个命令名去查找

比 nohup & 更可靠的替代方案

当遇到 nohup 无法解决的场景（如脚本内调用 systemd-run、需要资源隔离、或需重启策略），优先考虑这些：

• setsid ./script.sh &：让进程直接以 init（PID 1）为父进程，彻底脱离终端 session，不受任何 shell 生命周期影响
• disown 配合已启动的后台任务：./script.sh & → disown %1，适合调试中临时补救
• 长期服务类任务，别硬扛 nohup：改用 systemd --user 或 supervisord，它们能处理崩溃重启、日志轮转、依赖管理
• 交互式任务（如 scp、rsync -P）：用 tmux new-session -d -s mytask 'command'，比 nohup 更稳，还能随时 attach 查看进度

最容易被忽略的一点：nohup 不改变进程的 cwd（当前工作目录）。如果脚本里用的是相对路径读写文件，而你是在 /tmp 下执行的 nohup，那它实际操作的就是 /tmp 下的文件 —— 这和你在脚本里写 cd /path/to/data 是两回事，得自己保证路径健壮。

理论要掌握，实操不能落！以上关于《Linux后台运行教程：nohup使用详解》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！