web-dev-qa-db-ja.com

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

私は最近時々tail -f <logfile>は画面への更新を停止します。

やっている Ctrl>-C ただし、tailの再起動は問題なく動作します。そして、ログファイルが途中でローテーションされていないことを確認しました(これにより、tailが気を失う可能性があります)。

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

10
warren

テールコマンドがある場合は、straceでラップしてみてください。

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回押して、少し縦のスペースを作り、それがテーリングを停止するのを待ちます。うまくいけば、出力にいくつかの手掛かりがあるでしょう。

6
davey

使ってみてください:

tail --follow=name <logfile>

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


停止するパターンはありますか?時間の長さは?一日の特定の時間?

9
MikeyB

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

  • ログファイルのiノード(ls -i logfile)テールを開始する前に、テールが失敗したら、再度チェックします。 iノードが変更されている場合、ロガーはログファイル全体を書き換えているため、末尾の接続が切断されます。

  • Tailが機能しなくなる前の最後の行に注意して、ファイルにアクセスし、その行の後の最初のログエントリを見つけます。可能であれば、これを3〜5回繰り返します。ロギングを行うプログラムに問題がある場合は、テールブレークが表示された直後にログエントリを書き込んだプログラムの部分が原因である可能性が高いです。そのログエントリが常に同じである場合、またはプログラムの同じコンポーネントからのものである場合は、アプリケーションベンダーに問題レポートを送信するのに十分なデータがある可能性があります。

幸運を。

4
daveadams

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

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

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

3
Stephan Hoyer