客户端侧Broken Pipe错误的预防方法及Slurm+salloc场景下的相关技术咨询

嘿，这个场景我太熟了，分两块给你讲清楚，解决你的痛点：

一、Ubuntu客户端SSH防Broken Pipe的实用配置 #

你提到编辑~/.ssh/config不能100%保证，但这确实是客户端侧最有效的基础手段，我给你一套常用的配置，能覆盖绝大多数普通网络断连情况：

Host *
  ServerAliveInterval 30
  ServerAliveCountMax 5
  TCPKeepAlive yes

解释下：

• ServerAliveInterval 30：每30秒给服务器发一个探测包，确认连接还活着；
• ServerAliveCountMax 5：连续5次没收到服务器回应才主动断开（默认是3，调高能适应短暂的网络波动）；
• TCPKeepAlive yes：开启底层TCP协议的保活机制，和上面的SSH层保活形成双重保障。

另外，日常操作尽量避开信号极差的移动网络环境，比如地铁里频繁切换基站的场景，能进一步降低断连概率。

二、Slurm salloc连接断后任务不被取消的核心解决思路 #

你说用screen恢复没用，大概率是操作顺序错了！关键点是：salloc必须运行在服务器侧的持久化会话里，而不是直接在本地SSH的shell中启动。

正确的操作流程是：

• 通过SSH正常连接到服务器；
• 启动一个screen（或tmux）会话：screen -S slurm_session；
• 在这个screen会话里运行你的salloc命令，比如salloc --nodes=1 --ntasks=4；
• 之后即使本地SSH断了（出现Broken Pipe），服务器上的screen会话和里面的salloc进程都不会终止；
• 重新SSH连接服务器后，用screen -r slurm_session恢复会话，就能继续使用之前申请的节点资源了。

如果怕自己记不住顺序，也可以直接在SSH连接时就启动screen：ssh user@server -t screen -r slurm_session，这样连上去直接进入指定的screen会话，避免误操作。

另外，还有个兜底方案：如果已经在SSH shell里启动了salloc，突然意识到没开screen，可以快速按Ctrl+Z暂停salloc，然后输入bg把它放到后台，再执行disown -h %1（%1是后台进程的编号，用jobs可以查看），这样即使SSH会话断开，salloc进程也不会收到SIGHUP信号被终止，但这种方法不如screen/tmux直观，适合临时救急。

备注：内容来源于stack exchange，提问作者SO_32