搜索

docker exec 失败问题排查之旅

开源Linux

共 3120字，需浏览 7分钟

 · 2022-02-17


这篇文章学习的重点：

  • kubelet，docker-shim，dockerd，containerd，containerd-shim，runc 直接的关系
  • 排查方法：如何使用 docker，containerd-ctr，docker-runc 连接容器
  • runc 工作流程

问题描述

今天，在值班排查线上问题的过程中，发现系统日志一直在刷 docker 异常日志：

May 12 09:08:40 HOSTNAME dockerd[4085]: time="2021-05-12T09:08:40.642410594+08:00" level=error msg="stream copy error: reading from a closed fifo"
May 12 09:08:40 HOSTNAME dockerd[4085]: time="2021-05-12T09:08:40.642418571+08:00" level=error msg="stream copy error: reading from a closed fifo"
May 12 09:08:40 HOSTNAME dockerd[4085]: time="2021-05-12T09:08:40.663754355+08:00" level=error msg="Error running exec 110deb1c1b2a2d2671d7368bd02bfc18a968e4712a3c771dedf0b362820e73cb in container: OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused \"read init-p: connection reset by peer\": unknown"

从系统风险性上来看，异常日志出现的原因需要排查清楚，并摸清是否会对业务产生影响。


下文简单介绍问题排查的流程，以及产生的原因。

问题排查

现在我们唯一掌握的信息，只有系统日志告知 dockerd 执行 exec 失败。

在具体的问题分析之前，我们再来回顾一下 docker 的工作原理与调用链路：

docker调用链路

可见，docker 的调用链路非常长，涉及组件也较多。因此，我们的排查路径主要分为如下两步：

  • 确定引起失败的组件
  • 确定组件失败的原因

定位组件

熟悉 docker 的用户能够一眼定位引起问题的组件。但是，我们还是按照常规的排查流程走一遍：

# 1. 定位问题容器
$ sudo docker ps | grep -v pause | grep -v NAMES | awk '{print $1}' | xargs -ti sudo docker exec {} sleep 1
sudo docker exec aa1e331ec24f sleep 1
OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused "read init-p: connection reset by peer": unknown


# 2. 排除docker嫌疑
$ docker-containerd-ctr -a /var/run/docker/containerd/docker-containerd.sock -n moby t exec --exec-id stupig1 aa1e331ec24f621ab3152ebe94f1e533734164af86c9df0f551eab2b1967ec4e sleep 1
ctr: OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused "read init-p: connection reset by peer": unknown


# 3. 排除containerd与containerd-shim嫌疑
$ docker-runc --root /var/run/docker/runtime-runc/moby/ exec aa1e331ec24f621ab3152ebe94f1e533734164af86c9df0f551eab2b1967ec4e sleep
runtime/cgo: pthread_create failed: Resource temporarily unavailable
SIGABRT: abort
PC=0x6b657e m=0 sigcode=18446744073709551610

