Bash logrotate: soll immer nur die Hälfte einer Datei rotieren

[Tobias0]

Merkwürdige Frage, aber kann man irgendwie logrotate in /etc/logrotate.d/... sagen, er soll nur die Hälfte einer Datei rotieren?

Beispiel: Rotiere, wenn size=100M, aber behalte jeweils die neusten 50M.

Gehe außerdem Zeilenweise vor, also zerstöre keine intakten Zeilen.

Ist das möglich?

 

[nutrix]

Merkwürdige Frage, aber kann man irgendwie logrotate in /etc/logrotate.d/... sagen, er soll nur die Hälfte einer Datei rotieren?

Nein.

Beispiel: Rotiere, wenn size=100M, aber behalte jeweils die neusten 50M.

Nein, die Size gibt nur an, ab wann rotiert bzw. gepackt werden soll, wenn die Datei eine bestimmte Größe erreicht. Ist dann sinnvoll, wenn Logs sehr groß werden können, und Du sicherstellen mußt, daß der Platz nicht überläuft.

Gehe außerdem Zeilenweise vor, also zerstöre keine intakten Zeilen. Ist das möglich?

Nein.

Warum willst Du das so? Du kannst alle Dateien nach dem Packen archivieren, und Du kannst sie aus dem Archiv jederzeit wieder auspacken und hast sie vollständig vorliegen. Daher finde ich Dein Vorgehen hier recht sinnlos, weil mit Dein Kontext fehlt.

 

[Tobias0]

Warum willst Du das so? Du kannst alle Dateien nach dem Packen archivieren, und Du kannst sie aus dem Archiv jederzeit wieder auspacken und hast sie vollständig vorliegen. Daher finde ich Dein Vorgehen hier recht sinnlos, weil mit Dein Kontext fehlt.

Ich freue mich, dass du meine Frage beantwortet hast, aber der unfreundliche Unterton muss wirklich nicht sein ...

Die Anwendung, die log files liest, verlangt dies so.

Ergänzung (16. August 2025)

https://goaccess.io

 

[synack]

Dein genauer usecase ist mir unklar, evtl. hilft das hier:
https://andrewladlow.co.uk/2019/06/22/goaccess-with-rotating-compressed-web-logs/

Den unfreundlichen Unterton von nutrix habe ich nicht erkannt.

 

[Tobias0]

evtl. hilft das hier:

Nein, dann funktioniert real time nicht mehr.

Den unfreundlichen Unterton von nutrix habe ich nicht erkannt.

🤷‍♂️ Bin kein Richter, aber war von schon meldungswürdig der Ton.

 

[nutrix]

Ich freue mich, dass du meine Frage beantwortet hast, aber der unfreundliche Unterton muss wirklich nicht sein ...

Wo war ich bitte unfreundlich? Ich bin und war sachlich und nüchtern. Warum wollt Ihr immer noch umständliches Drumherumgerede mit Blümchen und Co., anstatt auf den Punkt zu kommen?

Und als IT-Ler mit über 35 Jahren Erfahrung, der u.a viel mit Massendaten und Logs zu tun hat, darf ich doch mal nachfragen, warum Du das so willst oder brauchst? 😉 Beruflich arbeite ich viel mit allen Tools wie Grafana, ELK, Splunk, Prometheus und anderen SIEM wie Logsammlerarten, daher kenne ich mich etwas damit aus und hatte mich nur etwas über Deine Anforderung gewundert, weil man das so nicht machen würde, was Du vorhast. Entweder, mal hält Logs vor, oder man recylet eben.

https://goaccess.io

Danke, kannte ich so nicht. Aber da Du hier nur aktuelle Daten verarbeitest, sollte das doch so passen, und Logrotate sollte nur bei sehr großen Dateien (ab 1-2 GB und Co.) eingreifen.

🤷‍♂️ Bin kein Richter, aber war von schon meldungswürdig der Ton.

Mach es doch, melde es. Vielleicht hast Du ja selbst ein Problem, wenn man Dein Tun in Frage stellt. Du darfst aber immer nicht vergessen, daß wir Helfenden alle keine Glaskugel habe, alle nicht in Deinen Kopf hineinschauen können, und jeden Tag mit Problemen und Anfragen geflutet werden. Einerseits, weil die Leute zu faul zum Googlen oder Dokulesen sind (damit meine ich jetzt nicht Dich, Du hattest mal eine wirklich gute Anfrage), und teilweise aus Nichtwissen wirklich sinnlose Anfragen kommen, die oftmals sich dann als XY-Problem darstellen, und die vorherigen Beratungen vollkommen umsonst waren, weil wir auf eine falsche Fährte geführt wurden. Das dies anstrengend und nervenaufreibend ist, kannst Du Dir bestimmt vorstellen.

