macOS下SSH断开后tmux会话被终止 远程GPU任务中断问题咨询

先做个快速验证：按照原有流程启动tmux、运行任意常驻命令（比如top）、按Ctrl+b后按d完成detach，不做其他操作，直接在mac端输入exit正式退出SSH连接（不要直接关闭终端窗口、硬断网络），重新建立SSH连接后输入tmux ls，查看原有会话是否存在。

常见问题对应解决方案 #

• 未正确完成detach就断开SSH连接
  若detach后直接关闭终端窗口、遇网络瞬断，SSH客户端会主动发送挂断信号给所有关联子进程，导致未完全和tmux服务端剥离的会话被连带终止。需要注意：按完Ctrl+b再按d后，只有屏幕回到可以正常输入命令的远程shell提示符界面，才代表detach成功；如果还停留在tmux的会话界面，说明操作未生效，这时候断SSH一定会带走会话。
  正确操作逻辑：确认detach成功后，必须在远程原shell终端输入exit主动退出SSH，等连接完全断开后再进行其他操作。

• 远程服务器配置了用户退出时清理所有子进程的PAM规则
  多数云服务器、GPU集群默认开启pam_systemd模块，当SSH连接退出、用户登录会话结束时，会自动清理所有关联进程，detach状态的tmux也会被纳入清理范围。
  对应解决：

  • 启动tmux时显式指定独立服务套接字，让tmux不绑定当前用户的登录会话范围：
    tmux -S /tmp/unique_tmux_sock new -s train
  • 后续重连查看会话时需指定对应套接字：
    tmux -S /tmp/unique_tmux_sock ls
tmux -S /tmp/unique_tmux_sock attach -t train
  • 有服务器sudo权限的话，可修改/etc/systemd/logind.conf，将KillUserProcesses参数设置为no，重启systemd-logind服务即可从根源关闭进程清理规则。

• shell配置绑定了挂断信号捕获规则
  若远程的.bashrc/.zshrc里配置了trap命令，会在登录shell退出时主动杀掉所有关联后台进程，导致刚detach的tmux被连带终止。
  对应解决：创建tmux会话时直接以后台模式启动，从根源上让会话和当前登录shell无强绑定：
  tmux new-session -d -s train
  这种方式完全不需要手动按Ctrl+b d执行detach，会话从创建开始就独立在后台运行，后续随时可用tmux attach -t train重新进入会话操作。断开SSH时直接输入exit退出即可，会话会持续后台运行。

• 目标进程本身异常退出
  若排查完上述问题，tmux ls能正常看到会话存在，但会话内的训练进程已经停止运行，说明并非tmux被终止，而是脚本本身因显存溢出、权限不足、路径错误等问题被系统强制杀掉。可将脚本运行输出重定向到独立日志文件：
  python train_script.py > train.log 2>&1
  进程退出后可直接查看日志定位具体报错原因。

内容的提问来源于stack exchange，提问作者Masoumeh Javanbakht