Access.log läuft voll

    Hallo!


    Ich hatte jetzt bereits mehrmals, dass auf verschiedenen Servern die access.log im Kundenverzeichnis den Serverspeicher bis auf 0% volllaufen lassen.
    Gab oder gibt es einen Problem mit dem LOGGING ??

    Zitat von kk

    In der aktuellen v2.6.0 kann es ein Problem geben, wenn NGINX genutzt wird und die Logrotation zuschlägt. Wir arbeiten daran, Update kommt in den nächsten Stunden.


    aber ist ja eher unwahrscheinlich, dass seine Logs seit dem Release von v2.6.0 schon mehrfach vollliefen?

    Leider doch. Server haben nur 250 GB SSDs ... Access.log war jeweils immer 200 GB groß... 0% freier Speicher. Jeweils unterschiedliche Ubuntu Systeme mit NGIX als WebServer.

    Der Fehler ist auch wirklich äußerst ärgerlich. Um das vielleicht kurz zu erklären: lclogsplit wurde komplett neu entwickelt und arbeitet intern nun vollständig Event-basiert. Dabei erkennt lclogsplit auch, ob Log-Dateien rotiert wurden - und zwar dann wenn sich die inode-Nummer der betroffenen Log-Datei geändert hat oder die Logdatei zurückgesetzt (truncated) wurde. Genau hier gab es einen Fehler, der bei Logfile-Quellen (also nur bei NGINX) in manchen Fällen fälschlicherweise ein "Truncate" bei der Logdatei gemeldet hat - woraufhin diese komplett neu eingelesen und durchgeparsed wurde. Je nachdem wie groß wie Quell-Log-Datei war, führte das dann entsprechend zu viel Output. :(
    Wir planen nun die Testphase vor größeren Änderungen etwas umzustrukturieren, um so etwas früher erkennen zu können. (das NGINX-Log wird z.b. standardmäßig nur wöchentlich rotiert, und der Fehler kann frühestens ab der zweiten Rotation auftreten).

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden