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

  • Fragen, Anregungen usw bitte im Diskussions-Thread stellen! :danke_ATDE:


    Das ständige Schreiben in /var/log/ kann die Lebenszeit einer SD negativ beeinflussen, insbesondere wenn man den Mini-Rechner permanent laufen lässt - deshalb würde ich hier gerne einige Möglichkeit vorstellen um /var/log in ein sogenannten tmpfs Bereich auszulagern
    sowie ein paar weitere Modifikationen um nicht unbedingt alles zu loggen (teilweise wird auch einiges doppelt geloggt)


    Allerdings hat tmpfs für /var/log/ auch einige Nachteile:

    • tmpfs liegt im RAM, wovon der RaspberryPI nicht allzuviel hat - es verbraucht aber nur soviel Ram wie tatsächlich belegt ist (Vorteil gegenüber ramfs) wenn allerdings kein freier Ram mehr zur Verfügung steht würde tmpfs auf den SWAP ausweichen und der wiederum befindet sich auf der SD..
    • tmpfs ist flüchtig - das heisst die Daten sind nach dem ausschalten oder reboot komplett weg.. Das mag für manche nicht schlimm sein, allerdings gibt es in /var/log/ einige Dateien und Verzeichnisse die nicht automatisch erzeugt aber von einigen Diensten benötigt werden - da müsste es also ein Script geben was sich bei Systemstart darum kümmert...
      Desweiteren wird es bei einem ungewollten Neustart schwer irgendwelche Probleme dann noch nachzuvollziehen - also bräuchte man eigentlich auch ein Script was /var/log/ regelmässig sichert

    Einfach nur über /etc/fstab ein tmpfs für /var/log/ zu erzeugen ist keine gute Idee, da dann keine Verzeichnisse angelegt werden die aber von einigen Diensten benötigt werden um Logfiles schreiben zu können - auch Dateirechte sind wichtig damit einige Dienste überhaupt ihre Logs beschreiben; es gibt sogar 2 Dienste die ihre Logfiles nicht selber erstellen und somit zum Beispiel die "zuletzt angemeldeten Benutzer" nicht mehr protokolliert werden würden.
    Deshalb wäre es sinnvoller mein weiter unten gezeigtes varlog Script zu verwenden.


    Nun gibt es bekanntlich mehrere Wege etwas umzusetzen, ich gehe erstmal nur auf einen ein (da ich auch gleich Zubett mus :D)

    Ich gehe nun erst mal davon aus das ihr Raspbian nutzt - inwiefern das hier auch für OpenELEC oder Raspbmc zutrifft müsste erst noch herrausgefunden werden


    Also zunächst müsste man sich darüber im klaren werden wann bzw wie oft man /var/log/ sichert.
    Ich denke das ein mal jeden Tag reichen sollte - zusätzlich richten wir aber auch ein Script ein was beim herunterfahren ebenfalls eine Sicherung erstellt sowie beim hochfahren die Sicherung von /var/log/ wiederherstellt..

    • Script erstellen:
      nano /etc/init.d/varlog

      "alt"
    • Script ausführbar machen:

      Code
      chmod +x /etc/init.d/varlog
    • Script bei Systemstart so früh und beim herunterfahren so spät wie möglich ausführen:

      • Für ein Linux älter als Jessie: Script in den Runlevel eintragen sodass es bei starten und herunterfahren des Systems ausgeführt wird:

        Code
        update-rc.d varlog start 01 2 3 4 5 . stop 99 0 1 6 .
      • Für Jessie oder neuer => Beitrag#49
    • Nun sorgen wir dafür das /var/log/ erstmalig gesichert wird:

      Code
      /etc/init.d/varlog stop
    • Bevor wir nun "start" ausführen eine kurze Erklärung was /etc/init.d/varlog macht:

      Durch den " stop " Parameter werden alle Dateien und Verzeichnisse inkl. deren Datei-Rechte/Besitzer von /var/log/ nach /var/save.log/ kopiert.

      Durch den " start " Parameter wird erst geprüft ob tmpfs bereits für /var/log gemounted wurde und falls nicht wird /var/log/* nach /var/save.log/ kopiert und /var/log/ als tmpfs mit 70M (Megabyte) eingehängt (über das vorhandene)..
      Anschliesend werden alle Dateien und Verzeichnisse inkl. deren Datei-Rechte/Besitzer von /var/save.log/ nach /var/log/ kopiert.

      Man kann auch in /etc/fstab eine Zeile einfügen worüber die maximale Grösse fürs tmpfs von /var/log festgelegt wird, das würde das Script dann auch auslesen:

      Code
      tmpfs		/var/log	tmpfs	size=70M	0	0

    Nun starten wir das Script damit tmpfs für /var/log eigehängt wird:

    Code
    /etc/init.d/varlog start

    Somit würde nun die SD schon mal (vorallem im Dauerbetrieb) entlastet werden ;)

    Wichtig hierbei ist allerdings dass wenn der RPI crashen sollte, also nicht regulär herunter fährt, sämtliche neu geschriebenen Daten weg sind - tmpfs ist flüchtig. Also wenn möglich das System immer normal herunter fahren ( halt oder poweroff oder shutdown -r now oder reboot usw)


    Nun zu dem Problem das der RaspberryPI nicht immer sauber herunter gefahren wird - sondern oft einfach nur der Netzstecker gezogen wird:

    Dazu erstellen wir uns einen crontab Eintrag - da gäbe es nun 2 Möglichkeiten:

    - Entweder es wird die crontab des root Benutzers verwendet: sudo crontab -e

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

    - Oder es wird die System-Crontab verwendet: nano /etc/crontab

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

    ACHTUNG: Auf diese Anpassung würde ich aber wenn möglich verzichten da dass kontraproduktiv wäre, das würde die SD wieder nur unnötig belasten!


    Optimierungen:

    Jetzt gäbe es noch ein paar weitere Probleme, das aber nicht unbedingt nur tmpfs betrifft:

    • Der syslog Daemon schreibt einige Log-Dateien sofort und andere wiederrum Zeitverzögert. Der Sinn ist, dass Systemrelevante Informationen sofort in Stein gemeißelt werden (Debugging Informationen) während unwichtigere Infos ruhig verzögert geschrieben werden können..
      Welche Log-Datei wie behandelt wird erkennt man in der /etc/syslog.conf an dem führenden "–" vor der Log-Datei. Alle Dateien mit "–" werden verzögert geschrieben.
    • (r)Syslogd generiert auch regelmässig 'MARK' timestamp Einträge in den Logs was man auch abschalten kann/sollte und zwar über die Datei /etc/default/syslogd (oder /etc/default/rsyslog) indem man den einen Eintrag ergänzt zu:

      Code
      RSYSLOGD_OPTIONS="-c3 -m 0"
    • Zum einen ist (zumindest Debian bzw Raspbian) standardmässig so konfiguriert das die letzten 4 Logdateien behalten werden, das letzte ungepackt mit Dateiendung ".0" und alle älteren werden mit gzip gepackt. Das kann bei einer begrenzten Grösse für /var/log/ problematisch werden..
      Das wird über die Datei /etc/logrotate.d/rsyslog geregelt aber ausserdem wird über die Datei auch festgelegt was in welche Logdatei geschrieben werden soll, was auch den eingangs erwähnten doppelten Eintrag verursacht und zwar beinhaltet /var/log/messages , /var/log/syslog sowie /var/log/kern.log nahezu identisch Einträge.
      Über die Datei kann auch eingestellt werden wieviele Backup Dateien behalten werden sollen usw.
      Weitere Details kann man sich über die manual-pages anzeigen lassen ( man logrotate ) oder hier nachlesen: http://wiki.ubuntuusers.de/Logdateien
    • Eine weitere Optimierung wäre auch /etc/fstab um folgende Optionen zu erweitern: noatime,nodiratime,commit=120 sodass es zum Beispiel so aussehen würde:

      Code
      proc            /proc           proc    defaults          0       0
      /dev/mmcblk0p1  /boot           vfat    defaults,noatime,nodiratime,commit=120          0       2
      /dev/mmcblk0p2  /               ext4    defaults,noatime,nodiratime,commit=120  0       1
      # a swapfile is not a swap partition, so no using swapon|off from here on, use  dphys-swapfile swap[on|off]  for that
    • Eine weitere Optimierung bzw Reduzierung der Schreibzugriffe wäre für /tmp/ ebenfalls tmpfs zu erzeugen, da dort zum Beispiel bei jedem SSH Zugriff eine temporäre Datei erzeugt wird, aber auch weitere Dateien ausgelagert werden.. Das aktiviert man ebenfalls über /etc/default/tmpfs:
      Code
      RAMTMP=yes
    • Dann müssen wir noch RamRun und RamLock aktivieren:

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


      RAMRUN bewirkt dass beim Bootvorgang alles in /var/run/ belassen wird und nicht aufgeräumt, und /var/run wird dadurch auch in tmpfs abgelegt
      Das gleiche gilt auch für RAMLOCK bezüglich /var/lock/
      RAMRUN/RAMLOCK Hintergrund:

      Spoiler anzeigen

      Adding RAMRUN=yes and RAMLOCK=yes to /etc/default/rcS will make Debian put your /var/run and /var/lock in a tmpfs instead of on disk.

      RAMRUN:
      Make /var/run/ available as a ram file system (tmpfs).
      Will also disable cleaning of /var/run/ during boot.
      Set to 'yes' to enable, to 'no' to disable.
      The size of the tmpfs can be controlled using TMPFS_SIZE and RUN_SIZE in /etc/defaults/tmpfs.

      RAMLOCK:
      Make /var/lock/ available as a ram file system (tmpfs).
      Will also disable cleaning of /var/lock/ during boot.
      Set to 'yes' to enable, to 'no' to disable.
      The size of the tmpfs can be controlled using TMPFS_SIZE and LOCK_SIZE in /etc/defaults/tmpfs

      Guck auch mal in die Datei /etc/default/tmpfs , da kannste auch noch ein paar Sachen einstellen ;)


    Weitere Optimierungen (auch bezüglich Logrotate) findet ihr > hier <


    Bekannte Probleme:

    Seltsamerweise kommt es auf manchen Systemen vor das apache2 früher gestartet wird als varlog aber das dann nicht funktioniert weil für apache2 einige Verzeichnisse fehlen..
    Ein Workaround wäre folgendes:

    Code
    #apache2 fix
    for i in $(ls /etc/rc?.d/S??apache2) ; do mv -f $i $(dirname $i)/S99apache2; done
    
    
    #varlog fix
    for i in $(ls /etc/rc?.d/S??varlog) ; do mv -f $i $(dirname $i)/S01varlog; done


    Links:

    http://wiki.ubuntuusers.de/SSD/Auslagerung
    https://help.ubuntu.com/community/SwapFaq


    Changelog:
    12.08.2014: Crontabeintrag für "varlog start" angepasst

  • /var/log/ in eine Art RAMdisk auslagern & weitere Optimierungen bezgl. Logs? Schau mal ob du hier fündig wirst!

  • Hi meigraf!

    Schöne Anleitung!

    Die Probleme mit Apache, die auch bei nginx auftreten, lassen sich verhindern, wenn man Dein Skript im INIT INFO ergänzt:

    Code
    # X-Start-Before: $syslog
    # X-Stop-After:   $syslog


    weisen rc.d an, das varlog-Skript in der Reihenfolge vor $syslog (i.d.R. rsyslog) zu starten und nach $syslog zu beenden.

    Herzliche Grüße, Thomas

    Einmal editiert, zuletzt von thbeckmann (21. Dezember 2013 um 11:06)

  • Es gibt nur bestimmte Required-Start / Required-Stop Bedingungen die man nutzen kann. Welche das sind kann man fast am Ende von folgendem Artikel nachlesen: https://wiki.debian.org/LSBInitScripts
    Man könnte zwar auch selber welche festlegen aber damit hab ich mich noch nie beschäftigt ;)


    Der Workaround vom apache2 funktioniert für nginx bei dir nicht :huh:

    Ansonsten bitte genauer beschreiben wie dein 'Konflikt' aussieht - und am besten auch in einem eigenen Thread, denn sonst werden die Tutorial Threads schnell unübersichtlich wenn hier jegliche Probleme behandelt werden...

  • Sehr nettes Tutorial. Habe eben meinen kleinen LAN-Server nach der Anleitung umgestellt und es funktioniert perfekt. Ein paar Dinge sind mir aufgefallen:

    1) Im Script fehlt die Zeile die /var/save.log anlegt falls es noch nicht existiert. Oder man legt es manuell einmal an.

    Code
    [ ! d /var/save.log ] && mkdir /var/save.log
    /bin/cp -Rpu /var/save.log/* /var/log/

    2) Die folgenden sed Zeilen funktionieren bei mir nicht da in meiner rcS weder eine Zeile mit RAMRUN noch RAMLOCK steht und deshalb keine Ersetzung funktioniert. Ich habe die beiden Zeilen manuell mit dem vi eingebaut.

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

    3) In der folgenden Zeile ist ein Typo:

    Code
    varlogsize=$(grep /var/log /etc/fstab|awk {'print \$4'}|cut -d"=" -f2)


    Es muss heissen

    Code
    varlogsize=$(grep /var/log /etc/fstab|awk {'print $4'}|cut -d"=" -f2)

    4) Der folgende Code der das /var/log sichert synchronisiert nicht beide Verzeichnisse, d.h. löscht keine Dateien in /var/save.log wenn sie nicht mehr in /var/log existieren. Das muss man beruecksichtigen, wenn man in /var/log mal aufraeumt. Das musste ich machen, denn in diesem Kontext ist mir aufgefallen, dass mein mindlna.log in der Zwischenzeit ziemlich gross geworden war, weil ich es nicht in logrotate aufgenommen hatte.

    Code
    /bin/cp -Rpu /var/log/* /var/save.log/ >/dev/null 2>&1

    5) Es sind keine absoluten Pfade fuer die benutzten Befehle wie echo, cp usw im Script notwendig. Ich habe sie bei mir rausgenommen.

    6) logrotate meckert wegen der 777 Rechte bei /var/log. Deshalb habe ich

    Code
    chmod 755 /var/log
    cp -Rpu /var/log.save/* /var/log/

    noch ins Script eingebaut.


  • Sehr nettes Tutorial. Habe eben meinen kleinen LAN-Server nach der Anleitung umgestellt und es funktioniert perfekt. Ein paar Dinge sind mir aufgefallen:

    1) Im Script fehlt die Zeile die /var/save.log anlegt falls es noch nicht existiert. Oder man legt es manuell einmal an.

    Code
    [ ! d /var/save.log ] && mkdir /var/save.log
    /bin/cp -Rpu /var/save.log/* /var/log/

    Ich muss gestehen das ich immer nur den Post >hier< aktualisiert aber diesen hier vernachlässigt habe :blush:

    In dem eigentlich aktuellen Script wird das vor dem case erstellt:

    Code
    varlogSave=/var/save.log/
    [ ! -d $varlogSave ] && mkdir -p $varlogSave



    2) Die folgenden sed Zeilen funktionieren bei mir nicht da in meiner rcS weder eine Zeile mit RAMRUN noch RAMLOCK steht und deshalb keine Ersetzung funktioniert. Ich habe die beiden Zeilen manuell mit dem vi eingebaut.

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

    Hm das ist ungewöhnlich bzw anscheint ist das bei Raspbian nun in /etc/default/tmpfs , muss ich mal überprüfen ob das eine allgemeine Debian Änderung ist oder nur bei Raspbian... Ansonsten bau ich halt ne entsprechende Dateiprüfung noch ein ;)


    3) In der folgenden Zeile ist ein Typo:

    Code
    varlogsize=$(grep /var/log /etc/fstab|awk {'print \$4'}|cut -d"=" -f2)


    Es muss heissen

    Code
    varlogsize=$(grep /var/log /etc/fstab|awk {'print $4'}|cut -d"=" -f2)

    Stimmt leider - es war halt so dass das ursprüngliche Script von einem anderen Script erstellt wurde und man dort alle $ maskieren musste... hab ich nur in dieser Zeile anscheint vergessen :blush:


    4) Der folgende Code der das /var/log sichert synchronisiert nicht beide Verzeichnisse, d.h. löscht keine Dateien in /var/save.log wenn sie nicht mehr in /var/log existieren. Das muss man beruecksichtigen, wenn man in /var/log mal aufraeumt. Das musste ich machen, denn in diesem Kontext ist mir aufgefallen, dass mein mindlna.log in der Zwischenzeit ziemlich gross geworden war, weil ich es nicht in logrotate aufgenommen hatte.

    Code
    /bin/cp -Rpu /var/log/* /var/save.log/ >/dev/null 2>&1

    mmh good point. Muß ich mir mal überlegen ob ich daraus rsync mache...


    5) Es sind keine absoluten Pfade fuer die benutzten Befehle wie echo, cp usw im Script notwendig. Ich habe sie bei mir rausgenommen.

    Also meine Erfahrung (ich nutze varlog schon bevor es den RPI überhaupt gab) hat gezeigt das man nie etwas falsch machen kann wenn man Absolute Pfade nutzt und gerade weil das varlog Script ziemlich früh gestartet wird, ist ggf. noch keine PATH gesetzt usw also lieber absolute Pfade drin lassen als Probleme kriegen ;)

    oder eben in dem Script PATH=/sbin:/usr/sbin:/bin:/usr/bin setzen


    6) logrotate meckert wegen der 777 Rechte bei /var/log. Deshalb habe ich

    Code
    chmod 755 /var/log
    cp -Rpu /var/log.save/* /var/log/


    noch ins Script eingebaut.

    Auch das ist im aktuellen Script >hier< schon behoben und hatte ich dort auch >hier< reported

    Allgemein stehen in dem Post aber auch noch weitere nützliche Tipps die ich ggf mal hier einfügen sollte ;)

  • Dieses Tut hatte ich schon lange im Hinterkopf und bin es dann endlich gestern angegangen. Dass es einen Thread dazu gibt wo dasselbe Thema behandelt wird war mir nicht bekannt. Daten- bzw Informationsredundanzen haben leider die Angewohnheit nie lange in sync zu bleiben. Du wirst diese Redundanz sicherlich aufloesen :).

    Habe eben das Script vom anderen Thread kopiert und aktiviert und es funktioniert perfekt. Durch die Einfuehrung der varlogSave Variable konnte ich auch einfacher den Namen anpassen, denn mir gefaellt /var/log.save besser. Dann stehen beide Namen direkt untereinander beim normalen ls.

    Zum rsync: Daran hatte ich auch schon gedacht, dass zu aendern. Leider gehoert rsync aber nicht zur Standardinstallation bei Raspian. Und genaugenommen ist es auch nur eine geringfuegige Feinheit.

    Zu den Pfaden: Das schadet natuerlich nicht sie zu benutzen. Ich persoenlich mag sie nicht, da sie die Leserlichkeit eines Scripts negativ beeinflussen und setze dann lieber einmal am Anfang den Pfad entsprechend wenn es unbedingt notwendig ist. Aber das ist Geschmackssache .

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

    Leider verkompliziert der Profi manche Dinge etwas unötig für den Laien da er alles automatisieren möchte, denn es ist nicht ersichtlich WIE denn nun diese beiden
    Parameter stehen müssen, wenn man nicht den Uralt Editor sed kennt, den (fast) keiner mehr benutzt. Man kann es ja auch manuell editieren zb mit nano.

    Müssen die nun auf

    RAMRUN=YES
    RAMLOCK=YES

    stehen oder beide auf NO?

    (RAMRUN=YES ist in der /etc/default/tmpfs, RAMLOCK nicht)

    Darüber hinaus gibt es von den Herstellern KEINE Informationen darüber welche Mechanismen in SD Karten eingesetzt werden, da diese unter Betriebsgeheimnis fallen.
    Ich habe diesbezüglich dienstlich bei SanDisk nachgefragt deren Karten wir in Produkten verwenden. Es wurde uns daher geraten einen verzögerten Cache einzurichten, der Schreibzugriffe auf die Karte minimiert und der generell vor die Karte geschaltet wird, wie zb bei Windows standardmässig. Auch Smartphone arbeiten mit einem Tweaking Cache oder "SD Booster".

    Einmal editiert, zuletzt von Superhobel (11. Mai 2014 um 22:26)

  • Superhobel: In meinem TuT steht das diese Werte aktiviert werden müssen.. Aktivieren bedeutet 'yes'.
    Der sed Befehl sucht nach dem Vorkommen "RAMRUN=no" und ersetzt es mit "RAMRUN=yes".

    Bei dem rest weiß ich nicht genau was du uns damit sagen willst?

  • Hi Profi,

    habs verstanden duch intensive Analyse des sed Befehls wo das s wohl für substitute steht :bravo2:

    Der Rest ist Techno-Babble.... einfach so ..... d.h. dass Du keine Infos kriegst, ob dieses RAM Caching wirklich
    etwas bewirkt oder ob man es so hätte lassen können wie es ist. ir verbauen diese Karten zu tausenden pro Jahr.
    Die Geäte sind eher kaputt als die Karten.


  • etwas bewirkt oder ob man es so hätte lassen können wie es ist. ir verbauen diese Karten zu tausenden pro Jahr.
    Die Geäte sind eher kaputt als die Karten.

    Das kommt extrem auf den Einsatzbereich usw an - mir sind schon 2 gestorben weshalb ich dann diese Scripts geschrieben hab und seither is mir keine mehr verreckt
    Das läßt sich also nicht wirklich einfach so verallgemeinern zumal SD Karten eigentlich für Sequenzelles schreiben optimiert sind aber nicht für Random, wie es aber bei Betriebssystemen der Fall ist.
    Desweiteren halten NAND-Flash Speicherzellen einfach nicht unendlich viele Schreib- Lese- Zugriffe aus, das ist technisch Fakt.. Das wird mit den hier genannten Optimierungen ebenfalls minimiert und steigert somit die Lebensdauer

  • Hi,

    ich habe mal eine naive Frage, da es nicht mehr funktioniert, wenn man es ins NAND kopiert, d.h. das Systm aus dem Nand heraus startet.

    Wo wird eigentlich das Verzeichnis /var/log wieder mit Inhalt bespielt?

    Code
    cp -Rpu /var/log/* $varlogSave

    sichert (??) das /log ja bei service start.

    und weiter unten das gleiche nochmal

    Code
    cp -Rpu /var/log/* $varlogSave >/dev/null 2>&1


    auch in die gleiche Richtung.

    Müsste es nicht:

    cp -Rpu /var/log/* /var/save.log/

    heissen bei start?

    De Ausdruck

    Code
    varlogsize=$(grep /var/log /etc/fstab|awk {'print $4'}|cut -d"=" -f2) [ -z "$varlogsize" ] && varlogsize="70M"

    ist schwer zu lesen finde ich, lässt sich der auch entschachtelt und dadurch vielleicht fehlerfreier machen? Klappt nämlich auch nicht bei mir.

    Einmal editiert, zuletzt von Superhobel (14. Mai 2014 um 21:47)

  • $varlogSave ist eine Variable und wird oben im Script festgelegt: varlogSave=/var/save.log/
    Beim start wird es erst, sofern noch nicht gemountet, gesichert und anschließend zurück kopiert - siehe case start)

    varlogsize wird durch auslesen eines möglicherweise in /etc/fstab vorhandenen Eintrags festgelegt. existiert aber kein solcher Eintrag wird varlogsize auf 70M gesetzt. Aber was du in einer zeile gepostet hast muß in 2 zeilen stehen, was in meinem script auch der fall ist! also bitte noch mal dein script genauer mit meinem vergleichen

  • Hallo @ all

    Ich habe gerade das Script eingerichtet.... und es funktioniert! :thumbs1: Allerdings habe ich erst mal gar nix kapiert, mir deshalb dann den ganzen Mist über runlevels :-/ in den Wikis reingezogen und dann doch nicht gewusst, ob die Umleitung auf tmpfs überhaupt aktiv ist oder nicht.

    Ich habe mir erlaubt, für meinen Einsatz ein paar Änderungen vorzunehmen. Ich poste das hier mal, weil ich eben von Shell-Script noch nicht wirklich Ahnung habe und ich hoffe, jemand findet einen Bock, falls ich einen geschossen habe. Folgendes habe ich geändert:

    1. Ich habe die tmpfs-größe auf 50 mb limitiert. Ich werde das mal im Auge behalten, obs reicht.
    2. Weil ich anfangs nicht gesehen habe, obs überhaupt gestartet wird, habe ich ein paar Log-Einträge implementiert, die aber nur bei Start und Stop schreiben.... und die mir das Programm etwas näher gebracht haben.

    So sieht das mit den Log-Einträgen aus:

    Wie gesagt, ich habe danach das Programm ein wenig besser verstanden. Und so sieht das jetzt aus:

    Allerdings habe ich zweit Dinge nicht verstanden. Ich hoffe, mir erklärt das jemand.

    1. Was bedeutet diese Zeile...?...was tut die? Was ist -z für ein Befehl? :s
    [ -z "$varlogsize" ] && varlogsize="50M"

    Und 2. Wenn ich das mit der Crontab einrichte, dann ist der "Dienst" doch beendet und es wird wieder ganz normal auf die Karte geschrieben. Und am zweiten Tag muss doch ein Fehler passieren, weil beim Aufruf durch die Crontab die Umleitung doch gar nicht mehr läuft. Ich habe den Crontab-Eintrag deshalb erst mal gelassen. Wie kann ich das lösen? Die "Umleitung" der /var/log/ soll ja morgen nach 5 Uhr immer noch bestehen.

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

    vg, Thomas

    Einmal editiert, zuletzt von WinterUnit16246 (12. August 2014 um 18:00)

  • In dem Script ist bereits ein Limit von 70MB eingestellt (70M), die verwendet wird sofern in /etc/fstab kein Eintrag für /var/log/ vorhanden ist, und genau das wird über die 2 folgenden Zeilen bewerkstelligt:

    Code
    varlogsize=$(grep /var/log /etc/fstab|awk {'print $4'}|cut -d"=" -f2)
    [ -z "$varlogsize" ] && varlogsize="70M"

    Die erste Zeile prüft bzw durchsucht die Datei /etc/fstab nach Einträgen für /var/log sowie filtert dann die 4.Spalte (awk) .... usw
    Die zweite Zeile ist eine if-Schleife, nur eben ohne if then fi , das kann man bei Einzeilern in bash auch so schreiben.. Das -z bedeutet soviel wie: wenn nachfolgendes leer oder nicht vorhanden. Bedeutet also in diesem Fall das der in der ersten Zeile erfolgte Suchvorgang erfolglos war. Wenn also "$varlogsize" leer, dann setze varlogsize auf 70M.


    Bockmist hast du insofern gebaut als dass du ein Logfile auf die SD schreibst und somit den Grund wieso /var/log ausgelagert wird teilweise außer Kraft setzt.
    Das varlog Script dient dazu die SD zu entlasten und Schreib-/Lese-Vorgänge zu minimieren, dein /home/varlog.log wirkt dem aber entgegen :-/
    Desweiteren hast du keine Logfile-Größen-Prüfungen und wenns dumm läuft wächst und wächst und wächst das Logfile ins unermessliche...

    Also eigentlich eher Kontraproduktiv und eigentlich auch überflüssig wenn man weiß worauf man achten muss:

    Ob es funktioniert hat kann man an 2 Stellen prüfen:
    Zum einen kann man über die Ausgabe des Befehls mount gucken ob dort für /var/log ein tmpfs auftaucht. Das geht auch über den Befehl df .
    Zum anderen gibts Tools um die Disk I/O Zugriffe zu beobachten, zum Beispiel: iotop , iostat , iozone , sar , dstat oder vmstat


    Wegen deiner 2.Frage muss ich zugeben das Ich da Bockmist geschossen habe :blush: bzw müsste der Befehl eben auch anschließend wieder mit start in crontab stehen:

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

    Das sleep sorgt dafür das dem Device ein kleines bisschen Pause gegönnt wird ;)
    Die && bewirken in diesem Fall das der nachfolgende Befehl nur ausgeführt wird wenn der vorherige erfolgreich war. Wenn also das stoppen nicht erfolgreich war brauch man auch nicht noch mal starten..

  • Danke für Deine Antwort.... jetzt habe ich das auch soweit erst mal verstanden :thumbs1:

    In dem Script ist bereits ein Limit von 70MB eingestellt (70M), die verwendet wird sofern in /etc/fstab kein Eintrag für /var/log/ vorhanden ist, und genau das wird über die 2 folgenden Zeilen bewerkstelligt:

    Mein var/log ist derzeit etwa 5 mb groß. Da dachte ich, dass ich das erstmal im Script auf 50mb downsizen kann. Ich werde das aber mal im Auge behalten.

    Ich habe aber anderer Stelle noch ein kleines Verständnisproblem. Wenn doch in der fstab für /var/log eine Größe definiert ist, so kann ich doch eigentlich auch davon ausgehen, dass der mount für tmpfs mit dem mountpoint /var/log schon über die fstab passiert ist. Wäre es da nicht sauberer, den neuen mount in diesem codeblock nicht auszuführen, wenn varlogsize > 0 ist? :s

    Zitat

    Bockmist hast du insofern gebaut ....


    Jau, absolut.... aber zu dem Zeitpunkt hatte ich an die beiden morgendlichen 5-Uhr-Jobs noch gar nicht gedacht, weil die ja auch noch gar nicht implementiert waren. In dem Moment war's nur ein Boot- und Shutdown-Job, wo zwischen den beiden auch mal mehrere Wochen liegen können. Deshalb war das irrelevant. Aber jetzt mit dem 5-Uhr-Tee sieht das ganz anders aus. :no_sad:

    Ich möchte nicht auf mein Log verzichten, weil ich das auch noch für andere Dinge brauche. Für meine automatischen Backups zum Beispiel, die sich aus mehreren Einzeljobs zusammensetzen.... und für weitere planmäßig durchzuführenden automatischen aufgaben.

    Deshalb habe ich jetzt unterhalb der Datumsvariable d die Variablenzuweisung systemlog=/media/HD_1/Log/system.log eingesetzt. Und im weiteren alle /home/varlog durch $systemlog ersetzt. Jetzt werden die Einträge korrekt in mein Log auf der Platte angehängt.

    Im ersten Posting schreibst Du:

    Code
    ACHTUNG: Auf diese Anpassung würde ich aber wenn möglich verzichten da dass kontraproduktiv wäre, das würde die SD wieder nur unnötig belasten!


    Ich nehme mal an, Du meinst damit, dass man besser auf beide Cronjobs verzichtet... also kein stop, kein start. Wäre es vielleicht eine Alternative, die flüchtigen /var/logs in tmpfs einfach auf die Platte zu sichern? Also in die Case-Abfrage hinter stop und vor * einfach auf z.B. Copy2HD einfügen. Dort wird das Paket aus tempfs einfach einmal täglich auf die Platte kopiert und man hat es zur Verfügung, falls man mal nach Problemen recherchieren muss. Das heisst, auf die SD-C würde ich dann gar nicht zurückkopieren. Würde das gehen?

    Ich habe das einfach mal eingebaut und getestet... es funktioniert. Ich stells jetzt so ein, dass mir die crontab alle Dateien aus /var/log (tmpfs) einmal täglich um 5 Uhr auf die Platte sichert. Und mit dem Protokoll werde ich immer daran erinnert, dass ich die Größe im Auge behalten muss. Das bedeutet, auf Karte findet da für diese Sache dann nix mehr statt.... und die Sicherung habe ich trotzdem.

    Gruss, Thomas

    Einmal editiert, zuletzt von WinterUnit16246 (12. August 2014 um 17:58)


  • Danke für Deine Antwort.... jetzt habe ich das auch soweit erst mal verstanden :thumbs1:


    Mein var/log ist derzeit etwa 5 mb groß. Da dachte ich, dass ich das erstmal im Script auf 50mb downsizen kann. Ich werde das aber mal im Auge behalten.

    Du scheinst aber den ersten Beitrag nicht vollständig gelesen oder verstanden zu haben: Die 70M oder 50M bezieht sich auf die Maximale Größe, die aber nicht gleich von Anfang an belegt wird. tmpfs verhällt sich nicht wie ramfs. tmpfs belegt nur soviel wie tatsächlich verwendet wird. Also auch wenn du da 200M einstellen würdest und nur 5MB belegt wären, würde die tmpfs auch nur 5MB Ram verwenden.



    Jau, absolut.... aber zu dem Zeitpunkt hatte ich an die beiden morgendlichen 5-Uhr-Jobs noch gar nicht gedacht, weil die ja auch noch gar nicht implementiert waren. In dem Moment war's nur ein Boot- und Shutdown-Job, wo zwischen den beiden auch mal mehrere Wochen liegen können. Deshalb war das irrelevant. Aber jetzt mit dem 5-Uhr-Tee sieht das ganz anders aus. :no_sad:

    Ich möchte nicht auf mein Log verzichten, weil ich das auch noch für andere Dinge brauche. Für meine automatischen Backups zum Beispiel, die sich aus mehreren Einzeljobs zusammensetzen.... und für weitere planmäßig durchzuführenden automatischen aufgaben.

    Ob du den 5 Uhr Crontabeintrag nutzt oder nicht spielt mit deiner Veränderung nur eine 2.Geige. Der Crontabeintrag ist ebenfalls Kontraproduktiv wie ich aber auch beschrieben habe. Ich nutze das varlog Script schon seit Jahren und habe kein Crontabeintrag..

    Deshalb habe ich jetzt unterhalb der Datumsvariable d die Variablenzuweisung systemlog=/media/HD_1/Log/system.log eingesetzt. Und im weiteren alle /home/varlog durch $systemlog ersetzt. Jetzt werden die Einträge korrekt in mein Log auf der Platte angehängt.

    Das ist schon besser :)

    Im ersten Posting schreibst Du:

    Code
    ACHTUNG: Auf diese Anpassung würde ich aber wenn möglich verzichten da dass kontraproduktiv wäre, das würde die SD wieder nur unnötig belasten!


    Ich nehme mal an, Du meinst damit, dass man besser auf beide Cronjobs verzichtet... also kein stop, kein start. Wäre es vielleicht eine Alternative, die flüchtigen /var/logs in tmpfs einfach auf die Platte zu sichern? Also in die Case-Abfrage hinter stop und vor * einfach auf z.B. Copy2HD einfügen. Dort wird das Paket aus tempfs einfach einmal täglich auf die Platte kopiert und man hat es zur Verfügung, falls man mal nach Problemen recherchieren muss. Das heisst, auf die SD-C würde ich dann gar nicht zurückkopieren. Würde das gehen?

    Kannst du machen wie Du willst - um so weniger auf der Systemplatte geschrieben wird um so besser (egal ob NAND-Flash oder was auch immer)

    Ich wollte es einfach nur nicht übertreiben und alle Eventualitäten beachten die irgendein User haben könnte, und 10 verschiedene Scripts oder Abfragen oder Variablen einbauen...

    Ich habe das einfach mal eingebaut und getestet... es funktioniert. Ich stells jetzt so ein, dass mir die crontab alle Dateien aus /var/log (tmpfs) einmal täglich um 5 Uhr auf die Platte sichert. Und mit dem Protokoll werde ich immer daran erinnert, dass ich die Größe im Auge behalten muss. Das bedeutet, auf Karte findet da für diese Sache dann nix mehr statt.... und die Sicherung habe ich trotzdem.

    Naja, wenn du die Logs unbedingt sichern willst.... Normalerweise brauch man das aber i.d.R. nicht wirklich :D
    Wenn das System um kurz vor 4 Uhr abschmiert dann sind die Logs eh futsch.

    Mit den Anpassungen für rsyslog kannst du das was ins Log geschrieben werden soll auch minimieren.
    Durch die Anpassungen für logrotate kannst du zudem einstellen das zB nur 2 Tage alte Logs behalten werden, auf ältere Logs hättest du dann auch kein Zugriff mehr aber es würde eben weniger Datenmüll rumliegen und somit auch weniger Platz verbrauchen ;)

    Es gibt also immer Vor- oder Nachteile, der eine bevorzugt dies der andere aber jenes..

  • Hi meigrafd

    Ich bin mir gerade ein wenig unsicher, ob das Script nicht ein ziemliches Integritätsproblem beinhaltet....vielleicht kannst Du ja aufklären, ob ich da einem Irrtum unterliege. Mir ist das heute morgen aufgefallen, als ich es mir für die Anpassung des zweiten Pi vorgenommen habe, der ja seine Log's auch auf Platte speichern soll. Und da muss ich ja Konflikte mit den Log's vom ersten vermeiden. Ich versuche das Problem mal zu erklären.

    Nehmen wir an, das Script wird am 3.Mai mit dem erstmaligen Aufruf "stop" initialisiert. "stop" bewirkt ja, dass der Inhalt der SD-Card /var/log/ nach $varlogSave kopiert wird.

    Das heisst, direkt danach haben beide Speicherorte den gleichen Stand.... und zwar den 3. Mai. Mit Aufruf "start" wird SDC/var/log zuerst noch mal kopiert, dann tempfs generiert und zum Schluss dann $varlogSave nach tempfs/var/log kopiert. Damit ist dann SDC/var/log erst mal aus dem Rennen und wird nicht weiter verwendet. So war es ja auch gewollt.

    Nehmen wir weiter an, der Rechner läuft jetzt über 2 Wochen durch, bis 20. Mai und varlog kriegt dann ein manuell ausgeführtes "stop". Er kopiert korrekter Weise zur Sicherung tempfs/var/log nach $varlogSave. Soweit ist alles gut.

    Jetzt kommt das erste Problem. Meiner Meinung nach lebt tempfs nach dem "stop" weiter, weil tempfs von irgendwelchen logbuchschreibenden Prozessen blockiert wird. Es wird imho deshalb nicht unmounted. Insofern ist varlog eigentlich gar nicht gestoppt, er hat nur einmal die Logs kopiert und macht dann weiter. Der letzte Befehl umount -f /var/log/ im Stop-Code-Block bleibt imho immer erfolglos.

    Und nun das zweite Problem. Und das besteht bei einem echten shutdown. Und das ist m. E. sogar gravierender. Der Stand der tempfs/var/log ist ja vor dem shutdown aktuell der 20.Mai. Ich erinnere, dass SDC/var/log ja während der ganzen quasi inaktiv war und unverändert immer noch auf dem Stand 3. Mai steht.

    Und beim nächsten "start" macht das Script folgendes: Es kopiert als allererstes SDC/var/log/ nach $varlogSave (und damit den Stand vom 3. Mai), generiert tempfs und kopiert $varlogSave zurück nach tempfs. Damit sind alle Logbuch-Einträge zwischen dem 3. und dem 20. verloren. Nach meiner Meinung wird eigentlich bei jedem Start tempfs/var/log immer wieder zurück auf den Stand 3. Mai gesetzt werden.

    Ich habe jetzt in meinem Script die Logik insofern geändert, dass ich generell auf Platte ein Backup der Log's mache und tempfs nur von diesem Backup generiere. Liege ich mit meiner Überlegung jetzt total daneben?

    In meinem Stop-Code-Block besteht allerdings das gleiche Problem. Mit den letzten beiden Zeilen wärs korrekt, aber das schlägt fehl, weil eben der umount fehlschlägt. Ich verzichte deshalb im Moment ganz darauf, die Log's auf der SDC zu aktualisieren.... mir reichts, wenn ich das auf der Platte sehen kann.

    Einmal editiert, zuletzt von WinterUnit16246 (5. September 2014 um 15:48)


  • Nehmen wir an, das Script wird am 3.Mai mit dem erstmaligen Aufruf "stop" initialisiert. "stop" bewirkt ja, dass der Inhalt der SD-Card /var/log/ nach $varlogSave kopiert wird.

    Das heisst, direkt danach haben beide Speicherorte den gleichen Stand.... und zwar den 3. Mai. Mit Aufruf "start" wird SDC/var/log zuerst noch mal kopiert, dann tempfs generiert und zum Schluss dann $varlogSave nach tempfs/var/log kopiert. Damit ist dann SDC/var/log erst mal aus dem Rennen und wird nicht weiter verwendet. So war es ja auch gewollt.

    Nehmen wir weiter an, der Rechner läuft jetzt über 2 Wochen durch, bis 20. Mai und varlog kriegt dann ein manuell ausgeführtes "stop". Er kopiert korrekter Weise zur Sicherung tempfs/var/log nach $varlogSave. Soweit ist alles gut.

    Jetzt kommt das erste Problem. Meiner Meinung nach lebt tempfs nach dem "stop" weiter, weil tempfs von irgendwelchen logbuchschreibenden Prozessen blockiert wird. Es wird imho deshalb nicht unmounted. Insofern ist varlog eigentlich gar nicht gestoppt, er hat nur einmal die Logs kopiert und macht dann weiter. Der letzte Befehl umount -f /var/log/ im Stop-Code-Block bleibt imho immer erfolglos.

    Das stimmt, ist aber auch nicht weiter tragisch da "stop" eigentlich nur genutzt werden soll wenn das System tatsächlich herunter fährt. Ein manuelles abschalten ist also eigentlich gar nicht vorgesehen.
    Ein vorheriges stoppen der Dienste die in /var/log/ schreiben und nach "stop" von varlog diese wieder zu starten, wäre ein Ansatz für solch einen manuellen Eingriff.
    Aber wie gesagt ist das auch gar nicht vorgesehen oder beabsichtigt. Man startet sein System, /var/log/ wird ausgelagert, und in 2 Jahren rebootet man mal, dann wird es durch den shutdown-Prozess gestoppt und beim system start auch wieder gestartet.... mehr muss nich sein ;)


    Und nun das zweite Problem. Und das besteht bei einem echten shutdown. Und das ist m. E. sogar gravierender. Der Stand der tempfs/var/log ist ja vor dem shutdown aktuell der 20.Mai. Ich erinnere, dass SDC/var/log ja während der ganzen quasi inaktiv war und unverändert immer noch auf dem Stand 3. Mai steht.

    Und beim nächsten "start" macht das Script folgendes: Es kopiert als allererstes SDC/var/log/ nach $varlogSave (und damit den Stand vom 3. Mai), generiert tempfs und kopiert $varlogSave zurück nach tempfs. Damit sind alle Logbuch-Einträge zwischen dem 3. und dem 20. verloren. Nach meiner Meinung wird eigentlich bei jedem Start tempfs/var/log immer wieder zurück auf den Stand 3. Mai gesetzt werden.

    Nein, das siehst du falsch.
    Es wird nicht nur einfach " cp " genutzt sondern " cp -Rup ", was bewirkt dass nur neuere Dateien/Verzeichnisse kopiert werden.

    p kopiert mode,ownership,timestamps mit also Dateirechte, Besitzer und Zeit/Datum der Datei.
    u steht für update und sorgt für besagtes "nur neuer als". Es wird also nur das kopiert wo die Quelle neuer ist als das Ziel.

    Siehe dazu man cp


    Dein Script hat einen Fehler und zwar das Setzen von $HDBackupDir ...
    Es gibt zu dem Zeitpunkt noch keine Variable die mit $HDBackupDir abgerufen werden kann. Die Zeile müsste also HDBackupDir=/media/HD_1/Log/var.log/ lauten, nicht $HDBackupDir=/media/HD_1/Log/var.log/ ;)


  • Nein, das siehst du falsch.
    Es wird nicht nur einfach " cp " genutzt sondern " cp -Rup ", was bewirkt dass nur neuere Dateien/Verzeichnisse kopiert werden.

    Ja, war mir klar.... das hatte ich vorher natürlich nachgelesen. Die Frage ist: Welchen tatsächlichen Stand hat die Quelle? Und meiner Meinung nach (bezogen auf mein Datumsbeispiel) eben den 3. Mai, weil das vorher NIE aktualisiert wurde. Sobald Du zu irgendeinem späteren Zeitpunkt im Start-Code-Block erneut von der SD-Card kopierst, was eben bei jedem Neu-Start geschieht, kopierst Du immer einen Uralt-Stand.... zwar mit der Angabe "nur neue", aber die gibts ja nicht, weil diese Quelle NIE aktualisiert wurde.

    Zeile 4 des Start-Code-Blocks kopiert mit cp -Rpu /var/log/* $varlogSave immer die SDC-Logs, die aber NIE aktualisiert werden, weil sie danach sofort abgeklemmt werden. Denk mal drüber nach.... ;) ... Zeig mir eine Code-Zeile, wo die SDC-var/logs auf aktuellem Stand gebracht werden.... die gibts nämlich nicht, weil der umount tempfs wegen offener Zugriffe nicht funktioniert.

    Zitat

    Dein Script hat einen Fehler und zwar das Setzen von $HDBackupDir ...


    Oh, danke, ein Flüchtigkeitsfehler.... beim Kopieren.... :thumbs1:

    Gruß, Thomas

    Einmal editiert, zuletzt von WinterUnit16246 (24. August 2014 um 18:16)

Jetzt mitmachen!

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