ramlog voll

[Musicman]

Hi

Eben hat ein Skript hat nicht mehr funktioniert und als ich per http auf meinen loxberry zugreifen wollte, gab es diese Fehlermeldung hier:

HTML::Template->new() : can't mkdir /tmp/templatecache/1e (file_cache => 1): No space left on device at /opt/loxberry/webfrontend/htmlauth/system/power.cgi line 71.

Danach habe ich mich per ssh verbunden. df -h liefert 100% Benutzung von /opt/loxberry/log/ramlog

Ich habe nun einen Neustart per ssh ausgelöst (über die Web Oberfläche ging das nicht mehr, die obige ehlermeldung erscheint) gemacht und nun ist die Nutzung wieder bei 0%. Unabhängig davon, wieso der Logspeicher gefüllt wurde - kann man die alten logs automatisch löschen lassen?
Eine Erhöhung des Speichers auf 415MB würde das Problem ja nur herauszögern.

Ich habe LoxBerry v2.0.1.3 und einen Raspberry Pi 3 Model B.
Diese Meldung erschien im Selfcheck Status:

[B]28.03.2020 08:13:[/B] Healthcheck reports 1 errors. Please run Healthcheck for details.
Current errors:
/opt/loxberry/log/system_tmpfs is below limit of 5% discspace (AVAL 0.0B/SIZE 386.0MB). Please reboot your LoxBerry.

[svethi]

Die Logs werden automatisch gelöscht. Die Frage ist eher was Du da alles Logst, damit das so volllaufen konnte

[Musicman]

Offensichtlich werden die Logs nicht automatisch gelöscht...
Ich habe kürzlich ein FHEM Skript installiert, ich nehme an das FHEM.log wird der Grund dafür sein. Kann es sein, dass das FHEM log immer weiter wächst und das Problem dann auftritt?
Im Skript wird tatsächlich laufend geloggt.
Da ich eben den Neustart gemacht habe, muss ich das Verhalten erst wieder beobachten.

[svethi]

Bei Dingen, die nicht mit dem Loxberry ausgeliefert werden und nicht über das Loxberry System geloggt werden, kann das schon sein. Jede Datei muss mehr oder weniger konfiguriert sein. Wurde da ein Logfile angelegt, das nicht zum System gehört, macht dann auch logrotate nichts damit. Das wäre dann Dein Part darauf zu achten.

[Prof.Mobilux]

Wo speichert FHEM das log hin? Geht das nach /var/log? Wir haben da eventuell einen Bug beim Aufräumen der System-Logs in /var/log...

[svethi]

Musicman kannst Du mal gucken was für Eigentümer die fhem.log in /opt/loxberry/log/ramlog/log/plugins/fhem/ hat?

[Musicman]

Danke, svethi !
Sieht gut aus:

-rw-r--r-- 1 loxberry loxberry    42 Mar 28 17:59 fhem.log

[svethi]

Das passt.

[phil84]

Hallo,

ich habe dasselbe Problem. Ca. alle 14 Tage hängt sich dann der Loxberry auf. Die Wetterdaten usw. werden nicht mehr übermittelt und über den Explorer ist er nicht mehr erreichbar. Er ist jedoch noch im Netzwerk angemeldet und ich kann auch meine Dachfenster über das FHEM Plugin (Weitergabe der Befehle von Loxone --> Loxberry) ansteuern. Anbei mal ein Screenshot des RAM logs. Ich weiß nicht woher es kommt. Ich habe in FHEM mal das Logfile angeschau und es ist nicht besonders viel drin. Aber außer FHEM nutze ich eigentlich fast nur Weather4Lox, MQTT Gateway und WIFI Scanner. Ist sind zwar noch ein paar andere Plugins installiert, aber die nutze ich eigentlich nicht.

Kann ich die Logs in Loxberry automatisch löschen lassen alle x Tage? Oder zumindest das von WIFI Scanner. Das Log ist ziemlich voll....

[phil84]

Guten Morgen :-)

[phil84]

@svethi: Hast du eine Idee?

[phil84]

Hat jemand eine Idee woran das liegt?

[Musicman]

