Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Ein Plugin installiert eine Drittapplikation (z.B. FHEM). Die Drittapplikation loggt sehr viel in die RAM-Disk und räumt das Log nie auf.
  • Ein Benutzer installiert selbst eine Applikation. Diese Applikation loggt in die RAM-Disk und räumt nie auf.
  • Dateien wurden zwar gelöscht, aber von der Applikation noch nicht freigegeben

Schnelle Abhilfe

Schnelle Abhilfe bei diesem Fehler schafft ein Reboot von LoxBerry. Die RAM-Disk wird durch den Reboot geleert, sodass danach wieder alles funktioniert.

...

Hier sieht man, dass das daemon.log und daemon.log.1 sehr groß sind. Diese Logs würden normalerweise vom Dienst logrotate geleert, das hat aber (wahrscheinlich weil die RAM-Disk bereits zu voll war) nicht mehr funktioniert.

Gelöschte, offene Dateien aufspüren

Linux hat die Eigenheit, dass Dateien gelöscht werden können (und sie sind dann auch nicht mehr sichtbar), wenn aber die gelöschte Datei noch von einem Programm genutzt wird, bleibt die Datei noch vorhanden. Erst, wenn diese Applikation die Datei schließt, wird sie tatsächlich gelöscht.

Verwende diesen Befehl, um offene, gelöschte Dateien zu finden:

Code Block
languagebash
lsof -nP | grep '(deleted)'

Es erscheint eine Liste aller offenen, gelöschten Dateien:

Image Added

Die vorletzte Zahl ist der belegte Speicher in Bytes (im Bild hat das gelöschte mosquitto.log 2146011 Bytes = ~2 MB). Die erste Spalte ist der Prozess, die letzte Spalte der Pfad der Datei. Damit kannst du meist auf die Applikation, den Dienst oder das Plugin schließen.

Um die Datei endgültig zu entfernen, musst du den entsprechenden Prozess stoppen.  

Fehler korrigieren

Mit den Tipps oben bist du jetzt soweit, dass du weißt, wer der Verursacher ist. Nun gilt es, ein erneutes Auftreten zu verhindern:

...

Page properties
hiddentrue


Verwandte Vorgänge