docker exec 失败问题排查之旅

最新推荐文章于 2024-03-20 10:19:26 发布
最新推荐文章于 2024-03-20 10:19:26 发布
阅读量1.3k 收藏 1
点赞数
文章标签： 定位 java golang go linux
原文链接：https://mp.weixin.qq.com/s?__biz=MzU1MzY4NzQ1OA==&mid=2247502072&idx=2&sn=6a2312228d3c84e6ab6d30be698839c4&chksm=fbed8835cc9a0123b34475f54a0b2e8f38064f0378085502233f1eb792bfadf94a230901e872&scene=126&&sessionid=0
版权

a12285d287e6bc4ef0edf49c8d707d8e.gif

这篇文章学习的重点：

  • 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 的工作原理与调用链路：

1d0693d2f285712b89d18e6bc3c2bbdf.png
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 <runtime.callCgoMmap+62>  00007ffd30f0d140
00007ffd30f0d148:  00007ffd30f0d190  0000000000411a88 <runtime.persistentalloc1+456>
00007ffd30f0d158:  0000000000bf6dd0  0000000000000000
00007ffd30f0d168:  0000000000010000  0000000000000008
00007ffd30f0d178:  0000000000bf6dd8  0000000000bf7ca0
00007ffd30f0d188:  00007fdcbb4b7000  00007ffd30f0d1c8
00007ffd30f0d198:  0000000000451205 <runtime.persistentalloc.func1+69>  0000000000000000
00007ffd30f0d1a8:  0000000000000000  0000000000c1c080
00007ffd30f0d1b8:  00007fdcbb4b7000  00007ffd30f0d1e0
00007ffd30f0d1c8:  00007ffd30f0d210  00007ffd30f0d220
00007ffd30f0d1d8:  0000000000000000  00000000000000f1
00007ffd30f0d1e8:  0000000000000011  0000000000000000
00007ffd30f0d1f8:  000000000069c31c  0000000000c1c080
00007ffd30f0d208:  000000000045814e <runtime.callCgoMmap+62>  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 <runtime.callCgoMmap+62>  00007ffd30f0d140
00007ffd30f0d148:  00007ffd30f0d190  0000000000411a88 <runtime.persistentalloc1+456>
00007ffd30f0d158:  0000000000bf6dd0  0000000000000000
00007ffd30f0d168:  0000000000010000  0000000000000008
00007ffd30f0d178:  0000000000bf6dd8  0000000000bf7ca0
00007ffd30f0d188:  00007fdcbb4b7000  00007ffd30f0d1c8
00007ffd30f0d198:  0000000000451205 <runtime.persistentalloc.func1+69>  0000000000000000
00007ffd30f0d1a8:  0000000000000000  0000000000c1c080
00007ffd30f0d1b8:  00007fdcbb4b7000  00007ffd30f0d1e0
00007ffd30f0d1c8:  00007ffd30f0d210  00007ffd30f0d220
00007ffd30f0d1d8:  0000000000000000  00000000000000f1
00007ffd30f0d1e8:  0000000000000011  0000000000000000
00007ffd30f0d1f8:  000000000069c31c  0000000000c1c080
00007ffd30f0d208:  000000000045814e <runtime.callCgoMmap+62>  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）：

  • 线程数达到限制

  • 文件数达到限制

  • 内存达到限制

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

143ddcbfdd788b36569104976968a34b.png
业务线程数监控指标

上图展示了业务容器的线程数监控。所有容器的线程数都已经达到 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 的初始化参见下图：

b3bfd9e16c9b45f8923dfd9ff41fc99e.png
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/

03ed436dbea8df4b675740a0768ac9b6.gif

627aee96d91cd8d37aef2c877d6fc02c.png

你可能还喜欢

点击下方图片即可阅读

49aa1314bc9eb44854c7a4daeeb5e653.png

服务网格：棋到中盘方见势

e55150adec026053e80d7b2f90c8fc5c.gif

云原生是一种信仰 🤘

关注公众号

后台回复◉k8s◉获取史上最方便快捷的 Kubernetes 高可用部署工具，只需一条命令，连 ssh 都不需要！

dfcac8fb383052a1ae5f9237b226f682.gif

5bca74cb3969942c1f4a24f44da3b77f.gif

