GitLab CI执行多SSH命令异常：Spring Boot应用部署后停滞
2026-6-12
排查思路
- 检查CI部署脚本的SSH启动命令完整性：确保Spring Boot启动时彻底脱离CI Runner的会话控制。比如启动命令必须包含完整的IO重定向：
nohup java -jar your-app.jar > /dev/null 2>&1 &，避免因为Runner复用IO流导致第一台机器的进程IO阻塞。如果脚本里只写了nohup java -jar ... &，没重定向输出，进程可能会因为等待终端输出而挂起。 - 跟踪第一台机器上Spring Boot进程的系统调用：用
strace -p <进程PID>查看进程卡在哪个系统调用上，比如是否卡在read/write等IO操作；用lsof -p <进程PID>检查打开的文件描述符，看是否有未关闭的终端连接（比如指向Runner的SSH会话）。 - 拆分部署步骤为独立CI作业：把两台机器的部署从同一个job里的两次脚本调用，改成两个独立的GitLab CI作业（比如
deploy-server1和deploy-server2），让它们在不同的Runner进程中执行，排除Runner会话复用导致的异常。 - 监控目标机器的系统资源：在部署时实时查看第一台机器的CPU、内存、网络IO（用
top、free -h、iostat命令），确认是否因为CI同时部署导致资源耗尽，引发Spring Boot进程的GC停顿或线程阻塞。 - 检查SSH命令的终端参数：避免在SSH命令中使用
-t强制分配伪终端，因为这会让Spring Boot进程依赖SSH会话的终端，当Runner启动第二个SSH连接时，可能会触发第一个会话的SIGHUP信号（即使nohup也可能处理不彻底）。建议用ssh -T禁用终端分配，或者直接使用无终端的SSH调用。
内容的提问来源于stack exchange，提问作者xing
相关产品推荐
相关产品推荐
