/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

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

Ja du hast recht.
Es sind 250 MB

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

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.

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:

pi@Raspobot:/etc $ sudo update-rc.d varlog start 01 2 3 4 5 . stop 99 0 1 6 .
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

hehe danke für deine Antwort, jedoch funktionierte es wohl auch mit der alten Anleitung auch wenn der da an der stelle gemekert hatte.

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.

Quote from Zappelmann

Code

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

pi@Raspobot:/etc $ sudo update-rc.d varlog start 01 2 3 4 5 . stop 99 0 1 6 .
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

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

Hallo meigrafd,

danke für deine Hilfe, da ich aber noch eine Frage habe und ich dein Tutorials nicht zumüllen möchte hab ich hier

http://www.forum-raspberrypi.d…-optimierungen-bezgl-logs

einen neuen Thread aufgemacht.

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

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

/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