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

Fragen, Anregungen usw bitte im Diskussions-Thread stellen!

[hr]
[hr]

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.

[hr]

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
  
  
  Bash

  #!/bin/bash
  ### BEGIN INIT INFO
  # Provides:          varlog
  # Required-Start:    $local_fs
  # Required-Stop:     $local_fs
  # X-Start-Before:    $syslog
  # X-Stop-After:      $syslog
  # Default-Start:     2 3 4 5
  # Default-Stop:      0 1 6
  # Short-Description: Start/stop tmpfs logfile saving
  ### END INIT INFO
  #
  # varlog        This init.d script is used to start tmpfs logfile saving and restore.
  #
  
  
  varlogSave=/var/save.log/
  
  
  [ ! -d $varlogSave ] && mkdir -p $varlogSave
  PATH=/sbin:/usr/sbin:/bin:/usr/bin
  
  
  function _save() {
      if [ -x "$(which rsync)" ]; then
          rsync -a --delete /var/log/ ${varlogSave}
      else
          cp -Rpu /var/log/* $varlogSave
      fi
      sync
  }
  
  
  case $1 in
      start)
          echo "*** Starting tmpfs file restore: varlog."
          if [ -z "$(grep /var/log /proc/mounts)" ]; then
              echo "*** mounting /var/log"
              _save
              varlogsize=$(grep /var/log /etc/fstab|awk {'print $4'}|cut -d"=" -f2)
              [ -z "$varlogsize" ] && varlogsize="70M"
              mount -t tmpfs tmpfs /var/log -o defaults,size=$varlogsize
              chmod 775 /var/log
          fi
          cp -Rpu ${varlogSave}* /var/log/
      ;;
      stop)
          echo "*** Stopping tmpfs file saving: varlog."
          _save
          umount -f /var/log/
      ;;
      *)
          echo "Usage: $0 {start|stop}"
          exit 1
      ;;
  esac
  
  
  exit 0

  Display More

  
  

  "alt"

  
  

  Bash

  #!/bin/bash
  ### BEGIN INIT INFO
  # Provides:          varlog
  # Required-Start:    $local_fs
  # Required-Stop:     $local_fs
  # X-Start-Before:    $syslog
  # X-Stop-After:      $syslog
  # Default-Start:     2 3 4 5
  # Default-Stop:      0 1 6
  # Short-Description: Start/stop logfile saving
  ### END INIT INFO
  #
  # varlog		This init.d script is used to start logfile saving and restore.
  #
  
  
  varlogSave=/var/save.log/
  [ ! -d $varlogSave ] && mkdir -p $varlogSave
  
  
  PATH=/sbin:/usr/sbin:/bin:/usr/bin
  
  
  case $1 in
  	start)
  		echo "*** Starting tmpfs file restore: varlog."
  		if [ -z "$(grep /var/log /proc/mounts)" ]; then
  			echo "*** mounting /var/log"
  			cp -Rpu /var/log/* $varlogSave
  			varlogsize=$(grep /var/log /etc/fstab|awk {'print $4'}|cut -d"=" -f2)
  			[ -z "$varlogsize" ] && varlogsize="70M"
  			mount -t tmpfs tmpfs /var/log -o defaults,size=$varlogsize
  			chmod 755 /var/log
  		fi
  		cp -Rpu ${varlogSave}* /var/log/
  	;;
  	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/
  	;;
  	*)
  		echo "Usage: $0 {start|stop}"
  	;;
  esac
  
  
  exit 0

  Display More

  
  

  
  

• 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:

/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)

[hr]

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

#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

#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!

[hr]

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:

  Display Spoiler

  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 <

[hr]
[hr]

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:

#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

[hr]

Links:

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

[hr]
[hr]

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

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

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...

Quote from framp

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

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

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

Quote from framp

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

Quote from framp

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

Quote from framp

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...

Quote from framp

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

Quote from framp

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

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?

Quote from Superhobel

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

$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

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:

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 bzw müsste der Befehl eben auch anschließend wieder mit start in crontab stehen:

#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..

Quote from ThomasL

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.

Quote from ThomasL

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.

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..

Quote from ThomasL

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

Quote from ThomasL

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...

Quote from ThomasL

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
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..

Quote from ThomasL

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.

Display More

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

Quote from ThomasL

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/