印度机房用 tmux 跑长任务，SSH 断了进程也没了

印度机房那台跑批的机器，Ubuntu 20.04，OpenSSH 8.2，Mumbai 区域，跨公网连过去 RTT 稳定在 90ms 上下。备份加校验的脚本要跑四十分钟，我图省事直接 ssh 上去敲命令，结果链路抖了一下，终端卡死，重连之后进程已经没了。日志停在中间，/tmp 里半截文件还在，白跑。

后来改成 tmux 常驻。步骤很简单，关键是每一步别省：

ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=3 ops@10.x.x.x
tmux new -s backup
# 在会话里跑
./backup.sh 2>&1 | tee /var/log/backup/$(date +%F).log
# 主动脱离
# Ctrl-b d

重连后确认：

tmux ls
tmux attach -t backup

脚本本身也加一层兜底，别让它挂着终端：

nohup ./backup.sh >/var/log/backup/run.log 2>&1 &

为什么用 tmux 而不是直接 nohup：nohup 只挡 SIGHUP，进程还绑在那个 shell 的会话里，标准输入关掉后有些交互式工具会直接退出；tmux 给的是伪终端，进程以为自己在正常终端里，行为一致。代价是多一层服务端进程，机子内存吃紧时要注意，另外 tmux 会话不会跟着重启存活，机器一重启就全没了，这点得靠 systemd 补。

ServerAliveInterval 不是万能的。链路完全断掉时它只是让客户端早点发现，不会保住服务端进程。我在拉合尔到孟买这条线上遇到过一次运营商侧静默丢包，客户端还在等，服务端已经超时清会话，最后还是靠 tmux 服务端没死才捞回来。反例是那次机器 OOM，tmux 会话跟着进程一起被 kill，tmux ls 什么都不剩，只能看 dmesg 里的 oom-killer 记录。

还有个坑：tee 写日志时如果目录权限不对，脚本照跑但日志是空的，我后来在脚本开头加了一句 mkdir -p 和可写检查才踏实。

你们在跨公网的长任务上，是坚持 tmux，还是直接交给 systemd 或 supervisor 托管？想听听别人怎么权衡的。