Daher verzeih mir doch einfach, daß ich nüchtern und sachlich wie direkt bleibe, weil ich Effizienz wie schnelle Problemlösung einfach vorziehe. Ich bin jeden Tag mit ungelogen tausenden Problemen konfrontiert, beruflich wie Privat (für andere), und helfe hier noch mit meinem bescheidenen Wissen nebenbei aus. Nebenbei (!) habe ich mal alte HDDs gesucht und diese Anfrage beantwortet:
https://www.computerbase.de/forum/t...otting-auf-hdd-und-ssd.2249060/#post-30832993

Daher erzeuge bitte keinen Beef, wo keiner ist, oder? 😉 Wie gesagt, von meiner Seite bin ich gerade weder schlecht gelaunt noch Dir irgendwie negativ zugewandt, ich hatte ja geantwortet. Oder wäre Dir dann keine Antwort lieber gewesen?

So, jetzt erst mal ein Kaffee und Frühstück, sorry.

 

[simpsonsfan]

Den Use-Case will ich nicht beurteilen.

Aber die Funktionialität "benenne alte log-Datei um und starte neue log-Datei mit den letzen <50MB Zeilen der vorherigen Logdatei" sollte sich ja relativ schnell selbst implementieren lassen.
Vielleicht noch Sonderfälle abfangen, bspw. überlange Zeilen, also wenn bereits eine Zeile meinetwegen 70MB oder über die 100MB hat.
In zwei, drei Tagen sollte sich da schnell was zusammenbasteln lassen.

Ich hab übrigens auch keinen unfreundlichen Ton wahrgenommen. (Ein Vorgehen als sinnlos zu erachten ist eine Meinung, kein Angriff auf den Urheber des Vorgehens.)

 

[Tornhoof]

Gehe außerdem Zeilenweise vor, also zerstöre keine intakten Zeilen.

Das geht im Allgemeinen eh nicht und erfordert Unterstützung des Programms selber. Ein logischer Logeintrag ist nicht notwendigerweise nur eine Zeile.


Wenn goaccess außerhalb der Live-Analyse nutzen willst, dann ggf die Alternativen anschauen die die Daten vorhalten, sei es kibana und zugehörige Toolketten oder grafana und zugehörige Toolketten

 

[nutrix]

Das Problem ist aber, wie will man bitte sinnvoll Logdateien teilen bzw. abschneiden? Das geht nicht so einfach, besonders wenn Meldungen über mehrere Zeilen gehen. Da würde man Infos, Warnings wie Errors aus dem Zusammenhang reissen, und das wäre ja überhaupt nicht sinnvoll. Wenn man nur die letzte Zeile aus einer 50 Zeilen Meldung hat, kann das zu Rätselraten führen. Und Logs zerteilen ist überhaupt nicht trivial, da muß man viel über die Log-Erzeugenden Dateien wissen, und das würde ich ungern bei einem aufwendigen System mit den unterschiedliche Logarten machen wollen, das wäre sehr aufwendig.

 

[Tobias0]

und Logrotate sollte nur bei sehr großen Dateien (ab 1-2 GB und Co.) eingreifen

Na gut, vielleicht brauche ich logrotate auch gar nicht für diesen access.log. Bisher hatte ich bei 10M rotiert, aber das sind meist nur 7 Tage ... und wenn rotiert wird, fängt er wieder bei 0 an. Außerdem habe ich ca. 250 GB freien Speicherplatz.

 

[mae]

Aber die Funktionialität "benenne alte log-Datei um und starte neue log-Datei mit den letzen <50MB Zeilen der vorherigen Logdatei" sollte sich ja relativ schnell selbst implementieren lassen.

Schnell vielleicht, aber korrekt ist schwer. Waehrend Du die Zeilen aus dem alten log herauskopierst, will das loggende Programm vielleicht etwas loggen, und das kommt dann irgendwo mitten in Deine neue log-Datei. Alternativ koenntest Du noch versuchen, das Loggen waehrend dieser Zeit zu unterdruecken, aber das geht nicht immer bzw. hat unangenehme Konsequenzen.

 

[nutrix]

