tail -f folgt nicht der Protokolldatei im Docker-Container

Ich sehe ein seltsames Verhalten beim Ausführen des tail -fBefehls in einem Docker-Container in CoreOS.

Es gibt eine Reihe von Variablen, von denen ich mir vorstellen kann, dass sie zum Problem beitragen, aber ich bin mir nicht sicher, was ich tun muss, um zuerst Fehler zu beheben. Unter CoreOS verwende ich die neueste Version mit Overlayfs-Unterstützung sowie eine neuere Version von Docker (1.4.1).

Interessant ist, dass ich Protokolle erfolgreich auf einem anderen Host-Betriebssystem (Ubuntu 14.04) beenden kann, auf dem eine andere Version von Docker (1.3) ausgeführt wird.

Ich kann Strace-Protokolle erstellen, wenn dies zur Fehlerbehebung beiträgt. Sie scheinen sich zwischen den Hosts erheblich zu unterscheiden. Auf dem Host, der nicht funktioniert, stoppt die Strace beispielsweise, nachdem in der Strace-Ausgabe Folgendes eingelesen wurde:

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>

Ich bin mit strace einfach nicht vertraut genug, um die Ergebnisse sehr gut zu interpretieren.

— jmreicha
quelle

Genau das gleiche Problem hier zu haben. Noch kein Glück, das herauszufinden?

— Roberto Andrade

@ RobertoAndrade hat dies immer noch nicht herausgefunden. Meine Problemumgehung besteht derzeit darin, "less + F file.log" zu verwenden, aber es ist keine großartige Lösung. Lassen Sie mich wissen, wenn Sie etwas finden!

— jmreicha

Ich habe zu einem Debian-Host mit derselben Docker-Version und denselben Containern gewechselt und alles funktioniert gut (dasselbe mit einem boot2docker-Host). All dies mit den neuesten Versionen für alle Komponenten.

— Roberto Andrade

@ RobertoAndrade Ja, ich hatte das gleiche Ergebnis. Ich würde immer noch gerne herausfinden, warum CoreOS Probleme zu haben schien. Wissen Sie zufällig, welche Version von CoreOS verwendet wird?

— jmreicha

Antworten:

Keine Lösung, sondern eine Problemumgehung:

Ich habe das gleiche Problem unter CoreOS 607.0.0 und habe dieses Problem in Containern reproduziert, die auf Ubuntu oder Fedora basieren. Container, die Busybox verwenden, haben dieses Problem jedoch nicht. Zwei Problemumgehungen:

1) Verwenden Sie ein Busybox-basiertes Containerbild wie z. B. alpine

2) Installieren Sie die Busybox in Ihrem vorhandenen Container und führen Sie sie aus

busybox tail -F <logfile>

— Christoph
quelle

Kater-Alpen funktioniert!

— Miao1007

Dies ist ein Fehler , der in CoreOS 561 eingeführt wurde, als das Standarddateisystem von btrfs auf overlayfs geändert wurde. Ich habe eine Problemumgehung gefunden, um das Dateisystem beim ersten Start eines Hosts grundsätzlich mit btrfs zu formatieren, und das scheint vorerst zu funktionieren.

Nehmen Sie Folgendes in Ihr CloudInit auf:

#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

— Brandon
quelle