Lösung 1:
Dies liegt wahrscheinlich daran, dass, obwohl Sie die Datei abschneiden, der Prozess, der in die Datei schreibt, mit dem Schreiben an dem Offset fortfährt, an dem er zuletzt war. Was also passiert, ist, dass logrotate die Datei abschneidet, die Größe Null ist, der Prozess erneut in die Datei schreibt und an dem Offset fortfährt, an dem er aufgehört hat, und Sie haben jetzt eine Datei mit NULL-Bytes bis zu dem Punkt, an dem Sie sie abgeschnitten haben, plus dem neuen ins Log geschriebene Einträge.
od -c nach truncate + plötzliches Wachstum, erzeugte Ausgabe nach dem Muster von:
0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
33255657600 \0 C K B - s e r v e r [ h t t
33255657620 <more log output>
Was dies sagt, ist von Offset 0 bis 33255657600, dass Ihre Datei aus Nullbytes und dann einigen lesbaren Daten besteht. Das Erreichen dieses Zustands dauert nicht so lange, wie es dauern würde, all diese Nullbytes tatsächlich zu schreiben. Die ext{2,3,4}-Dateisysteme unterstützen so genannte Sparse-Dateien. Wenn Sie also nach einem Bereich einer Datei suchen, der nichts enthält, wird davon ausgegangen, dass dieser Bereich Null-Bytes enthält und keinen Speicherplatz beansprucht auf Festplatte. Diese Nullbytes werden nicht wirklich geschrieben, sondern nur angenommen, dass sie dort sind, daher dauert es nicht lange, bis 0 auf 3,5 GB geht. (Sie können die benötigte Zeit testen, indem Sie so etwas wie dd if=${HOME}/.bashrc of=largefile.bin seek=3432343264 bs=1 tun , dies sollte in wenigen Millisekunden eine Datei von über 3 GB erzeugen).
Wenn Sie ls -ls ausführen in Ihren Logdateien, nachdem sie abgeschnitten wurden und wieder plötzlich angewachsen sind, sollte jetzt eine Zahl am Anfang der Zeile angezeigt werden, die die tatsächliche Größe (in auf der Festplatte belegten Blöcken) darstellt, die wahrscheinlich um Größenordnungen kleiner ist als die Größe von nur ls -l gemeldet .
Lösung 2:
Ich bin extrem zuversichtlich, dass Kjetil es getroffen hat. Drew, Sie sind vielleicht noch nicht von seiner Erklärung überzeugt, aber ich fordere Sie auf, sorgfältig zu lesen, was er sagt.
Wenn Sie es akzeptieren, besteht die Lösung entweder darin, Ihre Anwendung zu stoppen und neu zu starten, wenn die Protokolle rotiert werden, oder Sie verwenden ein Tool wie "rotatelogs" von Apache, bei dem Sie die Protokollausgabe über eine Pipe an das Tool senden und das Tool sich darum kümmert die Logdatei von Zeit zu Zeit rotieren. Zum Beispiel meldet sich eine meiner Apache-Instanzen mit
ErrorLog "|/usr/sbin/rotatelogs /www/logs/error_log 604800"
was viele Logfiles mit Namen wie
verursacht-rw-r--r-- 1 root root 4078 Dec 21 01:04 error_log.1292457600
-rw-r--r-- 1 root root 4472 Dec 29 08:41 error_log.1293062400
-rw-r--r-- 1 root root 78630 Jan 4 12:57 error_log.1293667200
-rw-r--r-- 1 root root 15753 Jan 12 01:10 error_log.1294272000
erscheinen, ohne Apache neu zu starten; Ich kann sie dann nachträglich manuell komprimieren. Beachten Sie, dass die Rotation jede Woche durchgeführt wird, also alle 604800 Sekunden, wobei dies das Argument ist, das an rotatelogs übergeben wird .
Wenn Sie die App nicht stoppen und neu starten können und sie sich nicht über eine Pipe anmelden kann, haben Sie meiner Meinung nach ein echtes Problem. Vielleicht haben andere Vorschläge.