/var/log/ in eine Art RAMdisk auslagern & weitere Optimierungen bezgl. Logs

  • Vielen Dank, das mit dem journaling ist eine ganz schöne Belastung der SD Karte. Anderweitig gibt es da keine Möglichkeiten um das ein bisschen ein zu dämmen? Eine Live Cd bzw. VM zu benutzen würde bedeuten das ich hier einen zusätzlichen USB Sick mit einbinden muss um von diesem das OS zu laden, oder? Oder meinst auf du auf die SD Karte eine VM schreiben?
    Aber die Idee mit dem SLC USB Sick wäre ja eigentlich des Rätsels Lösung, wenn ich die SD nur kurz zum Booten bzw. starten benötige und alles andere auslagere auf einen SLC USB Stick? Müsste doch Theoretisch gehen. Da muss ich mich aber erst mal richtig einlesen.
    Auch mit dem CRON gesteuertem rdate werde ich mir auf jedenfall anschauen.


    Das mit dem Blinken bzw. kurz Aufleuchten der grünen LED sieht so aus als würde jede Sekunde etwas darauf zugreifen, was es allerding laut IOTOP nicht macht, deswegen hatte ich vermutet ob das nur eine Bereitschaft der SD signalisiert.


    Dankeschön für deine Ausführliche Erklärung.


    Gruß Nea

    M.f.G.


    Andreas


    Über eine positive Bewertung oder ein Danke würde ich mich freuen.



    Begeistert vom DoorPi Projekt!

  • Vielen Dank, das mit dem journaling ist eine ganz schöne Belastung der SD Karte. Anderweitig gibt es da keine Möglichkeiten um das ein bisschen ein zu dämmen?


    Das einzige was mir dazu bekannt ist wäre > dies <. Dazu habe ich auch im ersten Beitrag unter Optimierungen was geschrieben (noatime).


    Eine Live Cd bzw. VM zu benutzen würde bedeuten das ich hier einen zusätzlichen USB Sick mit einbinden muss um von diesem das OS zu laden, oder? Oder meinst auf du auf die SD Karte eine VM schreiben?


    Du musst das halt auf jeden Fall von einem anderen Linux-Betriebssystem aus machen. Dafür gibt es mehrere Möglichkeiten:
    - Die SD im Raspberry stecken lassen und die cmdline.txt dahingehend verändern das von einem USB-Gerät gebootet wird. Siehe dazu > hier < oder > hier <
    - Ein Linux auf einem anderen Rechner. Dazu würde es reichen wenn auf einem PC eine LiveCD (Knoppix, Damn Small Linux, etc.) gebootet wird. Alternativ dazu kann man das auch in einer VM (VirtualBox, VMware, etc.) machen ohne den PC neuzustarten.


    Aber die Idee mit dem SLC USB Sick wäre ja eigentlich des Rätsels Lösung, wenn ich die SD nur kurz zum Booten bzw. starten benötige und alles andere auslagere auf einen SLC USB Stick?


    Ein USB-Stick basiert genau so wie eine SSD oder eben eine SD auf NAND-Flash und verträgt daher ebenso wenig Schreibzugriffe... Das würde also eigentlich nichts ändern.
    Ein USB-Gerät ist am PI auch nicht schneller da alles über nur einen USB 2.0 Kanal an die SoC angebunden ist - also auch hier kein Vorteil.


    Es gibt zwar keine SD Karten mit SLC Speicherzellen (wäre mir nicht bekannt) aber dafür gibt es sog. "Industrial SD"s die eine weitaus höhere Lebensdauer haben.
    Mir ist aber bisher noch keine SD Karte gestorben - ich installier aber auch nicht ständig neu und nutze die SD auch nicht als Datenhalde - sofern man sich also nicht derart veräußert besteht eigentlich kein Bedarf anderweitig aktiv zu werden ;)

  • Hallo meigrafd,


    weil mir mein SD-Kärtchen auch lieb und teuer ist, befasse ich mich jetzt mit Deinem Tut.


    Zuerst vielleicht eine Bemerkung zu RAMRUN und RAMLOCK, die anderen Verwirrten (so wie mir) helfen könnte: Die Einstellung RAMRUN gibt es nicht mehr. /var/run ist jetzt immer ein Link auf /run, und das ist jetzt immer tmpfs. Und RAMLOCK ist jetzt standardmässig auf yes (in /etc/default/tmpfs) und damit ist /var/lock ein tmpfs. Aber auch wenn es auf no stünde, wäre es immer noch auf einem tmpfs, nämlich auf dem von /run. (Siehe dazu man 5 tmpfs)
    Lange Rede kurzer Sinn: beide Einstellungen kann der SD-Karten-freundliche User jetzt ignorieren.


    So und jetzt zum varlog-Script: Wäre es nicht besser, das Verzeichnis /var/log einfach nach $varlogSave zu mounten, anstatt den Inhalt zu kopieren. Das würde der SD die Kopiererei von /var/log nach $varlogSave ersparen. (Bei Dir einmal pro Boot-Vorgang, bei allen, die den cron-Eintrag nutzen täglich einmal.)


    Und zum cron-Eintrag (und damit der täglichen Sicherung von tmpfs/var/log nach sd/$varlogSave): Du schreibst ja selbst, dass das kontraproduktiv wäre. Aber würde es die Belastung der SD nicht sogar erheblich steigern gegenüber dem kompletten Verzicht darauf /var/log auf ein tmpfs zu legen?
    Ein Beispiel: Nehmen wir mal an, in einer Logdatei würde täglich durchschnittlich 1KB dazu geschrieben.
    Dann wäre das eben jeden Tag 1 KB "Schreibbelastung" für die SD-Karte, wenn Dein varlog-Script nicht benutzt wird.


    Wenn man aber Dein varlog-Script verwendet (und auch in cron für eine tägliche Sicherung einträgt), dann wäre die Schreiblast für die SD am ersten Tag 1 KB, am zweiten 2 KB u.s.w., weil ja immer die ganze Log-Datei kopiert wird. Es wäre also viel schlimmer als ohne den ganzen Aufwand.


    Oder hab ich da irgendwo einen Denkfehler?


    Gruß,
    FeinerFug

  • Ich habe die Ramdisk nach diesem Tut ebenfalls im Einsatz.


    Beschäftige mich aber derzeit mit anderen Schreibbelastungen. Nämlich die von Sensoren.
    Auch diese schreiben ständig in eine Datei oder DB.
    Wenn ich aber ständig in DBs schreibe, werden diese ja immer größer.
    Befürchte hier mal Platzprobleme bei einer tmpfs.
    Denn diese laufen ja im RAM. Genau dieser ist auf den meisten Raspis beschränkt.


    Ich habe bei mir 3 rrd Datenbanken in Verwendung. Diese drei verbrauchen 250KB Platz.
    Wird ein wenig viel für eine RamDisk.


    Gruß
    Georg

    Gruß Georg


    ... und sie leben doch :cool:


    Raspberry Pi B+, Raspberry Pi2, Raspberry Pi3


  • Ich habe bei mir 3 rrd Datenbanken in Verwendung. Diese drei verbrauchen 250KB Platz.
    Wird ein wenig viel für eine RamDisk.


    Sollte es nicht eher MB statt KB lauten? ;)

  • Habe das mit rrd Datenbanken jetzt mal probiert.
    Datenbanken bekommen zwar Werte, jedoch ändert sich das Änderungsdatum und Zeit nicht. Somit werden diese rrd Dateien beim Runterfahren oder Neustart nicht gesichert.
    Nach einem Neustart sind wieder die alten Datenbanken, Max 1Tag alt da.
    Die aktuelleren Werte darin sind dann weg.


    Wenn diese Dateien sind in einem normalen Verzeichnis liegen, ändert sich aber sehr wohl bei jedem Update da Zeit und das Datum der Datei.
    Also ist RamDisk dafür unbrauchbar

    Gruß Georg


    ... und sie leben doch :cool:


    Raspberry Pi B+, Raspberry Pi2, Raspberry Pi3

  • Hi meigrafd,


    da ich mich auch gerade damit beschäftige eine Ramdisk für mein Roboter zu erstellen, da der viele Sensordaten permanent in Logs schreiben soll, bin ich auf dein Tutorial gestoßen. Ich habe versucht das Tut. mal auf dem Raspi 2 B mit Raspbian Jessie Lite in der aktuellsten Version von Februar 2016 einzuarbeiten.
    Jedoch gibt es bei dieser Zeile hier ein Problem.

    Code
    1. update-rc.d varlog start 01 2 3 4 5 . stop 99 0 1 6 .


    wenn ich den runlevel hinzufügen will dann bekomm ich eine Error meldung:
    siehe hier:

    Code
    1. pi@Raspobot:/etc $ sudo update-rc.d varlog start 01 2 3 4 5 . stop 99 0 1 6 .
    2. update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults


    Ich hatte es vorher unter wheezy mit dem alten raspi getestet da hatte es sauber funktioniert.


    vielleicht kannst du das eventuell für die neue Version des Raspbian mal anpassen, da ich an dem Punkt natürlich jetzt hänge da ich mich mit solchen Runlevels bisher nie beschäftigt habe und nicht weis wie ich den nun eintragen kann bzw. wie der auf dem neuen raspbian dann lauten sollte.



    vielen Dank


    MFG


    Zappelmann

  • Das liegt vermutlich daran dass Jessie primär auf systemd setzt und das alte sysVinit von Wheezy und zuvor erst später gestartet wird, für varlog dann wohl zu spät. Ein möglicher Fix hierfür wäre eben auf systemd umzusteigen.


    Hier betrete ich selber noch Neuland und weiß bei folgendem nicht ob das 100% funktioniert, es sieht aber ganz danach aus, zumindest mit MINIbian.


    [hr]


    varlog ab Jessie:


    Das Script /etc/init.d/varlog benötigen wir weiterhin. Wer es bisher mithilfe von update-rc.d in sysVinit eingetragen hat, muss es dort wieder austragen bzw deaktivieren:


    Code
    1. sudo update-rc.d varlog disable


    Nun müssen wir eine neue Service Datei für systemd erstellen:

    Code
    1. sudo nano /etc/systemd/system/varlog.service




    Und nun noch diesen Dienst einschalten:


    Code
    1. sudo systemctl enable varlog


    Nach einem Reboot kann man sich anzeigen lassen ob ein Dienst gestartet wurde:

    Code
    1. sudo systemctl status varlog


    Man kann auch einen Graphen erzeugen lassen, wie lange das booten gedauert hat aber vor allem wann welcher Dienst gestartet wurde:

    Code
    1. sudo systemd-analyze plot > irgendwas.svg

    diese *.svg kann man dann mit einem Webbrowser betrachten, entweder über einen Webserver auf dem Pi, oder die Datei auf den eigenen Computer übertragen und via Drag&Drop zB in Firefox betrachten.


    Bei mir wird varlog direkt nach "local-fs.target" ausgeführt, also genau so wie eingestellt :angel:

  • Hallo zusammen,


    ich hab eine Frage zur Auslagerung von var/log in den Ram, funktioniert unter Raspberry Pi 3 und Jessie das script von der 1 Seite noch?

  • So, hab es versucht und hab es leider abgeschossen, hab die Skripte wie auf der Seite 1 ausgeführt und hab den gleiche Fehlermeldung gehabt wie 'Zappelmann', ich hab dann trotzdem alles weitere nach der Anleitung zu Ende gemacht.


    Code
    1. update-rc.d varlog start 01 2 3 4 5 . stop 99 0 1 6 .


    wenn ich den runlevel hinzufügen will dann bekomm ich eine Error meldung:
    siehe hier:

    Code
    1. pi@Raspobot:/etc $ sudo update-rc.d varlog start 01 2 3 4 5 . stop 99 0 1 6 .
    2. update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults


    Danach hab ich es die Anweisung wie in Post 49 ausgeführt und das RPI neu gestartet.
    Leider ging dabei was schief und das RPI fährt nicht mehr hoch! Jetzt werde ich die SD Karte formatieren und neu einrichten... Es wäre super wenn jemand sagen könnte wie man bei Jessie genau vorgehen muss, also wie weit darf man in Post 1 gehen und ab wann kommt Post 49 zum Tragen.


    Gesendet von meinem GEM-703L mit Tapatalk

  • Welches RaspberryPi Modell man hat spielt keine Rolle. Das varlog Script funktioniert auch auf normalen Computern etc.


    Du machst einfach alles aus Beitrag#1 bis auf den Schritt bezüglich "update-rc.d". Anschließend arbeitest du Beitrag#49 ab.
    "update-rc.d" ist nämlich noch das alte sysVinit, was seit Jessie aber durch systemd abgelöst wurde. Das steht aber eigentlich auch in Beitrag#49 - also bitte nicht nur die Code Blöcke copy&pasten sondern auch den drum zu stehenden Text lesen


    [hr]


    Desweiteren wäre es toll wenn ihr für eure individuellen Probleme nicht in den Anleitungen selbst postet sondern einen eigenen Thread erstellt um dort euer Problem (ungestört ausführlicher) zu behandeln, denn sonst werden die Tutorial Threads dermaßen unübersichtlich das keiner mehr weiß was davon wichtig ist bzw keine Lust mehr alle seiten durch zu lesen - wir haben hier im Forum leider bereits einige Tutorials die über 20 Seiten gehen weil da jeder seine Problemchen abhandelt.


    Vielen Dank für euer Verständnis.

  • Ist lästig aber auch wieder naheliegend wenn man ein Tutorial durchgeht und ein Problem hat, dass man auch dort sein Problem dranhaengt.


    meigrafd : Was hälst Du davon


    1) Dass Du einen neuen Thread zu dem Tutorial aufmachst und ihn als ProblemschilderungsThread zu diesem Thread bezeichnest
    2) In dem Thread auf dieses Tutorial verlinkst
    3) Am Anfang zu diesem Tutorial auf den ProblemschilderungsThread verlinkst und jeden deutlich darauf hinweist


    Vielleicht hat das ja etwas Erfolg die Leute von weiteren Posts hier abzuhalten ;)

    "Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect." Linus Torvalds, 28.9.2003

    >>> raspiBackup: Sichere Deine Raspberry regelmäßig im laufenden Betrieb <<<

  • framp : Das hab ich mit vielen anderen meiner Tutorials hier auch schon so gehandhabt, die Erfahrung zeigt aber dass das leider trotzdem von einigen ignoriert wird.... Es gibt da auch einen Thread in dem ich zuletzt in jedem 2.Post das erwähnte aber es dann doch wieder ignoriert wurde :wallbash:
    Aber ja, kann ich morgen mal einrichten.

  • Wäre es denn erlaubt, hier sowas wie ein 'Upgrade' zu posten? Hier deshalb, weil mein Upgrade ohne jeden Zweifel auf diese Urversion zurückgeht und das Lob dafür natürlich hier dem TE gebührt. Mein Upgrade beinhaltet die Anpassung an Systemd, macht aber prinzipiell das gleiche, mit gleicher zugrunde liegenden Logik.

    Einmal editiert, zuletzt von ThomasL ()

  • Selbstverständlich


    Prima... Danke... na, dann will ich mal.....


    Zunächst ein paar erläuternde Fakten/Erklärungen:

    • Mein "Upgrade" hat prinzipiell die gleiche Funktion, wie das Original
    • Eine Änderung ergibt sich dadurch, dass ich die SD-Card ausser beim eher seltenen systemctl->Shutdown/Reboot NICHT mit Log-Daten beschreibe. Dieser Schreibvorgang ist allerdings für den Restore beim nächsten Boot zwingend erforderlich. Eine externes Storage funktioniert hier nicht, da der Restore zu einem Zeitpunkt stattfindet, zudem remote-fs.target noch nicht angezogen wurde und evtl. auch lokal zu verbindende Laufwerke (via fstab,mount-units,rc-local) noch nicht gemounted sind


    • systemd-journald läuft bei mir (mit der Einstellung "Storage=persistent") während der Boot-Phase in tmpfs->/run und wird zu gegebener Zeit (after local-fs.target) nach /var/log geflusht (siehe systemd-journal-flush.service).


    • Die Unit varlog.service ist VOR dem Flush aktiv. Das bedeutet, wenn geflusht wird, ist /var/log bereits erfolgreich nach tmpfs redirected/gemounted.


    • Die gewünschten (aber bisher von mir nie genutzten) Sicherheitskopien werden periodisch auf einem externen Speicher (USB-HD, USB-Stick, NAS) angelegt. Gegebenenfalls muss dazu im Script ein/der Pfad angepasst werden.
    • Ich verzichte im Script auf Plausibilitätsprüfungen, weil alles so gut wie statisch abläuft... variabilität oder mal-so-mal-so gibts hier nicht
    • Ich empfehle /tmp unbedingt ebenfalls nach tmpfs zu mounten (s.u.)
    • rsyslog ist unter Jessie ein Zombie und erzeugt heute keine eigenen Daten mehr. Systemd-journald ist das primäre Journaling-System und versorgt zusätzlich und auf Wunsch auch noch rsyslog. Damit wird explizit für rsyslog völlig überflüssiger redundanter Datenschrott angelegt. Deshalb empfehle ich rsyslog zu entfernen (s.u. und Hinweis beachten).
    • Ich empfehle VOR der Inbetriebnahme zuerst alles einmal bis unten zu lesen und sich einen Überblick über die notwendigen/gewünschten Schritte zu verschaffen. Diese Anleitung ist nicht in erforderlicher Reihenfolge aufgebaut, einzelne Parts können, müssen aber nicht..... also unbedingt Reihenfolge beachten!


    Die systemd-unit, um das Script im Bootprozess zu starten:

    Code
    1. nano /etc/systemd/system/varlog.service



    Das Bash-Script:

    Code
    1. nano /usr/local/bin/varlog



    Inbetriebnahme mit folgenden Schritten (die Reihenfolge unbedingt einhalten):


    Nach dem Reboot sollte der varlog-status fehlerfrei sein und /var/log in tmpfs laufen


    Eine Kontrolle des aktuellen/laufenden Boots zeigt, dass die Reihenfolge wie erwünscht passt:

    Code
    1. journalctl -b | grep "varlog\|journal" -i



    Der vorherige Boot wurde bis zum spätestmöglichen Zeitpunkt geloggt:

    Code
    1. journalctl -b -1



    Um rsyslog zu entfernen und system-journald (nach meinem Ermessen) sinnvoll einzustellen, ist folgendes zu tun:

    Code
    1. nano /etc/systemd/journald.conf


    Unten am Ende anfügen:

    Code
    1. Storage=persistent
    2. SystemMaxUse=20M
    3. ForwardToSyslog=no


    rsyslog entfernen und systemd-journald "persistent" einrichten. Achtung!!! Das muss VOR Inbetriebnahme des Scripts varlog erfolgen!!!

    Code
    1. mkdir -p /var/log/journal/tmp
    2. systemd-tmpfiles --create --prefix /var/log/journal
    3. adduser thomas systemd-journal
    4. systemctl restart systemd-journald
    5. apt-get purge --remove rsyslog


    Um eine periodische Sicherung auf einen externen Speicher zu ermöglichen, muss ein crontab-Eintrag erstellt werden. Ich habe hier 4 Beispiele von 1-4 Backups, bzw. 24 stündlich, alle 12 stunden, nach 8 stunden und nach 4 stündlich. Bei mir läuft 12-stündlich, was ich auch bei der enorm hohen Stabilität meines Jessie-Servers für absolut ausreichend und empfehlenswert erachte. Andere Belange können aber andere Zyklen erfordern.

    Code
    1. crontab -e


    Code
    1. 0 2 * * * /usr/local/bin/varlog sik
    2. 0 2,14 * * * /usr/local/bin/varlog sik
    3. 0 2,10,18 * * * /usr/local/bin/varlog sik
    4. 0 2,8,14,20 * * * /usr/local/bin/varlog sik


    Die Sicherungskopie gemäß meiner Namens- und Pfad-Vorgaben im Script kann auf dem externen Storage wie folgt geöffnet werden:

    Code
    1. journalctl -D /media/var/$HOSTNAME/log/journal


    Mein Logdir ist heute sehr überschaubar. Das früher von rsyslog angelegte Chaos ist vollständig beseitigt:


    Abschließend noch eine Mount-Unit, um /tmp ebenfalls nach tmpfs zu mounten:

    Code
    1. nano /etc/systemd/system/tmp.mount
    2. chown 644 /etc/systemd/system/tmp.mount
    3. chmod root:root /etc/systemd/system/tmp.mount



    Und noch aktivieren:

    Code
    1. cd /etc/systemd/system
    2. systemctl enable tmp.mount

    Einmal editiert, zuletzt von ThomasL ()

  • Eben hat sich meine raspi verabschiedet da /var/log voll war.
    Der Grund dafür ist

    Code
    1. /bin/cp -Rpu /var/log/* /var/log_save


    Ich hatte das schon mal weiter oben angemerkt, denn dadurch akkumulieren sich alle Logs in save, selbst wenn eigentlich logrotate aufgeräumt.

    Code
    1. /usr/bin/rsync -a --delete /var/log/ ${varlogSave}

    löst das Problem, denn damit werden die beiden Verzeichnisse gesynced und gelöschte Dateien/Verzeichnisse in save gelöscht.


    Voraussetzung ist aber das rsync installiert ist. Man könnte das Script noch intelligenter machen dass es rsync benutz wenn es existiert und ansonsten cp.


    Jedenfalls sollte am besten auch in den Code Beispielen oben von den BeitragsErstellern noch angepasst werden :shy:

    "Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect." Linus Torvalds, 28.9.2003

    >>> raspiBackup: Sichere Deine Raspberry regelmäßig im laufenden Betrieb <<<

    Einmal editiert, zuletzt von framp ()