☰

tail -f 未跟踪 Docker 容器中的日志文件

tag-icon • tag-icon logging docker tail strace coreos
tail -f 未跟踪 Docker 容器中的日志文件

我发现tail -f在 CoreOS 中的 Docker 容器内运行命令时出现了一些奇怪的行为。

我能想到的很多变量都可能导致了这个问题，但我不确定首先需要做什么来排除故障。在 CoreOS 上，我运行的是支持 overlayfs 的最新版本，以及较新版本的 Docker (1.4.1)。

有趣的是，我能够在运行不同版本 Docker（1.3）的不同主机操作系统（Ubuntu 14.04）上成功地跟踪日志。

如果这有助于排除故障，我可以生成 strace 日志，它们似乎在不同的主机上存在很大差异。例如，在不工作的主机上，在 strace 输出中读取以下内容后，strace 停止：

04:03:03 inotify_add_watch(4, "f017f0a1-a1e9-11e4-90bc-027e0f87cac6-paster.log", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 1 <0.000028>
04:03:03 fstat(3, {st_mode=S_IFREG|0644, st_size=12229, ...}) = 0 <0.000022>
04:03:03 read(4, 0x7711f0, 64)          = ? ERESTARTSYS (To be restarted if SA_RESTART is set) <3.101545>

我对 strace 不够熟悉，无法很好地解释结果。

答案1

这不是解决方案，而是一种解决方法：

我在 CoreOS 607.0.0 上遇到了同样的问题，并在基于 Ubuntu 或 Fedora 的容器中重现了此问题。但是使用 busybox 的容器没有这个问题。两种解决方法：

1）使用基于 busybox 的容器镜像，例如 alpine

2）在现有容器中安装 busybox 并运行

busybox tail -F <logfile>

答案2

这是一个漏洞在 CoreOS 561 中，当默认文件系统从 btrfs 更改为 overlayfs 时引入了此功能。我发现解决方法在主机首次启动时基本上使用 btrfs 格式化文件系统，目前看来这是可行的。

在您的 CloudInit 中包含以下内容：

#cloud-config
coreos:
  units:
    - name: format-var-lib-docker.service
      command: start
      content: |
        [Unit]
        Before=docker.service var-lib-docker.mount
        ConditionPathExists=!/var/lib/docker.btrfs
        [Service]
        Type=oneshot
        ExecStart=/usr/bin/truncate --size=25G /var/lib/docker.btrfs
        ExecStart=/usr/sbin/mkfs.btrfs /var/lib/docker.btrfs
    - name: var-lib-docker.mount
      enable: true
      content: |
        [Unit]
        Before=docker.service
        After=format-var-lib-docker.service
        Requires=format-var-lib-docker.service
        [Install]
        RequiredBy=docker.service
        [Mount]
        What=/var/lib/docker.btrfs
        Where=/var/lib/docker
        Type=btrfs
        Options=loop,discard

相关内容