Docker Compose日志命令因日志大小报错退出求助

我运行多个Docker容器，用以下命令将所有容器日志写入文件：

docker-compose -f docker-compose.yml logs -f -t &> output.log &

我的docker-compose.yml配置片段如下：

version: '3.7'

services:
  pm-a:
    # ...
    environment:
      PYTHONUNBUFFERED: 1
      # ...
    logging:
      driver: "json-file"
      options:
        max-size: "200k"
        max-file: "10"
        mode: "non-blocking"
 # 其他服务配置类似...

运行一段时间后，未终止任何容器的情况下，docker-compose logs命令意外退出，output.log最后一行报错：

error from daemon in stream: Error grabbing logs: no such file or directory

经测试，该问题和日志大小直接相关：增大日志上限会延迟问题出现，日志输出量大会加速触发。我原本认为日志轮转应该能保证docker-compose logs持续运行，但实际日志达到上限后还能正常轮转一段时间才出问题。我已经用docker inspect --format='{{.LogPath}}'检查过底层日志文件，确认日志早已达到上限。

我试过更换日志驱动（比如local）、调高COMPOSE_HTTP_TIMEOUT等方法，都没解决问题。我的Docker版本是：

Docker version 20.10.13, build a224086

我有三个问题：

1. 我对日志轮转的理解是否有误？日志达到上限时日志命令退出是否为预期行为？
2. 作为Docker新手，有哪些方法可更深入调试该问题，比如获取更详细的报错信息？
3. 若有直接解决方案，恳请告知！

问题解答 #

1. 日志轮转的理解与预期行为 #

你的理解没错，日志轮转的设计目标就是保证日志收集命令（比如docker-compose logs -f）持续运行，不会因为日志文件轮转就退出。这个报错不是预期行为，属于Docker daemon或docker-compose在处理日志轮转时的bug，尤其是在json-file驱动的non-blocking模式下更容易触发——当轮转后的日志文件被删除/重命名时，daemon可能丢失了文件句柄，导致后续日志流读取失败。

2. 深入调试的方法 #

• 开启Docker daemon的调试日志：修改Docker配置文件（比如/etc/docker/daemon.json），添加"debug": true，然后重启Docker服务。此时daemon会输出更详细的日志到系统日志（比如journalctl -u docker.service），可以看到日志读取失败时的具体上下文。
• 直接用docker logs -f单独跟踪单个容器的日志，排查是特定容器触发的问题还是所有容器都有问题，缩小范围。
• 用strace跟踪docker-compose进程，看退出时的系统调用细节：

  strace -f -o compose_strace.log docker-compose -f docker-compose.yml logs -f -t
  

  查看compose_strace.log里的错误调用，定位具体是哪个文件操作失败。

3. 直接解决方案 #

• 升级Docker版本：你用的20.10.13是较老的版本，后续的20.10.x补丁版本以及23.x、24.x版本都修复了多个日志轮转相关的bug，升级到最新的LTS版本（比如20.10.24+）大概率能解决问题。
• 调整日志驱动参数：如果暂时无法升级，去掉mode: "non-blocking"配置——非阻塞模式下，日志轮转时的文件句柄管理更容易出问题，换成默认的阻塞模式能降低触发概率。
• 替代日志收集方案：用专门的日志收集工具（比如fluentd、filebeat）直接读取Docker的日志文件目录（默认是/var/lib/docker/containers/<container-id>/），绕过docker-compose logs的限制，这种方式更稳定，适合长期日志收集。

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