如何使用Valgrind检测Docker-Compose容器内存泄漏并跟踪Docker调用？

首先得明确为什么你的命令没效果：docker-compose本质是一个客户端工具，它的作用只是向Docker Daemon发送指令，让Daemon去创建、启动容器。容器进程是Docker Daemon的子进程，而非docker-compose的子进程——Valgrind的--trace-children=yes只能跟踪当前启动进程（这里就是docker-compose）直接fork/exec出来的子进程，完全触及不到Daemon启动的容器进程，所以docker-compose部署完退出后，Valgrind自然就停止跟踪了。

要检测容器内应用的内存泄漏，有几种更可行的方案：

方案1：在容器内部用Valgrind启动应用 #

这是最直接且推荐的方式，把Valgrind集成到容器的启动流程里：

1. 修改Dockerfile，安装Valgrind工具（以Debian/Ubuntu镜像为例）：

   FROM ubuntu:latest
   # 安装依赖和Valgrind
   RUN apt-get update && apt-get install -y valgrind
   # 复制你的应用程序到容器内
   COPY myapp /usr/local/bin/
   # 用Valgrind启动应用，指定日志输出路径
   CMD ["valgrind", "--log-file=/tmp/debug.log", "--track-origins=yes", "--leak-check=full", "/usr/local/bin/myapp"]
   

2. 在docker-compose.yml中挂载日志目录，方便你在主机上查看Valgrind的输出：

   version: '3.8'
   services:
     my-service:
       build: ./path/to/dockerfile
       volumes:
         - ./valgrind-logs:/tmp  # 将容器的/tmp目录挂载到主机的valgrind-logs文件夹
       # 如果不需要重新构建，也可以直接覆盖command字段
       # command: ["valgrind", "--log-file=/tmp/debug.log", "--track-origins=yes", "/usr/local/bin/myapp"]
   

3. 启动容器后，主机的./valgrind-logs目录下就会生成debug.log，里面包含完整的内存泄漏检测结果。

方案2：附加Valgrind到已运行的容器进程 #

如果不想修改容器启动流程，可以先启动容器，再通过docker exec进入容器，用Valgrind附加到运行中的应用进程：

1. 正常启动容器：

   docker-compose -f docker-compose.yml up --build -d
   

2. 查看容器内目标应用的进程ID（PID）：

   docker exec <容器名称或ID> ps aux
   

3. 进入容器并运行Valgrind附加命令：

   docker exec -it <容器名称或ID> valgrind --attach=<目标PID> --log-file=/tmp/debug.log --track-origins=yes
   

   注意：这种方式需要容器内已经安装了Valgrind，而且目标进程没有开启严格的地址空间保护，部分容器镜像可能默认限制了调试权限，你可能需要在启动容器时添加--cap-add=SYS_PTRACE参数来允许调试：

   # 在docker-compose.yml的service中添加
   services:
     my-service:
       # ...其他配置
       cap_add:
         - SYS_PTRACE
   

方案3：使用Docker的PID命名空间共享（仅适合本地调试） #

你可以让容器共享主机的PID命名空间，这样主机上能直接看到容器内的进程，然后在主机上用Valgrind跟踪：

1. 修改docker-compose.yml，添加pid: host：

   version: '3.8'
   services:
     my-service:
       # ...其他配置
       pid: host
   

2. 启动容器后，在主机上找到容器内应用的PID，然后用Valgrind跟踪：

   valgrind --log-file=/tmp/debug.log --track-origins=yes --attach=<容器内应用的主机PID>
   

   这种方式的风险是容器能访问主机的所有进程，安全性较差，只适合本地调试场景。

总结一下，方案1是最稳妥的选择，它能完整跟踪应用从启动到运行的整个生命周期的内存情况，而且不需要额外的权限配置。

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