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

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

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

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

    Gruß Nea

    M.f.G.

    Andreas

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

    Begeistert vom DoorPi Projekt!

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

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

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

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

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

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

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

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

  • Hallo meigrafd,

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

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

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

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

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

    Oder hab ich da irgendwo einen Denkfehler?

    Gruß,
    FeinerFug

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

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

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

    Gruß
    Georg

    Gruß Georg

    ... und sie leben doch :cool:

    Raspberry Pi B+, Raspberry Pi2, Raspberry Pi3


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

    Sollte es nicht eher MB statt KB lauten? ;)

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

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

    Gruß Georg

    ... und sie leben doch :cool:

    Raspberry Pi B+, Raspberry Pi2, Raspberry Pi3

  • Hi meigrafd,

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

    Code
    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

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

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


    vielen Dank

    MFG

    Zappelmann

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

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


    varlog ab Jessie:

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

    Code
    sudo update-rc.d varlog disable

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

    Code
    sudo nano /etc/systemd/system/varlog.service
    &quot;alt&quot;

    Und nun noch diesen Dienst einschalten:

    Code
    sudo systemctl enable varlog

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

    Code
    sudo systemctl status varlog

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

    Code
    sudo systemd-analyze plot > irgendwas.svg

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

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

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

    Code
    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

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

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


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

    Vielen Dank für euer Verständnis.

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

    meigrafd: Was hälst Du davon

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

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

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

  • 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

    lx2
    6. Oktober 2016 um 18:58

    einen neuen Thread aufgemacht.

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

    Einmal editiert, zuletzt von WinterUnit16246 (7. Oktober 2016 um 12:00)

  • Selbstverständlich


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

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

    • Mein "Upgrade" hat prinzipiell die gleiche Funktion, wie das Original
    • Eine Änderung ergibt sich dadurch, dass ich die SD-Card ausser beim eher seltenen systemctl->Shutdown/Reboot NICHT mit Log-Daten beschreibe. Dieser Schreibvorgang ist allerdings für den Restore beim nächsten Boot zwingend erforderlich. Eine externes Storage funktioniert hier nicht, da der Restore zu einem Zeitpunkt stattfindet, zudem remote-fs.target noch nicht angezogen wurde und evtl. auch lokal zu verbindende Laufwerke (via fstab,mount-units,rc-local) noch nicht gemounted sind
    • systemd-journald läuft bei mir (mit der Einstellung "Storage=persistent") während der Boot-Phase in tmpfs->/run und wird zu gegebener Zeit (after local-fs.target) nach /var/log geflusht (siehe systemd-journal-flush.service).
    • Die Unit varlog.service ist VOR dem Flush aktiv. Das bedeutet, wenn geflusht wird, ist /var/log bereits erfolgreich nach tmpfs redirected/gemounted.
    • Die gewünschten (aber bisher von mir nie genutzten) Sicherheitskopien werden periodisch auf einem externen Speicher (USB-HD, USB-Stick, NAS) angelegt. Gegebenenfalls muss dazu im Script ein/der Pfad angepasst werden.
    • Ich verzichte im Script auf Plausibilitätsprüfungen, weil alles so gut wie statisch abläuft... variabilität oder mal-so-mal-so gibts hier nicht
    • Ich empfehle /tmp unbedingt ebenfalls nach tmpfs zu mounten (s.u.)
    • rsyslog ist unter Jessie ein Zombie und erzeugt heute keine eigenen Daten mehr. Systemd-journald ist das primäre Journaling-System und versorgt zusätzlich und auf Wunsch auch noch rsyslog. Damit wird explizit für rsyslog völlig überflüssiger redundanter Datenschrott angelegt. Deshalb empfehle ich rsyslog zu entfernen (s.u. und Hinweis beachten).
    • Ich empfehle VOR der Inbetriebnahme zuerst alles einmal bis unten zu lesen und sich einen Überblick über die notwendigen/gewünschten Schritte zu verschaffen. Diese Anleitung ist nicht in erforderlicher Reihenfolge aufgebaut, einzelne Parts können, müssen aber nicht..... also unbedingt Reihenfolge beachten!


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

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

    Das Bash-Script:

    Code
    nano /usr/local/bin/varlog

    Inbetriebnahme mit folgenden Schritten (die Reihenfolge unbedingt einhalten):

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

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

    Code
    journalctl -b | grep "varlog\|journal" -i
    Spoiler anzeigen

    Oct 09 20:21:30 raspi3 systemd-journal[101]: Runtime journal is using 4.0M (max allowed 21.7M, trying to leave 32.6M free of 213.2M available → current limit 21.7M).
    Oct 09 20:21:30 raspi3 systemd-journal[101]: Runtime journal is using 4.0M (max allowed 21.7M, trying to leave 32.6M free of 213.2M available → current limit 21.7M).
    Oct 09 20:21:30 raspi3 systemd[1]: Starting Journal Socket (/dev/log).
    Oct 09 20:21:30 raspi3 systemd[1]: Listening on Journal Socket (/dev/log).
    Oct 09 20:21:30 raspi3 systemd[1]: Starting Journal Socket.
    Oct 09 20:21:30 raspi3 systemd[1]: Listening on Journal Socket.
    Oct 09 20:21:30 raspi3 systemd[1]: Starting thlu:varlog.service: Redirect /var/log to tmpfs...
    Oct 09 20:21:30 raspi3 systemd[1]: Starting Journal Service...
    Oct 09 20:21:30 raspi3 systemd[1]: Started Journal Service.
    Oct 09 20:21:30 raspi3 systemd-journal[101]: Journal started
    Oct 09 20:21:31 raspi3 systemd[1]: Started thlu:varlog.service: Redirect /var/log to tmpfs.
    Oct 09 20:21:34 raspi3 systemd[1]: Starting Trigger Flushing of Journal to Persistent Storage...
    Oct 09 20:21:35 raspi3 systemd-journal[101]: Permanent journal is using 20.0M (max allowed 8.0M, trying to leave 10.5M free of 49.8M available → current limit 20.0M).
    Oct 09 20:21:36 raspi3 systemd-journal[101]: Time spent on flushing to /var is 757.266ms for 314 entries.
    Oct 09 20:21:35 raspi3 systemd[1]: Started Trigger Flushing of Journal to Persistent Storage.

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

    Code
    journalctl -b -1
    Spoiler anzeigen

    -- Logs begin at Fri 2016-09-23 03:53:43 UTC, end at Sun 2016-10-09 20:17:58 UTC. --
    Oct 09 20:11:17 raspi3 systemd-journal[101]: Runtime journal is using 4.0M (max allowed 21.7M, trying to leave 32.6M free of 213.2M available → current limit 21.7M).
    Oct 09 20:11:17 raspi3 systemd-journal[101]: Runtime journal is using 4.0M (max allowed 21.7M, trying to leave 32.6M free of 213.2M available → current limit 21.7M).
    Oct 09 20:11:17 raspi3 kernel: Booting Linux on physical CPU 0x0
    Oct 09 20:11:17 raspi3 kernel: Initializing cgroup subsys cpuset
    Oct 09 20:11:17 raspi3 kernel: Initializing cgroup subsys cpu
    Oct 09 20:11:17 raspi3 kernel: Initializing cgroup subsys cpuacct
    ::::
    ::::
    Oct 09 20:17:29 raspi3 systemd[1]: Stopped target Local File Systems.
    Oct 09 20:17:29 raspi3 systemd[1]: Unmounting /boot...
    Oct 09 20:17:29 raspi3 systemd[1]: Stopping thlu:varlog.service: Redirect /var/log to tmpfs...
    Oct 09 20:17:29 raspi3 systemd[1]: Stopped Load/Save Random Seed.
    Oct 09 20:17:29 raspi3 umount[857]: umount: /var/log: target is busy
    Oct 09 20:17:29 raspi3 umount[857]: (In some cases useful info about processes that
    Oct 09 20:17:29 raspi3 umount[857]: use the device is found by lsof(8) or fuser(1).)
    Oct 09 20:17:29 raspi3 systemd[1]: var-log.mount mount process exited, code=exited status=32
    Oct 09 20:17:29 raspi3 systemd[1]: Failed unmounting /var/log.
    Oct 09 20:17:29 raspi3 systemd[1]: Unmounted /boot.
    Oct 09 20:17:29 raspi3 systemd[1]: Starting Unmount All Filesystems.
    Oct 09 20:17:29 raspi3 systemd[1]: Reached target Unmount All Filesystems.
    Oct 09 20:17:29 raspi3 systemd[1]: Stopping Local File Systems (Pre).
    Oct 09 20:17:29 raspi3 systemd[1]: Stopped target Local File Systems (Pre).
    Oct 09 20:17:29 raspi3 systemd[1]: Stopping Create Static Device Nodes in /dev...
    Oct 09 20:17:29 raspi3 systemd[1]: Stopped Create Static Device Nodes in /dev.
    Oct 09 20:17:29 raspi3 systemd[1]: Stopping Remount Root and Kernel File Systems...
    Oct 09 20:17:29 raspi3 systemd[1]: Stopped Remount Root and Kernel File Systems.
    lines 586-637/637 (END).

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

    Code
    nano /etc/systemd/journald.conf


    Unten am Ende anfügen:

    Code
    Storage=persistent
    SystemMaxUse=20M
    ForwardToSyslog=no

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

    Code
    mkdir -p /var/log/journal/tmp
    systemd-tmpfiles --create --prefix /var/log/journal
    
    
    adduser thomas systemd-journal
    systemctl restart systemd-journald
    
    
    apt-get purge --remove rsyslog

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

    Code
    crontab -e
    Code
    0 2 * * * /usr/local/bin/varlog sik
    0 2,14 * * * /usr/local/bin/varlog sik
    0 2,10,18 * * * /usr/local/bin/varlog sik
    0 2,8,14,20 * * * /usr/local/bin/varlog sik

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

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

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

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

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

    Und noch aktivieren:

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

    Einmal editiert, zuletzt von WinterUnit16246 (11. März 2017 um 12:22)

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

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


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

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

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

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

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

Jetzt mitmachen!

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