goroutine 0 [idle]:
runtime: unknown pc 0x6b657e
stack: frame={sp:0x7ffd30f0d218, fp:0x0} stack=[0x7ffd2ab0e738,0x7ffd30f0d760)
00007ffd30f0d118:  0000000000000002  00007ffd30f7f184
00007ffd30f0d128:  000000000069c31c  00007ffd30f0d1a8
00007ffd30f0d138:  000000000045814e   00007ffd30f0d140
00007ffd30f0d148:  00007ffd30f0d190  0000000000411a88 
00007ffd30f0d158:  0000000000bf6dd0  0000000000000000
00007ffd30f0d168:  0000000000010000  0000000000000008
00007ffd30f0d178:  0000000000bf6dd8  0000000000bf7ca0
00007ffd30f0d188:  00007fdcbb4b7000  00007ffd30f0d1c8
00007ffd30f0d198:  0000000000451205   0000000000000000
00007ffd30f0d1a8:  0000000000000000  0000000000c1c080
00007ffd30f0d1b8:  00007fdcbb4b7000  00007ffd30f0d1e0
00007ffd30f0d1c8:  00007ffd30f0d210  00007ffd30f0d220
00007ffd30f0d1d8:  0000000000000000  00000000000000f1
00007ffd30f0d1e8:  0000000000000011  0000000000000000
00007ffd30f0d1f8:  000000000069c31c  0000000000c1c080
00007ffd30f0d208:  000000000045814e   00007ffd30f0d210
00007ffd30f0d218: <00007ffd30f0d268  fffffffe7fffffff
00007ffd30f0d228:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d238:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d248:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d258:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d268:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d278:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d288:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d298:  ffffffffffffffff  0000000000000000
00007ffd30f0d2a8:  00000000006b68ba  0000000000000020
00007ffd30f0d2b8:  0000000000000000  0000000000000000
00007ffd30f0d2c8:  0000000000000000  0000000000000000
00007ffd30f0d2d8:  0000000000000000  0000000000000000
00007ffd30f0d2e8:  0000000000000000  0000000000000000
00007ffd30f0d2f8:  0000000000000000  0000000000000000
00007ffd30f0d308:  0000000000000000  0000000000000000
runtime: unknown pc 0x6b657e
stack: frame={sp:0x7ffd30f0d218, fp:0x0} stack=[0x7ffd2ab0e738,0x7ffd30f0d760)
00007ffd30f0d118:  0000000000000002  00007ffd30f7f184
00007ffd30f0d128:  000000000069c31c  00007ffd30f0d1a8
00007ffd30f0d138:  000000000045814e   00007ffd30f0d140
00007ffd30f0d148:  00007ffd30f0d190  0000000000411a88 
00007ffd30f0d158:  0000000000bf6dd0  0000000000000000
00007ffd30f0d168:  0000000000010000  0000000000000008
00007ffd30f0d178:  0000000000bf6dd8  0000000000bf7ca0
00007ffd30f0d188:  00007fdcbb4b7000  00007ffd30f0d1c8
00007ffd30f0d198:  0000000000451205   0000000000000000
00007ffd30f0d1a8:  0000000000000000  0000000000c1c080
00007ffd30f0d1b8:  00007fdcbb4b7000  00007ffd30f0d1e0
00007ffd30f0d1c8:  00007ffd30f0d210  00007ffd30f0d220
00007ffd30f0d1d8:  0000000000000000  00000000000000f1
00007ffd30f0d1e8:  0000000000000011  0000000000000000
00007ffd30f0d1f8:  000000000069c31c  0000000000c1c080
00007ffd30f0d208:  000000000045814e   00007ffd30f0d210
00007ffd30f0d218: <00007ffd30f0d268  fffffffe7fffffff
00007ffd30f0d228:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d238:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d248:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d258:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d268:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d278:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d288:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d298:  ffffffffffffffff  0000000000000000
00007ffd30f0d2a8:  00000000006b68ba  0000000000000020
00007ffd30f0d2b8:  0000000000000000  0000000000000000
00007ffd30f0d2c8:  0000000000000000  0000000000000000
00007ffd30f0d2d8:  0000000000000000  0000000000000000
00007ffd30f0d2e8:  0000000000000000  0000000000000000
00007ffd30f0d2f8:  0000000000000000  0000000000000000
00007ffd30f0d308:  0000000000000000  0000000000000000

goroutine 1 [running]:
runtime.systemstack_switch()
 /usr/local/go/src/runtime/asm_amd64.s:363 fp=0xc4200fe788 sp=0xc4200fe780 pc=0x454120
runtime.main()
 /usr/local/go/src/runtime/proc.go:128 +0x63 fp=0xc4200fe7e0 sp=0xc4200fe788 pc=0x42bb83
runtime.goexit()
 /usr/local/go/src/runtime/asm_amd64.s:2361 +0x1 fp=0xc4200fe7e8 sp=0xc4200fe7e0 pc=0x456c91

rax    0x0
rbx    0xbe2978
rcx    0x6b657e
rdx    0x0
rdi    0x2
rsi    0x7ffd30f0d1a0
rbp    0x8347ce
rsp    0x7ffd30f0d218
r8     0x0
r9     0x6
r10    0x8
r11    0x246
r12    0x2bedc30
r13    0xf1
r14    0x11
r15    0x0
rip    0x6b657e
rflags 0x246
cs     0x33
fs     0x0
gs     0x0
exec failed: container_linux.go:348: starting container process caused "read init-p: connection reset by peer"

由上可知，异常是 runc 返回的。

定位原因

定位异常组件的同时，runc 还给了我们一个惊喜：提供了详细的异常日志。

