1. 问题描述

GitLab CI任务，Runner使用的是docker machine executor类型的执行器，执行失败报错：

Running on runner-h6ezaymy-project-1037-concurrent-0 via runner-h6ezaymy-auto-scale-1668060271-ce458595...
...
WARNING: Failed to pull image with policy "if-not-present": error during connect: Post https://192.168.99.251:2376/v1.25/images/create?fromImage=registry.gitlab.com%2Fgitlab-org%2Fgitlab-runner%2Fgitlab-runner-helper&tag=x86_64-58ba2b95: dial tcp 192.168.99.251:2376: connect: no route to host (manager.go:205:3s)
ERROR: Job failed (system failure): error during connect: Post https://192.168.99.251:2376/v1.25/containers/47272fbe49e4be0f85724ad99f0657b72f568810ce0f4914c57e7fcf114764e2/wait: dial tcp 192.168.99.251:2376: connect: no route to host

重试，问题依旧。

2. 排查思路

问题原因猜测：

偶发问题？确认是否能稳定复现
CICD配置问题？确认CICD配置，检查用法是否正确
runner问题？重启runner，再次尝试复现

排查确认：

偶发问题，重试失败，但是夜间可以成功执行
CICD配置正常，报错与配置无关，而且夜间可以成功执行
runner问题无法排除，需要进一步排查

3. Runner问题排查

3.1. 网络问题？

登录到runner所在宿主机，进入到runner

1	docker-machine ssh runner-h6ezaymy-auto-scale-1668060271-ce458595

提示vm不存在。

1	docker-machine ls

查看当前的vm，负责运行任务的vm确实不存在了，看来不是网络问题。
怀疑是vm出问题被干掉了，然后重新创建了一个vm。
那么vm为什么会被干掉？看看日志吧。

3.2. 查看系统日志

1
2
3

journalctl -xe
# or
cat /var/log/messages | grep -i kill -A3 -B3

确实找到了程序被干掉的证据，刚好和gitlabci任务失败的时间吻合。

1
2

11月 10 17:13:42 runner kernel: Out of memory: Kill process 12293 (MainHGCMthread) score 215 or sacrifice child
11月 10 17:13:42 runner kernel: Killed process 12294 (EMT-0), UID 0, total-vm:4345420kB, anon-rss:45340kB, file-rss:2622104kB, shmem-rss:4kB

那么这个vm为什么被干掉了？oom？

3.3. CI任务占用内存太高？

检查ci任务的代码，并没有发现导致超高内存占用的逻辑。

3.4. Linux OOM机制

回想起Linux OOM的逻辑，并不是一个程序占用内存高就把它干掉，而是整个系统的内存高，才会选出一个打分最高的程序干掉。

这就合理了，下午的时候runner所在宿主机上跑满了任务，很有可能出现内存紧张的情况。而这个被干掉的runner当时被打分最高，所以被干掉了。

Linux OOM机制参考：

4. 解决办法

方法一：增加资源
升级宿主机内存，或者添加runner宿主机

方法二：错峰执行ci任务
比如这个失败的任务，还是夜间执行吧

一个计算机技术爱好者与学习者

好好学GitLab：GitLab CI报错ERROR: Job failed (system failure)