SSH 会话随 VPN 断开而死：用 tmux 还是作业运行器？

VPN 指示灯变绿，路由也回来了，可你留在那里的 SSH 窗口再也不会返回提示符。恢复一条路由并不恢复使用它的那段 TCP 会话，所以敲进那个窗口的内容都丢了。如果真正担心的是编辑器缓冲区或一次很长的迁移，解决办法是别再把这份工作绑在一条连接上。tmux 和作业运行器各自解决这个问题的一半。

重连的 VPN 不会续上套接字

TCP 没有地址变化之后接着续上的概念。SSH 连接由两端共同标识，隧道重建后本地地址可能改变，原来的套接字已经死了。服务器最终会察觉，而你的终端立刻就会察觉。

客户端 keepalive能更早发现对端已经死亡。它不会把会话拉回来，也无法恢复已经在运行的命令。keepalive 是探测器，不是恢复工具。它完全不知道远端命令是否还活着。

把工作放在远端主机上

会话要建在远端主机上，而不是笔记本上。照常连接，在那里启动 tmux，把编辑器或迁移跑在它里面。用默认前缀分离，SSH 连接消失时会话仍然继续运行。在本地启动 tmux 只能保护你的 shell 不被关窗，保护不了远端的命令不被死掉的隧道牵连。

ssh [email protected]
tmux new-session -s office-work

VPN 回来之后，向同一台主机开一条新的 SSH 连接，按名字重新接上。持久的是会话，而不是连接。起一个一周后你还认得出的名字。

tmux 与作业运行器

只要主机开着，tmux 就能让交互进程活下去。作业运行器或服务管理器让非交互作业活下去，记录它的退出状态，即使 SSH 会话彻底结束也能存活。前者是你要盯着看的工作，后者是排好时间、之后再去检查的工作。

除非主机配置了自动恢复，否则两者都熬不过重启。tmux 会话随机器一起死，临时作业随开机一起死，除非它被注册成一个单元。按这份工作需要活多久来选。

两种做法都需要一份重连之后能读的日志。没有日志，你只知道进程还在，不知道它做过什么。把日志路径写在会话名旁边。

按必须活下来的东西做决定

按工作中断时最糟的后果来决定。编辑器会话只会丢掉没保存的缓冲区，烦人但还能救。只提交一半改动的迁移可不能这么算，所以要用有结果记录的运行器。如果作业是交互式的而且很长，tmux 加一份写下来的日志通常就够了。

systemd-run --user --unit=migrate-customers --collect ./migrate.sh

不管你选哪种，重新运行任何东西之前先看记录下来的结果。最后一行缺失，说明的是笔记本看到了什么，而不是服务器提交了什么。正是这个区别让你一开始就该把工作挪到连接之外，而分离与重新接上模型是它最小的形态。