Na gut, vielleicht brauche ich logrotate auch gar nicht für diesen access.log. Bisher hatte ich bei 10M rotiert, aber das sind meist nur 7 Tage ... und wenn rotiert wird, fängt er wieder bei 0 an. Außerdem habe ich ca. 250 GB freien Speicherplatz.

Na komm, 10MB sind doch heute nichts mehr.

Außerdem habe ich ca. 250 GB freien Speicherplatz.

Dann kann ich erst recht nicht verstehen, warum Du Dir hier solche Gedanken darum machst. Bei den vielen VMs und Server, die nur mit 50-100 GB ausgestattet sind, da muß ich mir sicher ernsthaft überlegen, was bei Überlaufen von Logs passiert und entsprechend planen, besonders dann, wenn Du für Analysezwecke den Debuglevel hochschrauben mußt, und innnerhalb von Stunden mehrere Gigabyte geschrieben werden.

Von welchen Größen sprechen wir denn insgesamt unter /var/log und anderen Verzeichnissen, von wie vielen Anwendungen gleichzeitig, die überwacht werden sollen?
Wenn das bei 10MB bleibt, paßt das doch alles bei Dir, ich würde hier gar nichts groß weiter unternehmen. Ich bin heute bei mindestens 100MB bis 1GB, wo ich rotiere.

 

[kieleich]

logrotate zerteilt nicht sondern gibt der datei einen neuen namen, und bittet dann den server, die datei unter dem freigewordenen namen neu zu öffnen. einträge die "am stück" geloggt werden, sollten so nicht zerteilt werden. das passiert nur wenn das technisch intern eben doch separate logmeldungen sind

wenn du das über die stange brechen willst, könnte man so verfahren, das die neue logdatei leer angelegt wird mit einer bestimmten größe (z.B. 10M Nullen) und dann sobald der Log begonnen hat, diese 10M inplace/notrunc überschrieben werden mit den letzten 10M der umbenannten Logdatei.

die erste Zeile in dieser Datei wäre dann angefressen

beim rotieren müsste man diese duplizierten 10M dann immer raus schneiden

viel aufwand, für wenig nutzen. am ende einfacher ein programm zu schreiben das die logs rotationsübergreifend anzeigt. wie es systemd auch macht (gleich ein spezielles log format dafür)

 

[simpsonsfan]

Schnell vielleicht, aber korrekt ist schwer. Waehrend Du die Zeilen aus dem alten log herauskopierst, will das loggende Programm vielleicht etwas loggen

Definiere erst mal, was korrekt ist.
Die Kommentare haben ja bereits vollkommen recht damit, dass ein Log-Eintrag durchaus über mehrere Zeilen gehen kann. Daher ist das Kopieren von ganzen Zeilen womöglich eh schon nicht korrekt.

Aber stimmt schon, den Austausch der Dateien zur Laufzeit (was ja logrotate wohl macht) muss man dann wohl etwas vorischtiger angehen. Wenn man Ahnung vom verwendeten Dateisystem hätte, könnte man ja möglicherweise direkt Filepointer verschieben. Oder man müsste eben den Datenstrom vom log zwischenbuffern o.ä.
Letztlich würde es vermutlich irgendwie in zusätzlichen temporären Dateien münden, die man sich im Anschluss wieder passend zusammensetzt.

 

[mae]

Definiere erst mal, was korrekt ist.

Alles, was in das log geschrieben wurde, ist in einer der log-Dateien, und zwar genau einmal. Spaetere log-Eintraege sind in spaeteren Dateien als fruehere Eintraege, bzw. wenn zwei in der selben Datei sind, ist der aeltere vor dem juengeren.

Die Kommentare haben ja bereits vollkommen recht damit, dass ein Log-Eintrag durchaus über mehrere Zeilen gehen kann.

Selbst wenn man es erlaubt, dass zwischen Zeilen, oder sogar zwischen Zeichen geschnitten wird, ist Korrektheit im obigen Sinn problematisch.

Aber stimmt schon, den Austausch der Dateien zur Laufzeit (was ja logrotate wohl macht) muss man dann wohl etwas vorischtiger angehen. Wenn man Ahnung vom verwendeten Dateisystem hätte, könnte man ja möglicherweise direkt Filepointer verschieben. Oder man müsste eben den Datenstrom vom log zwischenbuffern o.ä.

