`tail -f`で更新が停止することがあり、ファイルは移動していません

10

最近tail -f <logfile>、画面への更新が停止する場合があることに気付きました。

ただし、Ctrl>- Cを実行し、tail作業を再開すると問題ありません。そして、ログファイルが途中でローテーションされていないことを確認しました（tail気が散る可能性があります）。

何が原因でしょうか？RHEL 5.2 x64を実行しています。

logging rhel5 tail

— ウォーレン
ソース

これはすべてのログファイルで発生しますか、それとも特定のログファイルだけで発生しますか？ログファイルはどのファイルシステムにありますか？どのアプリケーションがログファイルを書き込んでいますか？（1）tailコマンドを開始してから一定期間が経過したかどうかを確認するために、失敗の時間を測定しましたか。または（2）一定の間隔で（たとえば、常に1時間の後に：00：10：20：30：40および：50に）？

— daveadams

@daveadams-私が気づいた限りでは、2つ（2つのサーバーのそれぞれに1つ）しかありません。この場合、HPSA Coreサーバー（データセンターオートメーション）のBSAE（レポートツール）のデータマイナーログファイルと報告ホスト上BSAEためのserver.log

— ウォーレン

1

余談ですが、ファイルが削除されて後で別のファイルに完全に置き換えられた場合でも、tail -Fは引き続き機能します。

— Sirex、2011

6

straceもしあれば、tailコマンドをラップしてみてください：

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

次に、クレイジーな再帰的キックの場合のみ、strace出力をテールすることができます（ファイルに移動するためにそれが壊れても問題ありません）。

 tail -f /tmp/tail.trace

鉱山は次のようになります。

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,

-tは時間をオンにし、-Tは呼び出しに費やされた時間をオンにします。

リターンを4〜5回押して、少し縦のスペースを作り、それがテーリングを停止するのを待ちます。うまくいけば、出力にいくつかの手掛かりがあるでしょう。

— デイビー
ソース

9

使ってみてください：

tail --follow=name <logfile>

そして、それがよりうまく機能するかどうかを確認してください。それがあなたの下から回転することを心配する必要はありません。

停止するパターンはありますか？ある程度の時間？一日の特定の時間？

— MikeyB
ソース

ファイルは下からローテーションアウトされていませんtail-定期的に（2〜20時間の間）停止しているだけです。追跡が停止します。もっとパターンがあったらいいのに：-\

— warren

キーボード上の他のキー（ctrl-c以外）を押すと、うまくいきますか？停止したら、strace / ltrace / etcを使用して接続を試みることができます。それが何かをしているかどうかを確認します。

— MikeyB

straceについて十分に検討してください。Enterキーも他のキーも、何も起こりません。私は時々screen、拡張デバッグのためにセッションでtail-fを実行したままにしておきたいのですが、これは気になる

— warren

1

ああ…おそらく問題ではないかもしれませんが、tail -fを実行して、誤って画面ウィンドウをコピーモードで開いたままにしないでください。コピーモードでは、コマンド出力ブロックが最終的に作成されます（バッファーがいっぱいになると）。

— MikeyB

すばらしい答えです。もちろん、ファイルは毎時上にローテーションされていました！

— アレックス、

4

問題のある両方のログファイルが同じアプリケーションの異なるコンポーネントによって書き込まれていることを考えると、問題を引き起こしているのは、そのアプリケーションのロギングコードの一部ではないのでしょうか。何が起こっているのかをよりよく理解するために、2つのテストを提案します。

ls -i logfileテールを開始する前にログファイルのiノード（）に注意してください。テールが失敗したら、再度チェックしてください。iノードが変更されている場合、ロガーはログファイル全体を書き換えているため、末尾の接続が切断されます。
tailが機能しなくなる前の最後の行に注意して、ファイルにアクセスし、その行の後の最初のログエントリを見つけます。可能であれば、これを3〜5回繰り返します。ロギングを行うプログラムに問題がある場合は、テールブレークが表示された直後にログエントリを書き込んだプログラムの部分が原因である可能性が高いです。そのログエントリが常に同じである場合、またはプログラムの同じコンポーネントからのものである場合は、アプリケーションベンダーに問題レポートを送信するのに十分なデータがある可能性があります。

幸運を。

— Daveadams
ソース

3

ここで同じ問題があります。

問題は、私が見ているファイルが別のマシンからマウントされたことでした。変更通知はマウントを介して伝播されませんでした。

解決策は、元のマシンでテールを使用することでした。

— ステファン・ホイヤー
ソース