点击 "阅读原文" 获取更好的阅读体验！

发现朋友圈变“安静”了吗？

037c090cb11ebab8974582a1ad0b7e4c.gif

米开朗基杨
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
excel导出在docker环境中总是失败的问题
09-29
主要介绍了excel导出在docker环境中总是失败的问题及解决方法，本文给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值，
docker基础介绍及问题排查.pptx
06-27
Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。
tried to kill container, but did not receive an exit event
最新发布
qq_38619478的博客
03-20 198
【代码】tried to kill container, but did not receive an exit event。
docker-exec-web-console：从浏览器到docker exec的Web UI
02-05
docker exec Web控制台 此图像最初是由启发的。 容器使用socat将Docker套接字绑定到TCP端口，这样我就可以避免更改Go服务器中的http.Post部分以直接与UNIX套接字进行通信。 您可以通过以下方式启动容器： docker run \ --name docker-exec-web-console \ -p 9999:8888 \ -v /var/run/docker.sock:/var/run/docker.sock \ bitbull/docker-exec-web-console 然后，您可以通过以下网址访问控制台： http://localhos
Docker 安装 Jenkins 并解决初始安装插件失败问题
09-29
主要介绍了Docker 安装 Jenkins 并解决初始安装插件失败问题,本文给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值，需要的朋友可以参考下
[问题未处理]-docker报错stream copy error- reading from a closed fifo导致服务器oom并cpu飙升后无响应
爷来辣的博客
09-28 8696
问题及原因 告警触发 服务器探活失败 最后宕机告警。 现象：系统oom cpu负载爆高 服务器连接不上 读写等爆炸 阿里云控制台vnc进入也显示超时 总共想通业务的机子有5台 其余4台服务器都没有问题。 关键错误日志 Sep 27 08:37:54 docker005 dockerd: time="2020-09-27T08:37:54.525450264+08:00" level=error msg="stream copy error: reading from a closed fifo"
stream copy error: reading from a closed fifo问题排查
热门推荐
暴走乔巴
03-16 1万+
stream copy error: reading from a closed fifo
Docker EOF问题排查
wanger5354的博客
07-14 1817
微信公众号：运维开发故事，作者：华仔 一、前言 问题排查过程，源码部分均由我的开发同事排查和记录；在征得其同意后，由我发表在此。 二、问题 某天接到客户反馈，pod的事件中出现大量的 warning event: Readiness probe failed: OCI runtime exec failed: exec failed: EOF: unknown。但不影响客户访问该服务。 三、环境 特别说明：客户在负责运行业务的k8s节点上坚持开启了cpu-manager 组件 版本 k.
getting the final child‘s pid from pipe caused \“EOF\““: unknown
Yu的博客
01-11 3260
k8s pod一直处于ContainerCreating，kd查看事件中报错 Failed create pod sandbox: rpc error: code = Unknown desc = failed to start sandbox container for pod "image-nginx": Error response from daemon: OCI runtime create failed: container_linux.go:346: starting container
pthread_create failed: Resource temporarily unavailable
LeftShadow
03-30 3447
golang 线程创建失败 runtime/cgo: pthread_create failed: Resource temporarily unavailable SIGABRT: abort 简要描述 接了个报警，一个后台服务挂了，看了下 nohup 打出来的日志，发现线程创建过多，资源分配不过来，进程直接被杀死了。 问题分析 分析了一下日志 crontab服务正在启动,PID: 12123 ,时间: 2021-01-01 15:00:00 runtime/cgo: pthread_create f
如何解决docker容器启动失败
09-29
在本片文章中小编给各位整理的是关于如何解决docker容器启动失败相关内容，有兴趣的朋友们可以参考下。
Docker push镜像失败解决方法
09-30
主要介绍了Docker push镜像失败解决方法的相关资料,这里对解决push 镜像失败提供了解决方案，需要的朋友可以参考下
docker-exec-automation:批处理 docker-exec 任务的脚本
06-06
Docker Exec 机器人批处理 docker-exec 任务的脚本。安装$ git clone https://github.com/docker-exec/docker-exec-bot.git$ cd docker-exec-bot$ cp .dbot-placeholder .dbot 完成“.dbot”配置文件中所需的属性。 ...
Docker 常见问题解决
09-29
主要介绍了如何解决Docker 常见问题，帮助大家更好的理解和使用docker容器，感兴趣的朋友可以了解下
fede:快速简单的 Docker Exec
06-30
用法###Exec fede exec [docker-exec-params] container-name-regex command [params]因此，对于一次性命令： fede exec web ps aux 对于交互式内容： fede exec -it db mysql -p ＃＃＃存根 fede stub stub-name ...
一次docker错误的耗时排查过程记录
01-09
客户是深信服的订制系统，基于 centos 改的，排查半天发现居然是文件损坏，而不是 docker 的问题。 环境信息 docker信息: $ docker info Containers: 0 Running: 0 Paused: 0 Stopped: 0 Images: 2 Server ...
Docker核心技术之镜像
09-22
Docker核心技术之镜像
dockerexc:在所选容器上运行docker exec -it container_id binbash
05-11
docker exec -it container_id /bin/bash 您还可以添加项目并从任何地方启动它们，只需设置docker-compose.yml的名称和路径即可。 dockerexc --name="ProjectName" --path="/Users/user/project/docker-compose....
docker exec
09-24
### 回答1： docker exec 是一个 Docker 命令，用于在运行中的容器中执行命令。它可以让你在容器内部执行各种操作，比如查看日志、运行 shell 脚本、安装软件等等。使用 docker exec 命令时，需要指定要进入的容器名称或 ID，以及要执行的命令。例如： ``` docker exec -it my_container bash ``` 上面的命令会进入名为 my_container 的容器，并在容器内启动一个 bash 终端。 ### 回答2： Docker exec是一个Docker命令，用于在正在运行的容器中执行命令。 通过docker exec命令，我们可以进入正在运行的容器中，并在容器的环境中执行指定的命令。这样可以方便地与容器交互，执行各种操作，如安装软件、启动服务、修改配置文件等。 使用docker exec命令的基本语法如下： docker exec [选项] 容器ID/容器名 命令 其中，[选项]可以是以下几个常用选项： -d：分离模式，在容器中后台执行命令 -i：交互模式，保持标准输入开启，可与-t选项一同使用 -t：为命令分配一个伪终端 例如，我们可以通过以下命令，进入一个正在运行的容器并查看其中的文件列表： docker exec -it 容器ID/容器名 ls 还可以通过以下命令，在容器中执行一个shell脚本： docker exec -i -t 容器ID/容器名 /bin/bash -c "脚本路径/脚本名.sh" 当我们想在后台执行某个命令时，可以使用-d选项： docker exec -d 容器ID/容器名 命令 总之，Docker exec是一个非常实用的命令，它可以让我们方便地与正在运行的容器进行交互，并在容器环境中执行各种操作和命令。无论是调试应用程序、修改容器配置还是执行其他操作，docker exec都是一个强大而方便的工具。 ### 回答3： Docker exec 是一个 Docker 命令，用于在正在运行的 Docker 容器中执行命令。该命令允许用户在容器内部运行自定义命令，与容器进行交互并执行一系列操作。 使用 docker exec 命令的语法如下： ```Shell docker exec [OPTIONS] CONTAINER COMMAND [ARG...] ``` 其中，OPTIONS 表示可选的参数，CONTAINER 表示要执行命令的容器，COMMAND 表示要在容器内执行的命令，ARG 表示命令的参数。 通过使用 docker exec 命令，可以在容器内部执行各种命令，例如进入容器的交互式终端、执行特定的 shell 命令、运行脚本等。 与使用 docker attach 命令不同的是，docker exec 命令在容器内部另行启动一个进程执行命令，并且不会中止容器的主进程。因此，使用 docker exec 命令可以在容器运行期间进行试验、调试和管理操作，而不会影响到容器的正常运行。 为了使用 docker exec 命令，必须确保容器处于运行状态。同时，要执行的命令必须是容器内部可执行的命令，并且容器内部必须已经安装了相应的工具或软件。 总而言之，docker exec 是一个非常有用的命令，它允许用户在正在运行的 Docker 容器中执行各种操作，并且不会影响到容器的正常运行。通过 docker exec 命令，用户可以方便地与容器内部进行交互、执行命令并且进行调试和管理操作。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值