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

  • Angenommen das varlog Script läuft noch nicht und angenommen die Datei /var/log/syslog hat einen timestamp vom 3.Mai


    Wenn wir jetzt varlog starten wird die Datei /var/log/syslog nach /var/save.log/ kopiert und tmpfs für /var/log/ erzeugt bzw da drüber gemountet.
    Als würde man einen Eimer auf eine anderen halb vollen drauf stellen, dann tropft das Wasser in den oberen Eimer aber nicht mehr in den da drunter. Im unteren Eimer ist aber weiterhin das alte Wasser drin..


    Anschließend wird die Datei /var/save.log/syslog wieder in den neuen, leeren tmpfs Ordner /var/log/ kopiert.


    Nun wird in /var/log/syslog etwas rein geschrieben, somit wird der timestamp raufgesetzt.


    Irgendwann, sagen wir am 20.Mai, führen wir einen Reboot durch.


    Die Datei /var/log/syslog wird erneut nach /var/save.log/ kopiert, da die aktuelle Datei einen timestamp vom 20.Mai besitzt, diese also neuer ist als die /var/save.log/syslog vom 3.Mai


    Nun startet der Rechner neu.
    Der tmpfs Mount ist noch nicht vorhanden und /var/log/ beinhaltet Dateien vom 3.Mai auch die syslog Datei ist vom 3.Mai


    Das varlog Script kopiert nun nur die Dateien die neuer als von 20.Mai wären. Das trifft aber zu diesem Zeitpunkt auf keine der Dateien zu. (fast) Alle Dateien in /var/save.log/ sind vom 20.Mai wohingegen die Dateien in /var/log/ noch vom 3.Mai sind (das alte Wasser vom unteren Eimer)


    Und nun wird tmpfs erzeugt bzw über /var/log/ gelegt und die Dateien aus /var/save.log/ nach /var/log/ kopiert.... In /var/log/ sind nun Dateien vom 20.Mai, eben von dem Tag als rebootet wurde




    Ist es jetzt klar wie das abläuft :huh: :geek:

  • Jau, habe ich jetzt verstanden... :lol: ... mir war nur die Technik ein wenig suspekt.... ich hatte nen falschen Fokus auf den Copy. Mir war klar, dass er nix kopiert, aber mir war nicht klar, dass genau das beabsichtigt war. Meine Logik ist da irgendwie geradliniger.... *lacht*... zum Salto noch ne Schraube.... dafür bin ich zu alt. :s


    Ich habe mein Script für beide Pi's jetzt fertig und das gerade "oben" aktualisiert. Das Problem (meines Verstehens) wäre gelöst, wenn die letzten beiden Zeilen auch in meinem Stop-Code-Block nicht auskommentiert wären. Da liegt nämlich genau das Problem, warum die SDC-Logs nie wieder zurückaktualisiert werden. Denn diese beiden Kommandos funktioneren eben nicht. Allerdings denke ich auch, soooo wichtig ist das nicht. Bei mir liegt jetzt alles auf der Platte... und das reicht, um, bei Bedarf was zu recherchieren.


    Na ja... war auf jeden Fall für mich spannend..... :thumbs1:


    Gruss, Thomas

    Edited once, last by WinterUnit16246 ().

  • Ein kleines Problem gibt es durch das cp: Alte nicht mehr existierende Dateien in /var/log werden nicht dabei gelöscht. Hatte ich mit meigrafd schon diskutiert. Eine Lösung ist die Benutzung von rsync. Allerdings ist die Kanone da etwas zu gross für den Spatz :lol: cp reicht vollends.

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


    Hast Du die Woche schon Deine Raspberry gesichert :shy: Bei mir tut das automatisch raspiBackup ;)

  • Ich hoffe , Du hilfst mir noch einmal..... ich weiss nicht, wie ich das eintragen muss. Ich glaube, mein Script funktioniert gar nicht.....
    sudo update-rc.d varlog start 01 2 3 4 5 . stop 99 0 1 6 .


    Ich müsste ja noch nen 2 Parameter angeben, um die Pi's im Zielverzeichnis zu unterscheiden. Da weiss ich jetzt nicht mehr weiter :s


    Od muss ich ein "Zwischenscript" in die Runlevels eintragen, welches das richtige dann mit zusätzlichem Parameter 2 startet?


    Gruß, Thomas

  • Hallo meigrafd


    Ich hoffe, Du bist nachsichtig bezüglich meines enthusiastischen Eifers als Linux-Anfänger und nimmst mir das nicht übel.... aber ich bin immer noch der Meinung, dass im Script ein Integritäts-Problem mit eigentlich regelmäßigem Datenverlust besteht.... und zwar bei JEDEM Systemstart.


    Ich bin der Meinung, dass sdc->/var/log ausser beim allerersten Start von varlog danach gar nicht mehr verwendet werden darf. Ich versuche das mal zu erklären und greife auf meine Datumsbeispiele zurück.


    Der Rechner hatte ein Laufzeit vom 3. bis 20. Mai und wird am 20. Mai neu gestartet. In der Zeit vom 3. bis zum Shutdown wurden die Logs in tempfs->/var/log geschrieben und beim shutdown nach $varlogSave gesichert. Bis dahin ist alles im grünen Bereich.


    Nun wird der Rechner am 20. neu gestartet. Bevor varlog gestartet und aktiv ist, werden zunächst mal Log-Einträge ganz normal nach sdc->/var/log geschrieben.... sofern irgendwelche Programme überhaupt Einträge schreiben und das vor dem varlog-start tun. Und damit wird das Filedatum der betroffenen Dateien in sdc->/var/log aktualisiert und aus einer Alt-Datei vom 3. Mai wird eine geänderte mit heutigem Datum. In dieser Datei fehlen aber alle Einträge vom 3. bis 20. Und nun überschreibt beim Copy im Start-Code-Block diese Alt-Datei mit dem Log-Eintrag von heute (aber einem Datenloch vom 3. - 20) die eigentlich aktuelle und vollständige Datei in $varlogSave, die dann anschließend wiederum nach tempfs->/var/log kopiert wird.Damit sind die Log-Daten dieses Prozesses aus dem Zeitraum 3.-20.verloren.


    Meiner Meinung nach sollten die in der Bootphase vor varlog geschriebenen einträge ebenso wie die in der shutdownphase nach varlog geschriebenen Einträge in sdc->/var/log einfach unberücksichtigt bleiben. Reinkopieren -um das zu aktualisieren- geht leider nicht, und rauskopieren kopiert mit einem aktuellem Datum verfälschte Dateien, die keine Daten der Zeiten vor dem Boot enthalten.


    Ich habe das jetzt in meinem Script gelöst. Ebenso das Problem mit den Backup von 2 Pi's, die nicht kollidieren dürfen..... das war sogar einfacher als gedacht. Ich habe das oben mal aktualisiert.


    Gruss, Thomas

    Edited once, last by WinterUnit16246 ().

  • Hallo @ all


    Jetzt ist mir beim Durchsehen meiner Job-Log-Protokolle aufgefallen, dass mit meiner varlog-Adaption doch was nicht stimmt. Und beim genaueren Hinsehen habe ich festgestellt, dass sich die Files auf dem Hin- und Rückweg zwischen tempfs und meinem BackupDir regelrecht kaputt kopiert haben. Ich bin da jetzt nicht großartig traurig, denn nach ein paar Tagen füllen sich die Pötte ja alle wieder neu und sind dann irgendwann korrekt .... und im Moment gibts auch keinen Bedarf, in den Logs nach echten System-Fehlern zu suchen.


    Die Auswirkungen des Fehlers sind also im Moment "erträglich", und nachdem ich die Ursache beseitigt habe, lösen sich diese Fehlerauswirkungen irgendwann in Luft auf. Was war die Ursache? Es war das noch nicht verfübare Netzwerk in der Startphase der PI's. Bei mir sind ja beide PI vollständig im Netz integriert und nutzen demenstprechend auch die Speichermedien des Netzes für alle Aktionen.... eben genau das tut auch das Script "varlog".


    Ich habe jetzt in meinem Script ganz oben in der Sektion der Var-Inits 10 Wartesekunden eingebaut, wenn der Start des Scripts aller Wahrscheinlichkeit nach aus den Runlevels erfolgt ist. Damit ist der Fehler nie wieder aufgetreten. Aber ich weiss nicht, ob es da nicht eine bessere Methode gibt, als eine konstante Zeit zu warten.


    Hat vielleicht jemand einen Rat?


    Gruß, Thomas

    Edited once, last by WinterUnit16246 ().

  • Gelöscht wegen OT.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Edited once, last by rpi444 ().

  • Moin



    Ich starte Scripte die das Netzwerk benötigen, aus dem Verzeichnis "/etc/network/if-up.d".


    Starten die dort liegenden Scripte automatisch, wenn das Netz verfügbar ist? Was passiert, wenn das Netz resp. der Router mal kurz wegfällt und neu startet...?... würde das Script dann noch mal starten?


    Gruß, Thomas

  • Gelöscht wegen OT.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Edited once, last by rpi444 ().

  • Er hat das Script als Vorlage für sein Individuelles Vorhaben abgeändert - also würde ich euch bitten euren Problem-Lösungungs-Talk in einem eigenen Thread abzuhandeln, da das im Grunde nichts mehr mit diesem Tutorial hier zu tun hat... Danke


    Würde jeder sein individuelles Problem in den Anleitungs-Threads behandeln, würden diese ziemlich schnell aus allen Nähten platzen und extrem unübersichtlich werden. Daher bitte ich erneut um Verständnis und stillem Nachkommen.

  • Ein kleiner Erfahrungsbericht: Erst einmal vielen Dank für das schöne Tutorial. Habe mich von vorne nach hinten durchgearbeitet. ...und auch installiert.


    Zum Thema:

    Code
    sed -i /etc/default/rcS -e "s/RAMRUN=no/RAMRUN=yes/"
    sed -i /etc/default/rcS -e "s/RAMLOCK=no/RAMLOCK=yes/"


    ein df -h brachte zutage, dass die Switches schon gesetzt waren. In der rcS gab es keine Einträge - jedoch in der /etc/default/tmpfs. Habe ich dann so belassen. Also: nicht wie oben erwähnt einfach in die rcS eintragen.


    Zum Thema:
    umount in der stop-Sequenz. Ein händische Ausführen der Cron-Befehle hat auch mir bestätigt, dass dieser umount wegen Zugriffes erfolglos abgebrochen wird. Ich habe ihn entfernt. Die if-Anweisung in der start-Sequenz wird aufgrund des fstab-Eintrages bei mir nicht durchlaufen. Das ist aus meiner Sicht auch ok. Somit verkürzt sich der Cron-Eintrag wieder auf den ursprünglichen kürzeren, einteiligen Befehl.

    Code
    #varlog - Taeglich um 05:00
    0 5 * * * root /etc/init.d/varlog stop >/dev/null 2>&1



    Die beiden oben gekennzeichneten Zeilen loggen das Durchlaufen der start bzw stop Sequenz.


    Zum Thema
    was wird beim booten gerade noch vor dem Mounten in die alten /var/log/dateien geschrieben? Bei mir gar nichts. Nada. Habe die SD in meinen Desktoprechner getan und die alten Dateien in der /var/log gelöscht. Wieder zurück in den Raspi. Ein rehalt ;) durchgeführt und die Karte im Desktop ausgelesen: Keine Einträge im /var/log.
    Somit müssen hier auch keine gesonderten Mechanismen berücksichtigt werden. Wegen eines fehlenden umount-Befehls mache ich mir auch keinen Kopf, da die Partition beim shutdown sowieso ins Daten-Nirvana geschickt wird.

  • Moin,


    nachdem eine meiner SD´s den Geist aufgegeben hat, machte ich mich auf die Suche und fand noch etliche Prozesse, die schreibend auf die SD zugreifen.
    So z. B. die Datei dead.letter ("Mail Mülleimer" für nicht zugestellte Mails) und weitere Prozesse, die, gut versteckt, die SD beanspruchen.


    Wie nun bändigen?
    Eine Ramdisk ist ja schon vorhanden (/var/log....) und Links setzen ist ja auch keine Hexerei.
    Beispiel anhand der Datei: /root/dead.letter


    (vorher als root einloggen)
    1)Datei in der RAMDisk verschieben:

    Code
    mv /root/dead.letter /var/log/dead.letter


    2)Link auf ursprüngliche Datei setzen:

    Code
    ln -s /var/log/dead.letter /root/dead.letter


    3)Test, ob Daten geschrieben werden und der Link funktioniert:

    Code
    echo testroot >> /root/dead.letter | echo testvarlog >> /var/log/dead.letter | tail /root/dead.letter


    Die Ausgabe von tail sollte jetzt wie folgt aussehen:

    Quote


    .....
    testroot
    testvarlog


    4)Prima, damit die Datei aber nicht im Laufe der Zeit anschwillt und unnötig Speicher frisst, kann diese in logrotate eingebunden werden oder vor der RAMDisk-Sicherung mit

    Code
    > /var/log/dead.letter


    z. B. per cronjob geleert werden.


    Da im Mail Mülleimer dann doch gelegentlich interessante Info´s schlummern lasse ich mir diese per Mail zustellen, vor dem Löschen.


    Bye


    Jürgen

  • Moin,


    hab das script gestern getestet und es funktioniert soweit. Nur bekomme ich heute morgen eine Email mit der Info das logrotate probleme hat.


    Die Rechte von /var/log sehen so aus:


    hat jemand einen Tipp?
    Gruß
    Jan

  • Hallo,


    danke für die Rückmeldung, logrotate kreidet ja nicht nur Verzeichnisse an sondern auch files in /var/log.
    Scheint als wenn es an dem chmod 755 für /var/log/ liegt, welches in deinem Skript Anwendung findet. Ist vielleicht "zu viel Recht" für den Geschmack von logrotate. Hier trotzdem mal ein ls-la innerhalb von /var/log




    auf einem anderes Raspi hat /var/log ursprünglich diese Rechte:

    Code
    drwxr-xr-x 10 root root       4096 Sep  5 06:25 log


    anstatt nun:

    Code
    drwxrwxrwt 10 root root       1620 Sep  4 19:28 log
  • ich nochmal ;) sowas lässt mir ja keine Ruhe.


    Habe das nochmal genau nach deiner Anleitung gemacht (Wheezy Raspbian, frisch installiert, angemeldet mit User "pi").
    Gleich am Anfang beim Script erstellen mittels "nano /etc/init.d/varlog" gibts einen Berechtigungsfehler, also mache ich es mit
    sudo nano /etc/init.d/varlog


    auch das "chmod +x /etc/init.d/varlog" braucht ein sudo
    sudo chmod +x /etc/init.d/varlog


    somit auch das "update-rc.d varlog start 01 2 3 4 5 . stop 99 0 1 6 ."
    sudo update-rc.d varlog start 01 2 3 4 5 . stop 99 0 1 6 .


    Ist es vielleicht dann so, dass auch der chmod 755 auf /var/log in deinem script mittels sudo chmod 755 /var/log/ gemacht werden muss?


    Denn bei mir ist es so dass nach jedem Reboot die Rechte auf /var/log/ wieder so aussehen.
    drwxrwxrwt 10 root root 1620 Sep 4 19:28 log


    Update: auch mit sudo chmod 755 /var/log/ im skript sind nach dem booten die rechte auf 777 ;(
    Automatisch zusammengefügt:[hr]
    jetzt nerve ich bestimmt ;) aber ick habs.


    Es liegt daran das ich in der fstab schon den Eintrag
    tmpfs /var/log tmpfs size=70M 0 0
    habe. Denn dadurch hat /var/log 777 und in dem skript wird der chmod ja nur gemacht wenn tmpfs nicht schon vorhanden ist.

    Edited once, last by Jasimo ().

  • In der Anleitung gehe ich davon aus das man root ist, und somit entfällt es vor jeden Befehl "sudo" zu setzen. Entweder man weiß dass man root Rechte brauch um solche Modifikationen vorzunehmen, wenn das jeder 0815 Benutzer könnte wäre das nicht besonders sicher - oder das man vorher zum root Benutzer wechseln sollte...


    Das Script selbst wird bereits als root ausgeführt und benötigt daher kein "sudo", auch nicht die darin befindlichen Befehle.


    Im Script wird der chmod nur dann gemacht wenn /var/log noch nicht gemountet ist: if [ -z "$(grep /var/log /proc/mounts)" ]; then
    Mit /etc/fstab hat das an dieser Stelle nicht viel zu tun bzw nicht direkt.
    Der Eintrag in /etc/fstab ist gewollt und so auch vorgesehen. Was Helfen könnte wäre den chmod unter die if zu setzen, also nach dem "fi"und vor "cp -Rpu ${varlogSave}* /var/log/"


    Normalerweise wird /var/log/ nicht separat gemountet. Dh an dieser Stelle geht das Script davon aus, das falls ein mount von /var/log/ schon vorhanden ist das Scripts bereits gestartet wurde und somit diese Operation nicht nochmals machen sollte.

  • Hallo,


    stimmt alles was Du sagst. Denke das mit dem chmod unter das if ist (zumindest für mich) die Lösung.
    Danke! für das tolle Skript und Howto

  • Guten Abend,
    die Optimierungen laufen bei mir nun und das sehr gut. Sehr gutes Tut und auch gut erklärt. Eine Frage hätte ich aber nun doch und zwar, ich habe bei meinem RPi kurzes rhytmisches leuchten der SD aktivitäts led, so ca alle sek. 1 mal. Aber wie gesagt das Leuchten ist ganz schwach und rhytmisch. Ist das Normal? Wenn ja ist es mir, anscheinend, vorher nie aufgefallen.


    Als Tool habe ich bei mir IOTOP installiert um den lästigen Lese oder Schreibzugriffen Herr zu werden. Ich hänge hier mal einen Screanshot an.
    Als OS läuft bei mir Raspbian (Wheezy) sowie Asterisk, DoorPi und den mjpg-streamer.


    Kann ich hier noch verbessern?


    Danke für Eure Hilfe


  • ich habe bei meinem RPi kurzes rhytmisches leuchten der SD aktivitäts led, so ca alle sek. 1 mal. Aber wie gesagt das Leuchten ist ganz schwach und rhytmisch. Ist das Normal? Wenn ja ist es mir, anscheinend, vorher nie aufgefallen.


    Als Tool habe ich bei mir IOTOP installiert um den lästigen Lese oder Schreibzugriffen Herr zu werden. Ich hänge hier mal einen Screanshot an.


    Die Grüne LED (ACT) zeigt allgemein Zugriffe auf die SD an, also sowohl Schreiben als auch Lesen.
    Wie du deinem Screenshot entnehmen kannst laufen 4 Prozesse die für diese Zugriffe verantwortlich sind:
    doorpi -> lesend
    asterisk -> schreibend
    jbd2 -> schreibend
    ntpd -> schreibend


    Lesende Zugriffe sind nicht schädlich und können ignoriert werden.
    Was oder wo asterisk schreibt kann ich nicht beurteilen, kenne ich mich nicht mit aus...
    jbd2 deutet darauf hin das die Journaling-Funktion des Dateisystems genutzt wird. Bedeutet zu Deutsch: Du nutzt ext4. Abhilfe erreicht man durchs abschalten des Journaling. Dazu musst du den Datenträger des Dateisystems aber aushängen/umounten und das würde bei der SD des PI's bedeuten das du ein anderes Linux-System benötigst, eine VM oder eine LiveCD o.ä... Und dort dann (ohne den Datenträger zu mounten): sudo tune2fs -O ^has_journal <DEVICE> Siehe dazu auch http://wiki.ubuntuusers.de/ext
    ntpd mag ich allgemein nicht, aber nur weil ständig/permanent ein Dienst läuft... Ich bevorzuge stattdessen rdate über crontab.. Nichts desto Trotz synchronisiert der Dienst die Systemzeit..