Okay, da gibts tatsächlich einen Fehler, den ich bereits gefixt habe. Solltest daher ein Auge drauf haben, bis es das Release gibt.

svethi: Kannst du mir biite beschreiben was ich ändern muss bis das Release kommt? Es ist sehr mühsam wenn immer wieder das Log voll ist und ich den Loxberry manuell über ssh neu starten muss.

[svethi]

Kannst auf die Entwicklerversion stellen und updaten, da ist das schon gefixt

[svethi]

😳

[Musicman]

Ich habe die Konfiguration nun gemacht und Loxberry neu gestartet. Nun kann ich FHEM (Desktop) jedoch nicht mehr aufrufen - die Seite wird nicht geladen. Gemäss webfrontend ist Fhem am laufen (PID: 745). Hast du eine Idee was schief gelaufen ist?

[Musicman]

fhem konnte ich über das webfrontend weder stoppen noch neu starten. Ich habe den prozess über ssh beendet (kill -9 745), und danach über das webfrontend fhem neu gestartet. Nun läuft es wieder

[Musicman]

Hi svethi

Ich bin damals von der Entwicklerversion wieder zurück auf Release gegangen, weil fhem durch die Änderungen nie richtig funktioniert hat. Ich vermute, es haben Pfade geändert und noch weiteres?

Jedenfalls habe ich das Ramlog Problem dadurch immer noch. Gibt es bald ein offizielles Release bei fhem inkl. Updatebeschreibung? Einfach nur Updaten geht leider nicht, danach funktionierte es bei mir nicht mehr.

Gruss

[svethi]

Meines Wissens hat sich am Loxberry zwischen dem Release und dem Master seinerzeit nicht viel geändert. Was das Problem mit dem fhem ist kann ich Dir nicht sagen. Wenn es ein Loxberry Update gibt, dann wird das auch über das Updatetool ausgerollt. Wenn es dabei Probleme gibt, müsste man sich das im Detail ansehen. Die Erfahrung hat bisher immer gezeigt, dass es bei Problemen stets an irgendwelcher selbst installierten weiteren Software lag, oder an Datei, die in falsche Verzeichnisse gelegt wurden. Derartige Sachen muss man sich dann speziell ansehen. Da gibt es kein Standardverfahren.
Da der Loxberry derzeit in Bezug auf die Config Dateinen umgebaut wird und jeder diverse andere Projekte hat, ist kein neues Releasedatum absehbar.

[Christian Fenzl]

Ich glaub, es geht um Master/Release vom FHEM Plugin. Ich kann mich erinnern, dass Michael bei einer neuen Version die FHEM-Installation in die Standard-Pfade von FHEM verlegt hat.

Musicman Vielleicht schilderst du nochmal kurz, was aktuell das Problem ist, weil in den Tiefen des Threads ist das konkrete Problem „verloren“ gegangen.

lg, Christian

[svethi]

Nein, es ging darum, dass er die ramdrive Probleme hatte. Ich hatte die Änderung gepusht und gesagt, er soll mal den Entwicklungsstand installieren. Das hat er gemacht und meinte, dass danach fhem nicht mehr gelaufen wäre. Ich sehe da aber keine Zusammenhänge

[Musicman]

Ich weiss nicht genau, wieso fhem nach dem Update nicht mehr funktionierte. Ich bin auch kein fhem Spezialist, ich nutze fhem für die Steuerung meiner Lüftung gemäss dem Beitrag von hme0354 hier: https://www.loxforum.com/forum/faqs-...ge2#post239736
Im Prinzip wird über fhem ein python Skript ausgeführt, der Befehl dazu bei mir lautet:
define FHEMStart notify global:INITIALIZED.* {system("/opt/loxberry/webfronted/legacy/fhem/scripts/ccfhem.py --ip 192.168.1.220 &")}

Ich sehe grad, dass bei mir noch Version 0.4.2 läuft, ich dachte damals hätte ich 0.6.1 installiert und die Lüftungs Kommunikation lief nicht mehr. Spricht aus eurer Sicht etwas gegen ein Update? Ist in V0.6.1 das Problem gelöst oder liegt es gar nicht am Plugin sondern am Loxberry OS?

