我看到一些奇怪的行为在CoreOS的Docker容器中运行tail -f命令。
我可以想到的一些变数可能会导致这个问题，但我不确定我需要做什么来排除故障。 在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，非常善于解释结果。
不是一个解决scheme，而是一个解决方法：
我在CoreOS 607.0.0上遇到同样的问题，并在基于Ubuntu或Fedora的容器中转载了这个问题。 但是使用busybox的容器没有这个问题。 两种解决方法：
1）使用基于busybox的容器图像，如高山
2）在你现有的容器中安装busybox并运行
busybox tail -F <logfile>
这是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