Lösung 1:
Ah, dafür gibt es eine Flagge.
statt tail -f /var/log/file zu verwenden wir sollten tail -F /var/log/file verwenden
tail -F übersetzt zu tail --follow=name --retry wie in;
--follow=name:Folgen Sie dem Namen der Datei anstelle des Dateideskriptors--retry:Wenn auf die Datei nicht zugegriffen werden kann, versuchen Sie es später erneut, anstatt zu sterben
Lösung 2:
# tail --follow=mylog.log
Von Mannschwanz :
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.
Also in diesem Fall mit dem -F Option wäre richtig.
-F same as --follow=name --retry
Lösung 3:
Die genaue Antwort hängt von Ihrem Betriebssystem ab - aber in vielen Fällen tail -F wird das Richtige tun.
Lösung 4:
tail -Für tail --follow=name
Lösung 5:
IMHO ist es etwas seltsam, Ihre Protokolldatei nach GRÖSSE und nicht nach Datum zu ändern. Die meisten Systemprotokolle (in Unix oder Linux) rotieren auf wöchentlicher oder monatlicher Basis und nicht basierend auf der Größe ... Das ist etwas, das ich aus verschiedenen Gründen mag, und auch etwas, das, wenn es implementiert wird, Ihr Problem lösen würde.
Acht Jahre später weiß ich nicht, wovon zum Teufel ich hier gesprochen habe:Es gibt unzählige Orte, an denen Sie nach Größe rotieren möchten, da tägliche/wöchentliche/monatliche Rotationen MASSIVE Dateien hervorbringen können, die ernsthafte Probleme verursachen können. P>
Aus einer erfahreneren Perspektive ist die eigentliche Frage, warum Sie sich hinsetzen und eine Datei kontinuierlich verfolgen möchten, die so schnell wächst, dass Sie sie mehr als täglich drehen müssen ... Es wäre, als würden Sie den Matrix-Stream vorbeischauen.
Heutzutage sollten Sie sich besser mit einer großen Datenprotokollaggregation wie Splunk oder Sumologic befassen, bei der Protokollereignisse in Klassen gefiltert und basierend auf bestimmten Protokollwerten ausgelöst werden können ... Sie müssen überhaupt keine Live-Protokolle ansehen.