VS Code Server断开连接后无法正常关闭问题排查咨询

问题背景 #

过去数周团队一直顺畅使用VS Code Remote开展开发工作，部署方案为AWS官方参考方案的深度定制版本，采用AWS EC2实例作为远程服务器。
为控制成本，每台服务器配置为30分钟无活动后自动关机，其中“无活动”的判定规则为：pgrep无法检测到任何应当维持系统运行的特定进程。当前配置的其中一项无活动检测命令为：

pgrep -f .vscode-server/bin/

该规则在5台开发人员专属服务器中的4台上运行正常：开发人员关闭最后一个远程窗口后的数分钟内，所有服务端VS Code进程都会自动关闭，30分钟后远程服务器即可正常触发自动关机。
但第5台服务器始终无法通过该项无活动检测（CPU利用率见下图，图中绿线始终趋近于0但从未完全消失）：在用户断开VS Code UI连接很长时间后，执行ps x仍可查看到多个路径为.vscode-server/bin/的进程持续运行。

排查步骤 #

• 拉取残留进程完整信息，禁止使用截断命令行输出的参数：

  ps -efww | grep .vscode-server/bin/ | grep -v grep
  

  先区分残留进程类型：node主进程、扩展宿主进程、端口转发进程、调试适配器进程、终端shell进程的残留根因完全不同，先明确进程类型再定向排查。
• 检查残留进程父进程ID，判断是否为孤儿进程：

  ps -o ppid=,pid=,cmd= -C node | grep .vscode-server
  

  若进程PPID为1（即init/systemd进程），说明父进程已提前退出，子进程未被回收，属于异常遗留；若PPID仍指向.vscode-server路径下的主进程，说明主进程本身未触发退出流程。
• 排查服务端日志定位退出阻塞点：
  远程端日志存放在~/.vscode-server/logs/目录下，按连接时间找到对应会话的日志文件夹，搜索shutdown、exit、extension host、timeout关键词，重点确认是否存在扩展shutdown钩子长时间不返回、文件锁未释放、端口转发进程卡住的报错。这类问题90%以上由第三方扩展持有资源不释放导致，主进程等待扩展响应超时后未执行强杀逻辑，就会持续残留。
• 对比异常实例与正常实例的VS Code Server版本：
  进入~/.vscode-server/bin/目录，查看留存的版本号文件夹，和4台正常实例的版本做对比。历史上多个VS Code Server版本存在连接断开后进程不退出的已知bug，若版本不一致，直接删除异常版本的目录，重新连接让服务端自动拉取匹配版本后再测试退出逻辑。
• 检查进程信号处理是否异常：
  取残留进程的PID，执行以下命令查看信号掩码：

  grep SigIgn /proc/<替换为实际残留进程PID>/status
  

  若结果显示SIGTERM信号被忽略，说明进程被注入了自定义信号处理逻辑，常见诱因包括实例上安装的安全软件、审计插件、用户shell配置文件（.bashrc/.zshrc）中加载的动态库篡改了进程默认信号响应逻辑。
• 优化现有检测规则：
  当前使用的pgrep -f .vscode-server/bin/匹配范围过宽，可能把VS Code Server临时拉起的版本检查、日志上报等短生命周期进程误判为活跃进程，可收紧匹配规则，仅匹配主进程特征，减少误判。

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