爱刨根知识网

  1. 首页 > 经验知识 > >

译文-来自: Netflix 在 Linux 内核中调试 FUSE 死锁

生活经验linux


译文-来自: Netflix 在 Linux 内核中调试 FUSE 死锁

文章插图
Netflix 的计算团队负责管理 Netflix 的所有 AWS 和容器化工作负载，包括自动缩放、容器部署、问题修复等 。作为该团队的一员，我致力于修复用户报告的奇怪问题 。
这个特殊问题涉及自定义内部FUSE 文件系统：ndrive 。它已经溃烂了一段时间，但需要有人坐下来愤怒地看着它 。/proc这篇博文描述了在将问题发布到内核邮件列表并了解内核等待代码的实际工作原理之前，我是如何深入了解发生了什么的！
症状：卡住 Docker Kill 和僵尸进程
我们有一个停滞的 docker API 调用：
goroutine 146 [选择，8817 分钟]：net/***/***/***/***/***/***/***/***/***/***/***/***/***/***/x/net/context/ctx***/x/net@v0.0.0-20211209124913-491a49abca63/context/ctx***/docker/docker/client.(*Client).doRequest(0xc0001a8200, 0x163bd48, 0xc00004409 0, 0xc000966100, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) /go/pkg/mod/github.com/moby/moby@v0.0.0-20190408150954-50ebe4562dfc/client/request.go:132 +0xbegithub.com/docker/docker/client.(*Client).sendRequest(0xc0001a8200, 0x163bd48, 0xc000044090, 0x13d8643, 0x3, 0xc00079a720, 0x51, 0x0, 0x0, 0x0, ...) /go/pkg/mod /github 。com/moby/moby@v0.0.0-20190408150954-50ebe4562dfc/client/request.go:122 +0x156 github.com/docker/docker/client.(*Client).get(...) /go/pkg/mod /github.com/moby/moby@v0.0.0-20190408150954-50ebe4562dfc/client/request.go:37 github.com/docker/docker/client.(*Client).ContainerInspect(0xc0001a8200, 0x163bd48, 0xc000044090, 0xc 0006a01c0, 0x40 , 0x0, 0x0, 0x0, 0x0, 0x0, ...) /go/pkg/mod/github.com/moby/moby@v0.0.0-20190408150954-50ebe4562dfc/client/container_inspect.go:18 +0x128github.com/Netflix/titus-executor/executor/runtime/docker.(*DockerRuntime).Kill(0xc000215180, 0x163bdb8, 0xc000938600, 0x1, 0x0, 0x0) /var/lib/buildkite-agent/builds/ip-192- 168-1-90-1/netflix/titus-executor/executor/runtime/docker/docker.go:2835 +0x310 github.com/Netflix/titus-executor/executor/runner.(*Runner).doShutdown(0xc000432dc0, 0x163bd10, 0xc000938390, 0x1, 0xc000b821e0, 0x1d, 0xc0005e4710) /var/lib/buildkite-agent/builds/ip-192-168-1-90-1/netflix/titus-executor/executor/runner/runner.go:3 26 +0x4f4 github.com/Netflix/titus-executor/executor/runner.(*Runner).startRunner(0xc000432dc0, 0x163bdb8, 0xc00071e0c0, 0xc0a502e28c08b488, 0x24572b8, 0x1df5980) /var/lib/buildkite-agent/builds/ip-192-168-1-90-1/netflix/titus-executor/executor/runner/runner.go:122 +0x391由 github.com/Netflix/titus- 创建执行者/执行者/runner.StartTaskWithRuntime /var/lib/buildkite-agent/builds/ip-192-168-1-90-1/netflix/titus-executor/executor/runner/runner.go:81 +0x411在这里，我们的管理引擎对 Docker API 的 unix 套接字进行了 HTTP 调用，要求它终止一个容器 。我们的容器配置为通过SIGKILL. 但这很奇怪 。kill(SIGKILL)应该是比较致命的，那么容器是干什么的呢？
$ docker exec -it 6643cd073492 bash OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: process_linux.go:130: executing setns process caused: exit status 1: 未知唔 。似乎它还活着，但setns(2)失败了 。为什么会这样？如果我们通过查看进程树ps awwfux，我们会看到：
\_ containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/6643cd073492ba9166100ed30dbe389ff1caef0dc3d35 | \_ [码头工人初始化] | \_ [ndrive] <已失效>好的，所以容器的 init 进程仍然存在，但是它有一个僵尸子进程 。容器的初始化进程可能在做什么？
# cat /proc/1528591/stack [<0>] do_wait+0x156/0x2f0 [<0>] kernel_wait4+0x8d/0x140 [<0>] zap_pid_ns_processes+0x104/0x180 [<0>] do_exit+0xa41/0xb80 [< 0>] do_group_exit+0x3a/0xa0 [<0>] __x64_sys_exit_group+0x14/0x20 [<0>] do_syscall_64+0x37/0xb0 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xae

推荐阅读


上一篇：vmware虚拟机安装教程(xp/win7版 图文演示虚拟机vmware安装win7系统教程)

下一篇：系统之家 win7 系统之家官网win7纯净版系统下载