Diskussion/Fragen: /var/log/ in eine Art RAMdisk auslagern & weitere Optimierungen

  • Hier bitte Fragen, Anregungen, Ergänzungen oder allgemeine Diskussionen bezüglich des Threads /var/log/ in eine Art RAMdisk auslagern & weitere Optimierungen bezgl. Logs behandeln damit es dort drüben übersichtlich bleibt!


    Vielen Dank für euer Verständnis!

  • Diskussion/Fragen: /var/log/ in eine Art RAMdisk auslagern & weitere Optimierungen? Schau mal ob du hier fündig wirst!

  • Hallo meigrafd,

    ein Script zur Verlagerung von /var/log in den RAM wollte ich mir schon seit einiger Zeit mal erstellen. Nun habe ich Deins gefunden und es hat sich noch eine Frage ergeben.

    Der stop - Bereich des varlog Scripts umfasst momentan die folgenden Zeilen:

    Code
    stop)
           echo "*** Stopping tmpfs file saving: varlog."
           #[ -n $varlogSave ] && rm -rf ${varlogSave}*
           #[ ! -d $varlogSave ] && mkdir -p $varlogSave
           cp -Rpu /var/log/* $varlogSave >/dev/null 2>&1
           sync
           umount -f /var/log/
       ;;

    Ich frage mich, ob es nicht von Vorteil wäre, den stop Bereich folgendermaßen abzuändern:

    Code
    stop)
           echo "*** Stopping tmpfs file saving: varlog."
           rsync -a --delete /var/log/ $varlogSave
           umount -f /var/log/
       ;;

    Warum?
    Das Verzeichnis $varlogSave würde dann nur Dateien enthalten, die /var/log/ zum Zeitpunkt der Scriptausführung beinhaltete.


    Um dies mit dem derzeitigen Script zu erreichen, müsste die auskommentierte Zeile aktiviert werden:

    Code
    [ -n $varlogSave ] && rm -rf ${varlogSave}*


    Allerdings wäre dies auch nicht ganz im Sinne des Erfinders, da dadurch möglicherweise unnötig viele Dateien gelöscht werden (die die sich gar nicht geändert haben und die bei rsync auch nicht "angefasst" würden).

    Würdest Du mir zustimmen?

  • der "cp -Rpu" Befehl kopiert nur Dateien die neuer sind => update. Vorhandene Dateien die nicht verändert wurden werden also nicht überschrieben.
    Jedes mal $varlogSave vollständig zu löschen belastet die SD unnötig, da löschen auch schreiben ist und das wiederum dem entgegenwirken würde wofür das Script aber eingesetzt wird.
    Insofern sehe ich kein Vorteil gegenüber deines "rsync" Vorschlags :huh:

    Der nachfolgende "sync" Befehl ist wichtig damit der Schreibbuffer vor dem aushängen beleert wird und somit nichts verloren geht.


  • der "cp -Rpu" Befehl kopiert nur Dateien die neuer sind => update. Vorhandene Dateien die nicht verändert wurden werden also nicht überschrieben.


    Ja und was passiert mit Dateien die sich in $varlogSave aber nicht (mehr) in /var/log/ befinden?


    Jedes mal $varlogSave vollständig zu löschen belastet die SD unnötig, da löschen auch schreiben ist und das wiederum dem entgegenwirken würde wofür das Script aber eingesetzt wird.


    Das sehe ich genau so. Allerdings erhält man allein mit "cp -Rpu " keinen identischen Inhalt von /var/log/ in $varlogSave.



    Insofern sehe ich kein Vorteil gegenüber deines "rsync" Vorschlags


    Mit "rsync -a --delete" erhalte ich den identischen Inhalt von /var/log/ in $varlogSave ohne vorheriges Löschen von $varlogSave.



    Der nachfolgende "sync" Befehl ist wichtig damit der Schreibbuffer vor dem aushängen beleert wird und somit nichts verloren geht.


    rsync beinhaltet bereits "sync", oder?


  • Der sync Befehl auf Kommandozeilenebene weist das OS an, alle Filebuffer-Daten (die evtl. noch im RAM gehalten werden) raus zu schreiben.


    Das ist mir bekannt.


    Das "sync" in rsync bezieht sich auf das Feature des Befehls...


    Also schließt rsync intern nicht mit einem sync bzw. der Anweisung an das OS ab, dass alle Filebuffer-Daten raus geschrieben werden?

    Ich hatte angenommen, dass das OS von rsync zum Schluss angewiesen wird, die Filebuffer-Daten raus zu schreiben. Andernfalls müsste man ja von einem unvollendeten rekursiven Synchronisationszustand nach Ausführung von rsync ausgehen. Kann man das an einer glaubwürdigen Stelle oder Seite nachlesen?

  • Ich gehe ebenfalls davon aus, dass rsync die Buffer leert, um es genau zu erfahren, wirst du dich wohl durch die Sourcen arbeiten müssen...

    Ein sync am Ende von File-Operationen mag oft überflüssig sein, schadet nicht, vermeidet Irritationen und bringt die CPU nicht an ihre Leistungsgrenzen...

    dd z.B. schreibt seine Buffer NICHT final raus, da ist ein sync sehr zu empfehlen... (vor allem, wenn dd als Target einen Massenspeicher hat, der kurz darauf entnommen wird (z.B. SD Karte beim Schreiben einer Images)).


  • Ein sync am Ende von File-Operationen mag oft überflüssig sein, schadet nicht, vermeidet Irritationen und bringt die CPU nicht an ihre Leistungsgrenzen...


    Stimmt, ich werde das sync belassen und mir das Source-Code Studium sparen.

    Jetzt werde ich prüfen, warum der stop - Bereich des Orginal varlog-Scripts bei mir nicht funktioniert.


  • Jetzt werde ich prüfen, warum der stop - Bereich des Orginal varlog-Scripts bei mir nicht funktioniert.

    Habe die Prüfung nun mit folgendem Ergebnis abgeschlossen:
    Bei neueren Linuxsystemen mit Systemd (z.B. Jessie, Ubuntu 16.04) wird der Stop-Bereich des varlog Scripts zur Sicherung des Inhalts der RamDisk /var/log nicht ausgeführt. Praktisch hat man also keine Sicherung des letzten Inhalts von /var/log nach einem normalen Herunterfahren. :(


    Dies lässt sich auch leicht nachprüfen. Einfach mal den Inhalt von save.log kopieren (z.B. nach save.log.2). Dann das System runterfahren. Wenn varlog ordnungsgemäß funktionieren würde, dann müsste save.log mit dem Inhalt von /var/log aktualisiert worden sein. Praktisch wird man aber nach einem Neustart feststellen, dass save.log nicht aktualisiert wurde (z.B. mit "diff -rq save.log save.log.2")

    Was ist zu tun, damit varlog mit Systemd funktioniert?
    Geholfen hat bei mir das Einfügen einer Zeile in den Unit-Abschnitt von /etc/systemd/system/varlog.service:

    Code
    Conflicts=umount.target


    Die korrigierte Service-Datei sieht bei mir nun so aus:

    Den Wert von WantedBy habe ich ebenfalls geändert, von local-fs.target zu multi-user.target. Für die Funktion von varlog hatte dies keine Relevanz. Jedoch hatte ich nach dem Lesen mehrerer Dokumentationsseiten und Konfigurationsbeispiele den Eindruck, dass an dieser Stelle eine Art SysVinit Runlevel angegeben werden sollte. Da local-fs.target keinem Runlevel entspricht, habe ich es entfernt.

  • Code
    Conflicts=umount.target


    Das funktioniert so nicht bzw. wird zu einem Glücksspiel, wobei immer die Gefahr besteht, dass Du das Boot-Journal zerschiesst. Der Mount muss unbedingt vor dem Flush des Journals erfolgen, damit das Schreiben bzw. die Übertragung des Bootlogs ordentlich vom tmpfs nach /var/log funktioniert.

    Zitat

    Habe die Prüfung nun mit folgendem Ergebnis abgeschlossen:
    Bei neueren Linuxsystemen mit Systemd (z.B. Jessie, Ubuntu 16.04) wird der Stop-Bereich des varlog Scripts zur Sicherung des Inhalts der RamDisk /var/log nicht ausgeführt. Praktisch hat man also keine Sicherung des letzten Inhalts von /var/log nach einem normalen Herunterfahren.

    Das is falsch. Die Ursache liegt an dem Statement "After=local-fs.target" in Deiner Unit. BTW, rsync funktioniert perfekt. Das sind z.B. die letzten Einträge beim letzten Shutdown meines PI's:

    Code
    journalctl -b -1
    Feb 26 22:50:07 raspi2 systemd[1]: Reached target Unmount All Filesystems.
    Feb 26 22:50:07 raspi2 systemd[1]: Stopping Local File Systems (Pre).
    Feb 26 22:50:07 raspi2 systemd[1]: Stopped target Local File Systems (Pre).
    Feb 26 22:50:07 raspi2 systemd[1]: Stopping Create Static Device Nodes in /dev...
    Feb 26 22:50:07 raspi2 systemd[1]: Stopped Create Static Device Nodes in /dev.
    Feb 26 22:50:07 raspi2 systemd[1]: Stopping Remount Root and Kernel File Systems...
    Feb 26 22:50:07 raspi2 systemd[1]: Stopped Remount Root and Kernel File Systems.
    lines 995-1038/1038 (END)

    Einmal editiert, zuletzt von WinterUnit16246 (26. Februar 2017 um 22:54)


  • Das funktioniert so nicht bzw. wird zu einem Glücksspiel, wobei immer die Gefahr besteht, dass Du das Boot-Journal zerschiesst. Der Mount muss unbedingt vor dem Flush des Journals erfolgen, damit das Schreiben bzw. die Übertragung des Bootlogs ordentlich vom tmpfs nach /var/log funktioniert.


    Du meinst der Start-Bereich des Orginal - varlog Scripts von meigrafd funktioniert so nicht?

    Dazu habe ich mich bisher gar nicht geäußert. Ich habe mit meiner Änderung erreicht, dass der Stop-Bereich des varlog Scripts ausgeführt wird und nun richtig funktioniert. Wenn Du nun behauptest, dass der Start-Bereich nicht funktioniert, dann ist das was anderes und der Verfasser meigrafd eher Ansprechpartner.

    Den Start-Bereich habe ich auch geprüft (wenn auch noch nicht so gründlich), aber bisher scheint er bei mir ebenfalls gut zu funktionieren.

    Das is falsch. Die Ursache liegt an dem Statement "After=local-fs.target" in Deiner Unit.


    Was ich schrieb, stimmt sehr wohl. Du und alle Anderen können es leicht unter Jessie und Linux Mint 18 == Ubuntu 16.04 nachvollziehen (siehe oben). Das Tutorial von meigrafd mit der Datei varlog.service ohne die Zeile "Conflicts=umount.target" führt dazu, dass der Stop-Bereich von /etc/init.d/varlog nicht ausgeführt wird.

    Wenn bei Deinem System Start + Stop funktioniert, ist es gut. Allerdings wäre es auch gut, wenn Du noch ergänzen würdest, dass Du mit einem modifizierten System arbeitest. Du hast rsyslog entfernt und systemd-journald persistent eingerichtet. Es ist ja durchaus vorstellbar, dass dadurch früher Schreibvorgänge in /var/log/ stattfinden. Da rsyslog laut svg-Plot erst nach basic.target gestartet wird, bin ich momentan bezüglich der richtigen Funktion des Start-Bereichs vom varlog-Scripts auch sehr entspannt.

    Ich nutze ein Standardsystem ohne derartige Modifikationen und zumindest zum Stop-Bereich des varlog-Scripts kann ich sagen, dass dieser jetzt einwandfrei ausgeführt wird.


    BTW, rsync funktioniert perfekt.


    Danke, also hast Du die cp-Befehle in deinem varlog bereits durch rsync ersetzt?

    Die Ergebnisse der genauen Prüfung des Start-Bereiches liefere ich gern noch nach.

  • Du meinst der Start-Bereich des Orginal - varlog Scripts von meigrafd funktioniert so nicht?


    Nein, meine ich nicht. meigrafd's Script ist tadellos in Ordnung und macht was es soll.

    Was ich schrieb, stimmt sehr wohl. Du und alle Anderen können es leicht unter Jessie und Linux Mint 18 == Ubuntu 16.04 nachvollziehen (siehe oben).


    Richtig, dieses angeblich 'fehlerhafte' Verhalten ist leicht reproduzierbar.... aber die Ursache ist nicht Meigrafd's Script, sondern -ich wiederhole mich- Deine Service-Unit.

    Zitat

    Wenn bei Deinem System Start + Stop funktioniert, ist es gut. Allerdings wäre es auch gut, wenn Du noch ergänzen würdest, dass Du mit einem modifizierten System arbeitest. Du hast rsyslog entfernt und systemd-journald persistent eingerichtet. Es ist ja durchaus vorstellbar, dass dadurch früher Schreibvorgänge in /var/log/ stattfinden. Da rsyslog laut svg-Plot erst nach basic.target gestartet wird, bin ich momentan bezüglich der richtigen Funktion des Start-Bereichs vom varlog-Scripts auch sehr entspannt.


    Nein, ich arbeite auch nicht mit einem modifizierten System, sondern mit Standard-Systemd. Diese Standard-Systemd beinhaltet als primären Logger systemd-journald. Ich habe lediglich eingestellt, dass ich die Logs persistent haben will. rsyslog hat definitiv mit Deinem Problem überhaupt nichts zu tun, weil rsyslog ein Zombie ist, ein zahnloser Tiger ohne besonders notwendige Verwendung. rsyslog ist unter Jessie KEIN eigenständiger Logger mehr, sondern kriegt nur das von systemd-journald vorgekaute Zeugs... quasi als völlig überflüssige redundante Doppelspeicherung. Kann man lassen, muss man aber nicht, ist aber trotzdem überflüssig. Aber wie gesagt, mit Deinem Problem hat das nix zu tun, weil Journald die maßgebliche Instanz ist. Und nur darauf muss es ausgerichet sein. Und wie ich schon sagte, die Ursache sind falsche Statements in der Unit-Sektion.

    Und mal ganz nebenbeibemerkt, unter systemd gibt es keinen isolierten Start- und Stoppbereich, denm man getrennt voneinander customizen kann. Eine für den Start notwendige Einstellung hat zwingend eine Auswirkung auf den Shutdown... und zwar insofern, dass die Reihenfolge beim Shutdown und beim Stoppen von Services in exakt umgekehrter Reihenfolge zum Start abläuft. Lediglich mit "conflict" kann darauf Einfluss genommen werden, weil mit dem Anziehen einer Unit zwingend die andere geschlossen wird... und das vice versa...

    Also ... wie ich sagte, Deine Einstellungen in der Unit-Section sind falsch. Wenns für die Bootphase korrekt eingestellt ist, läufts auch automatisch korrekt beim Shutdown. Getrennt einzustellen ist das nicht.

    Einmal editiert, zuletzt von WinterUnit16246 (27. Februar 2017 um 18:19)

  • Ich hab das Script in der Anleitung etwas modifiziert und auf die mittlerweile als besser herausgefundene "rync" Sache erweitert => http://codepad.org/BhbkCcFs

    Das hätte zur Folge das nicht der Inhalt der Dateien kopiert wird sondern wirklich nur " mode,ownership,timestamps " also die Dateiattribute. Es würde dann jeweils nur eine Leere Datei mit den Dateiattributen erstellt und somit weitaus weniger RAM belegt werden.
    Inwiefern es sich dann beim "stop" verhält kann ich gerade nicht feststellen da ich unterwegs bin - evtl. habe ich hier auch einen Denkfehler? :s

  • Hallo
    Mein Start zu dem Thema erfolgte mit dem Beitrag#59 von ThomasL
    Das Problem bei reboot oder halt läuft der rsync Schalter --delete ins Leere.
    Das sieht dann so aus nach einigen reboot ist /var/log/ voll. Wo ist mein Fehler.

    Code
    ls -la /var/log/journal/8c5604e85c924195aef34a3e4079998d/
    -rw-r----- 1 root systemd-journal 8388608 Mai  5 20:45 system@00054ecb4a3785b9-6ec412cc2b86581b.journal~
    -rw-r----- 1 root systemd-journal 4194304 Mai  5 20:56 system@00054ecb74072424-285188f29f35fc74.journal~
    -rw-r----- 1 root systemd-journal 4194304 Mai  5 21:00 system.journal
    #
    ls -la /var/log_save/journal/8c5604e85c924195aef34a3e4079998d/
    -rw-r----- 1 root systemd-journal 8388608 Mai  5 20:45 system@00054ecb4a3785b9-6ec412cc2b86581b.journal~
    -rw-r----- 1 root systemd-journal 4194304 Mai  5 20:56 system.journal

    Auf dem RasPi läuft jessi in Version. Der rsyslog wurde entfernt.

    Code
    Linux bastel_pi 4.4.50+ #970 Mon Feb 20 19:12:50 GMT 2017 armv6l GNU/Linux
    
    
    sudo apt-get purge --remove rsyslog

    Die Unit wurde nicht verändert.

    Das script varlog wurde angepasst.

    In der journal.conf steht bei mir

    Code
    #Storage=persistent
    SystemMaxUse=50M
    SystemKeepFree=5M
    SystemMaxFileSize=4M
    ForwardToSyslog=no
  • Hallo Zentris

    Nach jedem reboot oder halt gibt es in /var/log/ und in /var/log_save eine weitere xxx.journal~ Datei
    es ist nur eine Frage der Zeit bis /var/log/ dann voll ist.

    Wenn ich die Beschreibung von ThomasL richtig verstanden habe wird das journal
    beim booten nach /var/run geschrieben und erst wenn /var/log als tmpfs gemounted ist nach /var/log/ verschoben.
    In diesem Moment gibt es ein /var/log/journal/xx../system .journal
    Wenn jetzt der Start Zweig vom script varlog versucht das in /var/log_save/journal/xx../ stehende system .journal
    nach /var/log/journal/xx../ zu schreiben entsteht eben das Problem der .journal~ (Sicherungs) Dateien.


  • Nach jedem reboot oder halt gibt es in /var/log/ und in /var/log_save eine weitere xxx.journal~ Datei
    es ist nur eine Frage der Zeit bis /var/log/ dann voll ist.

    Nun, ich bezog mich auf das vollaufen... der Journal-Daemon _sollte_ beginnen, ältere Logfiles zu löschen, wenn das eingestellte Limit (bei dir 50MB) erreicht ist... insofern läuft da nix voll...

    Ich habe hier ein Linux (Ubuntu 14.04) seit ca. 1 Jahr laufen mit Systemd (Laptop) und an den Default-Einstellungen nichts geändert... da läuft kein Log voll... zusammen mit logrotate werden auch die "alten" SystemV-Logs sauber aufgeräumt...


    Wenn ich die Beschreibung von ThomasL richtig verstanden habe wird das journal
    beim booten nach /var/run geschrieben und erst wenn /var/log als tmpfs gemounted ist nach /var/log/ verschoben.
    In diesem Moment gibt es ein /var/log/journal/xx../system .journal
    Wenn jetzt der Start Zweig vom script varlog versucht das in /var/log_save/journal/xx../ stehende system .journal
    nach /var/log/journal/xx../ zu schreiben entsteht eben das Problem der .journal~ (Sicherungs) Dateien.

    Das Problem ist vielleicht (ich bin nicht sicher (!) ) mit einem gut eingestellten logrotate abfangbar:
    Dass ältere Logs in diesem _save-Verzeichnis (diese Sicherungsdateien) dann nach x Tagen gelöscht werden... x > 7-14 Tage.
    Damit würden dann diese Files, welche evtl. durch den Journaldaemon nicht behandelt werden, nicht übermäßig anwachsen...

    Wäre so mein erster Ansatz...

  • Hallo Zentris

    Das logrotate kann das Problem sicher entschärfen ist aber auch nicht einfach zu konfigurieren.
    Auf meinem Pc zb. läuft Arch und es gibt einen logrotate.service sowie den logrotate.timer
    für das Journal ist kein service zuständig die Journal Dateien belegen gut 450 MB in /var/log
    Das ist auch nicht optimal eingestellt.


    In Jessi gibt es keinen logrotate.service bzw. .timer das müste alles gebaut und sinnvoll konfiguriert werden.

  • [font="Courier New"]logrotate[/font] ist eigentlich recht einfach zu konfigurieren, es gibt auch 'ne Menge (guter) Beschreibungen (ist schon recht lange Bestandteil von Linux...) und natürlich eine man-page :)

    Jessi bringt logrotate (natürlich) mit... und es wird dort auch verwendet... allerdings nicht als Service im Sinne von Systemd (Nein, es gibt da wirklich keinen logrotate.service).
    Ich selbst kenne Arch jetzt nicht...

    Logrotate wird periodisch über cron.daily ([font="Courier New"]/etc/cron.daily/logrotate[/font]) gestartet, findet seine Konfigurationsfiles unter[font="Courier New"] /etc/logrotate.conf[/font] und arbeitet die ab (auf größeren Systemen könne da auch mehrere Konfigurationsfiles per include eingehängt sein...

  • Hallo Zentris

    Danke für den Tipp mit logrotate :danke_ATDE:
    Ich werde versuchen etwas tiefer einzusteigen und bei einem Ergebnis hier wieder melden.


    Nur ein Bauchgefühl das ganze Problem könnte mit der varlog.service Unit zu tun haben.
    Auch diese Abfragen sind nicht OK

    Code
    journalctl --verify -D /var/log_save/journal/8c5604e85c924195aef34a3e4079998d/
    PASS: /var/log_save/journal/8c5604e85c924195aef34a3e4079998d//system@00054eb7af61b5d7-112262f92082465f.journal~
    PASS: /var/log_save/journal/8c5604e85c924195aef34a3e4079998d//system.journal
    Data object references invalid entry at 299312███████████████████████████████████████████████████████████████████████████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  75%
    File corruption detected at /var/log_save/journal/8c5604e85c924195aef34a3e4079998d//system@00054eb7c9f4b8eb-a9491762b84614a8.journal~:000000 (of 8388608 bytes, 0%).
    FAIL: /var/log_save/journal/8c5604e85c924195aef34a3e4079998d//system@00054eb7c9f4b8eb-a9491762b84614a8.journal~ (Ungültige Nachricht)

    Bei dieser Abfrage stört mich die Meldung "Failed unmounting /var/log."

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!