异常日志表明：runc exec 失败的原因是因为 Resource temporarily unavailable，比较典型的资源不足问题。而常见的资源不足类型主要包含（ulimit -a）：

  • 线程数达到限制
  • 文件数达到限制
  • 内存达到限制

因此，我们需要进一步排查业务容器的监控，以定位不足的资源类型。

业务线程数监控指标

上图展示了业务容器的线程数监控。所有容器的线程数都已经达到 1w，而弹性云默认限制容器的线程数上限就是 1w，设定该上限的原因，也是为了避免单容器线程泄漏而耗尽宿主机的线程资源。

$ cat /sys/fs/cgroup/pids/kubepods/burstable/pod64a6c0e7-830c-11eb-86d6-b8cef604db88/aa1e331ec24f621ab3152ebe94f1e533734164af86c9df0f551eab2b1967ec4e/pids.max
10000

至此，问题的原因已定位清楚，对，就是这么简单。

runc 梳理

虽然，我们已经定位了异常日志的成因，但是，对于 runc 的具体工作机制，一直只有一个模糊的概念。

趁此机会，我们以 runc exec 为例，梳理 runc 的工作流程。

  • runc exec 首先启动子进程 runc init
  • runc init 负责初始化容器 namespace
    • runc init 利用 C 语言的 constructor 特性，实现在 go 代码启动之前，设置容器 namespace
    • C 代码 nsexec 执行两次 clone，共三个线程：父进程，子进程，孙进程，完成对容器 namespace 的初始化
    • 父进程与子进程完成初始化任务后退出，此时，孙进程已经在容器 namespace 内，孙进程开始执行 go 代码初始化，并等待接收 runc exec 发送配置
  • runc exec 将孙进程添加到容器 cgroup
  • runc exec 发送配置给孙进程，配置主要包含：exec 的具体命令与参数等
  • 孙进程调用 system.Execv 执行用户命令

注意：

  • 步骤 2.c 与步骤 3 是并发执行的
  • runc exec 与 runc init 通信基于 socket pair 对（init-p 和 init-c）

runc exec 过程中各进程的交互流程，以及 namespace 与 cgroup 的初始化参见下图：

runc工作流程

综合我们对 runc exec 执行流程的梳理，以及 runc exec 返回的错误信息，我们基本定位到了 runc exec 返回错误的代码：

func (p *setnsProcess) start() (err error) {
   defer p.parentPipe.Close()
   err = p.cmd.Start()
   p.childPipe.Close()
   if err != nil {
      return newSystemErrorWithCause(err, "starting setns process")
   }
   if p.bootstrapData != nil {
      if _, err := io.Copy(p.parentPipe, p.bootstrapData); err != nil {       // clone标志位，ns配置
         return newSystemErrorWithCause(err, "copying bootstrap data to pipe")
      }
   }
   if err = p.execSetns(); err != nil {
      return newSystemErrorWithCause(err, "executing setns process")
   }
   if len(p.cgroupPaths) > 0 {
      if err := cgroups.EnterPid(p.cgroupPaths, p.pid()); err != nil {        // 这里将runc init添加到容器cgroup中
         return newSystemErrorWithCausef(err, "adding pid %d to cgroups", p.pid())
      }
   }
   if err := utils.WriteJSON(p.parentPipe, p.config); err != nil {            // 发送配置：命令、环境变量等
      return newSystemErrorWithCause(err, "writing config to pipe")
   }

   ierr := parseSync(p.parentPipe, func(sync *syncT) error {                  // 这里返回 read init-p: connection reset by peer
      switch sync.Type {
      case procReady:
         // This shouldn't happen.
         panic("unexpected procReady in setns")
      case procHooks:
         // This shouldn't happen.
         panic("unexpected procHooks in setns")
      default:
         return newSystemError(fmt.Errorf("invalid JSON payload from child"))
      }
   })
   if ierr != nil {
      p.wait()
      return ierr
   }
   return nil
}

现在，问题的成因与代码分析已全部完成。

Reference

  1. https://www.kernel.org/doc/Documentation/cgroup-v1/pids.txt
  2. https://github.com/opencontainers/runc

原文链接：https://xyz.uscwifi.xyz/post/DdS5a690E

Linux学习指南
有收获，点个在看 
浏览 3
点赞
评论
收藏
分享

手机扫一扫分享

举报
评论
图片
表情
推荐
堪称最优秀的Docker可视化管理工具——Portainer你真的会用吗？
来源：blog.csdn.net/shark_chili3007/article/details/123366179👉 欢迎加入小哈的星球 ，你将获得: 专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡 /  赠书福利全栈前后端分离博客项目
小哈学Java
0
展讯平台手机重启问题分析指南
和你一起终身学习，这里是程序员Android经典好文推荐，通过阅读本文，您将收获以下知识点:一、 User 版本 默认开启 sysdump 方法二、插入SD卡 抓取Sysdump log三、 sysdump log 分析四、展讯平台抓取重启 串口log的方案五、展讯平台判断重启类型六、展讯平台关闭
程序员Android
0
被开除了，因为用了Docker。。
将Python客栈设为“星标⭐”第一时间收到最新资讯来源丨经授权转自 古时的风筝（ID：gushidefengzheng）作者丨风筝前几天网上冲浪，看到一位技术管理者发了一个帖子。大意就是：“因为团队里一个程序员跟他反应说开发机内存不够了，请求换一台内存大一点的机器。这位管理者感到很诧异，为什么别人
Python客栈
1
字节面试：如何解决MQ消息积压问题？
面试题大全：www.javacn.siteMQ（Message Queue）消息积压问题指的是在消息队列中累积了大量未处理的消息，导致消息队列中的消息积压严重，超出系统处理能力，影响系统性能和稳定性的现象。1.消息积压是哪个环节的问题？MQ 执行有三大阶段：消息生产阶段。消息存储阶段。消息消费阶段。
Java中文社群
0
排名问题新解法：探索可视化计算中的 RANK 函数
上次我们介绍了可视化计算替代 DAX 计算的一些场景。参考：PowerBI 进阶：可视化计算替代 DAX 场景探索今天我们介绍一个新的场景，这是一个困扰许多人的问题，排名问题。在 DAX 中，很多新手小白对于上下文概念还不太理解，但在处理排名问题时又要求你必须理解一些上下文，比如常见的绝对排名和相对
PowerBI战友联盟
8
想都是问题，干就有答案，今天收获2个成绩
觉醒的拉新活动终于结束我以加入涛哥战队的方式去做的这次拉新活动最终排名是第4，没进前三虽然有遗憾，但还是从这个活动中学到了很多东西。为什么我要参与这个活动呢？参加这个拉新活动目的绝不是为了赚这个佣金，虽然我也能分到几千块，如果纯粹地为了赚这个佣金，其实是一个投入产出比极低的事情。最主要的还是奔着学习
python之禅
0
被开除了，因为用了Docker。。
前几天网上冲浪，看到一位技术管理者发了一个帖子。大意就是：“因为团队里一个程序员跟他反应说开发机内存不够了，请求换一台内存大一点的机器。这位管理者感到很诧异，为什么别人的都够，就你不够呢，于是到他的机器上看了一下，发现这位程序员同学在本地使用了 Docker，并且启动了很多容器。于是这位管理者大手一
Jack Cui
10
为什么回归问题用 MSE？
作者：Matrix.小泽直树来源：https://zhuanlan.zhihu.com/p/463812174最近在看李沐的实用机器学习课程，讲到regression问题的loss的时候有弹幕问：“为什么要平方？”如果是几年前学生问我这个问题，我会回答：“因为做回归的时候的我们的残差
机器学习算法与Python实战
10
分库分表后，数据库数据一致性问题如何解决？
来源：juejin.cn/post/6933003178661462023前言数据迁移分布式事务总结前言通过对数据的垂直拆分或水平拆分后，我们解决了数据库容量、性能等问题，但是将会面临数据迁移和数据一致性的问题。在数据迁移方面，需要考虑如何快速迁移、平滑迁移、不停机的迁移等。待数据迁移完毕后，还需要
java金融
0
面试官：MQ 消息丢失、重复、积压问题，如何解决？
点击关注上方“Stephen”，设为“置顶或星标”，第一时间送达干货面试官在面试候选人时，如果发现候选人的简历中写了在项目中使用了MQ 技术（如 Kafka、RabbitMQ、RocketMQ），基本都会抛出一个问题：在使用 MQ 的时候，怎么确保消息 100% 不丢失？这个问题在实际工作中很常见，
Stephen
0
点赞
评论
收藏
分享

手机扫一扫分享

举报