Bitbucket自托管EC2 Runner管道持续报Docker错误137求助

核心分析方向 #

错误137通常指向容器被内核OOM Killer终止，但你已排除常规内存/CPU、存储问题，且仅在启用services:docker时触发，问题有明确的1个月周期，所以重点要从Docker-in-Docker（DinD）的资源泄漏或系统级Docker权限/资源限制的隐性变化入手。

具体排查步骤 #

1. 追踪DinD容器的资源泄漏 #

启用services:docker时，Bitbucket Runner会启动DinD容器，这类容器长期运行极易积累未清理的镜像、容器、volume，即使主机存储充足，DinD内部存储也可能耗尽：

• 直接清理DinD残留资源：

  # 若Runner是容器部署，先进入Runner容器
  docker exec -it <bitbucket-runner-container-id> sh
  # 强制清理DinD内所有无用资源
  docker system prune -af --volumes
  

  也可在Runner主机上找到关联的DinD容器ID，直接清理其内部资源。

2. 检查Docker的内存与cgroup配置 #

• 调整Docker默认共享内存：DinD容器默认使用主机的shm，若shm不足会触发错误137。检查/etc/docker/daemon.json，添加或修改：

  {
    "default-shm-size": "4g"
  }
  

  重启Docker：systemctl restart docker。
• 验证cgroup版本兼容性：Amazon Linux 2默认用cgroup v1，ECS优化AMI可能切换到v2，DinD对v2的适配可能存在隐性问题。查看当前cgroup版本：

  stat -fc %T /sys/fs/cgroup/
  

  若输出cgroup2fs，尝试切换回v1：在GRUB启动参数中添加systemd.unified_cgroup_hierarchy=0，重启主机。

3. 精准定位OOM Killer目标进程 #

即使监控了内存，也要确认是哪个进程触发了OOM：

• 查看系统日志中的OOM Killer记录：

  dmesg | grep -i "oom-killer"
  

  或检查/var/log/messages、/var/log/syslog，确认被杀死的是Pipeline容器还是DinD的子进程。

4. 调整Runner与Pipeline的资源分配 #

• 修改Runner配置文件（通常为runner.properties），提升Runner容器的资源上限：

  runner.capacity.memory=8g
  runner.capacity.cpu=4
  

  重启Runner服务：systemctl restart bitbucket-runner。
• 在Pipeline步骤中显式设置Docker服务的资源限制：

  pipelines:
    default:
      - step:
          services:
            - docker
          resources:
            memory: 4096
            cpu: 2
          script:
            - # 你的业务命令
  

5. 排查yum更新带来的依赖变更 #

每周yum更新可能导致containerd、runc等Docker依赖包版本变化，引发兼容性问题：

• 回滚最近一次Docker相关包的更新：

  yum history list docker* containerd runc
  yum history undo <对应更新ID>
  

  暂时禁用Docker相关包的自动更新，观察问题是否复现。

6. 强制留存失败Pipeline容器日志 #

无法查看失败容器日志是排查瓶颈，修改Runner配置留存失败容器：

• 在Runner配置中添加：

  runner.pipeline.container.keep-failed=true
  

  重启Runner后，失败的Pipeline容器不会被自动删除，可通过docker logs <失败容器ID>获取日志。

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