[ertlweber]

HI zusammen - gleiches Problem hab ich auch immer wieder
Aber kein FHEM am laufen.
eigenartig

vor neustart


nach neustart:

[Musicman]

Also ich muss meinen Loxberry immer nach ca. 2 Wochen manuell neu starten. Das Problem ist, dass nicht einmal der Mailer mehr funktioniert und ich so nicht vom Loxberry benachrichtigt werde. Ich überwache deswegen die Funktion meiner Plugins über Loxone, so dass ich eine Benachrichtigung bekomme und dann Loxberry über ssh neu starten kann. Über die Weboberfläche neu starten funktioniert nicht mehr, weil der Speicher voll ist. Das Dialogfenster wird nicht mehr geöffnet.
Falls ich irgendwelche Infos dazu sammeln kann, bitte sagt mir was.
Es kann gut sein, dass es nicht an fhem liegt.

[Christian Fenzl]

https://www.loxwiki.eu/display/LOXBERRY/RAM+Disk+voll+-+No+space+left+on+device

[Musicman]

Ich verstehe das nicht ganz. Bei mir wächst /dev/zram0 immer weiter an, bis der Fehler gemäss Beitrag 1 auftritt.
Wenn ich jedoch du -h /opt/loxberry/log/ramlog ausführe, dann scheint dort nur 7.7 MB zu sein. Ich habe nicht herausgefunden, wo die restlichen 170MB sind.
Hier einige Outputs vom Terminal (die jeweiligen Zeilen mit den Ausgaben der Unterverzeichnisse habe ich weggelassen):

root@loxberry:~# df -h
/dev/zram0 386M 179M 179M 53% /opt/loxberry/log/ramlog

root@loxberry:~# du -h /opt/loxberry/log/ramlog
7.7M /opt/loxberry/log/ramlog

root@loxberry:~# du -h /opt/loxberry/log
14M /opt/loxberry/log

root@loxberry:~# du -h /tmp
72K /tmp

root@loxberry:~# du -h /var/log
2.6M /var/log

Scheinbar sieht alles gut aus, aber zram wächst stetig bis 100%...

[Musicman]

Ich habe versucht, alle mounts mit --bind aufzuspüren. Jedoch sehe ich ich immer noch nicht, wieso zram0 immer anwächst. Funktioniert evtl. etwas nicht mit dem leeren von zram', so dass die log Dateien dort nie wieder gelöscht werden?

Hier der Output von findmnt (ich habe zwei mounts von meinem NAS zusätzlich):

loxberry@loxberry:~/sbin $ findmnt | grep "\["
├─/var/log /dev/zram0[/var/log] ext4 rw,nosuid,nodev,relatime
├─/tmp /dev/zram0[/tmp] ext4 rw,nosuid,nodev,relatime
├─/var/tmp /dev/zram0[/var/tmp] ext4 rw,nosuid,nodev,relatime
├─/opt/loxberry/log/plugins /dev/zram0[/log/plugins] ext4 rw,nosuid,nodev,relatime
├─/opt/loxberry/log/system_tmpfs /dev/zram0[/log/system_tmpfs] ext4 rw,nosuid,nodev,relatime
├─/backup //192.168.1.10/Sicherungen/Loxone/loxberrybackup[/Loxone/loxberrybackup] cifs rw,relatime,vers=2.0,cache=strict,username=loxberr y,uid=1001,forceuid,gid=1001,forcegid,addr=192.168 .1.10,file_mode=0755,dir_mode=0755,soft,nounix,ser verino,mapposix,rsize=65536,wsize=65536,echo_inter val=60,actimeo=1
├─/opt/loxberry/data/plugins/miniserverbackup/backup_storage //192.168.1.10/Sicherungen/Loxone/miniserverbackup[/Loxone/miniserverbackup] cifs rw,relatime,vers=2.0,cache=strict,username=loxberr y,uid=1001,forceuid,gid=1001,forcegid,addr=192.168 .1.10,file_mode=0755,dir_mode=0755,soft,nounix,ser verino,mapposix,rsize=65536,wsize=65536,echo_inter val=60,actimeo=1