Du denkst schon in die richtige Richtung. Das "direkt Filepointer verschieben" wird in Unix-Filesystemen mittels rename(2) gemacht, wobei die Atomizitaet dieser Operation garantiert ist. @kieleich hat ja schon beschrieben, wie das gemacht wird. Diese Methode funktioniert korrekt, je nach loggendem Programm wohl auch bezueglich der Grenzen zwischen Log-Eintraegen. Das kann man nicht leicht aendern, ohne eine Race condition einzufuehren und damit die Korrektheit zu verlieren.

 

[Tobias0]

Beispiel:

cat /etc/logrotate.d/traefik
/var/log/traefik/*.log {
  size 100M
  rotate 3
  missingok
  notifempty
  compress
  postrotate
    docker kill --signal="USR1" traefik
  endscript
}

Beispiel für einen Eintrag (sensible Informationen habe ich ersetzt):

tail -n 1 /var/log/traefik/access.log
xxx.xxx.xxx.xxx - - [16/Aug/2025:12:13:36 +0000] "GET /forschung.html?xxx HTTP/1.1" 404 19 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X xxx) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/xxx.xxx.xxx.xxx Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 140 "-" "-" 0ms

Ergänzung (16. August 2025)

Aber macht denn tail -n nicht so etwas Ähnliches schon?

 

[simpsonsfan]

@mae Post #13 war mir, als ich das vorher geschrieben hatte, sogar entgangen.
Die Anforderung, dass keine duplizierten Logdaten (in verschiedenen Dateien) vorhanden sein sollen, macht es dann nochmal schwieriger. Da erscheint die Aussage von @kieleich, die logfiles einfach rotationsübergreifend anzuzeigen, sinnvoll.

@Tobias0 tail -n gibt dir die letzten n Zeilen einer Textdatei zurück, und zwar zu dem Zeitpunkt, an dem du tail aufrufst. Wie das im Einzelnen tatsächlich implementiert ist, weiß ich nicht, ich vermute über eine temporäre Kopie.

Prinzipiell ist eine Textdatei einfach eine Folge von Bytes, und ein LineFeed-Zeichen beschreibt dann das Ende einer Zeile.
Um die Zeilen zu ermitteln, gehst du also grundlegend durch die komplette Datei und schaust, ob ein Byte ein LF darstellt.
Ich habe recht viel mit logfiles zu tun, die gerne mal hunderte MB groß werden und in die quasi durchgehend geschrieben wird (ich nehme an, die Tools verwenden dort BufferedWriter, sodass meinetwegen 2 mal pro Sekunde oder so ein tatsächlicher Schreibvorgang angestoßen wird.) Und dort ist dann natürlich die Ausgabe, wenn man händisch tail aufruft, beim nächsten Aufruf schon wieder anders.

Und wenn du gleichzeitig Daten von einem alten Logfile in ein neues kopieren und neue Logdaten in dieses File schreiben möchtest, kann das komplexer werden. Letztlich brauchst du immer irgendeinen Buffer.

Aber viel einfacher könnte es sein, statt der 100MB Files, die immer 50MB vom letzten Log am Anfang haben, sich lauter 50MB Files zu halten und die bei Bedarf gemeinsam auszuwerten.

 

[Tobias0]

@simpsonsfan Goaccess ist ziemlich "dumm" (bzw. naiv) und kann im real time mode nicht mit mehreren, rotierten log files umgehen - selbst, wenn diese vorher nicht komprimiert wurden.

Ergänzung (16. August 2025)

Edit:

cat goaccess.conf
tz Europe/Berlin
time-format %H:%M:%S
date-format %Y-%m-%d
log-format COMBINED
log-file /srv/logs/traefik/access.log
output /srv/report/index.html
real-time-html true
ws-url wss://url...
port 443

 

[simpsonsfan]

Goaccess [...] kann im real time mode nicht mit mehreren, rotierten log files umgehen

Und was, wenn du dir einfach ein tempfile zusammenbaust? Kopie des vorherigen Logs und dann einfach den Output aus dem akutellen zusätzlich laufend reinpipen?
So in der Art: tail -f current.log | tee temp.log

 

[nutrix]

@Tobias0
Dein genauer Anwendungszweck ist mir immer noch nicht klar. Willst Du alle Logs nur überwachen, oder was genau willst Du mit dem oben genannten Programm da tun? Wenn Du entsprechend analysieren willst, macht man das modern über ein SIEM oder sowas wie den ELK. Man packt alle Logs in eine Datenbank und dann entspannt seine Auswertungen fahren. Ansonsten interessieren die Logs doch nur in Problemfällen.