web-dev-qa-db-ja.com

tail -fがDockerコンテナのログファイルを追跡しない

CoreOSのDockerコンテナー内でtail -fコマンドを実行すると、奇妙な動作が発生します。

問題の原因となっていると思われる変数がいくつかありますが、最初にトラブルシューティングするために何をする必要があるのか​​わかりません。 CoreOSでは、overlayfsをサポートする最新バージョンと、新しいバージョンのDocker（1.4.1）を実行しています。

興味深いのは、Docker（1.3）の異なるバージョンを実行している別のホストOS（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に精通していません。

loggingdockertailstracecoreos
7
jmreicha

解決策ではなく回避策：

CoreOS 607.0.0でも同じ問題が発生し、UbuntuまたはFedoraベースのコンテナーでこの問題を再現しました。ただし、busyboxを使用するコンテナにはこの問題はありません。 2つの回避策：

1）Alpineなどのbusyboxベースのコンテナーイメージを使用する

2）busyboxを既存のコンテナにインストールして実行します

busybox tail -F <logfile>
4
Christoph

これは、デフォルトのファイルシステムがbtrfsからoverlayfsに変更されたときにCoreOS 561で導入された bug です。ホストが最初に起動したときに、基本的にbtrfsを使用してファイルシステムをフォーマットする workaround を見つけましたが、今のところそれは機能しているようです。

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
3
Brandon