解決策 1:
ああ、これにはフラグがあります。
tail -f /var/log/file を使用する代わりに tail -F /var/log/file を使用する必要があります
tail -F tail --follow=name --retry に変換されます のように;
--follow=name:ファイル記述子の代わりにファイル名に従います--retry:ファイルにアクセスできない場合は、死ぬ代わりに後で再試行してください
解決策 2:
# tail --follow=mylog.log
マンテールより :
With --follow (-f), tail defaults to following the file descriptor,
which means that even if a tail’ed file is renamed, tail will continue
to track its end. This default behavior is not desirable when you
really want to track the actual name of the file, not the file descrip‐
tor (e.g., log rotation). Use --follow=name in that case. That causes
tail to track the named file by reopening it periodically to see if it
has been removed and recreated by some other program.
したがって、この場合は -F を使用します オプションは正しいでしょう。
-F same as --follow=name --retry
解決策 3:
正確な答えは OS によって異なりますが、多くの場合、tail -F です。 正しいことをします。
解決策 4:
tail -テールの場合 --follow=name
解決策 5:
私見ですが、ログ ファイルを日付ではなくサイズで変更するのは少し奇妙です。ほとんどのシステム ログ (UNIX または Linux) は、サイズに基づくのではなく、週単位または月単位でローテーションします...これは、さまざまな理由で私が気に入っているものであり、実装すれば問題が解決するものでもあります。
8 年後、私はここで一体何を話しているのかわかりません。サイズでローテーションしたい場所がたくさんあります。なぜなら、毎日、毎週、毎月のローテーションでは大量のファイルが生成され、深刻な問題を引き起こす可能性があるからです.
より経験豊富な観点から言えば、本当の問題は、なぜあなたが座って継続的にファイルを追跡したいのかということです。これは、毎日よりも頻繁にローテーションしているほど急速に成長しているファイルです...それは、マトリックスのストリームを見ているようなものです.
最近では、Splunk や Sumologic などのビッグ データ ログ アグリゲーションを調べた方がよいでしょう。そこでは、ログ イベントをクラスにフィルター処理し、特定のログ値に基づいてトリガーできます。ライブ ログを監視する必要はまったくありません。