如何在Linux中配置SSH连接断开后进程不退 Linux使用nohup的方法

nohup 经常失效的根本原因是它只忽略 SIGHUP，不解决进程归属与 TTY 依赖问题；需同时满足显式重定向、强制后台、规避 TTY 依赖三条件才可靠。

nohup ./script.sh & 为什么经常失效

根本原因不是 nohup 失效，而是它只负责忽略 SIGHUP，不解决进程归属问题。Shell 在退出时会清理自己的作业表（job table），如果进程仍登记在其中，即使忽略信号，某些程序（如含 read、sudo 或交互式逻辑的脚本）会因失去控制终端而主动退出。

常见连带问题包括：

• nohup.out 所在目录不可写（比如当前路径权限不足），nohup 直接失败并返回 125 或 126
• 脚本里用了相对路径读写文件，但 nohup 不切换工作目录（cwd），实际操作的是启动时的路径，容易出错
• 漏掉末尾的 &，导致命令前台阻塞，SSH 断开前就卡住
• nohup./script.sh 中缺少空格，被解析为一个命令名，报 command not found

真正可靠的 nohup 写法

必须同时满足三个条件：显式重定向输出、强制后台、规避 TTY 依赖。缺一不可。

推荐写法：

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

说明：

• > ./output.log：绕过默认的 nohup.out，避免权限/路径不确定性
• 2>&1：把 stderr 合并进 stdout，日志统一，排查方便
• 末尾的 &：确保脱离前台控制，否则 nohup 会等待脚本退出（尤其当脚本不自动结束时）

如果脚本依赖特定目录，请先 cd /path/to/script && nohup ./script.sh > output.log 2>&1 &，不能靠脚本内部 cd 补救。

遇到 nohup 不行时，该换什么

当脚本内调用 ssh、rsync -P、scp 等需要伪终端的命令，或需随时查看实时进度，nohup 就力不从心了。

更稳的选择：

• tmux new-session -d -s mytask 'command'：启动分离式会话，之后可用 tmux attach -t mytask 重新进入
• setsid ./script.sh &：让进程直接以 init（PID 1）为父进程，彻底脱离会话期，不受 shell 生命周期影响
• ./script.sh & disown %1：适合已启动但忘记加 nohup 的场景，补救快
• 长期服务类任务（如 Web 后端、定时采集），别硬扛 nohup：改用 systemd --user 或 supervisord，它们管重启、日志轮转、资源限制

最容易被忽略的细节

很多人以为加了 nohup 就万事大吉，其实最关键的控制点藏在路径和上下文里：

• nohup 不改变当前工作目录（cwd），所有相对路径都按启动位置解析 —— 和你在脚本里写 cd 是两回事
• 脚本中若调用 sudo，默认拒绝非 TTY 环境，得加 -n 参数或配置 Defaults !requiretty
• nohup.out 或自定义日志文件如果磁盘满、inode 耗尽、或挂载为只读，nohup 会静默失败或退出
• 用 ps aux | grep script.sh 查进程时，注意区分是真运行还是残留的 grep 进程

真正稳住一个远程进程，靠的不是单条命令，而是对路径、权限、TTY、信号链路的完整掌控。