`tail -f` wird manchmal nicht mehr aktualisiert - und die Datei wurde nicht verschoben

Ich habe kürzlich festgestellt, dass tail -f <logfile>die Aktualisierung des Bildschirms manchmal unterbrochen wird.

Ein Ctrl>- Cund ein Neustart tailfunktioniert jedoch einwandfrei. Und ich habe überprüft, ob die Protokolldatei nicht in der Mitte des Streams gedreht wird (was dazu führen kann, dass tailsie den Verstand verliert).

Was würde das verursachen? Ich verwende RHEL 5.2 x64.

Versuchen Sie, Ihren Schwanzbefehl mit stracefolgenden Zeichen zu versehen:

strace -Tt -o /tmp/tail.trace tail -f /var/log/messages

Dann können Sie nur für verrückte rekursive Kicks die Strace-Ausgabe verfolgen (spielt keine Rolle, wenn das kaputt geht, weil es in eine Datei geht):

 tail -f /tmp/tail.trace

Meins sieht aus wie:

8:39:00 write(1, "ng SMAC\n", 8)       = 8 <0.000026>
18:39:00 read(3, "", 0)                 = 0 <0.000019>
18:39:00 fstat64(3, {st_mode=S_IFREG|0640, st_size=92990, ...}) = 0 <0.000019>
18:39:00 fstatfs64(3, 84, {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=4807069, f_bfree=1924458, f_bavail=1680271, f_files=1221600, f_ffree=820806, f_fsid={-1331083162, -1313908385}, f_namelen=255, f_frsize=4096}) = 0 <0.000021>
18:39:00 inotify_init()                 = 4 <0.000033>
18:39:00 inotify_add_watch(4, "/var/log/messages", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 1 <0.000041>
18:39:00 fstat64(3, {st_mode=S_IFREG|0640, st_size=92990, ...}) = 0 <0.000019>
18:39:00 read(4,

Das -t schaltet die Zeit ein und -T schaltet die in Anrufen verbrachte Zeit ein.

Drücken Sie 4 oder 5 Mal die Eingabetaste, um ein wenig vertikalen Raum zu schaffen, und warten Sie dann, bis das Tailing aufhört. Hoffentlich gibt es einige Hinweise in der Ausgabe.

Versuchen Sie es mit:

tail --follow=name <logfile>

Und sehen Sie, ob das besser funktioniert. Sie müssen sich keine Sorgen machen, dass es unter Ihnen herausgedreht wird.

Gibt es ein Muster dafür? Bestimmte Zeitdauer? Bestimmte Tageszeit?

Angesichts der Tatsache, dass beide problematischen Protokolldateien von verschiedenen Komponenten derselben Anwendung geschrieben werden, frage ich mich, ob nicht ein Teil des Protokollierungscodes für diese Anwendung das Problem verursacht. Ich schlage zwei Tests vor, um eine bessere Vorstellung davon zu bekommen, was los ist:

• Notieren Sie sich den Inode der logfile ( ls -i logfile), bevor Sie den Schwanz starten. Wenn der Schwanz ausfällt, überprüfen Sie ihn erneut. Wenn sich der Inode geändert hat, schreibt der Logger die gesamte Protokolldatei neu, wodurch die Verbindung zum Tail unterbrochen wird.

• Beachten Sie die letzte Zeile, bevor der Schwanz nicht mehr funktioniert. Besuchen Sie dann die Datei und suchen Sie den ersten Protokolleintrag nach dieser Zeile. Tun Sie dies nach Möglichkeit 3-5 Mal. Wenn es ein Problem mit dem Programm gibt, das die Protokollierung durchführt, ist höchstwahrscheinlich der Teil des Programms verantwortlich, der den Protokolleintrag unmittelbar nach dem Auftreten von Tail Break geschrieben hat. Wenn dieser Protokolleintrag immer derselbe ist oder von derselben Programmkomponente stammt, verfügen Sie möglicherweise über genügend Daten, um einen Problembericht an den Anwendungsanbieter zu senden.

Viel Glück.

Das gleiche Problem hier haben.

Das Problem war, dass die Datei, die ich gerade beobachte, von einem anderen Computer gemountet wurde. Die Änderungsbenachrichtigung wurde nicht über das Mount weitergegeben.

Die Lösung bestand darin, den Schwanz auf der Originalmaschine zu verwenden.