Hallo Zusammen,
ich habe FHEM auf einem RasPi3B seit längerem am Laufen
und verwende ein tägliches Logfile, heißt
attr global logfile ./log/fhem-%Y-%m-%d.log
Seit zwei Tagen wird jedoch keine neues File mehr erzeugt.
Nach komplettem Neustart (reboot RasPi) werden zumindest wieder die Logs der Devices gemacht,
aber weiterhin kein Logfile.
Hat jemand eine Idee?
Ich habe den Speicher in Verdacht,
aber free -m sagt das noch Speicher verfügbar ist.
Grüße
Hallo,
wenn Du nur den RAM Speicher siehst hilft das nicht weiter. Was sagt denn die Abfrage des Datei Speichers? Im selben Paket in dem free bereit gestellt wird sollte sich auch htop befinden. Das zeigt Dir mehr an.
Auf Grund Deiner Beschreibung gehe ich von: Datei Speicher ist voll, aus. Bei einem Neustart werden die Swap Dateien geleert. Das führt zunächst zu freiem Datei Speicher, der dann durch die Swap Dateien wieder aufgebraucht wird.
Grüße Jörg
Das globale Attribut "logfile" repräsentiert ja nicht das Logfile selbst.
Ist denn das device "Logfile" selbst noch in Deinem FHEM vorhanden?
Was steht im device "global" in den Internals unter "currentlogfile"
Hast Du mal versucht, FHEM manuell von der Konsole zu starten, um zu sehen, ob dabei Fehler auftreten?
Zitat von: betateilchen am 04 Februar 2026, 09:06:39Das globale Attribut "logfile" repräsentiert ja nicht das Logfile selbst.
Ist denn das device "Logfile" selbst noch in Deinem FHEM vorhanden?
Was steht im device "global" in den Internals unter "currentlogfile"
Hast Du mal versucht, FHEM manuell von der Konsole zu starten, um zu sehen, ob dabei Fehler auftreten?
das Logfile ist da
currentlogfile ./log/fhem-2026-02-04.logaber in der Anzeige sehe ich nur Einträge von Vorgestern (02.02.2026...)
Bin aktuell offline, aber Heute Morgen war das File fhem-2026-02-04.log nicht da
Danke und Grüße
Knut
Zitat von: KNUT345 am 04 Februar 2026, 09:55:13das Logfile ist da
Das ist erstmal nur eine Behauptung, mehr nicht.
Schau bitte auf dem Dateisystem nach, ob es die Datei wirklich gibt und - wenn ja - was da drinsteht.
Die Angabe in dem Internal ist lediglich der Name der von FHEM ermittelten Logdatei, die verwendet werden sollte. Man kann daraus nicht ableiten, ob diese benannte Datei tatsächlich existiert.
Wie schon gesagt, free ist der falsche Befehl bzgl. (Festplatten-)Speicherplatz. Richtig ist df -h.
Kann aber auch einfach sein, dass deine SD-Karte hinüber ist.
File war nicht da.
Hat definitiv mit Speicher zu tun.
/dev/root war 84%
nach Löschen alter files nun so:
fhem@RasPi3:~ $ df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root 15G 7,4G 6,4G 54% /
devtmpfs 431M 0 431M 0% /dev
tmpfs 463M 0 463M 0% /dev/shm
tmpfs 463M 13M 451M 3% /run
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 463M 0 463M 0% /sys/fs/cgroup
/dev/mmcblk0p1 253M 54M 199M 22% /boot
/dev/sda1 15G 9,4G 5,6G 63% /media/usb
tmpfs 93M 0 93M 0% /run/user/1001
fhem@RasPi3:~ $
wollte dann mit
shutdown restartneu starten, dann hat sich FHEM aufgehängt
und konnte RasPi nur noch per Netz ein/aus starten
danach waren die alten Dateien wieder im Log-Ordner vorhanden
also wieder gelöscht, jetzt mal abwarten wie es weiterläuft
Grüße
Knut
Hallo,
ich würde an Deiner Stelle auch mal prüfen wie umfangreich die Linux System Logs sind. Vor einigen Jahren hatte ich ein ähnliches Problem. Da war Log Rotate nicht aktiviert und die System Logs haben alles blockiert.
Grüße Jörg
Zitat von: KNUT345 am 04 Februar 2026, 20:49:09...danach waren die alten Dateien wieder im Log-Ordner vorhanden...
Klingt auch merkwürdig. Oben war ja schon von einer defekten SD-Karte die Rede.
Ich finde es immer sinnvoll mal kurz zu schauen ob das Verzeichnis /lost&found leer ist. Wenn nicht gab es Fehler im Dateisystem die auf Fehler der Karte hindeuten können. Insbesondere wenn es viele Dateien sind.
Gruß Ralf
Ja, auf die SD-Karte habe ich auch schon getippt,
die ist schon recht alt.
/lost&found ist leer
Was ich mir nicht erklären kann.
Obwohl ich nun die alten Files schon mehrfach gelöscht habe,
die Devices auch wieder "normal" geloggt werden,
sind die alten Dateien am anderen Tag wieder da
und die aktuellen Logs sind weg.
Wie wenn ein Prozess alles wieder auf Start stellt.
Das einzige um Mitternacht passiert sind:
- save
- ein linux file copy von SD auf USB
Danke und Grüße
Knut
Zitat von: KNUT345 am 05 Februar 2026, 08:16:35ein linux file copy von SD auf USB
Was kopierst du hier?
Und: sicher, dass die "USB-Platte/Stick" auch gemountet ist? Weil wenn nicht, dann wird "lokal" kopiert (also "in" den Mountpoint, statt auf das "Mount-Ziel" <- logisch ist ja nicht da)
Gruß, Joachim
Zitat von: MadMax-FHEM am 05 Februar 2026, 09:34:19Und: sicher, dass die "USB-Platte/Stick" auch gemountet ist? Weil wenn nicht, dann wird "lokal" kopiert (also "in" den Mountpoint, statt auf das "Mount-Ziel" <- logisch ist ja nicht da)
Gruß, Joachim
ja, ist da
/dev/sda1 15G 9,4G 5,6G 63% /media/usb
Noch ein Hinweis zu dem "normalen" Loggen, das nicht so normal ist, denn
die Backup-Files von Gestern zeigen obwohl Datum von Heute zum Zeitpunkt der Datensicherung entweder:
- keine neuen Einträge, nur Einträge bis zum Beginn der Störung
- oder kryptische Einträge
Grüße, Knut
Hi,
Ich würde nach meiner Erfahrung bestätigen: wenn die SD nicht voll war ( was auch meist nur durch Beenden des Logging auffällt) ist sie am Sterben.
Ich hatte seit Wochen das Gefühl, dass ein FHEM, auf einem Raspberry den ich betreue, sich komisch verhält: Die Bedienung "ruckelte". Bei der Suche ist mir ein Tool vom Raspberry OS aufgefallen: agnostics.
sudo apt install agnosticsDann auf der Kommandozeile:
sh /usr/share/agnostics/sdtest.shDas lieferte bei mir ein solides Fail :( obwohl das System an sich scheinbar fehlerfrei lief. Gestern die SD getauscht (nur mit dd kopiert) und nun läuft alles wieder fluffig. Dabei lief die Erzeugung des Images von der SD auch eher unauffällig.
Wäre ein einfacher Test in solchen unklaren Fällen und scheint eventuell noch rechtzeitig vor dem totalem Ausfall zu warnen.
Edit: was mir noch auffiel: das setup installiert offenbar eine komplette GUI, was man eigentlich auf dem Server nicht will. Ich rate deshalb noch zur sparsamen Variante:
sudo apt install fioUnd dann von github (https://github.com/raspberrypi-ui/agnostics/tree/master/data)nur die beiden Dateien sd_bench.fio und sdtest.sh holen und nach /usr/share/agnostics kopieren.
Gruß Otto
Vielleicht nur der Hinweis, dass ich mich bei sterbender SD-Karte nicht unbedingt auf dd verlassen würde, sondern persönlich ein besseres Gefühl dabei hätte, wenn ich einfach das ganze System neu aufsetze und FHEM aus einem Backup restore.
Aber ausprobieren schadet natürlich auf keinen Fall.
Zitat von: Otto123 am 05 Februar 2026, 10:26:40(nur mit dd kopiert)
Sehe ich das richtig, dass du schlicht ein Image der alten SD auf eine neue SD gezogen hast?
Grüße, Knut
Ja neu aufsetzen wäre bestimmt besser,
zumal das System nun schon recht alt ist,
aber wenn halt das System gar nicht läuft dauert mir das zu lange.
Mal sehen ob einfaches kopieren funktioniert.
Ansonsten, dann eben neu aufsetzen.
Grüße, Knut
beim Wieder-Neustart sagt es nun
pi@RasPi3:/home/fhem $ sudo systemctl status fhem
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: ena
Active: active (running) since Mon 2026-02-02 08:18:45 CET; 3 days ago
Process: 644 ExecStart=/usr/bin/perl fhem.pl fhem.cfg (code=exited, status=0/S
Main PID: 652 (perl)
Tasks: 10 (limit: 2065)
CGroup: /system.slice/fhem.service
├─ 652 /usr/bin/perl fhem.pl fhem.cfg
├─1182 /usr/bin/perl fhem.pl fhem.cfg
├─1184 /usr/bin/perl fhem.pl fhem.cfg
├─1185 /usr/bin/perl fhem.pl fhem.cfg
├─1186 /usr/bin/perl fhem.pl fhem.cfg
├─1188 /usr/bin/perl fhem.pl fhem.cfg
├─1189 /usr/bin/perl fhem.pl fhem.cfg
├─1190 /usr/bin/perl fhem.pl fhem.cfg
├─1199 /usr/bin/perl fhem.pl fhem.cfg
└─1200 /usr/bin/perl fhem.pl fhem.cfg
Heißt es zeigt mir wieder den 02.02. an, wie wenn Datum nicht aktualisiert wird
Ein paar Sekunden später gibt es dann das fhem-2026-02-05.log
aber mit komischen Einträgen
OnTimeH: Hour: 0.000 Day: 0.000 Month: 106.407 Year: 302.002
2023-04-25_04:57:29 SolarNeu statMyOnTimeHHour: 0.000
2023-04-25_04:57:29 SolarNeu statMyOnTimeHDay: 0.000
2023-04-25_04:57:29 SolarNeu statMyOnTimeHMonth: 106.407
2023-04-25_04:57:29 SolarNeu statMyOnTimeHYear: 302.002
2023-04-25_04:57:29 SolarNeu statIstYear: 468.5
2023-04-25_04:58:59 SolarNeu Durchfluss: 0
2023-04-25_04:58:59 SolarNeu myLeistungN: 0.0
2023-04-25_04:58:59 SolarNeu myLeistung: 0
2023-04-25_04:58:59 SolarNeu myErtragN: 41024116686.09
2023-04-25_04:58:59 SolarNeu myErtrag: 11402.5
2023-04-25_04:58:59 SolarNeu mySolvis: 11484.7
2023-04-25_04:58:59 SolarNeu myEffizienz: 0.000
2023-04-25_04:58:59 SolarNeu statMyErtragTrend: 1497.9
2023-04-25_04:58:59 SolarNeu myState: off
2023-04-25_04:58:59 SolarNeu trend: 1497.9
2023-04-25_04:58:59 SolarNeu off
und die alten Files sind natürlich wieder da
Grüße, Knut
Das Systemdatum stimmt aber? Was gibt (über SSH) date?
Und was sagt das Syslog nach dem Neustart, siehst du da irgendwo das Datum springen? Es könnte natürlich sein, dass – wieso auch immer – der Pi mit 02.02. startet und dann erst nach einiger Zeit, wenn FHEM schon läuft, auf den 05.02. springt und dann systemd den Startzeitpunkt von FHEM aber (falsch, aber aus seiner Sicht aufgrund des Zeitsprungs richtig) auf "3 days ago" stellt.
Zitat von: KNUT345 am 05 Februar 2026, 17:24:38Sehe ich das richtig, dass du schlicht ein Image der alten SD auf eine neue SD gezogen hast?
genau :) aber offline!
Beim Raspberry wird beim ordentlichen Shutdown eine Datei mit der aktuellen (System) Zeit geschrieben. Beim Start geht es mit dieser Zeit los, wenn dann später Netzwerk, Internet und ntp läuft, wird die Zeit wieder aktuell gesetzt.
Kann (warum auch immer) beim shutdown (oder auch sonst) nicht geschrieben werden, steht die Zeit beim Start auf dem letzten Stand der Datei /etc/fake-hwclock.data
Ohne Internet bzw. ohne ntp wird die Zeit nicht aktuell gesetzt.
Zitat von: KNUT345 am 05 Februar 2026, 18:10:49und die alten Files sind natürlich wieder da
Das hört sich schon recht merkwürdig an -> Wo kommen die wieder her wenn sie wirklich gelöscht wurden :o
Vermutlich wäre ein Neuaufsetzen zielführend wenn das System "ordentlich" laufen muss.
Wenn es egal ist kann man natürlich noch suchen.
Problem gelöst.
Es war die SD-Karte.
Ich habe (noch einmal testweise) die Karte kopiert
und mit der neuen Karte läuft alles wieder wie gewohnt.
Nichts desto trotz.
Neu Aufsetzen werde ich zeitnah einplanen.
Danke für eure Tipps und Grüße
Knut