GitLab Runner（Windows服务）执行WSL命令失败求助

核心原因 #

GitLab Runner作为Windows服务默认运行在会话0，而WSL依赖用户交互式会话的环境配置与用户态资源，这是导致wsl --list输出空行、退出码-1的主要原因。

可行解决方案 #

• 改用交互式方式运行GitLab Runner
  停止并卸载现有服务，改用当前用户身份启动Runner：

  sc stop gitlab-runner
  gitlab-runner uninstall
  gitlab-runner run
  

  若需要后台运行，可创建快捷方式放入「启动」文件夹，或用nssm等工具包装为交互式后台进程。这种方式下Runner会加载当前用户的WSL配置，命令可正常执行。

• 为服务账户初始化WSL环境
  服务账户（如Local System）的WSL环境独立于普通用户，未初始化时无法正常调用：

  1. 用PsExec工具以服务账户身份打开交互式命令行：

     psexec -s -i cmd.exe
     

  2. 在打开的cmd窗口中初始化WSL：

     wsl --list --online
     wsl --set-default Ubuntu  # 替换为你安装的分发版
     

  完成操作后关闭窗口，重新启动GitLab Runner服务。

• 指定WSL绝对路径并检查权限
  在Pipeline脚本中直接使用wsl.exe的绝对路径调用，避免环境变量缺失问题：

  C:\Windows\System32\wsl.exe --list
  

  同时确认服务账户拥有「登录为服务」权限，且能访问C:\Windows\System32目录及WSL安装路径。

• 检查WSL依赖服务状态
  WSL2依赖VMCompute服务，确保它处于运行状态：

  sc query vmcompute
  sc start vmcompute  # 如果未运行则启动
  

  并设置VMCompute为自动启动：

  sc config vmcompute start= auto
  

排查调试技巧 #

• 在Pipeline脚本中添加环境变量与用户信息输出，确认运行上下文：

  echo %PATH%
  whoami
  echo %USERPROFILE%
  

• 使用wsl --debug-shell命令在服务环境中启动调试shell，直接查看WSL的错误日志与运行状态。

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